Tesi Matteo Miotto

UNIVERSITÀ DEGLI STUDI DI TRIESTE
FACOLTÀ DI INGEGNERIA
Corso di Laurea Triennale in Ingegneria Informatica
Progettazione e sviluppo di una applicazione per la

gestione di dati bibliografici in ambiente .NET
Relatore: Laureando:
Chiar.mo Prof. Maurizio Fermeglia Matteo Miotto
Anno accademico 2009 - 2010

Indice dei contenuti
Indice dei contenuti ........................................................................................................................................... 0
CAPITOLO 1 - Introduzione ............................................................................................................................... 3
CAPITOLO 2 – Analisi dei requisiti .................................................................................................................... 5
2.1 Analisi base di dati esistente .......................................................................................................... 5
2.2 Analisi applicazione esistente ......................................................................................................... 9
2.3 Requisiti .......................................................................................................................................... 9
2.3.1 Gestione staff .................................................................................................................. 9
2.3.2 Gestione pubblicazioni.................................................................................................. 10
2.3.3 Esportazione pubblicazioni ........................................................................................... 11
2.3.4 Upload documenti ........................................................................................................ 11
2.3.5 Gestione congressi ........................................................................................................ 11
2.3.6 Gestione progetti .......................................................................................................... 12
2.3.7 Gestione tesi ................................................................................................................. 12
2.3.8 Gestione corsi ............................................................................................................... 13
2.3.9 Report ........................................................................................................................... 14
2.3.10 Ulteriori requisiti ......................................................................................................... 14
CAPITOLO 3 - Progettazione ........................................................................................................................... 15
3.1 Principi generali di progettazione (User Experience & User Interface) ........................................ 15
3.2 Processo di progettazione ............................................................................................................ 15
3.3 Layout interfaccia utente .............................................................................................................. 16
CAPITOLO 4 – Interfaccia Utente.................................................................................................................... 18
4.1 Installazione e configurazione ...................................................................................................... 18
4.2 Utilizzo dell’applicazione .............................................................................................................. 19
4.2.1 Avvio dell’applicazione ................................................................................................. 19
4.2.2 Esempio d’uso ............................................................................................................... 20
CAPITOLO 5 - Implementazione ..................................................................................................................... 25
5.1 WPF e XAML.................................................................................................................................. 25
5.2 Navigation-Based Windows Applications ..................................................................................... 26
5.2.1 Containers ..................................................................................................................... 26
5.2.2 Navigazione tra le pagine .............................................................................................. 27
5.2.3 Passaggio di dati tra pagine .......................................................................................... 27
5.3 Implementazione di una pagina (XAML) ...................................................................................... 28
1
5.4 Data binding.................................................................................................................................. 32
5.4.1 Uso di LINQ to SQL ........................................................................................................ 32
5.4.2 Implementazione del data binding ............................................................................... 33
5.4.3 Data binding a livello di interfaccia utente (XAML) ...................................................... 34
5.4.4 Uso di DataGrid ............................................................................................................. 35
5.4.5 Data binding a livello di codice C# ................................................................................ 37
5.4.6 Navigazione tra record:................................................................................................. 39
5.4.7 Editing di record ............................................................................................................ 40
CAPITOLO 6 - Conclusioni ............................................................................................................................... 42
Bibliografia ....................................................................................................................................................... 43
2
CAPITOLO 1
Introduzione
L’obbiettivo di questa tesi è la progettazione e la realizzazione di un’applicazione che gestisca le attività del
laboratorio MOSE. Le principali attività di tale laboratorio prevedono essenzialmente la gestione dei dati
relativi alle pubblicazioni scientifiche, ma anche a progetti, congressi, tesi, componenti dello staff e corsi.
La situazione iniziale vede l’esistenza di una base di dati e un’applicazione realizzata in ambiente Microsoft
Office Access (in particolare si tratta di un file .ADP, Access Data Project). L’obbiettivo è, dunque, quello di
realizzare un’applicazione, in sostituzione a quella esistente, in grado di gestire le attività del laboratorio
MOSE, operando sulla base di dati esistente.
Ciò che ha motivato la realizzazione di una nuova applicazione è la necessità di svincolarsi dall’ambiente
Microsoft Office Access, sul quale è realizzata la precedente applicazione. Infatti l’esecuzione di tale
applicazione richiede il possesso, da parte dell’utente, della corretta versione di Microsoft Office Access,
nonché della relativa licenza. Inoltre, lo sviluppo di una nuova applicazione offre la possibilità di
riprogettare le modalità di presentazione dei dati e le operazioni da effettuare su di essi, al fine di
migliorare l’organizzazione e l’usabilità dell’applicazione stessa.
L’unico vincolo progettuale fa riferimento all’uso dell’ambiente .NET. Si è scelto, infatti, di sviluppare
l’applicazione utilizzando la tecnologia WPF (Windows Presentation Foundation) e il linguaggio di
programmazione C#.
Gli obiettivi del lavoro svolto sono stati:
 Studio delle tecnologie .NET, in particolare WPF e C#;

 Raccolta dei requisiti mediante interviste e analisi della base di dati e dell’applicazione esistenti;
 Progettazione del nuovo front-end (o interfaccia utente);
 Realizzazione dell’applicazione;
 Test.
In questa tesi verranno affrontati tutti i punti dello sviluppo della nuova applicazione, in particolare:
 Nel capitolo 2 verranno illustrate le modalità di raccolta e analisi dei requisiti, nonché la loro
presentazione;
 Nel capitolo 3 verranno esposti i principi generali seguiti per la progettazione dell’applicazione, con
particolare attenzione all’interfaccia utente, all’organizzazione e alla presentazione dei dati;
 Nel capitolo 4 verranno illustrate le modalità d’installazione e configurazione dell’applicazione.
Verrà inoltre esposto un esempio d’uso dell’applicazione;
3
 Nel capitolo 5 verranno considerati alcuni dettagli tecnici relativi all’implementazione
dell’applicazione, come lo sviluppo dell’interfaccia utente per mezzo della tecnologia WPF e del
data binding mediante l’uso di LINQ e il codice C#.
4
CAPITOLO 2
Analisi dei requisiti
2.1 Analisi base di dati esistente

L’analisi dei requisiti è stata effettuata principalmente analizzando la base di dati e l’applicazione esistenti.
Ulteriori vincoli e requisiti sono stati espressi dal committente in un’intervista. Per l’analisi dei requisiti non
è stata fornita documentazione relativa alla base di dati e all’applicazione(ADP).
La base di dati esistente viene utilizzata da:
 Il sito web del laboratorio MOSE. Tale sito, realizzato con la tecnologia Share Point, interroga la
base di dati per la visualizzazione delle informazioni (in sola lettura);
 Applicazione esistente (ADP);
 Applicazione “windows form” non utilizzata.
La base di dati è composta da 22 tabelle, 63 viste e 133 stored procedures. Tali elementi sono stati
esaminati durante la fase di analisi dei requisiti. In questa tesi verranno citate tabelle, viste e stored
procedures esclusivamente utilizzate dall’applicazione (ADP).
Si riporta di seguito lo schema relazionale della base di dati. Lo schema completo verrà suddiviso in più
parti per facilitarne la consultazione.
5
tblStaff tblStaffTitoli tblTitoli tblTipoPubbl
PK ID_Staff PK,FK1 ID_Staff PK ID_Titolo PK ID_TipoPubb
PK,FK2 ID_Titolo
Cognome Autori TipoPubblicazione
Nome Riferimento TipoPubEnglish
Attivo FK2 ID_Stato Class_TS
Username FK3 ID_Rivista Class_PD
Amministratore Anno
PhotoFileName Titolo
PhoneNumber FK1 ID_tipoPubb
tblStatoTitolo
OfficeLocation ID_SitoWeb tblRiviste
Email PK ID_Stato ImpactFactor
Summary ID_Settore PK ID_rivista
Eduacation Stato
ResearchActivity Statoen Denominazione
ResearchProject RivistaInternazionale
Collaborations Referee
Enabled LuogoPubblicazione
tblTitoloProgetto
tblStaffCongressi tblCongressi
PK,FK1 ID_Titolo
PK,FK1 ID_Staff PK ID_Congresso
PK,FK2 ID_Progetto
PK,FK2 ID_Congresso
Denominazione
Presentazione Data
Organizzazione Anno
Partecipazione CongressoInternazionale
Referee
tblCollegamentoKeywordsTitolo tblProgetti
PK,FK1 ID_Keyword PK,FK1 ID_Progetto
PK,FK2 ID_Titolo
Progetto
SiglaProgetto
Anno_Inizio
Anno_Fine
Finanziatore
ResponsabileLocale
ResponsabileGlobale
FinanziamentoLocale
FianziamentoGlobale
tblKeyword VisualizzaSito
TipoProgetto
PK ID_Keyword ImgProject
Summary
Keyword Link
Figura 2.1
La porzione di schema relazionale considerata in Figura 2.1 fa riferimento alle pubblicazioni. La tabella
tblTitoli rappresenta le pubblicazioni ed è il fulcro di questa porzione di diagramma relazionale.
6
tblStaff tblTesi tblTesiDettaglio
PK ID_Staff PK ID_Tesi PK,FK1 ID_Tesi
Cognome FK1 ID_Tipo DettaglioIT

Nome ArgomentoIT DettaglioEN
Attivo ArgomentoEN
Username Collaborazione
Amministratore Correlatori
PhotoFileName FK2 ID_Curriculum
PhoneNumber FK3 Stato
OfficeLocation FK4 ID_Relatore
Email Autore
Summary DataInizioTesi tblCurriculum
Eduacation MeseLaurea
ResearchActivity AnnoLaurea PK ID_Curriculum
ResearchProject Voto
Collaborations Curriculum
Enabled CurriculumEN
tblTesiStato tblTipiTesi
PK ID_Stato PK ID_Tipo
StatoTesi Tipo
Figura 2.2
La porzione dello schema relazionale riportata in Figura 2.2 si sviluppa attorno alla tabella tblTesi,
rappresentante le tesi.
tblStaff tblStaffCorsi tblCorsi

PK ID_Staff PK,FK1 ID_Staff PK ID_Corso
PK,FK2 ID_Corso
Cognome NomeCorso
Nome Organizzatore EnteOrganizzatore
Attivo Periodo
Username Luogo
Amministratore Anno
PhotoFileName
PhoneNumber
OfficeLocation
Email
Summary
Eduacation
ResearchActivity
ResearchProject
Collaborations
Enabled
Figura 2.3
Quest’ultima porzione di schema relazionale (Figura 2.3) fa riferimento ai corsi e alla partecipazione agli
stessi dei componenti dello staff.
7
Si riportano di seguito le viste utilizzate dall’applicazione esistente:
 viewTesi_ID: utilizzata per visualizzare le informazioni relative alle tesi, ordinate rispetto al campo
AnnoLaurea (ordinamento decrescente). Gli attributi di questa vista sono: ID_Tesi, ID_Tipo,
ArgomentoIT, ArgomentoEN, Collaborazione, Correlatori, ID_Curriculum, Stato,
ID_Relatore, Autore, DataInizioTesi, MEseLAurea, AnnoLaurea, Voto;
 viewTesi_Autore: utilizzata per visualizzare le informazioni relative alle tesi, ordinate rispetto al
campo Autore (ordinamento crescente). Gli attributi di questa vista sono: ID_Tesi, ID_Tipo,
ArgomentoIT, ArgomentoEN, Collaborazione, Correlatori, ID_Curriculum, Stato,
ID_Relatore, Autore, DataInizioTesi, MEseLAurea, AnnoLaurea, Voto;
 viewStaff: utilizzata per visualizzare l’elenco dei componenti dello staff. Gli attributi di questa vista
sono: ID_Staff, Cognome, Nome, Attivo;
 viewRiviste: utilizzata per visualizzare le informazioni relative alle riviste, ordinate rispetto al
campo Denominazione (nome della rivista). Gli attributi di questa vista sono: ID_rivista,
Denominazione, RivistaInternazionale, Referee, LuogoDiPubblicazione;
 viewReportTesiAreaChimica: utilizzata per visualizzare le informazioni relative alle tesi discusse
dei curriculum facenti parte dell’area chimica. L’ordinamento fa riferimento al campo AnnoLaurea
(ordinamento decrescente). Gli attributi di questa vista sono: ID_Tesi, ArgomentoIT,
Collaborazione, Correlatori, ID_Curriculum, Stato Tesi, Tipo, ArgomentoEN, Cognome
(del relatore, da tblStaff), Autore, DataInizioTesi, MEseLAurea, AnnoLaurea, Voto,
Curriculum;
 viewReportTesiAreaInformatica: utilizzata per visualizzare le informazioni relative alle tesi
discusse dei curriculum facenti parte dell’area informatica. L’ordinamento fa riferimento al campo
AnnoLaurea (ordinamento decrescente). Gli attributi di questa vista sono: ID_Tesi, ArgomentoIT,
Collaborazione, Correlatori, ID_Curriculum, Stato Tesi, Tipo, ArgomentoEN, Cognome
(del relatore, da tblStaff), Autore, DataInizioTesi, MEseLAurea, AnnoLaurea, Voto,
Curriculum;
 viewReportTesiNonDiscusse: utilizzata per visualizzare le informazioni relative alle tesi non
ancora discusse. L’ordinamento fa riferimento al campo AnnoLaurea (ordinamento decrescente).
Gli attributi di questa vista sono: ID_Tesi, ArgomentoIT, Collaborazione, Correlatori,
ID_Curriculum, Stato Tesi, Tipo, ArgomentoEN, Cognome (del relatore, da tblStaff),
Autore, DataInizioTesi, MEseLAurea, AnnoLaurea, Voto, Curriculum.
Si riportano di seguito le stored procedures utilizzate dall’applicazione esistente:
 sp_PubbStaff: utilizzata per visualizzare le pubblicazioni relative a un componente dello staff. La

sua esecuzione richiede due parametri: ID_staff, ovvero l’identificatore del componente dello
staff per il quale si vogliono visualizzare le relative pubblicazioni, e ID_Output, ovvero
l’identificatore (valori possibili: 0,1,2) che permette di scegliere la modalità di visualizzazione delle
informazioni (con il valore 0 vengono visualizzate sia le pubblicazioni presentate in un congresso
che in una rivista, mentre con i valori 1 e 2 vengono visualizzate le pubblicazioni presentate
rispettivamente in congressi e pubblicazioni);
 Sp_Pubbweb: utilizzata per visualizzare le pubblicazioni presentate nel sito web del laboratorio
MOSE. La sua esecuzione richiede un parametro: ID_SitoWeb, ovvero l’identificatore del sito web.
8
2.2 Analisi applicazione esistente
Come già accennato in precedenza, l’applicazione esistente è realizzata in ambiente Microsoft Access. In
particolare si tratta di un file di tipo ADP, ovvero Access Data Project. L’applicazione è composta da 27
maschere (si intendono sia le maschere che le sotto maschere) e 7 report. Con il termine “maschera” si
intende la finestra (o form) all’interno di un’applicazione di MS Access.
Analizzando singolarmente le maschere è stato possibile individuare l’insieme dei dati da visualizzare e le
operazioni che si desiderano effettuare su di essi. Sono state eseguite inoltre delle prove per verificare
l’usabilità dell’interfaccia utente, identificare i punti di forza e le caratteristiche da migliorare o aggiungere.
Tutti gli elementi raccolti nella fase di analisi hanno portato alla stesura dei requisiti, esposti nel capitolo
2.3.
2.3 Requisiti
Dall’analisi della basi di dati, dell’applicazione esistente e dall’intervista con il committente è possibile
individuare i requisiti dell’applicazione. Essi verranno suddivisi in più parti al fine di migliorarne la
consultazione.
2.3.1 Gestione staff
Le attività relative allo staff del laboratorio MOSE consistono nella gestione dei dati relativi al
personale.
Si desiderano visualizzare i seguenti dati:
 ID_Staff;
 Cognome;
 Nome;
 Active status: indica lo stato di attività/inattività del soggetto;
 Username;
 Admin Status: indica se il soggetto è amministratore o meno;
 Nome del file immagine associata: immagine presente sul server web del laboratorio che
deve essere visualizzata nel sito web. In caso non sia presente alcuna immagine associata al
soggetto, per convenzione si utilizza il file “nofoto.jpg”;
 Numero di telefono;
 Ubicazione dell’ufficio;
 Email;
 Dati relativi al curriculum:
o Sommario;
o Educazione;
o Attività di ricerca;
o Progetti di ricerca;
o Collaborazioni.
Si desiderano effettuare le seguenti operazioni sui dati:
9
 Aggiunta, modifica, rimozione di un componente dello staff;
 Visualizzazioni lista e dettaglio.
2.3.2 Gestione pubblicazioni
I dati che si desiderano memorizzare e gestire sono:
 Dati relativi alle pubblicazioni:

o ID Titolo;
o Autori: formato non normalizzato, che consiste in una stringa contenente l’elenco
di tutti gli autori che hanno partecipato a una particolare pubblicazione;
o Anno;
o Riferimento;
o Rivista di pubblicazione;
o Congresso di presentazione e/o pubblicazione;
o Titolo;
o Lista keywords associate alla pubblicazione;
o Lista dei progetti a cui la pubblicazione fa riferimento;
o Tipo di pubblicazione;
o Stato della pubblicazione;
o Sito web;
o Settore;
o Impact Factor;
o Lista dei componenti dello staff che hanno partecipato alla pubblicazione.
 Dati relativi ai tipi di pubblicazione:
o ID Tipo;
o Descrizione del tipo di pubblicazione (Italiano);
o Descrizione del tipo di pubblicazione (Inglese);
o Class UNITS;
o Class UNIPD.
 Dati relativi allo stato delle pubblicazioni:
o ID Stato;
o Descrizione Stato.
 Dati relativi alle riviste di pubblicazione:
o ID Rivista;
o Denominazione;
o Internazionale (si/no);
o Referee (si/no);
o Luogo di pubblicazione.
 Dati relativi alle keywords:
o ID Keyowrd;
o Keyword.
Le operazioni che si desiderano effettuare su tali dati sono:
 Aggiunta, modifica e rimozione di pubblicazioni, tipi di pubblicazione, stati delle

pubblicazioni, riviste, keywords;
10
 Per le pubblicazioni sono necessarie le visualizzazioni lista, dettaglio e personalizzata.
Quest’ultima offre la possibilità di visualizzare le pubblicazioni relative ad un componente
dello staff scelto dall’utente;
 Visualizzazione lista per tipi di pubblicazione, stato delle pubblicazioni, riviste e keywords.
2.3.3 Esportazione pubblicazioni
L’esportazione delle pubblicazioni è un processo che prevede la scrittura su un file di testo (.txt) in
formato “comma separated” dei dati relativi alle pubblicazioni secondo diverse modalità. Il
processo di esportazione si snoda lungo i seguenti punti:
1. Scelta del componente dello staff per il quale si desiderano esportare le pubblicazioni;
2. Scelta del formato di esportazione tra i seguenti:
a. Autore, titolo, rivista, riferimento;
b. Autore, rivista, riferimento, titolo;
c. Titolo, autore, rivista, riferimento;
d. Rivista, riferimento, titolo, autore;
e. Rivista, riferimento, autore, titolo.
3. Scelta di informazioni aggiuntive tra le seguenti:
a. Numero;
b. Tipo;
c. Stato Titolo;
d. Anno.
4. Scelta della cartella di destinazione;
5. Esecuzione dell’esportazione.
2.3.4 Upload documenti
L’upload dei documenti è un processo che prevede il salvataggio di un documento relativo ad una
pubblicazione in una directory del server del laboratorio MOSE. Il processo si snoda lungo i seguenti
punti:
1. Scelta di una pubblicazione da una lista;

2. Scelta della lettera iniziale del nome del file tra le seguenti:
a. d (file .doc);
b. p (file .pdf);
c. s (file .ppt).
3. Scelta del file “in locale”;
4. Scelta della cartella di destinazione;
5. Eseguire l’upload nella cartella di destinazione.
2.3.5 Gestione congressi
I dati relativi ai congressi che si desiderano memorizzare e gestire sono:
 ID Congresso;
 Denominazione;
 Data;
11
 Anno;
 Congresso Internazionale (si/no);
 Referee (si/no);
 Lista dei componenti dello staff che partecipano a un congresso:
o Cognome;
o Partecipazione (si/no);
o Organizzazione (si/no);
o Presentazione (si/no).
 Aggiunta, modifica, rimozione di un congresso;

 Visualizzazione dettaglio.
2.3.6 Gestione progetti
I dati relativi ai progetti che si desiderano memorizzare e gestire sono:
 ID Progetto;
 Sigla;
 Denominazione del progetto;
 Anno inizio;
 Anno fine;
 Finanziatore;
 Finanziamento locale;
 Finanziamento globale;
 Responsabile locale;
 Responsabile globale;
 Visualizza sul sito (si/no);
 Immagine del progetto (nome del file);
 Link sito;
 Tipo progetto: numero intero (0 nessuno, 1 processo, 2 materiali, 3 bio, 4 ICT);
 Sommario(codice html).
 Aggiunta, modifica, rimozione di un progetto;

 Visualizzazioni lista e dettaglio.
2.3.7 Gestione tesi
 Dati relativi alle tesi:

o Numero (identificativo);
o Autore;
o Relatore: componente dello staff;
o Curriculum;
12
o Correlatori;
o Collaborazione;
o Tipo Tesi;
o Titolo della tesi in italiano e inglese;
o Stato della tesi;
o Data inizio tesi;
o Mese laurea;
o Anno laurea;
o Voto;
o Abstract (dettaglio della tesi).
 Dati relativi ai curriculum:
o ID Curriculum;
o Denominazione in italiano e in inglese.
 Dati relativi ai tipi di tesi:
o Id Tipo;
o Denominazione.
 Dati relativi allo stato della tesi:
o ID Stato;
o Descrizione dello stato.
 Aggiunta, modifica, rimozione di tesi, curriculum, tipo tesi e stato tesi;

 Visualizzazione lista per curriculum, tipo tesi e stato tesi;
 Visualizzazioni lista e dettaglio per le tesi;
 Ordinamenti “alfabetico” e “per anno” per quanto riguarda le tesi.
2.3.8 Gestione corsi
 ID Corso;
 Nome del corso;
 Ente organizzatore;
 Periodo;
 Luogo;
 Anno;
 Lista dei componenti dello staff che partecipano ai corsi (Cognome, organizzatore(si/no)).
 Aggiunta, modifica, rimozione di un corso;

 Visualizzazione dettaglio.
13
2.3.9 Report
È prevista la creazione di 7 tipi di report. In particolare 4 report per le pubblicazioni e 3 per le tesi.
Per quanto riguarda i report relativi alle pubblicazioni essi sono “personalizzati”, ovvero riguardano
le pubblicazioni di un componente dello staff scelto. Nello specifico:
 Report totale delle pubblicazioni: i dati che vengono visualizzati sono: Anno, ID
Pubblicazione, Autori, Rivista-Convegno di pubblicazione, Riferimento, Titolo,
Tipo di pubblicazione;
 Report “per anno”: i dati che vengono visualizzati sono: Titolo, Autori, Denominazione,
Riferimento, Titolo, Tipo pubblicazione, Stato. Tali dati vengono raggruppati secondo
l’anno di pubblicazione;
 Report “per tipo di pubblicazione”: i dati che vengono visualizzati sono: Anno, ID
Pubblicazione, Autori, Rivista-Convegno di pubblicazione, Titolo, Riferimento. Tali
dati vengono raggruppati secondo il tipo di pubblicazione;
 Report “per numero”: i dati che vengono visualizzati sono: ID Pubblicazione, Anno,
Autori, Denominazione, Riferimento, Titolo, Tipo, Stato. Tali dati vengono visualizzati
con ordinamento crescente rispetto al campo ID Pubblicazione.
Per quanto riguarda i report relativi alle tesi, si prevede nello specifico:
 Report “area chimica”: visualizza le tesi relative ai curriculum dell’area chimica,

raggruppandole secondo l’anno di laurea;
 Report “area informatica”: visualizza le tesi relative ai curriculum dell’area informatica,
raggruppandole secondo l’anno di laurea;
 Report “tesi non discusse”: visualizza le tesi ancora non discusse di tutti i curriculum,
raggruppandole secondo l’anno di laurea.
Tutti i report relativi alle tesi visualizzano i seguenti dati: Autore, ID Tesi, Titolo Tesi, Tipo,
Collaborazione, Stato, Data Laurea, Voto.
2.3.10 Ulteriori requisiti
Un’ulteriore requisito espresso dal committente riguarda l’integrazione dell’applicazione in

un’unica finestra.
14
CAPITOLO 3
Progettazione
3.1 Principi generali di progettazione (User Experience & User Interface)

Dall’analisi dell’applicazione esistente (realizzata in ambiente MS Access) sono stati individuati i punti di
forza e soprattutto i punti deboli dell’interfaccia utente (o User Interface, brevemente UI). Dato che
l’obbiettivo principale è la riprogettazione del front-end, è stato svolto uno studio sulla User Experience,
ovvero tutto ciò che riguarda l’esperienza utente durante l’utilizzo della User Interface. Anche se il concetto
di User Experience dà l’impressione di essere prettamente filosofico, esso può diventare un’importante
strumento alla base della progettazione di un’interfaccia utente, elemento spesso fondamentale per il
successo di un’applicazione.
Dallo studio effettuato ci si propone di progettare il nuovo front-end attenendosi ai seguenti principi
generali:
 Applicazione integrata in un’unica finestra;

 Rendere l’applicazione semplice da utilizzare;
 Ridurre la complessità delle informazioni presentate all’utente;
 Aiutare l’utente a concentrarsi sulle attività importanti;
 Suggerire azioni legate all’attività che l’utente sta svolgendo;
 Organizzare e raggruppare i concetti in base all’attività dell’utente e non unicamente in base alla
struttura della base di dati;
 Organizzare i contenuti in maniera ordinata e semplice da consultare;
 Creazione di un interfaccia “familiare”, conosciuta dall’utente.
Sulla base di questi principi generali si è basata la progettazione del nuovo front-end.
3.2 Processo di progettazione

Partendo dall’ultimo principio di progettazione elencato precedentemente, si è scelto di realizzare
un’interfaccia utente avente l’aspetto simile alle applicazioni della suite Microsoft Office 2010. Tale scelta è
stata fatta tenendo conto della familiarità che l’utente possiede nell’utilizzo di tali applicazioni.
Nella progettazione del nuovo front-end è stata effettuata una riorganizzazione delle attività. Infatti,
mentre nell’applicazione esistente le attività erano profondamente legate alla struttura della base di dati,
nel nuovo front-end si è cercato di raggruppare le attività correlate tra loro. Questo raggruppamento è
stato realizzato in base a:
15
 Rilevanza di un’attività nel complesso della gestione;
 Mole di dati che un’attività necessità di gestire;
 Frequenza di esecuzione di un’attività.
Il raggruppamento ha portato alla definizione di attività principali e secondarie. Nella progettazione

dell’interfaccia utente le attività principali dovranno essere facilmente individuabili e accessibili dall’utente.
Le attività secondarie, invece, verranno suggerite all’utente a seconda del contesto in cui si trova.
Una volta identificate le attività principali, per ognuna di esse s’individuano:
 I dati che l’attività necessita gestire:

o Raggruppamento dei dati a seconda della loro importanza, frequenza di utilizzo e
dimensione;
o Visualizzazione delle informazioni principali, ponendo in secondo piano i dati meno
importanti o meno utilizzati. In questo modo si aumenta la facilità nella consultazione delle
informazioni.
 Le operazioni frequenti e ripetitive sui dati. Tali operazioni dovranno essere eseguibili facilmente.
Per questo motivo gli strumenti per accedere alle operazioni principali dovranno essere posti in
primo piano;
 Le attività secondarie (correlate e meno frequenti). Queste attività verranno poste in secondo
piano.
Raccogliendo tutti questi elementi si passa alla definizione del layout della User Interface.
3.3 Layout interfaccia utente

Alcuni studi sulla User Experience condotti dalle più importanti software house, utilizzando sofisticate
tecniche (come l’eyetracking, ovvero il tracciamento dello sguardo sullo schermo), hanno mostrato come gli
utenti spesso “leggono” le pagine web e interfacce utente come due linee orizzontali in alto, seguite da una
striscia verticale sulla parte sinistra dello schermo, secondo quello che è noto come “schema a F”.
Tenendo conto di tutti gli elementi finora raccolti per la progettazione dell’interfaccia utente, si
rappresenta in figura 3.1 il modello di layout scelto per il nuovo front-end.
Analizzando il layout:
1. Activity Pane: è il pannello che contiene le attività principali. Corrisponde al raggruppamento

effettuato nel capitolo 3.2. Le attività principali sono rappresentate con un rettangolo grigio;
2. Action Pane: è il pannello contenente le operazioni principali che si intendono eseguire sui dati. In
questo pannello si possono trovare, ad esempio, i pulsanti di navigazione, editing dei record,
modalità di visualizzazione, ecc.;
3. Action Group: è un raggruppamento logico delle operazioni. Il titolo del gruppo è rappresentato
con un rettangolo grigio. Un esempio di gruppo di operazioni può essere quello relativo ai pulsanti
di navigazione (vai al primo record, record precedente, record successivo, ultimo record, record
corrente);
4. Action: è un pulsante che permette l’esecuzione di un’operazione. La maggior parte dei pulsanti ha
una struttura composta da icona (rettangolo grigio) e testo (rettangolo blu) per migliorarne la
16
comprensione. Spesso alcuni pulsanti possono raggruppare più operazioni che verranno rese
accessibili all’utente premendo il pulsante stesso;
5. Navigation pane: panello contenente l’elenco delle attività e delle operazioni secondarie. Può
inoltre contenere delle attività correlate suggerite all’utente. L’elenco ha una struttura ad albero, in
modo da permettere l’espansione o la contrazione di gruppi di attività (il gruppo di attività è
rappresentato da un rettangolo blu, mentre le singole attività sono rappresentate da un rettangolo
grigio);
6. Content Area: è l’area che raccoglie e organizza tutti i dati relativi all’attività corrente, il cui titolo è
rappresentato (in figura 3.1) con un rettangolo azzurro;
7. Expander Group: è un pannello che può essere espanso (7) o compresso (8) e contiene i dati da
presentare all’utente. La funzione di espansione/compressione del pannello permette all’utente
rispettivamente di rendere visibili/nascondere gruppi di dati non utili alla consultazione. Questo
consente di ridurre la complessità dei dati presentati all’utente. I dati all’interno di un expander
group sono riuniti in gruppi logici (per descrivere, ad esempio, il dettaglio anagrafico di un soggetto
un gruppo può contenere informazioni di carattere generale, un altro gruppo può contenere dati
relativi ai contatti, e così via);
8. Expander Group compresso;
9. Status Bar: visualizza lo stato dell’applicazione, notifica i salvataggi, le modifiche ai dati e lo stato di
connessione al database.
Figura 3.1
17
CAPITOLO 4
Interfaccia Utente
4.1 Installazione e configurazione

L’installazione e la configurazione non si presentano come punti critici del ciclo di vita di questa
applicazione.
Per quanto riguarda l’installazione dell’applicazione è previsto l’impiego della tecnologia ClickOnce. Click
Once è una tecnologia di distribuzione che consente di creare applicazioni basate su Windows. Esse sono
aggiornabili in qualsiasi momento e possono essere installate ed eseguite con un’interazione minima da
parte dell’utente. ClickOnce risolve un’importante problema: l’aggiornamento dell’applicazione. Questa
operazione infatti installa solamente le parti dell’applicazione che hanno subito modifiche, a differenza di
altre tecnologie (ad esempio MS Windows Installer) che nel processo di aggiornamento reinstallano
completamente le applicazioni.
La configurazione dell’applicazione è molto veloce. Gli unici elementi che hanno necessità di configurazione
sono:
 Stringa di connessione alla base di dati;

 Posizione della directory di destinazione per l’upload di documenti;
 Posizione della directory di destinazione per l’esportazione di documenti.
La configurazione della stringa di connessione può essere effettuata in 2 modi:
 Modifica del file di configurazione: procedura consigliata per utenti esperti. Essa prevede la
modifica del file (XML) denominato “MoseUXPrototype.exe.config”. Esempio di configurazione:
connectionString="Data Source=SERVER_NAME;Initial Catalog=MoseDB;Integrated
Security=True"
L’unica modifica necessaria è quella relativa al campo “Data Source”. Il valore da inserire è quello
relativo al nome del server (SQL Server);
 Configurazione guidata: procedura avviabile all’interno dell’applicazione.
Anche per quanto riguarda la configurazione delle directory di upload ed esportazione è disponibile una
configurazione guidata all’interno dell’applicazione. Per quanto riguarda la directory di esportazione, se
non viene specificata una particolare directory, la destinazione dell’esportazione sarà la directory
contenente il file eseguibile dell’applicazione.
18
4.2 Utilizzo dell’applicazione
Nel capitolo 3 (Progettazione) sono stati descritti i principi e le idee di base sui quali è stata sviluppata
l’interfaccia utente (o UI, User Interface). In questo capitolo si provvederà a fornire una panoramica sulle
funzionalità e sull’uso dell’applicazione.
Come accennato in precedenza, nel processo di progettazione è stata fatta una distinzione tra attività di
gestione principali e secondarie. In tabella 4.1 sono elencate le attività di gestione principali e, per ognuna
di esse, le attività secondarie e correlate.
PRINCIPALI PUBBLICAZIONI STAFF CONGRESSI PROGETTI TESI CORSI
Keywords Curriculum
Riviste Tipi Tesi
SECONDARIE
Tipi Pubb. Stati Tesi
Stati Pubb.
Staff Pubblicazioni Staff Pubblicazioni Staff Staff

Progetti Congressi Staff
CORRELATE Congressi Progetti
Tesi
Corsi
Tabella 4.1 – Gerarchia e organizzazione delle attività di gestione
Le attività secondarie sono attività che hanno a che fare con le relative attività principali ma la loro
importanza, la loro frequenza d’uso e la loro mole di dati sono minori rispetto alle attività principali. Le
attività correlate invece sono attività che vengono suggerite all’utente quando si trova in un certo contesto
(attività principale).
4.2.1 Avvio dell’applicazione
Fatta questa importante premessa sull’organizzazione delle attività, è possibile analizzare più in
dettaglio l’interfaccia utente e il suo utilizzo. All’avvio l’applicazione si presenta come una finestra
che occupa tutta la superficie dello schermo. È possibile ridurre le dimensioni della finestra ma non
oltre le dimensioni minime (800x600px), fissate per evitare “tagli” di visualizzazione.
Come già discusso nel capitolo 3.3, nella parte superiore dell’applicazione sono presenti le attività
principali. Esse sono disposte una di fianco all’altra per permettere una navigazione “a schede”. La
prima voce a sinistra non fa riferimento ad un’attività ma ad una pagina denominata “Home”
(Figura 4.1). Questa è la pagina visualizzata all’avvio dell’applicazione e permette l’accesso veloce a
tutte le attività principali e secondarie e alle funzionalità di configurazione.
19
Figura 4.1
Come è possibile notare dalla figura 4.1 le varie attività all’interno della pagina “Home” sono
contenute in gruppi. I controlli che realizzano i raggruppamenti sono denominati expander. Gli
expander sono dei controlli aventi un titolo e un contenuto che può essere espanso o compresso al
fine di migliorare l’organizzazione e regolare a piacimento la quantità di informazioni visualizzate.
4.2.2 Esempio d’uso
Per iniziare ad utilizzare l’applicazione basta fare click su una voce della pagina Home oppure
scegliere una tra le attività principali contenute in activity pane (vedi capitolo 3.3). Per offrire un
esempio che sia il più completo possibile, senza analizzare ogni singola attività dell’applicazione, si
consideri l’attività di gestione delle pubblicazioni. Le rimanenti attività hanno un funzionamento
identico.
La visualizzazione di default per le pubblicazioni (come per tutte le altre attività principali) è la
visualizzazione dettaglio (Figura 4.2).
20
Figura 4.2
Facendo riferimento alla figura 4.2:
1. Nel pannello delle azioni principali (action pane,

capitolo 3.3) si trova il gruppo delle azioni relative
alla navigazione (figura 4.3). Da destra a sinistra:
a. Pulsante “primo elemento”: permette di
visualizzare i dati del primo record. In
questo caso permetterà di visualizzare la
Figura 4.3
prima pubblicazione presente nella base di
dati (l’ordinamento in questo caso fa riferimento al campo ID_Pubblicazione);
b. Pusante “elemento precedente”: permette di visualizzare il record precedente a
quello corrente;
c. “Elemento corrente”: indica la posizione del record corrente all’interno di tutte le
pubblicazioni;
d. Pulsante “elemento successivo”;
e. Pulsante “ultimo elemento”.
2. In action pane si trova il gruppo delle azioni che
permettono l’editing (figura 4.4) di pubblicazioni. Si ha:
a. Pulsante “Aggiungi”: permette l’aggiunta di una
nuova pubblicazione. All’interno dell’area
contenuti (content area, capitolo 3.3) tutti i
campi saranno vuoti, pronti per l’inserimento di
Figura 4.4
nuovi dati. Il cursore si posiziona
automaticamente in corrispondenza del primo campo editabile;
b. Pulsante “Salva”: permette il salvataggio di una nuova pubblicazione e/o di
modifiche apportate;
c. Pulsante “Rimuovi”: permette la rimozione della pubblicazione corrente.
21
permettono l’aggiunta e la rimozione degli elementi che
sono in relazione uno a molti con le pubblicazioni (figura
4.5). Tra questi si trovano i componenti dello staff, i
progetti e le keywords (da destra a sinistra). Facendo click
su uno dei tre pulsanti apparirà un menù a tendina (detto
anche context menu) il quale visualizzerà le possibili
azioni che si possono compiere sul corrispondente Figura 4.5
elemento (staff, progetto, keyword):
a. Pulsante “Aggiungi”: permette la creazione di un nuovo elemento. Se ad esempio si
intende aggiungere un nuovo componente dello staff che ha partecipato alla
pubblicazione corrente, nella griglia relativa ai componenti dello staff (figura 4.2,
punto 8) comparirà una nuova riga;
b. Pulsante “Rimuovi”: permette la rimozione dell’elemento selezionato nella griglia
corrispondente. Ad esempio, considerando un elemento dello staff nella griglia
(figura 4.2, punto 8), selezionando la riga corrispondente all’elemento e facendo
click sul pulsante “Rimuovi”, il componente verrà rimosso dalla pubblicazione.
permettono di scegliere il tipo di visualizzazione da
adottare (figura 4.6). Per quanto riguarda le pubblicazioni
si ha:
a. Visualizzazione “Dettaglio”: il pulsante è
disattivato dato che ci si trova già nella
Figura 4.6
visualizzazione “dettaglio”;
b. Visualizzazione “Griglia”: permette di visualizzare i dati relativi alle pubblicazioni
disposti in una griglia. In tale visualizzazione sono presenti tutte le pubblicazioni;
c. Visualizzazione “Staff”: permette di visualizzare le pubblicazioni relative ad un
componente dello staff scelto.
5. In action pane si trova il gruppo delle azioni relative alle
funzionalità di esportazione ed upload delle pubblicazioni (figura
4.7). Facendo click su questi pulsanti si accederà alle funzionalità
relative;
6. Content pane (o area dei contenuti): in essa sono presenti tutti i
Figura 4.7
dati relativi alle pubblicazioni. Tali dati sono raccolti e suddivisi in
gruppi logici (figura 4.2, punti 7 e 9) all’interno di expander. Gli expander possono essere
compressi o espansi, come mostrato in figura 4.8, dove l’expander relativo alle
“Informazioni di Pubblicazioni” è stato compresso;
22
Figura 4.8
7. Gruppo “Informazioni Generali”: controllo di tipo expander, contiene tutte le informazioni
di carattere generale relative alle pubblicazioni;
8. Griglia relativa ai componenti dello staff che hanno partecipato alla pubblicazione. Come
per tutte le griglie (e dunque anche per quanto riguarda i punti 10 e 11), l’aggiunta di un
componente può essere fatta premendo il tasto tab fino alla creazione di una nuova riga. La
rimozione, invece, può essere effettuata selezionando la riga che si desidera rimuovere e
premendo il tasto canc;
9. Gruppo “Informazioni Pubblicazione”: controllo di tipo expander, contiene tutte le
informazioni specifiche sulla pubblicazione;
10. Griglia relativa ai progetti cui la pubblicazione fa riferimento;
11. Griglia relativa alle keywords relative alla pubblicazione;
12. Status Bar: indica lo stato dell’applicazione. Essa notifica eventuali salvataggi, rimuozioni e
aggiunte di nuove pubblicazioni;
13. Pannello di navigazione (o navigation pane): contiene le attività secondarie e le attività
correlate. È strutturato ad albero, in modo che sia possibile nascondere/visualizzare le
informazioni che si desiderano.
A titolo dimostrativo, di seguito si riportano le immagini relative alla visualizzazione griglia (figura
4.9) e visualizzazione staff (figura 4.10) delle pubblicazioni. Per motivi di spazio viene riportata
solamente la parte contenuta all’interno dell’area contenuti (content area).
Figura 4.9
23
Figura 4.10
Sia in figura 4.9 che in figura 4.10 è possibile notare come le griglie visualizzino le righe a colori
alternati, al fine di migliorarne la consultazione.
Nella visualizzazione staff relativa alle pubblicazioni(figura 4.10) è possibile notare la presenza sulla
sinistra di una lista contenente tutti i componenti dello staff. La griglia posizionata in destra
visualizzerà le pubblicazioni relative al componente dello staff selezionato.
Un’ultima funzionalità da sottolineare è la

gestione delle attività secondarie. Nel
pannello di navigazione (figura 4.10, punto
13), facendo click su una delle azioni
secondarie, si aprirà una finestra pop-up
che ne permetterà la gestione. In figura
4.11 è riportato un esempio di gestione di
attività secondaria, in particolare la
gestione dei tipi di pubblicazione.
Figura 4.11
24
CAPITOLO 5
Implementazione
5.1 WPF e XAML

WPF (o Windows Presentation Foundation) è una tecnologia sviluppata da Microsoft. WPF può essere
definito in molti modi (una libreria, un framework, un sottosistema, un insieme di controlli, un linguaggio,
un modello di programmazione). Probabilmente, il modo più semplice per capire cosa sia WPF è pensarlo
come un insieme di oggetti che permette di realizzare (complesse) interfacce utente in modo semplice,
“estendendo gli orizzonti” delle applicazioni Windows Form.
Le principali caratteristiche di WPF possono essere incluse tra le seguenti:
 Ampia integrazione: WPF integra molte tecnologie diverse tra loro, permettendo l’uso di
applicazioni contenenti elementi 3D, 2D, video, documenti e controlli e molto altro;
 Indipendenza della risoluzione: gli elementi sullo schermo possono essere compressi o estesi
indipendentemente dalla risoluzione dello schermo. Questo è possibile perché il rendering di
elementi WPF si basa sulla grafica vettoriale;
 Accelerazione hardware: WPF è costruito su Direct3D, quindi i contenuti, che siano 2D, 3D o
semplicemente caratteri, vengono converti in oggetti Direct3D e il rendering viene eseguito
dall’hardware;
 Programmazione dichiarativa: la combinazione di WPF e XAML è simile all’uso di HTML per definire
un’interfaccia utente. Infatti le applicazioni WPF necessitano del codice XAML (eXtensible
Application Markup Language) per la “descrizione” dell’interfaccia utente e del codice C# (o VB,
Visual Basic) per l’implementazione degli algoritmi. Questa caratteristica di WPF è molto
importante perché permette di separare l’implementazione dell’interfaccia utente dalla scrittura
del codice sottostante. Questo può essere un elemento utile quando ad esempio più team lavorano
su diverse parti. Ogni elemento (ad esempio una finestra) contenuto nell’applicazione sarà dunque
costituito da due files: NomeElemento.xaml e NomeElemento.xaml.cs. Il primo è il file contenente il
codice XAML, il secondo invece contiene il codice (in questo caso) C#;
 Composizione e personalizzazione: WPF permette la creazione di controlli utente composti da più
controlli elementari e la personalizzazione dei controlli stessi.
XAML è, in generale, un linguaggio di programmazione dichiarativo adatto alla costruzione e inizializzazione

di oggetti. XAML è, in particolare, un linguaggio di markup basato su XML, composto da un insieme di
regole per la descrizione di oggetti e i loro attributi, le loro proprietà e i valori delle proprietà stesse. Il
paragone tra il solo XAML e HTML è fuorviante. Infatti XAML consiste in alcune parole chiave e regole che
parser e compiler seguono per capire come utilizzare il codice XML, ma non definisce alcun elemento
25
interessante di per sé. Quindi parlare di XAML senza un framework come WPF è come parlare di C# senza il
.NET Framework.
5.2 Navigation-Based Windows Applications

L’applicazione realizzata è un’applicazione di tipo navigation-based. Esistono molte applicazioni così
implementate, per citarne alcune: Windows Explorer, Windows Media Player e anche il software ERP
Microsoft Dynamics NAV.
WPF mette a disposizione una “built-in infrastructrure” per la realizzazione di applicazioni di questo genere.
La caratteristica principale di un’applicazione navigation-based è quella di poter mostrare contenuti e
navigare tra essi come in un browser web. Lo sviluppo di un’applicazione di questo genere non influisce
sulla progettazione dell’applicazione.
La scelta di realizzare un’applicazione navigation-based è stata presa per semplificare l’implementazione

dell’interfaccia, il cui requisito fondamentale era la sua realizzazione integrata in un'unica finestra. Dunque
la finestra contenente l’applicazione funge da “browser” e le singole schermate fungono da pagine web. È
questo uno dei motivi per i quali in precedenza, in questa tesi, una schermata dell’applicazione veniva
anche chiamata “pagina”.
5.2.1 Containers
Quando si realizza un’applicazione navigation-based in WPF, i contenuti sono tipicamente

organizzati in elementi chiamati Page. Un elemento Page è fondamentalmente una versione
semplificata di una classe Window. Gli elementi Page possono essere ospitati in due navigation
containers: NavigationWindow o Frame. Questi contenitori provvedono a fornire un modo per
navigare da una pagina all’altra, un diario (o journal) che tiene traccia della cronologia di
navigazione e una serie di eventi relativi alla navigazione.
L’applicazione, dunque, è costituita da un solo elemento Window. L’elemento in questione è stato

denominato MainWindow. Come già detto ogni elemento in WPF è definito da due file. Dunque la
finestra MainWindow è composta dai file MainWindow.xaml e MainWindow.xaml.cs.
Si analizza ora il codice XAML della finestra MainWindow (ovvero il contenuto del file
MainWindow.xaml):
1 <Window
2 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
3 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
4 x:Class="MoseUXPrototype.MainWindow"
5 x:Name="Window"
6 Title="Gestione Attività Mose"
7 Width="800" Height="600" Background="#FFE0E4E7"
8 WindowStartupLocation="CenterScreen"
9 WindowState="Maximized"
10 MinHeight="600"
11 MinWidth="800">
12
13 <Grid x:Name="LayoutRoot">
14 <Grid.RowDefinitions>
15 <RowDefinition></RowDefinition>
16 </Grid.RowDefinitions>
17 <Frame Name="frmPageContainer" Grid.Row="0"
18 NavigationUIVisibility="Hidden"
26
19 Source="Pages/pagHome.xaml"/>
20 </Grid>
21 </Window>
In questa sezione si è interessati alle caratteristiche relative alle applicazioni navigation-based,

dunque l’unico elemento da evidenziare all’interno del codice è l’elemento Frame (riga 17). Nello
specifico:
<Frame Name="frmPageContainer" Grid.Row="0" NavigationUIVisibility="Hidden"

Source="/MoseUXPrototype;component/Pages/pagHome.xaml"/>
Dove:
 Name indica il nome dell’elemento Frame;
 NavigationUIVisibility impostato su Hidden permette di nascondere la barra di
navigazione (contenente anche pulsanti Previous e Forward);
 Source indica l’URI (Uniform Resource Identifier) della pagina che si intende visualizzare
all’interno del Frame.
5.2.2 Navigazione tra le pagine
L’obbiettivo della navigazione è quello di spostarsi da una pagina all’altra. È possibile eseguire la
navigazione in 3 differenti modi:
 Invocando il metodo Navigate;

 Usando Hyperlinks;
 Usando il journal.
Nell’applicazione si sfrutta il metodo Navigate per implementare le funzione di navigazione. Tale

metodo viene ovviamente invocato all’interno del codice C#, ovvero nel code-behind dell’interfaccia
utente (all’interno del file NomeElemento.xaml.cs).
Si analizza ora un frammento di codice contenente l’uso del metodo Navigate:
this.NavigationService.Navigate(new Uri("/Pages/pagHome.xaml", UriKind.Relative));
Dove il parametro passato al metodo Navigate è di tipo Uri e dove UriKind indica se l’Uri è relativo,
assoluto o indeterminato.
L’esecuzione del metodo Navigate provocherà, all’interno del contenitore (NavigationWindow o

Frame), il caricamento della pagina contenuta all’URI indicato.
5.2.3 Passaggio di dati tra pagine
Navigando tra le pagine, può essere necessario il passaggio di dati tra le stesse. Di seguito si riporta
un frammento di codice che mostra come può essere implementato il passaggio di dati da una
pagina ad un’altra:
1 int IDTitolo = currentTitle.ID_Titolo;

2 pagPubblicationsDetail nextPage = new pagPubblicationsDetail(IDTitolo);
3 this.NavigationService.Navigate(nextPage);
27
Nel frammento di codice riportato sopra, in particolare in riga 2, è possibile notare come una
pagina venga istanziata come un qualsiasi altro oggetto. È possibile inoltre notare come l’oggetto in
questione (la pagina pagPubblicationsDetail) venga creato invocando un overload del costruttore
che accetta un parametro di tipo intero. Di seguito si riporta il costruttore (overload) relativo:
1 public pagPubblicationsDetail(int IDTitolo)

2 {
3 this.InitializeComponent();
4 //Contenuto del costruttore
5 }
5.3 Implementazione di una pagina (XAML)

XAML è adatto alla rappresentazione di interfacce utente grazie alla sua “natura gerarchica”. In WPF, le
interfacce utente sono realizzate da un albero di oggetti conosciuto come logical tree. Si sottolinea che il
logical tree esiste anche per interfacce utente che non sono realizzate in XAML. In WPF ogni aspetto
(proprietà, eventi, resources, ecc.) è fortemente legato al logical tree. Il logical tree è un albero logico che
indica gli elementi principali di un’interfaccia utente, senza esporre i dettagli “visuali”
dell’implementazione. Infatti un’espansione del logical tree è il visual tree, ovvero l’intero albero di
elementi di cui viene fatto il rendering durante il runtime dell’applicazione.
Si analizza ora, in dettaglio, una piccola porzione di pagina, al fine di illustrare come avviene
l’implementazione del layout in XAML.
Figura 5.1
Si consideri la pagina (figura 5.1) relativa alla gestione dei componenti dello staff (visualizzazione dettaglio),
denominata pagStaffDetail.
28
La parte principale del logical tree, ovvero quella relativa ai contenitori principali del layout, è riportata in
figura 5.2.
Page
Layout Root
Resources
(Grid)
Activity Pane Action Pane Navigation Pane Content Area StaBar

(Border) (Border) (Stack Panel) (Border) (Status Bar)
Figura 5.2
In figura 5.2 all’interno dei blocchi troviamo il nome dei contenitori e tra parentesi la natura (tipo) dei
contenitori stessi. In figura 5.2 si possono riconoscere due tipi di panel, ovvero quei particolari contenitori
che permettono la realizzazione del layout:
 Stack Panel: questo contenitore ordina sequenzialmente i suoi elementi figli in una pila. La pila può
avere orientamento verticale od orizzontale;
 Grid: questo contenitore è molto versatile ed è sicuramente il più utilizzato nel layout
dell’interfaccia grafica dell’applicazione. Questo contenitore permette di disporre gli elementi figli
in più righe e colonne e mette a disposizione un grosso numero di funzionalità per controllare le
righe e le colonne. Facendo un paragone, il controllo Grid funziona in modo simile alla TABLE in
HTML.
Nell’implementazione del layout sono stati utilizzati esclusivamente questi due tipi di panel.
Si analizzerà di seguito un frammento del codice XAML della pagina pagStaffDetail. Il frammento in
questione è la parte di codice contenuta all’interno del controllo Border chiamato Action Pane (vedi figura
5.2). Un controllo di tipo border non è altro che un pannello rettangolare senza alcuna funzione di layout
(come invece hanno Stack Panel e Grid) i cui bordi e sfondo possono essere personalizzati. Nel caso del
“Action Pane” il controllo border viene utilizzato rendendone visibile solamente il bordo inferiore e
applicando un effetto di ombra (da 10 a riga 13) nella sua parte inferiore.
1 <Border Name="ActionPane" Grid.Row="1" Grid.ColumnSpan="2"

2 BorderThickness="0,0,0,0.8">
3 <Border.Background>
4 <LinearGradientBrush EndPoint="0,1" StartPoint="0,0">
5 <GradientStop Color="#FFF" Offset="0.0"/>
7 <GradientStop Color="#FFEFF1F3" Offset="1.0"/>
8 </LinearGradientBrush>
9 </Border.Background>
10 <Border.Effect>
11 <DropShadowEffect Color="#FF3D3D3D" ShadowDepth="1" BlurRadius="4"
12 Opacity="0.615"/>
13 </Border.Effect>
14 <Grid>
29
16 <RowDefinition Height="64"></RowDefinition>
16 <RowDefinition Height="16"></RowDefinition>
19 <Grid.ColumnDefinitions>
20 <ColumnDefinition Width="210"></ColumnDefinition>
27 <ColumnDefinition ></ColumnDefinition>
28 </Grid.ColumnDefinitions>
29 
30 <Path Data="M301,70.331 L301,149.331" Grid.RowSpan="2"
31 Grid.Column="1" HorizontalAlignment="Center" Stretch="Fill" Width="1">
32 <Path.Stroke>
33 <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
34 <GradientStop Color="#FF858585" Offset="1"/>
35 <GradientStop Color="White"/>
36 </LinearGradientBrush>
37 </Path.Stroke>
38 </Path>
39 <TextBlock Grid.Row="1" Grid.Column="2" HorizontalAlignment="Center"
40 Foreground="#FF646464">Modifica</TextBlock>
41 
42 <StackPanel Name="ModificaStack" Grid.Row="0" Grid.Column="2"
43 VerticalAlignment="Center" HorizontalAlignment="Center"
44 Orientation="Horizontal">
45 <Button Name="btnAdd" Height="55" Width="50" Style="{DynamicResource
46 ActivityButtonStyle}" HorizontalAlignment="Center" Margin="5,0,0,0"
47 VerticalAlignment="Center" Click="btnAdd_Click" ToolTip="Aggiungi un
48 nuovo componente dello staff">
49 <Grid HorizontalAlignment="Center" Height="50" Width="50">
51 <RowDefinition Height="2*"/>
52 <RowDefinition Height="*"/>
54 <TextBlock Grid.Row="1" VerticalAlignment="Center"
55 HorizontalAlignment="Center">Aggiungi</TextBlock>
56 <Image Grid.Row="0"
57 RenderOptions.BitmapScalingMode="NearestNeighbor"
58 Source="Images/icoAddStaff.png" Stretch="None"
58 HorizontalAlignment="Center" VerticalAlignment="Center"/>
60 </Grid>
61 </Button>
62 </StackPanel>
63 
64 </Grid>
65 </Border>
Il frammento di codice riportato sopra permette di realizzare la porzione di

action panel riportata in figura 5.3.
Per quanto riguarda il codice è possibile notare:

Figura 5.3
 Da riga 14 a riga 28: definizione di una Grid. La definizione di
righe e colonne avviene all’interno di Grid.RowDefinitions e Grid.ColumnDefinitions. La
definizione di righe e colonne prevede d’indicare l’altezza per le prime e l’ampiezza per le seconde.
L’unità di misura sono i pixel (px);
30
 Da riga 42 a riga 44: definizione di uno Stack Panel. Esso è caratterizzato da:
o Essere denominato ModificaStack;
o Essere posizionato all’interno della prima riga e seconda colonna della grid “padre”;
o Orientamento orizzontale per i componenti figli.
 Da riga 45 a 48: definizione di un pulsante. In particolare:
o È denominato btnAdd;
o È associato ad uno stile denominato ActivityButtonStyle. Uno stile (style) è un insieme di
proprietà che vengono definite all’inizio del codice XAML di una pagina, nell’ambito di
page.resources. In questo caso lo stile associato al pulsante prevede variazioni dello
sfondo e dei bordi del pulsante in reazione ad eventi come il passaggio del mouse, la
pressione del tasto sinistro del mouse, ecc.;
o Il suo contenuto è personalizzato, ovvero non è il classico pulsante di colore grigio
contenente una stringa di testo. Il contenuto di questo pulsante è una griglia (riga 49) al cui
interno sono posizionati un immagine (riga 56) e una textbox (riga 54).
 Le righe 29 e 63 indicano parti di codice omesse.
Il frammento di codice riportato è una piccola parte del codice XAML costituente l’intera pagina
pagStaffDetail (65 righe di 529). In esso sono presenti alcuni tra i più importanti concetti necessari alla
realizzazione del layout dell’applicazione.
Per rendere completa la spiegazione del frammento di codice e per facilitarne la comprensione, si riporta in
figura 5.4 la parte di logical tree riferita al frammento di codice.
Action Pane
(Border)
Border
(Grid) Border Effect
Background
Column ModificaStack Drop Shadow Linear Gradient

Row Definition (Textblock)
Definition (Stack Panel) Effect Brush
btnAdd
...
(Button)
(Grid)
Column ModificaStack
Row Definition (Textblock)
Definition (Stack Panel)
Figura 5.4
31
5.4 Data binding
Il data binding è la parte fondamentale dell’implementazione. Esso si occupa infatti di stabilire una
connessione con la base di dati e di “interfacciare” lo scambio di dati tra il front-end e la base di dati stessa.
Lo operazioni che si possono effettuare sono le più comuni: inserimento, rimozione e modifica di record,
esecuzione di query e stored procedures.
5.4.1 Uso di LINQ to SQL
Un componente fondamentale, usato per il data binding in quest’applicazione, è LINQ. LINQ

(Language Integrated Query) è una serie di estensioni al linguaggio C# (e VB.NET) che permettono
di utilizzare degli operatori “alla SQL” per lavorare su diverse sorgenti dati.
L’implementazione di LINQ utilizzata è denominata LINQ to SQL Classes. LINQ to SQL permette di
utilizzare la sintassi utilizzata in SQL per la definizione di query. La query definita grazie a LINQ verrà
successivamente convertita (automaticamente) in una chiamata ADO.NET (Dove ADO sta per
ActiveX Data Object). L’ambiente di sviluppo utilizzato, ovvero Visual Studio 2010, mette a
disposizione nell’IDE un designer che permette, a partire da un database SQL Server esistente, la
mappatura delle tabelle in classi che verranno utilizzate nell’applicazione.
Creazione della connessione

Per realizzare il data binding è stata creata una connessione alla base di dati MoseDB. Il tipo di
autenticazione scelta per la connessione al SQL server è la Windows Authentication. La stringa di
connessione è stata inoltre salvata in un file app.Config.xml. Questo file è presente anche nella
directory dove risiede l’applicazione e può essere utilizzato dall’utente per la modifica della stringa
di connessione.
Creazione di un elemento LINQ to SQL Classes

Realizzata la connessione, si esegue la mappatura delle tabelle alle classi. Questo passaggio può
essere implementato aggiungendo un nuovo elemento all’applicazione: LINQ to SQL Classes (figura
5.5). Il nome che è stato associato a questo elemento è MoseDB.
Figura 5.5
32
La creazione di un elemento LINQ to SQL Classes fa in modo che all’interno del progetto
dell’applicazione vengano inseriti 3 file (figura 5.6):
 MoseDB.dbml
 MoseDB.dbml.layout
 MoseDB.designer.cs Figura 5.6
Aprendo il file MoseDB.dbml si accede al designer che permette di trascinare dalla base di dati tutti
gli elementi di cui abbiamo bisogno nella nostra applicazione. In particolare è stato eseguito il drag-
and-drop di tutte le tabelle della base di dati e delle stored procedures sp_PubbStaff e sp_PubbWeb.
La classe MoseDBDataContext
C’è da notare che, a questo punto del processo di data binding, è stata generata (automaticamente
dall’ambiente di sviluppo) una classe MoseDBDataContext, che deriva dalla classe DataContext.
Questa classe ha la funzione di “mascherare” la connessione con il database e di rendere possibili le
operazioni di aggiornamento verso il database stesso.
Ogni tabella del database sarà accessibile come proprietà pubblica di questa classe e sarà, a sua
volta, un classe di tipo Table. Riassumendo in poche parole, la classe DataContext è l’entry point
per poter utilizzare Linq To SQL.
5.4.2 Implementazione del data binding
Per descrivere le modalità d’implementazione del data binding s’illustra il caso di gestione dei dati
relativi ai corsi. In figura 5.7 è riportata l’area contenuti (content area) relativa ai corsi.
Figura 5.7
Si riporta in figura 5.8 la porzione di diagramma relazione contenente i dati in gioco in questo
esempio.
33
tblStaff tblStaffCorsi tblCorsi
PK ID_Staff PK,FK1 ID_Staff PK ID_Corso
PK,FK2 ID_Corso
Cognome NomeCorso
Nome Organizzatore EnteOrganizzatore
Attivo Periodo
Username Luogo
Amministratore Anno
PhotoFileName
PhoneNumber
OfficeLocation
Email
Summary
Eduacation
ResearchActivity
ResearchProject
Collaborations
Enabled
Figura 5.8
Nelle applicazioni WPF il data binding viene implementato in due “livelli”. Infatti il data binding
viene realizzato sia a livello d’interfaccia, e quindi di codice XAML, sia a livello di codice C#.
La parte di data binding realizzata a livello d’interfaccia serve ad associare determinati controlli alle
rispettive sorgenti di dati. Ad esempio, in figura 5.7, è possibile notare come i dati vengano associati
a controlli di tipo textbox (in alto) e controlli di tipo combobox e checkbox (in basso). Inoltre a
livello d’interfaccia viene specificata la modalità con la quale i dati vengono presentati (ad esempio
se sono in sola lettura).
5.4.3 Data binding a livello d’interfaccia utente (XAML)
Considerando l’esempio introdotto in figura 5.7, si analizzeranno ora alcuni frammenti di codice
XAML per evidenziare il data binding a livello d’interfaccia. L’esempio considerato comprende la
realizzazione di un data binding relativo ad una visualizzazione detta master-detail, ovvero
comprendente i dati relativi a un corso (master) e i componenti dello staff che vi partecipano
(detail).
1 <Page.Resources>
2 <CollectionViewSource x:Key="MasterView"/>
3 <CollectionViewSource x:Key="DetailView" Source="{Binding
4 Source={StaticResource MasterView}, Path='tblStaffCorsis'}"/>
5 <CollectionViewSource x:Key="staffLookup" />
Il frammento di codice riportato sopra indica come nelle risorse della pagina siano stati definiti tre
elementi CollectionViewSource. Un elemento CollectionViewSource è una classe derivata da
CollectionView, ovvero quella classe che rappresenta una visualizzazione per il raggruppamento,
l’ordinamento, il filtraggio e lo spostamento in un insieme di dati. Gli elementi di tipo
CollectionViewSource sono da preferire a quelli di tipo CollectionView nei casi, come in questo,
in cui si debba lavorare con diverse view (e quindi anche diverse sorgenti di dati). Dal codice si nota
che:
 Vengono definite tre CollectionViewSource, denominate (x:key per definire il nome)

MasterView, DetailView e staffLookup: MasterView gestirà i dati relativi alla tabella
34
tblCorsi (figura 5.8); DetailView gestirà i dati relativi ai componenti dello staff che
partecipano al corso visualizzato dalla MasterView; staffLookup viene utilizzata per
realizzare una lista dei componenti dello staff;
 Nelle righe 3 e 4 si nota come la DetailView venga collegata alla MasterView. Utilizzando
Source s’indica qual è la sorgente di dati, in questo caso la risorsa di tipo statico
MasterView. Path viene usato per indicare il nome del particolare elemento contenuto
all’interno della sorgente al quale ci si vuole collegare;
 In riga 4 il contenuto di Path è una tabella denominata tblStaffCorsis. La “s” finale viene
aggiunta automaticamente dall’ambiente di sviluppo. Infatti, utilizzando LINQ, le tabelle del
database vengono mappate in classi. tblStaffCorsis fa riferimento alla classe che mappa
la tabella tblStaffCorsi.
Semplificando il concetto è possibile affermare che DetailView visualizzerà i dati relativi a

tblStaffCorsis, ma l’elemento corrente da visualizzare è “deciso” dalla MasterView.
Definite le sorgenti dei dati, è possibile ora associare i controlli ai dati desiderati. Il procedimento
per implementare l’associazione è riportato nei frammenti di codice che seguono.
1 <Expander Grid.Row="0" Name="expGeneralInfo" ...

2 DataContext="{Binding Source={StaticResource MasterView}}">
Nel codice XAML riportato sopra è importante sottolineare la presenza dell’elemento DataContext.
DataContext ottiene o imposta il contesto dati per un elemento che partecipa a un’associazione
dati. Il suo significato è molto simile al concetto di Source visto in precedenza. Osservando la figura
5.7 e ricordando il concetto di logical tree, si nota come l’oggetto Expander riportato nel codice sia
“padre” di tutti i controlli textbox in esso contenuti. Dunque la proprietà di DataContext si
ripercuoterà su tutti i “figli” del controllo Expander. Basterà specificare, per ogni controllo, il
particolare percorso (Path) del dato da associare, all’interno del contesto indicato:
<TextBox Name="txtNomeCorso" Text="{Binding Path=NomeCorso}"/>
In questa riga di codice (sopra) è possibile vedere come la proprietà Text della TextBox venga
associata all’attributo NomeCorso (tabella tblCorsi, figura 5.8). Il percorso indicato (Path) è relativo al
DataContext indicato in precendenza.
5.4.4 Uso di DataGrid
All’interno del secondo Expander (“Informazioni Staff” in figura 5.8) è contenuto un controllo
particolare: il DataGrid.
Un DataGrid è un controllo versatile per la visualizzazione di più righe e colonne di dati che
possono essere editati e ordinati. Questo controllo è ottimizzato per il data binding di elementi
DataTable, ovvero tabelle, come in questo caso. Si riporta di seguito la definizione del DataGrid:
1 <DataGrid x:Name="StaffCoursesGrid" AutoGenerateColumns="False" RowHeight="30"

2 ItemsSource="{Binding Source={StaticResource DetailView}}">
3 <DataGrid.Columns>
4 <DataGridComboBoxColumn Header="Staff" ItemsSource="{Binding
5 Source={StaticResource staffLookup}}" SelectedValuePath="ID_Staff"
6 SelectedValueBinding="{Binding Path=ID_Staff}" DisplayMemberPath="Cognome"
7 Width="Auto" />
8 <DataGridCheckBoxColumn Header="Organizzatore" Binding="{Binding
9 Path=Organizzatore}"/>
35
10 </DataGrid.Columns>
11 </DataGrid>
In particolare si nota:
 In riga 1 la definizione del DataGrid, avente nome StaffCoursesGrid;

 In riga 1 la presenza della proprietà AutoGenerateColumns, di tipo boolean, impostata sul
valore False. Tale proprietà, se impostata sul valore True, permette al controllo DataGrid,
durante il runtime dell’applicazione, di generare automaticamente le colonne in base alla
sorgente del data binding;
 In riga 2 è specificata la sorgente (ItemsSource) degli elementi del DataGrid, ovvero la
risorsa statica DetailView. Il significato di ItemsSource può essere pensato come il
DataContext, precedentemente definito. Tutti gli elementi “figli” del DataGrid, ovvero le
sue colonne, faranno riferimento alla sorgente di dati indicata da ItemsSource. Dunque,
come è possibile vedere in riga 9, basterà specificare il percorso (Path) all’interno del
contesto in cui ci si trova per completare il data binding;
 Da riga 3 a riga 10 si definiscono le colonne del Datagrid. Un datagrid supporta i seguenti
tipi di colonne:
o DataGridTextColumn;
o DataGridHyperlinkColumn;
o DataGridCheckBoxColumn (riga 8);
o DataGridComboBoxColumn (riga 4);
o Altro: se si desiderassero realizzare colonne diverse da quelle supportate, è
possibile definirne di personalizzate mediante l’uso di DataGridTemplateColumn.
 In riga 4 è presente la definizione di una ComboBox utilizzata per visualizzare tutti i
componenti dello staff. Dato che la sorgente di dati che alimenta questo controllo è diversa
dal controllo “padre” (ovvero il Datagrid), mediante la proprietà ItemsSource, viene
indicata come sorgente di dati staffLookup;
 In riga 5 SelectedValuePath permette d’impostare il percorso del valore selezionato nella
ComboBox all’interno della sorgente indicata da ItemsSource. Mediante SelectedValuePath
s’indica il valore relativo alla sorgente staffLookup;
 In riga 6 SelectedValueBinding permette d’impostare il percorso del valore selezionato
nella ComboBox all’interno della sorgente indicata da ItemsSource relativa, questa volta, al
DataGrid. Mediante SelectedValueBinding s’indica il valore relativo alla sorgente
DetailView;
 In riga 6 DisplayMemberPath permette di decidere quale valore (all’interno della sorgente)
viene visualizzato nella ComboBox. La differenza tra DisplayMemberPath e
SelectedValuePath sta nel fatto che il primo è utile ai soli scopi di visualizzazione nel front-
end, mentre il secondo indica il valore che effettivamente verrà letto e modificato nel data
binding.
L’uso del controllo DataGrid permette di realizzare una funzionalità molto utile (in termini di
usabilità dell’interfaccia) che vale la pena di accennare. Tale funzionalità è detta RowDetails. Essa
infatti permette di aggiungere un “dettaglio” ad ogni riga del DataGrid. Per chiarire meglio il
concetto si faccia riferimento alla figura 5.9.
36
Figura 5.9
Come è possibile vedere dalla figura 5.9, infatti, quando viene selezionata una riga del DataGrid
avviene l’apertura di un pannello che può contenere ulteriori dati dettagliati sull’elemento corrente
(riga). Per utilizzare questa funzionalità occorre scrivere le seguenti righe di codice XAML:
1 <DataGrid x:Name="ProjectsGrid">
2 <DataGrid.Columns>
3 ...
4 </DataGrid.Columns>
5 <DataGrid.RowDetailsTemplate>
6 <DataTemplate>
7 <Grid Margin="5">
8 ...
9 </Grid>
10 </DataTemplate>
11 </DataGrid.RowDetailsTemplate>
È possibile notare in riga 6 come venga utilizzato l’elemento DataTemplate che permette di definire
al suo interno il layout (in questo caso all’interno di una Grid) dei dati che si desiderano visualizzare
in RowDetails.
L’implementazione del data binding a livello d’interfaccia (e dunque di codice XAML) è conclusa. Si
considera ora la parte di data binding a livello di codice C# (e dunque nel code-behind
dell’interfaccia).
5.4.5 Data binding a livello di codice C#
Il seguente frammento di codice contiene l’implementazione del data binding a livello di codice C#.
L’associazione e il caricamento dei dati avviene completamente all’interno del metodo Page_Loaded
(riga 13), ovvero quel metodo che viene eseguito quando viene intercettato l’evento di “pagina
caricata”.
1 public partial class pagCourses

2 {
3 ...
4 private MoseDBDataContext db = new MoseDBDataContext();
5 private IEnumerable<tblCorsi> corsiData;
6
7 private CollectionViewSource MasterViewSource;
8 private CollectionViewSource DetailViewSource;
9
10 private BindingListCollectionView MasterView;
11 private BindingListCollectionView DetailView;
12
13 private void Page_Loaded(object sender, RoutedEventArgs e)
14 {
15 this.corsiData = db.tblCorsis;
37
16 this.MasterViewSource =
17 (CollectionViewSource)this.FindResource("MasterView");
18 this.DetailViewSource =
19 (CollectionViewSource)this.FindResource("DetailView");
20
21 MasterViewSource.Source = this.corsiData;
22
23 this.MasterView =
24 (BindingListCollectionView)this.MasterViewSource.View;
25 this.DetailView =
26 (BindingListCollectionView)this.DetailViewSource.View;
27 this.MasterView.CurrentChanged += new
28 EventHandler(MasterView_CurrentChanged);
29
30 var staffList = from s in db.tblStaffs
31 select new { s.Cognome, s.ID_Staff };
32
33 CollectionViewSource staffSource =
34 (CollectionViewSource)this.FindResource("staffLookup");
35
36 staffSource.Source = staffList;
37 }
38 ...
39 }
Analizzando il codice si nota che:
 In riga 4 viene creata un’istanza dell’oggetto MoseDBDataContext;

 In riga 5 viene creato un oggetto di tipo IEnumerable, riferito all’oggetto tblCorsi.
IEnumerable è un’interfaccia che permette semplici interazioni su una collezione di dati
come se fosse un oggetto di tipo Enum;
 Nelle righe 7 e 8 vengono definiti 2 oggetti di tipo CollectionViewSource;
 Nelle righe 10 e 11 vengono definiti 2 oggetti di tipo BindingListCollectionView. Un
oggetto BindingListCollectionView rappresenta una CollectionView per collezioni di
dati che implementano l’interfaccia IBindingList;
 In riga 15 si nota come corsiData venga “popolato” dagli elementi contenuti nella tabella
tblCorsi. Noto l’uso di LINQ, tblCorsis è la classe che mappa la tabella tblCorsi;
 In riga 16 si nota come l’oggetto MasterViewSource (di tipo CollectionViewSource) venga
associato all’oggetto MasterView (di tipo CollectionViewSource) definito nel codice XAML
nell’ambito di Page.Resources;
 In riga 21 viene definita la sorgente dati di MasterViewSource;
 In riga 23 si “associa” una vista (di tipo BindingListCollectionView) a MasterViewSource
(di tipo CollectionViewSource). In questo modo, utilizzando una vista di questo tipo, si
rendono possibili la navigazione, la modifica e l’ordinamento dei record. Ciò non era
implementabile mediante oggetti di tipo CollectionViewSource;
 In riga 27 si definisce un nuovo Eventhandler per l’evento che descrive “il cambiamento
dell’elemento corrente”: quando ci si sposta tra i record, il “cambiamento dell’elemento
corrente” consiste nel passaggio da un record ad un altro. Il metodo
MasterView_CurrentChanged viene riportato di seguito:
38
1 void MasterView_CurrentChanged(object sender, EventArgs e)
2 {
3 this.DetailView =
4 (BindingListCollectionView)this.DetailViewSource.View;
5 this.txtCurrentPosition.Text = (this.MasterView.CurrentPosition + 1)
6 .ToString() + " di " + (MasterView.Count).ToString();
7 }
È possibile notare come, in riga 6, venga aggiornata la textbox (txtCurrentPosition) che

indica la posizione corrente;
 In riga 30 si nota la definizione di una query (LINQ, non SQL) necessaria per popolare la
vista staffLookup (e quindi la ComboBox contenente gli elementi dello staff).
A questo punto l’implementazione del data binding è terminata.
5.4.6 Navigazione tra record:
La navigazione tra record viene resa possibile dalle funzioni di spostamento messe a disposizione
dalle viste (BindingListCollectionView). Si riportano di seguito le righe di codice utilizzate per
implementare lo spostamento tra record (“primo record”, “record precedente”, “record
successivo”, “ultimo record”):
1 private void btnFirst_Click(object sender, RoutedEventArgs e)

2 {
3 this.MasterView.MoveCurrentToFirst();
4 }
5
6 private void btnPrevious_Click(object sender, RoutedEventArgs e)
7 {
8 if (this.MasterView.CurrentPosition > 0)
9 {
10 this.MasterView.MoveCurrentToPrevious();
11 }
12 }
13
14 private void btnNext_Click(object sender, RoutedEventArgs e)
15 {
16 if ((this.MasterView.CurrentPosition < (this.MasterView.Count - 1)))
17 {
18 this.MasterView.MoveCurrentToNext();
19 }
20 }
21
22 private void btnLast_Click(object sender, RoutedEventArgs e)
23 {
24 this.MasterView.MoveCurrentToLast();
25 }
Si nota che:
 In riga 3 viene invocato il metodo MoveCurrentToFirst() relativo alla vista MasterView.

Esso permette la visualizzazione del primo elemento della collezione di dati (e dunque il
primo elemento della tabella tblCorsi);
 In riga 10 viene invocato il metodo MoveCurrentToPrevious() relativo alla vista
MasterView. Questo metodo permette di visualizzare l’elemento che precede l’elemento
corrente all’interno della collezione di dati;
 In riga 18 viene invocato il metodo MoveCurrentToNext() relativo alla vista MasterView;
39
 In riga 24 viene invocato il metodo MoveCurrentToLast() relativo alla vista MasterView;
 Per gli spostamenti verso l’elemento precedente e quello successivo vengono effettuati dei
controlli al fine di verificare che l’elemento corrente (prima dello spostamento) non sia il
primo o l’ultimo.
5.4.7 Editing di record
Vengono riportate di seguito le righe di codice che permettono l’aggiunta e la rimozione di record
relativi ai corsi e ai componenti dello staff che partecipano al corso corrente:
1 private void btnAdd_Click(object sender, RoutedEventArgs e)

2 {
3 this.MasterView.AddNew();
4 }
5
6 private void btnRemove_Click(object sender, RoutedEventArgs e)
7 {
8 if (this.MasterView.CurrentPosition > -1)
9 {
10 tblCorsi corsi = (tblCorsi)this.MasterView.CurrentItem;
11
12 foreach (var staffCorsi in corsi.tblStaffCorsis)
13 {
14 db.tblStaffCorsis.DeleteOnSubmit(staffCorsi);
15 }
16 this.MasterView.RemoveAt(this.MasterView.CurrentPosition);
17 }
18 }
19
20 private void btnSave_Click(object sender, RoutedEventArgs e)
21 {
22 try
23 {
24 this.MasterView.CommitNew();
25
26 this.DetailView.CommitEdit();
27 db.SubmitChanges(System.Data.Linq.ConflictMode.ContinueOnConflict);
28 Status.Content = "Modifiche salvate";
29 }
30 catch (Exception ex)
31 {
32 MessageBox.Show(ex.ToString());
33 }
34 }
35
36 private void btnAddStaff_Click(object sender, RoutedEventArgs e)
37 {
38 this.DetailView.AddNew();
39 this.DetailView.CommitNew();
40 }
41
42 private void btnRemoveStaff_Click(object sender, RoutedEventArgs e)
43 {
44 if (this.DetailView.CurrentPosition > -1)
45 {
46 tblCorsi corsi = (tblCorsi)this.MasterView.CurrentItem;
47
48 tblStaffCorsi staffcorsi =
49 (tblStaffCorsi)this.DetailView.CurrentItem;
50
51 if (this.DetailView.IsAddingNew == true)
40
52 {
53 this.DetailView.CancelNew();
54 Status.Content = "Elemento Staff rimosso";
55 }
56 else
57 {
58 this.DetailView.RemoveAt(this.DetailView.CurrentPosition);
59 db.tblStaffCorsis.DeleteOnSubmit(staffcorsi);
60 Status.Content = "Elemento Staff rimosso";
61 }
62 }
63 }
Dal codice sopra riportato si nota che:
 In riga 3, invocando il metodo MasterView.AddNew() si aggiunge un nuovo elemento alla

vista MasterView;
 Da riga 10 a riga 16 avviene la rimozione dell’elemento corrente (corso). Si noti come in riga
10 venga salvato l’elemento corrente in una variabile di tipo tblCorsi;
 Da riga 12 a riga 15 si entra in un ciclo che elimina ogni elemento della classe (che mappa la
tabella tblStaffCorsi) tblStaffCorsis in relazione con il corso che si desidera rimuovere;
 In riga 16 si rimuove il corso relativo alla posizione corrente (all’interno della vista);
 Da riga 20 a riga 34 avviene il salvataggio delle modifiche apportate. Si noti come in riga 24
venga invocato il metodo MasterView.CommitNew(). Tale metodo permette di terminare
l’eventuale transazione di aggiunta di un nuovo elemento, salvando i cambiamenti
apportati. In riga 25 viene invocato il metodo MasterView.CommitEdit(). Esso si comporta
allo stesso modo del metodo CommitNew(), a differenza che considera le eventuali
transazioni di modifica;
 In riga 27 è possibile notare come vengano inviati i cambiamenti verso il database. Il
metodo SubmitChanges viene invocato indicando (come parametro) la modalità di
salvataggio dei dati. Se durante il salvataggio delle modifiche si riscontrassero alcuni errori,
grazie all’uso di ContinueOnConflict, è possibile comunque salvare tutte le modifiche che
non generano errori o conflitti;
 Le operazioni di salvataggio da riga 22 a riga 33 sono racchiuse in un blocco try-catch, che
permette l’intercettazione di eventuali eccezioni. In caso di eccezione intercettata,
l’applicazione mostra una message box (riga 32) contenente la stringa che descrive
l’eccezione;
 Da riga 36 a riga 40 avviene l’aggiunta di un nuovo elemento staff, relativo al corso
corrente;
 Da riga 42 a riga 62 avviene la rimozione dell’elemento staff desiderato.
41
CAPITOLO 6
Conclusioni
L’obiettivo di realizzare un’applicazione per la gestione delle attività del laboratorio Mose è stato raggiunto
pienamente. La quasi totalità delle funzionalità è stata realizzata completamente. Le operazioni di
debugging e l’apporto delle modifiche finali sono in fase di realizzazione.
Sono stati raggiunti i seguenti obiettivi:
 Studio delle tecnologie .NET, in particolare WPF e C#;

 Raccolta dei requisiti mediante interviste e analisi della base di dati e dell’applicazione esistenti;
 Progettazione del nuovo front-end (o interfaccia utente);
 Realizzazione dell’applicazione.
Attualmente l’applicazione è in fase di test presso un solo utente. A breve si prevede di estendere la fase di
test a tutti gli utenti che necessitano dell’applicazione. Una volta terminata la fase di test è previsto il
porting in produzione della versione finale.
Il lavoro effettuato può essere quantificato in termini di righe di codice. In particolare:
 Righe di codice XAML: 8660;

 Righe di codice C#: 3920.
42
Bibliografia
Adam Nathan - WPF 4 Unleashed - Pearson Education (US) – 2010
Joe Mayo – C# 3.0 with .NET Framework 3.5 Unleashed – Second Edition – Pearson Education (US) – 2008
Microsoft Dynamics NAV 2009 User Experience Guidelines
Microsoft Windows 7 User Experience Guidelines
http://msdn.microsoft.com/it-it/vcsharp/cc707833(en-us).aspx
http://msdn.microsoft.com/it-it/vcsharp/dd239277(en-us).aspx
http://msdn.microsoft.com/library/ms752347(VS.85).aspx
http://msdn.microsoft.com/it-it/library/aa970683(VS.85).aspx
http://blogs.msdn.com/b/pietrobr/archive/2007/09/07/parliamo-di-linq-parte-3.aspx
43

Tesi Matteo Miotto

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tesi Matteo Miotto

Caricato da

Copyright:

Formati disponibili

UNIVERSITÀ DEGLI STUDI DI TRIESTE

Progettazione e sviluppo di una applicazione per la

Anno accademico 2009 - 2010

Gli obiettivi del lavoro svolto sono stati:

 Studio delle tecnologie .NET, in particolare WPF e C#;

2.1 Analisi base di dati esistente

La base di dati esistente viene utilizzata da:

Cognome FK1 ID_Tipo DettaglioIT

tblStaff tblStaffCorsi tblCorsi

Si riportano di seguito le stored procedures utilizzate dall’applicazione esistente:

 sp_PubbStaff: utilizzata per visualizzare le pubblicazioni relative a un componente dello staff. La

2.3.1 Gestione staff

Si desiderano visualizzare i seguenti dati:

Si desiderano effettuare le seguenti operazioni sui dati:

2.3.2 Gestione pubblicazioni

I dati che si desiderano memorizzare e gestire sono:

 Dati relativi alle pubblicazioni:

Le operazioni che si desiderano effettuare su tali dati sono:

 Aggiunta, modifica e rimozione di pubblicazioni, tipi di pubblicazione, stati delle

2.3.3 Esportazione pubblicazioni

2.3.4 Upload documenti

1. Scelta di una pubblicazione da una lista;

2.3.5 Gestione congressi

I dati relativi ai congressi che si desiderano memorizzare e gestire sono:

Le operazioni che si desiderano effettuare su tali dati sono:

 Aggiunta, modifica, rimozione di un congresso;

2.3.6 Gestione progetti

I dati relativi ai progetti che si desiderano memorizzare e gestire sono:

Le operazioni che si desiderano effettuare su tali dati sono:

 Aggiunta, modifica, rimozione di un progetto;

2.3.7 Gestione tesi

I dati che si desiderano memorizzare e gestire sono:

 Dati relativi alle tesi:

Le operazioni che si desiderano effettuare su tali dati sono:

 Aggiunta, modifica, rimozione di tesi, curriculum, tipo tesi e stato tesi;

2.3.8 Gestione corsi

I dati che si desiderano memorizzare e gestire sono:

Le operazioni che si desiderano effettuare su tali dati sono:

 Aggiunta, modifica, rimozione di un corso;

 Report “area chimica”: visualizza le tesi relative ai curriculum dell’area chimica,

2.3.10 Ulteriori requisiti

Un’ulteriore requisito espresso dal committente riguarda l’integrazione dell’applicazione in

3.1 Principi generali di progettazione (User Experience & User Interface)

 Applicazione integrata in un’unica finestra;

3.2 Processo di progettazione

Il raggruppamento ha portato alla definizione di attività principali e secondarie. Nella progettazione

Una volta identificate le attività principali, per ognuna di esse s’individuano:

 I dati che l’attività necessita gestire:

3.3 Layout interfaccia utente

1. Activity Pane: è il pannello che contiene le attività principali. Corrisponde al raggruppamento

4.1 Installazione e configurazione

 Stringa di connessione alla base di dati;

La configurazione della stringa di connessione può essere effettuata in 2 modi:

PRINCIPALI PUBBLICAZIONI STAFF CONGRESSI PROGETTI TESI CORSI

Staff Pubblicazioni Staff Pubblicazioni Staff Staff

4.2.1 Avvio dell’applicazione

4.2.2 Esempio d’uso

Facendo riferimento alla figura 4.2:

1. Nel pannello delle azioni principali (action pane,

Un’ultima funzionalità da sottolineare è la

5.1 WPF e XAML

Le principali caratteristiche di WPF possono essere incluse tra le seguenti:

XAML è, in generale, un linguaggio di programmazione dichiarativo adatto alla costruzione e inizializzazione

5.2 Navigation-Based Windows Applications