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: Chiar.mo Prof. Maurizio Fermeglia

Laureando: Matteo Miotto

Anno accademico 2009 - 2010

1

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

2

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

3

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;

4

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

5

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.

6

tblStaff

PK ID_Staff

Cognome Nome Attivo Username Amministratore PhotoFileName PhoneNumber OfficeLocation Email Summary Eduacation ResearchActivity ResearchProject Collaborations Enabled

tblStaffTitoli

PK,FK1 ID_StaffPK,FK2 ID_Titolo

tblTipoPubbl

PK ID_TipoPubb

TipoPubblicazione TipoPubEnglish Class_TS Class_PD

tblStatoTitolo

PK ID_Stato

Stato Statoen

tblRiviste

PK ID_rivista

Denominazione RivistaInternazionale Referee LuogoPubblicazione

tblCollegamentoKeywordsTitolo

PK,FK1 ID_KeywordPK,FK2 ID_Titolo

tblKeyword

PK ID_Keyword

Keyword

tblTitoloProgetto

PK,FK1 ID_TitoloPK,FK2 ID_Progetto

tblProgetti

PK,FK1 ID_Progetto

Progetto SiglaProgetto Anno_Inizio Anno_Fine Finanziatore ResponsabileLocale ResponsabileGlobale FinanziamentoLocale FianziamentoGlobale VisualizzaSito TipoProgetto ImgProject Summary Link

tblCongressi

PK ID_Congresso

Denominazione Data Anno CongressoInternazionale Referee

tblStaffCongressi

PK,FK1 ID_StaffPK,FK2 ID_Congresso

Presentazione Organizzazione Partecipazione

tblTitoli

PK ID_Titolo

Autori RiferimentoFK2 ID_StatoFK3 ID_Rivista Anno TitoloFK1 ID_tipoPubb ID_SitoWeb ImpactFactor ID_Settore

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.

7

tblStaff

PK ID_Staff


tblTesi

PK ID_Tesi

FK1 ID_Tipo ArgomentoIT ArgomentoEN Collaborazione CorrelatoriFK2 ID_CurriculumFK3 StatoFK4 ID_Relatore Autore DataInizioTesi MeseLaurea AnnoLaurea Voto

tblTipiTesi

PK ID_Tipo

Tipo

tblCurriculum

PK ID_Curriculum

Curriculum CurriculumEN

tblTesiStato

PK ID_Stato

StatoTesi

tblTesiDettaglio

PK,FK1 ID_Tesi

DettaglioIT DettaglioEN

Figura 2.2

La porzione dello schema relazionale riportata in Figura 2.2 si sviluppa attorno alla tabella tblTesi,

rappresentante le tesi.

tblStaffCorsi

PK,FK1 ID_StaffPK,FK2 ID_Corso

Organizzatore

tblCorsi

PK ID_Corso

NomeCorso EnteOrganizzatore Periodo Luogo Anno

tblStaff

PK ID_Staff


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.

8

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.

9

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:

10

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;

11

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;

12

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;

13

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.

14

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.

15

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:

16

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

17

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

18

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.

19

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

SECONDARIE

Keywords Riviste Tipi Pubb. Stati Pubb.

Curriculum Tipi Tesi Stati Tesi

CORRELATE

Staff Progetti Congressi

Pubblicazioni Congressi Progetti Tesi Corsi

Staff Pubblicazioni Staff

Staff Staff

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.

20

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

Figura 4.1

21

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

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

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.

Figura 4.2

Figura 4.3

Figura 4.4

22


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

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

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

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;

Figura 4.5

Figura 4.6

Figura 4.7

23

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

Figura 4.9

24

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

Figura 4.11

25

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

26

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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" x:Class="MoseUXPrototype.MainWindow" x:Name="Window" Title="Gestione Attività Mose" Width="800" Height="600" Background="#FFE0E4E7" WindowStartupLocation="CenterScreen" WindowState="Maximized" MinHeight="600" MinWidth="800"> <Grid x:Name="LayoutRoot"> <Grid.RowDefinitions> <RowDefinition></RowDefinition> </Grid.RowDefinitions> <Frame Name="frmPageContainer" Grid.Row="0" NavigationUIVisibility="Hidden"

27

19 20 21

Source="Pages/pagHome.xaml"/> </Grid> </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 2 3

int IDTitolo = currentTitle.ID_Titolo; pagPubblicationsDetail nextPage = new pagPubblicationsDetail(IDTitolo); this.NavigationService.Navigate(nextPage);

28

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 2 3 4 5

public pagPubblicationsDetail(int IDTitolo) { this.InitializeComponent(); //Contenuto del costruttore }

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.

Si consideri la pagina (figura 5.1) relativa alla gestione dei componenti dello staff (visualizzazione dettaglio),

denominata pagStaffDetail.

Figura 5.1

29

La parte principale del logical tree, ovvero quella relativa ai contenitori principali del layout, è riportata in

figura 5.2.

Page

Layout Root(Grid)

Resources

Navigation Pane(Stack Panel)

Content Area(Border)

Activity Pane(Border)

Action Pane(Border)

StaBar(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 2 3 4 5 7 8 9 10 11 12 13 14

<Border Name="ActionPane" Grid.Row="1" Grid.ColumnSpan="2" BorderThickness="0,0,0,0.8"> <Border.Background> <LinearGradientBrush EndPoint="0,1" StartPoint="0,0"> <GradientStop Color="#FFF" Offset="0.0"/> <GradientStop Color="#FFEFF1F3" Offset="1.0"/> </LinearGradientBrush> </Border.Background> <Border.Effect> <DropShadowEffect Color="#FF3D3D3D" ShadowDepth="1" BlurRadius="4" Opacity="0.615"/> </Border.Effect> <Grid>

30

Figura 5.3

15 16 16 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 58 60 61 62 63 64 65

<Grid.RowDefinitions> <RowDefinition Height="64"></RowDefinition> <RowDefinition Height="16"></RowDefinition> </Grid.RowDefinitions> <Grid.ColumnDefinitions> <ColumnDefinition Width="210"></ColumnDefinition> <ColumnDefinition Width="3"></ColumnDefinition> <ColumnDefinition Width="180"></ColumnDefinition> <ColumnDefinition Width="3"></ColumnDefinition> <ColumnDefinition Width="130"></ColumnDefinition> <ColumnDefinition Width="3"></ColumnDefinition> <ColumnDefinition Width="200"></ColumnDefinition> <ColumnDefinition ></ColumnDefinition> </Grid.ColumnDefinitions>  <Path Data="M301,70.331 L301,149.331" Grid.RowSpan="2" Grid.Column="1" HorizontalAlignment="Center" Stretch="Fill" Width="1"> <Path.Stroke> <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0"> <GradientStop Color="#FF858585" Offset="1"/> <GradientStop Color="White"/> </LinearGradientBrush> </Path.Stroke> </Path> <TextBlock Grid.Row="1" Grid.Column="2" HorizontalAlignment="Center" Foreground="#FF646464">Modifica</TextBlock>  <StackPanel Name="ModificaStack" Grid.Row="0" Grid.Column="2" VerticalAlignment="Center" HorizontalAlignment="Center" Orientation="Horizontal"> <Button Name="btnAdd" Height="55" Width="50" Style="{DynamicResource ActivityButtonStyle}" HorizontalAlignment="Center" Margin="5,0,0,0" VerticalAlignment="Center" Click="btnAdd_Click" ToolTip="Aggiungi un nuovo componente dello staff"> <Grid HorizontalAlignment="Center" Height="50" Width="50"> <Grid.RowDefinitions> <RowDefinition Height="2*"/> <RowDefinition Height="*"/> </Grid.RowDefinitions> <TextBlock Grid.Row="1" VerticalAlignment="Center" HorizontalAlignment="Center">Aggiungi</TextBlock> <Image Grid.Row="0" RenderOptions.BitmapScalingMode="NearestNeighbor" Source="Images/icoAddStaff.png" Stretch="None" HorizontalAlignment="Center" VerticalAlignment="Center"/> </Grid> </Button> </StackPanel>  </Grid> </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:

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);

31

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 EffectBorder

Background

ModificaStack(Stack Panel)

(Textblock)Column

DefinitionRow Definition

(Grid)

Linear Gradient Brush

Drop Shadow Effect

btnAdd(Button)

...

(Grid)

ModificaStack(Stack Panel)

(Textblock)Column

DefinitionRow Definition

Figura 5.4

32

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

33

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

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.

Si riporta in figura 5.8 la porzione di diagramma relazione contenente i dati in gioco in questo

esempio.

Figura 5.7

Figura 5.6

34

tblStaffCorsi

PK,FK1 ID_StaffPK,FK2 ID_Corso

Organizzatore

tblCorsi

PK ID_Corso

NomeCorso EnteOrganizzatore Periodo Luogo Anno

tblStaff

PK ID_Staff


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 2 3 4 5

<Page.Resources> <CollectionViewSource x:Key="MasterView"/> <CollectionViewSource x:Key="DetailView" Source="{Binding Source={StaticResource MasterView}, Path='tblStaffCorsis'}"/> <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

35

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 2

<Expander Grid.Row="0" Name="expGeneralInfo" ... 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 2 3 4 5 6 7 8 9

<DataGrid x:Name="StaffCoursesGrid" AutoGenerateColumns="False" RowHeight="30" ItemsSource="{Binding Source={StaticResource DetailView}}"> <DataGrid.Columns> <DataGridComboBoxColumn Header="Staff" ItemsSource="{Binding Source={StaticResource staffLookup}}" SelectedValuePath="ID_Staff" SelectedValueBinding="{Binding Path=ID_Staff}" DisplayMemberPath="Cognome" Width="Auto" /> <DataGridCheckBoxColumn Header="Organizzatore" Binding="{Binding Path=Organizzatore}"/>

36

10 11

</DataGrid.Columns> </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.

37

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 2 3 4 5 6 7 8 9 10 11

<DataGrid x:Name="ProjectsGrid"> <DataGrid.Columns> ... </DataGrid.Columns> <DataGrid.RowDetailsTemplate> <DataTemplate> <Grid Margin="5"> ... </Grid> </DataTemplate> </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 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public partial class pagCourses { ...

private MoseDBDataContext db = new MoseDBDataContext(); private IEnumerable<tblCorsi> corsiData; private CollectionViewSource MasterViewSource; private CollectionViewSource DetailViewSource; private BindingListCollectionView MasterView; private BindingListCollectionView DetailView; private void Page_Loaded(object sender, RoutedEventArgs e) { this.corsiData = db.tblCorsis;

Figura 5.9

38

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

this.MasterViewSource = (CollectionViewSource)this.FindResource("MasterView"); this.DetailViewSource = (CollectionViewSource)this.FindResource("DetailView"); MasterViewSource.Source = this.corsiData;

this.MasterView = (BindingListCollectionView)this.MasterViewSource.View;

this.DetailView = (BindingListCollectionView)this.DetailViewSource.View; this.MasterView.CurrentChanged += new EventHandler(MasterView_CurrentChanged); var staffList = from s in db.tblStaffs select new { s.Cognome, s.ID_Staff }; CollectionViewSource staffSource = (CollectionViewSource)this.FindResource("staffLookup"); staffSource.Source = staffList; } ... }

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:

39

1 2 3 4 5 6 7

void MasterView_CurrentChanged(object sender, EventArgs e) { this.DetailView = (BindingListCollectionView)this.DetailViewSource.View; this.txtCurrentPosition.Text = (this.MasterView.CurrentPosition + 1) .ToString() + " di " + (MasterView.Count).ToString(); }

È 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

private void btnFirst_Click(object sender, RoutedEventArgs e) { this.MasterView.MoveCurrentToFirst(); } private void btnPrevious_Click(object sender, RoutedEventArgs e) { if (this.MasterView.CurrentPosition > 0) { this.MasterView.MoveCurrentToPrevious(); } } private void btnNext_Click(object sender, RoutedEventArgs e) { if ((this.MasterView.CurrentPosition < (this.MasterView.Count - 1))) { this.MasterView.MoveCurrentToNext(); } } private void btnLast_Click(object sender, RoutedEventArgs e) { this.MasterView.MoveCurrentToLast(); }

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;

40

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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

private void btnAdd_Click(object sender, RoutedEventArgs e) { this.MasterView.AddNew(); } private void btnRemove_Click(object sender, RoutedEventArgs e) { if (this.MasterView.CurrentPosition > -1) { tblCorsi corsi = (tblCorsi)this.MasterView.CurrentItem; foreach (var staffCorsi in corsi.tblStaffCorsis) { db.tblStaffCorsis.DeleteOnSubmit(staffCorsi); } this.MasterView.RemoveAt(this.MasterView.CurrentPosition); } } private void btnSave_Click(object sender, RoutedEventArgs e) { try { this.MasterView.CommitNew(); this.DetailView.CommitEdit(); db.SubmitChanges(System.Data.Linq.ConflictMode.ContinueOnConflict); Status.Content = "Modifiche salvate"; } catch (Exception ex) { MessageBox.Show(ex.ToString()); } } private void btnAddStaff_Click(object sender, RoutedEventArgs e) { this.DetailView.AddNew(); this.DetailView.CommitNew(); } private void btnRemoveStaff_Click(object sender, RoutedEventArgs e) { if (this.DetailView.CurrentPosition > -1) { tblCorsi corsi = (tblCorsi)this.MasterView.CurrentItem; tblStaffCorsi staffcorsi = (tblStaffCorsi)this.DetailView.CurrentItem; if (this.DetailView.IsAddingNew == true)

41

52 53 54 55 56 57 58 59 60 61 62 63

{ this.DetailView.CancelNew(); Status.Content = "Elemento Staff rimosso"; } else { this.DetailView.RemoveAt(this.DetailView.CurrentPosition); db.tblStaffCorsis.DeleteOnSubmit(staffcorsi); Status.Content = "Elemento Staff rimosso"; } } }

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.

42

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.

43

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




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

Tesi Matteo Miotto

Documents

Transcript of Tesi Matteo Miotto