Il documento presenta una tesi di laurea sul progetto e-val, che si concentra sulle procedure di autovalutazione e valutazione dell'apprendimento in tecnologia web. Viene descritta in dettaglio l'architettura del sistema, comprese le tecnologie lato server e lato client, e viene fornita un'analisi della progettazione dell'applicazione e del database. Il documento include anche manuali per amministratori e docenti, evidenziando i requisiti di sistema e le procedure di installazione.

1. U n i v e r s i t `a d e g l i S t u d i d i P a d o v a
D i p a r t i m e n t o d i E l e t t r o n i c a e I n f o r m a t i c a
Tesi di laurea
e-Val
Procedure per l’autovalutazione e la valutazione
dell’apprendimento in tecnologia web
Relatore: Ch.mo prof. Matteo Bertocco
Laureando: Simone Vergolani

3. Indice
I Tecnologie utilizzate 3
1 Tecnologie lato server 5
1.1 Il linguaggio di programmazione: Java . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Il Database Management System: MySQL . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Structured Query Language (SQL) . . . . . . . . . . . . . . . . . . . . 8
1.2.2 Il pool di connessioni: DbConnectionBroker . . . . . . . . . . . . . . . 8
1.3 Il server Web: Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Servlet e JavaServer PagesTM . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2 Taglibs: una libreria di tag personalizzati . . . . . . . . . . . . . . . . 16
1.4 I JavaBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Tecnologie lato client 17
2.1 Formati e linguaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1 HyperText Markup Language (HTML) . . . . . . . . . . . . . . . . . . 17
2.1.2 Cascading Style Sheets (CSS) . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.3 Il linguaggio di scripting: JavaScript . . . . . . . . . . . . . . . . . . . 20
2.2 I browser Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Swing Java applet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Tecnologie di comunicazione 25
3.1 L’Hypertext Transfer Protocol (HTTP) . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Comunicazione applet–server: com.oreilly.servlet.HttpMessage . 26
3.2 La connessione al database: JDBC . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 2 Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2 3 Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
II Progetto e-Val 29
4 Piano di progetto 31
4.1 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4. ii INDICE
4.2 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Criticit`a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5 Progettazione della base di dati 37
5.1 Progettazione concettuale: lo schema Entit`a–Relazione . . . . . . . . . . . . . 38
5.2 Schema logico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.1 Ristrutturazione dello schema ER . . . . . . . . . . . . . . . . . . . . 45
5.2.2 Verifica delle forme normali . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 Schema fisico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.1 Utenti e sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.2 Accorgimenti per incrementare le prestazioni . . . . . . . . . . . . . . 56
6 Progettazione dell’applicazione server 57
6.1 Il design pattern Model–View–Controller . . . . . . . . . . . . . . . . . . . . . 58
6.2 Controller: i Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2.1 Il docente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2.2 Lo studente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2.3 Il reperimento degli allegati . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3 Model: i JavaBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.3.1 Correzione dei compiti . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.3.2 Assegnazione dei compiti agli studenti . . . . . . . . . . . . . . . . . . 74
6.3.3 Calcolo della difficolt`a dei quesiti . . . . . . . . . . . . . . . . . . . . . 75
6.4 View: le JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.4.1 Struttura di una JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5 Schema fisico dell’applicazione . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7 Progettazione dei client 81
7.1 Il client del docente: e–Val Question Manager . . . . . . . . . . . . . . . . . . 82
7.1.1 Il parser dei file HTML . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2 I browsers Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.2.1 I fogli di stile: CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.2.2 Il linguaggio di scripting client–side: JavaScript . . . . . . . . . . . . . 86
7.3 Il client dello studente: e–Val Student . . . . . . . . . . . . . . . . . . . . . . . 87
8 Organizzazione del codice 89
8.1 Package eVal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
8.2 Package eValStudent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.3 Package eValTeacher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.4 Package eValServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.5 Alcune estensioni di esempio . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5. INDICE iii
III Manuali e-Val 99
9 Manuale dell’amministratore 103
9.1 Requisiti di sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
9.2 Installazione dell’applicazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.2.1 Creazione del database . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.2.2 Il file eVal.war . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.2.3 Le applicazioni Java Swing e–Val Question Manager e e–Val Student . 105
9.2.4 Gli utenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.3 I files di configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
9.3.1 Il file web.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
9.3.2 TeacherConfiguration.xml . . . . . . . . . . . . . . . . . . . . . . . 109
9.3.3 StudentConfiguration.xml . . . . . . . . . . . . . . . . . . . . . . . 109
9.4 I files di log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.5 I servizi di amministrazione accessibili dal Web . . . . . . . . . . . . . . . . . 110
9.5.1 Cancellazione di un corso [Administration] . . . . . . . . . . . . . . . . 111
9.5.2 Creazione di un nuovo corso [NewCourse] . . . . . . . . . . . . . . . . 112
9.6 Incrementare le prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
10 Manuale del docente 113
10.1 Accesso dal Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
10.1.1 Pagina di benvenuto [Welcome] . . . . . . . . . . . . . . . . . . . . . . 114
10.1.2 Testata principale [Header] . . . . . . . . . . . . . . . . . . . . . . . . 115
10.1.3 Menu principale [Menu] . . . . . . . . . . . . . . . . . . . . . . . . . . 115
10.1.4 Modifica dei dati del corso [ModifyCourse] . . . . . . . . . . . . . . . . 116
10.1.5 Creazione di un nuovo esame [NewExam] . . . . . . . . . . . . . . . . 116
10.1.6 Modifica di un esame ancora da sostenere [ModifyExam] . . . . . . . . 117
10.1.7 Stampa della tabella d’esame [PrintExamStudentList] . . . . . . . . . 119
10.1.8 Esame svolto o in corso di svolgimento [ShowExamDone] . . . . . . . 119
10.1.9 Stampa della lista dei risultati [PrintExamResult] . . . . . . . . . . . 121
10.1.10Compito svolto o in corso di svolgimento dello studente [ShowExam-
Student] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
10.1.11Compito assegnato ad uno studente [PrintStudentTest] . . . . . . . . . 123
10.1.12Visualizzazione di un quesito [ShowQuestion] . . . . . . . . . . . . . . 124
10.1.13Rapporto su un compito svolto [ShowTestUsed] . . . . . . . . . . . . . 125
10.1.14Compito assegnato per un appello d’esame [PrintTest] . . . . . . . . . 125
10.1.15Modifica di un quesito [ModifyQuestion] . . . . . . . . . . . . . . . . . 125
10.1.16Modifica di un argomento [ModifyArgument] . . . . . . . . . . . . . . 126
10.1.17Stampa di un argomento [PrintArgument] . . . . . . . . . . . . . . . . 127
10.1.18Creazione di un nuovo argomento [NewArgument] . . . . . . . . . . . 128
10.1.19Visualizzazione di un compito gi`a assegnato [ShowTest] . . . . . . . . 128
10.1.20Modifica di un compito non ancora assegnato [ModifyTest] . . . . . . 129
10.1.21Creazione di un nuovo compito [NewTest] . . . . . . . . . . . . . . . . 129

6. iv INDICE
10.2 Inserimento dei quesiti: e–Val Question Manager . . . . . . . . . . . . . . . . . 130
10.2.1 Il parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
10.2.2 Tipologie di quesiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
10.2.3 Tag HTML speciali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
10.2.4 I comandi della finestra . . . . . . . . . . . . . . . . . . . . . . . . . . 133
10.2.5 L’editor HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
10.2.6 Procedura per l’inserimento di un quesito . . . . . . . . . . . . . . . . 135
10.3 Schema logico di utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
10.3.1 Correzione dei compiti e stampa dei risultati . . . . . . . . . . . . . . 139
11 Manuale dello studente 141
11.1 Svolgimento dell’esame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
IV Appendici 145
A Il CD–ROM allegato 147
B Colofone 149
Bibliografia 151

7. Elenco delle figure
1.1 Tipologie di servlet container . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 Flusso dei messaggi in un server Web . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 2 Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 3 Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Rappresentazione schematica del sistema . . . . . . . . . . . . . . . . . . . . . 32
4.2 Work Breakdown Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1 Schema Entit`a–Relazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Schema concettuale ristrutturato . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3 Schema logico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4 Schema fisico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.1 Schema completo dell’architettura MVC . . . . . . . . . . . . . . . . . . . . . 61
6.2 Interazioni tra i moduli del server Web . . . . . . . . . . . . . . . . . . . . . . 63
6.3 Controller per il docente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.4 Controller per lo studente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.5 Controllo dell’accesso dello studente . . . . . . . . . . . . . . . . . . . . . . . 68
6.6 Costruzione di una pagina HTML . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.7 Componenti del sistema fisico . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.1 Interazioni tra i moduli del parser HTML . . . . . . . . . . . . . . . . . . . . 85
8.1 Package eVal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
8.2 Package eValStudent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.3 Package eValTeacher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.4 Package eValServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.1 Schema dei vari componenti fisici . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.2 Cancellazione di un corso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
9.3 Creazione di un nuovo corso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

8. vi ELENCO DELLE FIGURE
10.1 Pagina di benvenuto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
10.2 Testata principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
10.3 Menu principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
10.4 Modifica dei dati del corso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
10.5 Creazione di un nuovo esame . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
10.6 Modifica di un esame ancora da sostenere . . . . . . . . . . . . . . . . . . . . 118
10.7 Stampa della tabella d’esame . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
10.8 Esame svolto o in corso di svolgimento . . . . . . . . . . . . . . . . . . . . . . 120
10.9 Stampa della lista dei risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
10.10Compito svolto o in corso di svolgimento dello studente . . . . . . . . . . . . 122
10.11Compito assegnato ad uno studente . . . . . . . . . . . . . . . . . . . . . . . 123
10.12Visualizzazione di un quesito . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
10.13Rapporto su un compito svolto . . . . . . . . . . . . . . . . . . . . . . . . . . 124
10.14Compito assegnato per un appello d’esame . . . . . . . . . . . . . . . . . . . . 125
10.15Modifica di un quesito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
10.16Modifica di un argomento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
10.17Stampa di un argomento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
10.18Creazione di un nuovo argomento . . . . . . . . . . . . . . . . . . . . . . . . . 128
10.19Visualizzazione di un compito gi`a assegnato . . . . . . . . . . . . . . . . . . . 128
10.20Modifica di un compito non ancora assegnato . . . . . . . . . . . . . . . . . . 129
10.21Creazione di un nuovo compito . . . . . . . . . . . . . . . . . . . . . . . . . . 130
10.22eValQuestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
10.23Visualizzazione di un quesito in e–Val Question Manager . . . . . . . . . . . . 134
10.24Editor del sorgente HTML di un quesito . . . . . . . . . . . . . . . . . . . . . 136
10.25Diagramma per la preparazione di un’esame . . . . . . . . . . . . . . . . . . . 138
10.26Diagramma per la correzione di un’esame . . . . . . . . . . . . . . . . . . . . 139
11.1 Pagina di benvenuto di e–Val Student . . . . . . . . . . . . . . . . . . . . . . . 141
11.2 Quesito presentato allo studente . . . . . . . . . . . . . . . . . . . . . . . . . 143

9. Introduzione
Questa tesi nasce dall’esigenza di automatizzare, per quanto possibile, il processo di esecuzione
e correzione degli esami universitari e pi`u in generale di eseguire test per valutare il livello di
apprendimento raggiunto dagli studenti che seguono un corso.
Ha comportato la progettazione e lo sviluppo di un’applicazione basata su tecnologia Web
consentendo di distribuire i servizi all’interno di una rete locale; `e inoltre in grado di soddisfare
contemporaneamente pi`u studenti e pi`u docenti (ambiente multi–authoring). La persisten-
za dei dati `e stata realizzata ricorrendo a un DBMS, che ha comportato la progettazione
preliminare di un database.
Complessivamente sono state realizzate 27 classi Java raggruppate in 4 packages, 43 pagine
JSP dinamiche, 4 fogli di stile CSS e alcune procedure JavaScript per un totale di circa 10’000
righe di codice.
Documentazione `E formata da tre parti pi`u alcune appendici: nella prima parte si de-
scrivono le varie tecnologie che sono state utilizzate per la realizzazione dell’applicazione
(quelle di maggior interesse ai fini del progetto vengono trattate pi`u a fondo); nella seconda
viene introdotto il problema e di seguito illustrate le fasi progettuali che hanno portato alla
realizzazione delle varie procedure; la terza parte contiene, invece, i manuali dell’applicazione
divisi per le tre categorie di utenti: l’amministratore, il docente e lo studente.
Le appendici trattano del contenuto del CD–ROM allegato e degli strumenti utilizzati per
realizzare questa documentazione. La bibliografia divisa per argomenti chiude la tesi.

10. 2 ELENCO DELLE FIGURE

11. Parte I
Tecnologie utilizzate

13. Capitolo 1
Tecnologie lato server
Questo capitolo presenta le tecnologie che sono state utilizzate per la realizzazione del progetto
e-Val: alcune sono state scelte a priori come vincoli, altre invece sono state adottate perch´e pi`u
adatte a svolgere quel particolare compito; vengono ora descritte brevemente, soffermandosi
soprattutto sugli aspetti pi`u interessanti ai fini progettuali. Ogni sezione inizia con una piccola
introduzione storica e qualche curiosit`a.
L’applicazione `e di tipo client–server quindi impiega strumenti, tecnologie, standards e
linguaggi che si riferiscono al servente, ai vari clients e ai canali di comunicazione.
1.1 Il linguaggio di programmazione: Java
y Java fu concepito da James Gosling, Patrick Naughton, Chris Warth, Ed Frank e Mike Sheridan
in Sun Microsystems Inc. nel 1991 e richiese 18 mesi per sviluppare la prima versione funzionante.
Inizialmente il linguaggio fu battezzato “OAK” ma venne rinominato “Java” nel 1995. Tra la
versione iniziale di Oak nell’autunno 1992 e l’annuncio al pubblico di Java nella primavera del
1995, molte altre persone avevano contribuito al progetto e all’evoluzione del linguaggio. Bill
Joy, Arthur van Hoff, Jonathan Payne, Frank Yellin e Tim Lindholm diedero un contributo
importantissimo per la maturazione del prototipo originale. La spinta iniziale per Java non
venne da Internet, bens`ı dal bisogno di un linguaggio indipendente dalla piattaforma, cio`e neutro
rispetto all’architettura, che avrebbe potuto essere impiegato per creare software da incorporare
in diversi dispositivi elettronici commerciali come forni a microonde e telecomandi. y
Java `e un linguaggio di programmazione general–purpose, concorrente, basato su classi e
orientato agli oggetti; deriva dal C e dal C++ ma `e organizzato in modo differente, con molti
aspetti omessi e nuove idee prese da altri linguaggi. Ecco i punti di forza di questo linguaggio:
• semplice: `e stato concepito per essere semplice da apprendere, efficace da usare e
rivolto ai programmatori professionisti; pur dovendo molto a C++, Java risulta essere
molto pi`u semplice e tollerante grazie anche alla mancanza di puntatori;
• orientato agli oggetti: implementa questo paradigma in modo esteso con l’eccezione,
per ragioni di efficienza, dei tipi semplici di dati;

14. 6 Tecnologie lato server
• robusto: `e fortemente tipizzato quindi controlla il codice gi`a durante la compilazione;
inoltre non c’`e la necessit`a di dover liberare la memoria quando si `e terminato di usare
un oggetto perch´e questo compito `e demandato al garbage collector; anche la gestione
delle eccezioni `e orientata agli oggetti;
• multiprocesso: il sistema run–time di Java fornisce una soluzione elegante, anche
se sofisticata, per la sincronizzazione di multiprocessi che mette in grado di costruire
sistemi interattivi funzionanti e affidabili;
• indipendente dall’architettura: l’obiettivo dei progettisti era “scrivi una volta per
tutte, esegui ovunque, in ogni momento, per sempre” e per gran parte `e stato raggiunto;
• interpretato ad alte prestazioni: Java consente la creazione di programmi mul-
tipiattaforma attraverso la compilazione in una forma intermedia chiamata bytecode;
questo codice `e stato pensato per ottenere alte prestazioni e pu`o essere interpretato su
ogni sistema che disponga di una Java Virtual Machine;
• grande supporto: Java dispone di varie API (Application Program Interface) per
quasi ogni ambito, molto utili per lo sviluppo di applicazioni.
Lo scotto maggiore per questa serie di vantaggi lo si paga sul lato delle prestazioni visto che,
a differenza dei linguaggi compilati, Java viene interpretato al momento dell’esecuzione.
g JavaTM Software: java.sun.com
1.2 Il Database Management System: MySQL
y Nel 1979 Michael (Monty) Widenius, programmatore della compagnia svedese TcX, sviluppa
uno strumento per la gestione di database che prende il nome di UNIREG. Nel 1994 la TcX inizia a
realizzare applicazioni per il Web utilizzando UNIREG, ma ci si accorge che per riuscire a generare
dinamicamente le pagine Web, c’`e bisogno di troppe risorse; allora prende in considerazione altri
prodotti quali mSQL: Widenius decide di connettere UNIREG a mSQL utilizzando delle veloci
routine a basso livello (ISAM). Dopo alcuni test si arriva alla conclusione che il sistema non `e n`e
abbastanza veloce n`e tanto flessibile anche perch´e nella versione 1.x mSQL non supporta nessun
indice. La TcX decide allora di creare un altro server per database che fosse piu’ vicino alle loro
esigenze partendo dall’esperienza di UNIREG; nasce quindi nel 1995 la prima versione di MySQL.
La scelta del nome `e ancora un mistero: per pi`u di 10 anni i nomi della directory principale e
di un grande numero di librerie avevano il prefisso “my”; `e anche possibile che il nome sia un
omaggio alla figlia di Monty, che si chiama My. Nel 2000 la MySQL AB adotta la licenza GPL
(GNU General Public License) per il prodotto MySQL. y
MySQL `e un sistema di gestione di database relazionali Open Source. Un database `e un
insieme di dati strutturati; potrebbero essere qualsiasi cosa, dalla semplice lista della spesa
a una galleria di immagini oppure a tutte le informazioni di una rete aziendale. Relazionale
significa che i dati non vengono salvati in una sola area ma separati in pi`u tabelle, tra le quali

15. 1.2 Il Database Management System: MySQL 7
esistono delle relazioni basate sui valori contenuti; le relazioni che legano le tabelle vengono
specificate nel momento in cui si richiedono i dati, cio`e quando si interroga il database.
Essendo inoltre Open Source, MySQL pu`o essere scaricato liberamente da Internet, usato
e modificato per soddisfare le esigenze di ogni utilizzatore. Le caratteristiche principali di
MySQL sono:
• affidabilit`a: questo sistema vanta ormai un numero elevato di installazioni in tutto il
mondo e si `e guadagnato una buona reputazione per la sua affidabilit`a (vedi la lista
degli utenti contenuta nell’appendice B di [4]);
• velocit`a: `e stata la prerogativa principale dei programmatori quando hanno cominciato
lo sviluppo di questo DBMS; questo ha comportato scelte penalizzanti come il non
riconoscimento delle chiavi esterne e dei trigger che richiederebbero il blocco automatico
dei dati o il loro controllo preventivo;
• capacit`a: in linea generale la capacit`a di MySQL in termini di database `e limitata
dalle dimensioni massime dei file ammesse dal sistema operativo: su un PC con Linux,
ad esempio, `e possibile creare una tabella unica da due gigabyte; su Linux–Alpha, invece,
le dimensioni massime di una tabella sono limitate a otto terabyte (alcuni utenti usano
MySQL con 60’000 tabelle e circa 5’000’000’000 di records);
• controllo di accesso: l’accesso al sistema avviene non solo in base all’identificatore
e alla password dell’utente, ma anche in base all’host da cui proviene la richiesta di
connessione; `e possibile inoltre controllare i permessi a livello di tabella e perfino di
colonna;
• strumenti di sviluppo: esistono molte API che permettono l’accesso al database da
molti ambienti di programmazione tra cui Java (attraverso i driver JDBC), C, C++,
Perl, PHP, Python e TCL; anche le applicazioni Win32 si possono collegare al database
utilizzando i driver ODBC (Open–DataBase–Connectivity);
• supporto di varie piattaforme tra cui Windows, Linux, Mac OS X Server e numerose
varianti di UNIX;
• entry level SQL92: il linguaggio di interrogazione usato per accedere ai dati `e un
dialetto dell’SQL (acronimo di Structured Query Language); sono stati inoltre introdotti
nuovi domini per i dati, nuove parole chiave e funzionalit`a specifiche.
Naturalmente i vantaggi di MySQL vengono pagati con la mancanza di alcune caratteristiche
importanti:
• non `e possibile interrogare il database attraverso SELECT annidati come le seguenti:
SELECT * FROM table1 WHERE id IN (SELECT id FROM table2);
SELECT * FROM table1 WHERE id NOT IN (SELECT id FROM table2);

16. 8 Tecnologie lato server
• il supporto alle transazioni `e parziale;
• non si possono memorizzare procedure e definire trigger (azioni che vengono intraprese
al verificarsi di un particolare evento);
• non supporta i vincoli di integrit`a interrelazionali come le chiavi esterne (FOREIGN KEY);
• non supporta le viste.
g MySQL AB: www.mysql.com
1.2.1 Structured Query Language (SQL)
y Nel 1970 E. F. Codd, ricercatore dei laboratori della IBM a San Jos`e in California, pubblica un
articolo intitolato “A Relational Model of Data for Large Shared Data Banks” che segna l’avvio
di esperimenti e ricerche per la realizzazione di linguaggi relazionali; il linguaggio pi`u significativo
`e SEQUEL (Structured English Query Language) definito da D. Chamberlin e da altri ricercatori
dei laboratori IBM, implementato negli anni 1974–75. Nel 1976-77 viene definita una versione
rivista denominata SEQUEL/2 il cui nome verr`a poi modificato in SQL per ragioni legali. Il primo
prototipo operativo di DBMS (Database Management System) viene installato da IBM nel 1977
con il nome di System R; d’ora in poi altri produttori cominciano ad investire nello sviluppo
di strumenti relazionali tra cui ORACLE Relational Software Inc e Sybase Inc; nel 1982 l’ANSI
(American National Standards Institute incarica il suo Database Committee X3H2 di sviluppare
una proposta per un linguaggio relazionale standard e porta alla definizione di un linguaggio che
`e sostanzialmente un dialetto di SQL dell’IBM. Nel 1987 l’ISO (International Organization for
Standardization) fa suo lo standard ANSI e lo chiama SQL/86; a questo seguiranno nel 1989 la
versione SQL/89 e nel 1992 quella denominata SQL–2 o SQL/92. Nel 1994 e nel 1996 vengono
pubblicati due documenti con correzioni tecniche significative. Nel 1999 viene presentata la
versione chiamata SQL/99 o SQL–3 ancora lontana dall’essere comunemente adottata. y
SQL `e un linguaggio per i sistemi di gestione di database relazionali. Infatti contiene al
suo interno sia le funzionalit`a per la definizione dello schema di una base di dati relazionale
(DDL, Data Definition Language) sia quelle per la modifica e l’interrogazione dell’istanza di
una base di dati (DML, Data Manipulation Language). Gi`a la versione del 1992 (SQL–2) `e
un linguaggio ricco e complesso, tanto che ancora molti sistemi commerciali non mettono a
disposizione tutte le funzionalit`a previste dallo standard.
Per quantificare in modo preciso l’aderenza allo standard, sono stati definiti tre livelli di
complessit`a dei costrutti del linguaggio, denominati rispettivamente Entry SQL, Intermediate
SQL e Full SQL.
1.2.2 Il pool di connessioni: DbConnectionBroker
DbConnectionBroker `e un package scritto interamente in Java per gestire connessioni multiple
e concorrenti verso un database. Il broker crea un pool dinamico di connessioni tenute sempre
aperte e pronte all’uso; quando una procedura ha bisogno di accedere alla base di dati, riceve

17. 1.3 Il server Web: Tomcat 9
una connessione dal broker e gliela restituisce non appena ha terminato di usarla. In questo
modo si evitano i tempi morti dovuti alle procedure di handshaking e di autenticazione, e si
riduce il numero di connessioni contemporaneamente aperte.
g Java Exchange: www.javaexchange.com
1.3 Il server Web: Tomcat
y Ai tempi delle definizioni delle specifiche JSP 1.0 e Servlet 2.0, la Sun svilupp`o il suo Java Serv-
er Web Development Kit poi rinominato Java Servlet Development Kit (JSDK), che utilizava un
Web Server interamente realizzatoin Java. Nel frattempo un gruppo esterno di sviluppatori open–
source, l’Apache Java Group, stava lavorando su un motore JSP/servlet che fosse compatibile con
le ultime API dei servlet e delle JSP ma che avrebbe dovuto integrarsi con i server Apache larga-
mente diffusi; il motore prese il nome di Apache JServ. Realizzarono JServ in due parti: la prima
era scritta in C e doveva fungere da modulo caricabile per il server Apache, l’altra era una imple-
mentazione in Java, di un servlet–container stand–alone. Le due parti comunicavano per mezzo
di un protocollo privato. Mentre il progetto JSDK della Sun era focalizzato sull’adesione alle
specifiche, l’Apache JServ si concentr`o sulle performance e sugli aspetti pi`u pragmatici. Divent`o
presto evidente che i due progetti si sovrapponevano e che gli sforzi si sarebbero dovuti unire.
Nel 1999 la Sun don`o alla Apache Software Foundation il codice sorgente dell’implementazione
di riferimento per le JSP e i servlet; per integrare i due progetti sorse il gruppo di collaborazione
Jakarta che fin`ı per`o per includere tutti i progetti open–source dell’Apache Java group. Tomcat
`e uno di questi progetti: la serie 3.x discende direttamente dal progetto della Sun mentre la
versione 4 impiega una nuova architettura ad alte prestazioni. y
Tomcat `e un server Web completamente scritto in Java; pi`u precisamente si tratta di un
servlet container stand–alone e rappresenta l’implementazione di riferimento per le tecnologie
JavaServer Pages ver 1.2 e Java Servlet ver 2.3, con l’aggiunta di alcune caratteristiche che lo
rendono pi`u efficiente e ne fanno una utile piattaforma per sviluppare e far girare applicazioni
Web.
Il servlet container gira in una Java Virtual Machine (vedi la figura 1.1) e pu`o essere
affiancato ad un server Web in tre modi:
• in–process: il servlet container `e legato al server Web da un plug–in cha fa un po’
da mediatore tra i due; plug–in e container si trovano nello stesso spazio di memoria
del server cos`ı come la JVM che li esegue; questa configurazione garantisce le massime
prestazioni dovute alla condivisione della memoria ma dall’altro canto limita la sca-
labilit`a e l’affidabilit`a (il crash di un qualsiasi thread pu`o portare al crash dell’intero
server;
• out–of–process: a differenza del tipo precedente qui si usano due spazi di memoria
distinti: in uno gira il server con il plug–in Java, nell’altro si trova la JVM con il servlet
container; solitamente plug–in e container comunicano usando il protocollo TCP–IP;

18. 10 Tecnologie lato server
Computer host
Java Virtual Machine
Servlet container out-of-process
Server Web Java plug-in
Computer host
Java Virtual Machine
Servlet container stand-alone
Servlet : Servlet :
Servlet : Servlet :
Figura 1.1: A sinistra un servlet container di tipo out–of–process; a destra uno
di tipo stand–alone.
• stand–alone: in questo caso il servlet container funge da server Web vero e proprio e
risponde direttamente alle richieste dei clients.
Quest’ultimo `e proprio il caso di Tomcat; infatti il servlet container mette a disposizione i
servizi di rete necessari a ricevere le richieste, decodificarle in base al protocollo HTTP e
inviare le risposte. Inoltre ospita e gestisce i servlet durante tutto il loro ciclo di vita. La
figura 1.2 mostra come si articola il flusso dei messaggi generato da una richiesta HTTP
dell’utente (il client):
• la richiesta viene ricevuta dal server Web e consegnata al servlet container che, come si
`e detto, pu`o essere fisicamente separato;
• il servlet container determina, in base alla sua configurazione e ai parametri della
richiesta, a quale servlet dovr`a passare il controllo;
• il servlet usa l’oggetto che rappresenta la richiesta HTTP per individuare l’utente remoto
e ricavarne il contenuto; esegue le operazioni per cui `e stato programmato e prepara i
dati da inviare al client;
• non appena il controllo ritorna al servlet container, questo si assicura che la risposta
venga interamente inviata al client.
I parametri di configurazione e di inizializzazione di Tomcat, come quelli di ogni singola
applicazione Web installata, vengono specificati da alcuni file in formato XML:
• server.xml viene letto ad ogni avvio del servlet container e contiene informazioni come
il nome del server, la porta per la connessione HTTP, la directory di installazione delle
applicazioni, i timeouts;

19. 1.3 Il server Web: Tomcat 11
Client Web Web Server Servlet Container Servlet
richiesta HTTP
risposta
richiesta HTTP
risposta
Figura 1.2: Flusso dei messaggi in un server Web dotato di un servlet container
Java.
• web.xml pu`o essere presente nella directory /WEB-INF/ di ciascuna applicazione e speci-
fica:
∗ quale meccanismo di autenticazione usare;
∗ i parametri di inizializzazione dei servlet;
∗ eventuali filtri che mappano le richieste HTTP e le inoltrano al servlet corretto;
∗ eventuali pagine di errore;
∗ la configurazione delle sessioni di lavoro;
∗ l’uso di eventuali librerie di tag personalizzati.
g Jakarta Tomcat: jakarta.apache.org/tomcat/index.html
1.3.1 Servlet e JavaServer PagesTM
y Il lavoro di James Gosling su un server Web basato su Java negli anni 1994/1995 divent`o
la base di partenza per i servlet. Un progetto pi`u ampio emerse nel 1996 da una gruppo di
sviluppatori capeggiati da Pavani Diwanji, che port`o alla realizzazione del Java Server Web di
Sun. Dal 1999 le cose si mossero molto rapidamente: il servlet expert group guidato da James
Davidson consegn`o a gennaio le specifiche dei servlet versione 2.1 e in dicembre la versione 2.2;
contemporaneamente il JSP group guidato da Larry Cable ed Eduardo Pelegri–Llopart definisce
la versione 1.1 delle JSP. L’anno 2000 ha visto nascere molte implementazioni di contenitori di

20. 12 Tecnologie lato server
servlet come anche strumenti di sviluppo e libri riguardanti soprattutto JSP 1.1 e Servlet 2.2.
Da quel momento in poi l’area che ebbe maggior sviluppo fu la realizzazione di librerie di tag
personalizzate. y
I Servlet sono delle classi Java indipendenti dalla piattaforma che vengono compilate in byte-
code e che possono essere caricate dinamicamente in un server Web abilitato; vengono eseguiti
rapidamente sul server in risposta alla richiesta di una pagina Web inviata, per esempio, da un
browser. La necessit`a di distribuire contenuti personalizzati a vari utenti collegati in Internet,
aveva portato all’uso delle applet Java; avevano per`o degli svantaggi: dovevano essere prima
scaricate dal server con dispendio di tempo e poi non c’era la sicurezza che i vari browsers
fossero compatibili con le applet. Si pens`o allora di spostare l’esecuzione del codice dal client
al server. Nascono cos`ı le tecnologie Java server–side che mettono a disposizione dei server
Web le peculiarit`a del linguaggio Java.
Dal punto di vista funzionale i servlet si collocano tra i programmi CGI (Common Gateway
Interface) e le estensioni proprietarie dei server come le NSAPI (Netscape Server API ) o i
moduli di Apache. I vantaggi dei servlet rispetto ai moduli sono:
• maggiore velocit`a rispetto agli script CGI poich´e quest’ultima prevede che il server web
una volta ricevuta la richiesta prepari diverse variabili d’ambiente relative alla richiesta
stessa e richiami il programma esterno; anche se `e dispendiosa in termini di tempo della
CPU, di memoria e di risorse `e ancora molto utilizzata;
• le API usate sono standard e sono supportate da molti server Web;
• possono accedere al grande numero di API disponibili per la piattaforma Java.
L’interfaccia javax.servlet.Servlet rappresenta l’astrazione fondamentale per i servlet;
infatti ogni classe servlet deve implementare o estendere questa interfaccia. L’interfaccia
prevede che venga definito il metodo service per gestire le richieste dei clients: questo
metodo viene chiamato dal servlet container ogni volta che un client invia una richiesta;
generalmente il servlet container riesce a soddisfare le richieste concorrenti usando una sola
istanza di ogni servlet ed eseguendo il metodo service in threads differenti. Quando il
servlet container passa la prima richiesta ad un servlet, ne richiama il suo metodo init senza
specificare alcun parametro: in questo modo il servlet `e in grado di svolgere le necessarie
operazione di inizializzazione (come per esempio la lettura di alcuni parametri o la creazione
di un pool di connessioni al database). Quando invece il container vuole liberarsi di un servlet
chiama il suo metodo destroy. Questi metodi definiscono precisamente il ciclo di vita di un
servlet.
Un’altra interfaccia importante `e javax.servlet.http.HttpServlet che estende quella
di prima aggiungendo alcuni metodi importanti per gestire il paradigma richiesta/risposta
con il client:
• doGet viene invocato quando la richiesta HTTP `e di tipo GET;
• doPost viene invocato quando la richiesta HTTP `e di tipo POST.

21. 1.3 Il server Web: Tomcat 13
Altre interfacce importanti sono:
• javax.servlet.ServletContext mette a disposizione del servlet la vista dell’appli-
cazione Web di cui fa parte; il servlet container ne fornisce l’implementazione e l’istanza
ai servlet che lo richiedano che possono cos`ı produrre messaggi di log, ottenere i riferi-
menti a risorse comuni, salvare o cancellare attributi a cui altri servlet appartenenti allo
stesso contesto possono accedere;
• javax.servlet.http.HttpServletRequest incapsula tutte le informazioni della richie-
sta del client, che nel caso del protocollo HTTP `e formata da una serie di headers e dal
corpo del messaggio; alcuni dei suoi metodi sono:
∗ getCookies che restituisce la lista dei cookies del client;
∗ getHeaders che restituisce la lista dei delle intestazioni legate alla richiesta HTTP;
∗ getSession che restituisce l’oggetto che modella la sessione attualmente in uso;
∗ getRequestURL che restituisce l’URL che il client ha usato per fare la richiesta;
∗ getParameter che restituisce la lista dei parametri legati alla richiesta;
• javax.servlet.http.HttpServletResponse incapsula tutte le informazioni della ri-
sposta verso il client che, come per la richiesta, `e formata da una serie di headers e dal
corpo del messaggio; ecco i suoi principali metodi:
∗ addCookie imposta un cookie;
∗ addHeader aggiunge un header alla richiesta HTTP;
∗ getOutputStream restituisce il flusso di dati verso il client;
∗ setContentType imposta il tipo MIME della risposta (es. text/html, image/gif,
application/zip . . . );
• javax.servlet.http.HttpSession mette a disposizione un modo per identificare l’u-
tente nel corso di pi`u richieste HTTP e per salvare informazioni riguardanti l’utente che
visita un sito; l’Hypertext Transfer Protocol (HTTP) `e infatti un protocollo senza stati
che non permette di associare facilmente le varie richieste con un particolare client; i
meccanismi usati per tener traccia dell’utente si basano su:
∗ cookies: `e il sistema pi`u usato; il container invia un cookie al client che lo rispedir`a
al server ad ogni richiesta successiva, permettendo di associarla alla sessione senza
possibilit`a di errore;
∗ sessioni SSL: la tecnologia di criptazione Secure Sockets Layer usata nel protocol-
lo HTTPS, implementa gi`a internamente un meccanismo che permette di associare
le richieste di uno stesso client con una sessione;
∗ riscrittura degli URL: quando un client non accetta i cookies, il server pu`o ag-
giungere un identificatore di sessione ad ogni percorso URL contenuto nelle pagine
HTML che invia; il nome del parametro deve essere jsessionid come nel seguente
esempio:

22. 14 Tecnologie lato server
http://www.myserver.com/catalog/index.html;jsessionid=1234
∗ campi nascosti nei form HTML: nei form HTML vengono aggiunti dei campi
nascosti contenenti le informazioni che si vogliono mantenere per pi`u transazioni;
i metodi pi`u significativi di HttpSession sono:
∗ setAttribute/getAttribute permettono di associare e prelevare un oggetto sal-
vato nella sessione;
∗ getId restituisce il numero identificativo della sessione;
∗ invalidate invalida la sessione e rimuove ogni oggetto associato;
∗ setMaxInactiveInterval stabilisce il numero massimo di secondi tra due richieste
successive dopo i quali la sessione non viene considerata pi`u valida;
I servlet, pur rappresentando una buona soluzione a molti problemi posti dalla program-
mazione lato server, non sono molto adatti a creare pagine HTML dinamiche; inoltre `e quasi
impossibile separare il lavoro di chi sviluppa la logica e i componenti di un’applicazione web,
dal lavoro di chi scrive i contenuti e cura l’aspetto visivo delle pagine.
Una soluzione a questi problemi `e stata trovata con le JavaServer PagesTM. Una JSP
`e un documento di testo che descrive come deve essere processata un richiesta per creare
una risposta: in sostanza sono file HTML (ma potrebbero essere anche di altri formati) con
estensione .jsp contenenti speciali tag in formato XML. Pi`u precisamente una pagina JSP
pu`o contenere:
• direttive: forniscono informazioni valide indipendentemente dalla specifica richiesta
ricevuta dalla pagina JSP; queste informazioni servono per la fase di traduzione e sono
del tipo:
<%@ d i r e c t i v e { attr”=”value }∗ %>
come per esempio <%@include file="JSPHead.jsp"%>;
• azioni: possono essere standard oppure personalizzate usando il meccanismo dell’esten-
sione dei tag (librerie di tag personalizzati); la sintassi segue le regole del formato XML:
hanno quindi un tag d’inizio, che comprende il nome dell’elemento, degli attributi, un
corpo opzionale e un eventuale tag di fine come nel seguente esempio:
<mytag attr1=”a tt r ib ut e value ” . . .>body</mytag>
tra le azioni pi`u importanti si segnalano
<jsp:useBean>
<jsp:setProperty>
<jsp:getProperty>
<j s p : i n c l u d e>
la prima permette di dichiarare un bean da usare in una JSP; la seconda e la terza
scrivono o leggono una propriet`a del bean; la terza include altri files esterni o JSP.

23. 1.3 Il server Web: Tomcat 15
• elementi di scripting: in pratica sono pezzi di codice Java che servono come “collante”
tra azioni e dati statici; sono di tre tipi:
∗ dichiarazioni: servono a dichiarare variabili e metodi che potranno essere usati
nella pagina JSP e non producono nulla nel flusso di uscita verso il client; la
sintassi `e:
<%! declaration ( s ) %>
come per esempio <%! int i = 0; %> oppure
<%! public String f(int i) { if (i<3) return("..."); ... } %>
∗ scriptlet: sono dei veri e propri frammenti di codice che vengono eseguiti nel
momento in cui viene processata la richiesta; la sintassi `e
<% s c r i p t l e t %>
come nel seguente esempio
<% if (Calendar.getInstance().get(Calendar.AM_PM) == Calendar.AM) {%>
Good Morning
<% } else { %>
Good Afternoon
<% } %>
∗ espressioni: `e un’espressione in linguaggio Java che viene valutata e il cui risultato
`e forzatamente convertito in una stringa; il risultato `e successivamente inviato al
client; la sintassi `e:
<%= expression %>
come per esempio <%= (new java.util.Date()).toLocaleString() %>;
Nella pratica non `e buona norma inserire troppo codice nella JSP perch´e ridurrebbe la
leggibilit`a e l’efficienza ddi questa tecnologia; diventa allora pi`u conveniente usare dei
tag personalizzati oppure dei JavaBeans;
• dati statici: `e tutto ci`o che non rientra nelle categorie precedenti e rappresentano le
parti fisse (template); possono essere per esempio del testo, del codice HTML o XML.
Quando `e richiesta una JSP da parte di un utente il JSP container (per esempio Tomcat) legge
la JSP e la utilizza come modello per creare un servlet che viene successivamente compilato
e caricato dal servlet container; ad ogni richiesta successiva della stessa pagina il servlet
container si limiter`a a rieseguire gli stessi metodi su threads concorrenti.
Per una descrizione pi`u accurata e approfondita si rimanda a [1], [21] e [25].
g Servlet: java.sun.com/products/servlet
g JavaServer Pages: java.sun.com/products/jsp

24. 16 Tecnologie lato server
1.3.2 Taglibs: una libreria di tag personalizzati
Come accennato nella sezione precedente, le azioni rappresentate dai tag possono essere
standard oppure personalizzate cio`e possono essere create dal programmatore; in questo se-
condo caso i tag vengono riuniti in librerie che possono essere usate nelle pagine JSP; la
dichiarazione si fa con la direttiva <%@ taglib . . . %>. Queste librerie rappresentano
un meccanismo importante per separare l’aspetto visuale dalla programmazione delle pagine
HTML dinamiche.
Taglibs fa parte del progetto Jackarta e raccoglie una serie di librerie che mettono a
disposizione diversi tipi di tag:
• DBTags: permettono di aprire connessioni al database, eseguire queries ed infine
inserire i risultati ottenuti nelle pagine JSP;
• Request/Response: permettono di accedere agli oggetti che contengono la richiesta
e la risposta del client, leggendone i parametri o il contenuto; possono anche creare o
leggere i cookies;
• Session: accedono agli attributi che riguardano la sessione corrente;
• Utility: mettono a disposizione tag condizionali, cicli for e altre utilit`a.
g Jakarta Taglibs: jakarta.apache.org/taglibs
1.4 I JavaBeans
Come si `e accennato non `e molto comodo e conveniente inserire troppo codice Java (cio`e
scriptlet) all’interno delle pagine JSP. Pu`o invece essere molto utile racchiuderlo in una classe
apposita che viene chiamata al momento del bisogno; per questo esistono i JavaBeans ovvero
l’architettura a componenti di Java. I vantaggi offerti da questi componenti software nel-
l’ambito delle applicazioni Web, sono quelli di permettere la riusabilit`a del software (“scrivi
una volta, esegui dappertutto”), la separazione tra contenuto e codice, l’implementazione
di uno stato dell’applicazione (compensando la natura “senza stati” del protocollo HTTP).
La specifica relativa ai JavaBeans `e molto complessa ma vale la pena di elencare alcune
caratteristiche:
• non devono avere alcuna propriet`a pubblica;
• le propriet`a che devono essere esposte dovranno avere metodi get e set secondo necessit`a
(per esempio getExamName oppure setExamDate);
• devono avere almeno un metodo costruttore senza argomenti per poter caricare il bean
a piacimento.
Le JSP mettono a disposizione alcune direttive per accedere alle propriet`a dei beans (vedi la
sezione 1.3.1).
g JavaBeansTM technology: java.sun.com/beans

25. Capitolo 2
Tecnologie lato client
A differenza delle tecnologie server–side, che sono numerose e possono essere molto diverse
(basti pensare ai server Web, ai DBMS, ai linguaggi di programmazione), dal lato del client
le tecnologie, o meglio i formati dei documenti e i linguaggi usati, sono in numero ristretto e
rappresentano il vero denominatore comune tra le diverse applicazioni Web.
2.1 Formati e linguaggi
2.1.1 HyperText Markup Language (HTML)
y L’HTML fu originariamente sviluppato da Tim Berners–Lee quando lavorava al CERN, e fu
reso popolare dal browser Mosaic, sviluppato presso la NCSA (National Center for Supercom-
puting Applications). Nel corso degli anni ’90 si `e imposto grazie alla crescita esplosiva del Web.
Durante questo tempo l’HTML `e stato ampliato in molti modi. Il Web poggia sul fatto che autori
di pagine Web e rivenditori condividono le medesime convenzioni per quanto riguarda l’HTML;
ci`o ha motivato un lavoro congiunto sulle specifiche dell’HTML. L’HTML 2.0 (Novembre 1995)
fu sviluppato sotto l’egida della Internet Engineering Task Force (IETF) per codificare quello che
era ormai nell’uso comune alla fine del 1994. L’HTML+ (1993) e HTML 3.0 (1995) proposero
versioni molto pi`u ricche dell’HTML. A dispetto del fatto di non aver mai ricevuto consensi
nelle discussioni sugli standard, queste bozze di lavoro hanno portato all’adozione di una variet`a
di nuove caratteristiche. Gli sforzi del Gruppo di lavoro su HTML all’interno del World Wide
Web Consortium (W3C), per codificare ci`o che era d’uso comune nel 1996, sfociarono nell’HTML
3.2 (Gennaio 1997). L’HTML 4 estende le possibilit`a dell’HTML con meccanismi per i fogli di
stile, lo scripting, i frame, gli oggetti incorporati con l’offerta di una maggiore accessibilit`a per le
persone affette da disabilit`a. L’HTML `e stato sviluppato con l’idea che ogni tipo di dispositivo
dovrebbe essere in grado di utilizzare le informazioni presenti sul Web: i PC con schermi grafici
di varie risoluzioni e profondit`a del colore, i telefoni cellulari, i palmari, i sintetizzatori vocali, i
computer dotati di connessioni veloci e quelli con connessioni lente, e cos`ı via. y
Per pubblicare informazioni destinate ad una distribuzione globale, `e necessario usare un
linguaggio universalmente compreso, una specie di madre lingua per l’editoria che tutti i

26. 18 Tecnologie lato client
computer siano in grado potenzialmente di comprendere. Il linguaggio di pubblicazione usato
dal World Wide Web `e l’HTML. L’HTML d`a agli autori i mezzi per:
• pubblicare documenti online con intestazioni, testo, tabelle, elenchi, foto, ecc.;
• recuperare informazioni online per mezzo di collegamenti ipertestuali, al clic di un
pulsante;
• progettare moduli per effettuare transazioni con servizi remoti, da utilizzare nella ricerca
di informazioni, nel fare prenotazioni, nell’ordinare prodotti, ecc.;
• includere fogli elettronici, video, brani audio e altre applicazioni direttamente nei loro
documenti.
I documenti HTML come ogni risorsa disponibile nel Web sono identificati da un indirizzo
che pu`o essere codificato per mezzo di un URI (Uniform Resource Identifier). Gli URI si com-
pongono tipicamente di tre parti: la denominazione del meccanismo utilizzato per accedere
alla risorsa, il nome della macchina che ospita la risorsa e il nome della risorsa stessa (per
esempio http://www.w3.org/TR).
Un documento HTML `e sostanzialmente un file di testo composto da contenuti testuali
e marcatori (tag) che servono a identificare la struttura del documento, la semantica dei
contenuti e gli aspetti legati alla presentazione e alla visualizzazione. I tag possono essere
unici (come nel caso di <IMG>) oppure possono essere di apertura, seguiti da un corpo e da un
tag di chiusura (per esempio <BIG>testo grande</BIG>); possono anche contenere al loro
interno degli attributi come per esempio
<INPUT class="login" type=PASSWORD name="Password" size="20">
Le parti fondamentali che compongono un documento HTML sono tre:
• una linea con le informazioni sulla versione dell’HTML;
• una sezione di intestazione delimitata dall’elemento HEAD;
• un corpo con i contenuti veri e propri del documento.
Ecco un esempio di un semplice documento HTML:
<!DOCTYPE HTML PUBLIC ”−//W3C//DTD HTML 4.01//EN”
” http ://www. w3 . org /TR/html4/ s t r i c t . dtd”>
<HTML>
<HEAD>
<TITLE>I l mio primo documento HTML</TITLE>
</HEAD>
<BODY>
<P>Eccomi !
</BODY>
</HTML>
g W3C HTML Activity: www.w3.org/MarkUp

27. 2.1 Formati e linguaggi 19
2.1.2 Cascading Style Sheets (CSS)
y La separazione della struttura di un documento dal suo layout fu gi`a un traguardo dell’HTML
dal suo inizio nel 1990: Tim Berners–Lee realizz`o il suo browser con un semplice foglio di stile
con una propria sintassi, che servisse per vari tipi di documenti; pensava che dovessero essere i
browser ad occuparsi dello stile grafico da dare ai documenti. Nel 1993 un browser importante
come l’NCSA Mosaic permetteva all’utente di cambiare solamente alcuni colori e font. Dall’altra
parte gli autori di pagine Web reclamavano di non avere abbastanza influenza sul layout dei
documenti. In risposta a questa esigenza, peraltro inascoltata da parte di alcuni programmatori
tra cui Marc Andreessen di NCSA Mosaic, H˚akon pubblic`o un primo documento sui fogli di
stile “a cascata” per l’HTML, incoraggiato da Dave Raggett il principale architetto del HTML
3.0. Nello stesso periodo Bert Bos stava lavorando al progetto Argo, un browser altamente
personalizzabile che supportava alcuni fogli di stile, e pens`o di unire le proprie forze con H˚akon.
La prima proposta dei CSS venne presentata nel 1994 e aveva come punto di forza, rispetto
anche ad altri linguaggi, la capacit`a di combinare (cascading) stili diversi definiti sia dall’autore
che dal fruitore dei contenuti, tenendo conto delle possibilit`a di visualizzazione del browser. Nel
dicembre del 1996 il CSS level 1 divent`o una W3C Recommendation e nel 1997 venne costituito
un gruppo di lavoro proprio in seno al W3C (il Cascading Style Sheets and Formatting Properties
Working Group) condotto da Chris Lilley. Nel frattempo la Microsoft si impegn`o a supportare i
fogli di stile nelle successive versioni di Internet Explorer che divent`o, nel 1996 con la versione 3,
il primo browser commerciale a supportarlo. Il browser successivo ad implementare i CSS, anche
se in modo parziale e con molto scetticismo da parte dei suoi programmatori, fu la versione 4 di
Netscape. y
I fogli di stile semplificano il codice di marcatura dell’HTML e sollevano in larga misura
l’HTML da compiti di presentazione. Essi danno ad autori ed utenti il controllo sulla pre-
sentazione dei documenti (informazioni sullo stile dei caratteri, l’allineamento dei paragrafi,
i colori, ecc.). Prima dell’avvento dei fogli di stile, gli autori avevano un controllo limitato
sulla riproduzione. L’HTML 3.2 includeva un certo numero di elementi e attributi che per-
mettevano di controllare allineamento, dimensione del carattere e colore del testo. Gli autori
sfruttavano anche tabelle e immagini come strumenti di formattazione delle pagine.
Le informazioni sullo stile possono essere specificate per singoli elementi, mediante l’uso
dell’attributo class dei tag HTML, o per gruppi di elementi. Tali informazioni vengono
collocate all’interno di un documento HTML o in un foglio di stile esterno. Per fare un
esempio se supponiamo di avere in un foglio di stile
P. s p e c i a l {
c o l o r : green ;
border : s o l i d red ; }
un autore pu`o collegarlo ad un documento in questo modo:
<HTML>
2 <HEAD>
<LINK href=”s p e c i a l . css ” r e l=”s t y l e s h e e t ” type=”text / css ”>
4 </HEAD>

28. 20 Tecnologie lato client
<BODY>
6 <P c l a s s=”s p e c i a l ”>Queste pa role sono s c r i t t e in verde .
</BODY>
8 </HTML>
Come si pu`o vedere, la riga 3 contiene il riferimento al file contenente il foglio di stile, mentre
la riga 6, all’interno del tag <P>, contiene il riferimento al nome dello stile.
Tra le propriet`a pi`u importanti del formato CSS ci sono
• lo sfruttamento dell’incapsulamento degli elementi di un documento HTML mediante i
meccanismi dell’ereditariet`a cio`e della propagazione delle informazioni di formattazione
ai sottoelementi di un documento
• l’unione di pi`u fogli di stile mediante alcune regole di priorit`a (cascading).
g Cascading Style Sheets: www.w3.org/Style
2.1.3 Il linguaggio di scripting: JavaScript
y Nel 1995 Netscape decise di dotare il proprio browser di un linguaggio di scripting che per-
mettesse ai Web designer di interagire con i diversi oggetti della pagina (immagini, form, link,
ecc.), ma soprattutto con le applet Java; infatti in quello stesso anno Netscape aveva stretto
una partnership con Sun Microsystems (ideatrice di Java). Brendan Eich venne incaricato del
progetto e invent`o LiveScript (chiamato cos`ı per indicarne la vivacit`a e dinamicit`a). Il 4 dicem-
bre 1995 le due aziende annunciarono la nascita di questo nuovo linguaggio, descrivendolo come
“complementare all’HTML e a Java”. La versione beta di Netscape Navigator 2.0 incorporava
quindi questo linguaggio che, in omaggio a Java, Netscape decise di ribattezzare con il nome di
JavaScript. La versione 2.0 di Netscape Navigator fu un grande successo, ma i Web designer
non utilizzarono JavaScript per interagire con le applet Java (come avrebbe voluto Netscape),
ma piuttosto per rendere pi`u vive le pagine. Nel luglio del 1996 Microsoft rispose a Netscape
introducendo all’interno di Internet Explorer 3 un nuovo linguaggio di scripting (VBScript) e una
propria versione di JavaScript, sotto molti aspetti simile all’originale, chiamata JScript. A causa
di alcune differenze introdotte da Internet Explorer 3, Netscape e Sun decisero di standardiz-
zare JavaScript e si affidarono all’European Computer Manufacturers Association (ECMA) che
produsse nel giugno 1997 ECMAScript il successore di JavaScript. Attualmente siamo alla terza
versione di ECMAScript e oggi quando si parla di JavaScript, JScript ed ECMAscript sostanzial-
mente si indicano tre variet`a dello stesso linguaggio anche se rimangono qua e l`a delle differenze
tra le implementazioni di browser diversi. y
JavaScript `e un linguaggio di scripting basato sugli oggetti rivolto soprattutto ad applicazioni
client, come i browser Web. Le sue funzioni permettono di accedere a molti elementi del
documento HTML in cui vengono definite e consentono di modificarne il valore degli attributi
e le impostazioni visuali aggiungendo alle pagine Web maggiore interattivit`a. Numerosi sono
i metodi in grado di gestire agevolmente date e stringhe di testo.
Il codice dello script viene inserito in formato testo direttamente all’interno di un docu-
mento HTML usando l’apposito tag <SCRIPT> oppure in un file separato; quando il browser

29. 2.2 I browser Web 21
carica il documento, legge lo script che viene interpretato ed eseguito. Un esempio di codice
`e il seguente:
function SelectSubmit ( xSelect , HTTPrequest ) {
i f ( xSelect . selectedIndex >−1)
FormSubmit( xSelect . form , HTTPrequest ) ;
e l s e a l e r t ( ” S c e g l i un elemento dalla l i s t a ! ” ) ;
}
g JavaScript: developer.netscape.com
g ECMAScript: www.ecma.ch
2.2 I browser Web
y Verso la fine degli anni ’80 un gruppo di ricercatori informatici del CERN di Ginevra capeggiato
da Tim Berners–Lee si occupa della realizzazione di un sistema di strutturazione dell’informazione
in rete. Nella prima fase, tutta l’analisi si fondava su di un singolo nodo: i database erano residen-
ti all’interno del singolo computer e le connessioni consentivano l’accesso ai dati in essi contenuti.
Con la nascita di Gopher, si sviluppa il concetto di puntatore o link; esso rivoluziona comple-
tamente la precedente concezione primordiale di rete. `E lo sviluppo dell’HTML a consentire
l’integrazione dei link e dei contenuti non testuali, all’interno delle pagine di puro testo; questo
linguaggio si sposa con l’idea di consentire ad un semplice programma interprete di decodificare
i contenuti delle pagine e permettere all’utente finale di visualizzarle sul proprio monitor. Tra il
1992 e il 1993 la NCSA (National Center for Supercomputing Applications) sviluppa un software,
lato client, per favorire la consultazione dei documenti HTML: si tratta di Mosaic. Cos`ı il gruppo
di lavoro dell’NCSA capeggiato da Marc Andreessen produsse la pi`u versatile, multipiattaforma,
interfaccia a Web e realizzata in C. Poich´e permetteva di vedere documenti con immagini incluse,
trasferire in rete suoni o videoregistrazioni e di puntarli da un documento, divent`o ben presto il
browser Web per eccellenza per tutti i lavori su computer con capacit`a grafiche. Nel corso del
1995, Mosaic viene praticamente abbandonato (l’ultima versione `e del 1997), per lasciare spazio
ad un nuovo browser, che d`a il via all’era della moderna consultazione del Web: Netscape. y
I browser Web sono delle applicazioni client che permettono, attraverso internet, di prelevare
dai server collegati al Web i documenti HTML desiderati e di visualizzarli nella forma pi`u
appropriata; le versioni pi`u recenti offrono caratteristiche importanti come per esempio il
supporto dei fogli di stile (CSS) e di JavaScript. Tuttavia l’aderenza agli standard per il Web
`e talvolta parziale o addirittura assente. Questo crea non pochi problemi di compatibilit`a tra
browser diversi obbligando spesso gli sviluppatori Web a creare documenti diversi a seconda
del browser che li caricher`a (vedi la tabella 2.1).
g Mozilla: www.mozilla.org
g Microsoft Internet Explorer: www.microsoft.com/ie
g Netscape Navigator: www.netscape.com

30. 22 Tecnologie lato client
Browsers
Java
frames
tables
plugins
fontsize
fontcolor
JavaScript
stylesheets
GIF89
DHTML
I-Frames
tablecolor
XML
Explorer 6.0 i $ $ $ $ $ $ $ $ $ $ $ $
Explorer 5.0 $ $ $ $ $ $ $ $ $ $ $ $ i
Explorer 3.0 $ $ $ $ $ $ $ $ $ $ $
Explorer 2.0 $ $ $
Explorer 1.0 $ $ $
Netscape 7.0 $ $ $ $ $ $ $ $ $ $ $ $ $
Netscape 6.0 $ $ $ $ $ $ $ $ $ $ $ $ $
Navigator 4.7 $ $ $ $ $ $ $ $ $ $ $
Navigator 3.0 $ $ $ $ $ $ $ $ $
Navigator 2.0 $ $ $ $ $ $ i $
Navigator 1.1 $ $
Mosaic 3.0 $ $ $
Mosaic 1.0
Mozilla 1.1 $ $ $ $ $ $ $ $ $ $ $ $ $
Mozilla 1.0 $ $ $ $ $ $ $ $ $ $ $ $ $
Opera 6.0 $ $ $ $ $ $ $ $ $ $ $ $ $
Opera 4.02 $ $ $ i $ $ $ $ $ $ $ $
Opera 3.60 $ $ i $ $ $ $ $ $
Opera 3.5 $ $ i $ $ $ $ $
Lynx $ $
Tabella 2.1: Caratteristiche dei principali browser Web: $ significa che la
funzionalit`a `e supportata, i significa che non `e pienamente supportata.
2.3 Swing Java applet
Swing `e un insieme di classi Java che fornisce componenti potenti e flessibili per costruire
interfacce grafiche per l’utente. Fa parte delle Java Foundation Classes (JFC) assieme con
l’Abstract Windowing Toolkit (AWT), un sistema meno recente per costruire interfacce grafiche
e gestire eventi quali click del mouse; a differenza di quest’ultimo, per`o, i componenti di Swing
non sono implementati da codice specifico per la piattaforma; sono invece scritti completa-
mente in Java e quindi sono indipendenti dalla piattaforma. Uno tra i componenti pi`u utili
e interessanti di Swing `e la classe javax.swing.JEditorPane che permette di visualizzare,
oltre che editare, vari tipi di contenuti testuali:
• text/plain: testo semplice;

31. 2.3 Swing Java applet 23
• text/html: testo in formato HTML 3.2; la sua visualizzazione grafica `e abbastanza
corretta e completa; supporta in modo parziale i fogli di stile1 (CSS) e i form per
l’inserimento di dati da inviare al server tramite il metodo POST o GET;
• text/rtf: testo in formato RTF (Rich Text Format).
Utilizzando le caratteristiche di questo componente, tra le quali la possibilit`a di specificare un
indirizzo Web come sorgente di contenuti da visualizzare (vedi il metodo setPage(URL page)),
si riesce a realizzare un semplice ma potente browser con un controllo molto accurato sulle
azioni compiute dall’utente che lo usa.
1
nella versione 1.4.0 del JDK `e presente un bug per cui JEditorPane non riesce a collegare correttamente
gli stili ai tag HTML specificati con lettere maiuscole.

32. 24 Tecnologie lato client

33. Capitolo 3
Tecnologie di comunicazione
Vengono ora descritti brevemente i protocolli di comunicazione tra i client e il server Web, e
quelli tra l’applicazione Web e il database.
3.1 L’Hypertext Transfer Protocol (HTTP)
y Il concetto di HTTP `e stato sviluppato da un team di sviluppatori che lavoravano al CERN
(Centre Europ´e en de Recherche Nucl´eaire). Dopo aver completato il lavoro di ricerca, lo donarono
all’American University (NSCA). Nella sua versione iniziale 0.9 era un protocollo molto semplice
usato per richiedere delle pagine da un server. Il browser si connetteva al server e mandava un
comando del tipo GET /welcome.html e il server rispondeva con il contenuto del file richiesto.
Non c’erano headers o metodi al di fuori del GET, e la risposta doveva essere un documento
HTML. Successivamente i browser e i server estesero questo protocollo fino ad arrivare nel 1996
alla versione 1.0 contenuta nella specifica RFC1945. Nel 1997 viene alla luce la versione 1.1
contenuta nella RFC2068 anche se per molti anni i browser e i server utilizzarono ancora quella
precedente. y
L’HTTP definisce come le pagine Web vengono richieste e trasmesse attraverso Internet. `E
un protocollo a richiesta/risposta: un client manda una richiesta al server specificando un
metodo, l’URI (Uniform Resource Identifier che identifica univocamente le risorse presenti
nel Web), la versione del protocollo seguiti da un messaggio in formato MIME (Multipurpose
Internet Mail Extensions) contenente alcune informazioni sul client e l’eventuale corpo del
messaggio; il server risponde con una riga di stato comprendente la versione del protocollo
e un codice di successo o di errore, seguita da un messaggio in formato MIME contenente
alcune informazioni sul server, metainformazioni ed infine il contenuto vero e proprio della
risposta. Un semplice esempio di una comunicazione tra un client e un server `e la seguente:
Richiesta
Risposta
Client Web Server

34. 26 Tecnologie di comunicazione
In realt`a la situazione `e complicata dalla presenza di vari intermediari (proxy, gateway, tunnel)
nella catena che dal client arriva al server, ma in questo contesto non interessano.
g The Internet Engineering Task Force: www.ietf.org/rfc.html
3.1.1 Comunicazione applet–server: com.oreilly.servlet.HttpMessage
y Il package com.oreilly.servlet `e nato come esempio per un capitolo del libro Java Servlet
Programming scritto da Jason Hunter e pubblicato da O’Reilly & Associates. L’autore si accorse
per`o che con piccole modifiche le classi potevano vivere autonomamente al di fuori del libro ed
essere usate per scopi applicativi. y
com.oreilly.servlet.HttpMessage fa parte di un package contenente varie classi utili alla
comunicazione client–server su protocollo HTTP, orientate alla tecnologia dei Servlet Java.
La classe semplifica la comunicazione HTTP permettendo di definire dei messaggi che possono
essere inviati ad un server da una qualsiasi applicazione Java. Si pu`o utilizzare sia il metodo
GET che POST. Tra le procedure che la classe mette a disposizione si segnalano:
• setHeader permette di impostare delle intestazioni;
• setCookie permette di inviare dei cookies;
• sendPostMessage/sendGetMessage invia una richiesta costruita in base alla lista di
propriet`a specificate.
Il metodo POST di questa classe permette di inviare anche oggetti Java serializzati; quando il
server li riceve dovr`a deserializzarli prima di poterli usare. Nel caso in cui li riceva un servlet,
questi li pu`o recuperare se nel suo metodo doPost() inserisce:
ObjectInputStream objin = new ObjectInputStream ( req . getInputStream ( ) ) ;
Object obj = objin . readObject ( ) ;
g com.oreilly.servlet package: www.servlets.com/cos
3.2 La connessione al database: JDBC
Le API messe a disposizione dal Java Database Connectivity (JDBC) permettono ai program-
mi scritti in Java di accedere ad una o pi`u sorgenti di dati. Nella maggior parte dei casi, la
sorgente di dati `e un DBMS relazionale e i suoi dati sono accessibili formulando interrogazioni
SQL.
Il package che include le varie API `e il java.sql: permette di stabilire connessioni a
database, eseguire query e gestirne i risultati mediante l’oggetto ResultSet. Se si esamina
il JDBC si vede che `e soprattutto un insieme di interfacce in cui la loro implementazione `e
lasciata ai driver dei singoli DBMS. Per MySQL il driver di riferimento si chiama Connector/J
(nelle versioni precedenti MM.MySQL).

35. 3.2 La connessione al database: JDBC 27
Applicazione
Database
Driver JDBC
Figura 3.1: Schema di una 2 Tier Architecture.
3.2.1 2 Tier Architecture
Questo tipo di modello divide le funzionalit`a di un sistema in un due ambiti: il client e il
server (si veda la figura 3.1). Si vede come il client includa l’applicazione ed il driver JDBC
necessario per connettersi al database (anche attraverso Internet). Questa soluzione presenta
alcuni svantaggi quali
• la ridotta portabilit`a dovuta al fatto di essere legati ad una particolare implementazione
di database;
• la fusione della logica di presentazione con quella di controllo che riduce la manutenibilit`a
del codice.
3.2.2 3 Tier Architecture
La soluzione offerta da questo modello sta nell’introdurre una struttura intermedia come
mostrato nella figura 3.2. Si vengono cos`ı a formare tre ambiti:
1. Client tier – rappresentato da un’applicazione leggera che implementa la logica di
presentazione per l’interazione con l’utente: tipicamente programmi Java e browser
Web; il client interagisce con l’applicazione middle–tier ma non necessita di conoscerne
la struttura o le funzioni di accesso alla base di dati;
2. Middle–tier server – comprende:
∗ le applicazioni che interagiscono con il client e che implementano la logica di
controllo;
∗ l’applicazione che fornisce le funzioni ad alto livello necessarie ad altre applicazioni
per svolgere i compiti relativi al problema; pu`o per esempio gestire il pool di
connessioni al database e interagire direttamente con il driver JDBC;

36. 28 Tecnologie di comunicazione
Database
Web Client
(Browser) Applicazione
Server
Gestore
transazioni
Driver
JDBC
Driver
JDBC
Database
Middle-tier Server
Applicazione Applicazione
Figura 3.2: Schema del modello 3 Tier.
∗ i driver JDBC per fornire la connettivit`a al database;
3. Sorgente di dati – `e il livello in cui risiedono i dati e spesso `e rappresentato da un
DBMS relazionale, ma pu`o anche essere un filesystem, un foglio di calcolo oppure un
data warehouse.
g Java Database Connectivity: java.sun.com/products/jdbc
g JDBC Driver for MySQL: www.mysql.com/products/connector-j

37. Parte II
Progetto e-Val

39. Capitolo 4
Piano di progetto
Codice progetto: WebExam
Titolo progetto: e-Val – Procedure per l’autovalutazione e la valutazione
dell’apprendimento in tecnologia web
Project manager: Simone Vergolani
Data inizio: 20/02/2002
Data fine: 10/02/2003
Stakeholder:
• Universit`a degli Studi di Padova
• Prof. Matteo Bertocco
• Sistemisti del DEI e del Dipartimento di Tecnica e Gestione
dei Sistemi Industriali di Vicenza
• Studenti che affronteranno l’esame
4.1 Obiettivi
• Realizzare un’applicazione software che permetta di valutare in modo quasi automatico
la preparazione degli studenti che seguono i corsi universitari (si veda la schematiz-
zazione della figura 4.1).
• Il sistema dovr`a dare la possibilit`a di inserire dei quesiti da proporre in un compito di
un appello d’esame, di fissare le date degli appelli, di iscrivere gli studenti, di permettere
lo svolgimento dell’esame da parte degli studenti e infine di correggere i compiti svolti.
• Il sistema dovr`a inoltre fornire la stampa degli studenti iscritti ad un appello di esame,
la lista dei risultati degli appelli, il testo del compito dato agli studenti.

40. 32 Piano di progetto
Inserimento e modifica esami Docente
Esecuzione esame
Studente
Creazione e cancellazione di corsi
Amministratore
Inserimento e modifica compiti
Scelta schemi di correzione
e-Val
Inserimento e modifica quesiti
Iscrizione studenti
Figura 4.1: Rappresentazione schematica del sistema completo e delle interazioni
con i vari utenti.
• Caratteristiche avanzate da studiare, ed eventualmente realizzare, saranno la scelta
di schemi di correzione, la modifica dei quesiti inseriti, la valutazione delle difficolt`a
incontrate dagli studenti nel rispondere alle domande, la possibilit`a di salvare su file i
quesiti inseriti.
4.2 Analisi dei requisiti
Il sistema deve gestire pi`u di un corso di insegnamento per il quale si possono svolgere degli
appelli d’esame; un corso `e identificato dal docente che lo insegna. Un insegnamento tratta
varie materie divise in argomenti; la verifica della preparazione degli studenti, identificati
dal numero di matricola, consiste nel sottoporre un compito, possibilmente diverso l’uno
dall’altro, formato da pi`u quesiti riguardanti gli argomenti del corso; i quesiti possono essere
di vari tipi: a risposta multipla (cio`e la risposta o le risposte esatte si trovano tra altre errate),
di tipo numerico oppure a risposta libera. I quesiti possono contenere delle figure che ne
spiegano l’enunciato. Poich´e l’aula di informatica in cui si svolge l’esame ha un numero di
postazioni limitato, gli studenti devono poter essere divisi in gruppi e fatti entrare a turno,
non appena il gruppo precedente ha terminato l’esame.
Nell’ottica di gestire in modo automatico lo svolgimento degli esami il docente deve creare
uno o pi`u compiti, fissare un appello d’esame ed iscrivere gli studenti; l’applicazione dovr`a
occuparsi di identificare lo studente che si presenta per sostenere un esame, controllare il
tempo a sua disposizione per svolgerlo, annotare ogni azione che lo studente compie ma che

41. 4.3 Vincoli 33
non `e finalizzata allo svolgimento del compito (chiusura del programma, abbandono della
finestra, ecc.) ed infine correggere le risposte date dagli studenti. Appena concluso l’esame il
docente deve poter scegliere uno schema di correzione che stabilisca i criteri per assegnare i
voti e deve poter stampare la tabella dei risultati.
4.3 Vincoli
I vincoli del progetto sono i seguenti (tra parentesi sono specificati gli strumenti utilizzati
durante lo sviluppo dell’applicazione):
• sistema operativo lato server: Linux (per lo sviluppo Windows XP );
• database management system: MySQL (per lo sviluppo MySQL ver 3.23.42–nt [Win32]);
• server web: Tomcat (per lo sviluppo Apache Tomcat HTTP Server ver 4.0.3 [Win32]);
• linguaggi e tecnologie server–side: Java (per lo sviluppo JavaTM 2 SDK Standard Edition
ver 1.3.1), JavaServer Pages ver 1.2, Java Servlet ver 2.3;
• comunicazione client–server mediante protocollo HTTP;
• client dello studente: Java Swing JFrame che permetta di visualizzare delle pagine
HTML;
• clients del docente: Java Swing JFrame e browser web che permettano di visualizzare
delle pagine HTML con fogli di stile;
• linguaggio di scripting client–side (incluso nel browser): JavaScript 1.3 (ECMA–262);
• risorse umane: una sola persona.
Come si pu`o notare l’applicazione `e stata sviluppata su piattaforma Windows anche se dovr`a
essere installata su un sistema Linux; ci`o `e permesso dalla tecnologia Java che garantisce la
massima portabilit`a del software.
4.4 Criticit`a
Di seguito sono descritti i casi pi`u critici che hanno richiesto uno sforzo particolare per essere
risolti, e accanto ad ognuno un breve cenno sulle azioni intraprese per affrontarli.
Descrizione criticit`a Azione
Implementazione di una 3–tier archi-
tecture evitando cio`e che i client ac-
cedano direttamente al database via
TCP–IP da internet
Uso della classe
com.oreilly.servlet.HttpMessage che
serializza un qualsiasi oggetto Java e lo invia
via HTTP al server Web il quale lo deserializza
e si occupa di inserirlo nel database

42. 34 Piano di progetto
Descrizione criticit`a Azione
Analisi del contenuto dei documen-
ti HTML per estrarne i quesiti, le
immagini e le risposte corrette
Uso della classe
com.arthurdo.parser.HtmlStreamTokenizer
per la realizzazione del parser Java che gestisce
gli eventi generati dai tag HTML
Mantenimento dei vincoli di integrit`a
referenziale tra le tabelle della base
di dati per evitare le anomalie di
cancellazione
La cancellazione dei record avviene ricorrendo
alla preventiva selezione tramite SQL degli stessi
con JOIN esterni
Possibilit`a di visualizzazione di docu-
menti HTML e invio dei dati dei form
sul client studente
Utilizzo del componente Java
javax.swing.JEditorPane che permette
la visualizzazione e l’editing di documenti
HTML
Permettere come risposta ad un quesi-
to d’esame un valore numerico da con-
siderare esatto entro un certo margine
di errore come anche ±∞
Realizzazione delle classi eVal.RealInterval e
eVal.Answer che implementano degli intervalli
reali entro cui considerare esatta la risposta
Sottoporre agli studenti con gli stessi
compiti i quesiti in un ordine casuale
Utilizzo di una funzione pseudo–casuale di
MySQL con cui ordinare i quesiti, che permette
la ricostruzione dell’ordine
La Work Breakdown Structure del progetto, illustrata nella figura 4.2, `e una struttura
orientata ai risultati che raggruppa gli elementi del progetto al fine di organizzare e definire
il campo d’azione complessivo del progetto.

43. 4.4 Criticit`a 35
Gestione
progetto
1.1
Validazione
e collaudo
1.7
Documenta-
zione
1.6
Sviluppo
applicazione
MVC
1.5
Progettazione
del database
1.4
Strumenti
di sviluppo
1.3
Raccolta
e analisi
dei requisiti
1.2
Clients
(

44. ›Š–Ž)
1.5.3
Controller/View
( Ž›Ÿ • Ž Ȧ

45. )
1.5.2
Model
(

46. ŠŸŠ ŽŠ—œ)
1.5.1
Schema
fisico
1.4.3
Progettazione
logica
1.4.2
Progettazione
concettuale
1.4.1
e-Val
1
 Scelta dei tools di
sviluppo
 Approfondimento
del DBMS MySQL
 Acquisizione di
competenze su
Java2
 Acquisizione di
competenze su
JavaServer Pages
e Servlet
 Installazione di
Apache Tomcat,
MySQL, J2SE,
Forte for Java
 Definizione
della WBS
 Determina-
zione delle
scadenze
 Assegna-
zione dei
tempi alle
attività
 Requisiti
software
 Requisiti
hardware
 Analisi dei
vincoli
 Realizzazione
dello schema
Entità-Relazione
 Stesura del
dizionario dei dati
 Individuazione
delle cardinalità
 Scelta delle chiavi
 Stesura della
tavola dei volumi
 Stesura della
tavola delle
operazioni
 Stesura delle
tavole degli
accessi
 Ristrutturazione
dello schema
Entità-Relazione
 Scelta degli
identificatori
principali
 Traduzione nello
schema logico
 Verifica delle
forme normali
 Scrittura dei
comandi SQL per
la creazione della
base di dati
 Scelta degli indici
 Assegnazione
delle
autorizzazioni agli
utenti
 Stesura della
documentazione
del progetto
 Scrittura dei
manuali
 Traduzione
dell'help in linea
 Stesura della tesi
 Verifica della
correttezza delle
procedure di
inserimento e
modifica dei dati
 Controllo della
robustezza
dell'applicazione
 Verifica delle
prestazioni del
DBMS
 Installazione delle
applicazioni
 Popolamento della
base di dati
 Formazione
dell'amministratore
della base di dati
 Progettazione
dei bean di
interfacciamento
con la base di
dati
 Realizzazione
delle procedure
di inserimento e
aggiornamento
del database
 Realizzazione
delle procedure
di cancellazione
dal database
preservando
l'integrità
referenziale
 Intercettazione e
mappatura delle
richieste dei clients
 Controllo dei diritti
per gli accessi degli
utenti
 Gestione delle
connessioni con il
database
 Aggiornamento dello
stato del database
 Realizzazione delle
pagine dinamiche
(JSP)
 Creazione dei fogli di
stile (CSS)
 Realizzazione delle
procedure JavaScript
 Realizzazione del
client studente per
lo svolgimento
dell'esame
 Realizzazione del
client docente per
l'inserimento e la
modifica dei
quesiti
 Progettazione del
parser per l'analisi
dei quesiti da
inserire
Figura 4.2: Work Breakdown Structure del progetto.

47. 36 Piano di progetto

48. Capitolo 5
Progettazione della base di dati
La progettazione di una base di dati inizia dalla progettazione concettuale che ha lo scopo
di tradurre il risultato dell’analisi dei requisiti in una descrizione formale e integrata degli
aspetti strutturali e dinamici del sistema, rappresentando i dati in modo indipendente dalle
applicazioni di implementazione della base di dati. Il risultato di questa fase progettuale
`e rappresentato dallo schema Entit`a–Relazione (ER) accompagnato dal Dizionario dei
dati che ne descrive in modo informale le entit`a e le relazioni. A questo punto lo schema va
ristrutturato per adattarlo alla traduzione verso un modello logico; vengono quindi analizzate
le eventuali ridondanze, eliminate le generalizzazioni e vengono scelti gli identificatori primari
(o chiavi), cio`e quegli attributi di un’entit`a che ne identificano univocamente le occorrenze.
La fase successiva `e la progettazione logica che ha lo scopo di tradurre lo schema ER in
uno schema logico tenendo in considerazione l’implementazione della base di dati (nella fat-
tispecie il modello relazionale) e il carico applicativo, inteso come dimensioni dei dati e carat-
teristiche delle operazioni. A questo schema si accompagnano le descrizioni delle operazioni
che si devono svolgere sui dati e le eventuali tavole degli accessi.
La qualit`a dello schema di una base di dati relazionale `e “certificata” da alcune propriet`a
dette forme normali. Il rispetto di tali propriet`a assicura che lo schema relazionale abbia
caratteristiche di qualit`a che garantiscono in particolare che il suo uso non creer`a una base di
dati soggetta ad anomalie di aggiornamento. Spesso le tecniche sopraesposte producono gi`a
schemi che sono in forma normale, per`o comunque la normalizzazione `e utile perch´e costituisce
uno strumento di verifica e che pu`o suggerire ulteriori migliorie.
L’ultima fase progettuale prevede l’implementazione dello schema logico per lo specifi-
co DBMS (MySQL), producendo lo schema fisico, cio`e le istruzioni SQL che permettono
di creare le tabelle necessarie; in questa fase si analizzano anche delle strategie per incre-
mentare le prestazioni, se fosse necessario, ricorrendo all’uso degli indici secondari che con-
sentono l’accesso efficiente ai dati e possono essere usati assieme agli indici primari definiti
automaticamente sugli identificatori principali.
Come si pu`o notare la progettazione prevede diverse fasi che gradualmente vanno dalla
massima astrazione dello scema ER fino alla definizione delle tabelle per mezzo di comandi
SQL (cfr. [2] e [3]).

49. 38 Progettazione della base di dati
5.1 Progettazione concettuale: lo schema Entit`a–Relazione
Lo schema concettuale del progetto ricavato analizzando i requisiti, le entit`a che apparten-
gono alla realt`a da modellare (appelli d’esame, studenti, corsi, iscrizioni, ecc.) e le relazioni
che legano queste entit`a, sono presentati in figura 5.1. I costrutti utilizzati dal modello ER
sono i seguenti:
Entit`a rappresentano classi di oggetti (per esempio studente,
corso, esame) che hanno propriet`a comuni ed esistenza
“autonoma” ai fini dell’applicazione;
Relazioni
(m1
,M1
) (m2
,M2
)
rappresentano legami logici significativi, per l’applicazione
di interesse, tra due o pi`u entit`a; vengono specificate anche
le cardinalit`a che indicano il numero minimo e massimo
di occorrenze di relazione cui una occorrenza dell’entit`a
pu`o partecipare (per esempio l’iscrizione di uno studente
ad un esame `e una relazione tra l’esame e lo studente, in
cui lo studente partecipa con cardinalit`a (1,N) cio`e pu`o
iscriversi ad uno o pi`u esami, mentre l’esame partecipa con
cardinalit`a (0,N) cio`e pu`o avere come iscritti pi`u di uno
studente come anche nessuno);
Attributi descrivono le propriet`a elementari di entit`a o relazioni;
Attributi composti sono dei raggruppamenti di attributi di una medesima
entit`a o relazione che presentano affinit`a nel loro significato;
Identificatori interni vengono specificati per ciascuna entit`a di uno schema e
descrivono i concetti (attributi o entit`a) dello schema che
permettono di identificare in maniera univoca le occorrenze
delle entit`a.

50. 5.1 Progettazione concettuale: lo schema Entit`a–Relazione 39
COURSE
Name
Password
Teacher
Login
Answer
(0,N)
Content
(0,N)
TimeValue
Composition
(0,N)
AddedValueQuestionOrder
(0,N)
Registration
(0,N)
Date
(1,N)
QUESTION
AnswerTypeCorrector
MemorandumComment
RightAnswerDifficulty
TextInsertionDate
(0,N)
TEST
CreationDate
Title
Template
Sorting
Assignment
(1,1)
ExamGroup
(0,N) PasswordDate
Difficulty
Execution(0,N)
MaxLengthClientName
CodeCurrentQuestion
Start
(0,N)
EndResult
STUDENT
Matricula
InsertionDate
Name
Surname
ATTACHMENT
Content
IDAttachment
Contents
EXAM
MaxStudentGroup
ExamDate
Comment
Active
Length
Name
StudentOrder
ARGUMENT
Description
Name
Subject
Kind
Testing
Belonging
Doing Happening
(1,1)
(0,N) (1,1)
Name
Password
Teacher
Login
Password
Login
(0,N)
(1,N)
(0,N)
(0,N)
(0,N)
(1,1)
(0,N) (0,N)
(1,1)
(1,1)
(1,1) (0,N)
Code
ACTION
TimeParameters
CodeType
Figura 5.1: Schema concettuale del progetto (schema Entit`a–Relazione).

51. 40 Progettazione della base di dati
Descrizione entit`a Attributi
Question: Domanda
d’esame che verte su uno
degli argomenti del corso
Text (contenuto in formato HTML del quesito), Memorandum
(nome che identifica il quesito), RightAnswer (risposta corretta
del quesito), AnswerType (tipologia di risposta: a scelta multipla,
valore numerico, aperta), Difficulty (difficolt`a del quesito in base
alle risposte date dagli studenti), Corrector (tipo di correttore
automatico), Comment (commento al quesito: es. spiegazioni sul
metodo di risoluzione), InsertionDate (data di inserimento)
Identificatori: Memorandum, Argument
Test: Compito d’esame
formato da pi`u quesiti e
che pu`o essere sottoposto
agli studenti
Title (titolo del compito), Template (specifica se il compito `e stato
creato dal docente oppure in modo automatico), Sorting (ordina-
mento dei quesiti nel compito: pu`o essere casuale oppure deciso
dal docente), Difficulty (difficolt`a del compito come media delle
difficolt`a dei singoli quesiti), CreationDate (data di creazione)
Identificatori: Title, Course
Student: Studente che
ha sostenuto o che deve
sostenere un esame
Name (nome), Surname (cognome), Matricula (numero di matri-
cola che lo identifichi univocamente, InsertionDate
Identificatori: Matricula
Exam: Appello d’esame Name (nome dell’esame), Date (data dell’appello), Length (dura-
ta in minuti), Active (indica se `e attivo), StudentOrder (ordina-
mento degli studenti per dividerli in gruppi), MaxStudentGroup
(numero degli studenti per gruppo), Comment (messaggio mostra-
to allo studente prima dell’inizio dell’esame), AllowPartialAnswer
(indica se vanno corrette anche le risposte parziali), RightAnswer-
Value, NoAnswerValue, WrongAnswerValue (queste tre voci rap-
presentano i pesi da assegnare alle risposte corrette, errate oppure
non date), ScoreSlope, ScoreOffset (questi due valori determinano
la posizione della retta di conversione punteggi–voti)
Identificatori: Name, Date, Course
Attachment: Allega-
to contenuto nel testo
HTML della domanda d’e-
same (per esempio un’im-
magine)
Content (contenuto dell’oggetto), Code (codice di sicurezza)
Identificatori: IDAttachment
Argument: Materia del
corso che interessa nella
verifica della preparazione
Name (nome della materia trattata), Description (descrizione)
Identificatori: Name, Course
Course: Corso uni-
versitario tenuto da un
docente
Name (nome del corso), Teacher (nome del docente), Login (lo-
gin per l’accesso al sistema), Password (password codificata per
l’accesso del docente)
Identificatori: Name
Action: Azione che
compie lo studente du-
rante l’esame
Type (descrizione del tipo di azione), Code (identificatore della
sessione durante la quale `e stata compiuta l’azione), Parameters
(intestazione HTTP inviata dal client), Time (ora dell’azione)
Identificatori: Time, Exam, Student
Tabella 5.3: Dizionario dei dati: entit`a.

52. 5.1 Progettazione concettuale: lo schema Entit`a–Relazione 41
Descrizione relazione Entit`a coinvolte Attributi
Answer: risposta che lo
studente d`a alla domanda
durante l’esame
Student (0,N), Ex-
am (0,N), Question
(0,N)
Content (contenuto della risposta da-
ta), Value (valore compreso tra 0 e 1
che esprime il grado di correttezza della
risposta), Time (ora in cui lo studente
ha risposto
Composition: associa
il compito d’esame alle do-
mande che lo compongono
Question (0,N),
Test (1,N)
QuestionOrder (ordine predefinito dei
quesiti nel compito stabilito dal do-
cente), AddedValue (valore da aggiun-
gere al quesito durante la correzione)
Assignment: assegna il
compito allo studente che
lo deve svolgere durante
l’esame
Test (0,N), Student
(0,N), Exam (0,N)
Password (codice che viene chiesto al-
lo studente per poter svolgere l’esame),
ExamGroup (numero del gruppo di
appartenenza), Date
Execution: associa lo
studente all’esame a cui si
presenta
Student (0,N), Ex-
am (0,N)
Start (ora in cui lo studente inizia la
prova ), End (ora di fine della pro-
va), ClientName (nome del comput-
er su cui si trova lo studente), Code
(numero della sessione attuale dello
studente), MaxLength (duranta dell’e-
same), CurrentQuestion (numero d’or-
dine del quesito al quale sta rispon-
dendo lo studente), Result (voto della
prova)
Registration: associa
lo studente all’esame a cui
si iscrive
Student (1,N), Ex-
am (0,N)
Date (data di iscrizione)
Contents: associa l’al-
legato alla domanda a cui
appartiene
Attachment (1,1),
Question (0,N)
Subject: associa la do-
manda all’argomento che
tratta
Question (1,1), Ar-
gument (0,N)
Kind: associa la materia
al suo corso universitario
Argument (1,1),
Course (0,N)
Testing: associa il com-
pito d’esame al corso
Test (1,1), Course
(0,N)
Belonging: associa l’e-
same al corso universitario
Exam (1,1), Course
(0,N)
Doing: associa l’azione
allo studente che l’ha com-
piuta
Action (1,1), Stu-
dent (0,N)
Happening: associa
l’azione all’esame durante
il quale `e accaduta
Action (1,1), Exam
(0,N)
Tabella 5.5: Dizionario dei dati: relazioni.

53. 42 Progettazione della base di dati
Le tabelle 5.3 e 5.5 costituiscono il dizionario dei dati diviso in entit`a e relazioni: spiegano
quali siano i significati degli elementi usati nel modello ER per rappresentare la realt`a che si
stanno analizzando.
Da una prima analisi lo schema concettuale risulta
• corretto perch´e utilizza propriamente i costrutti messi a disposizione dal modello ER,
• completo perch´e rappresenta tutti i dati di interesse,
• leggibile perch´e rappresenta i requisiti in modo naturale e facilmente comprensibile,
• non minimale cio`e non tutte le specifiche sui dati sono rappresentate una sola vol-
ta, per esempio Question.Difficulty, Assignment.ExamGroup e Execution.Result;
l’attributo Execution.MaxLength viene inizializzato con il valore di Exam.Length e pu`o
essere modificato per permettere agli amministratori, in caso di arresto imprevisto del
server, di far terminare il compito agli studenti che lo stavano svolgendo, “allungando”
il tempo a loro disposizione.
La tabella 5.6 mostra invece le regole di vincolo e di derivazione non espresse nello schema
ER e che devono invece essere sempre soddisfatte dai dati.
5.2 Schema logico
Per arrivare ad ottenere lo schema logico bisogna prima modificare lo schema ER, tenendo
conto del carico applicativo previsto in termini di dimensioni dei dati e caratteristiche delle
operazioni. Per questo `e stata compilata una tavola dei volumi (vedi tabella 5.7) che stima
il numero di occorrenze delle varie entit`a e relazioni. Le operazioni previste sono le seguenti
(tra parentesi la stima della frequenza e il tipo di operazione – B indica le operazioni che
deve eseguire automaticamente il sistema, I indica le operazioni che prevedono l’interazione
con l’utente):
• per il docente e l’amministratore:
1. Controllare l’autenticazione del docente (I–150/anno)
2. Inserire un nuovo quesito vuoto (I–150/anno)
3. Inserire o modificare un quesito (I–160/anno)
4. Inserire un allegato (B–70/anno)
5. Visualizzare e modificare il codice HTML sorgente di un quesito (I–30/anno)
6. Visualizzare un quesito e le risposte esatte (I–non stimabile)
7. Inserire, modificare e cancellare un corso (I–non stimabile)
8. Modificare la login di accesso del docente al corso (I–non stimabile)
9. Inserire, modificare e cancellare un argomento di un corso (I–non stimabile)
10. Inserire, modificare e cancellare un appello d’esame (I–25/anno)

54. 5.2 Schema logico 43
Regole di vincolo
RV1 Se un esame non `e attivo (cio`e Exam.Active `e ‘no’) non `e possibile inserire
risposte a quesiti (Answer), iniziare lo svolgimento dell’esame (Execution) o
inserire un’azione (Action) per quell’esame
RV2 Se un esame `e attivo (cio`e Exam.Active `e ‘yes’) non possono essere modificati
le assegnazioni dei compiti agli studenti (cio`e Assignment) e i compiti stessi
(cio`e Test, Composition, Question)
RV3 Non possono venire inserite risposte date dallo studente dopo che `e trascor-
so il tempo a disposizione per svolgere l’esame (cio`e Answer.Time non deve
superare Execution.Start aumentato di Execution.MaxLength minuti)
Regole di derivazione
RD1 La difficolt`a di un compito (Test.Difficulty) viene calcolata come la media
delle difficolt`a dei singoli quesiti nel momento in cui viene creato o modificato
il compito
RD2 La difficolt`a di un quesito (Question.Difficulty) viene calcolata dividendo
il numero delle risposte corrette per il numero di volte che quel quesito `e stato
proposto ad uno studente
RD3 Il gruppo di appartenenza di uno studente viene calcolato partizionando la lista
degli studenti ordinata secondo Exam.StudentOrder, con il numero contenuto
in Exam.MaxStudentGroup
RD4 Il risultato della correzione di un compito espresso in trentesimi viene cal-
colato convertendo il punteggio in centesimi (si moltiplica il punteggio per
Exam.ScoreSlope e si somma Exam.ScoreOffset); il punteggio in centesimi
`e la media dei punteggi assegnati alle risposte esatte, a quelle sbagliate e a
quelle non date aumentato di un eventuale valore relativo a qualche quesi-
to (Composition.AddedValue); il punteggio assegnato per una risposta esat-
ta `e Exam.RightAnswerValue, per una sbagliata `e Exam.WrongAnswerValue
mentre per una non data `e Exam.NoAnswerValue
Tabella 5.6: Regole non espresse nello schema ER; in particolare le regole di
derivazione descrivono come certi concetti siano derivabili da altri mediante
il calcolo aritmetico.
11. Verificare se un esame sia gi`a in corso di svolgimento (B–30/anno)
12. Attivare e disattivare un esame (I–40/anno)
13. Calcolare i voti conseguiti dagli studenti ad un esame (I–50/anno)
14. Verificare se un compito `e gi`a stato dato ad un esame (B–10/anno)
15. Inserire, modificare e cancellare un compito d’esame (I–100/anno)
16. Duplicare un compito (I–10/anno)
17. Calcolare la difficolt`a di un compito (B–100/anno)
18. Aggiungere una domanda ad un compito (I–850/anno)

55. 44 Progettazione della base di dati
Concetto Tipo Volume
Question E 400
Test E 70/anno
Student E 300/anno
Exam E 20/anno
Attachment E 150
Argument E 30
Course E 3
Action E 1200/anno
Answer R 3000/anno
Composition R 850/anno
Assignment R 350/anno
Execution R 300/anno
Registration R 350/anno
Contents R 150
Subject R 400
Kind R 30
Testing R 70/anno
Belonging R 20/anno
Doing R 1200/anno
Happening R 1200/anno
Tabella 5.7: Tavola dei volumi; si nota come la relazione Answer sia quella con
il maggior numero di occorrenze.
19. Rimuovere un quesito da un compito (I–80/anno)
20. Aggiungere un punteggio, uguale per tutti gli studenti) ad una domanda di un
compito (I–non stimabile)
21. Aggiornare l’ordine di visualizzazione dei quesiti nel compito (I–10/anno)
22. Assegnare i compiti agli studenti iscritti ad un esame (B–20/anno)
23. Modificare la risposta corretta di un quesito (I–non stimabile)
24. Correggere manualmente la risposta data da uno studente (I–non stimabile)
25. Modificare i parametri dello schema di correzione (I–50/anno)
26. Correggere di nuovo automaticamente le risposte degli studenti (B–non stimabile)
27. Controllare che non ci siano risposte aperte non corrette dall’applicazione (B–
50/anno)
28. Cancellare definitivamente un quesito dal database che non sia usato in un compito
(I–non stimabile)
29. Calcolare la difficolt`a di un quesito (B–850/anno)
30. Spostare dei quesiti da un argomento ad un altro (I–non stimabile)

56. 5.2 Schema logico 45
31. Reperire il tipo di risposta di un quesito (B–non stimabile)
32. Reperire un allegato di un quesito (B–non stimabile)
33. Iscrivere uno studente ad un esame (I–350/anno)
34. Cancellare l’iscrizione ad un esame di uno studente (I–non stimabile)
35. Visualizzare la lista dei corsi inseriti nel database (I–non stimabile)
36. Visualizzare un quesito (I–non stimabile)
37. Visualizzare le liste degli esami, dei compiti e degli argomenti di un corso (I–
150/anno)
38. Visualizzare per la modifica un corso, un argomento, un esame, un compito o un
quesito (I–non stimabile)
39. Visualizzare per esteso i quesiti che trattano lo stesso argomento (I–non stimabile)
40. Visualizzare la tabella dei risultati di un appello d’esame (I–20/anno)
41. Visualizzare la tabella degli studenti iscritti ad un appello d’esame con le relative
password d’accesso (I–20/anno)
42. Visualizzare per esteso il compito dato ad uno studente (I–non stimabile)
43. Visualizzare per esteso un compito (I–non stimabile)
44. Visualizzare gli esiti di un esame con la possibilit`a di modificare lo schema di
correzione (I–50/anno)
45. Visualizzare l’esito dell’esame di uno studente con la possibilit`a di correggere
manualmente le risposte (I–non stimabile)
46. Visualizzare la lista delle domande presenti in un compito (I–non stimabile)
• per lo studente:
47. Inserire un’azione compiuta dallo studente (B–1200/anno)
48. Controllare l’autenticazione dello studente (I–350/anno)
49. Memorizzare l’inizio della prova d’esame di uno studente (I–350/anno)
50. Calcolare il tempo rimanente per lo svolgimento dell’esame (B–140000/anno)
51. Calcolare il prossimo quesito da mostrare allo studente (B–10500/anno)
52. Salvare la risposta data da uno studente (I–3000/anno)
53. Memorizzare il ritiro dall’esame di uno studente (I–50/anno)
54. Memorizzare la conclusione dell’esame da parte di uno studente (I–300/anno)
55. Visualizzare il quesito da sottoporre ad uno studente (I–10500/anno)
56. Reperire l’allegato di un quesito (B–5000/anno)
5.2.1 Ristrutturazione dello schema ER
La ristrutturazione dello schema ER prevede di analizzare le ridondanze al fine di eliminarle
e di scegliere gli identificatori primari.

57. 46 Progettazione della base di dati
COURSE
IDCourse
Answer
(0,N)
Composition
(0,N)
(0,N)
Registration (0,N)(1,N)
QUESTION IDQuestion
(0,N)
TEST
Assignment
(1,1)
(0,N)
IDTest
Execution
(0,N) (0,N)
STUDENT
IDStudent
ATTACHMENT
IDAttachment
Contents
EXAM
IDExam
ARGUMENT
IDArgument
Subject
KindTesting
Belonging
Doing
Happening
(1,1)
(0,N) (1,1)
(0,N)
(1,N)
(0,N)
(0,N)
(0,N)
(1,1)
(0,N)
(0,N)(1,1)
(1,1)
(1,1)
(0,N)
ACTIONTime
Figura 5.2: Schema concettuale ristrutturato con l’aggiunta degli indici
IDQuestion, IDArgument, IDCourse, IDTest, IDStudent e IDExam; nello
schema sono stati evidenziate solamente gli identificatori primari, omettendo
gli altri attributi, per facilitare la leggibilit`a.
Analisi delle ridondanze Come anticipato nella sezione 5.1 a proposito della minimalit`a
dello schema concettuale e come si deduce dalle regole di derivazione della tabella 5.6, esistono
delle ridondanze che si `e deciso di lasciare, soprattutto per motivi di efficienza e semplificazione
delle procedure:
• il calcolo di Question.Difficulty necessario per esempio quando si vuole calcolare la
difficolt`a di un compito (circa 100 volte all’anno) richiederebbe la scansione e il calcolo
della media di circa 3600 risposte per anno di utilizzo, mediante l’uso di una query
abbastanza complessa (MySQL non supporta le query annidate);
• il calcolo di Assignment.ExamGroup non `e agevole da eseguire con una query e richiede
invece una routine scritta in Java, da eseguire contestualmente all’assegnazione dei
compiti agli studenti;
• Execution.Result si `e duplicata per tenere traccia anche degli eventuali studenti che

58. 5.3 Schema fisico 47
si ritirano dall’esame.
Scelta degli identificatori principali Le chiavi delle entit`a che si sono scelte non sono
tutte adatte a diventare degli identificatori principali per il successivo schema logico; infatti:
• l’occupazione di memoria sarebbe troppo grande e rallenterebbe soprattutto le operazio-
ni SQL di join, basti solamente pensare all’attributo Exam.Name (che ha un’occupazione
di memoria di qualche centinaio di byte) che compare nelle chiavi di Answer (3000 oc-
correnze all’anno), Action (1200 occorrenze all’anno) e Registration (350 occorrenze
all’anno);
• il DBMS (MySQL) su cui verr`a implementata la base di dati non aggiorna i cambiamenti
degli identificatori principali nelle tabelle referenziate, rendendo quasi impossibile il
cambiamento del valore di attributi importanti quali Argument.Name e Test.Title; ci`o
d`a origine alle cosiddette anomalie di aggiornamento.
Per questi motivi sono stati aggiunti degli attributi contenenti dei codici identificativi come
chiavi principali delle entit`a, sostituendo quelle scelte precedentemente che comunque riman-
gono delle chiavi secondarie.
A questo punto la ristrutturazione dello schema ER `e completa come si vede nella figura
5.2 che tradotto diventa lo schema logico di figura 5.3; in particolare le relazioni molti a
molti dello schema ER, cio`e quelle con molteplicit`a N sia a sinistra che a destra, diventano
tabelle che hanno, come attributi, gli attributi della relazione e, come chiave principale, quella
formata dall’unione delle chiavi principali delle entit`a che unisce.
5.2.2 Verifica delle forme normali
La qualit`a dello schema di una base di dati relazionale `e “certificata” da alcune propriet`a
dette forme normali; il rispetto di tali propriet`a assicura che lo schema relazionale abbia
caratteristiche di qualit`a che garantiscono, in particolare, che il suo uso non creer`a una base
di dati soggetta ad anomalie di aggiornamento (si veda [2]).
Lo schema relazionale `e sicuramente in Prima Forma Normale, poich´e tutti gli attributi
di tutte le relazioni contengono solamente valori atomici. La Seconda Forma Normale `e
verificata poich´e per ogni relazione non esistono dipendenze funzionali tra alcuni attributi che
compongono la chiave primaria e alcuni degli altri attributi non primi. Lo schema soddisfa
anche la Terza Forma Normale, se si escludono le dipendenze funzionali dovute all’aggiunta
dei codici che fungono da identificatori principali, poich´e tutti gli attributi non primi sono
mutuamente indipendenti, cio`e non esistono dipendenze funzionali fra di essi.
5.3 Schema fisico
Dallo schema logico ricavato nella sezione precedente si passa a scrivere la sequenza di comandi
SQL che definiscono lo schema della base di dati; in particolare prendendo d’esempio la tabella
dei quesiti (Question) `e necessario:

59. 48 Progettazione della base di dati
IDStudent IDExamIDQuestion TimeValueContent
Answer
IDArgumentIDQuestion
Question
Memorandum Text RightAnswer
AnswerType Corrector Difficulty
InsertionDate Comment
IDAttachment
IDQuestion
CodeContent
Attachment
IDCourseIDArgument
Argument
Name Description
Student
IDStudent Matricula
Name Surname
InsertionDate
IDTestIDQuestion
Composition
QuestionOrder AddedValue
Course
IDCourse Name
Teacher Login
Password
IDExamIDStudent
Execution
Start End Code
ClientName MaxLength
CurrentQuestion Result
IDExamIDStudent
Assignment
Password ExamGroup Date
IDTest
IDCourseIDTest
Test
Title IDCourse
Difficulty Template
Sorting
IDCourseIDExam
Exam
Name ExamDate Length Active
StudentOrder MaxStudentGroup
RightAnswerValue NoAnswerValue
WrongAnswerValue ScoreSlope
ScoreOffset AllowPartialAnswer
Comment
IDExamIDStudent
Registration
RegistrationDate
IDExamIDStudent
Action
Time Code Type
Parameters
Figura 5.3: Schema logico derivante dalla traduzione delllo schema ER
ristrutturato.
• definire i domini per ogni attributo di ogni tabella e gli eventuali relativi vincoli di
integrit`a (DEFAULT, NOT NULL, ecc.):
CREATE TABLE Question (
2 IDQuestion INT NOT NULL AUTO_INCREMENT ,

60. 5.3 Schema fisico 49
Memorandum VARCHAR (250) NOT NULL ,
4 IDArgument INT NOT NULL ,
Text MEDIUMTEXT ,
6 RightAnswer VARCHAR (200) ,
AnswerType VARCHAR (40) NOT NULL ,
8 Corrector VARCHAR (40) DEFAULT ’AnswerMatch ’ NOT NULL ,
Difficulty FLOAT ,
10 InsertionDate DATETIME ,
Comment TEXT ,
• definire i vincoli di integrit`a intrarelazionale cio`e le chiavi primarie e secondarie:
12 PRIMARY KEY ( IDQuestion),
UNIQUE ( Memorandum , IDArgument),
• definire i vincoli di integrit`a interrelazionale cio`e i vincoli diintegrit`a referenziale
ovvero le chiavi esterne, anche se MySQL non le implementa e quindi non le terr`a in
considerazione:
14 FOREIGN KEY ( IDArgument ) REFERENCES Argument ON DELETE SET NULL );
La definizione completa dello schema della base di dati `e:
CREATE DATABASE eVal;
USE eVal;
CREATE TABLE Question (
IDQuestion INT NOT NULL AUTO_INCREMENT,
Memorandum VARCHAR(250) NOT NULL,
IDArgument INT NOT NULL,
Text MEDIUMTEXT,
RightAnswer VARCHAR(200),
AnswerType VARCHAR(40) NOT NULL,
Corrector VARCHAR(40) DEFAULT ’AnswerMatch’ NOT NULL,
Difficulty FLOAT,
InsertionDate DATETIME,
Comment TEXT,
PRIMARY KEY (IDQuestion),
UNIQUE (IDQuestion),
UNIQUE (Memorandum, IDArgument),
#INDEX (Memorandum, IDArgument),
#INDEX (IDArgument),
#INDEX (Difficulty),
FOREIGN KEY (IDArgument) REFERENCES Argument ON DELETE SET NULL);
CREATE TABLE Argument (
IDArgument INT NOT NULL AUTO_INCREMENT,
Name VARCHAR(250) NOT NULL,

61. 50 Progettazione della base di dati
IDCourse MEDIUMINT NOT NULL,
Description VARCHAR(250),
Timestamp TIMESTAMP,
PRIMARY KEY (IDArgument),
UNIQUE (IDArgument),
UNIQUE (Name, IDCourse),
#INDEX (Name, IDCourse),
#INDEX (IDCourse),
FOREIGN KEY (IDCourse) REFERENCES Course ON DELETE SET NULL);
CREATE TABLE Course (
IDCourse MEDIUMINT NOT NULL AUTO_INCREMENT,
Name VARCHAR(250),
Teacher VARCHAR(100),
Login CHAR(16) NOT NULL,
Password CHAR(16) NOT NULL,
Timestamp TIMESTAMP,
PRIMARY KEY (IDCourse),
UNIQUE (IDCourse),
UNIQUE (Name),
#INDEX (Name),
UNIQUE (Login, Password)
#INDEX (Login, Password)
);
CREATE TABLE Attachment (
IDAttachment INT NOT NULL AUTO_INCREMENT,
IDQuestion INT NOT NULL,
Content MEDIUMBLOB,
Code SMALLINT NOT NULL,
Timestamp TIMESTAMP,
PRIMARY KEY (IDAttachment),
UNIQUE (IDAttachment),
#INDEX (IDQuestion),
FOREIGN KEY (IDQuestion) REFERENCES Question ON DELETE CASCADE);
CREATE TABLE Test (
IDTest INT NOT NULL AUTO_INCREMENT,
Title VARCHAR(250) NOT NULL,
IDCourse MEDIUMINT NOT NULL,
Difficulty FLOAT,
Template ENUM(’yes’,’no’) NOT NULL DEFAULT ’yes’,
Sorting ENUM(’default’,’random’)
NOT NULL DEFAULT ’random’,
CreationDate DATETIME,

62. 5.3 Schema fisico 51
PRIMARY KEY (IDTest),
UNIQUE (IDTest),
UNIQUE (Title, IDCourse),
#INDEX (Title, IDCourse),
#INDEX (IDCourse),
#INDEX (Difficulty),
#INDEX (Template),
FOREIGN KEY (IDCourse) REFERENCES Course ON DELETE SET NULL);
CREATE TABLE Student (
IDStudent INT NOT NULL AUTO_INCREMENT,
Matricula VARCHAR(16) NOT NULL,
Name VARCHAR(50),
Surname VARCHAR(50),
InsertionDate DATETIME,
PRIMARY KEY (IDStudent),
UNIQUE (IDStudent),
UNIQUE (Matricula)
#INDEX (Matricula),
);
CREATE TABLE Exam (
IDExam INT NOT NULL AUTO_INCREMENT,
Name VARCHAR(250) NOT NULL,
IDCourse MEDIUMINT NOT NULL,
ExamDate DATETIME NOT NULL,
Length INT NOT NULL,
Active ENUM(’yes’,’no’) NOT NULL DEFAULT ’no’,
StudentOrder VARCHAR(20) NOT NULL DEFAULT ’alphabetic’,
MaxStudentGroup SMALLINT NOT NULL DEFAULT 5,
RightAnswerValue FLOAT NOT NULL DEFAULT 1,
NoAnswerValue FLOAT NOT NULL DEFAULT 0.2,
WrongAnswerValue FLOAT NOT NULL DEFAULT 0,
ScoreSlope FLOAT NOT NULL DEFAULT 30,
ScoreOffset FLOAT NOT NULL DEFAULT 0,
AllowPartialAnswer ENUM(’yes’,’no’) NOT NULL DEFAULT ’yes’,
Comment TEXT,
Timestamp TIMESTAMP,
PRIMARY KEY (IDExam),
UNIQUE (IDExam),
UNIQUE (Name, IDCourse, ExamDate),
#INDEX (Name, IDCourse, ExamDate),
#INDEX (IDCourse),
#INDEX (ExamDate),
#INDEX (Active),
FOREIGN KEY (IDCourse) REFERENCES Course ON DELETE SET NULL);
CREATE TABLE Answer (
IDStudent INT NOT NULL,
IDQuestion INT NOT NULL,

63. 52 Progettazione della base di dati
IDExam INT NOT NULL,
Content TEXT,
Value FLOAT,
Time DATETIME NOT NULL,
PRIMARY KEY (IDStudent, IDQuestion, IDExam),
UNIQUE (IDStudent, IDQuestion, IDExam),
#INDEX (IDQuestion),
#INDEX (IDExam),
FOREIGN KEY (IDStudent) REFERENCES Student ON DELETE CASCADE,
FOREIGN KEY (IDQuestion) REFERENCES Question ON DELETE CASCADE,
FOREIGN KEY (IDExam) REFERENCES Exam ON DELETE CASCADE);
CREATE TABLE Composition (
IDTest INT NOT NULL,
IDQuestion INT NOT NULL,
QuestionOrder SMALLINT NOT NULL,
AddedValue FLOAT NOT NULL DEFAULT 0,
Timestamp TIMESTAMP,
PRIMARY KEY (IDTest, IDQuestion),
UNIQUE (IDTest, IDQuestion),
#INDEX (IDQuestion),
FOREIGN KEY (IDTest) REFERENCES Test ON DELETE CASCADE,
FOREIGN KEY (IDQuestion) REFERENCES Question ON DELETE CASCADE);
CREATE TABLE Assignment (
IDStudent INT NOT NULL,
IDExam INT NOT NULL,
IDTest INT NOT NULL,
Password VARCHAR(16) NOT NULL,
ExamGroup SMALLINT NOT NULL,
Date DATE,
PRIMARY KEY (IDStudent, IDExam),
UNIQUE (IDStudent, IDExam),
UNIQUE (IDStudent, Password),
UNIQUE (IDExam, IDTest),
#UNIQUE (IDStudent, IDTest),
#INDEX (IDExam),
FOREIGN KEY (IDStudent) REFERENCES Student ON DELETE CASCADE,
FOREIGN KEY (IDTest) REFERENCES Test ON DELETE NO ACTION,
FOREIGN KEY (IDExam) REFERENCES Exam ON DELETE NO ACTION);
CREATE TABLE Execution (
IDStudent INT NOT NULL,
IDExam INT NOT NULL,
Start DATETIME,
End DATETIME,
Code VARCHAR(100) NOT NULL,
ClientName VARCHAR(150),

64. 5.3 Schema fisico 53
CurrentQuestion SMALLINT NOT NULL DEFAULT 1,
MaxLength INT NOT NULL,
Result VARCHAR(10),
PRIMARY KEY (IDStudent, IDExam),
UNIQUE (IDStudent, IDExam),
#INDEX (IDExam),
FOREIGN KEY (IDStudent) REFERENCES Student ON DELETE CASCADE,
FOREIGN KEY (IDExam) REFERENCES Exam ON DELETE NO ACTION);
CREATE TABLE Registration (
IDStudent INT NOT NULL,
IDExam INT NOT NULL,
RegistrationDate DATE,
PRIMARY KEY (IDStudent, IDExam),
UNIQUE (IDStudent, IDExam),
#INDEX (IDExam),
FOREIGN KEY (IDStudent) REFERENCES Student ON DELETE CASCADE,
FOREIGN KEY (IDExam) REFERENCES Exam ON DELETE NO ACTION);
CREATE TABLE Action (
IDStudent INT NOT NULL,
IDExam INT NOT NULL,
Time DATETIME NOT NULL,
Code VARCHAR(50) NOT NULL, #see Execution
Type VARCHAR(50),
Parameters TINYTEXT,
PRIMARY KEY (IDStudent, IDExam, Time),
UNIQUE (IDStudent, IDExam, Time),
#INDEX (IDExam),
#INDEX (Time),
FOREIGN KEY (IDStudent) REFERENCES Student ON DELETE CASCADE,
FOREIGN KEY (IDExam) REFERENCES Exam ON DELETE NO ACTION);

65. 54 Progettazione della base di dati
EVAL -- e-Val: Schema fisico / Main Subject Area
1, 1 / 1, 1 -- 14.33.30 , 25/01/2003
Question
IDQUESTION: INT
MEMORANDUM: VARCHAR(250)
IDARGUMENT: INT
TEXT: MEDIUMTEXT
RIGHTANSWER: VARCHAR(200)
ANSWERTYPE: VARCHAR(40)
CORRECTOR: VARCHAR(40)
DIFFICULTY: FLOAT
INSERTIONDATE: DATETIME
COMMENT: TEXT
Argument
IDARGUMENT: INT
NAME: VARCHAR(250)
IDCOURSE: MEDIUMINT
DESCRIPTION: VARCHAR(250)
TIMESTAMP: TIMESTAMP
Course
IDCOURSE: MEDIUMINT
NAME: VARCHAR(250)
TEACHER: VARCHAR(100)
LOGIN: CHAR(16)
PASSWORD: CHAR(16)
TIMESTAMP: TIMESTAMP
Attachment
IDATTACHMENT: INT
IDQUESTION: INT (FK)
CONTENT: MEDIUMBLOB
CODE: SMALLINT
TIMESTAMP: TIMESTAMP
Test
IDTEST: INT
TITLE: VARCHAR(250)
IDCOURSE: MEDIUMINT (FK)
DIFFICULTY: FLOAT
TEMPLATE: VARCHAR(10)
SORTING: VARCHAR(10)
CREATIONDATE: DATETIME
Student
IDSTUDENT: INT
MATRICULA: VARCHAR(16)
NAME: VARCHAR(50)
SURNAME: VARCHAR(50)
INSERTIONDATE: DATETIME
Exam
IDEXAM: INT
NAME: VARCHAR(250)
IDCOURSE: MEDIUMINT (FK)
EXAMDATE: DATETIME
LENGTH: INT
ACTIVE: VARCHAR(10)
STUDENTORDER: VARCHAR(20)
MAXSTUDENTGROUP: SMALLINT
RIGHTANSWERVALUE: FLOAT
NOANSWERVALUE: FLOAT
WRONGANSWERVALUE: FLOAT
SCORESLOPE: FLOAT
SCOREOFFSET: FLOAT
ALLOWPARTIALANSWER: VARCHAR(10)
COMMENT: TEXT
TIMESTAMP: TIMESTAMP
Answer
IDSTUDENT: INT (FK)
IDQUESTION: INT (FK)
IDEXAM: INT (FK)
CONTENT: TEXT
VALUE: FLOAT
TIME: DATETIME
Composition
IDTEST: INT (FK)
IDQUESTION: INT (FK)
QUESTIONORDER: SMALLINT
ADDEDVALUE: FLOAT
TIMESTAMP: TIMESTAMP
Assignment
IDSTUDENT: INT (FK)
IDEXAM: INT (FK)
IDTEST: INT (FK)
PASSWORD: VARCHAR(16)
EXAMGROUP: SMALLINT
DATE: DATE
Execution
IDSTUDENT: INT (FK)
IDEXAM: INT (FK)
START: DATETIME
END: DATETIME
CODE: VARCHAR(100)
CLIENTNAME: VARCHAR(150)
CURRENTQUESTION: SMALLINT
MAXLENGTH: INT
RESULT: VARCHAR(10)
Registration
IDSTUDENT: INT (FK)
IDEXAM: INT (FK)
REGISTRATIONDATE: DATE
Action
IDSTUDENT: INT (FK)
IDEXAM: INT (FK)
TIME: DATETIME
CODE: VARCHAR(50)
TYPE: VARCHAR(50)
PARAMETERS: TINYTEXT
Figura 5.4: Schema fisico realizzato con il programma ERwin, uno strumen-
to CASE (Computer Aided Software Engineering) per la progettazione di
database mediante l’uso di schemi ER.

66. 5.3 Schema fisico 55
5.3.1 Utenti e sicurezza
`E buona norma stabilire le politiche per il controllo dell’accesso, da mettere in atto con i
meccanismi di protezione di MySQL che si basano su:
• l’identificazione dell’utente che si collega alla base di dati, eventualmente con una
password, con il controllo anche del nome del computer da cui si connette;
• i privilegi di accesso alle risorse che possono essere l’inserimento, la modifica, la cancel-
lazione e altri;
• le risorse per le quali si possono concedere o meno privilegi e che possono essere l’intera
base di dati, singole tabelle e addirittura singole colonne.
Poich´e l’accesso alla base di dati avverr`a esclusivamente dal server Web Tomcat, installato
sullo stesso computer di MySQL, le connessioni al database partiranno solo da localhost; in
particolare saranno tre i servlet dell’applicazione che avranno bisogno dei diritti di accesso al
database:
• il servlet che soddisfa alle richieste dello studente che sta svolgendo l’esame, di seguito
identificato con Student; i comandi SQL
GRANT SELECT ON eVal .* TO Student@localhost
GRANT INSERT , UPDATE ON Action TO Student@localhost
GRANT INSERT , UPDATE ON Execution TO Student@localhost
GRANT INSERT , UPDATE ON Answer TO Student@localhost
definiscono i privilegi che il servlet deve possedere per poter eseguire con successo le
operazioni sulla base di dati definite nella sezione 5.2, pi`u precisamente quelle dalla 47
alla 55;
• il servlet che soddisfa alle richieste del docente e dell’amministratore dell’applicazione;
i comandi
GRANT SELECT ,DELETE ON eVal .* TO Teacher@localhost
GRANT INSERT ,UPDATE ON Student TO Teacher@localhost
GRANT INSERT ,UPDATE ON Exam TO Teacher@localhost
GRANT INSERT ,UPDATE ON Registration TO Teacher@localhost
GRANT INSERT ,UPDATE ON Assignment TO Teacher@localhost
GRANT INSERT ,UPDATE ON Test TO Teacher@localhost
GRANT INSERT ,UPDATE ON Composition TO Teacher@localhost
GRANT INSERT ,UPDATE ON Question TO Teacher@localhost
GRANT INSERT ,UPDATE ON Argument TO Teacher@localhost
GRANT INSERT ,UPDATE ON Attachment TO Teacher@localhost
GRANT UPDATE ON Execution TO Teacher@localhost
GRANT UPDATE ON Answer TO Teacher@localhost
GRANT UPDATE ON Course TO Teacher@localhost
definiscono i privilegi che il servlet possiede per poter eseguire con successo le operazioni
dalla 1 alla 46 definite in 5.2;

67. 56 Progettazione della base di dati
• il servlet che fornisce gli allegati dei quesiti (operazione 56 in 5.2) avr`a solo l’accesso
alla tabella degli allegati:
GRANT SELECT ON eVal.Attachment TO Browser@localhost
A questi tre “utenti” va aggiunto l’amministratore del database ExamRoot che avr`a tutti i
privilegi su tutte le tabelle:
GRANT ALL PRIVILEGES ON eVal .* TO ExamRoot@localhost
`E chiaro che dovranno essere i servlets ad occuparsi di autenticare i docenti e gli studenti
che utilizzano il sistema.
5.3.2 Accorgimenti per incrementare le prestazioni
Per ogni tabella si `e definita una chiave primaria sulla quale il database costruisce automati-
camente delle strutture ausiliarie, dette indici utilizzati per il reperimento efficiente e pi`u
veloce dei dati.
Quando si esegue un’interrogazione del database (query), l’operazione pi`u gravosa per il
DBMS `e quella di join, cio`e quella che “unisce” due tabelle in base ai vincoli relazionali non
scritti nel database ma definiti mediante i valori di alcuni campi delle tabelle; se a questi campi
non sono associati degli indici e i record da scandire sono numerosi, il tempo impiegato per
restituire il risultato potrebbe risultare inaccettabile. MySQL d`a la possibilit`a di specificare
degli indici secondari oltre a quelli creati automaticamente sulla chiave primaria.
Nel caso in cui, all’aumentare dei dati immagazzinati nel database, ci fosse un peggiora-
mento delle prestazioni, si sono suggeriti alcuni indici sugli attributi utilizzati nelle operazioni
di join (si veda a proposito la definizione SQL completa della base di dati). Per esempio sulla
tabella Answer che punta alla tabella Exam, potrebbe essere creato il seguente indice:
CREATE INDEX NomeIndice ON Answer ( IDExam)
e cos`ı per le tabelle Registration, Execution, Assignment ed Action.
Nell’uso degli indici bisogna fare attenzione allo spazio necessario su disco per la loro
creazione, proporzionale al numero di record della tabella in cui viene definito l’indice; inoltre
l’inserimento o la cancellazione di un record da un tabella, causa l’aggiornamento dell’indice
con un conseguente peggioramento delle prestazioni.

68. Capitolo 6
Progettazione dell’applicazione server
L’applicazione server ha il compito di soddisfare le richieste che arrivano dai vari client. Come
si vede nella figura 4.1 gli utenti sono rappresentati da:
• i docenti che devono preparare i compiti d’esame, fissare gli appelli, iscrivere gli studenti
e stabilire i criteri per la correzione automatica (schemi di correzione);
• gli studenti che devono svolgere gli esami;
• gli amministratori del sistema che sono autorizzati a creare ed eliminare i corsi.
Utilizzando come protocollo di comunicazione l’HTTP su TCP/IP, i vari utenti possono
trovarsi ovunque nella rete locale, per cui `e opportuno che l’accesso ai servizi del sistema
sia regolato da un’autenticazione.
L’utente interagisce di solito con il server mediante un browser; tutto ci`o che attiene alla
rappresentazione dei contenuti di un’applicazione Web (pagine HTML, documenti pdf, im-
magini, ecc.) e permette l’interazione con l’utente viene normalmente denominato interfaccia
utente. Il codice che `e responsabile, cio`e che “costruisce”, l’interfaccia utente sul server `e in-
vece denominato Presentation Layer (o presentazione lato server). Quindi l’interfaccia utente
`e formata da una componente sul client (browser, form HTML, contenuti ipertestuali) e da
una sul server (costruzione e restituzione delle pagine HTML, elaborazione dei dati inviati
nei form).
Se prendiamo il caso di una semplice applicazione Web, le richieste di un client vengono
soddisfatte dal server restituendo la pagina HTML voluta; se il contenuto della pagina varia
a seconda dell’utente o dei parametri della richiesta o ai dati contenuti in un database, allora
le pagine restituite devono venire create al momento della richiesta. Quindi il server si limita
a restituire ed eventualmente generare dinamicamente, la pagina richiesta dal client senza
prendere decisioni dettate, per esempio, dalla storia delle transazioni client–server passate
(stato) o di dati contenuti nel database; in questo caso quindi abbiamo un presentation
layer quasi banale e si parla di transazioni atomiche cio`e di transazioni che avvengono senza
interruzione e prima che qualcosa possa cambiare.

69. 58 Progettazione dell’applicazione server
Effettivamente in origine l’HTTP era un sistema che non considerava la storia delle varie
transazioni (era cio`e senza stato): la connessione del client con il server si apriva con una
richiesta di una pagina e si chiudeva con la restituzione della pagina da parte del server. Questo
sistema non permette per`o di creare applicazioni particolarmente interattive e nemmeno tanto
complesse; si sono allora trovati tre metodi per poter far fronte all’inconveniente della non
tracciabilit`a dell’utente collegato (si veda anche la sezione 1.3.1): riscrittura degli URL, uso
dei cookies, inserimento di campi nascosti all’interno dei form HTML. Avendo a disposizione
questi meccanismi il server pi`o creare e associare degli oggetti per ognuno di essi, all’interno
di una cosiddetta sessione o unit`a di lavoro; in questo caso la transazione copre pi`u richieste
HTTP e viene chiamata conversazionale. In questa situazione la logica di presentazione sul
server pu`o assumere una forma anche complessa per soddisfare varie esigenze e prendere delle
decisioni non solo in base alla richiesta ma anche in base allo stato; si pu`o allora parlare di
un Presentation Layer Deterministico.
E questa `e la soluzione ottimale per poter gestire al meglio le esigenze dei vari clients:
• il docente interagisce utilizzando dei form che permettano di gestire l’inserimento o la
modifica di compiti, quesiti ed appelli d’esame o di impostare uno schema di correzione;
quindi l’applicazione preveder`a la realizzazione di molte pagine diverse che devono poter
essere facilmente gestibili;
• lo studente interagisce in modo abbastanza elementare ma deve avere delle procedure
di autenticazione e accesso nonch´e di controllo delle azioni svolte, pi`u accurate.
Quindi il client pi`u che essere orientato alla richiesta di pagine HTML, diventa un generatore
di eventi per la logica di presentazione del server Web, rendendo l’interfaccia con l’utente
simile a quella delle pi`u sofisticate applicazioni Client/Server.
Per compiere i servizi richiesti l’applicazione si appoggia al database, che costituisce il
modello della realt`a di interesse e fornisce i dati all’applicazione mediante interrogazioni SQL.
6.1 Il design pattern Model–View–Controller
Se si guarda al client dalla parte dell’applicazione server si vede che il client visualizza una
serie di pagine HTML. Da ognuna di queste pagine possono arrivare degli eventi al server che
fisicamente si realizzano con i metodi GET o POST del protocollo HTTP; a questi eventi possono
essere aggiunti dei dati, chiamati parametri, che ne precisano il significato; per esempio se
viene premuto il bottone “Aggiungi” oppure “Rimuovi” di un form vengono inviati i dati del
form con l’aggiunta rispettivamente dei parametri Event=Aggiungi o Event=Rimuovi.
Quindi il server vede che il client visualizza una pagina, riceve un evento dal client, esegue
delle elaborazioni, invia un’altra pagina, vede che il client la visualizza e cos`ı via. Un modello
per rappresentare quello che accade sul client `e costituito da un diagramma di stato di questo
tipo:

70. 6.1 Il design pattern Model–View–Controller 59
Pagina 1 Pagina 2Evento A: Pagina 3Evento B:
La Pagina 1 corrisponde al primo stato, la Pagina 2 al secondo, la Pagina 3 al terzo; quello
che accade tra gli stati viene chiamato evento. In realt`a quello che accade `e un po’ pi`u
complesso: il client che si trova in un certo stato pu`o produrre un evento accompagnato
da alcuni parametri. La combinazione dello stato corrente, dell’evento e del risultato della
valutazione delle condizioni determiner`a lo stato successivo ed eventualmente alcune azioni
che devono essere intraprese affinch`e possa avvenire la transizione dello stato. Quanto appena
detto pu`o essere riassunto nella seguente asserzione:
[lo stato corrente + un evento + alcuni parametri]
determinano
[le azioni + lo stato successivo]
Un’architettura ben consolidata per l’interfaccia utente che consente di implementare questo
modello a stati ed eventi `e il design pattern MVC (o Model 2). Questo modello prevede che
l’applicazione Web sia divisa in tre parti: il Model, la View e il Controller. In questo tipo di
architettura ci sono due requisiti che il Controller deve soddisfare:
• il primo e pi`u importante `e che il Controller deve determinare il flusso di controllo del
sistema: deve analizzare l’evento che arriva dall’interfaccia utente e deve determinare
lo stato successivo dell’interfaccia stessa;
• il secondo, che spesso crea confusione nell’implementazione di questa architettura, `e
che il Controller deve eseguire le azioni necessarie nell’ambito del problema da trattare
(chiamato Model o Problem Domain); queste azioni quindi cambiano lo stato del sistema
sottostante; molta confusione deriva proprio dal fatto che lo stato del sistema `e diverso
dallo stato dell’interfaccia utente: in una normale applicazione, per esempio a finestre, il
Model `e responsabile della notifica alle classi preposte alla visualizzazione (View) di un
qualsiasi cambiamento dello stato del sistema sottostante; viceversa in un’applicazione
Web con un client leggero come un semplice browser, non c’`e modo di notificare al client
un cambiamento dello stato dell’applicazione.
Quindi i Controller ricevono ed analizzano gli eventi in ingresso, considerano lo stato del client
e determinano lo stato successivo del sistema; dal nuovo stato del sistema il Controller invoca
un’appropriata View che visualizza l’output richiesto. Quindi riassumendo:
i Controllers si occupano dell’input mentre le Views dell’output
La View viene creata su richiesta, quindi deve reperire i dati dal Model ogni volta che viene
istanziata e non c’`e alcuna notifica successiva del cambiamaento del modello. Views e Con-
trollers, che comunque devono rimanere separati, formano assieme il Presentetion Layer di
un’applicazione Web.

71. 60 Progettazione dell’applicazione server
Il Model invece `e separato dal Presentation Layer e deve provvedere a quei servizi necessari
nell’ambito del problema da trattare, compreso l’accesso ai dati persistenti (database). Sia
View che Controller possono mandare messaggi al Model, il quale invier`a di ritorno le risposte
appropriate.
L’interfaccia utente, compreso il Presentation Layer, il Model e la base di dati sono gli
elementi di una 3–Tier Architecture (si veda per maggiori dettagli la sezione 3.2.2).
I vantaggi del modello MVC sono:
• l’alto livello di astrazione dei dati raggiungibile, dovuto alla separazione logica e fun-
zionale delle diverse parti dell’applicazione;
• la creazione di classi utili a una grande quantit`a di applicazioni
• la possibilit`a di ampliare in modo facile l’applicazione, basti pensare che si potrebbe mo-
dificare completamente l’aspetto dell’interfaccia utente, cio`e la View, senza modificare
la logica di funzionamento, costituita dal Controller e dal Model.
Gli svantaggi d’altra parte riguardano:
• la logica di funzionamento e del controllo degli eventi, che pu`o essere difficile da capire;
• il codice, pu`o risultare lento per la presenza del Controller.
Il progetto dell’applicazione server di e-Val seguir`a proprio il modello MVC illustra-
to in tutte le sue parti nella figura 6.1. Si possono individuare tre aree distinte (3–Tier
Architecture):
• presentation layer divisa a sua volta in
∗ Controller: `e quella parte di applicazione responsabile di gestire gli input dell’u-
tente, che in un’applicazione Web sono rappresentati da richieste HTTP; diventa
naturale assegnare questo compito ad un servlet Java che permette di implementare
al suo interno il codice necessario a interpretare gli eventi, aggiornare il Modello e
scegliere la View opportuna;
∗ View: `e competente della visualizzazione delle informazioni al client, la loro pre-
sentazione visiva; in un’applicazione Web `e la visualizzazione sullo schermo dell’u-
tente remoto costituita da una pagina HTML; poich´e i contenuti di queste pagine
cambiano a seconda dei dati del database e dello stato del client, queste pagine de-
vono essere costruite dinamicamente al momento della richiesta; questa possibilit`a
`e offerta dalla tecnologia delle JavaServer Pages con l’aggiunta di alcune librerie
di tag personalizzati; la View accede al Model e al database solamente per leggerne
i dati, ma non per aggiornarli;
• model layer o semplicemente Model corrisponde ai dati e alla logica dell’applicazione,
indipendente sia dal View che dal Controller tanto che potrebbe essere utilizzata an-
che per soddisfare le esigenze di un’applicazione desktop; `e stata realizzata mediante i
componenti JavaBeans che possono contenere le procedure di reperimento dei dati dal
database;

72. 6.2 Controller: i Servlet 61
aggiorna modello recupera dati
lettura
lettura/scrittura
View
(JavaServer Pages)
Controller
(Servlet)
Client
(Browser o Java Applet)
Driver JDBC e pool di connessioni
(Connector/J e DbConnectionBroker)
Model
(JavaBean)
Richiesta
HTTP
Pagina
HTML
Database
(MySQL)
Utente
Flusso di
uscita
Evento
di input
Presentation
layer
Model
layer
Persistence
layer
3TierArchitecture
Figura 6.1: Schema completo dell’architettura MVC per l’applicazione e-Val
• persistence layer `e il livello in cui i dati vengono depositati permanentemente imple-
mentato dalla base di dati relazionale gi`a progettata.
Gli accessi al database sia del Model che del View sono gestiti da un pool di connessioni
che aumenta l’efficienza e la velocit`a di accesso: quando un modulo ha bisogno di reperire
informazioni dal database, gli viene assegnata un connessione gi`a aperta e libera, presa dal
pool a cui poi verr`a restituita.
6.2 Controller: i Servlet
La sincronizzazione tra View e Model `e delegata al Controller. Si tratta di un meccanismo
che deve gestire le azioni dell’utente per trasformarle in eventi della logica dell’applicazione,

73. 62 Progettazione dell’applicazione server
i quali possono poi venire processati utilizzando metodi presenti sul lato dell’applicazione. Si
tratta di operazioni complesse che si svolgono quindi sia sul lato Web che su quello Server.
Si `e deciso di realizzare due applicazioni MVC indipendenti per la gestione dei servizi per
gli studenti e per i docenti pi`u un modulo per la restituzione degli allegati; questa soluzione
permette di separare funzionalmente i servizi e adottare diverse strategie per l’autenticazione
e l’accesso al sistema.
6.2.1 Il docente
L’accesso dei docenti al sistema pu`o avvenire tramite browser Web o tramite l’applicazione
e–Val Question Manager, usando comunque il protocollo HTTP. Per questo `e stato progettato
un servlet che costituisce il controller MVC e ha la funzione di identificare il docente che si
collega al sistema, eseguire le azioni necessarie del Model ed infine scegliere la pagina JSP
pi`u opportuna da visualizzare al docente. Il servlet che realizza questa funzione si chiama
TeacherController.
Per permettere di indirizzare le richieste del docente a questo controller, bisogna informare
Tomcat sulle mappature delle richieste HTTP, inserendo opportunamente nel file web.xml le
righe
s e r v l e t
2 servlet −nameTeacherController/ servlet −name
servlet −c l a s seValServer . TeacherController/ servlet −c l a s s
4 init −param
!−− Numero minimo di connessioni −−
6 param−nameminConnections/param−name
param−value2/param−value
8 / i nit −param
init −param
10 !−− Numero massimo di connessioni −−
param−namemaxConnections/param−name
12 param−value3/param−value
/ init −param
14 . . .
/ s e r v l e t
16 . . .
servlet −mapping
18 servlet −nameTeacherController/ servlet −name
url−pattern∗ . teacher/ url−pattern
20 / servlet −mapping
le righe 2 e 3 associano un nome interno al servlet eValServer.TeacherController mentre
la riga 19 fa in modo che tutte le richieste HTTP che terminano con .teacher vengano
indirizzate a questo servlet; per esempio la richiesta
http://localhost:8080/eVal/Welcome.teacher
viene inoltrata automaticamente da Tomcat al servlet TeacherController. Nel file web.xml

74. 6.2 Controller: i Servlet 63
possono essere inseriti anche dei parametri (si vedano le righe 4–13) che vengono letti dal
servlet la prima volta che viene caricato.
/Browser web : servlet
/ : TeacherController
pool di connessioni
/Pool dei docenti : DbConnectionBroker
java bean
/Docente : dbTeacherModel
/ : dbAccess
database
/eVal : SchemaMySQL
sessioni
/Sessioni del server : HttpSession
/e-Val Student :
servlet
/ : StudentController
pool di connessioni
/Pool degli studenti : DbConnectionBroker
java bean
/Studente : dbStudentModel
/Motore JSP : RequestDispatcher
java server page
/Pagina JSP : HttpServlet
/Motore JSP : RequestDispatcher
java server page
/Pagina JSP : HttpServlet
1 : processRequest ()
1.2 : getConnection ()
1.9 : freeConnection ()
1.3 : setdbConnection ()
1.4 : isAuthenticated ()
1.6 : setCurrentJSP ()
1.8 : freeDBConnection ()
1.1 : getAttribute ()
1.5 : setAttribute ()
2.3 : setDBConnection ()
2.4 : isStillAuthenticated ()
2.6 : freeDBConnection ()
2.2 : getConnection ()
2.7 : freeConnection ()
2.1 : getAttribute ()
2 : processRequest ()
1.4.1.1 : query ()
2.4.1.1 : query ()
1.4.1 : getQueryValue ()
2.4.1 : getQueryValue ()
1.7 : forward ()
1.7.1 : _jspService ()
1.7.1.1 : getDBConnection ()
1.7.1.2 : query ()
2.5 : forward ()
2.5.1 : _jspService ()
2.5.1.1 : getDBConnection ()
2.5.1.2 : query ()
1 : processRequest ()
1.2 : getConnection ()
1.9 : freeConnection ()
1.3 : setdbConnection ()
1.4 : isAuthenticated ()
1.6 : setCurrentJSP ()
1.8 : freeDBConnection ()
1.1 : getAttribute ()
1.5 : setAttribute ()
2.3 : setDBConnection ()
2.4 : isStillAuthenticated ()
2.6 : freeDBConnection ()
2.2 : getConnection ()
2.7 : freeConnection ()
2.1 : getAttribute ()
2 : processRequest ()
1.4.1.1 : query ()
2.4.1.1 : query ()
1.4.1 : getQueryValue ()
2.4.1 : getQueryValue ()
1.7 : forward ()
1.7.1 : _jspService ()
1.7.1.1 : getDBConnection ()
1.7.1.2 : query ()
2.5 : forward ()
2.5.1 : _jspService ()
2.5.1.1 : getDBConnection ()
2.5.1.2 : query ()
Figura 6.2: Azioni svolte dai vari moduli del server a seguito di una richiesta
HTTP del client: l’ordine temporale con cui vengono richiamati i metodi dei
vari oggetti segue la numerazione che precede i nomi.
Si analizzano ora alcune operazioni svolte dal servlet (figura 6.2); appena il servlet viene
caricato (una volta solamente), il container esegue il suo metodo init che crea il pool di
connessioni:
ConnectionBroker = new DbConnectionBroker ( ”com . mysql . jdbc . Driver ” ,
2 ” jdbc : mysql :// ” + getServletContext ( ) . getInitParameter ( ” server ” ) + ”/” +
getServletContext ( ) . getInitParameter ( ” database ” ) ,

75. 64 Progettazione dell’applicazione server
4 getInitParameter ( ” user ” ) , getInitParameter ( ”password” ) ,
Integer . parseInt ( getInitParameter ( ”minConnections” )) ,
6 Integer . parseInt ( getInitParameter ( ”maxConnections” )) ,
new Fil e ( ErrorLog . getLogDirectory () ,
8 ” eVal TeacherBroker . log ” ) . getAbsolutePath () ,
Double . parseDouble ( getInitParameter ( ”maxConnectionTime” ) ) , true ,
10 Integer . parseInt ( getInitParameter ( ”maxCheckoutSeconds” ) ) , 1 ) ;
nelle righe 2–6 la funzione getInitParameter restituisce i parametri letti dal file web.xml e
servono per inizializzare il pool. Appena avviato, il servlet `e pronto ad accettare le richieste
HTTP che vengono passate, assieme alla risposta che dovr`a essere mandata indietro, al metodo
protected void processRequest ( HttpServletRequest request ,
2 HttpServletResponse response )
throws ServletException , java . io . IOException
Questo metodo deve allora contenere le procedure necessarie per l’autenticazione, la ge-
stione delle sessioni, l’aggiornamento del Model e deve scegliere la View pi`u opportuna da
visualizzare. Infatti all’arrivo di una richiesta il servlet recupera l’eventuale sessione esistente:
HttpSession s e s s i o n = request . getSession ( ) ;
dbTeacherModel Teacher =
( dbTeacherModel ) s e s s i o n . getAttribute ( ”teacherDB” ) ;
e da questa recupera il JavaBean implementato dalla classe dbTeacherModel che mette a
disposizione i metodi per l’aggiornamento della base di dati. Il docente che si collega la prima
volta al sistema non ha ancora una sua sessione di lavoro e quindi nemmeno il bean. Deve
quindi inserire le proprie login e password che verranno inviate al server assieme alla richiesta
di autenticazione; in questo caso il servlet istanzia un nuovo JavaBean e controlla che la login
e la password corrispondano al docente di un corso:
Teacher = new dbTeacherModel ( ) ;
2 . . .
i f ( Teacher . isAuthenticated ( Login , Password ) ) {
4 ErrorLog . write ( ”Docente autenticato : ” + HTTPHeader( request ) ) ;
SessionTracked = true ;
6 s e s s i o n . setAttribute ( ”teacherDB” , Teacher ) ;
s e s s i o n . setMaxInactiveInterval (
8 Integer . parseInt ( getInitParameter ( ” MaxInactiveInterval ” ) ) ) ;
i f ( request . getParameter ( ”Applet”) == n u l l ) URI = ”Main” ;
10 e l s e URI = ” AppletAuthentication ” ;
} e l s e {
12 s e s s i o n . i n v a l i d a t e ( ) ;
ErrorLog . write ( ”−−− I l seguente c l i e n t DOCENTE ” +
14 ” ( login : ” + Login + ” ) non `e stato autenticato : ” +
HTTPHeader( request ) ) ;
16 }
alla riga 3 il servlet verifica l’identit`a del docente mediante la funzione isAuthenticated
del Model; alla riga 6 salva, nell’ambito della sessione di lavoro, il bean corrispondente al

76. 6.2 Controller: i Servlet 65
docente; alla riga 9 stabilisce se la richiesta arrivi da un browser o dall’applicazione e–Val
Question Manager; se viceversa il docente non `e stato riconosciuto, alla riga 12 la sessione
viene annullata e viene scritto un avviso nel file di log.
Non appena il servlet ha recuperato la sessione o ha autenticato un nuovo docente chiede,
al pool DbConnectionBroker una connessione al database e la passa al JavaBean:
Teacher . setdbConnection ( ConnectionBroker . getConnection ( ) )
a questo punto il servlet svolge la sua funzione di Controller: esegue le azioni in base al
tipo di richiesta e dei suoi parametri, richiama le funzioni definite nel JavaBean Teacher che
aggiorna la base di dati ed infine sceglie la pagina JSP opportuna da inviare al client per la
visualizzazione.
Per esempio, se `e stata inviata al servlet la richiesta di visualizzare un compito esistente
(l’URL potrebbe essere localhost:8080/eVal/ShowTest.teacher), il servlet esegue questo
codice:
i f (URI. equalsIgnoreCase ( ”ShowTest” ) ) {
2 OK = Teacher . setFirstIdArgument ( ) ;
i f (OK = Teacher . setIDTest ( request . getParameter ( ”IDTest” ) ) ) {
4 i f ( Teacher . isTestUsed ( ) ) {
Teacher . setCurrentJSP ( ”ShowTest” ) ;
6 } e l s e {
OK = Teacher . s e t T e s t D i f f i c u l t y ( ) ;
8 Teacher . setCurrentJSP ( ”ModifyTest” ) ;
}
10 }
in cui alla riga 3 recupera dalla richiesta il parametro contenente l’identificatore del compito
scelto; alla riga 4 verifica se il compito `e gi`a stato dato ad un esame, nel qual caso non pu`o
pi`u essere modificato, e sceglie la pagina JSP da visualizzare (riga 5 o 8); alla riga 7 calcola
ed aggiorna la difficolt`a del compito scelto in base alle risposte pi`u recenti. La visualizzazione
della JSP avviene mediante il comando
JSPdispatcher ( Teacher . getCurrentJSP ( ) , request , response ) ;
Conclusa la preparazione della JSP e prima di restituire il controllo al servlet container viene
liberata la connessione al database e restituita al pool:
ConnectionBroker . freeConnection ( Teacher . freeDBConnection ( ) ) ;
La logica di funzionamento del Controller, cio`e il flusso di controllo per la scelta delle
pagine JSP da visualizzare, `e illustrata nella figura 6.3: ogni pagina JSP `e rappresentata da
uno stato contenente le varie azioni che l’utente pu`o compiere (tipicamente la convalida dei
form o i click dei bottoni presenti nelle pagine HTML); da ogni stato escono delle frecce che
rappresentano gli eventi ricevuti dal controller e che possono dividersi a seconda del verificarsi
di alcune condizioni sui dati; infine le frecce vanno a finire in un’altra pagina JSP, cio`e il nuovo
stato dell’interfaccia utente.

77. 66 Progettazione dell’applicazione server
Main.jsp
Welcome.jsp
inserimento login e password
NewCourse.jsp
inserimento nome, docente, login e password
ShowExamDone.jsp
impostazione dello schema di correzione
stampa della tabella degli iscritti all’esame
nuova correzione delle risposte
visualizzazione degli studenti che hanno sostenuto l’esame
visualizzazione dei compiti svolti dagli studenti
filtraggio dei voti da mostrare
stampa della tabella dei risultati
PrintExamStudentList.jsp
PrintExamResult.jsp
ShowExamStudent.jsp
modifica della correttezza delle risposte date
visualizzazione del compito completo
visualizzazione dei singoli quesiti
azioni compiute dallo studente
PrintStudentTest.jsp
ShowQuestion.jsp
ShowTestUsed.jsp
innalzamento del punteggio delle risposte
visualizzazione e modifica dei quesiti del compito
visualizzazione del compito completo
PrintTest.jsp
ModifyQuestion.jsp
modifica del memorandum e del commento
modifica della risposta corretta
NewTest.jsp
inserimento del titolo
scelta dell’ordinamento dei quesiti
ModifyTest.jsp
modifica del nome e dell’ordinamento dei quesiti
modifica dell’ordine dei quesiti
rimozione di quesiti dal compito
scelta di un argomento del corso
aggiunta di un quesito al compito
visualizzazione di un quesito
ShowTest.jsp
NewArgument.jsp
inserimento del nome e della descrizione
ModifyArgument.jsp
modifica del nome e della descrizione
spostamento dei quesiti in un altro argomento
eliminazione dei quesiti scelti
visualizzazione dei quesiti scelti
scaricamento dei quesiti scelti
visualizazione e modifica dei quesiti
PrintArgument.jsp
Menu.jsp
scegli un esame
crea un nuovo esame
elimina un esame
scegli un compito
crea un nuovo compito
copia un compito esistente
elimina un compito
scegli un argomento
crea un nuovo argomento
elimina un argomento
aggiorna la difficoltà dei quesiti
aggiorna l’intervallo di visualizzazione
scarica e-Val Student
Header.jsp
menu principale
pagina precedente
aggiorna pagina
modifica dati corso
aiuto
esci
NewExam.jsp
inserimento nome, data e durata
inserimento studenti per gruppo e avvisi
ModifyCourse.jsp
modifica nome e docente
modifica login e password di accesso
ModifyExam.jsp
modifica nome, data e durata
modifica studenti per gruppo e avvisi
attivazione esame
iscrizione studenti
cancellazione iscrizioni
stampa della tabella degli iscritti all’esame
assegnazione compiti
Administration.jsp
nuovo corso
elimina corso
aiuto
esci
LoginError.jsp
Help.jsp
Richiesta pagina di benvenuto
è in svolgimento o è già concluso
ricorreggi le risposte
tabella d’esame
risultati dell’esame
mostra studente
mostra il compito dello studente
mostra il quesito scelto
mostra il compito di un gruppo di studenti alza o abbassa i punteggi
mostra il compito
modifica di un quesito
aggiorna risposta corretta
non ancora dato ad un esame
aggiornamento dell’ordine dei quesiti
selezione di un altro argomento
aggiunta di un quesito al compito
visualizza un quesito
già dato ad un esame
mostra il compito
visualizza un quesito
modifica quesito
visualizza quesiti scelti
sposta quesiti
menu principale
esci
modifica dati corso
crea nuovo esame
deve ancora iniziare
tabella d’esame
scelto un esame
scelto un argomento
crea nuovo argomento
crea nuovo compito
è un docente
esci
è un amministratore
nuovo corso
login
non valida
valida
imposta schema di correzione
aiuto
aiuto
aggiorna difficoltà quesiti
aggiorna intervallo di visualizzazione
scelto compito
H*
pagina precedente
Figura 6.3: Il diagramma mostra come il controller per il docente sceglie le varie
view da visualizzare, implementate da pagine JSP dinamiche.

78. 6.2 Controller: i Servlet 67
6.2.2 Lo studente
Welcome.jsp
Authentication.jsp
inizio dell’esame
AuthenticationFail.jsp
Question.jsp
risposta al quesito
prossimo quesito
aggiornamento del quesito corrente
ritiro dall’esame
consegna del compito
ActionRecorded.jsp
ritorno al quesito
InvalidAnswer.jsp
ritorno al quesito
ConfirmEnd.jsp
conferma del ritiro o della consegna
ritorno al quesito
End.jsp
il client studente è stato attivato
primo quesito
è stata compiuta un’azione non consentita
è stata data una risposta
non è autorizzato
è stato autenticato
lo studente ha richiesto un login
di tipo sbagliato
va al prossimo quesito
ritiro o consegna del compito
fine dell’esame
vai al prossimo quesito
già risposto a tutte le domande
Figura 6.4: Logica di funzionamento del controller per lo studente.
Il funzionamento e la realizzazione del controller che riceve le richieste dello studente,
generate dall’applicazione e–Val Student, `e del tutto simile a quello del docente (si veda
a proposito la figura 6.2). Le differenze riguardano naturalmente la logica implementata
illustrata nel diagramma di figura 6.4, e la modalit`a di autenticazione che deve essere pi`u

79. 68 Progettazione dell’applicazione server
Ottieni dalla sessione il bean dello studente
Controlla che lo studente possa ancora svolgere l'esame
Controlla che il client sia java
Invia al client un messaggio di errore
Crea un nuovo bean per lo studente
Controlla nel database se lo studente è iscritto all'esame
Invalida la sessione e distruggi il bean
Salva il bean nella sessione
Soddisfa la richiesta del client
Invia il segnale di chiusura automaticaInvia al client un messaggio di errore
il bean esiste
è java
il client ha richiesto di sostenere un esame
il client ha inviato un comando
non è iscritto
è iscritto
il bean non esiste
il client ha richiesto la sincronizzazione del tempo
non può più svolgere l'esame
non è java
Figura 6.5: Flusso di controllo che regola l’accesso dello studente.
complessa; infatti lo studente ha diritto di collegarsi solamente se sono soddisfatte le seguenti
condizioni (si veda la figura 6.5):
1. il client collegato al server deve essere un’applicazione Java:
i f ( request . getHeader ( ” user−agent ” ) . toLowerCase ( ) . trim ()
. startsWith ( ” java ” ) ) {
2. il numero di matricola e la password devono corrispondere ad uno studente iscritto ad
un esame;

80. 6.2 Controller: i Servlet 69
3. l’esame `e stato attivato dal docente;
4. lo studente non ha esaurito il tempo a disposizione;
5. lo studente non ha gi`a risposto a tutti i quesiti.
La seconda e la terza condizione vengono controllate una sola volta dalla funzione isAuthen-
ticated del bean dello studente
i f ( Student . isAuthenticated ( request . getParameter ( ” Matricula ” ) ,
2 request . getParameter ( ”Password” ) , s e s s i o n . getId () ,
request . getRemoteHost ( ) , HTTPHeader( request ) ) ) {
4 . . .
in cui si specificano, per poterne tenere traccia nel database, anche l’identificatore assegnato
alla sessione corrente (riga 2), il nome del computer sul quale lo studente sta svolgendo l’esame
e i parametri della richiesta (riga 3). La funzione `e implementata nel bean dbStudentModel
utilizzando una query SQL:
SELECT Assignment.IDStudent ,
2 Assignment.IDTest , Assignment.IDExam , Exam.Length *60 as ’Length ’
FROM Student inner join Assignment using(IDStudent)
4 inner join Exam using(IDExam)
WHERE Student.Matricula like Matricula and
6 Assignment.Password like Password and
Exam.Active like ’yes’
in cui Matricula e Password sono quelle specificate dallo studente.
La terza e la quarta condizione vengono verificate ad ogni richiesta HTTP dello studente
e prima di intraprendere qualsiasi azione:
i f ( ! Student . i s S t i l l A u t h e n t i c a t e d ( s e s s i o n . getId ( ) ) ) {
request . setAttribute ( ” error ” , ”Non s e i pi`u autorizzato ” +
”ad usare questo c l i e n t . ” ) ;
s e s s i o n . i n v a l i d a t e ( ) ;
JSPdispatcher ( ” Error ” , request , response ) ;
}
in cui la funzione isStillAuthenticated `e contenuta nel model ed `e implementata dalla
seguente query:
SELECT IFNULL ((NOW () ADDDATE(Start , INTERVAL MaxLength SECOND )) OR
(NOW () SUBDATE(Start , INTERVAL 10 MINUTE )) , 0) as ’Expired ’,
(Start IS NOT NULL ) as ’Started ’,
(End IS NOT NULL ) as ’Ended ’,
CurrentQuestion
FROM Execution inner join Exam using(IDExam)
WHERE Execution.IDStudent like IDStudent and
Execution.IDExam like IDExam and
Code like ’ jSessionID ’ and
ClientName like ’ ClientName ’ and
Exam.Active like ’yes’
Nelle prime due righe si nota come venga verificato che il tempo a disposizione non sia scaduto.

81. 70 Progettazione dell’applicazione server
6.2.3 Il reperimento degli allegati
I quesiti che vengono inseriti nel database e mostrati agli studenti sono in formato HTML,
quindi oltre al testo possono contenere delle immagini. Quando il browser deve visualizzare
queste pagine prelevate dal server, le analizza per vedere se ci sono degli oggetti allegati e, ad
uno ad uno, li scarica dal server utilizzando la richiesta contenuta nel tag HTML dell’oggetto.
Allo scopo di fornire al browser le immagini contenute nei quesiti, ma pi`u in generale qual-
siasi oggetto allegato, `e stato creato un servlet (chiamato eValServer.AttachmentControl-
ler) che soddisfa questo tipo di richieste dei client; nel file web.xml `e stata inserita questa
mappatura:
servlet −mapping
servlet −nameAttachment/ servlet −name
url−pattern/ attachment/ url−pattern
/ servlet −mapping
quindi il servlet risponde solamente a quelle richieste che iniziano con attachment; per reperire
l’allegato desiderato la richiesta dovr`a contenere anche due parametri: un identificatore nu-
merico dell’immagine e un codice di sicurezza. Quindi un possibile tag, contenuto in un
quesito HTML, potrebbe essere
IMG src=”attachment ? id=40code =31583” name=”Immagine7”
`E quindi necessaria un’operazione di preparazione dei quesiti HTML prima del loro inserimen-
to nel database in modo da sostituire gli indirizzi originali delle immagini che puntano al file
locale, con questi indirizzi relativi contenenti i parametri necessari al reperimento dell’allegato
dal database; questa operazione viene compiuta in modo automatico dal parser implementato
in e–Val Question Manager.
Nel caso degli allegati, il servlet non deve prendere alcuna decisione sull’oggetto da
restituire ma deve semplicemente inviare come risposta, il flusso di byte contenente l’allegato:
ServletOutputStream out = response . getOutputStream ( ) ;
2 BufferedOutputStream bos = new BufferedOutputStream ( out ) ;
. . .
4 InputStream in = ExamDB. getAttachment ( IDAttachment , AttachmentCode ) ;
BufferedInputStream bis = new BufferedInputStream ( in ) ;
6 i n t i ;
do {
8 i = bis . read ( ) ;
i f ( i != −1) bos . write ( i ) ;
10 } while ( i != −1);
nelle prime due righe il servlet apre il flusso bufferizzato di byte verso il client; nella riga 4
ottiene il flusso bufferizzato in ingresso dal database corrispondente all’allegato desiderato ed
infine nelle righe 7–10 legge i byte dal database e li invia in uscita.

82. 6.3 Model: i JavaBeans 71
6.3 Model: i JavaBeans
Nell’architettura MVC il Model contiene tutto il codice che non dipende dall’applicazione
Web; potrebbe infatti servire anche per un’applicazione desktop. Il modo pi`u naturale di
implementarlo `e quello di usare dei JavaBean, cio`e delle classi Java che devono soddisfare
alcune semplici regole (si veda la sezione 1.4).
Come spiegato nell’introduzione al Controller, l’applicazione deve fornire i servizi per
due grandi aree, i docenti e gli studenti, pi`u il reperimento degli allegati. Si `e realizzata
allora la classe dbAccess, che fornisce i servizi a basso livello verso il database, come per
esempio l’esecuzione delle queries e la restituzione dei risultati ottenuti (HashMap, TreeMap e
ArrayList). Da questa classe vengono derivati i beans veri e propri per gli ambiti di interesse:
dbStudentModel, dbTeacherModel e dbAttachmentAccess.
Di seguito verranno spiegate le operazioni principali o pi`u complesse svolte dai beans.
6.3.1 Correzione dei compiti
La correzione dei compiti svolti durante un appello d’esame `e stata pensata come composta
di tre fasi:
• valutazione del grado di correttezza: viene svolta automaticamente per confronto
con la risposta esatta del quesito non appena arriva la risposta dello studente al server
e salvata nel database nel campo Answer.Value; il valore 0 significa che la risposta `e
sbagliata, mentre il valore 1 ha il significato di risposta giusta; un valore intermedio `e
ammesso solo per i quesiti che prevedono pi`u risposte esatte (in questo caso il valore `e
calcolato prendendo il numero di risposte esatte diviso per il numero totale di risposte);
• assegnazione del peso alle risposte: il docente deve scegliere un peso compreso tra
0 e 1 da assegnare alle risposte corrette, errate e a quelle non date; nel caso in cui il
docente lo desideri possono essere considerate parzialmente corrette anche i quesiti con
pi`u di una risposta esatta; c’`e inoltre la possibilit`a di aggiungere o togliere un punteggio
a piacimento ad una o pi`u risposte di un compito, per compensare per esempio la
particolare difficolt`a incontrata dagli studenti a rispondere ad un quesito;
• calcolo del punteggio di un compito: `e semplicemente la media dei pesi assegnati
precedentemente alle risposte di un compito espressa in centesimi;
• conversione punteggio–voto: essendo il punteggio del compito espresso in centesimi
`e necessario una sua conversione mediante la definizione di una retta di conversione
scelta dal docente.
Nella tabella seguente sono descritti i vari tipi di risposte possibili per un quesito e un esempio
della relativa rappresentazione stringa con la quale vengono salvate nel database:
Descrizione dei tipi di risposte Esempio

83. 72 Progettazione dell’applicazione server
Radio: solamente una delle risposte presentate `e corretta;
la risposta viene salvata nel database per mezzo della parola
opt seguita dal numero posizionale della risposta
opt3
Checkbox: pi`u di una risposta presentata `e corretta; nel
database le risposte sono separate da un punto e virgola
opt1; opt4
Range: prevede l’inserimento di un valore numerico che
viene considerato esatto con un preciso margine di errore;
l’intervallo aperto valido di valori viene specificato dai due
estremi separati da un trattino di sottolineatura; gli even-
tuali valori puntuali vanno separati da un punto e virgola;
sono ammessi anche gli infiniti (inf o +inf, -inf)
−1.7 ≤ x −1.2 diven-
ta -1.7;-1.7 -1.2
oppure
x ≤ 5 diventa -inf 5;5
Anytext: in questo caso la risposta `e aperta e dovr`a essere
corretta manualmente dal docente
Sia le risposte corrette (Question.RightAnswer) sia quelle date dagli studenti (Answer.Con-
tent) vengono salvate usando il medesimo formato, cos`ı da poter essere facilmente confrontate
in modo automatico. Infatti quando lo studente risponde ad un quesito, il server crea due
istanze della classe Answer inizializzate con la risposta data dallo studente e quella corretta;
richiama poi il seguente metodo che restituisce direttamente il grado di correttezza da salvare
nel database (in Answer.Value):
s t a t i c f i n a l f l o a t RIGHT ANSWER = new Float ( 1 ) . floatValue ( ) ;
2 s t a t i c f i n a l f l o a t WRONGANSWER = new Float ( 0 ) . floatValue ( ) ;
p u b l i c f l o a t compareAnswer ( Answer RightAnswer ) {
4 i f ( NullAnswer ) return 0 ;
e l s e i f ( AnswerType . equalsIgnoreCase ( ” anytext ” ) ) {
6 return −1;
} e l s e i f ( AnswerType . equalsIgnoreCase ( ”checkbox” ) ) {
8 f l o a t Score =0;
i f ( Answers . s i z e ()=RightAnswer . s i z e ( ) ) {
10 f o r ( I t e r a t o r i = Answers . i t e r a t o r ( ) ; i . hasNext ( ) ; ) {
i f ( RightAnswer . contains (( String ) i . next ( ) ) )
12 Score += RIGHT ANSWER;
e l s e
14 Score += WRONGANSWER;
}
16 return Score /RightAnswer . s i z e ( ) ;
} e l s e return WRONGANSWER;
18
} e l s e i f ( AnswerType . equalsIgnoreCase ( ” radio ” ) ) {
20 i f ( RightAnswer . contains (( String ) Answers . get ( 0 ) ) )
return RIGHT ANSWER;
22 e l s e
return WRONGANSWER;

84. 6.3 Model: i JavaBeans 73
24
} e l s e i f ( AnswerType . equalsIgnoreCase ( ” range ” ) ) {
26 RealInterval I n t e r v a l s [ ] = RightAnswer . getRange ( ) ;
f l o a t Score =0;
28 i f ( Answers . s i z e () 1) return WRONGANSWER;
e l s e {
30 f o r ( I t e r a t o r i = Answers . i t e r a t o r ( ) ; i . hasNext ( ) ; ) {
RealInterval r i = new RealInterval (( String ) i . next ( ) ) ;
32 boolean Found = f a l s e ;
f o r ( i n t j =0; jI n t e r v a l s . length ; j++)
34 i f ( I n t e r v a l s [ j ] . contains ( r i ) ) {
Score +=RIGHT ANSWER;
36 Found=true ;
break ;
38 }
i f ( ! Found ) Score += WRONGANSWER;
40 }
return Score /Answers . s i z e ( ) ;
42 }
} e l s e return 0 ;
44 }
Le righe 5, 7, 19 e 25 selezionano il tipo di risposta che deve essere confrontata; prendendo
in considerazione il tipo range, se viene specificata pi`u di una risposta la riga 28 la considera
errata; se invece la risposta `e una sola e numerica, la riga 33 comincia a confrontarla con tutti
i valori della risposta esatta; pi`u precisamente verifica che il valore specificato appartenga
all’intervallo reale della risposta esatta (Intervals[j].contains(ri) alla riga 34).
Le altre tre operazioni descritte per la correzione dei compiti, possono essere riassunte
nella seguente formula:
V oto in trentesimi =
1
n
·
n
i=1
(p(i) + ai) · Slope + Offset (6.1)
in cui n `e il numero dei quesiti presenti nel compito dello studente, Slope e Offset rappre-
sentano la pendenza e lo scostamento della retta di conversione punteggio–voto, p(i) sono i
pesi assegnati alla risposta a seconda che sia corretta, errata oppure non data; infine ai sono
gli eventuali valori aggiunti a discrezione del docente (compresi tra 0 e 1).
Queste operazioni vengono eseguite, per tutti gli studenti che hanno sostenuto un esame,
da un’unica query contenuta nel metodo setExamResult() del bean dbTeacherModel:
SELECT Execution.IDStudent ,
2 Execution.IDExam ,
round(avg(
4 (case
when Answer.Value is null then Exam.NoAnswerValue
6 when Answer.Value =0 || ( Answer.Value 1
Exam. AllowPartialAnswer like ’no’) then Exam. WrongAnswerValue
8 when Answer.Value 0 then Answer.Value*Exam. RightAnswerValue end)

85. 74 Progettazione dell’applicazione server
+ Composition.AddedValue
10 )* Exam.ScoreSlope+Exam.ScoreOffset ) as Score
FROM Student inner join Execution using(IDStudent)
12 inner join Assignment using(IDStudent , IDExam)
inner join Exam on ( Execution.IDExam=Exam.IDExam)
14 inner join Composition on ( Assignment.IDTest=Composition.IDTest)
left join Answer on ( Composition.IDQuestion=Answer.IDQuestion and
16 Execution.IDStudent=Answer.IDStudent and Execution.IDExam=Answer.IDExam)
WHERE Execution.IDExam like IDExam and
18 Execution.Result not like ’R’
GROUP BY Execution.IDStudent
Si analizza ora la query: le righe 5–8 assegnano i pesi ai vari tipi di risposte; la riga 9 aggiunge
un eventuale punteggio correttivo; la riga 3 fa una media di tutte le risposte raggruppate per
singoli studenti come definito nella riga 19; la riga 10 converte i punteggi espressi in centesimi,
in voti espressi in trentesimi moltiplicando i punteggi per la pendenza della retta di conversione
e aggiungendo l’offset; le righe 11–16 specificano le relazioni tra le tabelle considerate; in
particolare la riga 15 esegue un join sinistro per tenere conto anche delle risposte non date;
infine le righe 17 e 18 selezionano l’esame identificato dal codice IDExam e gli studenti che
non si sono ritirati nel corso dell’esame.
6.3.2 Assegnazione dei compiti agli studenti
Prima di attivare un esame `e necessario assegnare agli studenti iscritti uno o pi`u compiti
preparati in precedenza; la procedura di assegnazione prevede che il docente scelga alcuni tra
i compiti disponibili e che l’applicazione li assegni automaticamente a tutti gli studenti; deve
essere tenuto conto anche del numero di studenti per gruppo che possono accedere contempo-
raneamente a sostenere l’esame (corrisponde almeno alla capienza dell’aula di informatica).
Il criterio che viene seguito per l’assegnazione `e il seguente:
• si calcola il numero di gruppi di studenti che sosterranno l’esame (cio`e il numero di
studenti iscritti diviso per gli studenti per gruppo);
• si dividono i compiti da assegnare per il numero di gruppi;
• se non sono abbastanza si assegnano ciclicamente i compiti ai gruppi (perci`o alcuni
gruppi avranno lo stesso compito);
• i compiti destinati ad ogni gruppo vengono assegnati alternativamente e ciclicamente
agli studenti in ordine alfabetico;
• per ogni studente viene creata una password che assieme al numero di matricola iden-
tifica univocamente l’esame.
Questo algoritmo `e implementato dalla seguente procedura:
p u b l i c boolean assignTestExam ( String [ ] strIDsTest ) {
2 boolean b = true ;
ArrayList IDsStudent = getQueryColumn ( ”SELECT Student . IDStudent ” +

86. 6.3 Model: i JavaBeans 75
4 ”FROM Registration natural j o i n Student ” +
”WHERE Registration . IDExam l i k e ” + IDExam + ” ”
6 ”ORDER BY Student . Surname , Student .Name” , 1 ) ;
i n t RegisteredStudent = IDsStudent . s i z e ( ) ;
8 i n t StudentPerGroup = Integer . parseInt (
( String ) getQueryValue ( ”SELECT MaxStudentGroup from Exam ” +
10 ”WHERE IDExam l i k e ” + IDExam ) . get ( ”MaxStudentGroup” ) ) ;
i n t NoTest = strIDsTest . length ;
12 i n t NoGroup = Functions . roundUp (( double ) RegisteredStudent /
( double ) StudentPerGroup ) ;
14 i n t NoMinTestPerGroup = Functions . roundDown (( double ) NoTest /
( double )NoGroup ) ;
16 i n t Group=0;
i n t Test =0;
18 i n t StudentInGroup=0;
i n t TestInGroup=0;
20 i n t NoStPerTest=0;
i n t TestCount=0;
22 f o r ( i n t St =0; StRegisteredStudent ; St++) {
i f ( ( St % StudentPerGroup)==0) {
24 Group++;
Test += TestInGroup ;
26 TestCount=0;
StudentInGroup = (GroupNoGroup?StudentPerGroup :
28 ( RegisteredStudent%StudentPerGroup ) ) ;
TestInGroup = (Group=(NoTest−(NoGroup∗NoMinTestPerGroup ))?
30 ( NoMinTestPerGroup+1):Math .max(1 , NoMinTestPerGroup ) ) ;
NoStPerTest = Functions . roundUp (( double ) StudentInGroup /
32 ( double ) TestInGroup ) ;
}
34 b = addAssignment (( String ) IDsStudent . get ( St ) ,
strIDsTest [ ( Test + ( TestCount++ % TestInGroup )) % NoTest ] , Group ) ;
36 }
}
Alla riga 3 viene recuperata dal database la lista degli studenti iscritti all’esame; le righe 7–21
definiscono alcune variabili utili per i calcoli successivi (per esempio il numero dei compiti
per gruppo, il numero di studenti iscritti, ecc.); il ciclo for della riga 22 scorre tutti gli
studenti iscritti in ordine alfabetico; le righe 23–33 vengono eseguite solamente quando si sta
per iniziare l’assegnazione dei compiti ad un gruppo di studenti; infine la riga 34 richiama,
per ogni iscritto, la funzione addAssignment che aggiorna la base di dati e calcola la password
di accesso per lo studente, assicurandosi che non ne sia gi`a stata assegnata un’altra di uguale.
6.3.3 Calcolo della difficolt`a dei quesiti
La difficolt`a di un quesito viene calcolata utilizzando la media delle correttezze delle risposte
date dagli studenti fino a quel momento. Questa operazione viene svolta dalla procedura

87. 76 Progettazione dell’applicazione server
setQuestionsDifficulty utilizzando un’unica query che restituisce la lista dei quesiti con i
relativi indici di difficolt`a:
SELECT Question.IDQuestion ,
2 round(avg(ifnull(Answer.Value ,0))*( -100) + 100) as NewDifficulty ,
Question.Difficulty as OldDifficulty
4 FROM Student inner join Execution using(IDStudent)
inner join Assignment using(IDStudent , IDExam)
6 inner join Exam on ( Execution.IDExam=Exam.IDExam)
inner join Composition on ( Assignment.IDTest=Composition.IDTest)
8 inner join Question using ( IDQuestion)
left join Answer on ( Composition.IDQuestion=Answer.IDQuestion and
10 Execution.IDStudent=Answer.IDStudent and Execution.IDExam=Answer.IDExam)
WHERE Exam.IDCourse like IDCourse
12 GROUP BY Question.IDQuestion
HAVING ( OldDifficulty is null ) or ( OldDifficulty not like NewDifficulty)
14 ORDER BY Question.IDQuestion
La riga 2 calcola la media dei valori delle risposte che per`o esprimono la correttezza compresa
tra 0 e 1, mentre la difficolt`a si esprime in centesimi; esegue quindi anche la conversione
Difficolt`a = 1 − Correttezza. Le righe 4–10 definiscono le relazioni tra le tabelle; la riga 11
seleziona solamente i quesiti del corso scelto; la riga 12 specifica che le medie devono essere
fatte tra le risposte di ogni singolo quesito; infine la riga 13 evita che vengano selezionati i
quesiti per i quali non c’`e alcuna variazione della difficolt`a, evitando che vengano inutilmente
riaggiornate.
6.4 View: le JSP
Come si `e detto nell’introduzione la View dell’applicazione `e responsabile della visualiz-
zazione delle pagine HTML generate dinamicamente in base ai dati contenuti nel database;
la soluzione naturale per questo compito `e l’utilizzo delle JavaServer PagesTM. Per essere
aderenti allo schema MVC e per sfruttarne al meglio i vantaggi offerti, si sono fatte queste
scelte:
• all’interno della pagina JSP non si sono usati elementi di scripting (dichiarazioni, script-
let o espressioni) cos`ı da rendere pi`u leggibile la pagina e separare la struttura dalla
presentazione dei dati; il codice va invece inserito o nel Controller o nel Model;
• la JSP deve accede al database o al bean per leggere i dati necessari alla costruzione
della pagina, ma non deve modificare il modello o il database; questo `e utile per separare
funzionalmente la JSP e consente una pi`u facile correzione degli errori;
• per ovviare all’assenza di codice nelle JSP si `e ricorso ai JavaBean e alle librerie di tag
personalizzati (in particolare le Taglibs) che consentono di reperire i dati dal database,
dalla sessione o dall’oggetto che rappresenta la richiesta HTTP.
Queste regole isolano funzionalmente i vari moduli dell’applicazione Web e consentono di
modificare, per esempio, la visualizzazione di una pagina o di pi`u pagine preservando la
logica di funzionamento dell’applicazione.

88. 6.4 View: le JSP 77
Database relazionale SQL
Pagina web di e-Val
Documento HTML dinamico
Codice JavaScriptFoglio di stile CSS
Allegati
contiene le procedure che
vengono eseguite dal browser
per migliorare l’uso
dell’interfaccia utente
contiene le definizioni
sullo stile grafico della
pagina
Java Servlet
Java Server Page
Parte HTML statica (modello)
Istruzioni per il JSP container (direttive)
Tag JSP standard (in formato XML)
Tag personalizzati (es. accesso al database)
Codice Java (scriptlet)
è un file di testo
simile all’HTML
contiene i dati da
visualizzare e la struttura
logica della pagina
Traduzione (compilazione)
Esecuzione del servlet
Risultato della query
Interrogazione (query)
Figura 6.6: Costruzione di una pagina HTML da una JSP.
Nella figura 6.6 `e illustrato il processo che porta alla visualizzazione della pagina HTML
sul browser del computer remoto. Se `e la prima volta che viene chiamata la JSP, il servlet
container la traduce in un servlet, lo compila, lo carica nella JVM e lo esegue; alle chiamate
successive il container si limiter`a ad eseguire il servlet gi`a compilato. L’esecuzione del servlet
produce un documento HTML che viene inviato al browser; la visualizzazione e l’interazione
con l’utente vengono facilitati dall’uso dei fogli di stile e di codice JavaScript.
Per richiamare una JSP il servlet che funge da controller deve eseguire:
RequestDispatcher dispatcher ;
dispatcher = getServletContext ( ) . getRequestDispatcher ( ”/NewExam. jsp ” ) ;
dispatcher . forward ( request , response ) ;
La logica di scelta delle JSP `e gi`a stata descritta sia per l’interfaccia docente (si veda la
figura 6.3) sia per quella studente (si veda la figura 6.4).

89. 78 Progettazione dell’applicazione server
6.4.1 Struttura di una JSP
Viene ora analizzata la struttura tipica di una JSP. Bisogna ricordare che una JavaServer
Page `e un file di testo in formato XML in cui, tra i vari tag, vengono inseriti i pezzi di codice
HTML necessario per la visualizzazione. Ogni pagina inizia con:
%@ t a g l i b uri=”http: // jakarta . apache . org / t a g l i b s / dbtags ” p r e f i x=”sql ” %
2 %@ t a g l i b uri=”http: // jakarta . apache . org / t a g l i b s / request −1.0”
p r e f i x=”req” %
4 %@ t a g l i b uri=”http: // jakarta . apache . org / t a g l i b s / session −1.0”
p r e f i x=”s e s s ” %
6 %@ t a g l i b uri=”http: // jakarta . apache . org / t a g l i b s / u t i l i t y ” p r e f i x=”x” %
jsp:useBean id=”teacherDB ” scope=”s e s s i o n ”
8 c l a s s=”eValServer . dbTeacherModel”/
jsp:useBean id=”TeacherConnection ” scope=”request ”
10 c l a s s=”java . sql . Connection ”/
!DOCTYPE HTML PUBLIC ”−//W3C//DTD HTML 4 . 0 1 Transitional //EN”
12 ” http: //www. w3 . org /TR/html4/ loose . dtd”
in cui i primi quattro tag dichiarano quali librerie si vogliono utilizzare nella pagina; la riga 7
permette di usare il JavaBean denominato teacherDB per recuperarne le propriet`a da inserire
nella pagina; la riga 9 dichiara invece che la connessione al database deve essere passata alla
JSP come parametro della richiesta HTTP (questo consente il riciclo della connessione e la
sua restituzione al pool di connessioni); infine la riga 11 specifica il tipo e la versione del
documento HTML.
All’interno del tag HEAD, che rappresenter`a l’intestazione della futura pagina HTML,
vengono inserite le righe
META http−equiv=”CONTENT−TYPE” content=”text /html ; charset=iso −8859−1”
LINK REL=s t y l e s h e e t HREF=”Common/ eVal style . css ” TYPE=”text / css ”
SCRIPT type=”text / j a v a s c r i p t ” src=”Common/ e V a l s c r i p t . j s ”/SCRIPT
che specificano al browser il tipo di contenuto, il set di caratteri, il foglio di stile CSS e il file
con il codice JavaScript.
L’accesso al database per recuperare i dati da inserire nella pagina, avviene tramite la
libreria di tag DBTags; per recuperare, ad esempio, gli esami di un determinato corso e
inserirli in una lista di selezione di un form basta scrivere:
sql:statement id=”stmt ” conn=”TeacherConnection”
2 . . .
FORM method=POST name=’Exam’ action = ’ ’
4 DIV c l a s s =’FormHead ’Esami/DIV
sql:query
6 SELECT concat(Name , ’ [’, date_format(ExamDate ,’%d %M %Y, %H:%i’), ’]’),
IDExam
8 FROM Exam
WHERE IDCourse like jsp:getProperty name=teacherDB property=idCourse/ and
10 ExamDate SUBDATE(curdate (), INTERVAL

90. 6.5 Schema fisico dell’applicazione 79
jsp:getProperty name=teacherDB property=months/ MONTH)
12 ORDER by Active DESC , ExamDate DESC
/ sql:query
14 SELECT s i z e = ’4 ’ multiple name=’IDExam’
ondblclick=”SelectSubmit ( this , ’ ShowExam . teacher ’ ) ; ”
16 s q l : r e s u l t S e t id=”rs ”
OPTION value=sql:getColumn p o si tio n =”2”/
18 sql:getColumn positio n =”1”/
/ s q l : r e s u l t S e t
20 /SELECTBR
A href=”j a v a s c r i p t : SelectSubmit ( document .Exam. IDExam,
22 ’ShowExam . teacher ’ ) ; ”Vai/A
A href=”j a v a s c r i p t : FormSubmit( document .Exam,
24 ’NewExam. teacher ’ ) ; ”Nuovo/A
A href=”j a v a s c r i p t : i f ( confirm ( ’ Sei sicuro di voler eliminare
26 g l i esami s e l e z i o n a t i ? ’ ) ) SelectSubmit ( document .Exam. IDExam,
’ DeleteExams . teacher ’ ) ; ”Elimina/A
28 /FORM
. . .
30 / sq l : statement
La prima riga crea lo statement per accedere al database; la riga 5 dichiara l’inizio di una
query; le righe 6–12 specificano la query (si noti alla riga 9 la presenza di un tag predefinito che
recupera la propriet`a idCourse del JavaBean che specifica l’identificatore del corso scelto);
alla riga 17 il tag sql:getColumn position=2/ inserisce il secondo campo del risultato
della query all’interno del tag OPTION; le righe 13 e 19 specificano che `e necessario scorrere
tutti i record del risultato; le righe 21–27 mostrano come si possano inserire delle funzioni
JavaScript all’interno di un link ipertestuale.
6.5 Schema fisico dell’applicazione
Come si `e gi`a detto, l’applicazione segue il modello di una 3 Tier Architecture in cui ci sono il
client e il database separati dall’applicazione Web. La figura 6.7 mostra come sia fisicamente
realizzato il sistema completo: i blocchi di colore grigio rappresentano i computer della rete
con all’interno le varie applicazioni software. `E interessante notare due cose:
• i clients, siano essi del docente o dello studente, si collegano tramite HTTP al Sever
Web che pu`o trovarsi ovunque nella rete; dall’altra parte il DBMS `e collegato al driver
JDBC del server Web, attraverso una connessione TCP/IP; la separazione quindi tra
clients e database `e totale;
• i computer possono avere come sistema operativo sia Linux che Windows; questo aumenta
la portabilit`a del sistema.

91. 80 Progettazione dell’applicazione server
Web server: Windows/UNIX
JVM
java bean
dbAttachmentAccess
java bean
dbStudentModel
JDBC driver
java bean
dbTeacherModel
servlet container
Apache Jackarta Tomcat
servlet
Teacher controller
servlet
Student controller
servlet
Attachment controller
Computer studente: Windows/UNIX
Database server: Windows/UNIX
database management system
MySQL
JVM
e-Val Student
Computer docente: Windows/UNIX
Web browser:Mozilla/IE/Netscape
JVM
HTTP
TCP/IP
e-Val Question Manager
HTTP
Figura 6.7: Schema dell’implementazione e della disposizione fisica delle varie
componenti dell’applicazione.

92. Capitolo 7
Progettazione dei client
La connessione degli utenti al sistema avviene tramite applicazioni Java Swing o browsers,
utilizzando il protocollo HTTP. I client che si possono collegare al server sono:
• e–Val Question Manager che permette l’inserimento e la modifica dei quesiti nel database
da parte dei docenti;
• i browsers, che offrono l’accesso ai servizi offerti dall’applicazione web per i docenti e
gli amministratori;
• e–Val Student che consente agli studenti di poter autenticarsi, accedere ad un esame e
rispondere ai quesiti del compito assegnato.
Tutti i client permettono di visualizzare delle pagine HTML che vengono generate dinamica-
mente dal server; ci`o `e possibile usando la classe JEditorPane di Swing.
I client Java sono contenuti in due file eseguibili di tipo .jar:
• eValQuestionManager.jar che racchiude:
∗ il file Manifest.mf nella directory meta-inf che contiene le informazioni sul-
l’archivio compresso;
∗ il file TeacherConfiguration.xml contenente le informazioni di configurazione del
client (tra cui il nome del server Web predefinito a cui accedere);
∗ i files AnytextModel.html, CheckboxModel.html, RadioModel.html, RangeMo-
del.html sono quattro esempi, uno per ogni tipologia di quesito, che possono
essere usati in e-Val; il loro inserimento `e stato automatizzato e pu`o avvenire dalla
console dell’applicazione;
∗ il package com.arthurdo.parser contiene le classi usate dall’analizzatore dei do-
cumenti HTML;
∗ il package com.oreilly.servlet contiene la classe HttpMessage per l’invio dei
messaggi HTTP al server;
∗ il package eVal contiene le classi di uso comune dell’applicazione;

93. 82 Progettazione dei client
∗ il package eValTeacher contiene le classi principali del client del docente;
• eValStudent.jar che racchiude:
∗ il file Manifest.mf nella directory meta-inf che contiene le informazioni sul-
l’archivio compresso;
∗ il file StudentConfiguration.xml contenente le informazioni di configurazione del
client (tra cui il nome del server Web predefinito);
∗ il package com.arthurdo.parser contiene le classi usate dall’analizzatore dei do-
cumenti HTML;
∗ il package com.oreilly.servlet contiene la classe HttpMessage per l’invio dei
messaggi HTTP al server;
∗ il package eVal contiene le classi di uso comune dell’applicazione;
∗ il package eValStudent contiene le classi principali del client dello studente.
Poich´e non contengono i driver JDBC per l’accesso al database e il parser HTML `e abbastanza
elementare, le dimensioni dei due files sono molto contenute: 39 KB per eValStudent.jar
e 55 KB per eValQuestionManager.jar .
7.1 Il client del docente: e–Val Question Manager
L’applicazione si basa sui componenti Java Swing per l’interfaccia grafica e per la gestione
degli eventi generati dai bottoni della finestra. Quando viene avviata, legge prima di tutto
le informazioni di configurazione, tra cui il nome del server Web a cui deve collegarsi per
richiedere i servizi necessari; la seguente funzione serve allo scopo:
p r i v a t e void initParameters ( ) {
2 . . .
HashMap Parameters = new ConfigurationHandler ( ” teacher−c l i e n t ” ,
4 new InputStreamReader ( ConfigFile ) ) . getConfiguration ( ) ;
i f ( Parameters . s i z e () 0) {
6 SERVER = ( String ) Parameters . get ( ” host ” ) ;
SERVLET PATH = ( String ) Parameters . get ( ” s e r v l e t p a t h ” ) ;
8 i f ( !SERVLET PATH. endsWith ( ”/” ) ) SERVLET PATH += ”/” ;
EXT = ( String ) Parameters . get ( ” servlet mapping extension ” ) ;
10 }
. . .
Alla riga 3 la classe ConfigurationHandler legge i parametri di configurazione dal file XML
TeacherConfiguration.xml; alle righe 6–9 vengono impostati il nome del server Web, il
percorso dell’applicazione e l’estensione degli URI (Uniform Resource Identifier). La lettura
del file di configurazione avviene tramite l’uso di un parser simile a quello impiegato per i
quesiti HTML (si veda la sezione 7.1.1).
Successivamente il client chiede di inserire la login e la password del docente e le spedisce
al server per l’autenticazione:

94. 7.1 Il client del docente: e–Val Question Manager 83
TeacherLogin =
2 ( String ) Authentication . getAuthenticationData ( ) . get ( ”Login” ) ;
TeacherPassword =
4 ( String ) Authentication . getAuthenticationData ( ) . get ( ”Password” ) ;
String AuthenticationServer = URL SERVLET +
6 ” RequestAuthentication . ” + EXT;
Properties props = new Properties ( ) ;
8 props . put ( ”Login” , TeacherLogin ) ;
props . put ( ”Password” , TeacherPassword ) ;
10 props . put ( ”Applet” , ” true ” ) ;
String AuthenticationResponse =
12 ServerResponse ( AuthenticationServer , props ) ;
alle righe 1–4 recupera dal form di autenticazione la login e la password che vengono inserite
come parametri nel messaggio HTTP da inviare al server (righe 8–10). Se l’autenticazione
ha avuto successo, il server risponde (AuthenticationResponse alla riga 11) con una pagina
HTML di questo tipo:
!DOCTYPE HTML PUBLIC ”−//W3C//DTD HTML 4 . 0 1 Transitional //EN”
” http ://www. w3 . org /TR/html4/ loose . dtd”
HTML
HEADTITLEDati di a u t e n t i c a z i o n e/TITLE
/HEAD
BODY
CENTER
INPUT type=hidden name=authentication value=
”aut; j s e s s i o n i d=ED7E97994F7FF9F0035C3FBA9CCB1C93/aut”
/CENTER
/BODY
/HTML
da cui il client estrae l’identificatore della sessione (contenuto nel campo nascosto authenti-
cation) necessario per le successivamente identificazioni dello studente.
Gli eventi generati dalla finestra del client vengono gestiti dai metodi contenuti nella classe
principale
p u b l i c c l a s s TeacherClient extends javax . swing . JFrame
Quando viene premuto un bottone della finestra o viene selezionato l’elemento di una lista, la
classe JFrame richiama i metodi appropriati (per esempio buttonHTMLSourceMouseClicked
oppure comboModelItemStateChanged) passando come parametro il tipo di evento che l’ha
generato (per esempio java.awt.event.MouseEvent).
I messaggi di risposta del server non necessariamente sono delle pagine HTML (per esem-
pio nel caso della sincronizzazione del tempo); la seguente funzione `e usata dal client per
recuperare dei generici messaggi in formato stringa:
p r i v a t e String ServerResponse ( String serverURL , Properties props ) {
2 try {

95. 84 Progettazione dei client
HttpMessage msg = new HttpMessage (new URL( serverURL ) ) ;
4 BufferedReader in = new BufferedReader (
new InputStreamReader (msg . sendPostMessage ( props ) ) ) ;
6 String inputLine ;
StringBuffer Response = new StringBuffer ( ) ;
8 while ( ( inputLine = in . readLine ( ) ) ! = n u l l )
Response . append ( inputLine ) . append ( ”n” ) ;
10 in . c l o s e ( ) ;
return Response . toString ( ) ;
12 } catch ( Exception e ) {
setError ( ” Errore di comunicazione con i l server : ” + e . getMessage ( ) ) ;
14 return ”” ;
}
16 }
Al metodo viene passato un URL con gli eventuali parametri (props); alla riga 3 viene
preparato il messaggio HTTP (si veda la descrizione della classe HttpMessage nella sezione
3.1.1); alla riga 4 viene preparato un buffer per raccogliere il flusso di caratteri in arrivo dal
server e alla riga 5 viene inviato il messaggio; alle righe 8 e 9 viene letta la risposta. A questo
punto il client costruisce la finestra principale e mostra al docente la pagina di benvenuto di
e–Val Question Manager.
L’uso dell’applicazione `e illustrato nel capitolo dei manuali del docente (vedi 10.2).
7.1.1 Il parser dei file HTML
I quesiti di cui sono formati i compiti, devono essere in formato HTML; possono anche avere
delle immagini allegate. Non sono per`o immediatamente adatti all’inserimento nel datbase
per i seguenti motivi:
• i tag delle eventuali immagini allegate contengono i riferimenti locali degli oggetti;
• hanno alcune informazioni di intestazione;
• potrebbero non contenere di campi adatti alle risposte o contenerne di errati;
• le risposte corrette potrebbero essere assenti o specificate in modo errato.
Per questi motivi si ricorre all’uso di un parser che analizza tutto il codice HTML dei
quesiti che devono essere inseriti e svolge queste funzioni:
• scarta i tags HTML o le sezioni che non interessano ai fini del quesito o che potreb-
bero creare dei problemi una volta inserite in una pagina JSP; i tag inutili sono rap-
presentati da HTML, FORM e BODY; le sezioni scartate sono HEAD, SCRIPT,
TITLE e STYLE; a queste si aggiungono gli eventuali tags scelti dall’utente (indicati
nell’interfaccia grafica come Tag da escludere);
• elimina gli attributi inclusi in alcuni tag (come per esempio il tag P che spesso contiene
informazioni sulla formattazione del testo);

96. 7.1 Il client del docente: e–Val Question Manager 85
/TeacherClient : JFrame /qh : QuestionHandler
/ : HTMLDriver
/ParserOption : ParserOptionClass
/hst : HtmlStreamTokenizer
1.2 : parse ()
1.2.1.5.2 : printElement ()
1.2.1.8.1 : print ()
1.2.1.11.2 : printElement ()
1.1 : addOption ()
1.2.1.5.1 : isSet ()
1.2.1.11.1 : isSet ()
1 : ParseQuestion ()
/:
1.2.1 : parse ()
1.2.1.1 : startDocument ()
1.2.1.5 : startElement ()
1.2.1.8 : text ()
1.2.1.11 : endElement ()
1.2.1.13 : endDocument ()
1.2.1.2 : nextToken ()
1.2.1.3 : getTokenType ()
1.2.1.4 : parseTag ()
1.2.1.6 : nextToken ()
1.2.1.7 : getStringValue ()
1.2.1.9 : nextToken ()
1.2.1.10 : parseTag ()
1.2.1.12 : nextToken ()
1.2 : parse ()
1.2.1.5.2 : printElement ()
1.2.1.8.1 : print ()
1.2.1.11.2 : printElement ()
1.1 : addOption ()
1.2.1.5.1 : isSet ()
1.2.1.11.1 : isSet ()
1 : ParseQuestion ()
1.2.1 : parse ()
1.2.1.1 : startDocument ()
1.2.1.5 : startElement ()
1.2.1.8 : text ()
1.2.1.11 : endElement ()
1.2.1.13 : endDocument ()
1.2.1.2 : nextToken ()
1.2.1.3 : getTokenType ()
1.2.1.4 : parseTag ()
1.2.1.6 : nextToken ()
1.2.1.7 : getStringValue ()
1.2.1.9 : nextToken ()
1.2.1.10 : parseTag ()
1.2.1.12 : nextToken ()
Figura 7.1: Interazioni tra i moduli del parser HTML in seguito alla richiesta di
eseguire l’analisi di un documento (1:ParseQuestion()).
• trova le immagini allegate, le inserisce nel database e sostituisce nel documento l’indi-
rizzo corretto per il loro reperimento;
• individua il tipo di risposte presenti nel documento e segnala eventuali errori;
• interpreta le risposte corrette e le inserisce nel database.
La figura 7.1 mostra quali siano le interazioni tra i vari oggetti usati per il parsing; in partico-
lare vengono elencati, in ordine cronologico, i metodi utilizzati per l’analisi di un documento
molto semplice, costituito da un tag di apertura, un corpo e un tag di chiusura. Si vede come
la classe QuestionHandler, derivata da HTMLDriver di cui definisce i metodi astratti, debba
contenere il codice che gestisce gli eventi generati da HtmlStreamTokenizer; quest’ultima
classe, infatti, analizza sequenzialmente il contenuto del documento HTML riconoscendone i
tag, gli attributi e le parti di testo.
La classe QuestionHandler inserisce nel database le immagini che incontra e i quesiti
serializzando i due oggetti AttachmentClass e QuestionClass e inviandoli al server:

97. 86 Progettazione dei client
p r i v a t e String FromServer ( String HttpQuery , S e r i a l i z a b l e obj ) {
2 try {
return FromServer ( ServerRequest ( HttpQuery ) . sendPostMessage ( obj ) ) ;
4 } catch ( IOException e ) {
ParserMessage ( ” [#] Errore n e l l a comunicazione con i l server ( obj ) ! ” ) ;
6 return ”” ;
}
8 }
in cui alla riga 3 il metodo ServerRequest restituisce l’oggetto HttpMessage corrispondente
all’URL desiderato (HttpQuery).
7.2 I browsers Web
I broswers consentono al docente e all’amministratore di accedere via Web ai servizi messi
a disposizione da e-Val. I problemi maggiori incontrati nello sviluppo delle pagine HTML
dinamiche riguardano proprio i diversi gradi di compatibilit`a dei browser con gli standard in
circolazione (vedi tabella 2.1); a tal proposito si sono testate con successo le seguenti versioni:
Mozilla 1.1, Microsoft Internet Explorer 6.0 e Netscape 7.0. Altri browser, come per esempio
Opera o versioni precedenti di Netscape, non offrono un supporto soddisfacente ai fogli di
stile.
7.2.1 I fogli di stile: CSS
I fogli di stile permettono di separare la struttura di un documento HTML dal suo layout. A
questo scopo sono stati realizzati i seguenti files:
• eVal style.css: descrive lo stile dell’applicazione Web del docente; poich´e i browser
supportano quasi pienamente lo standard CSS, sono state usate anche caratteristiche
avanzate;
• Question style.css: descrive lo stile di visualizzazione dei quesiti;
• Student style.css: descrive lo stile delle pagine HTML visualizzate da e–Val Student
durante l’esecuzione dell’esame; i comandi sono semplici poich´e JEditorPane non sup-
porta interamente i fogli di stile (l’orientamento degli sviluppatori di Java `e comunque
quello di estenderne il supporto nelle versioni successive);
• Welcome style.css: descrive lo stile delle pagine di benvenuto;
7.2.2 Il linguaggio di scripting client–side: JavaScript
Per migliorare l’interazione con l’utente, migliorare l’interfaccia grafica e ridurre il numero di
bottoni dei form, si `e ricorso all’inserimento di semplici pezzi di codice JavaScript che vengono
eseguiti dal browser dell’utente. Non si sono riscontrati problemi di compatibilit`a con i diversi
browsers. Le procedure sono contenute in due files:

98. 7.3 Il client dello studente: e–Val Student 87
• Calendar.js: contiene il codice per la creazione e la gestione del calendario per la scelta
della data e dell’ora di un appello d’esame;
• eVal script.js: contiene le procedure per la gestione dei form HTML; per esempio la
selezione di tutti gli elementi di una lista viene realizzata dalla seguente funzione:
function CheckAll ( xCheck ) {
i f ( xCheck . length==undefined )
xCheck . checked=true ;
e l s e
f o r ( var i = 0; i xCheck . length ; i ++) xCheck [ i ] . checked=true ;
}
7.3 Il client dello studente: e–Val Student
Il funzionamento, le procedure di inizializzazione, di autenticazione e di comunicazione con il
server di questa applicazione Java sono del tutto simili a quelle di e–Val Question Manager del
docente e descritte nella sezione 7.1. Questo client contiene in pi`u una classe interna derivata
da TimerTask per la temporizzazione delle seguenti operazioni:
• visualizzare ad intervalli regolari il form di autenticazione dello studente;
• decrementare il tempo rimasto a disposizione dello studente per completare il compito;
• sincronizzare periodicamente il tempo rimanente del client con quello del server;
• eseguire il countdown per la chiusura dell’applicazione nel caso in cui riceva dal server
il comando di chiusura.
L’inizializzazione del timer avviene in questo modo:
p r i v a t e TimeClass Clock ;
p r i v a t e Timer ClientTimer = new Timer ( ) ;
. . .
Clock = new TimeClass ( TimerPeriod ) ;
ClientTimer . schedule ( Clock , TimerPeriod ∗1000 , TimerPeriod ∗1000);
A questo punto, dopo ogni TimerPeriod secondi viene eseguito il metodo run() della classe
TimeClass:
p u b l i c void run ( ) {
2 SecondsElapsed += TimeInterval ;
i f ( ExamRunning Logged ) {
4 //L ’ esame `e in corso
i f ( ( SecondsElapsed % SecondsTimeSync ) == 0){
6 i f ( ! getServerTime ( ) ) {
Decrement ( ) ;
8 setLoginButton ( true ) ;
} e l s e setLoginButton ( f a l s e ) ;

99. 88 Progettazione dei client
10 }
i f ( t h i s . SecondsLeft =0 || ConnectionRetry 20) {
12 ExamRunning = f a l s e ;
ExamEnd = true ;
14 setTimeout ( ) ;
} e l s e {
16 Decrement ( ) ;
TimeRefresh ( ) ;
18 }
} e l s e i f (ExamEnd) {
20 //L ’ esame `e concluso : s i sta facendo i l countdown per l a chiusura
Decrement ( ) ;
22 i f ( CloseTimeout 0) {
// Chiude i l c l i e n t
24 CloseClient ( ) ;
}
26 } e l s e i f ( ConnectionRetry 2 0 | | AuthenticationRetry 5) {
ExamRunning = f a l s e ;
28 ExamEnd = true ;
setTimeout ( ) ;
30 } e l s e i f ( Logged ( SecondsElapsed % InitialTimeSync ) == 0) {
//L ’ esame deve ancora cominciare : i l c l i e n t a s p e t t a dal server
32 // i l segnale d ’ i n i z i o
getServerTime ( ) ;
34 i f ( t h i s . SecondsLeft 0) {
ExamRunning = true ;
36 TimeRefresh ( ) ;
}
38 } e l s e i f ( ! Logged ! Logging
( SecondsElapsed % SecondsBeetwenLogin ) == 0) {
40 //L ’ esame deve ancora cominciare : i l c l i e n t esegue
// l ’ a u t e n t i c a z i o n e d e l l o studente
42 Logging = true ;
AuthenticateStudent ( ) ;
44 Logging = f a l s e ;
}
46 }
Poich´e il server non ha alcuna possibilit`a di connettersi direttamente con il client per in-
formarlo di un qualsiasi cambiamento di stato (per esempio lo studente potrebbe aver gi`a
risposto a tutti i quesiti e quindi avrebbe terminato l’esame), `e il client che periodicamente
richiede la sincronizzazione con il server (riga 6); se il server non risponde viene comunque
decrementato il tempo rimasto (riga 7) e viene abilitato il bottone che permette un nuovo
login dello studente (riga 8); se il tempo a disposizione dello studente `e scaduto o se il server
ad una richiesta di sincronizzazione ha risposto con un valore negativo (riga 11), il client inizia
le procedure di chiusura temporizzata (righe 19–25).

100. Capitolo 8
Organizzazione del codice
Questo capitolo contiene la descrizione dei packages che compongono l’applicazione e illustra
i rapporti che intercorrono tra le varie classi. Gli schemi UML delle classi adottano queste
notazioni:
Package
Package
rappresenta un package Java contenente pi`u classi;
Classe
Classe
rappresenta una classe Java; possono essere visualizzati o
meno gli attributi e i metodi;
Dipendenza
Classe A Classe B
la freccia tratteggiata mette in relazione di dipendenza due
classi; questo indica che a un cambiamento della Classe B
deve seguire una modifica della Classe A;
Generalizzazione
Classe A Classe B
la freccia continua mette in relazione di parentela due
classi; la Classe B rappresenta il padre mentre la Classe A
il figlio; in Java significa che la Classe A estende la Classe B.
Le classi che formano l’applicazione sono raccolte in quattro packages che ora verranno
brevemente descritti.

101. 90 Organizzazione del codice
8.1 Package eVal
eVal
ConfigurationHandler
ReadingParameters : boolean
ReadingName : boolean
ReadingValue : boolean
Name : String
Value : String
Parameters : HashMap
RootTag : String
ErrorOccurred : boolean
strError : String
create ConfigurationHandler(RootTag: String,XMLreader: Reader)
setError(strError: String) : void
getError() : String
getConfiguration() : HashMap
error(str: String) : void
startDocument() : void
endDocument() : void
startElement(tag: void) : void
endElement(tag: void) : void
text(str: String) : void
HTMLDriver
create HTMLDriver()
parse(HTMLReader: Reader) : void
startDocument() : void
startElement(tag: void) : void
text(str: String) : void
endElement(tag: void) : void
error(msg: String) : void
endDocument() : void
Answer
RIGHT_ANSWER_SCORE : float
WRONG_ANSWER_SCORE : float
INPUT_NAME : String
ANSWER_SEPARATOR : String
Answers : ArrayList
AnswerType : String
NullAnswer : boolean
Score : int
create Answer(Content: String[],AnswerType: String)
create Answer(Content: String,AnswerType: String)
parseAnswer(strAnswer: String) : void
getAnswerString() : String
getAnswerType() : String
size() : int
contains(str: String) : boolean
getRange() : RealInterval[]
compareAnswer(RightAnswer: Answer) : float
isValidAnswer() : boolean
AttachmentClass
content : byte[]
create AttachmentClass(buffer: byte[])
getContent() : byte[]
setContent(buffer: byte[]) : void
RealInterval
loVal : double
hiVal : double
Val : double
SinglePoint : boolean
create RealInterval(interval: String)
convert(d: String) : double
getLoVal() : double
getHiVal() : double
getVal() : double
isSinglePoint() : boolean
toString(val: double) : String
toString() : String
contains(value: String) : boolean
contains(ri: RealInterval) : boolean
ErrorLog
FILE_NAME : String
fout : FileOutputStream
getLogDirectory() : File
write(str: String) : void
Functions
getCode() : int
getStringCode(length: int) : String
implode(glue: String,ob: Object[]) : String
implode(glue: String,al: ArrayList) : String
explode(separators: String,str: String) : ArrayList
roundUp(d: double) : int
roundDown(d: double) : int
QuestionClass
Memorandum : String
Comment : String
RightAnswer : Answer
update : boolean
Text : StringBuffer
create QuestionClass(Memorandum: String)
setRightAnswer(RightAnswer: Answer) : void
getRightAnswer() : Answer
setComment(Comment: String) : void
getComment() : String
printText(str: String) : void
getText() : String
getMemorandum() : String
finalize() : void
setUpdate(b: boolean) : void
toUpdate() : boolean
Figura 8.1: Classi del package eVal.
Le classi contenute in questo package sono utilizzate sia dall’applicazione sul lato server
che dai client; contiene anche delle classi di utilit`a:
• Answer rappresenta la risposta ad un quesito; pu`o essere di quattro tipi;
• AttachmentClass rappresenta un allegato che il client e–Val Question Manager invia
al server per inserirlo nel database;
• ConfigurationHandler consente di leggere un file di configurazione in formato XML;
`e usato dai client del docente e studente;

102. 8.2 Package eValStudent 91
• ErrorLog scrive nel file dei messaggi dell’applicazione;
• Functions contiene alcune utili funzioni usate da altre classi;
• HTMLDriver scorre un file HTML e genera gli eventi a seconda dei tag che incontra;
per funzionare usa la classe HtmlStreamTokenizer;
• QuestionClass rappresenta un quesito che il client e–Val Question Manager invia al
server per inserirlo nel database; viene serializzato prima dell’invio;
• RealInterval rappresenta un intervallo reale aperto oppure un numero reale singolo.
8.2 Package eValStudent
Questo package costituisce l’applicazione e–Val Student per lo svolgimento dell’esame; le classi
contenute sono:
• AuthenticationPanel pannello per l’autenticazione dello studente;
• StudentClient client Java che permette allo studente di svolgere l’esame;
• StudentClient.TimeClass classe interna per la gestione della temporizzazione del
client; sincronizza anche il tempo a disposizione dello studente con quello del server
Web.
8.3 Package eValTeacher
Questo package costituisce l’applicazione e–Val Question Manager per l’inserimento e la mo-
difica dei quesiti; le classi contenute sono:
• AuthenticationPanel pannello per l’autenticazione del docente;
• OutputLogClass gestisce i messaggi generati del parser;
• ParserOptionClass rappresenta le opzioni che possono essere passate al parser HTML
• QuestionHandler `e il parser HTML; fa l’analisi di uno o pi`u quesiti in formato HTML,
trova ed inserisce nel database gli allegati del file, riconosce le risposte esatte dei quesiti,
modifica o elimina i tag HTML o i loro attributi;
• TeacherClient client Java che permette al docente di inserire i quesiti.
8.4 Package eValServer
Questo package contiene tutto il codice del server Web; implementa un’applicazione che segue
il design pattern MVC (Model–View–Controller). Le classi presenti sono:

103. 92 Organizzazione del codice
swing
JDialog
util
JFrame
TimerTask
eValStudent
TimeClass
TimeInterval : int
SecondsLeft : int
SecondsElapsed : int
create TimeClass(SecondsInterval: int)
Round(N: int) : int
getServerTime() : boolean
run() : void
TimeRefresh() : void
Decrement() : void
setTimeout() : void
AuthenticationPanel
create AuthenticationPanel(parent: Frame,modal: boolean)
getAuthenticationString() : String
getReturnStatus() : int
initComponents() : void
okButtonActionPerformed(evt: ActionEvent) : void
cancelButtonActionPerformed(evt: ActionEvent) : void
closeDialog(evt: WindowEvent) : void
doClose(retStatus: int) : void
StudentClient
create StudentClient(host: String)
create StudentClient()
StartClient() : void
setError(strError: String) : void
initParameters() : void
initComponents() : void
buttonLoginMouseClicked(evt: MouseEvent) : void
formWindowIconified(evt: WindowEvent) : void
formWindowDeactivated(evt: WindowEvent) : void
exitForm(evt: WindowEvent) : void
AuthenticateStudent() : void
Extract(Response: String,tag: String) : String
RequestURL(Action: String) : String
RequestURL(Action: String,Parameters: String) : String
sendServerRequest(strRequest: String) : String
Violation(Type: String,Parameters: String) : void
setLoginButton(b: boolean) : void
CloseClient() : void
main(args: String[]) : void
Figura 8.2: Classi del package eValStudent.
• AttachmentController servlet che restituisce ai client che lo richiedono gli allegati
dei quesiti;
• BackResponseClass viene usata per acquisire l’output delle JSP e inserirlo negli
archivi JAR o ZIP;
• dbAccess implementa le routine d’accesso a basso livello alla base di dati; viene estesa
dalle classi dbAttachmentAccess, dbStudentModel e dbTeacherModel
• dbAttachmentAccess mette a disposizione i metodi necessari per il reperimento degli
allegati;

104. 8.4 Package eValServer 93
• dbInsertQuestion mette a disposizione i metodi necessari per l’inserimento dei quesiti
nel database;
• dbStudentModel implementa i metodi necessari per l’accesso alla base di dati lato
studente (client studente); viene passata come Bean alle JSP che lo necessitano;
• dbTeacherModel implementa i metodi necessari per l’accesso alla base di dati lato
docente (browser); viene passata come Bean alle JSP che lo necessitano;
• QuestionJarHandler viene passata al parser HTML dei quesiti e serve per sostituire
gli indirizzi degli allegati con quelli che permettono l’accesso locale degli allegati; viene
usata per creare una versione salvabile su disco e leggibile dei quesiti nel database;
• StudentController questo servlet rappresenta il controller, nello schema MVC, delle
richieste dello studente che sta svolgendo l’esame;
• TeacherController questo servlet rappresenta il controller, nello schema MVC, delle
richieste del docente.

105. 94 Organizzazione del codice
swing
eVal
JDialogJFrame
HTMLDriver
QuestionClass AttachmentClass
JFileChooser
ConfigurationHandler
eValTeacher
MyFileFilter
AuthenticationPanel
create AuthenticationPanel(parent: Frame,modal: boolean)
getAuthenticationData() : HashMap
clearForm() : void
setInfo(msg: String) : void
hide() : void
getReturnStatus() : int
initComponents() : void
okButtonActionPerformed(evt: ActionEvent) : void
cancelButtonActionPerformed(evt: ActionEvent) : void
closeDialog(evt: WindowEvent) : void
doClose(retStatus: int) : void
TeacherClient
create TeacherClient(host: String)
create TeacherClient()
StartClient() : void
initParameters() : void
ServerResponse(serverURL: String,props: Properties) : String
AuthenticateTeacher() : boolean
Extract(Response: String,tag: String) : String
setError(str: String) : void
enableQuestionPanel(b: boolean) : void
initComponents() : void
buttonSaveQuestionMouseClicked(evt: MouseEvent) : void
buttonHTMLSourceMouseClicked(evt: MouseEvent) : void
buttonInsertQuestionMouseClicked(evt: MouseEvent) : void
buttonCloseMouseClicked(evt: MouseEvent) : void
buttonLoginMouseClicked(evt: MouseEvent) : void
buttonShowQuestionMouseClicked(evt: MouseEvent) : void
comboModelItemStateChanged(evt: ItemEvent) : void
editorHTMLMouseClicked(evt: MouseEvent) : void
ParseQuestion(insert: boolean,Source: Reader,HTMLfile: File) : void
exitForm(evt: WindowEvent) : void
main(args: String[]) : void
QuestionHandler
create QuestionHandler(ParserOption: ParserOptionClass,Question: QuestionClass,ServerOption: HashMap,OutputLog: OutputLogClass)
ParserMessage(msg: String) : void
error(str: String) : void
FromServer(is: InputStream) : String
ServerRequest() : void
FromServer(HttpQuery: String,obj: Serializable) : String
FromServer(HttpQuery: String,props: Properties) : String
startDocument() : void
newDocument(strMemorandum: String) : void
startElement(tag: void) : void
text(str: String) : void
endElement(tag: void) : void
print(str: String) : void
printElement(tag: void) : void
endDocument() : void
endQuestionParsing() : void
ExcludeSection(b: boolean) : void
setAnswer(Type: String,tag: void) : boolean
insertAttachment(imgSRC: String) : String
returnFile(filename: String,out: OutputStream) : void
SaveQuestion() : boolean
isQuestionSaved() : boolean
ParserOptionClass
create ParserOptionClass()
addOption(Name: String,Content: String) : void
isSet(Name: String) : boolean
isSet(Name: String,Ob: String) : boolean
OutputLogClass
create OutputLogClass(JTA: JTextArea)
write(msg: String) : void
clear() : void
Figura 8.3: Classi del package eValTeacher.

106. 8.4 Package eValServer 95
eValServer
AttachmentController
init(config: void) : void
destroy() : void
processRequest(request: void) : void
doGet(request: void) : void
doPost(request: void) : void
getServletInfo() : String
dbAccess
create dbAccess()
create dbAccess(host: String,database: String,user: String,password: String)
setdbConnection(conn: Connection) : boolean
getdbConnection() : Connection
freeDBConnection() : Connection
setError(strError: String) : void
getError() : String
resetError() : void
isErrorOccurred() : boolean
getdbHost() : String
getdbName() : String
getdbUser() : String
getdbPassword() : String
escapeString(str: String) : String
setQuery(str_sql: String) : int
updateQuery(str_sql: String) : int
getRecord() : String[]
resetQuery() : void
getQueryValue(str_sql: String) : HashMap
getOrderedQuery(str_sql: String,ColumnIndex: int) : TreeMap
getQueryColumn(str_sql: String,ColumnIndex: int) : ArrayList
getQuery(str_sql: String) : ArrayList
lastID() : int
finalize() : void
closeStatement() : void
dbAttachmentAccess
dbInsertQuestion
create dbInsertQuestion()
create dbInsertQuestion(host: String,database: String,user: String,password: String)
String2ID(strID: String) : int
setIDCourse(IDCourse: int) : void
setIDCourse(strIDCourse: String) : boolean
getIdCourse() : String
setIDArgument(strIDArgument: String) : boolean
getIdArgument() : String
setIDExam(strIDExam: String) : boolean
getIdExam() : String
setIDTest(strIDTest: String) : boolean
getIdTest() : String
setIDQuestion(strIDQuestion: String) : boolean
getIdQuestion() : String
setIDStudent(strIDStudent: String) : boolean
getIdStudent() : String
isAuthenticated(Login: String,Password: String) : boolean
setFirstIdArgument() : boolean
putEmptyQuestion() : String
InsertQuestion(question: QuestionClass) : boolean
updateQuestion(AnswerType: String,RightAnswer: String,HTMLtext: String) : boolean
updateQuestionFields(Memorandum: String,Comment: String) : boolean
getQuestion() : HashMap
deleteQuestion() : boolean
putAttachment(buffer: byte[]) : String
finalize() : void
dbStudentModel
create dbStudentModel()
create dbStudentModel(host: String,database: String,user: String,password: String)
getIdStudent() : String
getIdQuestion() : String
getIdExam() : String
getCode() : String
getIdTest() : String
getAnswerType() : String
isAuthenticated() : boolean
isExamEnd() : boolean
isRunningExam() : boolean
getExecutionStatus() : String
putAction(Type: String,Parameters: String) : void
isAuthenticated(Matricula: String,Password: String,jSessionID: String,strClientName: String,HTTPHeader: String) : boolean
isStillAuthenticated(jSessionID: String) : boolean
StartExam() : boolean
getTimeLeft() : String
setNextQuestion() : boolean
setCurrentQuestion() : boolean
setQuestion(Next: boolean) : boolean
setStudentAnswer(strContent: String[]) : boolean
setStudentAnswer(strContent: String[],Value: float) : boolean
getRightAnswer() : String
Surrender() : boolean
End() : boolean
dbTeacherModel
create dbTeacherModel()
create dbTeacherModel(host: String,database: String,user: String,password: String)
setMonths(strMonths: String) : boolean
getMonths() : String
isAdministrator() : boolean
setAdministrator(b: boolean) : void
clearJSPHistory() : void
isJSPHistoryEmpty() : boolean
setCurrentJSP(JSP: String) : void
getCurrentJSP() : String
setPreviousJSP() : void
deleteRecords(son: String,father: String,joinField: String) : int
clear() : int
insertCourse(Name: String,Teacher: String,Login: String,Password: String) : boolean
updateCourse(Name: String,Teacher: String) : boolean
deleteCourses(strIDsCourse: String[]) : boolean
updateCourseLogin(Login: String,Password: String) : boolean
insertArgument(Name: String,Description: String) : boolean
updateArgument(Name: String,Description: String) : boolean
deleteArguments(strIDsArgument: String[]) : boolean
insertExam(Name: String,ExamDate: String,Length: String,MaxStudentGroup: String,Comment: String) : boolean
updateExam(Name: String,ExamDate: String,Length: String,MaxStudentGroup: String,Comment: String) : boolean
deleteExams(strIDsExam: String[]) : int
isExamStarted() : boolean
setExamActive() : boolean
setExamInactive() : boolean
setExamResult() : boolean
isTestUsed() : boolean
insertTest(Title: String,RandomSorting: boolean) : boolean
updateTest(Title: String,Template: String,Sorting: String) : boolean
deleteTests(strIDsTest: String[]) : boolean
copyTest() : boolean
setTestDifficulty() : boolean
addTestQuestion(strIDsQuestion: String[]) : boolean
deleteTestQuestion(strIDsQuestion: String[]) : boolean
updateTestQuestionValue(strValue: String[],strIDsQuestion: String[]) : boolean
updateTestQuestionOrder(strOrder: String[],strIDsQuestion: String[]) : boolean
assignTestExam(strIDsTest: String[]) : boolean
addAssignment(strIDStudent: String,strIDTest: String,ExamGroup: int) : boolean
setRightAnswer(strRightAnswer: String) : boolean
setAnswerValue(strRightAnswerValue: String,strNoAnswerValue: String,strWrongAnswerValue: String,AllowPartialAnswer: boolean) : boolean
setScoreParameter(strScoreMax: String,strScoreMin: String,strValueMax: String,strValueMin: String) : boolean
RecorrectAnswer() : boolean
updateAnswerValue(strValue: String[],strIDsQuestion: String[]) : boolean
isAllAnswerCorrect() : boolean
deleteQuestions(strIDsQuestion: String[]) : boolean
getQuestionCount() : String
setQuestionDifficulty(diff: double) : boolean
moveQuestions(strIDArgument: String,strIDsQuestion: String[]) : boolean
setQuestionsDifficulty() : boolean
getAnswerType() : String
getAttachments(strIDsQuestion: String[]) : ArrayList
addStudentRegistration(r: Reader) : boolean
addStudentRegistration(Matricula: String,Surname: String,Name: String) : boolean
removeStudentRegistration(IDsStudent: String[]) : boolean
finalize() : void
eVal
AttachmentClassHTMLDriver QuestionClass
http
HttpServletHttpServletResponseWrapper
TeacherController
init(config: void) : void
destroy() : void
JSPdispatcher(strJSP: String,request: void) : void
ShowPoolInfo(Login: boolean,request: void) : void
HTTPHeader(request: void) : String
Send(response: void) : boolean
UpdateClientXMLConfig(host: String) : boolean
processRequest(request: void) : void
doGet(request: void) : void
doPost(request: void) : void
getServletInfo() : String
QuestionJarHandler
create QuestionJarHandler(os: OutputStream)
ParserMessage(msg: String) : void
error(str: String) : void
startDocument() : void
startElement(tag: void) : void
text(str: String) : void
endElement(tag: void) : void
endDocument() : void
print(str: String) : void
printElement(tag: void) : void
BackResponseClass
pw : PrintWriter
create BackResponseClass(response: void)
getWriter() : PrintWriter
setContentType(type: String) : void
flushBuffer() : void
isCommitted() : boolean
resetBuffer() : void
StudentController
init(config: void) : void
destroy() : void
JSPdispatcher(strJSP: String,request: void) : void
ShowPoolInfo(CurrentQuestion: boolean,request: void) : void
HTTPHeader(request: void) : String
processRequest(request: void) : void
doGet(request: void) : void
doPost(request: void) : void
getServletInfo() : String
Figura 8.4: Classi del package eValServer.

107. 96 Organizzazione del codice
8.5 Alcune estensioni di esempio
Vengono qui descritti alcuni possibili interventi che possono essere compiuti per estendere le
funzionalit`a dell’applicazione:
• implementazione di altri schemi di correzione: in questo caso `e necessario mo-
dificare sia le procedure di aggiornamento del database per il calcolo dei voti (db-
TeacherModel.setExamResult), sia la pagina JSP che visualizza i risultati di un esame
(ShowExamDone.jsp e ShowExamStudent.jsp); bisogna anche ridefinire le procedure per
l’inserimento dei parametri del nuovo schema (dbTeacherModel.setScoreParameter);
nel caso in cui fosse necessario cambiare anche l’algoritmo automatico che valuta la
correttezza delle risposte, bisognerebbe modificare il codice che confronta la risposta
con quella corretta (Answer.compareAnswer);
• interpretazione delle azioni degli studenti: potrebbe essere utile valutare se le
azioni compiute da uno studente durante un esame, devono essere considerate come
“sospette”; a questo proposito si dovrebbe modificare la JSP ShowExamDone.jsp per
evidenziare gli studenti che hanno compiuto delle azioni particolari;
• servizi statistici sui risultati: l’interpretazione dei risultati di un compito serve
per aggiustare opportunamente lo schema di correzione; a questo fine potrebbero es-
sere utili considerazioni statistiche o addirittura dei grafici riassuntivi; per fare ci`o
bisognerebbe agire solamente sulla presentazione (o View) dei dati, rappresentata dalle
pagine ShowExamDone.jsp e PrintExamResult.jsp.
Si potrebbe pensare anche di eseguire delle statistiche sui compiti che uno studente ha
ripetutamente svolto con esito negativo, oppure sapere dopo quanti tentativi, in media,
uno studente passa l’esame; in tutti questi casi `e sufficiente creare delle JSP ad hoc che
interroghino opportunamente la base di dati;
• generazione automatica e in tempo reale dei compiti: si potrebbe pensare di fare
in modo che i quesiti presentati allo studente vengano scelti al momento della richiesta,
in base alle risposte date in precedenza; si potrebbe, per esempio, implementare un
algoritmo di questo tipo: se lo studente risponde esattamente ad un quesito, allora
quello successivo verr`a scelto tra quelli che sono un po’ pi`u difficili; viceversa, se lo
studente risponde in modo errato gli verr`a proposta una domanda pi`u facile. In questo
caso sarebbe necessario modificare solamente il Model dell’applicazione senza toccare
le JSP; in particolare il metodo dbStudentModel.setQuestion dovrebbe contenere il
codice necessario per la scelta e dovrebbe aggiornare la base di dati per tener traccia
dei quesiti che man mano vengono proposti allo studente.

108. Conclusioni
Rispetto anche ad altre applicazioni commerciali di esercitazione e di valutazione dell’ap-
prendimento, e-Val pu`o vantare:
• l’indipendenza dalla piattaforma poich´e si basa su tecnologia Java e su un DBMS
disponibile per molti sistemi operativi;
• l’uso di tecnologie open source o comunque non a pagamento;
• un ambiente multi–authoring che gestisce pi`u corsi e soddisfa pi`u studenti e docenti
contemporaneamente;
• la distribuzione in rete dei servizi grazie all’uso del protocollo di comunicazione
HTTP;
• il ripristino degli esami dopo un black–out poich´e lo stato dei client degli studenti
`e salvato nel database.
Le funzionalit`a carenti o assenti riguardano invece:
• l’implementazione separata delle risposte dai quesiti;
• le statistiche sugli esiti degli esami e sugli studenti;
• le connessioni non protette tra client e server Web;
• la scelta automatica e in tempo reale dei quesiti da presentare allo studente.
Testing L’applicazione `e stata installata per prova su un computer non particolarmente
potente (un Pentium 200) dotato di sistema operativo Linux; sono stati inseriti fittiziamente
alcuni corsi, molti quesiti e qualche centinaio di studenti; `e stato successivamente simulato
un appello d’esame con un gruppo di volontari e l’esito `e stato positivo: il sistema non ha
dato segni di rallentamento e si sono potuti monitorare in tempo reale i risultati delle risposte
date.
Il primo utilizzo del sistema avverr`a presso il Dipartimento di Tecnica e Gestione dei Siste-
mi Industriali di Vicenza, grazie alla disponibilit`a degli amministratori dei sistemi informatici
del dipartimento.

109. 98 Organizzazione del codice

110. Parte III
Manuali e-Val

112. Introduzione
Questa parte della tesi contiene i manuali d’uso di e-Val per le tre categorie di utenti che
utilizzano l’applicazione:
• gli amministratori,
• i docenti,
• gli studenti.
I manuali dell’amministratore e dei docenti sono da considerarsi riservati e contengono le
istruzioni necessarie per l’installazione, la configurazione, la preparazione degli esami e la
correzione dei compiti. Il manuale del docente si chiude con una sezione che illustra lo schema
logico di utilizzo ovvero la sequenza delle procedure da compiere per preparare dal principio
un esame, consentirne lo svolgimento ed infine visualizzare i risultati.
Il manuale dello studente `e rivolto a coloro che devono sostenere un esame; dovrebbe quindi
essere reso disponibile per la consultazione nell’aula di informatica in cui avviene l’esame.
L’uso dell’applicazione da parte dello studente `e comunque molto semplice ed intuitivo anche
per chi abbia poca famigliarit`a con il computer.

113. 102

114. Capitolo 9
Manuale dell’amministratore
L’amministratore `e la persona che ha il compito di installare il server Web, il DBMS, l’appli-
cazione e-Val e di preparare l’aula di informatica in cui svolgere gli esami. Quando il sistema
diventa operativo esegue la manutenzione del database, crea nuovi corsi per i docenti che ne
facciano richiesta ed eventualmente cancella quelli inutilizzati.
9.1 Requisiti di sistema
Grazie alla tecnologia Java e alla disponibilit`a di MySQL per molte piattaforme e sistemi ope-
rativi l’applicazione server pu`o essere installata sia su computer dotati del sistema operativo
Linux sia su computer equipaggati con Windows. Devono essere presenti:
• un Java SDK e l’ambiente di runtime come per esempio la Java2 Standard Edition (J2SE)
scaricabile dal sito java.sun.com/j2se/; l’applicazione `e stata testata con successo sia
utilizzando la versione 1.3 che la 1.4;
• il servlet container Tomcat gratuitamente disponibile al sito Web del progetto Jakar-
ta jakarta.apache.org/downloads/binindex.html; una volta che il server Web `e
stato installato in una directory la variabile TOMCAT HOME deve puntare a questa di-
rectory; a questo scopo si pu`o utilizzare il comando SET di Windows oppure, per Win-
dows NT/2000/XP, impostare la variabile dal Pannello di controllo; supponendo per
esempio che la directory si chiami C:TOMCAT:
SET TOMCAT HOME=C:TOMCAT
Nei sistemi UNIX/Linux il comando da utilizzare dipende dalla shell in esecuzione; per
sh e bash (supponendo /usr/local/tomcat), sar`a:
TOMCAT HOME=/usr/local/tomcat; export TOMCAT HOME
La versione di Tomcat che si `e utilizzata per lo sviluppo `e la 4;

115. 104 Manuale dell’amministratore
• il DBMS MySQL adatto alla propria piattaforma scaricabile dal sito www.mysql.com; la
release stabile in questo momento `e la 3.23.
Non appena si sono installate queste applicazioni e sia stato avviato il database server si pu`o
iniziare l’installazione vera e propria dell’applicazione e-Val.
L’aula di informatica dove si svolgeranno gli esami dovr`a essere dotata di computer
equipaggati con una Java Virtual Machine e con l’applicazione Swing e–Val Student scari-
cabile direttamente via Web accedendo alla pagina principale dell’amministratore (vedi la
sezione 9.2.3).
9.2 Installazione dell’applicazione
La figura 9.1 illustra come siano distribuite tra i vari computer e come interagiscano le varie
applicazioni che formano il sistema e-Val.
9.2.1 Creazione del database
Il file eVal DB.sql contiene i comandi SQL per creare il database eVal, le varie tabelle e
gli utenti con i relativi privilegi; sono inoltre presenti delle righe commentate utili nel caso
si volessero incrementare le prestazioni del database mediante l’uso di indici sulle chiavi
secondarie di alcune tabelle.
Supponendo che esista l’utente admin e che abbia i privilegi necessari alla creazione di un
database bisogna eseguire il comando:
mysql -u admin -p eVal DB.sql
ed inserire la password di accesso. Se invece si lavora in Linux e si `e collegati come root basta
eseguire:
mysql eVal DB.sql
Se tutto va a buon fine non dovrebbe comparire alcun messaggio di avviso; viceversa bisogner`a
trovare la causa dell’arresto e prima di ridefinire di nuovo il database sar`a necessario cancellare
quello che si `e gi`a creato (usando il comando SQL DROP DATABASE eVal).
9.2.2 Il file eVal.war
Queso file contiene l’applicazione vera e propria da installare, comprese le applicazioni per il
docente e quella per lo studente. L’installazione `e molto semplice e consiste esclusivamente
nel copiare il file nella directory TomcatDir/webapps/ e far ripartire il server Web. A
questo punto Tomcat provvede automaticamente ad estrarre i files necessari e a costruire
l’albero delle directory dell’applicazione; dopo qualche decina di secondi il server `e pronto ad
accettare le richieste HTTP.
Per testare il funzionamento dell’applicazione `e sufficiente collegarsi con un qualsiasi
browser Web all’indirizzo localhost:8080/eVal/Welcome.teacher (supponendo di essere
sulla stessa macchina in cui `e installato il server Web); dopo qualche secondo, necessario

116. 9.2 Installazione dell’applicazione 105
Web server: Windows/UNIX
JVM
java bean
dbAttachmentAccess
java bean
dbStudentModel
JDBC driver
java bean
dbTeacherModel
servlet container
Apache Jackarta Tomcat
servlet
Teacher controller
servlet
Student controller
servlet
Attachment controller
Computer studente: Windows/UNIX
Database server: Windows/UNIX
database management system
MySQL
JVM
e-Val Student
Computer docente: Windows/UNIX
Web browser:Mozilla/IE/Netscape
JVM
HTTP
TCP/IP
e-Val Question Manager
HTTP
Figura 9.1: Schema della distribuzione dei moduli software tra i vari componenti
fisici (computer).
a Tomcat per compilare la JSP richiesta, dovrebbe comparire la pagina di benvenuto, con
i campi Login e Password. Se invece si dovessero verificare degli errori `e molto probabile
che derivino dall’impossibilit`a dell’applicazione di stabilire una connessione con il database
MySQL; in questo caso si pu`o provare a far ripartire sia il DBMS che il server Web e a leggere
la sezione 9.2.4 sull’accesso degli utenti al database.
9.2.3 Le applicazioni Java Swing e–Val Question Manager e e–Val Student
Queste due applicazioni danno la possibilit`a via internet ai docenti e agli studenti rispet-
tivamente di inserire o modificare i quesiti nella base di dati e di svolgere un esame. Sono
contenute nei due file eseguibili eValQuestionManager.jar e eValStudent.jar che si trovano

117. 106 Manuale dell’amministratore
nella directory TomcatDir/webapps/eVal/TeacherView/; si possono scaricare utilizzando
un browser Web e collegandosi come amministratore o come docente alla pagina di benvenuto
localhost:8080/eVal/Welcome.teacher (vedi le sezioni 9.5.1, 10.1.3 e 10.1.16). Entrambe
queste applicazioni necessitano di una JVM installata sui computer client e il comando per
eseguire, per esempio, l’applicazione studente `e:
java -jar eValStudent.jar
9.2.4 Gli utenti
Il DBMS MySQL accetta connessioni al database previa identificazione degli utenti; questa
avviene sulla base di tre parametri:
• il computer dal quale l’utente si collega;
• il nome dell’utente;
• la password.
L’applicazione Web di e-Val `e stata progettata seguendo un modello a tre livelli (3 tier
architecture) in cui i client degli utenti richiedono dei servizi via HTTP al server Web che
li compie accedendo, se necessario, alla base di dati; quindi i client non si collegano mai
direttamente al DBMS. Questo significa che gli utenti fisici del database sono esclusivamente
le classi caricate da Tomcat.
Internamente l’applicazione Web `e divisa in tre parti ognuna delle quali gestisce, per
i propri usi e in modo indipendente, un pool di connessioni verso il database. Sono stati
quindi definiti nel file eVal DB.sql tre utenti che hanno privilegi di accesso alle tabelle diversi
tenendo conto degli usi che ne dovranno fare: Student@localhost, Teacher@localhost e
Browser@localhost.
Le definizioni degli utenti possono essere comunque modificate nei casi in cui:
• MySQL non riconosca che la connessione al database provenga da localhost anche se
Tomcat `e installato nello stesso computer (problema riscontrato nel sistema Linux);
• MySQL non riconosca i privilegi a livello di tabella; in questo caso si pu`o ricorrere alla
definizione di un unico utente che abbia solamente privilegi a livello di database (per
esempio inserendo il comando GRANT SELECT, INSERT, UPDATE, DELETE ON eVal.*
TO Servlet@localhost IDENTIFIED BY ’...’;).
Ogni cambiamento dovr`a essere esteso ai files di configurazione dell’applicazione che gira sul
server Web (vedi la sezione 9.3).
L’applicazione prevede per`o che anche gli amministratori, i docenti e gli studenti abbiano
una login e una password di accesso:
• quella dell’amministratore viene definita nel file web.xml (vedi la sezione 9.3);
• quelle dei docenti vengono salvate nel database (Answer.Login e Answer.Password,
quest’ultima criptata usando la funzione PASSWORD() di MySQL);

118. 9.3 I files di configurazione 107
• quelle degli studenti sono costituite dal numero di matricola (Student.Matricula) e
da un codice univoco per l’accesso ad un esame (Assignment.Password).
9.3 I files di configurazione
I vari moduli dell’applicazione leggono i parametri necessari al funzionamento da alcuni files
di configurazione in formato XML che ora verrano analizzati in dettaglio.
9.3.1 Il file web.xml
Questo file contiene i parametri di configurazione dell’applicazione server e si trova nella
directory TomcatDir/webapps/eVal/WEB-INF. Ogni volta che viene avviato Tomcat, il
servlet container legge i parametri che gli servono per configurare l’applicazione (mappature
dei servlet, parametri globali, regole di sicurezza, metodi di autenticazione, dichiarazioni delle
librerie di tag, ecc.) e altri parametri che vengono messi a disposizione dei singoli servlet.
Per una descrizione approfondita della sua struttura e per il significato completo dei tag
si rimanda a [1] e [25]. Vengono ora esaminati i parametri pi`u significativi per l’applicazione:
• configurazione del database server: le seguenti righe
context−param
param−names e r v e r/param−name
param−valuel o c a l h o s t : 3 3 0 6/param−value
/ context−param
servono per specificare il nome del server e la porta (di solito MySQL `e configurato con
la 3306);
• configurazione dell’accesso per l’amministratore: le righe
init −param
2 param−nameadmin login/param−name
param−valuea dm i ni st rat or/param−value
4 / ini t −param
init −param
6 param−nameadmin password/param−name
param−valuepassword/param−value
8 / ini t −param
permettono di settare la login (riga 3) e la password (riga 7) dell’amministratore del
sistema;
• configurazione automatica dei client:
init −param
param−namec l i e n t c o n f i g/param−name
param−valuetrue/param−value
/ init −param

119. 108 Manuale dell’amministratore
se `e abilitata questa voce (valore del parametro true) ogni volta che un docente o
un amministratore chiedono al server Web di scaricare i client Java, questi vengono
automaticamente configurati per accedere correttamente al server (vedi in proposito le
sezioni 9.3.3 e 9.3.2);
• configurazione dell’accesso al database:
init −param
param−nameuser/param−name
param−valueS e r v l e t/param−value
/ init −param
init −param
param−namepassword/param−name
param−valuepassword/param−value
/ init −param
permettono di settare la login e la password che il servlet usa per l’accesso alla base di
dati; il nome e la classe Java che rappresenta il servlet sono definiti da
s e r v l e t
servlet −nameTeacherController/ servlet −name
servlet −c l a s seValServer . TeacherController/ servlet −c l a s s
. . .
L’applicazione Web ha internamente 3 servlet: uno per rispondere alle richieste degli
studenti, uno per quelle dei docenti e uno per recuperare gli allegati dei quesiti, che di
solito vengono richiesti dai browser Web.
• configurazione dei pool di connessione: i parametri
param−nameminConnections/param−name
param−namemaxConnections/param−name
param−namemaxCheckoutSeconds/param−name
param−namemaxConnectionTime/param−name
permettono di settare rispettivamente il numero minimo e massimo di connessioni aperte
contemporanemente, il numero massimo di secondi prima che le connessioni vengano
forzatamente riciclate dal connection broker ed infine il numero di giorni prima di re-
settare le connessioni; queste ultime vengono condivise dagli utenti collegati e vengono
gestite da tre diversi connection broker, una per ogni controller (studente, docente e
per il reperimento degli allegati); per un approfondimento sull’uso di questi parametri
si rimanda a www.javaexchange.com/api/packages.html
• configurazione delle sessioni HTTP: il parametro
init −param
param−nameMaxInactiveInterval/param−name
param−value3000/param−value
/ init −param

120. 9.3 I files di configurazione 109
specifica il numero massimo di secondi prima che la sessione dell’utente venga cancellata.
9.3.2 TeacherConfiguration.xml
Questo file si trova nella directory TomcatDir/webapps/eVal/TeacherView e permette
di far conoscere all’applicazione e–Val Question Manager quale sia il server Web a cui deve
accedere per richiedere i servizi di cui ha bisogno. Il parametro pi`u importante `e:
init −param
param−namehost/param−name
param−valuel o c a l h o s t : 8 0 8 0/param−value
/ init −param
in cui viene specificato il nome del server Web e il numero della porta. In realt`a non `e
necessario modificare manualmente questo file poich´e il server Web, prima di inviarlo all’utente
che lo ha richiesto, aggiorna il valore del parametro con il nome dell’host corretto e lo inserisce
nel file eValQuestionManager.jar che quindi `e pronto per essere eseguito in remoto.
9.3.3 StudentConfiguration.xml
Anche per l’applicazione e–Val Student valgono le stesse considerazioni appena fatte; in
aggiunta si sono definiti i seguenti parametri:
• sincronizzazione con il server:
param−nameseconds time sync/param−name
param−value20/param−value
specifica il numero di secondi prima che il client Java chieda nuovamente al server di
sincronizzare il tempo che rimane allo studente per completare l’esame;
• frequenza delle richieste di login:
param−namesec onds betwe e n lo gi n/param−name
param−value4/param−value
indica il numero di secondi che devono trascorrere tra una richiesta automatica di login
(non andata a buon fine) e l’altra;
• timeout:
param−namec l o s e t i m e o u t/param−name
param−value10/param−value
indica il numero di secondi che devono trascorrere prima che il client si chiuda auto-
maticamente in seguito ad un segnale di chiusura inviato dal server;
• frequenza del timer interno:

121. 110 Manuale dell’amministratore
param−namet i m e r p e r i o d/param−name
param−value4/param−value
setta il periodo in secondi del timer interno per la gestione dei vari task tra cui anche
quello dell’aggiornamento della visualizzazione del tempo rimanente allo studente (in
questo caso viene aggiornato ogni 4 secondi); gli intervalli precedenti devono essere presi
maggiori o uguali a questo valore.
9.4 I files di log
L’applicazione installata sul server e i client Java generano dei file di log salvati nella directory
home dell’utente; contengono vari tipi di informazioni tengono traccia della data e dell’ora di
inserimento degli eventi, come in questo esempio:
[13-dic-2002 12.28.21]: Il servlet docente `e attivo
[13-dic-2002 12.28.42]: Amministratore autenticato:[host]: localhost:8080
[user-agent]: Mozilla/5.0 ...
[13-dic-2002 12.29.02]: Docente autenticato:[host]: localhost:8080
[user-agent]: Mozilla/5.0 (Windows; ...
I tipi di messaggi che vengono inseriti riguardano:
• l’avvenuta autenticazione dei docenti e degli amministratori;
• le autenticazioni fallite da parte degli amministratori, dei docenti e degli studenti;
• gli avvisi di avvio o di fuori servizio dei pool di connessioni con il database;
• gli errori interni dell’applicazione server;
• le queries che al momento dell’esecuzione hanno generato un errore;
• le invalidazione di sessioni HTTP rimaste aperte.
9.5 I servizi di amministrazione accessibili dal Web
La creazione di nuovi corsi e la cancellazione di quelli inutilizzati nel database vengono eseguite
dall’amministratore, accedendo tramite un browser all’indirizzo
localhost:8080/eVal/Welcome.teacher
ed inserendo la login e la password di amministrazione cos`ı come sono settate nel file web.xml
(vedi 9.3.1).

122. 9.5 I servizi di amministrazione accessibili dal Web 111
Figura 9.2: Administration – Cancellazione di un corso
9.5.1 Cancellazione di un corso [Administration]
t figura 9.2
A questo punto comparir`a la pagina di amministrazione in cui si possono vedere i corsi pre-
senti nel database con i relativi docenti. Per eliminare definitivamente un corso che non deve
contenere alcun esame `e sufficiente sceglierlo dalla lista e premere il bottone Elimina corso .
Client dello studente avvia lo scaricamento dell’applicazione e–Val Student per lo svolgimento
degli esami. Il bottone Nuovo corso permette invece di aprire il form per l’inserimento di
un nuovo corso.
Figura 9.3: NewCourse – Creazione di un nuovo corso

123. 112 Manuale dell’amministratore
9.5.2 Creazione di un nuovo corso [NewCourse]
t figura 9.3
Per inserire un nuovo corso `e necessario specificare un nome che lo identifichi univoca-
mente; i campi Login e Password saranno usati per consentire l’accesso da parte del docente
al corso di appartenenza. Se tutto `e corretto, cliccando su Inserisci corso il nuovo corso verr`a
inserito nel database e ricomparir`a la pagina principale con la lista aggiornata dei corsi.
9.6 Incrementare le prestazioni
Le prestazioni del sistema possono essere penalizzate da due fattori principali:
• il grande numero di studenti che svolgono contemporaneamente gli esami (varie decine
di studenti) che incide sulla prontezza del sistema solamente durante gli appelli d’esame;
• la grande mole di dati contenuta nella base di dati (centinaia di compiti svolti) che
rallentano l’esecuzione delle varie queries.
Il primo caso pu`o essere risolto incrementando il numero di connessioni contemporaneamente
aperte dal pool di connessioni; ci`o si realizza cambiando i parametri di configurazione descritti
a pagina 108 e facendo ripartire il server Web.
Il secondo caso `e invece pi`u difficile da affrontare perch´e richiede di individuare ed analizza-
re quali siano le queries verso il database pi`u critiche, cio`e quelle che rallentano notevolmente
il sistema; non appena si `e individuata la query, la soluzione `e quella di creare degli indici
sulle chiavi secondarie del database per velocizzare le operazioni di reperimento dei dati; per
fare ci`o si pu`o usare il comando:
CREATE INDEX index_name ON tbl_name ( col_name [( length )] ,... )
Nel definire un nuovo indice bisogna fare attenzione allo spazio che occupa dopo la sua
creazione; `e infatti proporzionale al numero di record della tabella.

124. Capitolo 10
Manuale del docente
Il docente `e colui che inserisce i quesiti, crea i compiti e gli appelli d’esame, iscrive gli studenti
e sceglie gli schemi di correzione.
10.1 Accesso dal Web
L’uso dell’applicazione da parte del docente avviene principalmente attraverso il Web me-
diante l’uso di un qualsiasi browser che supporti i fogli di stile e il linguaggio di scripting
JavaScript (sono praticamente adatti tutti i browser pi`u aggiornati).
Interfaccia grafica L’interfaccia grafica `e stata studiata in modo da rendere semplice ed
intuitivo l’uso dell’applicazione: in alto sono sempre disponibili dei bottoni che permettono
di andare direttamente al menu principale, alla pagina che si `e appena visitata oppure di
richiamare un help in linea; i form presenti nelle pagine HTML danno la possibilit`a di inserire
dei dati. La veste grafica delle pagine `e stata ottenuta mediante l’utilizzo dei fogli di stile;
oltre a razionalizzare l’interfaccia utente ci`o facilita l’uso dell’applicazione.
Organizzazione L’applicazione prevede la gestione indipendente delle seguenti entit`a:
• gli esami e tutto ci`o che riguarda gli appelli di esame: gli studenti iscritti, lo svolgimento
e il risultato finale;
• i compiti cio`e i temi di esame che vengono preparati per essere presentati agli studenti
in un appello;
• gli argomenti che rappresentano gli ambiti tematici relativi al corso; servono per rag-
gruppare i quesiti inseriti.
Di seguito verranno presentate e analizzate in dettaglio le pagine che il docente pu`o trovarsi
di fronte; sono generate dinamicamnete al momento della richiesta dell’utente dal server Web,
utilizzando la tecnologia delle JavaServer PagesTM. Dopo il titolo di ogni pagina vengono
indicate alcune informazioni, identificate dai seguenti simboli: t indica il numero della figura

125. 114 Manuale del docente
corrispondente alla pagina in esame, indica la pagina o le pagine che la precedono, indica
invece le pagine alle quali si pu`o accedere.
Figura 10.1: Welcome – Pagina di benvenuto
10.1.1 Pagina di benvenuto [Welcome]
t figura 10.1
Header alla sezione 10.1.2
Menu alla sezione 10.1.3
`E la pagina iniziale che permette al docente di inserire la propria login (campo Login) e
la propria password (campo Password) ed accedere al sistema. Se l’autenticazione non va a
buon fine viene visualizzato una pagina di errore.
Figura 10.2: Header – Comandi della testata principale

126. 10.1 Accesso dal Web 115
10.1.2 Testata principale [Header]
t figura 10.2
Welcome alla sezione 10.1.1
Menu alla sezione 10.1.3
ModifyCourse alla sezione 10.1.4
Il menu `e sempre disponibile durante la navigazione tra le pagine; i comandi danno la
possibilit`a di tornare al menu principale o alla pagina precedente, di aggiornare la pagina
corrente con i dati pi`u recenti, di modificare i dati di un corso ( Modifica dati corso per
cambiare per esempio la login e la password d’accesso) e di uscire dall’applicazione e terminare
la sessione corrente.
Figura 10.3: Menu – Menu principale dell’applicazione del docente
10.1.3 Menu principale [Menu]
t figura 10.3
Welcome alla sezione 10.1.1
NewTest alla sezione 10.1.21
ShowTest alla sezione 10.1.19
ModifyTest alla sezione 10.1.20
NewArgument alla sezione 10.1.18
ModifyArgument alla sezione 10.1.16
NewExam alla sezione 10.1.5
ModifyExam alla sezione 10.1.6
ShowExamDone alla sezione 10.1.8
Il menu principale contiene gli elenchi degli esami finora svolti o programmati, dei compiti
creati e degli argomenti del corso che raggruppano le domande presenti nella base di dati. Gli
elementi delle liste possono essere scelti con un doppio click oppure selezionando l’elemento

127. 116 Manuale del docente
desiderato e premendo il bottone Vai . Il bottone Elimina permette di eliminare uno o
pi`u elementi delle liste con le seguenti regole:
• un argomento non pu`o essere eliminato se raccoglie ancora dei quesiti;
• un compito non pu`o essere eliminato se `e stato assegnato in un esame;
• quando viene eliminato un esame vengono cancellate anche le risposte degli studenti.
Il bottone Nuovo permette di creare un nuovo esame, un nuovo compito oppure aggiungere
un argomento. Il bottone Copia duplica il compito selezionato e permette di modificarlo;
Aggiorna difficolt`a quesiti ricalcola il grado di difficolt`a di ogni quesito tenendo conto delle
risposte date dagli studenti durante tutti gli esami svolti fino a quel momento: la difficolt`a
viene calcolata come il numero delle risposte esatte diviso il numero di tutte le volte che quel
quesito `e stato assegnato ad uno studente. Client dello studente permette di scaricare e–Val
Student, l’applicazione java necessaria per l’esecuzione degli esami; infine Aggiorna intervallo
stabilisce l’intervallo di mesi oltre il quale non visualizzare gli elementi creati precedentemente.
Figura 10.4: ModifyCourse – Form per la modifica dei dati del corso
10.1.4 Modifica dei dati del corso [ModifyCourse]
t figura 10.4
Header alla sezione 10.1.2
Questa pagina permette di cambiare il nome del corso e il nome del docente; si possono
modificare anche la login di accesso e la password (dopo la modifica cliccare su Salva login ).
10.1.5 Creazione di un nuovo esame [NewExam]
t figura 10.5
Menu alla sezione 10.1.3
ModifyExam alla sezione 10.1.6
Per la creazione di un nuovo esame sono necessarie le seguenti informazioni:

128. 10.1 Accesso dal Web 117
Figura 10.5: NewExam – Form per la creazione di un nuovo esame
• nome dell’esame;
• data dell’esame: per sceglierne una basta selezionare l’anno, il mese e cliccare sul giorno
desiderato (evidenziato con il colore arancione);
• durata dell’esame in minuti;
• il numero di studenti per gruppo: corrisponde al massimo numero di computer disponi-
bili nell’aula di informatica per svolgere l’esame o il massimo numero di studenti che
possono contemporaneamente partecipare all’esame;
• un avviso per lo studente che gli verr`a mostrato prima di iniziare l’esame.
Quando sono state inserite tutte le informazioni, `e necessario cliccare Salva l’esame .
10.1.6 Modifica di un esame ancora da sostenere [ModifyExam]
t figura 10.6
Menu alla sezione 10.1.3
NewExam alla sezione 10.1.5
PrintExamStudentList alla sezione 10.1.7
I campi modificabili sono gli stessi descritti a pagina 116 con l’aggiunta delle procedure
per iscrivere gli studenti ed assegnare loro un compito. Per iscrivere nuovi studenti `e neces-
sario scrivere (o usare un copia–incolla) nell’area di testo del form, il numero di matricola

129. 118 Manuale del docente
Figura 10.6: ModifyExam – Form per la modifica di un esame ancora da sostenere
dello studente, il cognome e il nome separati da una virgola (o da un punto e virgola o da
una tabulazione) e cliccare sul botton Iscrivi studenti . Gli studenti iscritti vengono allo-
ra visualizzati nella lista degli iscritti. Quando si sono iscritti tutti gli studenti si possono
assegnare i compiti: si possono scegliere dalla lista dei compiti disponibili e cliccando sul bot-
tone Assegna compito vengono automaticamente assegnati agli studenti considerando anche
il numero di studenti per gruppo. L’assegnazione del compito implica anche l’automatica
assegnazione di una password necessaria allo studente per sostenere l’esame e il numero del
gruppo di appartenenza (vedi PrintExamStudentList alla sezione 10.1.7).
L’assegnazione dei compiti
L’algoritmo per l’assegnazione dei compiti agli studenti iscritti ad un esame compie le seguenti
azioni:
• ordina gli studenti alfabeticamente e li divide in gruppi in base al numero scelto di
studenti per gruppo;
• divide il numero di compiti assegnabili per il numero di gruppi che si sono formati;
• assegna ciclicamente i compiti destinati ad ogni singolo gruppo oppure, se il numero di
compiti `e inferiore al numero di gruppi, assegna agli studenti di uno stesso gruppo gli
stessi compiti, possibilmente diversi da quelli di un altro gruppo.

130. 10.1 Accesso dal Web 119
La password `e costituita da due lettere alfabetiche (senza distinzione tra maiuscole e mi-
nuscole) e da due numeri scelti casualmente. Sono uniche per ogni studente perch´e devono
identificare l’appelo d’esame a cui lo studente partecipa.
Figura 10.7: PrintExamStudentList – Tabella d’esame necessaria per far sostenere
gli esami agli studenti
10.1.7 Stampa della tabella d’esame [PrintExamStudentList]
t figura 10.7
ModifyExam alla sezione 10.1.6
ShowExamDone alla sezione 10.1.8
Questa lista deve essere stampata e resa disponibile agli studenti che devono partecipare
all’appello d’esame; infatti solamente conoscendo la password uno studente pu`o sostenere
l’esame.
10.1.8 Esame svolto o in corso di svolgimento [ShowExamDone]
t figura 10.8
Menu alla sezione 10.1.3
PrintExamStudentList alla sezione 10.1.7
PrintExamResult alla sezione 10.1.9
ShowExamStudent alla sezione 10.1.10
ShowTestUsed alla sezione 10.1.13
La pagina contiene la lista degli studenti presenti all’esame scelto, il tempo che hanno
impiegato per rispondere alle domande, il compito a loro assegnato, il punteggio in cen-
tesimi ottenuto e il voto in trentesimi calcolato in base allo schema di correzione scelto.
Correggi di nuovo permette di rifare la correzione delle risposte date (necessario solamente
nel caso in cui siano stati modificati i quesiti successivamente allo svolgimento dell’esame).
Per stampare i risultati dell’esame basta cliccare su Tabella risultati ; selezionando Filtro voti
vengono visualizzati solamente i voti maggiori o uguali a 18; si pu`o anche stabilire il voto in
trentesimi oltre il quale assegnare la lode; infine possono essere nascosti gli assenti.

131. 120 Manuale del docente
Figura 10.8: ShowExamDone – Lista degli studenti che hanno svolto un esame
con la possibilit`a di scelta degli schemi di correzione
Se si clicca invece sul nome di uno studente si pu`o vedere il suo compito, le risposte che ha
dato e le azioni compiute durante l’esame (un eventuale asterisco rosso segnala che lo studente
ha compiuto pi`u azioni rispetto quelle di un normale svolgimento). Se si clicca sul compito si
accede a ShowTestUsed alla sezione 10.1.13 che permette di visualizzare la difficolt`a incontrata
dagli studenti che hanno svolto quel compito durante l’esame ed eventualmente aggiungere
un punteggio costante (“alzare il voto” di uno o pi`u quesiti).
Gli schemi di correzione
Nell’apposito form di questa pagina Web possono essere inseriti i parametri necessari per
correggere i compiti. Dai valori inseriti si ricava uno schema di correzione che si basa su:
• la retta di conversione punteggio–voto definita da quattro parametri: il minimo e il mas-
simo voto in trentesimi corrispondenti al minimo e al massimo punteggio in centesimi;
• i pesi delle risposte date dagli studenti: 0 corrisponde ad una risposta completamente
errata mentre 1 corrisponde ad una completamente corretta;

132. 10.1 Accesso dal Web 121
• considerare, per le domande a scelta multipla (CHECKBOX), anche le risposte parziali (che
altrimenti verrebbero considerate errate): il peso della risposta esatta viene moltiplicato
per il grado di correttezza della risposta.
La terminologia usata `e la seguente: Correttezza e Punteggio sono valori compresi tra 0 (peg-
giore) e 1 (migliore) espressi talvolta in percentuale (%) mentre Difficolt`a = 1−Correttezza
quindi ha valori compresi tra 0 (facile) e 1 (difficile). La correttezza o la difficolt`a di un compito
sono la media delle correttezze o delle difficolt`a dei singoli quesiti.
In definitiva supponendo che il compito sia formato da n quesiti il voto per ogni studente
viene calcolato in questo modo:
V oto in trentesimi =
1
n
·
n
i=1
(p(i) + ai) · Slope + Offset (10.1)
non appena siano definiti
• la pendenza della retta di conversione:
Slope =
V oto max − V oto min
Punteggio max − Punteggio min
(10.2)
• l’offset della medesima:
Offset =
(V oto min × Punteggio max) − (V oto max × Punteggio min)
Punteggio max − Punteggio min
(10.3)
• la funzione di pesatura:
p(i) =



Peso risposta corretta se la risposta `e corretta
Peso risposta non data se non `e stata data la risposta
Peso risposta errata se la risposta `e errata
e non si considerano le risposte parziali
Correttezza risposta× se la risposta `e parzialmente corretta
Peso risposta corretta e si considerano le risposte parziali
(10.4)
• i punteggi aggiunti alle singole domande di un compito inserito nel form ShowTestUsed
alla sezione 10.1.13:
ai = valore aggiunto alla domanda (tra 0 e 1). (10.5)
10.1.9 Stampa della lista dei risultati [PrintExamResult]
t figura 10.9
ShowExamDone alla sezione 10.1.8
La pagina contiene la lista degli studenti e dei risultati che hanno ottenuto all’esame scelto:
le modalit`a di visualizzazione (lode, filtro assenti, filtro voti insufficienti) sono definite nella
pagina precedente (ShowExamDone alla sezione 10.1.8).

133. 122 Manuale del docente
Figura 10.9: PrintExamResult – Lista degli studenti che hanno svolto un esame
e risultati
Figura 10.10: ShowExamStudent – Compito svolto o in corso di svolgimento dello
studente
10.1.10 Compito svolto o in corso di svolgimento dello studente [ShowEx-
amStudent]
t figura 10.10
ShowExamDone alla sezione 10.1.8
PrintStudentTest alla sezione 10.1.11
ShowQuestion alla sezione 10.1.12
La pagina mostra i quesiti assegnati allo studente, le risposte corrette, le risposte date
dallo studente, la correttezza (calcolata dal correttore automatico), il punteggio assegnato
in base al peso delle risposte e all’eventuale valore aggiunto ed infine il voto in trentesi-
mi. Cliccando su un quesito viene visualizzato il testo della domanda, mentre cliccando su

134. 10.1 Accesso dal Web 123
Mostra compito si vede il compito completo assegnato allo studente. C’`e anche la possibilit`a
di cambiare il punteggio assegnato dal correttore automatico (aggiornando con il bottone
Aggiorna correttezza quesiti ). Infine pi`u sotto `e presente una lista con le azioni compiute
dallo studente.
Le azioni compiute durante lo svolgimento dell’esame
Il sistema registra ogni azione che lo studente compie durante lo svolgimento dell’esame e
l’ora in cui `e stata compiuta; i tipi di azioni registrate sono le seguenti:
Tipo Descrizione
Login lo studente ha richiesto il primo login per svolgere l’esame:
vengono annotate anche le informazioni sul client HTTP
ReLogin lo studente ha richiesto di nuovo un login per continuare a
svolgere l’esame
TimeExpired lo studente ha terminato il tempo a disposizione
ExamEnded lo studente ha terminato l’esame (perch´e ha risposto a tutti
i quesiti o perch´e ha volontariamente concluso l’esame)
Iconified lo studente ha ridotto ad icona il client
LostFocus lo studente ha cercato di abbandonare il client
CloseClientNow lo studente ha volontariamente chiuso il client
Figura 10.11: PrintStudentTest – Compito assegnato ad uno studente
10.1.11 Compito assegnato ad uno studente [PrintStudentTest]
t figura 10.11
ShowExamStudent alla sezione 10.1.10
Visualizza il testo di tutti i quesiti del compito assegnato ad uno studente.

135. 124 Manuale del docente
Figura 10.12: ShowQuestion – Esempio di quesito
10.1.12 Visualizzazione di un quesito [ShowQuestion]
t figura 10.12
ShowExamStudent alla sezione 10.1.10
ShowTest alla sezione 10.1.19
ModifyTest alla sezione 10.1.20
Rappresenta il testo di un quesito con la risposta corretta.
Figura 10.13: ShowTestUsed – Rapporto su un compito svolto

136. 10.1 Accesso dal Web 125
10.1.13 Rapporto su un compito svolto [ShowTestUsed]
t figura 10.13
ShowExamDone alla sezione 10.1.8
PrintTest alla sezione 10.1.14
ModifyQuestion alla sezione 10.1.15
Questa pagina mostra i quesiti che compongono un tema d’esame dato ad un appello, il
calcolo delle difficolt`a relative all’appello scelto e quelle relative a tutti gli appelli precedenti.
Si ha la possibilit`a di aggiungere un punteggio che verr`a sommato al punteggio ottenuto da
ogni studente che aveva nel compito quel quesito (premere Aggiorna punteggi per rendere
effettive le modifiche); questo per esempio permette al docente di assegnare come corretto un
quesito, indipendentemente dalla risposta data dagli studenti. Se si clicca sul memorandum
di un quesito del compito si possono visualizzare e modificare i dati di quel quesito (vedi
ModifyQuestion alla sezione 10.1.15). La difficolt`a del compito visualizzata subito sotto il
titolo `e quella calcolata nel momento in cui si `e creato il compito e non tiene conto dei
risultati ottenuti in questo appello.
Figura 10.14: PrintTest – Compito assegnato per un appello d’esame
10.1.14 Compito assegnato per un appello d’esame [PrintTest]
t figura 10.14
ShowTestUsed alla sezione 10.1.13
ShowTest alla sezione 10.1.19
Visualizza un compito con tutti i quesiti e le risposte corrette.
10.1.15 Modifica di un quesito [ModifyQuestion]
t figura 10.15
ShowTestUsed alla sezione 10.1.13
ModifyArgument alla sezione 10.1.16
Il form permette di modificare il memorandum del quesito, il commento ed eventualmente
di ridefinire la risposta corretta; per cambiare la risposta basta riempire i campi del form
come se si dovesse rispondere alla domanda e premere Aggiorna risposta corretta . Per una
descrizione completa dei possibili tipi di risposte si rimanda alla sezione 10.2.1. Se si cambia
la risposta corretta di un quesito dato ad un esame `e necessario far eseguire di nuovo la
correzione dei compiti (vedi ShowExamDone alla sezione 10.1.8).

137. 126 Manuale del docente
Figura 10.15: ModifyQuestion – Quesito di esempio
10.1.16 Modifica di un argomento [ModifyArgument]
t figura 10.16
Menu alla sezione 10.1.3
PrintArgument alla sezione 10.1.17
ModifyQuestion alla sezione 10.1.15
In questa pagina `e possibile modificare il nome e la descrizione dell’argomento. Inoltre
la lista dei quesiti presenti permette di selezionare alcuni quesiti (cliccando sul quadratino a
sinistra del memorandum) e di compiere una delle seguenti azioni:
• spostarli in un altro argomento (scegliendo l’argomento destinatario dalla lista e clic-
cando su Sposta in );
• vederli premendo su Mostra quesiti (vedi PrintArgument alla sezione 10.1.17);
• scaricarli in formato HTML compresso (.zip) assieme agli allegati per avere una copia
di backup;
• cancellarli se non sono presenti in qualche compito.
Il bottone Inserisci nuovi quesiti avvia lo scaricamento del client docente e–Val Question
Manager necessario per modificare o inserire nuovi quesiti. Cliccando sul memorandum si
visualizza il quesito (vedi ModifyQuestion alla sezione 10.1.15).

138. 10.1 Accesso dal Web 127
Figura 10.16: ModifyArgument – Modifica di un argomento
Figura 10.17: PrintArgument – Quesiti selezionati di un argomento
10.1.17 Stampa di un argomento [PrintArgument]
t figura 10.17
ModifyArgument alla sezione 10.1.16

139. 128 Manuale del docente
Il codice HTML di questa pagina `e scritto in modo da fornire una copia di backup dei
quesiti scelti nella pagina precedente. Se infatti viene salvata o meglio se viene scaricata in
formato compresso assieme agli allegati (vedi Scarica quesiti in ModifyArgument alla sezione
10.1.16), pu`o essere reinserita direttamente nel client e–Val Question Manager, per ricostruire
esattamente i quesiti nella base di dati.
Figura 10.18: NewArgument – Form per la creazione di un nuovo argomento
10.1.18 Creazione di un nuovo argomento [NewArgument]
t figura 10.18
Menu alla sezione 10.1.3
ModifyArgument alla sezione 10.1.16
Permette di inserire un nuovo argomento con un nome e una sua descrizione.
Figura 10.19: ShowTest – Lista dei quesiti di un compito gi`a assegnato
10.1.19 Visualizzazione di un compito gi`a assegnato [ShowTest]
t figura 10.19
Menu alla sezione 10.1.3
PrintTest alla sezione 10.1.14
ShowQuestion alla sezione 10.1.12
Questa pagina mostra la lista dei quesiti che formano un compito `e gi`a stato assegnato ad
un esame e che quindi non `e pi`u modificabile. Si possono vedere le singole domande (cliccando
sul memorandum del quesito) oppure il compito completo (cliccando su Mostra compito ).

140. 10.1 Accesso dal Web 129
Figura 10.20: ModifyTest – Form di modifica di un compito
10.1.20 Modifica di un compito non ancora assegnato [ModifyTest]
t figura 10.20
Menu alla sezione 10.1.3
NewTest alla sezione 10.1.21
ShowQuestion alla sezione 10.1.12
Questa pagina permette di modificare un compito aggiungendo o togliendo quesiti dagli
argomenti disponibili: per aggiungere un quesito basta cliccare su Aggiungi accanto ad uno
dei quesiti appartenenti all’argomento a destra oppure selezionando pi`u quesiti e premendo il
bottone Inserisci nel compito . Per rimuovere viceversa i quesiti dal compito basta selezionare i
quesiti da togliere e cliccare su Rimuovi quesito . Si pu`o anche assegnare un ordine prestabilito
(ordine di default) per la presentazione dei quesiti allo studente, assegnando un numero ad
ogni quesito, in base al quale verr`a ordinato; se invece si vuole che ogni studente abbia un
ordine di visualizzazione casuale allora `e sufficiente scegliere come Ordinamento dei quesiti
l’opzione random. Anche qui `e possibile visualizzare il testo di un singolo quesito o quello
dell’intero compito cliccando rispettivamente sui memorandum o su Mostra compito .
10.1.21 Creazione di un nuovo compito [NewTest]
t figura 10.21
Menu alla sezione 10.1.3
ModifyTest alla sezione 10.1.20
Permette di inserire un nuovo compito con un titolo che lo identifichi scegliendo l’ordina-
mento desiderato dei quesiti (vedi ModifyTest alla sezione 10.1.20).

141. 130 Manuale del docente
Figura 10.21: NewTest – Form per la creazione di un nuovo compito
10.2 Inserimento dei quesiti: e–Val Question Manager
Questa applicazione Java permette l’inserimento di nuovi quesiti e la modifica di quelli esi-
stenti; si scarica dalla pagina web ModifyArgument alla sezione 10.1.16 e pu`o essere usata da
qualsiasi computer che abbia la possibilit`a di stabilire un collegamento HTTP via Internet.
Per eseguire l’applicazione `e necessario che sia installata una JVM e digitare da una shell, il
seguente comando (specificando se necessario il nome del server):
java -jar eValQuestionManager.jar [nome del server]
Interfaccia grafica La finestra `e divisa in due parti (vedi la figura 10.22): un browser Web
nella parte superiore e vari comandi per il settaggio del parser e l’inserimento dei quesiti.
10.2.1 Il parser
e-Val accetta come quesiti validi qualsiasi documento HTML contenente dei campi che diano
la possibilit`a di dare una risposta. Per riconoscere la tipologia di risposta, ricavare la risposta
corretta, distillare opportunamente il codice HTML, e–Val Question Manager sottopone il
documento al parser che lo analizza prima di inserirlo nel database: i messaggi generati
durante questa operazione sono visualizzati nel riquadro in basso a destra.
10.2.2 Tipologie di quesiti
I tipi di quesiti in formato HTML che possono essere inseriti devono far parte di una di queste
quattro categorie:
Risposte a scelta singola (RADIO)
Lo studente pu`o scegliere una sola risposta tra quelle presentate, come si pu`o vedere in questo
esempio:

142. 10.2 Inserimento dei quesiti: e–Val Question Manager 131
Figura 10.22: Client docente per l’inserimento delle domande
Il codice HTMLper ottenere questo tipo di risposte `e il seguente:
INPUT type=”RADIO”Prima r i s p o s t a ;BR
INPUT type=”RADIO” checkedSeconda r i s p o s t a ;BR
INPUT type=”RADIO”Terza r i s p o s t a ;BR
La risposta corretta viene selezionata con l’aggiunta dell’attributo checked all’interno del tag.

143. 132 Manuale del docente
Risposte a scelta multipla (CHECKBOX)
Lo studente pu`o scegliere pi`u risposte tra quelle presentate come nel seguente esempio:
Il codice HTML per ottenere questo tipo di risposte `e:
INPUT type=”CHECKBOX” checkedPrima r i s p o s t a ;BR
INPUT type=”CHECKBOX”Seconda r i s p o s t a ;BR
INPUT type=”CHECKBOX” checkedTerza r i s p o s t a ;BR
Le risposte corrette vengono selezionate aggiungendo l’attributo checked all’interno dei tag.
Risposte ad intervallo di valori (RANGE)
Lo studente deve inserire un valore numerico che verr`a considerato esatto dal correttore
automatico, se `e compreso nell’intervallo di valori specificato come si pu`o vedere in questo
esempio:
Il codice HTML per ottenere questo tipo di risposte `e il seguente:
INPUT type=”TEXT” value =”12;12 14 ”
La risposta corretta va inserita nell’attributo value osservando le seguenti regole: i numeri
separati dal punto e virgola (;) rappresentano valori puntuali ammissibili (per esempio 23.5;
45.8; 0); i numeri separati dal trattino ( ), rappresentano l’intervallo aperto tra i due valori;
inf rappresenta l’infinito; per definire i valori possono essere inoltre usati il segno positivo (+)
e negativo (-) e il punto decimale (.). Per rappresentare per esempio l’intervallo 12 ≤ x 14
bisogna inserire la stringa 12;12_14.
Risposte libere (ANYTEXT)
Lo studente pu`o inserire una risposta libera in forma scritta all’interno dell’area di testo,
come mostrato in questo esempio:

144. 10.2 Inserimento dei quesiti: e–Val Question Manager 133
Il codice HTML per ottenere questo tipo di risposte `e il seguente:
TEXTAREA/TEXTAREA
In questo caso il correttore automatico non assegna un valore alla risposta che dovr`a invece
essere corretta dal docente.
10.2.3 Tag HTML speciali
Per preparare pi`u quesiti in uno stesso documento HTML si pu`o ricorrere a una di queste
due tecniche:
• si scrivono i quesiti uno di seguito all’altro separati da un tag HTML qualsiasi (per
esempio HR) e, al momento di inserirli, si specifica questo tag nella casella denominata
Tag separatori;
• oppure si inserisce tra un quesito e l’altro il seguente tag che serve anche per specificare
il memorandum del quesito successivo:
INPUT type=TEXT name=”Memorandum” value=”RAM s t a t i c a ”
Sempre all’interno del documento HTML si pu`o gi`a scrivere il commento ad un quesito
inserendo il seguente tag:
INPUT type=TEXT name=”Comment” value=”Qui va i l commento”
10.2.4 I comandi della finestra
Se si osserva la figura 10.22, partendo dall’alto i comandi sono cos`ı suddivisi:
• Login : permette di ricollegarsi al server nel caso in cui la connessione dovesse essersi
interrotta (per esempio se il client `e rimasto per tanto tempo inattivo);
• Chiudi : chiude l’applicazione;
• HTML : quando `e visualizzato un quesito, mostra il codice HTML sorgente; il browser
diventa allora un editor che permette di modificare il quesito a piacere;

145. 134 Manuale del docente
• Sostituisci quesito / Salva HTML : se `e visualizzato un quesito allora permette di sos-
tituirlo con quello specificato nel campo Nuovo quesito; se invece si sta modificando
il codice sorgente HTML di un quesito, allora lo sottopone al parser per verificarne la
validit`a e lo salva nel database;
• Mostra quesito : visualizza il quesito corrente;
• Inserisci nuovo quesito : sottopone al parser il quesito specificato nel campo Nuovo
quesito per verificarne la validit`a e lo salva nel database;
• Memorandum: qui va inserito il nome del memorandum del quesito che si vuole inserire;
• Inserisci quesito : permette di scegliere il quesito da inserire:
∗ da file HTML: viene visualizzato un form per la scelta di un file;
∗ modello con risposta ad intervallo di valori (RANGE);
∗ modello con risposte a scelta multipla (CHECKBOX);
∗ modello con risposta a scelta singola (RADIO);
∗ modello con risposta libera (ANYTEXT).
Figura 10.23: Visualizzazione di un quesito in e–Val Question Manager
Ci sono poi tre parametri (rappresentati da liste di tag HTML separati da virgole) che
riguardano alcune opzioni del parser e che vanno modificati con cautela:

146. 10.2 Inserimento dei quesiti: e–Val Question Manager 135
• Tag separatori: questi tag vengono utilizzati per separare pi`u quesiti all’interno dello
stesso documento HTML;
• Tag da escludere: i tag di questa lista vengono rimossi dal documento e non vengono
quindi salvati (utile per eliminare per esempio i link ipertestuali);
• Tag senza attributi: da questi tag verrano eliminati tutti gli attributi eventualmente
presenti (utile per i documenti HTML generati dagli editor grafici in cui per esempio
i tag P contengono spesso informazioni sulla formattazione grafica dei paragrafi, che
potrebbero venire visualizzati non correttamente).
Nelle pagine del browser integrato sono presenti dei bottoni che sono di facile comprensione
(vedi la figura 10.23):
• Argomenti: la lista contiene gli argomenti del corso; quando si cambia un argomento `e
necessario premere il pulsante Aggiorna ;
• Quesiti: la lista contiene i quesiti dell’argomento scelto; quando si cambia la selezione
di un quesito `e necessario premere il pulsante Aggiorna ;
• Rispondi (test) : questo bottone serve per verificare che l’invio al server Web delle
risposte dei quesiti avvenga correttamente; bisogna inserire una risposta qualsiasi, non
necessariamente quella giusta; e premere questo bottone: se la risposta non `e arrivata
correttamente al server verr`a visualizzato un messaggio di errore;
10.2.5 L’editor HTML
I quesiti inseriti nella base di dati possono venire modificati premendo il tasto HTML quando
`e visualizzato il quesito che interessa; la finestra allora cambia aspetto e si accede all’editor
illustrato in figura 10.24. In questa modalit`a `e anche possibile inserire un’immagine salvata
in un file premendo CTRL + [tasto sinistro del mouse]; per agevolare l’editing vengono
evidenziati i memorandum e i commenti; una volta terminata la modifica occorre premere il
tasto Salva HTML perch´e il quesito venga analizzato dal parser e salvato nella base di dati.
Se si preme Mostra quesito si ritorna alla normale visualizzazione del quesito corrente.
Anche se i documenti non sono strettamente conformi allo standard HTML, il parser cerca
comunque di ricavarne le informazioni utili alla definizione del tipo di risposta e della risposta
esatta; se segnala ci`o non `e possibile lo segnala con un messaggio di errore.
10.2.6 Procedura per l’inserimento di un quesito
Vengono ora descritte le operazioni da compiere per l’inserimento di un quesito:
• si seleziona l’argomento in cui si vuole inserire il quesito o i quesiti e si preme il bottone
Aggiorna ;
• si inserisce nella casella di testo Memorandum un nome che descriva il quesito e che lo
identifichi univocamente all’interno dell’argomento;

147. 136 Manuale del docente
Figura 10.24: Editor del sorgente HTML di un quesito
• si clicca sulla casella combinata Inserisci quesito e si sceglie un modello di quesito
predefinito oppure un file HTML precedentemente creato, contenente uno o pi`u quesiti
e che deve osservare le regole sulle tipologie di quesiti spiegate nella sezione 10.2.1;
• si clicca il bottone Inserisci nuovo quesito (o Sostituisci quesito se lo si vuole inserire
in sostituzione di quello visualizzato);
Il parser a questo punto visualizzer`a alcune informazioni: gli eventuali errori riscontrati, il
numero dei quesiti analizzati e di quelli correttamente salvati.
Se si `e inserito un modello preimpostato di quesito lo si pu`o modificare cliccando sul
bottone HTML ; in questo modo c’`e anche la possibilit`a di inserire il testo della domanda, le
eventuali immagini e i campi per le risposte;
10.3 Schema logico di utilizzo
Questa sezione spiega quali siano le operazioni da seguire per preparare da zero un appelo
d’esame. Prima di tutto bisogna collegarsi con un browser Web all’indirizzo
localhost:8080/eVal/Welcome.teacher
inserire la login e la password del corso che interessa e premere Entra ; la prima pagina
visualizzata `e il menu principale dell’applicazione. A questo punto le fasi da seguire (fare
riferimento allo schema della figura 10.25) sono le seguenti:
1. si definiscano uno o pi`u argomenti trattati dal corso premendo il tasto Nuovo nella
sezione degli argomenti;

148. 10.3 Schema logico di utilizzo 137
2. servendosi dell’applicazione e–Val Question Manager, si inseriscano alcuni quesiti rag-
gruppati per argomenti (vedi la sezione 10.2.6);
3. si creino uno o pi`u compiti (bottone Nuovo nella sezione di compiti del menu princi-
pale), costituiti dai quesiti precedentemente inseriti;
4. si crei un appello d’esame in cui iscrivere gli studenti e assegnare loro i compiti preceden-
temente creati; poich´e l’aula di informatica per svolgere l’esame pu`o avere un numero di
postazioni limitato, gli studenti possono essere divisi in gruppi e fatti entrare a turno,
non appena il gruppo precedente ha concluso l’esame;
5. si stampi la lista degli studenti iscritti con le relative password di accesso;
6. si attivi l’esame; bisogna prestare attenzione all’attivazione di un esame in quanto il
sistema non controlla l’ora e la data dell’esame ma solamente se l’esame `e o no attivo.
7. il giorno dell’appello si esponga la lista degli iscritti nell’aula di informatica e si facciano
entrare a turno i gruppi di studenti come indicato nella lista.

149. 138 Manuale del docente
Creazione di un nuovo compito
Inserire un titolo per il compito
Specificare l’ordinamento dei quesiti
Creazione di un nuovo argomento
Inserire un nome per l’argomento
Inserire una descrizione
Inserimento di alcuni quesiti
Avvio dell’applet per inserire nuovi quesiti
Premere il pulsante [Mostra quesiti]
Scegliere l’argomento e premere il pulsante [Aggiorna]
Inserire un memorandum valido
Premere il pulsante [Inserisci quesiti]
Scegliere il tipo di quesito che si vuole inserire
Premere il pulsante [Inserisci nuovo quesito]
Modificare eventualmente il quesito premendo il pulsante [HTML]
Ripetere le precedenti operazioni per inserire più quesiti
Inserimento di quesiti nel compito
Selezionare i quesiti da aggiungere
Premere il pulsante [Inserisci nel compito]
Oppure cliccare direttamente su [Aggiungi]
a fianco di ogni quesito
Creazione di un nuovo esame
Inserire un nome per l’appello d’esame
Scegliere la data e l’ora dell’appello
Inserire la durata dell’esame
Inserire il numero di studenti per ogni gruppo
Inserire se necessario un avviso per lo studente
Iscrizione degli studenti all’esame
Srivere nell’area di testo la lista degli studenti
Assegnazione dei compiti
Selezionare uno o più compiti dalla tabella dei compiti disponibili
Tabella d’esame degli studenti iscritti
Controllare che la tabella sia completa
Stampare la lista da affiggere in aula
Attivazione dell’esame
Attivare l’esame premendo sul [Sì]
Premere il pulsante [Nuovo] argomento
Scaricare l’applet e-Val Question Manager
[Salva l’argomento]
Già inseriti tutti gli argomenti necessari
[Menu principale] per crearne un altro
Premere [Menu principale] e successivamente [Nuovo] compito
[Salva il compito]
Selezionare un argomento tra quelli disponibili
[Menu principale] per crearne un altro
Premere il pulsante [Nuovo] esame
[Salva l’esame]
[Iscrivi studenti]
Iscrivere ancora studenti
[Menu principale], selezionare un esame e premere [Vai]
Già iscritti all’esame tutti gli studenti
[Pagina precedente]
Può iniziare lo svolgimento dell’esame
[Assegna compito] e [Tabella esame]
Figura 10.25: Diagramma per la preparazione di un’esame: i termini tra pa-
rentesi quadre rappresentano i bottoni da premere nei form delle pagine
Web.

150. 10.3 Schema logico di utilizzo 139
Scelta dello schema di correzione
Definire la relazione lineare punteggio-voto
Dare il peso alle risposte (compreso tra 0 e 1)
Scegliere se considerare le risposte parziali (solo per CHECKBOX)
Controllo dell’esito del compito
Verificare le difficoltà incontrate nello svolgere il compito
Aggiungere o togliere una frazione di punteggio ai quesiti
Scelta dei parametri della lista dei risultati
Scegliere se mostrare il voto degli insufficienti
Scegliere se dare o meno la lode
Scegliere se mostrare o no gli assenti
Stampa della lista dei risultati
Scegliere l’esame voluto e premere [Vai]
[Calcola voti]
Se l’esito dei compiti non è soddisfacente
Cliccare su uno dei compiti dati
[Aggiorna punteggi]
[Pagina precedente] per controllare un altro compito
[Tabella risultati]
Figura 10.26: Diagramma per la correzione di un’esame: i termini tra parentesi
quadre rappresentano i bottoni da premere.
10.3.1 Correzione dei compiti e stampa dei risultati
Seguendo lo schema della figura 10.26 `e necessario:
1. scegliere dal menu principale l’esame desiderato e premere Vai ;
2. definire la retta di conversione punteggi–voti inserendo due corrispondenze tra punteggi
e voti;

151. 140 Manuale del docente
3. scegliere i tre pesi per le risposte corrette, non date ed errate;
4. stampare la tabella dei risultati con il bottone Tabella risultati .
Queste operazioni possono essere compiute gi`a durante lo svolgimento dell’esame, con la
possibilit`a di seguire “in diretta” l’andamento dell’esame (per aggiornare la pagina premere
il pulsante in alto Aggiorna ); bisogna fare attenzione comunque a non visualizzare la tabella
dei risultati perch´e disattiverebbe automaticamente l’esame interrompendone lo svolgimento.

152. Capitolo 11
Manuale dello studente
Figura 11.1: Pagina di benvenuto di e–Val Student.
Questo manuale `e rivolto agli studenti che devono utilizzare il sistema e-Val per sostenere
un esame. Per mandare in esecuzione il client e–Val Student e cominciare a sostenere l’esame
bisogna aprire una shell e digitare il comando (specificando se necessario il nome del server)
java -jar eValStudent.jar [nome del server]
A questo punto dovrebbe comparire una pagina di benvenuto come `e mostrato nella figura
11.1); dopo qualche istante una piccola finestra chieder`a di inserire il numero di matricola e
la password.

153. 142 Manuale dello studente
11.1 Svolgimento dell’esame
Quando viene visualizzata la finestra di autenticazione
`e necessario inserire la propria matricola e la password che sono state comunicate all’inizio
dell’esame: non c’`e distinzione tra lettere maiuscole e minuscole. Dopo aver premuto OK ,
se i dati sono corretti compariranno, nella parte alta della finestra, il nome dello studente, il
numero di matricola e il nome dell’appello d’esame e verr`a mostrata una pagina di avvisi da
leggere con cura, come questa:
Per iniziare l’esame basta premere il bottone Primo quesito .
Appena inizia l’esame il tempo a disposizione comincia a scorrere in alto a destra e viene
presentato il primo quesito (si veda la figura 11.2). Nella prte bassa del quesito si trova il
tasto Rispondi che permette di rispondere alla domanda proposta; se la risposta manca o
`e in un formato non corretto (nel caso si introduca una parola quando invece `e richiesto un
valore numerico) verr`a visualizzato il seguente messaggio di errore:
Gli altri tre bottoni presenti hanno queste funzioni: uno permette di passare al quesito suc-
cessivo senza rispondere a quello che si sta visualizzando, gli altri due terminano l’esame

154. 11.1 Svolgimento dell’esame 143
Figura 11.2: Quesito presentato allo studente da e–Val Student.
ritirandosi oppure consegnando l’elaborato cos`ı com’`e. Le domande vengono presentate in
sequenza ciclica, cio`e dopo l’ultimo si ritorna al primo. Le domande invece a cui sono gi`a
state date le risposte non verranno pi`u riproposte.
Se durante l’esame si dovesse chiudere o abbandonare il client comparirebbe il messaggio:
l’azione allora viene registrata dal server che invier`a al docente un messaggio di avviso.
Quando sono state date tutte le risposte alle domande o si `e esaurito il tempo a disposizione
viene visualizzato questo messaggio:
A questo punto non occorre fare altro che aspettare la chiusura automatica del client; d’ora
in poi l’accesso al sistema viene negato.

155. 144 Manuale dello studente

156. Parte IV
Appendici

158. Appendice A
Il CD–ROM allegato
A corredo di questa tesi `e stato creato un CD–ROM contenente l’applicazione, i sorgenti,
la documentazione, i javadoc e tutto quello che `e servito per realizzare il progetto. Ecco i
contenuti delle directory:
• doc contiene tutti i files che servono per compilare la tesi con LATEX; include anche:
∗ tools sono tutte le applicazioni e i manuali che sono serviti per la stesura della tesi
e della documentazione: jalopy per la formattazione del codice in modo da renderlo
ben leggibile; latex contiene i manuali dei principali pacchetti usati per la stesura
della tesi; postscript contiene i manuali di Adobe per il linguaggio PostScript; UML
contiene l’applicazione ArgoUML, le specifiche e i manuali dell’Unified Modeling
Language (uno standard per la progettazione orientati agli oggetti);
∗ erwin contiene gli schemi logico e fisico della base di dati realizzati con l’appli-
cazione ERwin;
∗ history contiene alcuni cenni storici sulle tecnologie che si sono utilizzate;
∗ Javadoc sono i Javadoc dell’applicazione e-Val;
∗ UML contiene i diagrammi realizzati con il programma ArgoUML;
• project contiene tutte i files che riguardano la realizzazione del progetto:
∗ build contiene i package con le classi Java compilate;
∗ source contiene i sorgenti dell’applicazione;
∗ Comune contiene i sorgenti e i files necessari per la compilazione del package eVal;
∗ Docente contiene i sorgenti e i files necessari per la compilazione del package
eValTeacher;
∗ Server contiene i sorgenti e i files necessari per la compilazione del package
eValServer;
∗ Studente contiene i sorgenti e i files necessari per la compilazione del package
eValStudent;

159. 148 Il CD–ROM allegato
∗ DB contiene il codice SQL per la creazione della base di dati;
∗ Testing contiene degli esempi di quesiti da inserire nel sistema;
• Technologies contiene le directory corrispondenti alle varie tecnologie adottate; al-
l’interno di ognuna si trovano documenti, applicazioni, manuali, pagine HTML che sono
servite alla realizzazione dell’applicazione;
• Official release contiene i files per l’installazione di e-Val e i manuali d’uso.

160. Appendice B
Colofone
Questa tesi `e stata scritta con il sistema di composizione del testo LATEX2ε a cui sono stati
aggiunti i seguenti pacchetti:
• caption2 per le didascalie delle figure;
• fancyhdr per l’intestazione delle pagine;
• fncychap per la formattazione dei capitoli;
• listings per l’inserimento e la formattazione dei pezzi di codice da inserire nel testo;
• longtable per il supporto di tabelle su pi`u pagine;
• inputenc per l’uso del set esteso di caratteri;
• multicol per la distribuzione del testo su pi`u colonne;
• graphicx per l’inserimento delle figure.
Molti dei diagrammi e degli schemi presentati nel testo, sono stati realizzati con l’ap-
plicazione ArgoUML, seguendo le notazioni dello Unified Modeling Language (UML) spon-
sorizzato dall’Object Management Group (OMG). UML `e un linguaggio grafico orientato agli
oggetti, utile per la visualizzazione, la progettazione, la costruzione e la documentazione dei
vari componenti di una applicazione software; in generale, `e adatto a descrivere anche altri
tipi di sistemi.

161. 150 Colofone

162. Bibliografia
[1] David Harms: JSP, Servlet e MySQL, McGraw–Hill (2001)
Database
[2] Atzeni–Ceri–Paraboschi–Torlone: Basi di dati, McGraw–Hill (1999)
[3] Maristella Agosti: Appunti di Basi di Dati, Corso di laurea in Ingegneria
Informatica (A.A. 2000/2001)
[4] Axmark – Widenius – Cole – DuBois: MySQL Reference Manual, MySQL AB (2001)
[5] Marc A. Mnich: Multi Tier Architectures for Database Connectivity, JavaExchange
(1998)
[6] JavaExchange: DbConnectionBroker
www.javaexchange.com
[7] Jon Ellis – Linda Ho: JDBCTM 3.0 Specification, Sun Microsystems (2001)
Java
[8] Herbert Schildt: JavaTM 2 – The complete reference, McGraw–Hill (1999)
[9] James Gosling – Bill Joy – Guy Steele – Gilad Bracha: The JavaTM Language
Specification Second Edition, Addison–Wesley (2000)
[10] JavaTM 2 SDK, Standard Edition Documentation v1.3.1, Sun Microsystems (2001)
[11] Vari: The JavaTM tutorial, Sun Microsystems (2001)
[12] John D. Mitchell – Arthur Choi: Java Tip 49: How to extract Java resources from
JAR and zip archives, JavaWorld (1998)
[13] Z. Steve Jin – John D. Mitchell: Java Tip 120: Execute self–extracting JARs,
JavaWorld (2001)