repairpdf_Oy51nCFX

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

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

ii INDICE
4.2 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Criticità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5 Progettazione della base di dati 37
5.1 Progettazione concettuale: lo schema Entità–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à 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

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à assegnato [ShowTest] . . . . . . . . 128
10.1.20Modifica di un compito non ancora assegnato [ModifyTest] . . . . . . 129
10.1.21Creazione di un nuovo compito [NewTest] . . . . . . . . . . . . . . . . 129

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 ﬁnestra . . . . . . . . . . . . . . . . . . . . . . . . . . 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
Bibliograﬁa 151

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à–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

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

Introduzione
Questa tesi nasce dall’esigenza di automatizzare, per quanto possibile, il processo di esecuzione
e correzione degli esami universitari e più 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; è inoltre in grado di soddisfare
contemporaneamente più studenti e più docenti (ambiente multi–authoring). La persisten-
za dei dati è 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 È formata da tre parti più 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ù 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.

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é più
adatte a svolgere quel particolare compito; vengono ora descritte brevemente, soffermandosi
soprattutto sugli aspetti più interessanti ai fini progettuali. Ogni sezione inizia con una piccola
introduzione storica e qualche curiosità.
L’applicazione è 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è 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 è un linguaggio di programmazione general–purpose, concorrente, basato su classi e
orientato agli oggetti; deriva dal C e dal C++ ma è organizzato in modo differente, con molti
aspetti omessi e nuove idee prese da altri linguaggi. Ecco i punti di forza di questo linguaggio:
• semplice: è 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ù 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;

6 Tecnologie lato server
• robusto: è fortemente tipizzato quindi controlla il codice già durante la compilazione;
inoltre non c’è la necessità di dover liberare la memoria quando si è terminato di usare
un oggetto perché questo compito è demandato al garbage collector; anche la gestione
delle eccezioni è 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 è 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 è stato pensato per ottenere alte prestazioni e può 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’è 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 è nè
abbastanza veloce nè tanto flessibile anche perché 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 è ancora un mistero: per più di 10 anni i nomi della directory principale e
di un grande numero di librerie avevano il prefisso “my”; è 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 è un sistema di gestione di database relazionali Open Source. Un database è 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ù tabelle, tra le quali

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è quando si interroga il database.
Essendo inoltre Open Source, MySQL può essere scaricato liberamente da Internet, usato
e modificato per soddisfare le esigenze di ogni utilizzatore. Le caratteristiche principali di
MySQL sono:
• affidabilità: questo sistema vanta ormai un numero elevato di installazioni in tutto il
mondo e si è guadagnato una buona reputazione per la sua affidabilità (vedi la lista
degli utenti contenuta nell’appendice B di [4]);
• velocità: è 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à: in linea generale la capacità di MySQL in termini di database è limitata
dalle dimensioni massime dei file ammesse dal sistema operativo: su un PC con Linux,
ad esempio, è 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; è 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 è un
dialetto dell’SQL (acronimo di Structured Query Language); sono stati inoltre introdotti
nuovi domini per i dati, nuove parole chiave e funzionalità specifiche.
Naturalmente i vantaggi di MySQL vengono pagati con la mancanza di alcune caratteristiche
importanti:
• non è 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);

• il supporto alle transazioni è 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à 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è 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ù significativo
è 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à 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
è 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 è un linguaggio per i sistemi di gestione di database relazionali. Infatti contiene al
suo interno sia le funzionalità 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à la versione del 1992 (SQL–2) è
un linguaggio ricco e complesso, tanto che ancora molti sistemi commerciali non mettono a
disposizione tutte le funzionalità previste dallo standard.
Per quantificare in modo preciso l’aderenza allo standard, sono stati definiti tre livelli di
complessità dei costrutti del linguaggio, denominati rispettivamente Entry SQL, Intermediate
SQL e Full SQL.
1.2.2 Il pool di connessioni: DbConnectionBroker
DbConnectionBroker è 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

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ò 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ò sulle performance e sugli aspetti più pragmatici. Diventò
presto evidente che i due progetti si sovrapponevano e che gli sforzi si sarebbero dovuti unire.
Nel 1999 la Sun donò 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ò per includere tutti i progetti open–source dell’Apache Java group. Tomcat
è 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 è un server Web completamente scritto in Java; più 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ù 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ò essere
affiancato ad un server Web in tre modi:
• in–process: il servlet container è 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à e l’affidabilità (il crash di un qualsiasi thread può 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;

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 è 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
è detto, può essere fisicamente separato;
• il servlet container determina, in base alla sua configurazione e ai parametri della
richiesta, a quale servlet dovrà 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 è 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;

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ò 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ò
la base di partenza per i servlet. Un progetto più ampio emerse nel 1996 da una gruppo di
sviluppatori capeggiati da Pavani Diwanji, che portò 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ò 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

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à di distribuire contenuti personalizzati a vari utenti collegati in Internet,
aveva portato all’uso delle applet Java; avevano però 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ò 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à 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à rispetto agli script CGI poiché 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 è dispendiosa in termini di tempo della
CPU, di memoria e di risorse è 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 è 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 è 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 è di tipo GET;
• doPost viene invocato quando la richiesta HTTP è di tipo POST.

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 è 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, è 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ù richieste HTTP e per salvare informazioni riguardanti l’utente che
visita un sito; l’Hypertext Transfer Protocol (HTTP) è 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: è il sistema più usato; il container invia un cookie al client che lo rispedirà
al server ad ogni richiesta successiva, permettendo di associarla alla sessione senza
possibilità di errore;
∗ sessioni SSL: la tecnologia di criptazione Secure Sockets Layer usata nel protocol-
lo HTTPS, implementa già 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ò 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:

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ù transazioni;
i metodi più 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ù 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 è 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 è stata trovata con le JavaServer PagesTM. Una JSP
è 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ù precisamente una pagina JSP
può 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ù 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à del bean; la terza include altri files esterni o JSP.

• 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 è:
<%! 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 è
<% 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: è un’espressione in linguaggio Java che viene valutata e il cui risultato
è forzatamente convertito in una stringa; il risultato è successivamente inviato al
client; la sintassi è:
<%= expression %>
come per esempio <%= (new java.util.Date()).toLocaleString() %>;
Nella pratica non è buona norma inserire troppo codice nella JSP perché ridurrebbe la
leggibilità e l’efficienza ddi questa tecnologia; diventa allora più conveniente usare dei
tag personalizzati oppure dei JavaBeans;
• dati statici: è tutto ciò che non rientra nelle categorie precedenti e rappresentano le
parti fisse (template); possono essere per esempio del testo, del codice HTML o XML.
Quando è 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 rieseguire gli stessi metodi su threads concorrenti.
Per una descrizione più 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

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è 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à.
g Jakarta Taglibs: jakarta.apache.org/taglibs
1.4 I JavaBeans
Come si è accennato non è molto comodo e conveniente inserire troppo codice Java (cioè
scriptlet) all’interno delle pagine JSP. Può 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à 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 è molto complessa ma vale la pena di elencare alcune
caratteristiche:
• non devono avere alcuna proprietà pubblica;
• le proprietà che devono essere esposte dovranno avere metodi get e set secondo necessità
(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à dei beans (vedi la
sezione 1.3.1).
g JavaBeansTM technology: java.sun.com/beans

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 è imposto grazie alla crescita esplosiva del Web.
Durante questo tempo l’HTML è 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ò 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ù 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à
di nuove caratteristiche. Gli sforzi del Gruppo di lavoro su HTML all’interno del World Wide
Web Consortium (W3C), per codificare ciò che era d’uso comune nel 1996, sfociarono nell’HTML
3.2 (Gennaio 1997). L’HTML 4 estende le possibilità dell’HTML con meccanismi per i fogli di
stile, lo scripting, i frame, gli oggetti incorporati con l’offerta di una maggiore accessibilità per le
persone affette da disabilità. L’HTML è 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à 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, è necessario usare un
linguaggio universalmente compreso, una specie di madre lingua per l’editoria che tutti i

18 Tecnologie lato client
computer siano in grado potenzialmente di comprendere. Il linguaggio di pubblicazione usato
dal World Wide Web è l’HTML. L’HTML dà 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ò 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 è 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

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à un traguardo dell’HTML
dal suo inizio nel 1990: Tim Berners–Lee realizzò 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ò 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ò 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à di combinare (cascading) stili diversi definiti sia dall’autore
che dal fruitore dei contenuti, tenendo conto delle possibilità di visualizzazione del browser. Nel
dicembre del 1996 il CSS level 1 diventò 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ò a supportare i
fogli di stile nelle successive versioni di Internet Explorer che diventò, 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ò 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>

<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ò 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à più importanti del formato CSS ci sono
• lo sfruttamento dell’incapsulamento degli elementi di un documento HTML mediante i
meccanismi dell’ereditarietà cioè della propagazione delle informazioni di formattazione
ai sottoelementi di un documento
• l’unione di più fogli di stile mediante alcune regole di priorità (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ò LiveScript (chiamato cos`ı per indicarne la vivacità e dinamicità). 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ù 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à dello stesso linguaggio anche se rimangono qua e là delle differenze
tra le implementazioni di browser diversi. y
JavaScript è 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à. 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

2.2 I browser Web 21
carica il documento, legge lo script che viene interpretato ed eseguito. Un esempio di codice
è 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. È 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ù versatile, multipiattaforma,
interfaccia a Web e realizzata in C. Poiché permetteva di vedere documenti con immagini incluse,
trasferire in rete suoni o videoregistrazioni e di puntarli da un documento, diventò ben presto il
browser Web per eccellenza per tutti i lavori su computer con capacità grafiche. Nel corso del
1995, Mosaic viene praticamente abbandonato (l’ultima versione è del 1997), per lasciare spazio
ad un nuovo browser, che dà 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ù
appropriata; le versioni più 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
è talvolta parziale o addirittura assente. Questo crea non pochi problemi di compatibilità tra
browser diversi obbligando spesso gli sviluppatori Web a creare documenti diversi a seconda
del browser che li caricherà (vedi la tabella 2.1).
g Mozilla: www.mozilla.org
g Microsoft Internet Explorer: www.microsoft.com/ie
g Netscape Navigator: www.netscape.com

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à è supportata, i significa che non è pienamente supportata.
2.3 Swing Java applet
Swing è 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ò, 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ù utili
e interessanti di Swing è la classe javax.swing.JEditorPane che permette di visualizzare,
oltre che editare, vari tipi di contenuti testuali:
• text/plain: testo semplice;

2.3 Swing Java applet 23
• text/html: testo in formato HTML 3.2; la sua visualizzazione grafica è 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à 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 è presente un bug per cui JEditorPane non riesce a collegare correttamente
gli stili ai tag HTML specificati con lettere maiuscole.

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 è stato sviluppato da un team di sviluppatori che lavoravano al CERN
(Centre Europé en de Recherche Nucléaire). 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. È
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 è la seguente:
Richiesta
Risposta
Client Web Server

26 Tecnologie di comunicazione
In realtà la situazione è 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 è 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ò 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ò 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à specificate.
Il metodo POST di questa classe permette di inviare anche oggetti Java serializzati; quando il
server li riceve dovrà deserializzarli prima di poterli usare. Nel caso in cui li riceva un servlet,
questi li può 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ù sorgenti di dati. Nella maggior parte dei casi, la
sorgente di dati è un DBMS relazionale e i suoi dati sono accessibili formulando interrogazioni
SQL.
Il package che include le varie API è 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 è soprattutto un insieme di interfacce in cui la loro implementazione è
lasciata ai driver dei singoli DBMS. Per MySQL il driver di riferimento si chiama Connector/J
(nelle versioni precedenti MM.MySQL).

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à 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à 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à
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ò per esempio gestire il pool di
connessioni al database e interagire direttamente con il driver JDBC;

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à al database;
3. Sorgente di dati – è il livello in cui risiedono i dati e spesso è rappresentato da un
DBMS relazionale, ma può 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

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à 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à dare la possibilità 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à 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.

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à
incontrate dagli studenti nel rispondere alle domande, la possibilità di salvare su file i
quesiti inseriti.
4.2 Analisi dei requisiti
Il sistema deve gestire più di un corso di insegnamento per il quale si possono svolgere degli
appelli d’esame; un corso è 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ù quesiti riguardanti gli argomenti del corso; i quesiti possono essere
di vari tipi: a risposta multipla (cioè 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é 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ù compiti, fissare un appello d’esame ed iscrivere gli studenti; l’applicazione dovrà
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

4.3 Vincoli 33
non è 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ò notare l’applicazione è stata sviluppata su piattaforma Windows anche se dovrà
essere installata su un sistema Linux; ciò è permesso dalla tecnologia Java che garantisce la
massima portabilità del software.
4.4 Criticità
Di seguito sono descritti i casi più critici che hanno richiesto uno sforzo particolare per essere
risolti, e accanto ad ognuno un breve cenno sulle azioni intraprese per affrontarli.
Descrizione criticità Azione
Implementazione di una 3–tier archi-
tecture evitando cioè 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

34 Piano di progetto
Descrizione criticità 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à
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à 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, è una struttura
orientata ai risultati che raggruppa gli elementi del progetto al fine di organizzare e definire
il campo d’azione complessivo del progetto.

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
(

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

ŠŸŠ ŽŠ—œ)
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.

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
è rappresentato dallo schema Entità–Relazione (ER) accompagnato dal Dizionario dei
dati che ne descrive in modo informale le entità 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è quegli attributi di un’entità che ne identificano univocamente le occorrenze.
La fase successiva è 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à dello schema di una base di dati relazionale è “certificata” da alcune proprietà
dette forme normali. Il rispetto di tali proprietà assicura che lo schema relazionale abbia
caratteristiche di qualità che garantiscono in particolare che il suo uso non creerà una base di
dati soggetta ad anomalie di aggiornamento. Spesso le tecniche sopraesposte producono già
schemi che sono in forma normale, però comunque la normalizzazione è utile perché costituisce
uno strumento di verifica e che può suggerire ulteriori migliorie.
L’ultima fase progettuale prevede l’implementazione dello schema logico per lo specifi-
co DBMS (MySQL), producendo lo schema fisico, cioè 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ò 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]).

38 Progettazione della base di dati
5.1 Progettazione concettuale: lo schema Entità–Relazione
Lo schema concettuale del progetto ricavato analizzando i requisiti, le entità che apparten-
gono alla realtà da modellare (appelli d’esame, studenti, corsi, iscrizioni, ecc.) e le relazioni
che legano queste entità, sono presentati in figura 5.1. I costrutti utilizzati dal modello ER
sono i seguenti:
Entità rappresentano classi di oggetti (per esempio studente,
corso, esame) che hanno proprietà 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ù entità; vengono specificate anche
le cardinalità che indicano il numero minimo e massimo
di occorrenze di relazione cui una occorrenza dell’entità
può partecipare (per esempio l’iscrizione di uno studente
ad un esame è una relazione tra l’esame e lo studente, in
cui lo studente partecipa con cardinalità (1,N) cioè può
iscriversi ad uno o più esami, mentre l’esame partecipa con
cardinalità (0,N) cioè può avere come iscritti più di uno
studente come anche nessuno);
Attributi descrivono le proprietà elementari di entità o relazioni;
Attributi composti sono dei raggruppamenti di attributi di una medesima
entità o relazione che presentano affinità nel loro significato;
Identificatori interni vengono specificati per ciascuna entità di uno schema e
descrivono i concetti (attributi o entità) dello schema che
permettono di identificare in maniera univoca le occorrenze
delle entità.

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

Descrizione entità 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à 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ù quesiti e
che può essere sottoposto
agli studenti
Title (titolo del compito), Template (specifica se il compito è stato
creato dal docente oppure in modo automatico), Sorting (ordina-
mento dei quesiti nel compito: può essere casuale oppure deciso
dal docente), Difficulty (difficoltà del compito come media delle
difficoltà 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 è 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 è 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à.

5.1 Progettazione concettuale: lo schema Entità–Relazione 41
Descrizione relazione Entità coinvolte Attributi
Answer: risposta che lo
studente dà 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 è accaduta
Action (1,1), Exam
(0,N)
Tabella 5.5: Dizionario dei dati: relazioni.

Le tabelle 5.3 e 5.5 costituiscono il dizionario dei dati diviso in entità e relazioni: spiegano
quali siano i significati degli elementi usati nel modello ER per rappresentare la realtà che si
stanno analizzando.
Da una prima analisi lo schema concettuale risulta
• corretto perché utilizza propriamente i costrutti messi a disposizione dal modello ER,
• completo perché rappresenta tutti i dati di interesse,
• leggibile perché rappresenta i requisiti in modo naturale e facilmente comprensibile,
• non minimale cioè 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ò
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 è stata compilata una tavola dei volumi (vedi tabella 5.7) che stima
il numero di occorrenze delle varie entità 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)

5.2 Schema logico 43
Regole di vincolo
RV1 Se un esame non è attivo (cioè Exam.Active è ‘no’) non è possibile inserire
risposte a quesiti (Answer), iniziare lo svolgimento dell’esame (Execution) o
inserire un’azione (Action) per quell’esame
RV2 Se un esame è attivo (cioè Exam.Active è ‘yes’) non possono essere modificati
le assegnazioni dei compiti agli studenti (cioè Assignment) e i compiti stessi
(cioè Test, Composition, Question)
RV3 Non possono venire inserite risposte date dallo studente dopo che è trascor-
so il tempo a disposizione per svolgere l’esame (cioè Answer.Time non deve
superare Execution.Start aumentato di Execution.MaxLength minuti)
Regole di derivazione
RD1 La difficoltà di un compito (Test.Difficulty) viene calcolata come la media
delle difficoltà dei singoli quesiti nel momento in cui viene creato o modificato
il compito
RD2 La difficoltà di un quesito (Question.Difficulty) viene calcolata dividendo
il numero delle risposte corrette per il numero di volte che quel quesito è 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
è 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 è Exam.RightAnswerValue, per una sbagliata è Exam.WrongAnswerValue
mentre per una non data è 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à 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 è già 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à di un compito (B–100/anno)
18. Aggiungere una domanda ad un compito (I–850/anno)

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à di un quesito (B–850/anno)
30. Spostare dei quesiti da un argomento ad un altro (I–non stimabile)

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à di modificare lo schema di
correzione (I–50/anno)
45. Visualizzare l’esito dell’esame di uno studente con la possibilità 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.

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à.
Analisi delle ridondanze Come anticipato nella sezione 5.1 a proposito della minimalità
dello schema concettuale e come si deduce dalle regole di derivazione della tabella 5.6, esistono
delle ridondanze che si è 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à 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 è 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 è duplicata per tenere traccia anche degli eventuali studenti che

repairpdf_Oy51nCFX

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to repairpdf_Oy51nCFX

Similar to repairpdf_Oy51nCFX (20)

repairpdf_Oy51nCFX