Progetto di tecnologie informatiche per la realizzazione di

POLITECNICO DI TORINO
III Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Tesi di Laurea
Progetto di tecnologie
informatiche per la realizzazione di
un Sistema Informativo finalizzato
alla gestione di scavi archeologici
Relatori:
prof. Angelo Raffaele Meo
prof. Alessandro Roccati
ing. Gianluca Cumani
Candidati:
Davide Boltri
Matteo Onofrio Bovero
Gennaio 2007
Indice
Prefazione
1
1 Introduzione
1.1 L’archeologia che si evolve
1.2 Il progetto ArcheoMap . .
1.3 ArcheoMap e l’open source
1.4 Organizzazione del volume
.
.
.
.
3
3
4
5
6
.
.
.
.
.
.
.
.
.
.
.
7
7
9
11
11
13
31
31
32
34
36
38
.
.
.
.
.
.
.
.
.
45
45
46
47
49
50
50
54
54
55
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Il Database di ArcheoMap
2.1 Nozioni generali sui Database . . . . . . . . .
2.2 I requisiti del Database . . . . . . . . . . . . .
2.3 Progetto concettuale . . . . . . . . . . . . . .
2.3.1 Modello entità-relazioni . . . . . . . .
2.3.2 Stesura del modello E-R di ArcheoMap
2.4 Progetto logico . . . . . . . . . . . . . . . . .
2.4.1 Ristrutturazione dello schema E-R . .
2.4.2 Ristrutturazione del diagramma E-R di
2.4.3 Traduzione verso il modello logico . . .
2.4.4 Schema logico del progetto ArcheoMap
2.4.5 Progettazione fisica . . . . . . . . . . .
3 L’interfaccia Web
3.1 Introduzione alla tecnologia Web . .
3.2 Requisiti per la realizzazione del sito
3.3 Architettura generale . . . . . . . . .
3.4 Apache e il linguaggio PHP . . . . .
3.5 L’interfaccia del sito . . . . . . . . .
3.5.1 Creazione del template . . . .
3.5.2 CSS . . . . . . . . . . . . . .
3.6 Business Logic . . . . . . . . . . . . .
3.6.1 Le Web application . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
ArcheoMap
. . . . . . .
. . . . . . .
. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.7
3.6.2 PEAR DB, l’interfaccia al database
3.6.3 Gestione della sicurezza . . . . . .
3.6.4 L’interfaccia multilingua . . . . . .
Le pagine del sito . . . . . . . . . . . . . .
3.7.1 Pagina di login . . . . . . . . . . .
3.7.2 Elenco dei progetti . . . . . . . . .
3.7.3 Dettagli della località . . . . . . . .
3.7.4 Inserimento di una nuova località .
3.7.5 Diario si scavo . . . . . . . . . . . .
3.7.6 Inserimento nuovo articolo . . . . .
3.7.7 Galleria fotografica . . . . . . . . .
3.7.8 Dettagli immagine . . . . . . . . .
3.7.9 Elenco dei reperti . . . . . . . . . .
3.7.10 Dettagli reperto . . . . . . . . . . .
3.7.11 Gestione dei permessi . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Gestione delle mappe
4.1 Introduzione ai sitemi GIS e al Web mapping
4.1.1 Formati digitali delle mappe . . . . . .
4.1.2 Gestori delle mappe . . . . . . . . . . .
4.1.3 GIS e Web Mapping . . . . . . . . . .
4.2 Requisiti del sistema di Web Mapping . . . . .
4.3 Il gestore di mappe: MapServer . . . . . . . .
4.3.1 Il mapfile . . . . . . . . . . . . . . . .
4.3.2 I layer di ArcheoMap . . . . . . . . . .
4.3.3 PHP/MapScript . . . . . . . . . . . .
4.4 MapServer integrato nel sito di ArcheoMap . .
4.5 Google Maps . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
57
60
60
61
62
63
64
65
66
68
69
70
70
71
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
75
75
76
76
77
77
78
79
82
83
85
87
5 Il programma su Palm
5.1 Introduzione ai dispositivi palmari . . . . . . . .
5.2 Requisiti del programma su PalmTM . . . . . .
5.3 Tecniche di ingegneria del software . . . . . . .
5.4 Progetto del programma su Palm . . . . . . . .
5.4.1 Analisi dei requisiti . . . . . . . . . . . .
5.4.2 Progetto del software, i diagrammi UML
5.4.3 Diagramma delle classi di ArcheoMap . .
5.4.4 Codifica . . . . . . . . . . . . . . . . . .
5.5 Panoramica sul software finito . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
93
93
95
95
98
98
100
103
115
119
2
6 Il GPS
6.1 Introduzione al GPS . . . . . . . . . . .
6.2 Standard NMEA . . . . . . . . . . . . .
6.3 Implementazione . . . . . . . . . . . . .
6.3.1 Interfacciamento Palmare / GPS
6.3.2 Parsing delle frasi NMEA . . . .
6.4 Il form di modifica e inserimento reperti
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 La sincronizzazione tra palmare e Database
7.1 Introduzione alla sincronizzazione dei palmari . . . .
7.2 Requisiti per la sincronizzazione . . . . . . . . . . . .
7.3 Inizializzazione del palmare . . . . . . . . . . . . . .
7.3.1 PDB, il formato file di PalmOS . . . . . . . .
7.3.2 Classi Perl per la creazione dei PDB . . . . .
7.3.3 Processo di inizializzazione . . . . . . . . . . .
7.4 HotSync, Coldsync e Conduit . . . . . . . . . . . . .
7.5 La Conduit di sincronizzazione dei dati di ArcheoMap
7.6 Trattamento dei conflitti di sincronizzazione . . . . .
8 Conclusione
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
126
126
128
130
130
132
133
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
137
. 137
. 138
. 139
. 139
. 140
. 142
. 143
. 145
. 146
149
9 Appendice
151
9.1 Codice per creazione del database . . . . . . . . . . . . . . . . . . . . 151
9.2 Codice del mapfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Bibliografia
167
Webografia
168
3
Elenco delle figure
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
Esempio di Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Formalismi grafici per i costrutti del modello E-R . . . . . . . . . . . 13
Schema grafico dell’entità località . . . . . . . . . . . . . . . . . . . 15
Schema grafico dell’entità scavo . . . . . . . . . . . . . . . . . . . . . 15
Schema grafico dell’entità progetto . . . . . . . . . . . . . . . . . . . 17
Schema grafico delle entità diario, galleria e insieme reperti . . 17
Schema grafico dell’entità articolo . . . . . . . . . . . . . . . . . . . 19
Schema grafico dell’entità immagine . . . . . . . . . . . . . . . . . . . 19
Schema grafico dell’entità reperto . . . . . . . . . . . . . . . . . . . 20
Fac-simile della scheda ministeriale, fronte . . . . . . . . . . . . . . . 21
Fac-simile della scheda ministeriale, retro . . . . . . . . . . . . . . . . 22
Schema grafico dell’entità utente . . . . . . . . . . . . . . . . . . . . 23
Schema grafico dell’entità permesso . . . . . . . . . . . . . . . . . . . 24
Schema grafico delle entità capo progetto e direttore scavo . . . 24
Schema grafico della relazione “composizione” . . . . . . . . . . . . 25
Schema grafico delle tre relazioni “sezione diario” “sezione galleria”
e “sezione reperti” . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Schema grafico delle relazioni “elenco articoli” e “scrittura” . . 26
Schema grafico delle due relazioni “elenco immagini” e “foto” . . . 27
Schema grafico delle relazioni che coinvolgono l’entità “reperto” . . . 28
Schema grafico delle relazioni che coinvolgono gli utenti . . . . . . . . 29
Schema grafico della relazione “esportazione” . . . . . . . . . . . . 29
Schema E-R concettuale completo per il database di ArcheoMap . . . 30
Schema grafico dell’entità “località” dopo l’accorpamento degli attributi dell’entità “scavo” . . . . . . . . . . . . . . . . . . . . . . . . 33
Schema E-R concettuale ridotto per il database di ArcheoMap . . . . 35
Schema di funzionamento di un indice per una tabella . . . . . . . . . 42
3.1 Diagramma temporale di una Web Application . . . . . . . . . .
3.2 Il modello usato per la costruzione del sito di ArcheoMap . . . .
3.3 Diagramma della classe di template “tpl” . . . . . . . . . . . .
3.4 Esempio di diagramma delle classi per il sito Web di ArcheoMap
4
.
.
.
.
.
.
.
.
.
.
.
.
48
51
52
53
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
Schermata
Schermata
Schermata
Schermata
Schermata
Schermata
Schermata
Schermata
Schermata
Schermata
Schermata
Schermata
della
della
della
della
della
della
della
della
della
della
della
della
pagina
pagina
pagina
pagina
pagina
pagina
pagina
pagina
pagina
pagina
pagina
pagina
di login . . . . . . . . . . . . . . . . . . . . .
con l’elenco dei progetti . . . . . . . . . . . .
con i dettagli di una località . . . . . . . . . .
per la creazione di una nuova località . . . . .
del diario di scavo . . . . . . . . . . . . . . .
per l’inserimento di un nuovo articolo di diario
con la galleria fotografica . . . . . . . . . . .
con i dettagli dell’immagine . . . . . . . . . .
con l’elenco dei reperti . . . . . . . . . . . . .
con i dettagli di un reperto . . . . . . . . . .
di gestione degli utenti . . . . . . . . . . . . .
con i dettagli sui permessi utente . . . . . . .
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Schema di funzionamento di MapServer . . . . . . . . . . . . .
Schema gerarchico degli oggetti definiti in MapServer . . . . .
Schema grafico di alcune classi di PHP/MapScript . . . . . . .
Schema di funzionamento di PHP/MapScript . . . . . . . . .
Schermata iniziale della mappa disegnata da MapServer . . . .
Schermata della mappa in seguito ad uno zoom . . . . . . . .
Schermata della mappa in seguito ad un ricentramento . . . .
Schermata della mappa con i rilievi montuosi . . . . . . . . . .
Schermata della mappa in seguito ad una richiesta di calcolo
distanza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.10 Schermata della mappa di Google Maps . . . . . . . . . . . . .
4.11 Schermata con dettaglio di Google Maps ingrandita . . . . . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
della
. . .
. . .
. . .
. 90
. 91
. 92
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Immagine di un dipositivo Palm . . . . . . . . . . . . . . . . .
Ciclo di vita del software secondo il modello a cascata . . . . .
Schema grafico di una classe in un diagramma UML . . . . . .
Schema grafico delle relazioni in un Class Diagram . . . . . .
Esempio di Sequence Diagram per l’interzione tra due oggetti .
Diagramma di flusso di un evento . . . . . . . . . . . . . . . .
Schema grafico della classe “GenericForm” . . . . . . . . . . .
Diagramma delle classi degli oggetti dell’interfaccia grafica . .
Diagramma delle classi per “ProjectsForm” . . . . . . . . . .
Diagramma delle classi per “LocationsForm” . . . . . . . . .
Diagramma delle classi per “ArticlesForm” . . . . . . . . . .
Diagramma delle classi per “ImagesForm” . . . . . . . . . . .
Diagramma delle classi per “FindsForm” . . . . . . . . . . . .
Diagramma delle classi per “ArticleEditForm” . . . . . . . .
Diagramma delle classi per “ImageEditForm” . . . . . . . . .
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
62
63
65
66
67
68
69
71
72
73
74
79
81
84
84
86
87
88
89
94
96
101
102
103
104
105
106
107
108
108
109
109
110
110
5.16
5.17
5.18
5.19
5.20
5.21
5.22
5.23
5.24
5.25
5.26
5.27
5.28
5.29
5.30
5.31
5.32
5.33
Schema grafico della classe “Project” . . . . . . . . .
Schema grafico della classe “Location” . . . . . . . . .
Schema grafico della classe “Article” . . . . . . . . .
Schema grafico della classe “Image” . . . . . . . . . . .
Schema grafico della classe “Find” . . . . . . . . . . .
Schema grafico della classe “MinistrySheet” . . . . .
Diagramma temporale del form “ProjectsForm” . . .
Schema grafico della classe “Permission” . . . . . . .
Schermata con l’elenco dei progetti . . . . . . . . . . .
Schermata delle preferenze . . . . . . . . . . . . . . . .
Schermata con l’elenco delle località . . . . . . . . . . .
Schermata con i dettagli di una località . . . . . . . . .
Schermata con l’elenco degli articoli di diario . . . . . .
Schermata per la modifica / creazione di un articolo . .
Schermata con l’elenco dei reperti e relativi riferimenti
Schermata con l’elenco delle immagini della galleria . .
Schermata per la creazione o modifica di un’immagine .
Schermata di gestione della fotocamera integrata . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
111
112
112
113
113
114
114
115
119
120
120
121
122
122
123
124
124
125
6.1
6.2
6.3
6.4
6.5
6.6
6.7
Uno dei satelliti della rete GPS . . . . . . . . . . . . . .
Rilevamento della posizione dall’incrocio di tre sfere . . .
Schema grafico delle classi di interfacciamento al GPS . .
Diagramma a stati di un parser NMEA . . . . . . . . . .
Schermata del form di modifica reperti . . . . . . . . . .
Schermata del form di scelta degli articoli . . . . . . . .
Schermata del form di creazione della scheda ministeriale
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
126
128
131
132
134
135
136
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
140
141
144
147
7.1 Schema descrittivo della PDB . . . . . . . . . . .
7.2 Classe generica per la creazione dei PDB . . . . .
7.3 Schermata di apertura di HotSync . . . . . . . . .
7.4 Algoritmo per la rilevazione di conflitti sui record
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Prefazione
ArcheoMap è il nome del progetto di mappatura di siti archeologici descritto in
questo volume, il cui scopo è quello di fornire un’architettura software integrata e
unitaria per la raccolta e georeferenziazione dei reperti portati alla luce nel corso
delle numerose campagne di scavo condotte sul suolo italiano, eccezionalmente fertile
sotto questo punto di vista.
ArcheoMap nasce come punto d’incontro ideale tra la cultura storica e la tecnologia informatica, il cui continuo evolversi mette a disposizione nuovi strumenti per
un’efficiente catalogazione e divulgazione delle scoperte archeologiche. Lo sviluppo
del progetto è stato promosso da I.I.C.E. (Istituto Italiano per la Civiltà Egizia), associazione culturale che raccoglie i principali studiosi di archeologia dalle università
italiane, e da due aziende torinesi che operano nel settore dell’Information Tecnology: la Tower Technologies S.r.l. e la Risolviamo S.r.l. che hanno supervisionato
tutta la fase di progettazione e implementazione.
Visto l’entusiasmo con cui è stata accolta la proposta di realizzazione del progetto
ArcheoMap da parte dei membri di I.I.C.E., si è previsto di realizzare una versione
dimostrativa tesa a metterne in luce le potenzialità e gli eventuali limiti. Per la
progettazione e implementazione si è indetta una tesi di laurea sperimentale presso
il prestigioso ateneo del Politecnico di Torino che ha immediatamente raccolto i
favori sia degli studenti sia del corpo docente nella persona del Prof. Angelo Raffaele
Meo, nella sua funzione di Relatore interno, in collaborazione con l’Università La
Sapienza di Roma nella persona del Prof. Alessandro Roccati, sotto il patrocinio di
Risolviamo S.r.l. e Tower Technologies S.r.l. in qualità di committenti.
La tesi è stata svolta da due studenti iscritti al corso di laurea di Ingegneria
Informatica: Davide Boltri e Matteo Onofrio Bovero che hanno cosı̀ potuto mettere
a frutto le esperienze e le conoscenze accumulate durante il loro corso di studi.
L’intero lavoro di progettazione e codifica è stato equamente suddiviso fra i due
laureandi.
In particolare, Davide Boltri si è occupato della creazione del sito Web di ArcheoMap, della progettazione e creazione di un programma per palmari Palm e
dell’interazione di quest’ultimo con il sistema di posizionamento satellitare GPS.
Matteo Onofrio Bovero si è occupato, parallelamente, del progetto del database
1
di ArcheoMap, della gestione delle mappe e del programma per la sincronizzazione
dei dati da un device Palm con il database.
I due studenti hanno lavorato congiuntamente alla risoluzione delle problematiche di volta in volta emerse durante il processo di progettazione e sviluppo, e si
sono accordati sulla corretta integrazione delle parti. Per la definizione dei requisiti
si sono rivolti ai membri di I.I.C.E., in quanto futuri utenti di ArcheoMap, e alle
aziende Risolviamo S.r.l. e Tower Technologies S.r.l. per la valutazione delle scelte
progettuali adottate.
2
Capitolo 1
Introduzione
1.1
L’archeologia che si evolve
4 Novembre 1922, Valle dei Re, Tebe, in Egitto: l’inglese Howard Carter1 scopre la
tomba di Tutankhamon, con il suo corredo funerario in gran parte intatto, e mette di
fronte agli occhi del mondo i tesori dei Faraoni. Si tratta di un risultato straordinario,
frutto di anni di lavoro e di ricerche compiute in un sito archeologico considerato
dai più esaurito, affidandosi unicamente alla propria esperienza, all’osservazione e
all’intuito.
Oggi, oltre 80 anni dopo, si scava ancora nella Valle dei Re e proprio nel corso del
2006 si annunciano nuove scoperte, forse non spettacolari come quella di Carter, ma
sicuramente altrettanto preziose dal punto di vista archeologico per la ricostruzione
storica. Ancora una volta sono fondamentali l’esperienza e l’acume degli studiosi,
ma nel frattempo il progresso tecnologico, ed in particolare l’informatica applicata,
hanno messo a disposizione di questi ultimi dei validi strumenti di ausilio nella
ricerca e nella conduzione della campagna di scavo. Ad esempio, l’equipe guidata
da Nicholas Reeves2 fa uso della tecnologia radar per sondare il terreno e ne analizza
le anomalie del segnale di eco per identificare le zone da sottoporre a indagine.
L’archeologia dunque, ben lungi dall’aderire allo stereotipo dell’Indiana Jones,
si presenta oggi come una scienza in evoluzione che sfrutta appieno le possibilità
offerte da apparecchiature elettroniche ed informatiche per procedere ad affinare le
ricerche sul passato e la ricostruzione storica.
La tecnologia informatica può fornire un concreto aiuto agli archeologi in diversi
1
Howard Carter (1873 - 1939), archeologo inglese. Giunto in Egitto come disegnatore, iniziò
ad interessarsi all’archeologia. La sua fortuna iniziò con l’incontro di Lord Carnarvon, un nobile
inglese appassionato di egittologia, che lo sovvenzionò economicamente per 7 anni. La tomba del
faraone Tutanchamon nel 1922 è la sua principale scoperta.
2
Nicholas Reeves, egittologo inglese e autore di vari libri sull’Antico Egitto, è attualmente
direttore dell’Amarna Royal Tomb Project, un progetto responsabile degli scavi nella Valle dei Re
3
1 – Introduzione
campi, uno dei quali, oggetto di questa tesi, è la catalogazione e mappatura dei
reperti. Scopo dell’archeologia è in prima istanza la ricostruzione del passato sulla
base delle informazioni tramandateci dai reperti che affiorano dalla terra o che giacciono sommersi in fondo al mare. Per raggiungere questo obiettivo non è sufficiente
una mera raccolta di oggetti, ma è necessaria soprattutto una loro efficiente catalogazione che permetta di scoprire le relazioni esistenti tra un oggetto e il luogo in cui
è stato rinvenuto, l’epoca a cui risale e come si lega ad altri oggetti scoperti nello
stesso luogo o altrove.
Muovendosi da queste considerazioni nasce il progetto ArcheoMap, la cui progettazione e prototipazione saranno descritti nel corso di questo volume.
1.2
Il progetto ArcheoMap
Il progetto ArcheoMap nasce con il proposito di creare un’infrastruttura informatica
che consenta di supportare attivamente le campagne di scavo effettuate da Università
e centri di ricerca in Italia e nel mondo.
L’obiettivo è quello di creare strumenti che consentano la mappatura approfondita di un sito archeologico e la completa catalogazione di quanto rinvenuto, nella
speranza che dal confronto e dall’analisi di queste informazioni gli studiosi di archeologia possano migliorare la nostra comprensione del passato. Tali strumenti
sono frutto dell’integrazione di tecnologie di georeferenziazione e condivisione dei
contenuti diffuse e collaudate, cosı̀ da permettere, anche ai non tecnici, di divenire
subito operativi.
Il progetto ArcheoMap può essere visto come l’integrazione di cinque componenti
base:
• Database: è il cuore di ArcheoMap, dove vengono raccolti e gestiti i dati
inerenti reperti e siti archeologici;
• Web: è il luogo di presentazione e condivisione dei contenuti raccolti durante
le campagne di scavo;
• Gestore delle mappe: permette la visualizzazione grafica e il trattamento
dei dati geografici;
• Computer palmare: è lo strumento che accompagna gli archeologi durante
gli scavi e consente la raccolta di informazioni sul campo;
• GPS: per la raccolta dei dati geografici inerenti la posizione dei reperti;
Operativamente, lo scenario tipo per il quale è stato sviluppato il progetto ArcheoMap è questo: gli archeologi, dotati del proprio computer palmare e di un GPS
4
1 – Introduzione
ad esso collegato, potranno muoversi lungo il sito dello scavo e annotare tramite il
software presente sul loro PDA3 i dati relativi ad ogni reperto. Sullo schermo del
palmare compariranno vari form 4 da cui sarà possibile redarre annotazioni per il
diario di scavo, scrivere dati per le schede di catalogazione, scattare fotografie (se
il palmare è dotato di macchina fotografica integrata) e acquisire i dati di posizione tramite il ricevitore GPS. Al termine della giornata i dati raccolti da tutti gli
archeologi sui propri dispositivi portatili potranno quindi essere sincronizzati su un
database ospitato in un server e resi disponibili via web a tutti gli utenti o solo ad
una parte di essi in base alla politica di riservatezza dei dati che si vuole adottare.
1.3
ArcheoMap e l’open source
Considerata la complessità e la varietà degli strumenti di cui si compone il progetto
ArcheoMap, è stato inevitabile per autori ed ideatori rivolgere la propria attenzione
al mondo Open Source.
Con tale termine si indica un movimento ideologico, prima ancora che un orientamento tecnico, la cui filosofia di fondo è quella di rendere pubblico il codice sorgente
del software prodotto per consentire ad eventuali altri sviluppatori di osservarne da
vicino il funzionamento a scopo didattico o semplicemente per apportare modifiche
a quanto già scritto.
Il grande vantaggio dei prodotti Open Source è quello di poter disporre di strumenti di buona se non ottima qualità, perché frutto della libera collaborazione di
una numerosa schiera di sviluppatori, e di cui esistono ampia documentazione e una
serie di case studies da analizzare.
Più in particolare, gli aspetti del mondo Open Source che principalmente interessano il progetto ArcheoMap sono riassumibili nei seguenti punti:
• Disponibilità di formati aperti: nell’ottica di costruire un progetto duraturo, è
indispensabile orientarsi verso formati file di cui siano note le specifiche e ben
documentati, cosı̀ da permetterne l’utilizzo anche in futuro quando il software
attuale diventerà obsoleto;
• Possibilità di manipolare il codice sorgente degli strumenti utilizzati, in modo da garantirne l’adattabilità a condizioni particolari o l’implementazione di
nuove caratteristiche, qualora se ne presenti la necessità;
• Abbattimento dei costi: quasi tutti gli strumenti utilizzati sia nel corso dello
sviluppo sia nella messa in opera del progetto (ad esempio il server web Apache
3
PDA (Personal Digital Assistent) è sinonimo di computer palmare, un piccolo dispositivo
elettronico delle dimensioni di una mano, che consente la raccolta ed elaborazione di dati
4
Quando riferito ai palmari, il termine form indica la videata di un’applicazione in cui si possono
scrivere o leggere dati
5
1 – Introduzione
e il sistema operativo Linux che formano la piattaforma su cui dovrà funzionare
ArcheoMap) sono gratuiti, cosı̀ da permettere un buon abbattimento dei costi
rispetto all’utilizzo di soluzioni proprietarie.
Nel corso del presente documento verranno meglio descritti i singoli strumenti
utilizzati man mano che se ne presenterà l’occasione.
1.4
Organizzazione del volume
Il volume è organizzato in nove capitoli, di cui il primo è questa breve introduzione.
Nel secondo capitolo si introducono alcune nozioni generali sui database e sui
formalismi grafici adottati per la loro progettazione; si illustrano i requisiti a cui
deve soddisfare il database di ArcheoMap e se ne vede l’applicazione pratica.
Nel terzo capitolo, dopo aver passato in rassegna le tecnologie e le norme di
buona progettazione che sono alla base dello sviluppo di un sito Web dinamico, si
descrive il progetto del sito Web di ArcheoMap il cui scopo è la divulgazione delle
informazioni sugli scavi archeologici e l’amministrazione degli utenti che collaborano
alle singole campagne di scavo.
Nel quarto capitolo vengono spiegate le principali problematiche relative alla
rappresentazione delle mappe digitali e ne viene descritta la loro gestione ad opera
del software MapServer; al termine del capitolo viene vista l’integrazione del sito
con il servizio GoogleMaps di Google.
Nel quinto capitolo si introducono le tecniche di Ingegneria del Software e se
ne vede l’applicazione pratica alla progettazione del software di ArcheoMap sui
dispositivi Palm.
Nel sesto capitolo si parla del sistema di posizionamento satellitare GPS e dei
modelli software adottati per supportare la comunicazione seriale tra il ricevitore e
il dispositivo palmare.
Nel settimo capitolo si descrivono le principali problematiche legate alla sincronizzazione dei dati tra i dispositivi palmari utilizzati dagli archeologi nel corso delle
campagne di scavo e il database.
L’ottavo capitolo conclude la trattazione.
Infine, come nono capitolo, è stata aggiunta un’appendice in cui sono riportati
frammenti del codice sorgente scritto durante la fase di sviluppo del progetto.
6
Capitolo 2
Il Database di ArcheoMap
2.1
Nozioni generali sui Database
Il termine Database indica un insieme di dati riguardanti uno stesso argomento o
più argomenti correlati tra di loro, strutturati in modo tale da consentire l’uso dei
dati stessi (e il loro aggiornamento) da parte di applicazioni software che prendono
il nome di DBMS (DataBase Management System).
A partire dagli anni ’60, quando hanno cominciato ad affermarsi i primi sistemi
di gestione delle basi dati, si sono affacciate sul mercato diverse soluzioni relative
al tipo di struttura in cui organizzare le informazioni, ma attualmente, per ragioni di semplicità ed efficienza, la soluzione più diffusa prende il nome di “modello
relazionale”.
Nel modello relazionale i dati sono organizzati in tabelle, collegate tra di loro da
relazioni. Le tabelle sono le strutture nelle quali sono ospitati i dati di uno stesso
tipo e sono formate da un numero di colonne (o campi) pari al numero di attributi
che si intende catalogare per un determinato tipo di informazione. Le relazioni sono
i legami logici che si possono instaurare tra i dati contenuti in tabelle diverse.
Per dare maggiore concretezza alla definizione di modello relazionale or ora presentata, si espone un breve esempio di database per corsi universitari. Tale database
è costituito da tre tabelle:
1. Una tabella in cui disporre i dettagli relativi agli allievi, i cui attributi (quindi
le colonne) sono il numero di matricola, il nome, il cognome e la data di nascita;
2. Una tabella in cui catalogare i corsi, i cui campi sono il codice del corso, il
nome del corso e il docente;
3. Una tabella in cui memorizzare gli esiti degli esami composta da tre campi:
uno per la matricola dello studente che ha sostenuto l’esame, un altro per il
7
2 – Il Database di ArcheoMap
codice del corso a cui si riferisce l’esame ed infine l’ultimo per la votazione
ottenuta.
La figura 2.1 visualizza il possibile contenuto di queste tabelle.
TABELLA STUDENTI
Matricola
Nome
Cognome
276545
Maria
Rossi
Data di
nascita
25/11/1971
485755
Anna
Neri
23/04/1972
200768
Fabio
Verdi
12/02/1972
TABELLA CORSI
TABELLA ESAMI
Studente
Voto
Corso
Codice
Titolo
Docente
276545
28
01ANA
01ANA
Analisi
Giani
276545
27
03CHI
02FIS
Fisica
Melli
200768
25
02FIS
03CHI
Chimica
Belli
Figura 2.1.
Esempio di Database
Alcune colonne sono ripetute in tabelle diverse e permettono di creare dei collegamenti logici tra il contenuto di queste : il campo Matricola mette in relazione
la “tabella studenti” e la “tabella esami” (con esso è possibile sapere quali studenti
hanno sostenuto un certo esame); il campo Codice della tabella dei corsi mette in
relazione la “tabella corsi” con la “tabella esami” (si può cosı̀ sapere gli esami che
riguardano un certo corso).
Se la matricola e il codice del corso sono univoci, ovvero se ad ogni studente
corrisponde una e una sola matricola e ad ogni corso corrisponde uno e un solo
codice, allora è possibile instaurare delle relazioni che consentano di interrogare il
database e scoprire senza ambiguità quali esami sono stati sostenuti da un determinato studente oppure quali studenti hanno superato l’esame di un determinato
corso. Proprio perché i campi univoci permettono di effettuare ricerche nelle tabelle
senza ambiguità, vengono chiamati “chiavi” nella terminologia tecnica dei database.
Di norma ogni tabella deve avere una chiave e se non è possibile trovare un campo
univoco tra quelli presenti nei suoi attributi, se ne aggiunge uno fittizio che risponda
a tale requisito.
Scoprire quali sono le informazioni essenziali da memorizzare in un database,
quali sono i tipi di dato elementari e da quali attributi sono composti, in altri
8
2 – Il Database di ArcheoMap
termini, individuare le tabelle di cui è formata la base dati, la loro struttura, le loro
chiavi e le relazioni che si possono formare, è compito del processo di progettazione
dei database. Tale processo si compone di quattro fasi, qui brevemente riassunte:
• Raccolta dei requisiti: si prendono contatti con quelli che saranno i fruitori
del database e si cerca di estrapolarne un documento in cui siano raccolte tutte
le informazioni essenziali allo sviluppo del progetto;
• Progettazione concettuale: a partire dall’analisi dei requisiti si conclude
con la redazione di uno schema concettuale in cui si descrive in modo formale il
progetto ad un elevato livello di astrazione senza preoccuparsi né della modalità
con la quale le informazioni verranno codificate nel sistema reale né della loro
efficienza;
• Progettazione logica: a partire dallo schema concettuale si produce uno
schema logico in cui si definiscono i dati in modo ancora slegato dalla realtà
fisica (quindi dal prodotto finale) ma concreto perché disponibile nei sistemi
di gestione delle basi dati;
• Progettazione fisica: è la parte finale, in cui lo schema logico viene completato con la specifica dei parametri fisici di memorizzazione dei dati propri del
DBMS che si intende utilizzare. Il prodotto di questa fase è il database finito,
pronto all’uso.
Nel seguito di questo capitolo si analizzeranno le singole fasi del progetto vedendo
in dettaglio in cosa queste consistono e mostrandone l’applicazione al database del
progetto ArcheoMap.
2.2
I requisiti del Database
La raccolta dei requisiti è la prima fase del processo di progettazione del database. È
estremamente importante riuscire a chiarire bene i dati e le relazioni che si intende
trattare, in modo da mettere in luce quali sono le caratteristiche a cui l’utente è
interessato e costruire una solida base di partenza per la definizione del progetto.
Il documento dei requisiti, che si può stilare al termine di questa fase, è descritto
in linguaggio naturale, in modo da risultare comprensibile anche ad un pubblico
non tecnico, ma nel contempo deve essere abbastanza rigoroso da non presentare
ambiguità e facilitare il successivo lavoro di analisi.
Dai dialoghi avuti presso il committente del progetto e dalle opinioni dei futuri
utilizzatori di ArcheoMap, si è giunti alla definizione dei seguenti punti:
9
2 – Il Database di ArcheoMap
1. Il database deve tener conto delle informazioni relative a località geografiche
interessate da studi archeologici. Ogni località è contraddistinta dal nome
geografico attuale, dal nome del luogo nell’antichità (se disponibile), dal nome
della nazione, città e comune in cui è collocato, dal proprio indirizzo e dalle
coordinate geografiche. L’accesso ai dati ospitati nell’ambito di una località
può essere pubblico o privato;
2. Ogni località è corredata da un testo descrittivo ed eventualmente note di vario
genere;
3. Ogni località può avere delle referenze per i contatti esterni: numero di telefono, indirizzo e-mail, indirizzo di un sito internet ed eventuali indicazioni
stradali su come raggiungerlo;
4. Ogni località può essere correntemente teatro di scavi archeologici, ed in tal
caso deve essere indicata la data di inizio ed eventuale data di fine dei lavori,
e può essere ad accesso pubblico o ad accesso privato;
5. Le località sono organizzate in progetti: ogni progetto può contenere più località, ma ognuna di esse è legata ad un unico progetto. I progetti sono caratterizzati da un nome, una descrizione, un indirizzo internet di riferimento,
un indirizzo e-mail, un numero di telefono, una data di apertura e una data di
chiusura;
6. Ogni località è dotata di tre sezioni: un diario di scavo, una galleria fotografica
e un insieme di reperti. La relazione tra diario di scavo, galleria fotografica e
reperti è univoca nei confronti della località a cui appartengono;
7. Il diario di scavo è l’insieme degli articoli scritti dai partecipanti ad una campagna archeologica per annotare tutto ciò che viene considerato rilevante ai
fini della ricerca. Le informazioni di interesse per ogni articolo sono: il titolo,
il testo del messaggio, la data in cui è stato scritto, l’autore, la data in cui è
stato modificato l’ultima volta e l’autore dell’ultima modifica;
8. Poiché spesso l’articolo non viene scritto di getto, ma può necessitare di rielaborazioni e modifiche prima di renderne pubblico il contenuto, deve essere
possibile decidere se il testo corrente sia visibile agli altri oppure no;
9. La galleria fotografica è l’insieme delle immagini inserite nel contesto della
località. Di ogni immagine si vuole conoscere il nome del file, la data di inserimento, la data di ultima modifica, eventuali note, l’utente che l’ha inserita e
l’utente che l’ha modificata;
10
2 – Il Database di ArcheoMap
10. Ogni reperto è definito da un nome, da una data di inserimento, da una data di
ultima modifica, dall’autore che l’ha inserito, dall’autore che l’ha modificato,
dalle coordinate geografiche in cui è stato scoperto e dall’insieme di articoli
del diario di scavo e immagini della galleria fotografica inerenti il reperto;
11. Ogni reperto va documentato con uno o più moduli ufficiali chiamati “schede
ministeriali”. Si vuole dare la possibilità di inserire la scheda ministeriale nel
database con i suoi singoli campi;
12. L’accesso ad ogni componente di ArcheoMap può essere ristretto a singoli utenti, distinti da un nome, un cognome, uno username, una password, un’indirizzo
e-mail e la lingua parlata;
13. Ogni utente deve avere a disposizione un insieme di permessi che gli consentano di accedere in modo limitato alle località e ai progetti, ma devono essere
presenti anche almeno due tipi di utenti privilegiati: i capi progetto, che si
occupano della gestione di uno o più progetti, e i direttori di scavo, che si
occupano della direzione di singole località. Il sistema deve comunque essere abbastanza flessibile da consentire l’introduzione di nuovi permessi e livelli
utente nel futuro, qualora lo si ritenesse necessario;
14. Poichè ogni utente ha a sua disposizione un palmare, occorre tenere traccia dei
progetti e delle località che ognuno desidera copiare sul proprio dispositivo.
2.3
Progetto concettuale
La fase di progettazione concettuale consiste nell’analisi dei requisiti e nella definizione di uno schema che sia in grado di descrivere al meglio le specifiche sui dati
di un’applicazione, mettendone in rilievo i concetti fondamentali e come questi si
legano tra di loro. Il tipo di schema che si intende generare segue un formalismo
rigoroso che viene ormai accettato come standard nello sviluppo delle basi dati. Si
tratta del “modello entità-relazioni”.
2.3.1
Modello entità-relazioni
Il modello entità-relazioni, spesso abbreviato come “modello E-R”, è un modello
concettuale di dati e, come tale, fornisce una serie di costrutti atti a descrivere la
realtà di interesse in una maniera facile da comprendere e che prescinde dai criteri
di organizzazione dei dati nei calcolatori. Questi costrutti vengono utilizzati per
definire degli schemi grafici che descrivono l’organizzazione e la struttura dei dati.
Nel seguito si analizzano le principali componenti di un modello E-R: entità, relazioni
e loro cardinalità, attributi, identificatori e generalizzazioni.
11
2 – Il Database di ArcheoMap
Le entità nel modello E-R rappresentano classi di oggetti (fatti, cose, persone,
per esempio) che hanno proprietà comuni ed esistenza autonoma ai fini dell’applicazione di interesse.
Le relazioni descrivono legami logici significativi tra due o più entità. Il numero
di entità legate prende il nome di grado della relazione. Solitamente si cerca, per
quanto possibile, di inserire relazioni di grado due.
Ad ogni relazione è assegnata una cardinalità, che specifica per ciascuna entità
che partecipa alla relazione quante volte l’occorrenza di una di queste entità può essere legata ad occorrenze delle altre. La cardinalità viene indicata con una coppia di
numeri (a,b), in cui il primo valore è la cardinalità minima, il secondo è la cardinalità
massima. La cardinalità minima è il numero minimo di partecipazione relativa e
può essere zero o uno: se zero la partecipazione è opzionale; se uno la partecipazione
è obbligatoria. La cardinalità massima è il numero massimo di partecipazione
relativa e può essere uno o molti (abbreviato in N ): se uno, vuol dire che a ogni
occorrenza di una entità corrisponde al massimo una occorrenza dell’altra; se N ,
vuol dire che ad ogni partecipazione di una entità corrisponde un numero arbitrario
di occorrenze dell’altra entità.
Gli attributi descrivono le proprietà elementari di entità o relazioni che si vogliono memorizzare nel database. La scelta degli attributi riflette il livello di dettaglio
con il quale si vogliono rappresentare le informazioni. Ad ogni attributo è associato
l’insieme di valori che questo può assumere: ad esempio vi possono essere attributi
solo numerici, oppure sotto forma di stringhe di testo a lunghezza fissa o variabile,
etc.
Tra gli attributi è necessario individuare gli identificatori, ovvero quell’insieme
minimale di attributi che consentono di identificare in modo univoco il singolo oggetto memorizzato nel database. Se non è possibile individuare un identificatore tra
gli attributi presenti, è prassi comune aggiungere un ulteriore attributo, ad esempio
un codice precostituito, che funga da identificatore.
Nel costrutto di generalizzazione si distinguono due tipi di entità: una entità
padre e una o più entità figlie relazionate in modo particolarmente stretto perché le
entità figlie sono da considerarsi delle specializzazioni o casi particolari dell’entità
padre. Ad esempio, l’entità “persona” è una generalizzazione delle entità “uomo” e
dell’entità “donna”. Ogni occorrenza delle entità figlie è anche occorrenza dell’entità
padre, e condividono gli stessi attributi.
Ad ogni costrutto del modello E-R corrisponde un formalismo grafico, come si
può vedere nella figura 2.2. Il grafico (a) rappresenta un’entità con i suoi attributi:
l’entità è raffigurata da un rettangolo con all’interno il nome che gli si vuole assegnare; i suoi attributi sono simboleggiati da dei pallini vuoti e l’identificatore da un
pallino nero. Si noti come nella rappresentazione grafica degli attributi non venga indicato l’insieme dei valori di appartenenza, perché questa informazione viene
demandata alla documentazione di corredo allo schema.
12
2 – Il Database di ArcheoMap
attr1
(a)
(0,1)
A
(1,1)
B
Rel
Entity
Id
(1,1)
A
attr3
(0,N)
B
Rel
attr2
(1,N)
Padre
Figlio
A
Rel
B
(c)
(b)
Figura 2.2.
(0,N)
Formalismi grafici per i costrutti del modello E-R
Il grafico (b) illustra un esempio di generalizzazione: l’entità Figlio è un caso
particolare dell’entità Padre, e tale legame viene delineato da una freccia che punta
verso l’entità più generica.
Le relazioni (grafico (c)) sono rappresentate come dei rombi, con all’interno il
nome che si intende assegnare loro, e da segmenti che uniscono le entità che la
relazione lega. Accanto alle entità viene riportata la cardinalità delle relazioni.
Sulla base della cardinalità si distinguono tre tipi di relazione:
• Relazioni uno a uno (grafico (c), primo schema): un’istanza dell’entità A
può legarsi al più con una istanza dell’entità B, mentre un’istanza dell’entità
B si lega ad una e una sola istanza dell’entità A;
• Relazioni uno a molti (grafico (c), secondo schema): un’istanza dell’entità
A si lega ad una e una sola istanza dell’entità B, mentre un’istanza dell’entità
B può legarsi con un numero imprecisato di istanze dell’entità A;
• Relazioni molti a molti (grafico (c), terzo schema): un’istanza dell’entità
A si lega a più istanze dell’entità B, e analogamente un’istanza dell’entità B
si lega a più istanze dell’entità A.
2.3.2
Stesura del modello E-R di ArcheoMap
Per tracciare il modello E-R del database che si intende progettare è necessario
analizzare i requisiti esposti nella sezione 2.2 allo scopo di individuare quali siano le
13
2 – Il Database di ArcheoMap
entità di interesse. A tale risultato si perviene leggendo accuratamente il testo dei
requisiti e annotando, tra i sostantivi e gli aggettivi presenti, i termini più rilevanti,
quali identificano delle classi di oggetti con esistenza autonoma e quali invece sono
attributi.
Entità del progetto
Leggendo i primi 3 punti dei requisiti, il sostantivo principale, quello che viene
più naturale associare ad un’entità, è sicuramente la parola “località” mentre
i vocaboli “nome”, “nazione”, “città”, “comune”, “indirizzo”, “coordinate”,
”descrizione”, “note”, “numero di telefono”, “indirizzo e-mail”, “indirizzo internet” e “indicazioni stradali” sono degli attributi che servono a
meglio specificare le proprietà di ogni singola istanza della classe “località”. Una
località, inoltre, può essere ad accesso pubblico o privato, e per tenerne traccia si aggiunge un ulteriore attributo “pubblico” di tipo booleano1 che indica lo stato della
località. Rimane da scegliere una chiave, ossia un attributo univoco. Dal momento
che nessuno degli attributi elencati rispetta tale proprietà, si decide di aggiungere
un campo “idLocalità” che serva allo scopo. Per brevità si anticipa che in tutte le successive entità si è optato di aggiungere un attributo chiamato “id[nome
entità]” nella forma di un codice numerico progressivo da utilizzare come identificatore univoco. Nella figura 2.3 è riportato lo schema grafico mentre nella tabella
2.1 è riportata la documentazione, con, per ogni attributo, il tipo di valori che può
assumere e una breve descrizione.
Il quarto punto informa che le località possono essere oggetto di scavo, ed in tal
caso hanno come attributi specifici la data di inizio e la data di fine dei lavori. Il modo
migliore di tradurre questo requisito è quello di introdurre una nuova entità “scavo”
che presenti gli stessi attributi dell’entità “località”, con in più le due proprietà
“data inizio” e “data fine”. Si è di fatto introdotta una generalizzazione, in cui
“località” è l’entità padre e “scavo” è l’entità figlia. Nella figura 2.4 è riportato
lo schema grafico e nella tabella 2.2 è riportata la documentazione degli attributi
che sono da aggiungere a quelli dell’entità “località”.
Nel quinto punto il termine più rilevante, da trattare come entità, è “progetto”,
che ha come attributi “nome”, “descrizione, “indirizzo internet”, “e-mail”,
“telefono”, “data apertura” e “data chiusura”. Nella figura 2.5 è riportato
lo schema grafico per l’entità “progetto”, mentre nella tabella 2.3 è riportata la
documentazione degli attributi.
Il sesto punto definisce le entità “diario”, “galleria” e “insieme reperti”,
ognuna delle quali non presenta attributi, oltre naturalmente ai rispettivi identificatori “idDiario”, “idGalleria” e “idInsiemeReperti”, aggiunti per rispettare il
1
Si dice “booleano” un’informazione che può assumere solo due valori: si/no oppure on/off.
14
2 – Il Database di ArcheoMap
nome_antico
idLocalità
città
nome_nuovo
comune
pubblico
indicazioni
Località
nazione
e−mail
indirizzo
telefono
note
coordinate
descrizione
internet
Figura 2.3.
Schema grafico dell’entità località
data inizio
località
scavo
data fine
idScavo
Figura 2.4.
Schema grafico dell’entità scavo
criterio di univocità delle chiavi. Nella figura 2.6 è rappresentato lo schema grafico
delle tre entità “diario”, “galleria” e “insieme reperti” mentre nella tabella
2.4 ne è data la documentazione.
15
2 – Il Database di ArcheoMap
Nome attributo Valori
Descrizione
id Località
Numero progressivo Codice che identifica in modo univoco la località
nome nuovo
Stringa di caratteri Nome assunto dalla località correntemente
nome antico
Stringa di caratteri Nome assunto dal luogo nell’antichità
nazione
Stringa di caratteri Nazione in cui è ubicata la località
città
Stringa di caratteri Nome della città in cui è situata la
località
comune
Stringa di caratteri Nome del comune in cui è situata la
località
indirizzo
Stringa di caratteri Indirizzo completo a cui è situata la
località
coordinate
Numeri e caratteri
Coordinate geografiche della località
descrizione
Stringa di caratteri Testo descrittivo della località
note
Stringa di caratteri Testo in cui vengono inserite annotazioni sulla località
telefono
Numeri
Numero di telefono di riferimento
per la località
email
Stringa di caratteri Indirizzo e-mail di riferimento per la
località
internet
Stringa di caratteri Indirizzo WWW di riferimento per
la località
indicazioni
Stringa di caratteri Testo in cui vengono fornite indicazioni stradali utili per raggiungere la
località
pubblico
Booleano
Valore che indica se la località è ad
accesso pubblico o privato
Tabella 2.1.
Documentazione per l’entità località
Il settimo e l’ottavo punto hanno come comune denominatore il termine “articolo”, che quindi è il candidato più adatto a diventare un’entità. I suoi attributi sono
“titolo”, “testo”, “data scrittura” e “data modifica”. Il termine “autore”
non viene trattato come attributo perché è un elemento troppo forte per essere
trattato in tal senso. Alla luce di quanto specificato nei punti dodici e tredici dei requisiti, si è ritenuto più appropriato considerare gli autori istanza dell’entità utente.
Si specifica poi che è possibile scegliere, dopo aver scritto un articolo, se pubblicarlo
16
2 – Il Database di ArcheoMap
Nome attributo Valori
Descrizione
id scavo
Numero progressivo Codice che identifica in modo univoco lo scavo
data inizio
Data
Data di inizio dello scavo
data fine
Data
Data di fine dello scavo
Tabella 2.2. Documentazione per l’entità scavo da aggiungere a quella
dell’entità località
descrizione
nome
idProgetto
internet
data chiusura
progetto
e−mail
data apertura
telefono
Figura 2.5.
Schema grafico dell’entità progetto
insieme
diario
reperti
idDiario
idInsiemeReperti
galleria
idGalleria
Figura 2.6.
Schema grafico delle entità diario, galleria e insieme reperti
17
2 – Il Database di ArcheoMap
Nome attributo Valori
Descrizione
idProgetto
Numero progressivo Codice che identifica in modo univoco il progetto
nome
Stringa di caratteri Nome con cui è noto il progetto
descrizione
Stringa di caratteri Testo descrittivo del progetto
internet
Stringa di caratteri Indirizzo internet di riferimento per
il progetto
email
Stringa di caratteri Indirizzo e-mail di riferimento per il
progetto
telefono
Numeri
Numero telefonico di riferimento per
il progetto
data apertura Data
Data in cui viene aperto il progetto
data chiusura Data
Data in cui viene chiuso il progetto
Tabella 2.3.
Documentazione per l’entità progetto
Nome attributo
idDiario
Valori
Descrizione
Numero progressivo Codice che identifica in modo univoco un’istanza dell’entità diario
idGalleria
Numero progressivo Codice che identifica in modo univoco un’istanza dell’entità galleria
idInsiemeReperti Numero progressivo Codice che identifica in modo univoco un’istanza dell’entità insieme
reperti
Tabella 2.4.
Documentazione per le entità diario, galleria e insieme reperti
immediatamente oppure no. Si risolve la richiesta introducendo l’attributo booleano
“visibile”. Impostando per ogni articolo questo attributo booleano l’autore può
scegliere se renderlo visibile oppure no. Nella figura 2.7 è riportato lo schema grafico
dell’entità “articolo” mentre nella tabella 2.5 ne è data la documentazione.
I punti nove e dieci dei requisiti definiscono l’entità “immagine”, con attributi “nome file”, “data inserimento”, “data modifica” e “note”(si veda figura
2.8 per la rappresentazione grafica e la tabella 2.6 per la documentazione), e l’entità “reperto” con attributi “nome”, “data inserimento”, “data modifica” e
“coordinate geografiche” (si veda figura 2.9 per la rappresentazione grafica e la
tabella 2.7 per la documentazione).
Nel punto undici si legge che ogni reperto può essere associato a una o più schede
ministeriali. Poiché si tratta di un documento ufficiale, che gli archeologi devono
18
2 – Il Database di ArcheoMap
testo
titolo
idArticolo
articolo
data modifica
visibile
data scrittura
Figura 2.7.
Schema grafico dell’entità articolo
Nome attributo
idArticolo
Valori
Descrizione
Numero progressivo Codice che identifica in modo univoco un’istanza dell’entità articolo
testo
Stringa di caratteri Testo dell’articolo
titolo
Stringa di caratteri Titolo dell’articolo
data scrittura Data
Data in cui è stato scritto l’articolo
data modifica
Data
Data in cui è stato modificato
l’articolo
Tabella 2.5.
Documentazione dell’entità articolo
note
data inserimento
data modifica
idImmagine
file
immagine
Figura 2.8.
Schema grafico dell’entità immagine
compilare in seguito al rinvenimento di un reperto, elencandone le caratteristiche
rilevanti al momento della scoperta, non si è ritenuto opportuno specificare nei
requisiti le singole parti di cui è composto. Nelle figure 2.10 e 2.11 sono mostrati il
19
2 – Il Database di ArcheoMap
Nome attributo
idImmagine
Valori
Descrizione
Numero progressivo Codice che identifica univocamente
un’istanza dell’entità immagine
note
Stringa di caratteri Note di vario genere relative all’immagine
data inserimento Data
Data in cui è stata inserita l’immagine
data modifica
Data
Data di ultima modifica dell’immagine
file
Stringa di caratteri Percorso del file dell’immagine
Tabella 2.6.
Documentazione dell’entità immagine
nome
data inserimento
data_modifica
idReperto
reperto
coordinate
Figura 2.9.
Schema grafico dell’entità reperto
Nome attributo
idReperto
Valori
Descrizione
Numero progressivo Codice che identifica univocamente
un’istanza dell’entità reperto
nome
Stringa di caratteri Nome assegnato al reperto reperto
data inserimento Data
Data in cui è stato inserito il reperto
data modifica
Data
Data di ultima modifica del reperto
coordinate
Stringa di caratteri Coordinate geografiche a cui è stato
trovato il reperto
Tabella 2.7.
Documentazione dell’entità reperto
fronte e il recto di un fac-simile della scheda ministeriale. Dal momento che si vuole
fornire la possibilità di memorizzare le schede ministeriali nel database, quello che si
fa è di introdurre l’entità “scheda ministeriale” e far corrispondere ogni campo
della scheda a un suo attributo.
Infine nei punti dodici e tredici vengono descritti gli utenti e i permessi associati. Applicando lo stesso procedimento adottato fino ad ora, si definisce l’entità
20
2 – Il Database di ArcheoMap
Figura 2.10.
Fac-simile della scheda ministeriale, fronte
21
2 – Il Database di ArcheoMap
Figura 2.11.
Fac-simile della scheda ministeriale, retro
22
2 – Il Database di ArcheoMap
“utente”, con attributi “nome”, “cognome”, “username”, “password”, “e-mail” e
“lingua ” (si veda figura 2.12 per lo schema grafico e la tabella 2.8 per la documentazione) e l’entità “permesso” con attributo “tipo permesso” (schema grafico
alla figura 2.13 e documentazione alla tabella 2.9). In questo modo si ottiene la
flessibilità richiesta, perché nel caso in cui si vogliano aggiungere nuovi permessi al
sistema sarà sufficiente aggiungere una nuova istanza della classe “permesso”. Per
quanto riguarda gli utenti privilegiati capo progetto e direttore scavo, questi sono a
tutti gli effetti degli utenti particolari, quindi la soluzione più naturale è di definirli
come entità separate, “capo progetto” e “direttore scavo”, specializzazioni dell’entità “utente”. Detto in modo più formale, si introducono tre generalizzazioni,
in cui “utente” è l’entità padre, “capo progetto” e “direttore scavo” sono le
entità figlie (figura 2.14).
nome
cognome
email
idUtente
username
utente
lingua
password
Figura 2.12.
Schema grafico dell’entità utente
Nome attributo Valori
Descrizione
idUtente
Numero progressivo Codice che identifica univocamente
un’istanza dell’entità utente
nome
Stringa di caratteri Nome di battesimo dell’utente
cognome
Stringa di caratteri Cognome dell’utente
username
Stringa di caratteri Username scelto dall’utente
password
Stringa di caratteri Password scelta dall’utente
email
Stringa di caratteri E-mail dell’utente
lingua
Stringa di caratteri Lingua parlata dall’utente
Tabella 2.8.
Documentazione dell’entità utente
23
2 – Il Database di ArcheoMap
tipoPermesso
idPermesso
permesso
Figura 2.13. Schema grafico dell’entità permesso
Nome attributo Valori
Descrizione
idPermesso
Numero progressivo Codice che identifica univocamente
un’istanza dell’entità permesso
tipo permesso Stringa di caratteri Nome assegnato al tipo di permesso
Tabella 2.9.
Documentazione dell’entità permesso
capo progetto
utente
direttore scavo
Figura 2.14.
Schema grafico delle entità capo progetto e direttore scavo
L’ultimo punto dei requisiti non introduce nessuna entità rilevante, e perciò ad
esso non corrisponde alcuno schema.
Relazioni del progetto
Una volta ultimata la ricerca e la definizione delle entità, con i loro attributi e le
generalizzazioni, il passo successivo è rileggere il documento dei requisiti mettendone
in luce questa volta le relazioni, ossia i legami tra le entità. Per ogni relazione, oltre a
stabilirne un nome simbolico che la identifichi nello schema finale, se ne deve fissare
la cardinalità, stabilendo se è del tipo uno a uno, uno a molti o molti a molti.
24
2 – Il Database di ArcheoMap
I primi quattro punti dei requisiti si limitano a definire le entità “località” e
“scavo“ e i loro attributi, non vi compaiono relazioni. Al punto cinque si legge
che le località sono organizzate in progetti: questa è la prima relazione da introdurre. Si definisce dunque una relazione di nome “composizione”2 che lega le entità
“località” e “progetto”. Tale relazione sta a significare che ogni progetto si compone di località, e che ogni località fa parte di un progetto. La relazione è di tipo uno
a molti: ogni istanza dell’entità “progetto” è relazionata a più istanze dell’entità
“località”, mentre ogni istanza dell’entità località si relaziona a una e una sola
istanza della classe “progetto”. Nella figura 2.15 è riportato lo schema grafico della
relazione con le entità che essa lega e la cardinalità.
(1,1)
località
Figura 2.15.
(0,N)
composizione
progetto
Schema grafico della relazione “composizione”
Il punto sei definisce tre relazioni che legano l’entità “località” con l’entità
“diario”, l’entità “galleria” e l’entità “insieme reperti”. I nomi assegnati simbolicamente a queste relazioni sono rispettivamente: “sezione diario”, “sezione
galleria” e “sezione reperti”. In tutti e tre i casi si tratta di una relazione del
tipo uno a uno: ogni istanza dell’entità “località” si lega a una e una sola istanza
delle entità “diario”, “galleria” e “insieme reperti”; viceversa, ogni istanza di
queste tre entità è legata in modo univoco a un’istanza di “località”. Nella figura
2.16 è riportato lo schema grafico delle tre relazioni.
Il punto sette definisce tre relazioni. La prima lega “diario” con “articolo”, a
cui si assegna il nome “elenco articoli”. Si tratta di una relazione del tipo uno
a molti, perché ogni articolo fa parte di un solo diario, ma ogni diario è formato da
più articoli. La seconda è la relazione che lega ogni articolo di diario al suo autore
(vale a dire un’istanza della classe “utente”), a cui si dà nome “scrittura”. Tale
relazione è ancora del tipo uno a molti: ogni articolo di diario viene scritto da uno e
un solo autore, mentre ogni autore può scrivere più articoli. La terza relazione, simile
alla precedente, lega ancora “articolo” con “utente” e serve per tener traccia
dell’ultimo utente che ha modificato l’articolo. Si tratta di una relazione uno a
molti perchè un utente può essere stato l’ultimo a modificare una serie di articoli.
Nella figura 2.17 è riportato lo schema risultante dall’unione delle tre relazioni.
2
Contrariamente a quanto avviene con la definizione delle entità, nel dare un nome alle relazioni
non è obbligatorio rimanere fedeli alla terminologia adottata nei requisiti: è sufficiente coglierne il
senso senza stravolgerlo
25
2 – Il Database di ArcheoMap
(1,1)
(1,1)
sezione
località
diario
diario
(1,1)
(1,1)
sezione
località
galleria
galleria
(1,1)
(1,1)
sezione
località
insieme reperti
reperti
Figura 2.16. Schema grafico delle tre relazioni “sezione diario” “sezione
galleria” e “sezione reperti”
(0,N)
(1,1)
elenco
diario
articolo
articoli
(1,1)
(1,1)
scrittura
(0,N)
modifica
utente
diario
(0,N)
Figura 2.17.
Schema grafico delle relazioni “elenco articoli” e “scrittura”
Il punto nove definisce la relazione “elenco immagini” che lega ogni galleria
a più immagini e ogni immagine ad una galleria (è dunque una relazione del tipo
uno a molti); la relazione “foto” che lega ogni utente alle immagini inserite e ogni
immagine all’unico utente che l’ha inserita (nuovamente una relazione uno a molti);
e la relazione “modifica foto” che lega un’immagine all’ultimo utente che l’ha
modificata. Fare riferimento alla figura 2.18 per lo schema grafico.
Il punto dieci delinea la relazione con cardinalità uno a molti “elenco reperti”
che lega le istanze dell’entità “reperto” alle istanze dell’entità “insieme reperti”;
la relazione uno a molti “catalogo” che lega i reperti all’utente che li ha inseriti;
26
2 – Il Database di ArcheoMap
(0,N)
(1,1)
elenco
immagini
galleria
immagine
(1,1)
(0,N)
(1,1)
foto
modifica
utente
foto
(0,N)
Figura 2.18.
Schema grafico delle due relazioni “elenco immagini” e “foto”
e la relazione uno a molti “modifica reperto” che associa un reperto all’ultimo
utente che l’ha modificato. Bisogna poi aggiungere due relazioni del tipo molti
a molti: “riferimento immagine” e “riferimento diario” che rispettivamente
legano i reperti agli articoli di diario e alle immagini della galleria. Infatti, ogni
istanza dell’entità “reperto” può fare riferimento a più immagini e più articoli di
diario che lo descrivono, e viceversa ogni istanza dell’entità “immagine” o dell’entità
“articolo” può fare riferimento a più reperti.
Nel punto undici si legge che ogni reperto può essere legato a una o più schede ministeriali, quindi si introduce la relazione “documentazione” del tipo uno a
molti che lega ogni reperto alle schede ministeriali che lo descrivono e ogni scheda
ministeriale al reperto descritto. Le schede ministeriali sono poi associate all’utente
che le ha create e all’utente che ha effettuato l’ultima modifica: in entrambi i casi
si tratta di relazioni uno a molti. Nella figura 2.19 è riportato lo schema grafico
che riassume tutte le relazioni che coinvolgono l’entità “reperto” e l’entità “scheda
ministeriale”.
Nei punti dodici e tredici viene trattata la gestione dei permessi. Tramite l’entità
“permesso” viene regolato l’accesso degli utenti alle località, perciò l’unica soluzione
è quella di creare una relazione ternaria “autorizzazione”, del tipo molti a molti,
che leghi contemporaneamente l’entità permesso alle entità “utente” e “località”.
Ci sono poi gli utenti privilegiati, vale a dire i capi progetto e direttori scavo, che
sono legati alle entità da essi controllate (rispettivamente progetti e località) da
opportune relazioni molti a molti “gestione” e “direzione”. Quest’intreccio di
associazioni viene rappresentato graficamente nella figura 2.20.
Infine nel punto quattordici si richiede di tener traccia dei progetti e delle località
che un utente vuol esportare sul proprio palmare. Questo si ottiene introducendo
un’ultima relazione, a cui si dà nome “esportazione”, che lega ogni utente alle
località e progetti che questo ha deciso di esportare. Si tratta di una relazione molti
27
2 – Il Database di ArcheoMap
(1,1)
(0,N)
insieme
reperti
elenco
reperto
reperti
(1,1)
(0,N)
utente
catalogo
(0,N)
(0,N)
(1,1)
modifica
(0,N)
reperto
modifica
scheda
redazione
(1,1)
(1,1)
(0,N)
scheda
ministeriale
documentazione
(1,1)
(0,N)
riferimento
articolo
diario
(0,N)
(0,N)
(0,N)
riferimento
immagine
immagine
Figura 2.19.
Schema grafico delle relazioni che coinvolgono l’entità “reperto”
a molti (perchè ogni istanza delle entità coinvolte può partecipare alla relazione con
cardinalità multipla), ed è una relazione ternaria per via del legame esistente tra
località e progetti: non è infatti possibile esportare una località senza esportare
contemporaneamente anche il progetto di cui fa parte. Nella figura 2.21 è dato lo
schema grafico che risolve quest’ultimo punto dei requisiti.
Lo schema completo
Una volta determinate le entità e le relazioni coinvolte nel progetto si uniscono
i singoli grafici e si traccia il modello E-R completo del database, riportato nella
figura 2.22. Per ragioni di praticità e per evitare di rendere troppo intricato lo
28
2 – Il Database di ArcheoMap
direttore
scavo
capo
progetto
utente
(1,N)
(1,N)
(1,N)
autorizza−
direzione
gestione
zione
(1,N)
(1,N)
(0,N)
(0,N)
località
Figura 2.20.
permesso
progetto
Schema grafico delle relazioni che coinvolgono gli utenti
utente
(0,N)
località
(0,N)
progetto
esportazione
(0,N)
Figura 2.21.
Schema grafico della relazione “esportazione”
schema, si sono rappresentate le entità senza specificarne gli attributi, per i quali si
deve fare riferimento alla documentazione nella sezione 2.3.2; per lo stesso motivo
si sono omesse le cardinalità delle relazioni. Si tratta di un modello concettuale,
ancora distante da quello che sarà il prodotto definitivo, perché in esso sono presenti
ridondanze e complessità che è possibile eliminare o semplificare. A partire da questo
schema si può procedere quindi con la fase di progettazione logica.
29
Figura 2.22.
30
permesso
utente
autorizzazione
gestione
riferimento
articolo
riferimento
immagine
composizione
scavo
esportazione
progetto
direttore
scavo
capo
progetto
modifica
diario
elenco
articoli
articolo
scrittura
località
direzione
elenco
immagini
immagine
foto
modifica
immagine
sezione
galleria
sezione
diario
sezione
reperti
elenco
reperti
reperto
catalogo
insieme
reperti
galleria
diario
scheda
redazione
modifica
scheda
documen−
tazione
modifica
reperto
2 – Il Database di ArcheoMap
Schema E-R concettuale completo per il database di ArcheoMap
2 – Il Database di ArcheoMap
2.4
Progetto logico
L’obiettivo di questa fase di progetto è quello di costruire uno schema logico in grado
di descrivere, in maniera corretta ed efficiente, tutte le informazioni contenute nello
schema E-R prodotto nella fase di progettazione concettuale. Non si tratta di una
semplice traduzione da un modello ad un altro perché prima di passare allo schema
logico occorre ristrutturare il modello E-R con il fine di ottimizzare il progetto. I
passi che portano alla definizione dello schema logico sono pertanto due:
• Ristrutturazione dello schema E-R;
• Traduzione verso il modello logico.
2.4.1
Ristrutturazione dello schema E-R
Scopo della ristrutturazione logica è quello di analizzare lo schema E-R prodotto nel
corso della progettazione concettuale e generare un altro schema E-R, equivalente
al primo in quanto rappresentazione stilizzata dei requisiti, ma ottimizzato perché
privo di ridondanze e costrutti superflui.
Le parti del diagramma concettuale che sono da considerare ridondanti sono
quelle che possono essere derivate da altre entità o relazioni senza alterare la compatibilità con i requisiti. Tipicamente ricadono in questa categoria:
• attributi che corrispondono ad informazioni ottenibili con semplici operazioni
da altre parti del modello;
• relazioni e entità che nel modello concettuale sono state introdotte per chiarezza ma che possono essere eliminate perchè desumibili da altri elementi del
modello.
Non esistono tecniche standard per individuare cosa vada tolto e cosa no, ci si deve
basare unicamente sull’esperienza e sulla capacità del progettista che, anche sulla
base di considerazioni prestazionali, può optare per una determinata scelta. Possono
infatti esserci situazioni in cui un’entità o un attributo, apparentemente ridondanti,
devono essere mantenuti; la loro eliminazione, infatti, causerebbe un eccessivo carico computazionale sul prodotto finito con impatto negativo sulle performance del
database.
Il passo successivo verso uno schema più essenziale è l’eliminazione delle generalizzazioni. Come si è detto nella sezione 2.3.1 le generalizzazioni sono forme
particolari di un’entità più generica che condividono con quest’ultima parte degli
attributi, introducendone eventualmente di nuovi. È evidente quindi che la ripetizione degli attributi in entità cosı̀ strettamente legate è un’inutile ridondanza che va
risolta. I modi di procedere sono sostanzialmente tre:
31
2 – Il Database di ArcheoMap
1. Accorpamento dell’entità figlia nell’entità padre: si crea un’unica entità, con il
nome dell’entità padre, e gli attributi dell’entità figlia vengono accorpati agli
attributi dell’entità padre. È la soluzione più adatta quando le entità figlie
introducono differenziazioni non sostanziali;
2. Accorpamento dell’entità padre nelle entità figlie: si creano tante entità quante
sono le entità figlie, ognuna di esse con gli attributi propri e, in aggiunta, quelli
dell’entità padre, che può cosı̀ essere eliminata. È la soluzione più adatta
quando la generalizzazione è totale, ossia quando le entità figlie sono ben
differenziate tra di loro;
3. Sostituzione con relazioni: se le entità padre e le entità figlie sono ben distinte e
si vogliono mantenere separati gli accessi alle singole entità, conviene sostituire
la generalizzazione con una vera e propria relazione.
2.4.2
Ristrutturazione del diagramma E-R di ArcheoMap
Dopo aver descritto cosa si intende per ristrutturazione di un diagramma E-R, se
ne dà un esempio pratico di applicazione sul progetto ArcheoMap.
Come sottolineato nella sezione precedente, il primo obiettivo è quello di ricercare
gli elementi che si possono eliminare perché ottenibili da altre entità e relazioni già
presenti nel progetto. Analizzando lo schema concettuale di figura 2.22 si possono
fare le seguenti considerazioni:
• L’entità “diario” è una ridondanza. Quello a cui si è effettivamente interessati
è poter accedere all’insieme di articoli scritti per una determinata località,
quindi in tal senso “diario” rappresenta solo un ponte concettuale che non
ha alcuna utilità pratica effettiva. Si opta dunque, per ragioni di efficacia,
per la sua eliminazione, e per collegare direttamente l’entità “articolo” con
l’entità “località”;
• Discorso del tutto analogo può essere fatto per le entità “insieme reperti”
e “galleria”;
• Vi sono ridondanze nella gestione dei permessi. Se è vero che dal punto di
vista concettuale le entità “capo progetto” e “direttore scavo” sono figlie
dell’entità “utente”, è anche vero che i ruoli svolti da queste all’interno dell’organizzazione di ArcheoMap possono essere ricavati dai permessi. In altre
parole, un utente che ha un permesso di tipo capo progetto è automaticamente identificato come un capo progetto, senza necessità di assegnargli un’entità
distinta. Si è scelto quindi di eliminare queste due entità senza che ciò vada
ad inficiare il corretto funzionamento del sistema;
32
2 – Il Database di ArcheoMap
• Le relazioni “riferimento immagine”, “riferimento articolo” e “documentazione” hanno la stessa cardinalità e svolgono dal punto di vista concettuale lo stesso compito: tener conto di quando articoli, immagini e schede
ministeriali sono da considerarsi di riferimento per un reperto catalogato. Si
è ritenuto più conveniente eliminare queste tre relazioni e tenerne una sola,
chiamata “riferimento”, con un attributo “tipo” in modo da tener conto di
quale categoria di riferimento si tratta.
Una volta risolte le ridondanze, il passo successivo è eliminare le generalizzazioni
rimaste, che nel caso in esame è una sola: quella che lega l’entità padre “località”
con l’entità figlia “scavo”. Poiché le due entità non presentano sostanziali differenze,
tra le possibili soluzioni prospettate nella sezione 2.4.1 si è optato per la prima, cioè
l’accorpamento dell’entità figlia nell’entità padre: tutti gli attributi dell’entità figlia
vengono aggiunti all’entità padre e per riconoscere quando una località è uno scavo,
si aggiunge un ulteriore attributo booleano chiamato “scavo”. Nella figura 2.23
è riportato lo schema grafico dell’entità “località” cosı̀ come si presenta dopo
l’accorpamento degli attributi dell’entità “scavo”.
nome_antico
data_fine
idLocalità
città
nome_nuovo
data_inizio
comune
pubblico
indicazioni
Località
nazione
scavo
e−mail
indirizzo
telefono
note
coordinate
descrizione
internet
Figura 2.23. Schema grafico dell’entità “località” dopo l’accorpamento degli
attributi dell’entità “scavo”
Non essendoci altre ottimizzazioni da fare, si può considerare conclusa la fase di
33
2 – Il Database di ArcheoMap
ristrutturazione e applicare quanto detto allo schema concettuale per ottenerne il
grafico di figura 2.24.
2.4.3
Traduzione verso il modello logico
A partire dallo schema E-R ristrutturato, si procede alla creazione del modello logico
vero e proprio. Si tratta di un modello che delinea in modo sufficientemente preciso
quella che sarà la struttura finale del database relazionale che si sta progettando, in
termini di tabelle, attributi e chiavi, senza tuttavia scendere in dettagli dipendenti
dalla particolare piattaforma DBMS scelta, la cui definizione viene demandata alla
fase successiva, la progettazione fisica.
Le tabelle sono descritte con un formalismo grafico: si dichiara il nome della
tabella seguito, fra parentesi, dalla lista degli attributi, ossia dei campi di cui è composta. Uno o più di questi campi sono sottolineati per indicare la chiave primaria,
cioè le colonne che identificano in modo univoco ogni voce inserita.
NomeTabella(chiave, attributo1, attributo2, ...)
La traduzione di un modello E-R in un modello logico segue delle regole generali
che sono di seguito esposte:
• Ogni entità è una tabella, le cui colonne sono gli attributi e la cui chiave
univoca è l’identificatore;
• Ogni relazione molti a molti diviene una tabella, le cui colonne sono gli identificatori delle entità associate, che fungono anche da chiave primaria;
• Le relazioni del tipo uno a molti con partecipazione obbligatoria (cardinalità
minima uno), vengono sciolte, e all’entità che ha partecipazione massima uno
viene aggiunto un attributo che è la chiava primaria dell’entità a cui è associata;
• Le relazioni del tipo uno a molti con partecipazione opzionale (cardinalità
minima zero) possono venire tradotte come nel punto precedente, altrimenti
possono generare una nuova tabella, avente come nome quello della relazione,
e come colonne gli identificatori delle entità associate. La chiave primaria è
la colonna corrispondente all’identificatore dell’entità che ha partecipazione
massima uno;
• Le relazioni del tipo uno a uno con partecipazione obbligatoria da parte di
entrambe le entità, vengono sciolte e ad una delle due entità (a scelta) viene
aggiunta una colonna corrispondente all’identificatore dell’altra entità;
34
Figura 2.24.
35
(1,N)
utente
(0,N)
permesso
(0,N)
elenco
articoli
(1,N)
autorizzazione
(1,N)
(0,N)
(1,1)
(0,N)
(1,1)
immagine
foto
(1,N)
località
(0,N)
(1,1)
elenco
immagini
(0,N)
riferimento
tipo
composizione
(0,N)
0,N
progetto
(0,N)
esportazione
modifica
diario
(1,1)
articolo
(1,1)
scrittura
(0,N)
modifica
immagine
(1,1)
elenco
reperti
0,N
reperto
(1,1)
catalogo
modifica
reperto
(0,N)
modifica
scheda
(1,1)
scheda
(1,1)
redazione
2 – Il Database di ArcheoMap
Schema E-R concettuale ridotto per il database di ArcheoMap
2 – Il Database di ArcheoMap
• Le relazioni del tipo uno a uno in cui una sola delle entità è a partecipazione obbligatoria sono tradotte in modo analogo alle precedenti, ma la colonna aggiuntiva corrispondente all’identificatore dell’altra entità è obbligatorio
associarla all’entità avente cardinalità minima zero;
• Le relazioni del tipo uno a uno in cui entrambe le entità hanno partecipazione
opzionale non vengono sciolte, ma si trasformano in una tabella avente come
colonne gli identificatori delle entità associate e come chiave primaria una di
queste colonne a scelta.
Le regole di traduzione appena elencate coprono tutte le possibili casistiche
e consentono di trasformare qualunque modello E-R ristrutturato in uno schema
logico.
2.4.4
Schema logico del progetto ArcheoMap
Si applicano ora le regole di traduzione al diagramma E-R ridotto di figura 2.24 per
tracciare lo schema logico del database.
Come passo preliminare si crea una tabella per ogni entità dello schema mettendo
come attributi quelli noti dallo studio concettuale:
articolo(idArticolo, testo, titolo, data scrittura, data modifica, visibile);
immagine(idImmagine, note, data inserimento, data modifica, file);
località(idLocalità, città, comune, nazione, scavo, indirizzo, coordinate, descrizione,
indirizzo internet, note, telefono, e-mail, indicazioni, data inizio, data fine,
nome nuovo, nome antico, pubblico);
progetto(idProgetto, nome, descrizione, internet, e-mail, telefono, data apertura,
data chiusura);
permesso(idPermesso, tipo permesso);
reperto(idReperto, nome, data inserimento, data modifica, coordinate);
scheda ministeriale(idScheda, data inserimento, data modifica, . . . , attributi scheda);
utente(idUtente, nome, cognome, username, password, e-mail, lingua);
La mossa successiva è quella di tradurre le relazioni. Per cominciare, la relazione
“autorizzazione” è del tipo molti a molti con partecipazione obbligatoria. Per
quanto detto, la soluzione è quella di creare una nuova tabella che abbia come
campi le chiavi delle entità “utente”, “progetto”, “località” e “permesso”:
36
2 – Il Database di ArcheoMap
autorizzazione(idPermesso, idUtente, idProgetto, idLocalità);
La relazione “scrittura” è del tipo uno a molti con partecipazione opzionale. Ci
sono due possibili modi per tradurla, tra questi si opta per lo scioglimento della
relazione e l’aggiunta di un nuovo attributo all’entità “articolo”, attributo che
punta alla chiave dell’entità “utente”, in questo modo:
articolo(idArticolo, testo, titolo, data scrittura, data modifica, visibile, idAutore);
La relazione “modifica diario” è identica alla precedente, quindi allo stesso modo
si aggiunge un nuovo attributo all’entità “articolo” che punta alla chiave dell’entità
“utente”:
articolo(idArticolo, testo, titolo, data scrittura, data modifica, visibile, idAutore,
idModificatore);
Un procedimento del tutto analogo si applica anche alle relazioni “foto”, “modifica foto”, “catalogo”, “modifica reperto”, “redazione” e “modifica scheda”, che quindi scompaiono, sostituite da attributi aggiunti alle entità che partecipano alla relazione con cardinalità massima uno:
immagine(idImmagine, note, data inserimento, data modifica, file, idAutore,
idModificatore);
reperto(idReperto, nome, data inserimento, data modifica, coordinate, idAutore,
idModificatore);
scheda ministeriale(idScheda, data inserimento, data modifica, . . . , attributi scheda,
. . . , idAutore, idModificatore);
La relazione “elenco articoli” è ancora una relazione uno a molti con partecipazione opzionale, e nuovamente si preferisce il suo scioglimento e l’aggiunta di un attributo all’entità “articolo”, che quindi va un’altra volta modificato,
aggiungendogli la chiave dell’entità associata, “località”:
articolo(idArticolo, testo, titolo, data modifica, data scrittura, visibile, idAutore,
idModificatore, idLocalità);
Stessa cosa per le relazioni “elenco immagini” e “elenco reperti”:
immagine(idImmagine, note, data inserimento, data modifica, file, idAutore,
idModificatore, idLocalità);
reperto(idReperto, nome, data inserimento, data modifica, coordinate, idAutore,
idModificatore, idLocalità);
37
2 – Il Database di ArcheoMap
La relazione “composizione”, che lega le località ai progetti, è un altro caso di
relazione uno a molti, ma questa volta a partecipazione obbligatoria (ogni località
deve appartenere a uno e un solo progetto), quindi non si hanno scelte: nella traduzione verso il modello logico è necessario sciogliere la relazione e aggiungere un
attributo all’entità che ha partecipazione massima uno, ossia “località”:
località(idLocalità, città, comune, nazione, scavo, indirizzo, coordinate, descrizione,
indirizzo internet, note, telefono, e-mail, indicazioni, data inizio, data fine,
nome nuovo, nome antico, pubblico, idProgetto);
La relazione molti a molti “riferimento” viene mantenuta e genera una tabella
siffatta:
riferimento(idRiferimento, idReperto, idOggetto, tipo);
dove “idOggetto” è la chiave dell’oggetto associato, che di volta in volta può essere
un articolo, un’immagine o una scheda ministeriale, in base a quanto indicato dal
campo “tipo”.
Infine la relazione ternaria molti a molti “esportazione” dà origine ad una
nuova tabella costituita dalle sole chiavi primarie che essa lega:
esportazione(idUtente, idProgetto, idLocalità)
Nel tentativo di rendere edotto il lettore su come si sviluppa passo per passo
il progetto logico, alcune tabelle sono state modificate più volte nel corso della
trattazione. Per chiarezza si mostra nella tabella 2.10 lo schema logico completo.
Con questo il database può uscire dall’astrazione progettuale per essere tradotto
in realtà fisica, implementato su un DBMS reale.
2.4.5
Progettazione fisica
La progettazione fisica è la fase finale del processo di pianificazione e creazione di
una base dati. Lo scopo di questa fase è quello di dare un’implementazione pratica
su calcolatore dello schema logico prodotto al termine della fase precedente. Al
prodotto finale si giunge per passi successivi:
1. Scelta del DBMS da utilizzare;
2. Creazione delle tabelle, sfruttando i tipi di dato e i costrutti specifici del DBMS
scelto;
3. Creazione di particolari procedure interne al DBMS, i trigger, per il mantenimento dell’integrità relazionale;
38
2 – Il Database di ArcheoMap
articolo(idArticolo, testo, titolo, data scrittura, data modifica, visibile, idAutore,
idModificatore, idLocalità);
autorizzazione(idPermesso, idUtente, idProgetto, idLocalità);
immagine(idImmagine, note, data inserimento, data modifica, file, idAutore,
idModificatore, idLocalità);
località(idLocalità, città, comune, nazione, scavo, indirizzo, coordinate, descrizione, indirizzo internet, note, telefono, e-mail, indicazioni, data inizio, data fine,
nome nuovo, nome antico, pubblico, idProgetto);
progetto(idProgetto, nome, descrizione, internet, e-mail, telefono, data apertura,
data chiusura);
permesso(idPermesso, tipo permesso);
reperto(idReperto, nome, data inserimento, data modifica, coordinate, idAutore,
idModificatore, idLocalità);
riferimento(idRiferimento, idReperto, idOggetto, tipo, data inserimento, idUtente);
scheda ministeriale(idScheda, data inserimento, data modifica, . . . , attributi
scheda, . . . , idAutore, idModificatore);
utente(idUtente, nome, cognome, username, password, email, lingua);
Tabella 2.10.
Schema logico del database di ArcheoMap
4. Ottimizzazione delle prestazioni per mezzo di particolari strutture chiamate
“indici”.
È fondamentale chiarire che il progetto del database ottenuto dall’applicazione successiva della progettazione concettuale e della progettazione logica è totalmente
indipendente dalla realizzazione fisica finale. Questo significa che quanto esposto
nei paragrafi seguenti rappresenta solo un esempio dei molti modi in cui è possibile implementare un prototipo del database: lo stesso si sarebbe potuto ottenere utilizzando un qualsiasi altro strumento tra i molti che il mercato mette a
disposizione.
PostgreSQL
DBMS (Database Management System) è il termine con cui in informatica si fa
riferimento a sistemi software disegnati appositamente per la creazione e la manipolazione di basi dati da parte di più utenti. Nell’obiettivo di utilizzare software
Open Source per lo sviluppo di un prototipo del progetto ArcheoMap, si è cercato
tra questi quale DBMS usare nell’implementazione del database. La scelta è caduta su PostgreSQL nella sua versione 7.4, a oggi considerato uno dei migliori DBMS
39
2 – Il Database di ArcheoMap
Open Source in circolazione, in grado di confrontarsi senza timori con i più blasonati
sistemi commerciali.
Nato nel 1985 come derivato del DBMS commerciale Ingres sviluppato in seno
all’università di Berkeley, ha goduto dei contributi della comunità di sviluppatori di
tutto il mondo, assumendo il nome attuale nel 1996 dopo che è stato introdotto il
supporto al linguaggio di interrogazione dei database SQL3 . La versione 7.4 utilizzata
come riferimento nella realizzazione del prototipo del progetto analizzato in questa
tesi è stata rilasciata nel 2003.
Questo DBMS supporta interrogazioni complesse in SQL, fa uso degli indici per
l’ottimizzazione delle prestazioni, consente la creazione di trigger per il mantenimento della integrità relazionale ed è improntato alla multi-utenza in modo da garantire
un accesso selettivo e sicuro ai dati. Mette inoltre a disposizione una serie di meccanismi per il backup e il restore dei dati in modo da mettersi al riparo da eventuali
guasti senza perdita di informazioni.
La caratteristica più importante è la sua espandibilità: è dotato di un linguaggio
di programmazione interno, chiamato PL/SQL, che consente la creazione di tipi di
dati complessi e di nuove funzionalità in modo da adattarsi facilmente a tutte le
esigenze.
Tipi di dato di PostgreSQL
Per tradurre il modello logico all’interno del DBMS occorre scegliere, tra i tipi di
dato messi a disposizione da questo, quelli che sono più adatti a rappresentare i
campi delle singole tabelle. Dalla documentazione delle entità viste nelle tabelle 2.1
– 2.9 i tipi di dato da utilizzare sono: numeri, numeri progressivi, numeri booleani,
stringhe di caratteri e date.
Per quanto riguarda la rappresentazione dei numeri, PostgreSQL mette a disposizione il tipo di dato integer che consente di trattare numeri interi su 32 bit fino
ad un valore massimo di 2147483647.
I numeri progressivi sono utilizzati per la definizione dei codici univoci delle
chiavi delle tabelle. PostgreSQL mette a disposizione per queste esigenze il tipo di
dato serial, anch’esso su 32 bit, con la caratteristica che ad ogni nuovo inserimento
in una tabella il codice viene incrementato di uno. In questo modo il primo elemento
inserito avrà codice 1, il secondo 2 e cosı̀ via, garantendo che nessun elemento abbia
lo stesso identificativo.
Per i numeri booleani si utilizza l’apposito tipo boolean che può assumere solo
due valori: true se il campo deve essere asserito, altrimenti false.
Per quanto riguarda la rappresentazione delle stringhe di caratteri, PostgreSQL
offre due possibilità: il tipo character varying(n) e il tipo text. Nel primo
3
SQL, Simple Query Language, linguaggio caratterizzato da pochi e semplici istruzioni
ottimizzate per l’interrogazione dei database
40
2 – Il Database di ArcheoMap
caso è possibile definire stringhe di caratteri che hanno una lunghezza massima n
specificata, nel secondo caso si possono inserire stringhe di caratteri di lunghezza
illimitata. Sebbene la seconda soluzione possa sembrare in prima istanza la più
conveniente, in realtà una stringa di caratteri di tipo text occupa più spazio di
una stringa con lunghezza massima dichiarata, quindi è conveniente utilizzare il
tipo text solo quando strettamente necessario. Si è perciò scelto di tradurre come
text solo i campi di lunghezza indefinita, come per esempio i testi di descrizioni e
articoli di diario, mentre per tutti gli altri campi si è adottato il tipo character
varying(n) impostando il parametro n ad una dimensione appropriata. Per esempio
l’attributo “nome” della tabella “utente” è stato fissato ad una lunghezza massima
di 80 caratteri, sufficienti ad ospitare nomi anche molto lunghi.
Infine per l’inserimento delle date si è utilizzato il tipo di dato timestamp
che consente di memorizzare in un intero di 32 bit data e ora con precisione al
millisecondo.
Terminata la scelta dei tipi di dato da utilizzare, è possibile scrivere il codice
SQL che istruisce il DBMS PostgreSQL su come creare le tabelle e la loro struttura.
Nella sezione 9.1 dell’appendice è riportato tale codice.
Trigger
Il termine trigger indica una procedura scritta all’interno del database che consente
di eseguire particolari azioni ogni volta che si effettuano delle modifiche (inserimento,
aggiornamento, cancellazione) ai dati di una tabella. Con i trigger si realizza la
cosiddetta “base dati attiva”: il database reagisce automaticamente a determinati
eventi, eseguendo il codice del trigger ogni volta che questo è necessario. In questo
modo i trigger vengono a far parte della struttura stessa del database e consentono
di mantenere tra i dati delle tabelle legami complessi che non è possibile esprimere
in meri termini di diagrammi E-R perché, essendo selettivi, hanno necessariamente
bisogno del supporto di un linguaggio di programmazione più completo del semplice
SQL. PostgreSQL possiede un proprio linguaggio interno per la definizione di trigger
che prende il nome di PL/SQL.
All’interno del database di ArcheoMap si sono definiti tre trigger, tutti sulla
tabella “autorizzazione” in cui sono registrati i permessi che regolano l’accesso degli
utenti. Il primo trigger, a cui si è dato il nome “check leader”, si scatena ogni
volta che viene effettuata una cancellazione su questa tabella per assicurarsi che un
progetto non venga lasciato senza almeno un capo progetto, come si richiede nei
requisiti. Se si sta togliendo il permesso di capo progetto all’ultima persona che ha
tale qualifica nell’ambito di un progetto, questo trigger se ne accorge, genera un
messaggio di errore e impedisce l’operazione.
Il secondo trigger si scatena dopo che sono stati cancellati i permessi di una persona nell’ambito di una località. Ogni utente presente nel database, per poter essere
41
2 – Il Database di ArcheoMap
considerato un collaboratore ad una località, deve obbligatoriamente avere almeno
un permesso associato ad essa. Tuttavia si deve tener conto di situazioni transitorie
in cui un utente, pur collaborando ancora ad un progetto o a una località, è stato
privato dei suoi permessi senza che gliene siano stati assegnati di nuovi. Per trattare
questa casistica, si è inserito un permesso fittizio chiamato “na” (abbreviazione di
not assigned ) agli utenti che si trovano nella situazione descritta. Si è creato allora il
trigger “set na” che automaticamente, alla cancellazione dei permessi di un utente,
se questo non ne ha altri nell’ambito della località, gli assegna il permesso fittizio.
Il terzo ed ultimo trigger, a cui si è dato nome “delete na”, è complementare
al precedente e si scatena quando viene inserito un nuovo permesso. Se il nuovo
permesso inserito riguarda una persona che si trova nello stato “na” per una data
località, il trigger automaticamente inserisce il nuovo permesso e cancella il permesso
fittizio, di cui non c’è più bisogno.
Indici
Con il termine “indice” nell’architettura delle basi dati si intende una struttura ad
albero binario che consente di velocizzare le operazioni di ricerca nelle tabelle.
In condizioni normali, per ottenere i risultati di un’interrogazione ad una tabella,
il DBMS effettua una scansione da cima e fondo, restituendo le righe della tabella
che soddisfano i criteri di ricerca. Tale modo di procedere, come è facile intuire, è
molto dispendioso nel caso di tabelle di grosse dimensioni.
La soluzione per velocizzare considerevolmente le operazioni di ricerca consiste
nell’affiancare ad una tabella una struttura ausiliaria a forma di albero binario (un
indice, per l’appunto) in cui ogni nodo contiene un valore del campo che si vuole
indicizzare e un puntatore alla posizione della riga che lo contiene nella tabella.
Nella figura 2.25 è rappresentato un’albero binario e, con una linea tratteggiata,
x4
x
x2
x5
x7
x6
x3
Figura 2.25.
x1
Schema di funzionamento di un indice per una tabella
il puntatore alla riga della tabella contenente lo specifico valore del campo. La
proprietà saliente degli alberi binari è che per ogni nodo, nel sotto albero di destra
42
2 – Il Database di ArcheoMap
sono contenuti solo valori minori, mentre nel sotto-albero di sinistra sono contenuti
solo valori maggiori. In questo modo le operazioni di ricerca vengono velocizzate
perché, partendo dal nodo superiore (nodo radice) e operando gli opportuni confronti
sul valore che si intende cercare, è possibile spostarsi a destra o a sinistra lungo
i singoli rami dell’albero escludendo automaticamente dalla ricerca l’intero sotto
albero opposto. È possibile dimostrare in termini matematici che il tempo di ricerca
medio negli alberi binari è log2 N dove N è il numero di valori complessivamente
contenuti nella tabella. Per esempio, per ricercare un elemento all’interno di una
tabella di 1000 righe, con una ricerca esaustiva è necessario effettuare mediamente
500 confronti, in un albero binario se ne effettuano mediamente 10 soltanto!
L’uso degli indici ha tuttavia una controindicazione: per mantenere aggiornato
l’albero binario, è necessario che ad ogni inserimento o cancellazione di un elemento in una tabella debba corrispondere anche un inserimento o una cancellazione
nell’indice. Risulta quindi sconveniente costruire indici su tutti i campi delle tabelle, è consigliato piuttosto stabilirne un numero ridotto solo per i campi più selettivi
effettivamente necessari, ovvero quelli maggiormente interessati dai criteri di ricerca.
PostgreSQL, cosı̀ come altri DBMS, costruisce automaticamente un indice per
le chiavi primarie delle tabelle, questo perché tali campi, essendo utilizzati nella
costruzione delle relazioni, sono spessissimo coinvolti nelle operazioni di ricerca.
Ipotizzando quali possano essere le operazioni compiute più frequentemente sul
database, si sono isolati, per ogni tabella, i campi più utilizzati e si è optato per la
definizione dei seguenti indici:
• Un indice per il campo “nome nuovo” della tabella “località” per velocizzare
la ricerca per nome delle località;
• Un indice per la coppia di campi “username“ e “password” della tabella
“utente” per velocizzare le operazioni di autenticazione degli utenti;
• Un indice sul campo “idAutore” della tabella “articolo” per velocizzare le
ricerche degli articoli scritti da un determinato utente;
• Un indice sul campo “idAutore” della tabella “immagine” per velocizzare le
ricerche delle immagini inserite da un determinato utente;
• Un indice sul campo “idAutore” della tabella “reperto” per velocizzare le
ricerche dei reperti catalogati da un determinato utente;
• Un indice sul campo “idLocalità” della tabella “articolo” per velocizzare
la ricerca degli articoli di diario collegati ad una determinata località;
• Un indice sul campo “idLocalità” della tabella “immagine” per velocizzare
la ricerca delle immagini collegate ad una determinata località;
43
2 – Il Database di ArcheoMap
• Un indice sul campo “idLocalità” della tabella “reperto” per velocizzare la
ricerca dei reperti collegati ad una determinata località;
• Un indice sulla tripla di campi “idReperto”, “idOggetto”, e “tipo” della
tabella “riferimento” per accelerare la ricerca dei riferimenti di un reperto.
44
Capitolo 3
L’interfaccia Web
3.1
Introduzione alla tecnologia Web
La prima pagina Web della storia venne pubblicata il 6 agosto 1991 da un matematico, Tim Bernes Lee, che può a buon merito essere considerato il fondatore del
Web. L’idea ispiratrice di tale evento era l’intenzione di condividere documentazione
scientifica in un formato elettronico indipendente dalla piattaforma utilizzata e di
renderla disponibile a chiunque ne fosse interessato tramite un collegamento di rete.
Il Web nasce quindi come un ideale mezzo per presentare e condividere contenuti
informativi tra persone distanti tra loro migliaia di chilometri, indipendentemente
dal sistema operativo o dal tipo di hardware in loro possesso. Per raggiungere
questo obiettivo il Web si basa sull’uso di una serie di standard e protocolli ideati
appositamente per lo scambio di documenti su reti dati, e di questi i principali sono
il protocollo HTTP e il linguaggio HTML.
L’HTML (sigla di HyperText Markup Language) è un semplice linguaggio che
permette di marcare le singole parti di un documento per descriverne in modo rigoroso il contenuto logico indicandone la funzione (tabelle, elenchi, paragrafi, link,
immagini, etc.) e lo stile (dimensione e colore del carattere da utilizzare, dimensioni
e colori dei bordi, etc.). I documenti scritti in tale linguaggio vengono interpretati da
un apposito software, il browser, che provvede a trasformare le indicazioni contenute
nel documento HTML in elementi visuali per la presentazione grafica dei contenuti.
Il protocollo HTTP (sigla di HyperText Transfer Protocol ) è un insieme di comandi standard per il trasferimento di documenti ipertestuali (come i file HTML)
sulle reti di dati che si basa su un meccanismo di richiesta / risposta: un calcolatore,
che svolge il ruolo di client, effettua le richieste, e dall’altro capo del collegamento
un altro calcolatore, che svolge il ruolo di Web Server, risponde inviando le informazioni richieste. Il processo svolto dal Web Server per la generazione delle risposte
porta a classificare le pagine Web in due tipi di categorie: pagine Web statiche e
45
3 – L’interfaccia Web
pagine Web dinamiche.
Le pagine Web di tipo statico sono il caso più semplice: il contenuto è determinato a priori e non cambia, lasciando all’utente l’unica scelta di visualizzare o
non visualizzare la pagina. In tal caso le operazioni compiute sono relativamente
semplici: il browser, sulla macchina client, invia al Web Server remoto la richiesta di
una determinata pagina, e quest’ultimo risponde cercando nella propria memoria il
file HTML corrispondente alla pagina richiesta e inviandola al client come risposta.
Il browser fa una scansione del file inviato, interpreta le indicazioni contenute, e
visualizza in forma grafica la pagina all’utente. Se durante il processamento del documento si rende necessario scaricare immagini, suoni o altri elementi multimediali,
si generano altre richieste al Web Server a cui seguono le risposte, ognuna contenente
il file necessario. Si noti che il termine “statico” riferito alle pagine Web fa riferimento strettamente al contenuto, indipendentemente da quale esso sia. Questo significa
che una pagina, anche se contiene immagini in movimento, filmati o elementi sonori,
è comunque statica se l’utente non ha avuto modo di operare precedentemente una
scelta su quali di questi elementi visualizzare.
Le pagine Web di tipo dinamico sono il caso di maggiore interesse per lo sviluppo
del progetto ArcheoMap: il contenuto cambia sulla base dei parametri di richiesta
impostati dall’utente. Le tipiche operazioni compiute durante la transazione sono
leggermente più complesse rispetto al caso precedente, e possono variare in alcuni
passi sulla base della soluzione adottata. Come architettura generale, per inviare
il contenuto personalizzato, il Web Server elabora un programma (quello che viene
detto Web application) e interagisce con un database da cui preleva i contenuti da
visualizzare secondo la richiesta.
Nel corso di questo capitolo si vedrà dapprima quale soluzione si è adottata per la
creazione del sito di ArcheoMap, quale l’architettura generale, strumenti e linguaggi
utilizzati e infine si farà una carrellata sulle principali pagine del sito.
3.2
Requisiti per la realizzazione del sito
All’interno del progetto ArcheoMap si vuole realizzare un sito che faccia da interfaccia verso il database. I DBMS hanno infatti un livello di interazione limitato
all’inserimento di istruzioni SQL, il risultato della cui esecuzione compare a schermo
sotto forma strettamente tabellare, senza alcuna presentazione grafica e in modo difficile da capire per i non tecnici in quanto troppo legato all’architettura interna del
database. Per questo è prassi comune realizzare un sito Web che funga da front-end.
Con tale termine si intende un’applicazione che traduca operazioni semplici, come il
click su un menu grafico, su un bottone o la compilazione di un modulo, in istruzioni
SQL da far eseguire al DBMS e ne presenti, in forma il più possibile user friendly,
46
3 – L’interfaccia Web
i risultati, nascondendo all’utente la complessità tecnica dell’interazione con la base
dati.
Detto questo, i requisiti che si intende soddisfare sono, sinteticamente, i seguenti:
• Il sito deve consentire all’utente di “navigare” le informazioni contenute nel
database, e rispettarne l’organizzazione logica dei dati;
• Il sito deve essere progettato con l’obiettivo della chiarezza: l’utente deve
sempre sapere in quale parte del sito si sta trovando e come raggiungere i
contenuti di cui ha bisogno;
• Poiché ogni utente ha permessi diversi, il sito deve limitare l’accesso ai dati ai
soli utenti che ne sono autorizzati, previa autenticazione, e limitatamente alle
sole informazioni consentite;
• Poiché il progetto ArcheoMap è aperto alla comunità internazionale, il sito
deve essere dotato di un’interfaccia multilingua, che consenta ad un utente di
navigare tra i contenuti senza ostacoli linguistici.
3.3
Architettura generale
Nella stesura del progetto di un sito Web dinamico ciò che si cerca di realizzare, per
evitare ridondanze e rendere il prodotto finale facilmente mantenibile ed espandibile,
è la separazione tra Presentation Logic, Business Logic e Data Access Logic.
Con il termine Presentation Logic si intende tutta quella parte dell’applicazione
Web che si occupa della presentazione dei dati all’utente: si tratta quindi del design
dell’interfaccia grafica, della sua usabilità e in generale del modo in cui vengono
presentati i contenuti.
Per Business Logic si intende l’insieme di meccanismi che regolano l’accesso ai
dati, per assicurare che gli utenti compiano solo le operazioni a loro consentite e
sull’insieme di dati a cui possono accedere, rispettando l’organizzazione prevista nel
database.
Con il termine Data Access Logic, infine, si intende l’insieme di meccanismi che
si occupano dell’accesso ai dati e prelevano dal database i risultati delle operazioni
di ricerca e di inserimento.
L’architettura generale che si intende seguire è quella rappresentata in figura
3.1: sull’asse orizzontale si sviluppano i processi, ovvero la sequenza di operazioni
che sono scatenate da un evento generato dall’utente, mentre sull’asse verticale è il
tempo, per cui ciò che è più in basso nel diagramma accade temporalmente dopo
ciò che è più in alto. Il diagramma rappresenta, sotto forma di use case 1 , il modo di
1
Per use case si intende un modello del modo in cui gli utenti interagiscono con il sistema e dei
processi scatenati dalla loro interazione
47
3 – L’interfaccia Web
Interfaccia
Sicurezza
Script
DataBase
Comando
Verifica sicurezza
Elaborazione comando
timeline
Accesso dati
Elaborazione
Visualizzazione
Figura 3.1.
Diagramma temporale di una Web Application
procedere dell’applicazione Web. I passi principali attraverso cui si dipana l’azione
sono i seguenti:
1. L’utente vede dal browser l’interfaccia grafica su cui può operare delle scelte,
ad esempio compilando un modulo o cliccando su un bottone;
2. Il comando dell’utente viene sottoposto ad un controllo sui permessi, per
assicurarsi che esso abbia i privilegi necessari;
3. In caso l’utente sia autorizzato, il comando viene elaborato dal programma
residente sul Web Server che, se necessario, compila una o più istruzioni SQL
per interrogare il database;
4. Il database esegue le istruzioni SQL e restituisce i risultati all’applicazione
Web;
5. Il programma elabora i risultati ottenuti e dispone i contenuti all’interno di
un documento HTML preparato dinamicamente;
6. Il codice HTML viene formattato secondo quanto stabilito dall’interfaccia
grafica e presentato all’utente, che può infine visualizzare quanto richiesto.
48
3 – L’interfaccia Web
Le entità che partecipano al processo, e che compaiono nella figura, sono quattro: l’interfaccia grafica che visualizza i contenuti; un modulo per la sicurezza che
limita l’uso delle sole operazioni consentite; un programma residente sul Web Server
sotto forma di script2 per l’implementazione della logica di funzionamento; infine il
database che raccoglie i dati da elaborare. Nel seguito verranno descritte le prime
tre entità, in quanto l’ultima è già stata esaurientemente dettagliata nel capitolo 2.
3.4
Apache e il linguaggio PHP
Prima di descrivere le componenti logiche in cui è suddiviso il progetto, è bene
introdurre gli strumenti utilizzati durante lo sviluppo.
Per l’implementazione del sito sono necessari un Web Server e un linguaggio
di programmazione in grado di interfacciarsi con esso per l’accesso al database e la
produzione delle pagine. Dal momento che si è scelto, come obiettivo di progetto,
di fare uso unicamente di software open source, come Web Server si usa Apache, e
come linguaggio di programmazione PHP.
Apache è un Web Server sviluppato a partire dal 1995 dalla comunità open
source e giunto nel corso del 2006 alla versione 2.0. Al momento in cui sono iniziati
i lavori sul progetto ArcheoMap la versione disponibile era la 1.3, che viene perciò
presa come riferimento. Nonostante la concorrenza di prodotti proprietari, Apache
è il Web Server più diffuso al mondo, perciò anche la documentazione relativa è
abbondante. Conseguenza diretta del suo successo è il gran numero di estensioni che
permettono ad Apache, per esempio, di interagire con diversi linguaggi di scripting,
tra cui PHP, di implementare internamente dei meccanismi di autenticazione e di
gestire transazioni sicure su canali di comunicazione cifrato.
PHP, acronimo di Personal Home Page è un linguaggio di programmazione inventato da Rasmus Lerdorf nel 1994 e reso di pubblico dominio nel 1995. La versione del linguaggio presa come riferimento per lo sviluppo di ArcheoMap è PHP4.
Si tratta di un linguaggio concepito appositamente per la gestione delle pagine Web
dinamiche, e come tale si caratterizza per la semplicità di integrazione nel codice
HTML e per l’ampio supporto ai diversi DBMS. PHP è un linguaggio di scripting
che si appoggia ad un Web Server, in particolare ad Apache, per l’esecuzione. Lo
scenario di utilizzo del PHP nel contesto di un sito Web dinamico è il seguente:
1. L’utente, tramite il browser, fa richiesta al Web Server di un file avente
estensione .php;
2. Il server cerca nella sua memoria tale file e lo interpreta;
2
Si definisce scriptun programma il cui codice viene interpretato ed eseguito da un altro software.
La programmazione su Web fa uso di script il cui interprete è chiamato dal Web Server
49
3 – L’interfaccia Web
3. Il programma che viene interpretato accede a un database per prelevare i
contenuti e genera del codice HTML in cui sono inseriti i contenuti appena
prelevati;
4. Il Web Server riceve questo codice HTML come risultato dell’esecuzione del
file PHP e invia il codice HTML all’utente come risposta.
A partire dalla release n◦ 4 del linguaggio, quella usata in ArcheoMap, PHP
supporta la programmazione ad oggetti (anche se in verità non in modo completo,
ma comunque sufficiente per le esigenze del caso) e quindi permette di scrivere codice
più pulito e strutturato.
3.5
L’interfaccia del sito
Nel contesto di un sito Internet il termine “interfaccia” indica l’aspetto grafico del
sito, composto da elementi passivi, che non offrono interazione all’utente (per esempio immagini e testi) e da elementi attivi che permettono all’utilizzatore di interagire
ed esprimere delle scelte o effettuare delle richieste (per esempio bottoni, link e moduli da compilare). L’interfaccia riveste quindi, all’interno del progetto, il ruolo di
Presentation Logic: mostra e organizza visualmente i contenuti e fornisce i modi per
richiederli e gestirli. Per mantenere la separazione tra presentazione e gestione dei
contenuti si hanno a disposizione due strumenti: i template e l’uso di fogli di stile,
meglio noti come CSS.
3.5.1
Creazione del template
Nella realizzazione dell’aspetto grafico di un sito Internet non c’è limite alla fantasia
dei designer, tuttavia considerazioni di carattere pratico e di immediatezza d’uso
verso l’utente hanno, con il tempo, portato alla definizione di alcune linee guida
da seguire per realizzare un sito usabile. Una di queste consiglia di mantenere
l’interfaccia grafica del sito il più omogenea possibile nel passaggio da una pagina
all’altra: in questo modo l’utente, abituatosi ai colori e alla disposizione delle aree
funzionali, si sente più a suo agio nella navigazione e gli risulta più facile capire dove
rivolgere lo sguardo alla ricerca di ciò che gli interessa.
Questo tipo di considerazione porta a stabilire, per l’aspetto grafico, un modello
comune a tutte le pagine del sito, ovvero un template. Il template di un sito è la
descrizione del suo aspetto generale in termini di disposizione dei contenuti nello
spazio della finestra del browser e del loro ruolo funzionale.
Esistono numerosi “motori di template”, piattaforme di sviluppo che permettono
la generazione di modelli per i siti Web. Tra le alternative open source si è preferito
50
3 – L’interfaccia Web
utilizzare, per via della sua flessibilità e semplicità, Savant2, totalmente scritto in
PHP e quindi ben integrabile con il resto del progetto.
Il modello che si è pensato di utilizzare per il sito di ArcheoMap è un classico
layout a tre colonne, con intestazione e fondo pagina. Nella figura 3.2 è mostrata
Figura 3.2.
Il modello usato per la costruzione del sito di ArcheoMap
un’immagine del modello adottato. Nella parte alta di ogni pagina c’è un’intestazione che visualizza il titolo e il menu di navigazione che punta alle sezioni principali
del sito: home page, mappe, elenco dei progetti, login/logout, link a siti associati
e una pagina di riconoscimenti. La parte mediana è divisa in tre pannelli: uno
centrale, più ampio, riservato alla presentazione dei contenuti veri e propri (vuota
nel caso della figura), e due pannelli laterali più stretti, di cui quello di sinistra per
l’accesso alle funzioni specifiche di ogni sezione, e quello di destra per la visualizzazione di una struttura ad albero che mostra all’utente in quale progetto e in quale
località sta operando in quel momento. Lo spazio a fondo pagina è riservato al logo
di ArcheoMap e a due link per testare l’aderenza agli standard del Web.
Per sfruttare i vantaggi offerti in termini di manutenibilità e chiarezza dal paradigma della programmazione ad oggetti, si è definita una classe di template chiamata
tpl, che definisce attributi e metodi generali della pagina. Nel diagramma 3.3 è ri51
3 – L’interfaccia Web
tpl
−titolo
−nome_menu
+pannello_sx()
+pannello_centro()
+pannello_dx()
+javascript()
+query()
+login()
+utente()
Figura 3.3.
Diagramma della classe di template “tpl”
portato lo schema della classe “tpl”. Come si può vedere, gli attributi definiti sono
essenzialmente due: “titolo”, in cui viene specificato di volta in volta il titolo di
ogni pagina, e “nome menu” in cui è indicato il tipo di menu da caricare pagina per
pagina, coerentemente con le operazioni che si intende svolgere sul contenuto. I
metodi messi a disposizione sono:
• “pannello sx()”: disegna il pannello di sinistra della pagina, contenente il
menu e, opzionalmente, dei bottoni per l’accesso alle funzioni amministrative;
• “pannello centro()”: disegna il pannello centrale, in cui sono visualizzati i
contenuti;
• “pannello dx()”: disegna il pannello di destra con il menu ad albero in
cui viene indicata, in modo gerarchico, la posizione attuale dell’utente tra
le località e i progetti che sta visitando;
• “javascript()”: include nel foglio HTML le istruzioni JavaScript per aggiungere effetti grafici alle pagine;
• “query()”: dal momento che molte operazioni compiute durante la navigaziona del sito richiedono uno o più accessi al database, questo metodo mette a
disposizione il codice per avviare la connessione al DBMS, eseguire la query,
prelevare i risultati e chiudere la connessione;
• “login()”: questo metodo serve per testare se l’utente che sta visualizzando
una pagina ha già effettuato login oppure no. Se si, nel menu di navigazione
52
3 – L’interfaccia Web
in alto stampa la scritta “logout”, altrimenti stampa la scritta “login” e il link
per effettuare l’autenticazione;
• “utente()”: stampa nella parte in alto a destra della pagina, subito sopra il
menu di navigazione, il nome dell’utente correntemente loggato3 .
Questa classe costituisce la base su cui sono create tutte le pagine del sito. In
particolare, ogni pagina è a sua volta una classe, che estende la classe base “tpl” e ne
sovrascrive i metodi per adattarli alle necessità proprie del contenuto da visualizzare
e gestire. In termini di progettazione si realizza il diagramma di figura 3.4 dove
progetto.php
località.php
progetti.php
reperti.php
reperto.php
tpl
scheda_min.php
diario.php
articolo.php
Figura 3.4.
immagine.php
galleria.php
Esempio di diagramma delle classi per il sito Web di ArcheoMap
compaiono le principali pagine del sito di ArcheoMap, ognuna collegata tramite una
freccia alla classe di template ad indicare appunto che ognuna di esse è una classe
figlia di “tpl”.
3
Per brevità, si userà nel corso del testo l’inglesismo “loggarsi” per intendere l’azione di un
utente che effettua log-in, ovvero si autentica per effettuare l’accesso al sito
53
3 – L’interfaccia Web
3.5.2
CSS
Se la realizzazione del template permette di definire la “forma” di ogni pagina,
specificando di quante parti è composta e la relativa posizione nello spazio, tutto ciò
che riguarda lo stile, quindi i colori, la dimensione dei caratteri, i bordi e gli sfondi
degli elementi grafici che compaiono a schermo, sono definiti nel CSS.
Il termine CSS è abbreviazione di Cascading Style Sheet, che in italiano può
essere reso come “fogli di stile”, e identifica lo standard definito dal W3C4 nel 1996
per descrivere la resa grafica di una pagina HTML. La sintassi di un CSS è composta
da una sequenza di istruzioni in cui, per ogni elemento, è possibile specificare una
serie di attributi riguardanti il suo aspetto. È inoltre possibile creare delle categorie
che racchiudono più elementi con un aspetto comune.
Una delle caratteristiche più apprezzate dei CSS è la possibilità di poter raggruppare tutte le istruzioni che li formano in un file esterno alla pagina. Questo consente
di rendere il codice del template più snello e pulito, in quanto le parti riguardanti
la resa grafica, quindi non strettamente inerenti alle funzioni definite nel template,
sono separate e raccolte in un documento a parte.
Ad esempio, nel layout adottato per ArcheoMap si è definito tramite CSS che
lo sfondo della pagina deve essere bianco, con i contenuti scritti in nero; che i menu
laterali devono essere in caratteri bianchi su sfondo azzurro; che i bottoni e gli
elementi di input devono essere di colore grigio, e che le etichette dei campi di un
modulo che è obbligatorio compilare siano in rosso.
Con l’accoppiata template e CSS si è ottenuta la separazione dell’aspetto grafico
dai contenuti, obiettivo che ci si era prefissi. Se infatti un designer professionista
desiderasse intervenire per cambiare la grafica del sito, tutto ciò che dovrebbe fare
sarebbe modificare il template e il CSS (soli due file!), e l’interfaccia del sito vi si
adatterebbe automaticamente.
3.6
Business Logic
Nel concetto di Business Logic è raccolta tutta la parte del sito che gestisce gli input
dell’utente, in modo del tutto trasparente, e genera una risposta facendo accesso al
database ed elaborando le informazioni ottenute per presentarle in un file HTML
leggibile dal browser. Ogni pagina PHP di cui è composto il sito è a tutti gli effetti
una Web application a sé stante che esegue tutte le operazioni necessarie e gestisce,
ad alto livello, l’accesso alla base dati.
4
W3C è il consorzio super partes che si occupa della definizione degli standard per le tecnologie
del Web
54
3 – L’interfaccia Web
3.6.1
Le Web application
Quando si parla di Web application si intende l’insieme di codice, interpretato dal
Web Server, che opera esattamente come un programma tradizionale: a fronte di
uno o più input da parte dell’utente, esegue delle elaborazioni e produce un output.
I modi in cui è previsto l’utente interagisca con una Web application in ArcheoMap sono sostanzialmente due: i link parametrizzati e i form.
I link parametrizzati sono link che si presentano nella forma:
/localita.php?prj=1&loc=3
Al nome della pagina da richiamare, nell’esempio “localita.php”, segue un punto
interrogativo (“?”) e poi dei parametri predefiniti passati come coppie nome parametro / valore. Nell’esempio si passano alla pagina referenziata (che è a sua volta
una Web application) i due parametri “prj”, con valore 1, e “loc” con valore 3. La
pagina richiamata legge questi parametri e in base ad essi elabora dei dati. Il link
di esempio riportato apre la pagina che mostra i dettagli della località avente codice
3 nel database e che fa parte del progetto 1.
I form sono dei moduli che possono essere compilati dall’utente tramite l’inserimento di caratteri in uno o più campi di input e con un pulsante di invio. Quando
l’utente clicca su tale pulsante, i parametri inseriti vengono inviati dal browser al
Web Server, che richiama il codice PHP delegato alla loro elaborazione.
Tutto il codice deputato all’elaborazione delle pagine è scritto all’interno dei
metodi definiti dalla classe base “tpl” (vedasi figura 3.3), la cui implementazione
effettiva dipende dal contesto.
Nel caso più generico, l’algoritmo seguito dalla Web application è il seguente:
1. Legge i parametri inviati dall’utente tramite un link o un form;
2. Controlla che l’utente abbia i permessi necessari ad eseguire l’operazione richiesta. Se è cosı̀ prosegue, altrimenti mostra un messaggio di avvertimento e
termina l’esecuzione;
3. Se è richiesta una lettura da database:
(a) Crea la query in SQL per interrogare il DBMS;
(b) Esegue la query;
(c) Se il database ha restituito dei risultati, li formatta in codice HTML per
presentarli e termina l’esecuzione;
(d) Se il database non ha restituito risultati, genera un messaggio di errore;
4. Se è richiesto l’inserimento di nuovi dati nel database:
55
3 – L’interfaccia Web
(a) Controlla che i campi siano stati compilati correttamente. Se non è cosı̀ ripresenta la pagina per permettere all’utente di modificare le informazioni,
altrimenti prosegue;
(b) Crea la query in SQL per richiedere un inserimento al DBMS;
(c) Esegue la query;
(d) Se non si sono verificati errori, viene presentata una pagina contenente
un messaggio di conferma dell’avvenuto inserimento;
5. Se è richiesta la cancellazione di dati già presenti nel database:
(a) Mostra un messaggio di conferma, per essere sicuri che l’utente abbia
veramente intenzione di cancellare i dati scelti;
(b) Crea la query in SQL per richiedere la cancellazione al DBMS;
(c) Esegue la query;
(d) Se non si sono verificati errori, viene presentata una pagina contenente
un messaggio di conferma dell’avvenuta cancellazione.
3.6.2
PEAR DB, l’interfaccia al database
PEAR sta per PHP Extension and Application Repository ed è una sorta di biblioteca per programmatori PHP che raccoglie e rende disponibili a tutti gli interessati
un’ampia serie di classi e di funzioni che risolvono molti problemi in cui spesso ci si
imbatte durante lo sviluppo di un programma PHP. In questo modo si può disporre
di codice già scritto e testato dalla comunità open source che può essere da subito
integrato nell’applicazione abbreviando notevolmente i tempi.
Tra i vari pacchetti presenti su PEAR è risultato molto utile, ai fini del progetto
ArcheoMap, PEAR DB, un layer di astrazione che consente di accedere ai database
indipendentemente dal DBMS utilizzato. Se è vero che come base di sviluppo di
ArcheoMap si è scelto di utilizzare PostgreSQL, è altresı̀ buona norma cercare di
mantenere il front-end, in altre parole il sito, slegato, per quanto possibile, dall’implementazione del DBMS sottostante. La ragione di ciò è presto detta: se nel futuro
si desiderasse sostituire PostgreSQL con altro prodotto analogo, è meglio poterlo
fare con il minor numero di modifiche possibile. La progettazione a componenti utilizzata lungo tutto lo sviluppo di ArcheoMap è abbastanza modulare da consentire
questo e PEAR DB occupa un ruolo importante.
Dopo aver impostato un file di configurazione in cui vengono scritti alcuni parametri fondamentali per la connessione al DBMS (indirizzo, porta su cui è in ascolto,
username, password, nome del database), si è provveduto a scrivere tutto il codice
delle Web application utilizzando le sole funzioni di PEAR DB per creare e chiudere
56
3 – L’interfaccia Web
connessioni, eseguire query, estrarre i risultati e gestire eventuali messaggi di errore.
Per il suo ruolo di “mediazione”, si può affermare che dal punto di vista progettuale
PEAR DB agisce come un connettore tra la Business Logic e la Data Access Logic.
3.6.3
Gestione della sicurezza
Tra i requisiti di progetto del sito Web di ArcheoMap vi è la richiesta che il contenuto
di una località, quindi il suo diario di scavo, la sua galleria e il suo catalogo di
reperti, sia, qualora ritenuto necessario dal capo progetto, ad accesso riservato: solo
gli utenti assegnati alla località devono poter leggere e inserire articoli, immagini o
reperti. Il problema della sicurezza dei dati si risolve con il garantire l’autenticazione
e l’autorizzazione. Sebbene i due termini siano spesso, impropriamente, considerati
sinonimi, rappresentano in realtà due aspetti ben distinti della questione.
Con “autenticazione” si intende il processo tramite il quale un software verifica
che l’utente con cui sta interagendo sia effettivamente chi egli sostiene di essere. Con
“autorizzazione” si intende invece l’insieme di regole per l’accesso ai dati. Va da sé
che l’autorizzazione può essere perseguita con successo solo dopo che un utente è
stato correttamente autenticato.
Adottando una prassi ormai comune tra i siti Web dinamici che vogliono garantire la riservatezza dei dati, si è scelto di mantenere diviso il software che si occupa
dell’autenticazione dalla parte che si occupa dell’autorizzazione. L’autenticazione
è sostanzialmente affidata ad una coppia username e password : l’utente, prima di
accedere alle parti riservate del sito, deve dimostrare la propria identità scrivendo la
giusta combinazione di username e password riservate. Se il test viene passato con
successo, l’utente è considerato autenticato e può procedere alla fase di autorizzazione: ogni volta che richiede una risorsa, sono consultati i suoi permessi contenuti
nella tabella “autorizzazione” del database e sulla base di questi si decide se consentire o meno l’operazione. L’autenticazione viene quindi fatta una volta soltanto,
mentre l’autorizzazione accompagna ogni accesso ai dati. Prima di vedere come
viene gestita l’autenticazione con ArcheoMap, è necessaria una breve dissertazione
sul protocollo HTTP e sulle sessioni.
Cookie e sessioni
Il protocollo HTTP ha i suoi pregi nella semplicità ed efficenza nella gestione dei
documenti ipertestuali come i file HTML, ma ha il difetto di essere un protocollo
stateless, senza stati. Un protocollo di comunicazione senza stati esegue le singole
operazioni come unità scollegate le une dalle altre, vale a dire che ogni richiesta
viene portata a termine indipendentemente dal risultato delle richieste precedenti.
Per questa ragione il protocollo HTTP non gestisce nativamente l’autenticazione e
57
3 – L’interfaccia Web
l’autorizzazione, perché ad ogni richiesta è impossibile sapere se l’utente si è già
autenticato oppure no.
Per ovviare a questa mancanza, fin dagli albori di Internet è valso l’uso dei
cookie. Un cookie è, nel gergo delle comunicazioni di rete, un piccolo file di testo,
delle dimensioni di pochi byte, che viene creato dal Web Server e memorizzato nel
computer dell’utente tramite il browser. All’interno dei cookie sono scritte poche
informazioni utili al Web Server per tener traccia delle precedenti richieste. Ad
esempio il Web Server, se riconosce la correttezza di username e password di un
utente, crea un cookie in cui scrive un codice di identificazione e lo fa memorizzare
dal browser. Nelle richieste successive il Web Server richiede al browser di inviargli
il contenuto del cookie e se questo corrisponde a quanto atteso si ha la prova che
l’utente è autenticato.
I cookie hanno una scadenza, oltre la quale non sono più considerati validi. Il
periodo di tempo che intercorre tra il momento in cui l’utente fa login e viene autenticato e il momento in cui i cookie scadono prende il nome di “sessione”. Durante
la sessione l’utente viene considerato autenticato e tutte le operazioni svolte sono
sottoposte regolarmente al processo di autorizzazione. Quando la sessione scade
l’utente la deve rinnovare effettuando il login. In questo modo viene creata una
struttura a stati che opera al di sopra di un protocollo senza stati.
Modulo Perl di Apache per l’autenticazione
Il software utilizzato per implementare l’autenticazione in ArcheoMap è Apache mod
perl. Si tratta di un’estensione al Web Server Apache a cui aggiunge un interprete Perl, un linguaggio di scripting che gode molta fama presto gli amministratori
di sistema Linux per la creazione di script di gestione. Apache mod perl consente
al programmatore di creare dei moduli specifici per aggiungere funzionalità direttamente al Web Server. Si è quindi scritto un modulo per far gestire ad Apache
l’autenticazione degli utenti e creare due cookie: in uno è contenuto un codice identificativo che permette di riconoscere il cookie come appartenente ad ArcheoMap, e
un secondo codice che identifica in modo univoco l’utente autenticato. Il modulo è
programmato per entrare in funzione quando si inviano username e password dalla
pagina login.php e svolge le seguenti operazioni:
1. Si connette al database e verifica dalla tabella “utente” se username e password segreta corrispondono;
2. Qualora il test precedente abbia risultato negativo lo script termina con un codice di errore e Apache non processa la richiesta. Dal punto di vista dell’utente,
questi vede il browser tornare alla pagina di login senza venire autenticato;
3. Se il test su username e password è andato a buon fine vengono generati i due
58
3 – L’interfaccia Web
cookie di ArcheoMap di cui si è detto poco sopra. L’utente vede ricaricarsi la
pagina di login ma, al posto del form si trova un messaggio di benvenuto. Da
questo momento ha inizio la sessione e l’autenticazione è effettuata.
Quando l’utente effettua il logout, il Web Server cancella i cookie e la sessione
termina.
Autorizzazione
L’autorizzazione riguarda strettamente il controllo di accesso ai dati e per questo è
distribuita nelle pagine e non centralizzata. Per controllare quale tipo di operazioni
possono essere effettuate e quali no, si fa riferimento alla tabella “autorizzazione” e
alla tabella “permesso” del database. In quest’ultima, in particolare, sono contenuti
i tipi di permesso che è possibile assegnare ad un utente di ArcheoMap:
• scrittura diario: un utente che ha questo tipo di permesso può inserire nuovi
articoli nel diario di scavo;
• lettura diario: un utente che ha questo tipo di permesso può leggere gli
articoli correntemente presenti nel diario di scavo;
• scrittura galleria: un utente che ha questo tipo di permesso può inserire
nuove immagini nella galleria fotografica;
• lettura galleria: un utente che ha questo tipo di permesso può vedere le
immagini correntemente inserite nella galleria;
• capo progetto: un utente che ha questo tipo di permesso ha implicitamente
l’autorizzazione a leggere e scrivere nei diari di scavo e nelle gallerie di tutte
le località che fanno parte del progetto da lui controllato; può creare nuove
località nell’ambito del suo progetto; può creare nuovi progetti; può infine
gestire i permessi degli utenti associati al progetto e delle località che ne fanno
parte;
• direttore scavo: un utente che ha questo tipo di permesso ha implicitamente
l’autorizzazione a leggere e scrivere nei diari di scavo e nelle gallerie della
località da lui controllata; può gestire i permessi degli utenti associati alla sua
località;
Ogni file PHP, nel momento in cui deve processare una pagina, richiama una
funzione di controllo, la procedura “getPerm()”, la quale restituisce un valore booleano, vero o falso. Se l’utente ha il permesso richiesto restituisce “vero”. Altrimenti
restituisce “falso”. Qualora la località in cui si sta navigando sia ad accesso pubblico, la “getPerm()“ restituisce automaticamente “vero” per ogni richiesta di un
59
3 – L’interfaccia Web
permesso di lettura, indipendentemente da chi sia l’utente; restituisce “falso” per le
richieste di scrittura. Il valore ritornato dalla “getPerm()” viene quindi gestito dal
codice PHP che l’ha richiesto per elaborare in modo opportuno la pagina o mostrare
messaggi d’errore nel caso in cui l’accesso non sia consentito.
3.6.4
L’interfaccia multilingua
Il pubblico fruitore di ArcheoMap può essere di qualsiasi nazionalità, non deve quindi
essere legato ad una specifica lingua. Per questo nei requisiti si è richiesto esplicitamente di predisporre l’interfaccia del sito in modo da poterla tradurre facilmente in
altre lingue, oltre all’Italiano.
La soluzione adottata è predisporre dei file di dizionario contenenti la traduzione di ogni etichetta di testo e di ogni bottone dell’interfaccia. Si è creata una
cartella “lang” al cui interno sono tanti file quante sono le lingue in cui è tradotta
l’interfaccia. Ogni file ha un nome che segue la convenzione:
archeo [codice lingua]
Ad esempio il file contenente la traduzione dell’interfaccia in italiano si chiama
“archeo it”; il file con la traduzione dell’interfaccia in inglese si chiama “archeo en”
e cosı̀ via.
All’interno del codice PHP il testo di ogni etichetta, menu e bottone che fa
parte dell’interfaccia è identificato da un codice. Invece di scriverne direttamente il
testo, si richiama la funzione “traduci” che si occupa di cercare nel file corretto la
traduzione dell’etichetta corrispondente al codice.
Per decidere in quale lingua va tradotta l’interfaccia, si seguono due strategie
distinte, a seconda che il visitatore del sito sia un utente registrato oppure un utente anonimo: se l’utente è registrato, nella tabella “utente” è riportato il campo
“lingua” in cui è memorizzata la lingua di appartenenza di una persona e sulla
base del valore di questo campo si usa per la traduzione il file opportuno. Se invece
l’utente è un visitatore anonimo, si usa per default la lingua del browser.
3.7
Le pagine del sito
Viene ora presentata, nel seguito, una carrellata delle principali pagine del sito di
ArcheoMap seguendo un ideale percorso compiuto da un utente che intenda esplorare le potenzialità del progetto. Per ognuna di esse verrà data una descrizione
dell’interfaccia e delle operazioni compiute sul database, qualora ve ne siano.
60
3 – L’interfaccia Web
Figura 3.5.
3.7.1
Schermata della pagina di login
Pagina di login
Da questa pagina, di cui viene data un’immagine nella figura 3.5 è data la possibilità
all’utente di effettuare il login, ossia di farsi riconoscere dal sistema e acquisire le
credenziali necessarie per navigare nelle altre pagine del sito. Il modello utilizzato
è, naturalmente, il template “tpl” adoperato per tutte le altre pagine, ma in questa
non sono presenti menu laterali. Questo significa che i metodi “pannello sx()”
e “pannello dx()” sono ridefiniti vuoti, non disegnano nulla. La grafica è molto semplice: in centro è presentato un form composto da due campi di testo in
cui l’utente che intende loggarsi scrive il proprio username e la propria password.
Quando l’utente preme il bottone “Login” i dati sono spediti al Web Server Apache e intercettati, come descritto nella sezione 3.6.3 dal modulo Perl. Se l’utente
è riconosciuto, viene impostata la sessione, memorizzati i cookie e infine mostrato
un messaggio di benvenuto all’utente, che da ora in avanti può proseguire con la
navigazione. Altrimenti viene mostrato un messaggio di errore.
61
3 – L’interfaccia Web
3.7.2
Elenco dei progetti
La pagina progetti.php, mostrata nella figura 3.6 permette di accedere all’elenco
Figura 3.6.
Schermata della pagina con l’elenco dei progetti
dei progetti e delle località ospitati nel database di ArcheoMap. Il pannello di destra
è vuoto, mentre nel pannello di sinistra è mostrato un menu “Crea nuovo progetto”
da cui un utente con i privilegi di capo progetto può creare un nuovo progetto da
inserire in ArcheoMap. Tale menu non viene fatto comparire qualora l’utente non
abbia i permessi sufficienti. Nella parte centrale della pagina è mostrato il contenuto,
in forma tabellare. La tabella viene generata dinamicamente quando si fa richiesta
di caricare la pagina: il codice PHP del metodo “pannello centro()” esegue una
query in SQL sulle tabelle “progetto“ e “località” del database per recuperare
l’elenco di tutti i progetti e, per ognuno di essi, di tutte le località, gestite al momento
da ArcheoMap.
La tabella è organizzata in tre colonne: nella colonna di sinistra è il nome del
progetto; nella colonna di centro è una breve descrizione e l’elenco delle località che
ne fanno parte; nella colonna di destra infine sono mostrati dei pulsanti con funzione
amministrativa per cancellare un progetto o per modificarne i dati associati, anche
62
3 – L’interfaccia Web
questi attivati solo per utenti che hanno permesso di capo progetto. Le località che
sono ad accesso riservato sono indicate da una piccola icona di un lucchetto (nell’esempio Pompei). I nomi dei progetti e delle località celano dei link parametrizzati:
l’utente, cliccando su di essi, viene rediretto ad una pagina contenente i dettagli per
l’elemento scelto.
3.7.3
Dettagli della località
Dalla pagina riportata nella figura 3.7 si leggono le informazioni relative ad una
località, e che sono contenute nella tabella “località” del database.
Figura 3.7.
Schermata della pagina con i dettagli di una località
La grafica di questa pagina sfrutta tutte e tre i pannelli messi a disposizione
dal template. Nel pannello di sinistra vi è il menu principale: nella parte alta i
link per accedere alle sezioni con l’elenco dei reperti, il diario di scavo e la galleria
fotografica. Seguono poi dei link a carattere amministrativo, che sono nascosti ai
normali utenti, e visibili solo per capo progetto e direttore scavo: un link per la
gestione del personale impiegato nella località, e due bottoni “Cancella” e “Modifica”
per cancellare la località oppure per modificarne le informazioni associate.
63
3 – L’interfaccia Web
Un bottone al fondo della colonna di sinistra permette di scegliere se la località
deve essere esportata sul palmare dell’utente oppure no. Il testo del bottone cambia
sulla base dello stato corrente: se la località è già selezionata per l’esportazione
su palmare (come è il caso dell’esempio in figura) allora il bottone permette di
disabilitare tale opzione; viceversa, se la località non è scelta per l’esportazione, il
testo del bottone cambia per consentire all’utente di abilitarla. Quando il bottone
viene premuto il codice della Web Application in esecuzione sul server scrive (o
cancella) un record dalla tabella “esportazione” del database e ricarica la pagina
per riflettere le modifiche apportate.
Il pannello di centro mostra il contenuto in forma tabellare. Nella colonna di
sinistra sono i nomi dei singoli campi e nella colonna di destra le informazioni vere
e proprie. Per la generazione dinamica di questa tabella il codice PHP attivato al
momento del caricamento della pagina prende i parametri passati nel link (visibili
nella barra degli indirizzi del browser ) e in base a questi crea una query per interrogare il database sulla località scelta. I campi sono quindi formattati in HTML per
visualizzare i dati cosı̀ come mostrato nella figura.
Infine il pannello di destra mostra una struttura ad albero che indica visivamente
all’utente in quale progetto e in quale località si trova attualmente. Il progetto e la
località attuali sono scritti in blu scuro su fondo azzurro, mentre le rimanenti sono
scritte in bianco su sfondo azzurro.
Pressoché identica è la pagina che mostra i dettagli per il progetto, su cui perciò
non ci si soffermerà oltre.
3.7.4
Inserimento di una nuova località
L’operazione di inserimento di una nuova località in un progetto è riservata ai soli
utenti che hanno privilegi di capo progetto per il progetto in cui la nuova località va
inserita. Se questo requisito è soddisfatto, dalla pagina con i dettagli del progetto c’è
un pulsante “Nuova località” che apre la schermata di figura 3.8 da dove è possibile
effettuare l’inserimento.
Lo spazio della pagina è dominato da un lungo form da compilare, costituito
da un elenco di campi di testo al cui interno si devono inserire le informazioni
richieste dalle etichette a fianco. In rosso sono segnalati i campi obbligatori. Al
fondo del form, non visibile nell’immagine per questioni di spazio, c’è il bottone che
scatena l’evento di inserimento. Quando questo bottone viene premuto, i dati del
form sono inviati al Web Server, il quale esegue il codice PHP contenuto nella Web
application. Viene costruita una query di inserimento che aggiunge un nuovo record
nella tabella “località”. Se l’inserimento è andato a buon fine e non si generano
errori, la località viene inserita nel database e collegata al progetto corrente. Poichè
è obbligatorio che una località abbia un proprio direttore scavo (vedasi figura 2.20:
la relazione “direzione” è a partecipazione obbligatoria), di default viene assegnato
64
3 – L’interfaccia Web
come direttore scavo lo stesso capo progetto. Starà poi a quest’ultimo, se lo ritiene
necessario, andare nella pagina di gestione degli utenti e assegnare un nuovo direttore
scavo.
Figura 3.8.
3.7.5
Schermata della pagina per la creazione di una nuova località
Diario si scavo
Se alla pagina dei dettagli della località si clicca sul link “Diario di scavo” la pagina
che viene mostrata è quella di figura 3.9. Qui è possibile leggere il diario di scavo
scritto mano a mano dagli utenti che collaborano alla località. Nel menu di sinistra
sono mostrati dei link che consentono di spostarsi verso le altre sezioni di interesse
o di ritornare alla località, e un bottone per inserire una nuova nota al diario. Nel
menu di destra è mostrato lo schema ad albero del sito e un form che consente di
ricercare termini nel testo degli articoli.
Nella parte centrale sono elencati gli articoli contenuti nel diario di scavo al
momento. Per ottenere questo elenco il codice PHP genera una query che prende dal link parametrizzato l’identificatore della località corrente (parametro “loc”
nella barra degli indirizzi) e ne usa il valore come chiave di ricerca nella tabella
“articolo”. Vengono estratti tutti gli articoli che fanno riferimento alla località
65
3 – L’interfaccia Web
Figura 3.9.
Schermata della pagina del diario di scavo
indicata e ordinati per data. Il risultato della query viene formattato come si vede
nell’immagine e presentato all’utente.
3.7.6
Inserimento nuovo articolo
Se l’utente preme sul pulsante “Nuova Nota” accede alla pagina mostrata nella figura
3.10 da cui può inserire un nuovo articolo nel diario di scavo.
Nella parte sinistra è presente il consueto menu di navigazione, che permette di
spostarsi verso altre sezioni del sito: elenco dei reperti, diario di scavo e galleria
fotografica.
Nella parte destra, sopra la struttura ad albero che indica la posizione corrente
all’interno del sito, è disposto un elenco di link utili per la gestione degli articoli di
diario inseriti da un singolo utente: “Upload” consente di caricare un file di testo
da utilizzare come allegato dell’articolo; “Ultime note visibili” permette di caricare
l’elenco degli ultimi articoli resi visibili dall’utente; “Note non visibili” permette di
caricare l’elenco degli ultimi articoli resi non visibili dall’utente; “Note eliminate”
66
3 – L’interfaccia Web
Figura 3.10.
Schermata della pagina per l’inserimento di un nuovo articolo di diario
mostra l’elenco degli ultimi articoli cancellati dall’utente ed eventualmente di ripristinarli. Infatti, per motivi di sicurezza e conservazione dei dati, gli articoli eliminati
dal diario non vengono materialmente cancellati dal database ma sono contrassegnati
con un flag e non più visualizzati. Infine, il link “Abbreviazioni da tastiera” visualizza
un breve help in linea in cui è mostrato il legame tra le funzioni della pagina e una
scorciatoia da tastiera per velocizzarne l’uso.
Al centro della pagina, il contenuto è rappresentato dal form per l’inserimento
della nuova nota. L’utente può inserire il titolo e il corpo dell’articolo nei due campi
di testo al centro. Il campo con il nome dell’autore è automaticamente precompilato
con il nome dell’utente corrente. Per rendere l’interfaccia il più famigliare possibile
agli utenti, si è modellato l’aspetto del form cosı̀ da assomigliare agli editor di testo di
comune utilizzo sui PC, con i loro formalismi grafici ormai riconosciuti per accedere
alle funzioni implementate:
• Il correttore ortografico: utilizza il dizionario multilingue open source myspell
per trovare eventuali errori di battitura nel testo ed evidenziarli;
• Pulsanti per cambiare l’aspetto di una parte del testo mettendolo in corsivo
67
3 – L’interfaccia Web
oppure in grassetto;
• Pulsanti per cambiare la formattazione del testo: allineamento a sinistra,
allineamento a destra, centrato oppure giustificato;
• Pulsanti per salvare l’articolo corrente, per cancellarlo o per effettuare ricerche.
Un checkbox al fondo della pagina permette all’autore di decidere se l’articolo deve
essere visibile a tutti oppure no dopo averlo salvato.
Quando l’utente preme il bottone a forma di dischetto per salvare la nota appena
inserita, il contenuto del form viene inviato al Web Server e da questo al codice PHP
della pagina che si occupa di generare una query per l’inserimento nella tabella
“articolo”.
3.7.7
Galleria fotografica
Dalla pagina “galleria.php” si accede alla galleria fotografica associata alla località, che si presenta come in figura 3.11.
Figura 3.11.
Schermata della pagina con la galleria fotografica
68
3 – L’interfaccia Web
I pannelli di sinistra e di destra ospitano, come nel resto del sito, i menu contestuali per la navigazione e l’accesso alla funzione di inserimento di una nuova
immagine. Il contenuto è l’insieme di miniature delle immagini della galleria, organizzate in una griglia. Per generare la pagina, il codice PHP esegue una query
che seleziona, tra tutte le immagini presenti nella tabella “immagine”, quelle che
corrispondono alla località corrente, genera le miniature se ancora non esistono, e
crea l’interfaccia. Ogni miniatura nasconde un link parametrizzato che, se cliccato,
apre la pagina con i dettagli dell’immagine.
3.7.8
Dettagli immagine
Se l’utente decide di visualizzare i dettagli di un’immagine, clicca sulla miniatura
corrispondente nella galleria e gli viene aperta una pagina simile a quella di figura
3.12
Figura 3.12.
Schermata della pagina con i dettagli dell’immagine
Al centro viene presentata l’immagine selezionata, con sotto il nome del file e la
descrizione. Se l’utente desidera visualizzare l’immagine in una dimensione differente, è sufficiente che operi una scelta dal menu a tendina immediatamente sopra alla
69
3 – L’interfaccia Web
foto. Se invece si desidera vedere l’immagine nelle sue dimensioni reali, è sufficiente
cliccare sul link “Vedi originale”. Si fa notare che, al momento dell’inserimento di
una nuova immagine, l’utente ne deve solo specificare il file e la descrizione. Le
miniature e lo scalamento a dimensioni differenti da quella reale sono gestite in toto
dal codice PHP lato server che procede alla creazione dei file necessari la prima volta
che questi vengono richiesti. Inoltre, per venire incontro alle esigenze dei semplici
visitatori, si è inserita una funzione di carrellata che permette di vedere tutte le immagini in sequenza, con l’intervallo tra un’immagine e la successiva programmabile
dall’utente in 2, 4, 6, 8 o 10 secondi.
Nel pannello di sinistra della pagina sono presenti tre pulsanti per l’amministrazione dell’immagine correntemente visualizzata (operazioni di cancellazione e
modifica) oppure per l’inserimento di una nuova. Se l’utente che sta visualizzando
l’immagine corrente non ne è l’autore stesso o non ha i privilegi di capo progetto o
direttore scavo, tale pannello non viene visualizzato.
3.7.9
Elenco dei reperti
Nella figura 3.13 è mostrata la schermata della pagina con l’elenco dei reperti
associati ad una località.
Il contenuto è presentato sotto forma di una tabella a quattro colonne. La prima colonna da sinistra mostra il nome del reperto; la seconda colonna mostra la
data di inserimento; la terza colonna riporta la data di ultima modifica; l’ultima
colonna a destra contiene un pulsante di amministrazione per cancellare il corrispondente reperto. Tale pulsante viene mostrato solo nel caso in cui un utente
abbia effettivamente i privilegi per compiere l’operazione (l’autore del reperto e gli
utenti capo progetto e direttore scavo che hanno come ambito di competenza la
località corrente).
Se un utente clicca sul nome del reperto viene aperta la pagina con i dettagli dello
stesso; se clicca sul link “Inserisci nuovo reperto” apre la pagina per l’inserimento di
un nuovo reperto.
3.7.10
Dettagli reperto
La pagina con i dettagli dei reperti si presenta come in figura 3.14. Il contenuto, a
centro pagina, ne mostra dapprima le informazioni di contorno (nome del reperto,
data di inserimento, autore, coordinate). Questi dati sono prelevati dal database
con una query che seleziona, tra i reperti presenti nella tabella “reperto”, quello
che corrisponde alla chiave di ricerca selezionata.
Subito sotto vengono mostrati, in forma tabellare, i riferimenti a cui il reperto
è legato. La tabella è divisa in quattro colonne: la prima a sinistra dice il tipo di
riferimento (galleria fotografica, nota da diario, scheda ministeriale); nella seconda
70
3 – L’interfaccia Web
Figura 3.13.
Schermata della pagina con l’elenco dei reperti
colonna è posta la data di inserimento del riferimento; la terza colonna porta il
nome del responsabile che ha inserito il reperto; infine l’ultima colonna a destra ha
un pulsante di amministrazione, per la cancellazione del riferimento, se l’utente ha
le credenziali sufficienti.
3.7.11
Gestione dei permessi
L’ultima sezione del sito presa in considerazione è quella che riguarda la gestione
degli utenti. Si tratta di pagine a cui può accedere solamente il personale con
permessi di capo progetto o di direttore scavo. Se dalla pagina con i dettagli della
località (vedi figura 3.7) si clicca sulla voce “Personale” del menu di sinistra, si apre
la schermata riportata nella figura 3.15.
Da questa pagina si vede l’elenco degli utenti che sono al momento associati con
la località corrente. Per ottenere questi dati il codice PHP si connette al database ed effettua una query sulla tabella “autorizzazione” filtrando solo le righe il
cui attributo “idLocalità” corrisponde alla località corrente. Una volta ottenuto
71
3 – L’interfaccia Web
Figura 3.14.
Schermata della pagina con i dettagli di un reperto
l’elenco, viene formattato e presentato nel pannello centrale dei contenuti, sotto forma di una tabella divisa in tre colonne: nelle prime due a partire da sinistra sono
il nome e il cognome dell’utente; nella terza è un campo che indica se l’utente ha
responsabilità di direttore scavo; infine nella quarta colonna più a destra sono due
bottoni per cambiare le impostazioni dei permessi.
Il nome dell’utente è cliccabile e se premuto apre la pagina di figura 3.16 in cui
sono visibili i dettagli dell’utente: il suo nome, cognome, username e lingua; segue
poi una tabella in cui sono riportate le località a cui l’utente è associato e i relativi
permessi.
72
3 – L’interfaccia Web
Figura 3.15.
Schermata della pagina di gestione degli utenti
73
3 – L’interfaccia Web
Figura 3.16.
Schermata della pagina con i dettagli sui permessi utente
74
Capitolo 4
Gestione delle mappe
4.1
Introduzione ai sitemi GIS e al Web mapping
Una mappa è un modello bidimensionale della superficie terrestre che cerca di riportare nel modo più fedele possibile la posizione e la distanza relativa nello spazio di
elementi geografici e urbanistici. Le mappe hanno sempre giocato un ruolo di primo
piano nelle attività umane, fin da tempi antichissimi. I primi tentativi di disegnare
una mappa risalgono addirittura al 6500 a.C. (mappa di Chatalhöyük in Turchia),
vale a dire ben 3000 anni prima dell’avvento della scrittura.
Sebbene indispensabili in più di un’occasione, le tradizionali mappe cartacee
presentano alcuni limiti:
1. Sono scomode da utilizzare: per poter offrire una rappresentazione accurata
di un’estensione geografica sono necessari fogli di grandi dimensioni che non
sono facili da maneggiare;
2. Non sono aggiornabili: l’attività umana porta alla continua modifica dell’ambiente tramite la creazione, per esempio, di nuove strade, nuovi incroci, nuove
strutture abitative, etc. L’unico modo per tener traccia di questi cambiamenti
è l’acquisto di una nuova mappa;
3. Non permettono di selezionare il tipo di informazione a cui si è interessati: la
mappa riporta costantemente tutte le informazioni disponibili senza la possibilità di visualizzarne temporaneamente solo alcune per una maggior facilità
di consultazione.
Questi limiti sono facilmente superati dalle mappe digitali consultabili via Internet dal browser del proprio PC: mettono infatti a disposizione un metodo conveniente ed efficiente di rappresentazione dei dati geografici, che ne rendono immediata
la fruibilità e consentono la creazione di nuovi servizi. È il caso di ArcheoMap, in
75
4 – Gestione delle mappe
cui si è sviluppato un sistema per visualizzare, in tempo reale, su una mappa, la
dislocazione delle località e dei reperti memorizzati nel database.
Per realizzare una mappa digitale sono necessari due tipi di risorse: la mappa
vera e propria, ossia la collezione di dati geografici che descrivono il territorio e le sue
componenti; e un software che sia in grado di presentare all’utente la mappa in un
formato grafico e ne permetta un qualche tipo di interazione. Vista la complessità
della materia, di seguito verranno date alcune definizioni e accennati aspetti utili a
comprendere la gestione delle mappe e i servizi associati.
4.1.1
Formati digitali delle mappe
Le informazioni geografiche digitali si dividono in due famiglie: dati vettoriali e dati
raster. I dati vettoriali rappresentano gli oggetti geometrici da cui è formata la mappa come l’elenco dei punti che li definiscono e relative coordinate. Questo significa
che una mappa memorizzata in formato vettoriale è come un complesso poligono,
di cui sono forniti i punti, ad ognuno dei quali corrispondono delle coordinate per
la georeferenziazione1 .
I dati raster, diversamente, sono delle immagini aeree del territorio. Per poter
far corrispondere a queste immagini una posizione geografica, sono accompagnate da
informazioni aggiuntive che collegano i bordi dell’immagine alle coordinate spaziali.
Solitamente in formato vettoriale sono le mappe stradali e le mappe geopolitiche
dei confini nazionali e comunali, perché facilmente riconducibili ai concetti geometrici di linea e segmento. In formato raster sono invece le immagini satellitari o
le mappe dei rilievi montuosi perché richiedono una resa grafica ricca di sfumature
di colore e di dettagli dalle forme troppo complesse per poter essere riprodotte con
punti e linee.
4.1.2
Gestori delle mappe
I software di gestione delle mappe hanno lo scopo di leggere le mappe digitali e
renderizzarle in un’immagine che visualizzi su schermo la cartina geografica trattandone adeguatamente le informazioni spaziali. Ad esempio, se l’utente clicca su
un punto della mappa a schermo, il software è in grado di dire a quale coordinata geografica corrisponde, effettuando cioè la georeferenziazione. Una caratteristica
propria dei software di gestione per le mappe digitali è quella di poter visualizzare contemporaneamente mappe riportanti informazioni diverse. Ad esempio, se si
hanno tre mappe vettoriali dell’Italia, di cui una con i confini regionali, una con il
tracciato delle strade e una con il tracciato dei fiumi, e una mappa raster con le
1
La georeferenziazione in generale è una procedura che permette di assegnare le coordinate
standard (secondo una data proiezione) ai punti di un’immagine
76
4 – Gestione delle mappe
immagini satellitari del Paese, è possibile visualizzarle assieme (sovrapponendo le
immagini satellitari con i tracciati stradali) oppure selezionare quali vedere in un
dato momento. Si realizza cioè la selettività delle informazioni.
4.1.3
GIS e Web Mapping
Le mappe digitali si prestano alla creazione di molteplici servizi su base geografica
tra cui quelli di maggior interesse ai fini del progetto ArcheoMap sono i sistemi GIS
e il Web Mapping.
Con il termine GIS (acronimo di Geographical Information System) si intende
un sistema software per l’acquisizione, memorizzazione, estrazione, trasformazione
e visualizzazione di dati spaziali dal mondo reale. Si tratta quindi di un sistema in
grado di produrre e gestire dati spaziali associando a ciascun elemento geografico
una o più descrizioni. L’obiettivo di un sistema GIS è di consentire all’utente di
cercare informazioni spaziali che possano essere utili per lo svolgimento di attività
lavorative o private e di visualizzarle selettivamente su di una mappa. Un sistema
GIS è formato pertanto da un gestore di mappe che sia in grado di interfacciarsi
ad un database: nella base dati vengono catalogate le informazioni che si vogliono
descrivere e georeferenziare; quando si effettuano delle ricerche, il sistema colloca
sulla mappa dei marcatori che contrassegnano la posizione nello spazio dei dati
memorizzati nel database.
Per Web Mapping si intende, infine, un servizio di fruizione delle mappe da
remoto sulla rete Internet. Lo scopo è quello di pubblicare e rendere fruibili sulla rete
informazioni a carattere geografico, garantendone l’accesso tramite uno strumento
ben conosciuto, il browser, e senza bisogno di installare software aggiuntivi. Viene
realizzato per mezzo di un gestore di mappe che è in grado di interfacciarsi ad un Web
Server : l’utente, dal suo browser, fa richiesta di una pagina Web su cui è disegnata
la mappa e può interagire con essa. Tutte le richieste riguardanti la mappa sono
prima inviate al Web Server, il quale le gira al gestore delle mappe per l’elaborazione
e la generazione della risposta. Il tutto avviene in modo trasparente all’utente finale
il quale dalla sua postazione di lavoro vede semplicemente il ricaricamento della
pagina con la mappa ridisegnata.
4.2
Requisiti del sistema di Web Mapping
L’obiettivo è quello di creare per ArcheoMap un sistema informativo che consenta
di visualizzare su una mappa la dislocazione delle località e dei reperti inseriti nel
database e di renderle disponibili ad utenti remoti che si connettano ad un Web
Server. Si vuole quindi realizzare un sistema GIS e contemporaneamente un servizio
di Web Mapping.
77
4 – Gestione delle mappe
L’utente deve visualizzare la mappa all’interno di una pagina Web e poter interagire con essa tramite un pannello di comandi. Si richiede di implementare almeno le
principali funzioni di zoom (ingrandimento della mappa), pan (scorrimento) e scelta
di layer (selettività delle informazioni).
Nel seguito del capitolo si descriveranno le soluzioni proposte per ottemperare
ai requisiti, gli strumenti utilizzati e verranno infine mostrate alcune immagini di
esempio per illustrare il funzionamento del prodotto finale.
4.3
Il gestore di mappe: MapServer
In ambito Open source il miglior software che consente la gestione delle mappe e
la realizzazione di un sistema di Web Mapping è MapServer. Realizzato presso
l’Università del Minnesota in collaborazione con la NASA, viene mantenuto oggi da
una comunità di sviluppatori sparsi in tutto il mondo e impiegato in una pluralità
di progetti che puntano ad offrire servizi via Web su base geografica.
L’obiettivo di MapServer è quello di fornire uno strumento per gestire e pubblicare mappe via Web, ma non è, per scelta degli autori, un sistema GIS in quanto
non prevede strutture integrate per la connessione ai database e dispone di limitate
capacità analitiche sui dati. Tuttavia le funzioni di MapServer sono rese disponibili
tramite un’API2 per vari linguaggi di programmazione, tra cui il PHP: è quindi
possibile creare applicazioni che si connettano ai database ed operino in modo complesso sui dati, sfruttando il motore di gestione delle mappe di MapServer per la
rappresentazione spaziale.
Nella figura 4.1 è illustrato il modo in cui lavora MapServer e come interagisce
con il Web Server. L’utente dal suo browser vede una pagina web che contiene
un’immagine della mappa, su cui può effettuare delle operazioni tramite un apposito
pannello di controllo posto nella stessa pagina. Quando viene effettuata una delle
operazioni previste, si scatena una richiesta al Web Server che attiva il seguente
processo:
1. Il Web Server riconosce, tra i parametri inviatigli dal browser dell’utente,
la richiesta di una funzione di aggiornamento della mappa e la inoltra a
MapServer;
2. MapServer legge dal disco i dati geografici in formato vettoriale o raster che
sono contenuti in opportuni file e genera la mappa come un’immagine, cosı̀ da
essere facilmente comprensibile per i browser;
2
API, Application Programming Interface, nell’ambito della scrittura di un software è uno
strumento fornito ai programmatori che rende disponibili un insieme di procedure per utilizzare le
funzioni messe a disposizione da un sistema o da un altro software
78
4 – Gestione delle mappe
Figura 4.1.
Schema di funzionamento di MapServer
3. L’immagine della mappa viene spedita al Web Server, il quale la include nella
pagina HTML generata e la restituisce al browser dell’utente.
La costruzione delle mappe in MapServer avviene gerarchicamente secondo il
concetto di layer. Ogni mappa è il prodotto della sovrapposizione di più layer,
ossia di livelli di informazione, ognuno contenente un insieme di dati omogenei che
devono essere rappresentati insieme. La visualizzazione dei layer è sotto il controllo
attivo dell’utente, che può scegliere quale visualizzare. Durante la generazione della
mappa, inoltre, MapServer può svolgere autonomamente determinate operazioni
come la visualizzazione delle etichette di testo, con la possibilità di non mostrare le
etichette al di sotto di un certo fattore di ingrandimento per evitare di sovraffollare
la mappa; può generare autonomamente la legenda e l’indicatore del fattore di scala;
può infine generare una piccola mappa secondaria di riferimento che mostra quale
parte della mappa generale si sta visualizzando nell’immagine principale.
Il numero e il tipo di layer che devono essere gestiti da MapServer e la scelta
di quali opzioni attivare viene controllata da un particolare file di configurazione
avente estensione .map (mapfile) che controlla il funzionamento del programma.
4.3.1
Il mapfile
Il mapfile è un file di testo che MapServer utilizza per determinare l’aspetto della
mappa e il modo in cui deve comportarsi quando gli giungono richieste dal Web
Server.
Il mapfile si presenta come una collezione di oggetti strutturati gerarchicamente,
79
4 – Gestione delle mappe
la cui definizione inizia con una parola chiave che identifica il tipo di oggetto e
termina con l’istruzione “end”. All’interno di un oggetto possono venir elencati dei
parametri (espressi come coppie nome / valore), oppure altri oggetti, il cui ambito
di valenza è ristretto all’oggetto che li include, da cui sono dipendenti. Un esempio
di sintassi di un mapfile è questo:
oggetto1
parametro1 valore
parametro2 valore
...
oggetto1.1
parametro valore
...
end
end
oggetto2
parametro1 valore
parametro2 valore
...
end
Si definiscono tre oggetti “oggetto1”, “oggetto2“ e “oggetto1.1”, di cui i primi
due sono indipendenti, e il terzo è figlio del primo, in quanto dichiarato al suo
interno, e viene perciò processato solo quando è processato oggetto1.
Gli oggetti definiti all’interno del mapfile non sono a discrezione dell’utente ma
devono rispettare una ben determinata nomenclatura e gerarchia riconosciute da
MapServer. Nella figura 4.2 sono illustrati in uno schema i principali oggetti predefiniti da MapServer e la loro organizzazione gerarchica, cosı̀ come va rispettata nel
mapfile.
Come si può vedere, alla testa di tutto è l’oggetto “map” che fa da contenitore
per tutti gli altri oggetti. Ciò che viene dichiarato al di fuori di esso è ignorato da
MapServer. Al suo interno vengono definiti i parametri generali della mappa che si
vuole disegnare, indicandone in particolare il formato di output (immagine di tipo
jpg, gif o png), la dimensione, in pixel, dell’immagine, il colore di sfondo, l’unità di
misura adottata e la directory in cui MapServer deve cercare i file di dati contenenti
le informazioni sulla mappa.
L’oggetto “layer” definisce le caratteristiche di ogni singolo livello di informazione di cui è composta la mappa. In un mapfile devono quindi essere dichiarati
tanti oggetti “layer” quanti sono i livelli. Ogni layer è caratterizzato da un nome,
da un tipo di dato (poligoni o punti nel caso di dati vettoriali, raster per immagini
aeree o satellitari), da un’etichetta che lo identifica nella legenda e da un parametro
80
4 – Gestione delle mappe
Figura 4.2.
Schema gerarchico degli oggetti definiti in MapServer
che indica se il layer è attivo oppure no, altrimenti detto, se deve essere visualizzato
automaticamente oppure solo su richiesta. Le informazioni di ogni layer sono memorizzate in un file dedicato, il cui nome viene indicato a MapServer da un opportuno
parametro.
Per definire le specifiche di visualizzazione di un layer in termini di colore di
sfondo, colore dei bordi, dimensioni e stile del font in cui vanno scritte le etichette si
fa uso dell’oggetto “class”. Ogni layer può avere più oggetti “class” definiti al suo
interno, l’importante è che ve ne sia almeno uno. Il motivo per cui MapServer consente la definizione di più oggetti “class” è di poter applicare, selettivamente, stili
di visualizzazione differenti ai dati memorizzati nei singoli file. Ad esempio, nel caso
di una mappa geopolitica dell’Italia, è possibile assegnare ad ogni regione un colore
differente. Per specificare a quali dati si applica un determinato oggetto “class”
si usa il parametro “expression” il quale prende come argomento un’espressione
logica che seleziona i dati contenuti nel file del layer ; qualora tale espressione sia
soddisfatta viene applicato su tali dati lo stile descritto nell’oggetto “class”.
L’oggetto “web” specifica il template che deve essere usato per la generazione
81
4 – Gestione delle mappe
della pagina Web contenente la presentazione della mappa e dei risultati della ricerca. Sono inoltre esplicitati il percorso in cui MapServer deve salvare le immagini
temporanee create durante il lavoro di processamento.
Con l’oggetto “scalebar” si definiscono le caratteristiche dell’indicatore di scala
della mappa, che si presenta nella forma di un righello graduato. Se ne possono
dettagliare la posizione, il colore, lo stile delle etichette, le dimensioni in pixel, l’unità
di misura e l’intervallo che separa una tacca dall’altra.
L’oggetto “legend” abilita MapServer a disegnare automaticamente la legenda,
un semplice specchietto informativo che associa ai colori della mappa una breve
descrizione del loro significato;
Infine l’oggetto “reference” crea una seconda piccola immagine di riferimento
che permette all’utente di sapere dove si trova sulla mappa generale nel caso in
cui abbia effettuato degli ingrandimenti sull’immagine principale. Della reference
possono essere definiti il colore della mappa, il colore del bordo e la dimensione.
Nell’appendice 9.2 è riportato il mapfile adottato per il progetto ArcheoMap.
Per la creazione della versione dimostrativa si è utilizzata una mappa dell’Italia che
consente di visualizzare: il tracciato dei confini nazionali; i principali corsi d’acqua
e laghi; le principali arterie stradali e la posizione delle maggiori città. Un layer di
tipo raster consente inoltre di sovrapporre delle immagini aeree che mostrano l’andamento dei rilievi montuosi. Come formato di output si è scelto, per il buon rapporto
qualità / dimensione, il formato PNG. Indicatore di scala, legenda e reference map
sono fatti gestire in automatico da MapServer.
4.3.2
I layer di ArcheoMap
Tra i layer definiti nel mapfile di ArcheoMap ve ne sono due su cui è necessario
soffermarsi: il layer “archeo-loc”, contenente i punti di georeferenziazione delle
località di ArcheoMap, e il layer “archeo-reperti”, contenente l’insieme dei punti
di georeferenziazione dei reperti di ArcheoMap.
Ciò che rende particolari questi due layer è che i file in cui sono memorizzati
i loro dati sono creati e modificati dinamicamente dal codice PHP delle pagine di
gestione delle località e dei reperti ogni qual volta vengano creati o cancellati dei
record nelle tabelle “località”e “reperti” del database.
Il formato dei file è “GML”: si tratta di un formato vettoriale in cui viene descritta una collezione di punti utilizzando il formalismo XML: ogni punto è definito
da dei marcatori, detti più propriamente tag, che specificano le singole proprietà di
un dato. La sintassi definita nel GML per la dichiarazione di un punto è la seguente:
<punti fid="1">
<ID>10</ID>
<NAME>Nome della localita’</NAME>
82
4 – Gestione delle mappe
<ogr:geometryProperty>
<gml:Point>
<gml:coordinates>012.99,41.74</gml:coordinates>
</gml:Point>
</ogr:geometryProperty>
</punti>
Il tag <punti> indica che sta iniziando la definizione di un punto; il tag <id>
specifica un identificativo del punto, e il tag <name> gli assegna un nome. Seguono
poi la descrizione dell’elemento geometrico e le coordinate geografiche di riferimento.
Uno script, lanciato in automatico, provvede ad interrogare il database alla ricerca di tutte le località e i reperti di cui è stata specificata la posizione tramite
coordinate. Per ognuno di questi punti viene quindi ripetuta la sequenza di tag
appena vista.
Una volta completata la compilazione del file, questo viene tradotto nel formato
“Shapefile”3 , specificamente pensato per la memorizzazione di informazioni geografiche vettoriali, e gestito da MapServer. In questo modo le località e i reperti del
database di ArcheoMap possono comparire nella cartina geografica digitale, come
richiesto dai requisiti.
4.3.3
PHP/MapScript
PHP/MapScript è un’insieme di funzioni e di classi che permettono al programmatore di accedere alle funzionalità di MapServer da script in PHP: si adatta perfettamente, quindi, alle esigenze del progetto ArcheoMap in quanto consente di integrare
le mappe generate da MapServer all’interno delle pagine Web del sito che, come
descritto nella sezione 3.4 sono scritte in tale linguaggio. Inoltre, sfruttando le potenzialità messe a disposizione da PEAR DB (vedi sezione 3.6.2) diventa possibile
accedere al database per la ricerca e gestione di dati geografici e quindi trasformare
MapServer in un vero e proprio sistema GIS.
L’infrastruttura di PHP/MapScript è costituita da un insieme di classi che ricalcano gli oggetti definiti da MapServer per i mapfile. Ad esempio, è definita una
classe “MapObj” che permette di trattare gli oggetti “map”, una classe “LayerObj”
per trattare gli oggetti “layer”, una classe “ReferenceObj” per trattare gli oggetti
“reference”, etc. Nella figura 4.3 viene dato uno schema grafico di alcune di queste
classi; si tratta di uno schema incompleto, il cui unico scopo è di meglio chiarire come sono strutturate, perché nella realtà gli attributi e i metodi definiti per ciascuna
classe sono molto più numerosi e consentono di modificare ogni singolo aspetto delle
mappe generate da MapServer. È possibile, ad esempio, cambiare dinamicamente il
3
Shapefile è il nome di un formato di dati vettoriale inventato dalla ESRI (Enviromental System
Research Insitute) divenuto uno standard per la diffusione di dati geografici
83
4 – Gestione delle mappe
MapObj
LayerObj
−width
ReferenceMapObj
−extente
−status
−name
−data
−units
−labelitem
+draw()
+draw()
+getLayer()
+queryByPoint()
−height
−imagetype
−width
−heigth
−color
+set()
+setExtent()
Figura 4.3.
Schema grafico di alcune classi di PHP/MapScript
colore di un layer della mappa, cambiare lo stile delle etichette, etc. Tutte cose non
possibili con il semplice mapfile in quanto il suo contenuto è statico e predeterminato
al momento della creazione.
Con l’inclusione di PHP/MapScript il processo di gestione delle mappe cambia
leggermente rispetto a quanto visto nella sezione precedente e diventa come illustrato nella figura 4.4: la richiesta proveniente dal browser dell’utente al Web Server
Figura 4.4.
Schema di funzionamento di PHP/MapScript
non viene immediatamente rediretta a MapServer ma passa prima dall’interprete
84
4 – Gestione delle mappe
PHP, il quale, tramite le funzioni di PHP/MapScript, interroga MapServer per l’elaborazione della mappa. I risultati sono quindi inglobati in una pagina PHP per
la formattazione in HTML e solo allora passati al Web Server che invia la risposta
all’utente. Oltre ad esserci un passaggio in più rispetto al modello della figura 4.1, la
vera novità è costituita dal database, a cui lo script PHP può accedere per integrare
le funzionalità di cartografia e georeferenziazione con le funzionalità di ricerca sui
dati.
Ogni operazione effettuata sulla mappa comporta una o più chiamate a procedure
di PHP/MapScript per processare e disegnare la cartina geografica. In termini
progettuali PHP/MapScript modifica lo stato corrente della mappa, definito da un
insieme di parametri quali: la sua estensione; le coordinate dell’area correntemente
visualizzata; il livello di zoom e l’elenco dei layer attivati. Quando l’utente esegue
un’operazione va a cambiare uno di questi parametri, lasciando gli altri immutati.
PHP/MapScript si occupa quindi di volta in volta di ricordare lo stato precedente e
riprodurlo ad ogni nuova richiesta variandone l’unico parametro che è effettivamente
cambiato.
4.4
MapServer integrato nel sito di ArcheoMap
Una volta descritte le proprietà di MapServer, i concetti fondamentali che stanno
dietro alla sua filosofia di funzionamento e come li si è usati per personalizzare la
mappa, si propone una carrellata di immagini che testimoniano come MapServer sia
stato integrato nel sito di ArcheoMap e quali sono le operazioni che un utente può
effettuare.
Quando si apre la pagina delle mappe, la schermata di fronte a cui si trova
l’utilizzatore è quella di figura 4.5. Lo stile della pagina segue lo schema a tre colonne
utilizzato per tutto il resto del sito: nel pannello a sinistra si trova la reference map
e la legenda; nel pannello a destra si trova il “centro di comando” con i pulsanti da
cui si possono accedere a varie operazioni; infine nel centro è posta la mappa con
l’indicatore di scala. Sulla mappa sono mostrati in prima istanza i layer dei confini
geografici, delle città, delle nazioni, dei laghi e dei siti di ArcheoMap (puntini rossi
sulla cartina).
Se ora l’utente sceglie dal pannello di destra lo strumento “zoomin” e poi punta
con il mouse una zona della mappa, questa viene ingrandita, come mostrato nella
figura 4.6. Si noti come la reference map si modifichi automaticamente per riflettere
l’operazione appena effettuata: un quadratino rosso mostra quale parte della mappa
generale è correntemente visualizzata nell’immagine principale, cosı̀ che l’osservatore
non corra il rischio di perdersi durante la navigazione.
Lo strumento “zoomout” compie l’operazione inversa: dimininuisce il livello di
ingrandimento della mappa fino a riportarla alle condizioni originali.
85
4 – Gestione delle mappe
Figura 4.5.
Schermata iniziale della mappa disegnata da MapServer
Con lo strumento “ricentra” si cambia il punto che è al centro della mappa. Ad
esempio, a partire dalla situazione di figura 4.6, se si punta il mouse sulla città
dell’Aquila si ottiene il risultato di figura 4.7: l’immagine principale si sposta e
inquadra la porzione d’Italia che ha il suo centro sul capoluogo abruzzese, e la
reference map si aggiorna di conseguenza.
Lo strumento “zoombox” permette di effettuare degli ingrandimenti, in modo
analogo a quanto fatto dallo strumento “zoomin” ma, a differenza di questo, invece
di selezionare un singolo punto, viene tracciato per mezzo del mouse un rettangolo
che circoscrive un’intera area su cui deve essere effettuato lo zoom.
Il pulsante “Reset” riporta la mappa alle condizioni originali, quelle di figura 4.5
annullando tutte le operazioni compiute.
Dal pannello di sinistra, come detto, si possono selezionare quali livelli informativi visualizzare. Ad esempio, se si vuole sovrapporre alla mappa il layer raster con
l’immagine dei rilievi montuosi, è sufficiente selezionarlo dal pannello e premere il
bottone “aggiorna”: quello che si ottiene è l’immagine di figura 4.8.
Nel menu intitolato “Informazioni” si dispone di uno strumento per la misura
86
4 – Gestione delle mappe
Figura 4.6.
Schermata della mappa in seguito ad uno zoom
delle distanze e del form di ricerca. Lo strumento con l’icona di un righello consente
di calcolare le distanze tra due punti della mappa. Quello che si ottiene è riportato
in figura 4.9: un segmento di puntini rossi indica i due punti tra cui si è calcolata
la distanza, mentre nel menu in basso a destra ne viene indicato il valore, espresso
in Km. L’operazione di calcolo della distanza non viene effettuata in automatico da
MapServer ma è stata implementata a parte: dapprima si preleva la posizione dei due
punti sull’immagine, poi si calcola a quali coordinate geografiche corrispondono (in
pratica si convertono i punti-immagine in punti-mappa) ed infine, nota l’estensione
della mappa corrente, ne viene computata la distanza.
4.5
Google Maps
“Google Maps” è un servizio di Web Mapping gratuito fornito dal celebre motore
di ricerca Google e messo a servizio del pubblico a partire dalla fine del 2005. Ciò
che ha reso famoso Google Maps rispetto agli altri servizi di Web Mapping presenti
in rete è la disponibilità di un ricco repertorio di foto satellitari ad elevato dettaglio
87
4 – Gestione delle mappe
Figura 4.7.
Schermata della mappa in seguito ad un ricentramento
che consentono di osservare in una sorta di visuale a volo d’uccello molte aree del
pianeta. Le zone della Terra attualmente coperte dalle foto satellitari ad elevato
dettaglio sono limitate, ma tra queste sono comunque comprese le principali aree
abitate degli Stati Uniti, Canada ed Europa più una serie di altri luoghi di interesse
politico o turistico nel resto del mondo. Google sta nel frattempo continuando
l’acquisto di nuove mappe per cui la copertura ad alta definizione aumenta nel
tempo.
Una caratteristica che ha contribuito non poco al successo di questo servizio
di Web Mapping è senza dubbio il rilascio di “Google Maps API”, una libreria di
funzioni che consente agli sviluppatori di integrare le mappe di Google all’interno
di altri siti, previa registrazione gratuita. Google Maps API fa uso della tecnologia
AJAX (Asinchronous Javascript And XML), appositamente pensata per le applicazioni Web interattive, e che trova nel servizio di Web Mapping di Google una delle
più significative forme di utilizzo. Il vantaggio offerto dalla tecnologia AJAX è che,
ad ogni richiesta dell’utente, anzichè ricaricare completamente la pagina con i dati
aggiornati, come avviene nelle applicazioni Web tradizionali, vengono modificate le
88
4 – Gestione delle mappe
Figura 4.8.
Schermata della mappa con i rilievi montuosi
89
4 – Gestione delle mappe
Figura 4.9.
Schermata della mappa in seguito ad una richiesta di calcolo della distanza
sole parti della pagina di cui si ha effettiva necessità, diminuendo cosı̀ la quantità
di dati che deve essere scambiata tra client e server e dando una sensazione di
maggiore reattività all’utente.
Quando Google Maps è divenuto pubblico, nonostante non sia stato rilasciato
con una licenza Open Source (Google ha reso gratuito il servizio, ma si riserva il
diritto di aggiungervi banner pubblicitari o di far pagare licenze ai partner commerciali) è tale la qualità delle mappe messe a disposizione che si è pensato, a titolo
sperimentale, di includerlo in ArcheoMap. Attualmente quindi sul sito sono disponibili due mappe: una gestita con MapServer, che può essere considerata la versione
ufficiale, e una gestita con GoogleMaps a scopo di test. Nella figura 4.10 è mostrata
la pagina con Google Maps: la schermata è dominata dalla mappa satellitare dell’Italia. I comandi sono raccolti in un piccolo pannello a sinistra e uno a destra. A
sinistra ci sono i bottoni per regolare il livello di zoom e gli spostamenti orizzontali
e verticali; a destra ci sono i bottoni per attivare i livelli disponibili: “Map” mostra
la mappa politica e stradale; “Satellite”, la visuale corrente, è la mappa satellitare;
90
4 – Gestione delle mappe
Figura 4.10. Schermata della mappa di Google Maps
“Hybrid” sovrappone le prime due. Sulla cartina si notano due marcatori, corrispondenti al sito archeologico di Pompei e a quello di Forcello. Questo dimostra la
flessibilità dell’API di Google Maps, che consente di integrare la sua cartografia con
dei riferimenti personalizzati, in questo caso i siti archeologici di ArcheoMap.
Nella figura 4.11 è mostrato il livello di dettaglio raggiungibile dalle immagini satellitari di Google Maps; si è fatto un ingrandimento sulla zona archeologica
di Pompei: se ne può distinguere con precisione l’impianto stradale antico, con
il perimetro delle abitazioni, in particolare l’antico anfiteatro con l’inconfondibile
semicerchio delle gradinate.
A riprova dell’utilità che possono rivestire mappe dettagliate come quelle proposte da Google, non si può non citare la recente scoperta di una villa romana nei
dintorni di Parma da parte di un utente di Google Maps che ha segnalato al Museo
Archeologico della propria città di una curiosa macchia in mezzo ai campi osservabile dalle mappe satellitari. Le successive indagini archeologiche hanno effettivamente
rivelato la presenza sul luogo di un insediamento romano del I secolo a.C.
91
4 – Gestione delle mappe
Figura 4.11.
Schermata con dettaglio di Google Maps ingrandita
92
Capitolo 5
Il programma su Palm
5.1
Introduzione ai dispositivi palmari
Il mondo dell’informatica è stato rivoluzionato nella seconda metà degli anni ’90
dalla comparsa dei primi dispositivi palmari, apparecchi elettronici dalle dimensioni ridotte, assimilabili a quelle del palmo di una mano (da cui il nome) capaci di
eseguire operazioni più complesse di una semplice calcolatrice e dotati di una certa
quantità di memoria interna (eventualmente espandibile) che consente di memorizzare programmi e dati di vario genere. Inizialmente pensati come avanzate agende
elettroniche, ne sono ben presto emerse le potenzialità come veri e propri computer
in miniatura tanto da coniare per essi il termine di mobile computing con cui si
intende la possibilità di tenere sempre con sè i propri dati sensibili e le applicazioni
più importanti per mezzo di dispositivi più pratici e agevoli da trasportare e usare
rispetto ai tradizionali personal computer portatili.
Tra i vari produttori che si sono cimentati nel mercato del mobile computing ha
avuto particolare successo l’azienda Palm, tanto che il suo nome è divenuto per un
certo periodo sinonimo di computer palmare. Le caratteristiche che hanno contribuito alla diffusione dei dispositivi di Palm sono la semplicità di utilizzo, il favorevole
rapporto qualità / prezzo e la disponibilità di una ben documentata API, l’interfaccia di programmazione che consente lo sviluppo di applicazioni per il sistema
operativo PalmOS, utilizzato su gran parte dei dispositivi Palm.
Nella figura 5.1 è mostrato un tipico dispositivo prodotto da Palm. La superficie
è dominata dallo schermo touchscreen, diviso in due parti. Nella sezione superiore
è visualizzata l’area di lavoro, dove si vede l’output dei programmi e del sistema
operativo; la sezione inferiore è l’area di scrittura, dove l’utente traccia le lettere
e i numeri che vengono interpretati dal sistema di riconoscimento “Graffiti” per
immetere dei testi qualora richiesto. In basso, infine, alcuni pulsanti per richiamare
velocemente le principali funzioni: la rubrica, l’agenda, la lista delle attività e il
93
5 – Il programma su Palm
Figura 5.1.
Immagine di un dipositivo Palm
blocco note.
Trattandosi di dispositivi dalle dimensioni contenute e che devono fare affidamento sulle proprie batterie interne per operare, i palmari hanno un’architettura
che si discosta molto da quella dei tradizionali PC. Il principale aspetto da tenere
in conto è l’assenza di un hard disk per la memorizzazione permanente dei dati: si
deve fare affidamento sulla sola memoria volatile, di capienza ridotta (valori tipici
sono 32MB o 64MB, ma in molti casi sono inferiori), che viene costantemente tenuta
attiva dalla batteria, anche quando apparentemente il dispositivo è spento. Va da
sè che, qualora la batteria si scaricasse completamente, tutti i file e le applicazioni
verrebbero persi irrimediabilmente.
Queste peculiarità fanno sentire i loro effetti anche sul processo di sviluppo delle applicazioni. In particolare occorre prestare attenzione all’uso della memoria,
impiegandola solo quando strettamente necessario, e occorre progettare accuratamente l’interfaccia grafica, in modo da sfruttare correttamente il ristretto spazio
offerto dallo schermo dei palmari.
Nel corso di questo capitolo si analizzerà il progetto e lo sviluppo dell’applicativo
di ArcheoMap su un dispositivo palmare prendendo a riferimento quelli prodotti da
Palm dotati di sistema operativo PalmOS, mettendo in luce quali sono i requisiti
che si devono soddisfare e le soluzioni proposte. Si concluderà con una carrellata di
94
5 – Il programma su Palm
immagini per illustrare nel dettaglio le funzionalità del prodotto finale.
5.2
Requisiti del programma su PalmTM
L’obiettivo è quello di produrre un’applicazione da far eseguire su un dispositivo
PDA1 prodotto dall’azienda Palm, che consenta di usufruire della base dati di ArcheoMap in modo pratico e intuitivo anche quando non si ha a disposizione un
collegamento di rete. Nell’ambito del progetto ArcheoMap ogni archeologo deve essere dotato di un proprio dispositivo palmare da usare sul luogo stesso dello scavo
per effettuare immediatamente le annotazioni ritenute necessarie, ed eventualmente
leggere quelle già prese da altri. Il legame palmare / utente è univoco, nel senso
che ogni dispositivo, al momento di essere assegnato ad una persona, ne eredita
implicitamente i permessi, ed è responsabilità di chi lo ha in custodia assicurarsi che
nessun altro lo usi a sproposito per leggere informazioni non autorizzate o cancellare
i propri dati.
Coerentemente con questo modello di utilizzo, il software deve fornire le stesse
funzionalità già implementate sul sito, con la stessa organizzazione logica. In particolare si richiede che l’utente, a partire dall’elenco dei progetti, possa esplorarne le
località e i relativi contenuti: diario di scavo, elenco dei reperti, galleria fotografica
e schede ministeriali. Oltre a poter leggere i singoli elementi, l’utente deve poter
aggiungerne di nuovi, se ha i permessi per farlo.
I recenti modelli PDA della Palm sono orientati alla multimedialità, per cui
qualora il dispositivo palmare sia dotato di una macchina fotografica, si richiede
che l’applicazione sia in grado di interfacciarsi con essa per scattare delle foto da
scaricare poi sul database al termine del lavoro.
5.3
Tecniche di ingegneria del software
Il termine “Ingegneria del Software” compare negli anni ’60 quando l’aumento delle
prestazioni dei calcolatori rende possibile la creazione di programmi molto complessi,
la cui scrittura e manutenzione non può più essere affidata alla sola esperienza del
programmatore. Si rende quindi necessaria una maggiore pianificazione che consenta
di definire prima tutte le caratteristiche e le funzionalità che deve avere l’applicazione
che si intende produrre, per procedere solo in un secondo momento alla scrittura del
codice.
L’Ingegneria del software ha introdotto il concetto di “ciclo di vita” di un’applicazione, ossia la successione di fasi tra loro coordinate che accompagnano l’intero processo di sviluppo e realizzazione di un programma da quando questo viene
1
PDA, Personal Digital Assistent, è sinonimo di palmare
95
5 – Il programma su Palm
concepito a quando ne termina la produzione. Queste fasi sono sostanzialmente
cinque:
• Analisi dei requisiti: si discutono, assieme ai committenti, le richieste che il
software deve soddisfare, chiarendone i punti oscuri e definendone le specifiche;
• Progetto: si modellano le strutture dati e il flusso del programma facendo uso
di diagrammi formali che permettono di definire, ad un livello astratto, tutte
le caratteristiche del software, coerentemente con quanto definito nei requisiti;
• Implementazione: i diagrammi generati durante la fase di progetto vengono
tradotti in un linguaggio di programmazione per la stesura del codice;
• Verifica e validazione: il codice prodotto viene sottoposto ad una serie di
test per assicurarsi che non presenti malfunzionamenti, e si certifica assieme
al committente il soddisfacimento dei requisiti;
• Manutenzione: si procede alla correzione di eventuali bug qualora durante
l’utilizzo del software se ne manifestino, oppure si raffinano le caratteristiche
aggiungendo nuove funzionalità richieste dagli utenti;
Nel corso degli anni si sono definiti diversi modelli di processo, ciascuno dei quali
si adatta ad alcune esigenze e ambiti di sviluppo. I principali sono lo sviluppo a
cascata (Waterfall model ) e il modello incrementale (Incremental Model ).
Il modello a cascata prevede che le singole fasi del ciclo di sviluppo si susseguano
una dopo l’altra in modo lineare, come illustrato nella figura 5.2: l’output di ogni
Figura 5.2.
Ciclo di vita del software secondo il modello a cascata
fase è un semilavorato di input per il passo successivo. Il grande pregio di questo
96
5 – Il programma su Palm
modello è la sua semplicità e chiarezza, ma presenta il limite di essere troppo rigoroso. I requisti vengono congelati nelle fasi iniziali e una loro modifica comporta
necessariamente il rifacimento dall’inizio di tutto il processo. Il cliente, inoltre può
osservare il risultato solo alla fine, a produzione compiuta, non potendo partecipare
in alcun modo alle fasi intermedie.
I limiti del modello a cascata sono stati superati da nuovi processi più dinamici
raggruppati sotto il nome di modelli evolutivi, di cui il modello incrementale ne è un
esempio. Le fasi in cui viene scomposto il processo sono le stesse viste poco sopra,
cosı̀ come la loro successione, ma anzichè concludersi con un unico software definitivo
si punta a rilasciare, nel più breve tempo possibile, dei prototipi da sottoporre
all’attenzione del committente e dei clienti. Sulle indicazioni da questi fornite si
procede alla creazione di prototipi via via sempre più raffinati fino a giungere al
prodotto finale. Prodotto finale che può poi, a sua volta, evolvere ulteriormente
nel tempo, qualora incontri successo sul mercato, attraverso il rilascio programmato
di nuove versioni o release che aggiungono nuove funzionalità e ne ottimizzano le
prestazioni. Con i modelli evolutivi di sviluppo del software si riesce ad ottenere una
maggiore soddisfazione da parte dei committenti, che si vedono coinvolti nel ciclo
di sviluppo e sono costantemente informati sullo stato di avanzamento dei lavori,
ma si ha come contropartita una maggior difficoltà dal lato progettuale, in quanto è
imperativo strutturare le singole parti del software in modo sufficientemente flessibile
da facilitarne le modifiche, quando richieste, e occorre programmare per bene l’ordine
di rilascio dei prototipi intermedi.
A supporto del progettista che si deve confrontare con lo sviluppo di software
dalla complessità crescente, si afferma nel corso degli anni ’70 il paradigma della
programmazione ad oggetti. Tradizionalmente la programmazione è vista come una
sequenza di comandi che istruiscono il processore su come svolgere determinati compiti. Tale approccio, detto paradigma procedurale, implica che il programmatore,
nell’elaborare una soluzione per un problema reale, si pone dalla parte della macchina, scomponendo l’assunto iniziale in sottoproblemi via via più semplici riconducibili
a operazioni logiche di assegnamento e di controllo di flusso. Con il paradigma ad
oggetti, viceversa, si pensa ad un programma come un mondo artificiale composto
da elementi che interagiscono tra di loro. Le entità che popolano questo mondo
artificiale sono gli “oggetti”, le cui caratteristiche, in termini di attributi e azioni
che possono compiere, sono definite nelle “classi”. In termini pratici una classe è la
definizione di una struttura dato, mentre gli oggetti ne sono le istanze particolari.
Gli attributi di una classe elencano le informazioni necessarie a descrivere lo stato
corrente di un oggetto. Per cambiare gli attributi, quindi per far cambiare lo stato
di un oggetto, si invocano delle funzioni che, nel gergo della programmazione ad
oggetti, prendono il nome di “metodi”. Proprio come nel mondo reale l’interazione
di un oggetto con un altro si manifesta tramite un cambiamento di stato di uno di
essi, analogamente nel paradigma della programmazione ad oggetti l’azione su un
97
5 – Il programma su Palm
oggetto si manifesta tramite l’esecuzione di un metodo.
Se nel redigere il progetto di un software si definiscono correttamente le classi, i
loro attributi e i metodi, è possibile scrivere codice modulare che facilita il lavoro di
prototipazione e di manutenzione.
5.4
Progetto del programma su Palm
Nello scrivere il software di ArcheoMap per Palm si è adottato un modello di sviluppo incrementale e l’obiettivo di questa tesi consiste nella produzione del primo
prototipo da sottoporre ai committenti per dimostrarne le potenzialità e discuterne
eventuali miglioramenti. Nel seguito sono descritte le fasi di analisi dei requisiti,
progetto e scrittura del codice di questo primo prototipo, mostrando come si è sfruttato il paradigma ad oggetti per la stesura di un software modulare ed efficiente,
tenendo contemporaneamente conto delle difficoltà rappresentante dallo sviluppo su
un sistema dalla limitate capacità come lo sono i computer palmari.
5.4.1
Analisi dei requisiti
Lo scopo dell’analisi dei requisiti è quello di stabilire cosa debba fare il software che
si sta per sviluppare, a partire dalle richieste avanzate dai committenti che, nel caso
di ArcheoMap, sono quelle esposte nella sezione 5.2. Si intende ridefinirne la formulazione, per cercare di renderla più rigorosa e formale, e metterne in luce l’elenco
preciso di specifiche che il programma deve soddisfare. Il prodotto dell’analisi, frutto
della collaborazione tra sviluppatori e committenti per dirimere eventuali dubbi e
incertezze, è il seguente elenco di punti:
1. Il software deve essere dotato di un’interfaccia grafica, tramite cui l’utente
accede alle varie parti di ArcheoMap. Nella terminologia Palm, l’equivalente
di una finestra prende il nome di form;
2. I dati a cui si vuole dare accesso devono essere organizzati in modo coerente
con la struttura del database e quella del sito;
3. Il software deve essere in grado di trattare l’elenco dei progetti di ArcheoMap
e mostrarne le relative informazioni; l’elenco delle località di ogni progetto
e i suoi dettagli; per ogni località se ne deve gestire il diario di scavo come
elenco di articoli, la galleria fotografica come elenco di immagini e l’elenco
dei reperti; se l’utente seleziona un articolo, un’immagine o un reperto dalla
lista, deve poterne visualizzare il contenuto e le informazioni di contorno; nel
caso dei reperti, questi devono presentare una lista di riferimenti agli articoli,
immagini e schede ministeriali che li descrivono; selezionato un riferimento,
98
5 – Il programma su Palm
deve essere possibile visualizzarne il contenuto senza costringere l’utente a
spostarsi in un’altra sezione del programma;
4. L’utente deve poter modificare gli oggetti già esistenti e inserire nuovi articoli
di diario, nuove immagini (qualora il Palm sia dotato di macchina fotografica
integrata), nuovi reperti con i loro riferimenti e compilare le schede ministeriali;
non si deve trattare l’inserimento di nuovi progetti e di nuove locazioni, cosı̀
come non deve essere possibile modificarne le informazioni associate, in quanto
tali azioni sono considerate di livello amministrativo e devono perciò essere
fattibili solo dal sito;
5. Essendo ogni PDA legato in modo diretto ad un utente, la gestione dei permessi è semplificata in quanto il programma eredita automaticamente i permessi
dell’utente a cui è in quel momento associato. Per quel che riguarda i permessi
di lettura, questi sono automaticamente soddisfatti nel momento in cui vengono caricati i dati nella memoria del dispositivo: se un utente, ad esempio,
non può leggere il diario di scavo, non vi dovranno essere articoli in memoria.
Il programma deve però bloccare eventuali tentativi di scrittura o di modifica
dei dati non di sua competenza;
6. Per la stesura di questa prima versione prototipale del programma non sono
richiesti particolari meccanismi di sicurezza dei dati, l’utente stesso è responsabile del dispositivo e del suo contenuto; è però richiesto l’inserimento di
username e password per l’inizializzazione del programma;
7. Poichè il numero di progetti e località presenti nel sito possono essere piuttosto numerosi, per evitare un’eccessiva occupazione di memoria del dispositivo
l’utente deve poter selezionare i progetti e le località che sono di suo interesse;
8. Se il palmare è dotato di macchina fotografica integrata, il programma deve
consentire all’utente di richiamarne l’interfaccia di gestione per scattare delle
foto e offrire gli strumenti necessari per memorizzarle e inserirle nella galleria
di immagini della località;
9. Data la scarsa memoria a disposizione sui PDA, si stabilisce che le sole immagini presenti in memoria siano le foto scattate dalla macchina fotografica
del dispositivo, qualora presente, mentre quelle già inserite nel database non
devono essere caricate. Per tali immagini la galleria fotografica sul palmare ne
contiene quindi le sole informazioni associate, ma non il relativo file grafico.
99
5 – Il programma su Palm
5.4.2
Progetto del software, i diagrammi UML
Se nella fase di analisi dei requisiti si stabilisce cosa deve fare il software, nella fase
successiva, quella di progetto, si decide come implementare le specifiche. Tale fase
non comporta ancora la scrittura di codice: si analizza il problema e si producono una
serie di diagrammi per fissare graficamente le singole componenti dell’applicazione
e il flusso operativo. Tali diagrammi sono raccolti sotto il nome di UML.
Lo Unified Modeling Language, nonostante il nome, non è un vero e proprio
linguaggio di programmazione, quanto piuttosto la formalizzazione di un insieme
di tipologie di diagrammi che vengono utilizzati nella modellazione del software. I
diagrammi definiti dallo standard UML sono sei:
• Diagramma delle classi (Class Diagram);
• Diagramma temporale (Sequence Diagram);
• Diagrammi dei casi d’uso (Use Case Diagram);
• Diagramma degli stati (Statechart Diagram);
• Diagramma delle attività (Activity Diagram);
• Diagramma dei componenti (Component Diagram);
Di questi, nel presente capitolo, sono utilizzati e documentati solo i primi due, in
quanto gli altri servono a modellare altre fasi del processo di sviluppo che non sono
intervenute nel caso di ArcheoMap.
Diagramma delle classi
Il diagramma delle classi, nell’ambito della programmazione ad oggetti, modella i
tipi di oggetti che intervengono nel programma, descrivendone gli attributi, i metodi
principali e le relazioni che si instaurano tra di essi. L’elemento fondamentale di
tale diagramma è la “classe”, schematizzata da un rettangolo tripartito, come da
figura 5.3: nella fascia in alto viene annotato il nome della classe, che la identifica
univocamente nell’ambito del progetto; nella fascia intermedia c’è l’insieme degli
attributi, cioè le caratteristiche che le sono proprie; l’ultima fascia in basso è l’elenco
dei metodi, ossia le azioni che una classe può compiere. Molto spesso non è necessario
dettagliare una classe esplicitandone gli attributi e i metodi; in tali frangenti, per
semplicità si può semplificare il diagramma scrivendone solo il nome.
Il paradigma della programmazione ad oggetti prevede che gli attributi e i metodi
di una classe possano essere pubblici o privati. Se un attributo o un metodo è
dichiarato come privato, ad esso si può accedere solo dall’interno della classe che lo
contiene. Viceversa, un attributo o un metodo dichiarato pubblico è liberamente
100
5 – Il programma su Palm
nome classe
−attributo1
−attributo2
+metodo1()
+metodo2()
Figura 5.3.
Schema grafico di una classe in un diagramma UML
accessibile da tutte le altre classi del progetto. Come regola generale gli attributi
che indicano lo stato di un oggetto sono dichiarati privati, mentre i metodi che
modificano gli attributi sono dichiarati pubblici. In tal modo si implementa un
meccanismo di sicurezza implicito: l’unico modo per modificare lo stato di un oggetto
è chiedere all’oggetto stesso di modificarlo chiamando un suo metodo pubblico.
É invalsa la consuetudine che i metodi pubblici di una classe che modificano il
valore di un attributo seguano una nomenclatura formata dal nome dell’attributo
preceduto dal prefisso “set”. I metodi che leggono il valore di un attributo hanno la
nomenclatura formata dal nome dell’attributo preceduto dal prefisso “get”. Quindi
ad esempio
setAttributo1(nuovo_valore)
setAttributo2(nuovo_valore)
sono due metodi che impostano il valore di “attributo1” e “attributo2”;
getAttributo1()
getAttributo2()
sono due metodi che leggono il valore dei medesimi attributi. Quando si disegna il
diagramma delle classi, per semplicità, non si specificano i metodi getter e setter in
quanto la loro presenza è implicita.
Le relazioni che legano tra di loro le classi sono principalmente di tre tipi:
• Relazione di composizione: una classe A, detta componente, è in relazione
di composizione con una classe B, detta contenitore, se ogni oggetto istanza di
B contiene al suo interno una o più istanze di A; graficamente la composizione
è indicata da una freccia con punta romboidale piena;
• Relazione di aggregazione: è concettualmente identica alla relazione di
composizione, ma più debole, nel senso che alcune istanze della classe contenitore possono non contenere la classe componente; graficamente viene resa con
una freccia dalla punta romboidale vuota;
101
5 – Il programma su Palm
• Relazione di generalizzazione: una classe A è una generalizzazione di una
classe B se ogni oggetto istanza di B eredita gli attributi e i metodi di A,
aggiungendone di nuovi per specializzarsi; in altre parole la relazione di generalizzazione instaura un rapporto di ereditarietà, in cui A è la classe padre
(detta anche “superclasse”) e B è la classe figlia; graficamente tale relazione
viene resa con una freccia dalla punta triangolare vuota;
• Relazione di associazione: è la relazione più generica che lega due classi A
e B per indicare che queste si relazionano tra loro: A può chiamare metodi di
B e viceversa; sono associazioni tutte le relazioni che non possono considerarsi
composizioni, aggregazioni o generalizzazioni.
Nella figura 5.4 è riportato lo schema grafico delle relazioni che legano le classi in
un Class Diagram. Poichè in un programma mediamente complesso è facile arrivare
A
A
A
A
B
B
B
B
Composizione
Aggregazione
Generalizzaz.
Associazione
Figura 5.4.
Schema grafico delle relazioni in un Class Diagram
alla definizione di decine di classi, è comodo organizzarle in insiemi omogenei che
prendono il nome di package. Il criterio di omogeneità viene stabilito dai progettisti
contestualmente all’utilità nel progetto che si sta sviluppando.
Diagramma temporale
Se con il Class Diagram si modellano il numero e il tipo di oggetti che compongono
un software, il diagramma temporale permette di prototipare il processo seguito
dall’applicazione, ossia la sequenza di interazioni tra gli oggetti che consentono al
programma di elaborare le informazioni in input per produrre dei risultati in output.
102
5 – Il programma su Palm
I diagrammi temporali si sviluppano in due dimensioni: l’asse verticale rappresenta il tempo, con valori crescenti verso il basso; l’asse orizzontale riporta la
sequenza di operazioni. Uno dopo l’altro, nell’ordine in cui entrano in gioco, sono
illustrati gli oggetti del programma. Una freccia indica l’invio di un messaggio, ossia
la chiamata di un metodo da parte di un oggetto; dei rettangoli disposti verticalmente lungo l’asse temporale rappresentano il periodo di esecuzione del metodo, al
termine del quale si genera la risposta. Nella figura 5.5 è illustrato un esempio di
Figura 5.5.
Esempio di Sequence Diagram per l’interzione tra due oggetti
diagramma temporale in cui un oggetto di nome “Oggetto1” invia un messaggio a
“Oggetto2” per l’esecuzione di un metodo e ne riceve la risposta.
5.4.3
Diagramma delle classi di ArcheoMap
Per tracciare il Class Diagram di ArcheoMap si parte dall’analisi dei requisiti esposta
nella sezione 5.4.1 per estrarne i concetti fondamentali da modellare. Dal momento
che i programmi su palmare utilizzano un’interfaccia grafica, è conveniente suddividere il progetto in due parti: una relativa al design degli elementi grafici (dipendente
dalla piattaforma di sviluppo), ed una che si occupa della gestione dei dati (indipendentemente dal dispositivo impiegato), in modo da mantenere separata la logica
di presentazione dalla logica di accesso alle informazioni.
Progetto dell’interfaccia grafica
Come esplicitato nel primo punto, i programmi per palmare hanno un’interfaccia
grafica. Questo implica che è necessario prevedere il design di una serie di form,
termine con il quale si designa l’area dello schermo su cui gli utenti vedono elementi
grafici come bottoni, campi di testo e liste per leggere le informazioni e impartire
comandi. Sebbene ogni form abbia un suo design e una sua logica funzionale, è
possibile identificare un sottinsieme di caratteristiche comuni a tutti. In particolare
103
5 – Il programma su Palm
ogni form ha un codice identificativo che lo contraddistingue nell’ambiente di esecuzione; ha una lista di oggetti grafici che ne definiscono l’interfaccia e un menu. È
possibile anche trovare dei metodi comuni, per definire i quali tuttavia è necessario
prima fare una piccola digressione sulla programmazione ad eventi.
Start
no
evento?
si
processa
evento
no
coda
piena?
si
no
wait
Figura 5.6.
Diagramma di flusso di un evento
Quando si deve gestire un’interfaccia grafica va tenuto in conto che gli input
da parte dell’utente (ad esempio la pressione su un bottone o la scrittura di un
testo) giungono in modo asincrono, vale a dire casualmente. Questo mal si integra
con il processo di esecuzione di un programma che solitamente segue un percorso
logico stabilito, funziona cioè in modo sincrono. Per ovviare a questo problema
tutti i sistemi operativi moderni si basano sull’approccio ad eventi. Il sistema itera
continuamente in un ciclo simile a quello mostrato nella figura 5.6: quando viene
scatenato un evento, per esempio perchè l’utente ha premuto un bottone, il sistema
operativo testa il contenuto di una zona di memoria in cui vengono accodati gli
eventi non ancora processati. Se la coda è vuota l’evento viene immediatamente
servito, altrimenti rimane in attesa fino a quando non è il suo turno. Al termine
della procedura il sistema torna al punto di partenza. Le operazioni che devono
essere compiute per processare un evento sono indicate dal programmatore in sede
di progetto e implementazione dell’applicativo.
Per esempio, nell’API di PalmOS viene fornita la funzione “FrmHandleEvent()”
che si occupa di smistare gli eventi provenienti dall’interfaccia grafica verso altre
routine più specifiche sulla base del tipo di evento che deve gestire. Quando viene
aperto un form “FrmHandleEvent()” chiama la funzione “FrmOpenEvent()” in cui
104
5 – Il programma su Palm
vanno scritte le operazioni da compiere all’apertura del form; quando viene chiuso
chiama la funzione “FrmCloseEvent()”; quando giunge un evento da parte di un
bottone chiama “CtlSelectEvent()”; quando l’evento è scatenato da una lista
chiama “LstSelectEvent()”; quando un utente opera su un campo di testo chiama
“FldChangedEvent()” ed infine chiama “MenuEvent()” per gestire gli eventi del
menu. Altri sistemi operativi utilizzano nomi diversi per le procedure da chiamare
ma le funzioni messe a disposizione sono analoghe.
È chiaro che tutte le procedure di gestione degli eventi sono comuni ad ogni
form e quindi possono essere definite una volta sola all’interno di una classe generica
“GenericForm” e poi sovrascritte dagli altri form secondo necessità. Nella figura
5.7 è illustrato lo schema grafico di tale classe e nella tabella 5.1 ne è fornita la
documentazione.
GenericForm
−formId
−GUIobjects
−Menu
+FrmHandleEvent()
+FrmOpenEvent()
+FrmCloseEvent()
+CtlSelectEvent()
+LstSelectEvent()
+FldChangedEvent()
+MenuEvent()
+GetObjectPtr()
Figura 5.7.
Schema grafico della classe “GenericForm”
Gli elementi grafici interattivi previsti da PalmOS e inclusi nei form di ArcheoMap sono principalmente tre: bottoni, liste e campi di testo. Per ognuno di essi
si definisce una classe che ne descrive le caratteristiche, come riportato nella figura
5.8: ogni elemento grafico ha delle caratteristiche comuni, quali la dimensione e lo
stato corrente (attivo o disattivo), che possono essere raccolte in una classe generica
“GUIObject”. Le classi che descrivono il particolare elemento grafico ereditano da
questa gli attributi comuni e l’espandono con altri specifici. Cosı̀ la classe “Button”
aggiunge l’attributo “label” in cui viene scritta l’etichetta corrente del bottone; la
classe “List” ha l’attributo “items” che indica la collezione di voci della lista; ed
infine la classe “TextField” aggiunge l’attributo “text” per tener traccia del testo
correntemente visualizzato.
105
5 – Il programma su Palm
Attributi
formId
GUIObjects
Menu
Metodi
FrmHandleEvent()
identificatore del form
collezione di oggetti grafici
descrizione di un menu contestuale al form
gestisce gli eventi del form e ne smista le richieste di
servizio a metodi più specifici
FrmOpenEvent()
gestisce l’evento associato all’apertura del form
FrmCloseEvent()
gestisce l’evento associato alla chiusura del form
CtlSelectEvent()
gestisce gli eventi generati dalla pressione di pulsanti nel
form
LstSelectEvent()
gestisce gli eventi generati dalla selezione di un elemento
di una lista
FldChangedEvent() gestisce gli eventi generati dalla modifica di un campo
di testo
MenuEvent()
gestisce gli eventi scatenati dal menu
GetObjectPtr()
restituisce il riferimento ad un oggetto grafico del form
Tabella 5.1.
Documentazione per la classe GenericForm
GUIObject
−size
−status
Button
−label
Figura 5.8.
List
−items
TextField
−text
Diagramma delle classi degli oggetti dell’interfaccia grafica
A questo punto si è definita l’infrastruttura a partire dalla quale è possibie progettare l’interfaccia grafica dell’applicazione. Per definire quali e quanti form devono
essere gestiti è necessario analizzare il punto tre dei requisiti. Innanzitutto è richiesto
che il software mostri l’elenco di progetti di ArcheoMap e per ognuno ne visualizzi le relative informazioni. La soluzione pensata è di creare un form che presenti
106
5 – Il programma su Palm
un elenco di progetti e un campo di testo in sola lettura. Quando l’utente seleziona un progetto tra quelli presenti nella lista, il campo di testo viene compilato
con i dati che lo riguardano. Da un punto di vista progettuale questo si traduce
in una classe “ProjectsForm”, che estende “GenericForm” a cui aggiunge i metodi “LoadProjectData()” e “ShowProjectData()”, come rappresentato nella figura
5.9. Il primo, quando invocato, carica dalla memoria i dati relativi al progetto; il
secondo li visualizza all’utente.
GenericForm
Projects
List
ProjectsForm
Project
+LoadProjectData()
TextField
+ShowProjectData()
Figura 5.9.
Diagramma delle classi per “ProjectsForm”
Soluzioni del tutto analoghe si sono adottate per i restanti form che si devono occupare della gestione delle liste: “LocationsForm” (figura 5.10) per la lista
delle località; “ArticlesForm” (figura 5.11) per la lista degli articoli che compongono il diario di scavo; “ImagesForm” (figura 5.12) per la lista della immagini che
compongono la galleria fotografica.
Leggermente diverso il form con l’elenco dei reperti. Poichè infatti ogni reperto è
accompagnato da informazioni testuali e da una lista di riferimenti, le liste da gestire
sono due. Quando è selezionato un reperto dalla lista principale, viene compilato un
breve campo di testo con i dettagli del reperto e la lista dei riferimenti. La figura
5.13 mostra il diagramma delle classi per “FindsForm”.
Nei requisiti si richiede che l’utente, cliccando su uno dei riferimenti, possa visualizzare i dettagli di articoli, immagini e schede ministeriali. Questo comporta
la definizione di almeno altri tre form. Le informazioni rilevanti di un articolo di
diario si evincono dallo schema entità relazioni del database (vedi figura 2.7) e sono:
l’autore, la data di creazione, il titolo e il testo. Si progetta quindi un form chiamato
“ArticleEditForm” composto da quattro campi di testo, uno per ogni dettaglio che
si intende visualizzare. Nella figura 5.14 è riportato il diagramma delle classi che
modella questo form.
107
5 – Il programma su Palm
GenericForm
Locations
List
LocationsForm
Location
TextField
+LoadLocationData()
+ShowLocationData()
Figura 5.10.
Diagramma delle classi per “LocationsForm”
GenericForm
Articles
List
ArticlesForm
Article
TextField
+LoadArticleData()
+ShowArticleData()
Figura 5.11.
Diagramma delle classi per “ArticlesForm”
Per quel che riguarda le immagini, le informazioni rilevanti che appaiono nello
schema E-R (figura 2.8) sono data, autore e note. Viene quindi progettato un nuovo
form chiamato “ImageEditForm” composto da tre campi di testo, il cui modello è
riportato in figura 5.15.
Più complicata è la gestione della scheda ministeriale. Tale documento è infatti
composto da oltre cinquanta campi di testo (vedi figure 2.10 e 2.11), troppi per essere
compresi in un unico form, date le ridotte dimensioni dello schermo di un palmare.
La soluzione che si è dovuto giocoforza adottare è stata quella di dividere il contenuto della scheda ministeriale su più form, chiamati “MinistrySheetEditForm”,
quattordici per l’esattezza: ognuno di essi è composto da alcuni campi di testo, nei
quali sono riportati i dettagli della scheda.
108
5 – Il programma su Palm
GenericForm
Images
List
ImagesForm
Image
TextField
+LoadImageData()
+ShowImageData()
Figura 5.12.
Diagramma delle classi per “ImagesForm”
GenericForm
References
Find
List
List
FindsForm
+LoadFindData()
+LoadReferencesData()
Find
TextField
+ShowFindData()
+ShowFindReferences()
Figura 5.13.
Diagramma delle classi per “FindsForm”
I form “ArticleEditForm”, “ImageEditForm” e “MinistrySheetEditForm” possono essere utilizzati anche per aggiungere e modificare nuovi articoli di diario, nuove
immagini o nuove schede ministeriali. Per distinguere di volta in volta se vadano
usati in modalità lettura, modifica o inserimento, alle classi che li modellano si è
aggiunto un attributo “mode” che può assumere uno dei tre valori. Se il form viene
aperto in modalità sola lettura i campi sono precompilati e l’utente può solo leggerli
e non modificarli; in modalità modifica i campi sono precompilati e l’utente può
cambiarne il contenuto; in modalità inserimento i form sono vuoti e l’utente deve
provvedere da sè a compilarli.
109
5 – Il programma su Palm
Author
DateTime
Body
Title
TextField
TextField
TextField
TextField
ArticleEditForm
−mode
+LoadArticleData()
Figura 5.14.
Diagramma delle classi per “ArticleEditForm”
Author
DateTime
Notes
TextField
TextField
TextField
ImageEditForm
−mode
+LoadImageData()
Figura 5.15.
Diagramma delle classi per “ImageEditForm”
Progetto delle classi di dati
Come specificato nei requisiti, l’applicativo deve gestire i dati di progetti, località,
articoli di diario, immagini, reperti e schede ministeriali. Ognuno di questi elementi
può essere modellato con una classe, in cui ne vengono specificati gli attributi e i
metodi. Per definire queste classi si fa riferimento ancora una volta allo schema entità
relazioni del database in quanto il loro compito è quello di mantenere in memoria
durante l’esecuzione del programma le singole informazioni sui dati di ArcheoMap
che devono essere gestite dai form.
Sul modello della relazione “progetto” di figura 2.5 si definisce la classe “Project”
rappresentata in figura 5.16: gli attributi sono i medesimi, l’unica novità è costituita dal metodo “toString()” il cui compito è quello di restituire al chiamante
una stringa di testo in cui sono riportati gli attributi di un’istanza della classe. Tale metodo non è l’unico: sono definiti anche i metodi getter e setter per leggere e
110
5 – Il programma su Palm
impostare il valore dei singoli attributi, ma che per brevità non sono mostrati nei
Class Diagram.
Project
−projectID
−name
−description
−internetAddress
−email
−phone
−dateStart
−dateEnd
+toString()
Figura 5.16.
Schema grafico della classe “Project”
In modo analogo si definisce la classe “Location” (vedi figura 5.17) che corrisponde all’entità “località” definita nella figura 2.3; la classe “Article” (vedi
figura 5.18) che introduce nel progetto dell’applicazione l’entità “articolo” di figura 2.7; la classe “Image” (vedi figura 5.19) equivalente all’entità “immagine” di
figura 2.8; la classe “MinistrySheet”, parzialmente rappresentata in figura 5.21; e
le classi “Find” e “Reference” (vedi figura 5.20) per trattare reperti e riferimenti
per i quali si rimanda agli schemi di figura 2.9 e 2.19. La relazione che lega queste
due ultime classi è un’aggregazione, cioè una composizione facoltativa, perchè un
reperto può non avere riferimenti associati.
Le classi che compongono l’interfaccia grafica e quelle che modellano i tipi di dato
non sono indipendenti le une dalle altre, bensı̀ cooperano tra di loro per assecondare
i comandi impartiti dagli utenti. Per esemplificare come si realizza l’interoperabilità
tra i due insiemi di classi, si analizza nel dettaglio cosa avviene quando l’utente, dal
form con l’elenco dei progetti, sceglie una voce dalla lista per visualizzarne i dettagli
nel campo di testo.
Nella figura 5.22 è riportato il diagramma temporale per “ProjectsForm”:
1. L’utente apre il form. L’evento di apertura viene gestito dal metodo “FrmOpenEvent()”, il quale si occupa di inizializzare le variabili interne dell’interfaccia;
2. Durante l’esecuzione del metodo “FrmOpenEvent()” viene inizializzata la lista
dei progetti: viene letto dalla memoria l’elenco dei progetti di ArcheoMap e
111
5 – Il programma su Palm
Location
−LocationID
−public
−excavation
−dateStart
−dateEnd
−modernName
−ancientName
−city
−state
−address
−coordinates
−description
−internetAddress
−email
−phone
−notes
+toString()
Figura 5.17.
Schema grafico della classe “Location”
Article
−articleID
−locationID
−visible
−creationDate
−modificationDate
−author
−title
−body
+toString()
Figura 5.18. Schema grafico della classe “Article”
i nomi di questi sono inseriti nella lista, operazione che viene compiuta dal
metodo “SetItems()” della classe “ListObject”;
112
5 – Il programma su Palm
Image
−imageID
−locationID
−creationDate
−author
−fileName
−notes
+toString()
Figura 5.19.
Schema grafico della classe “Image”
Find
Reference
−findID
−referenceID
−locationID
−objectID
−creationDate
−objectType
−author
−author
−findName
−creationDate
−coordinates
+toString()
+toString()
Figura 5.20.
Schema grafico della classe “Find”
3. L’utente seleziona il nome di un progetto dalla lista: questo evento viene
gestito dal metodo “LstSelectEvent()”;
4. Per servire la richiesta dell’utente, viene dapprima chiamato il metodo “LoadProjectData()” che si occupa di istanziare in memoria un oggetto della classe
“Project” in cui sono caricati i dettagli del progetto selezionato;
5. Sull’oggetto istanziato al punto precedente viene chiamato il metodo “toString()” per ottenere la stringa che descrive il progetto e questa viene
impostata nel campo di testo “TextObject”.
Al termine di questo processo l’utente può leggere i dettagli del progetto da lui
selezionato. Sequenze del tutto analoghe si applicano agli altri form del programma
ArcheoMap.
113
5 – Il programma su Palm
MinistrySheet
−sheetID
−findID
−creationDate
−locationID
− etc
+toString()
Figura 5.21.
Figura 5.22.
Schema grafico della classe “MinistrySheet”
Diagramma temporale del form “ProjectsForm”
Gestione dei permessi
Come richiesto dai requisiti, il software deve gestire i permessi di accesso alle varie
sezioni di ArcheoMap, seppure in modo semplificato rispetto a quanto implementato
su Web. Lo scenario di utilizzo prevede che i team di archeologi abbiano a disposizione un insieme di palmari, da assegnare ognuno ad una persona specifica che è
responsabile dei suoi dati. Quando l’utente riceve il palmare per la prima volta,
viene inizializzato con i dati a cui l’utente ha accesso in lettura. In questo modo
l’unica autorizzazione da controllare all’interno del programma sono i permessi in
scrittura. A tale scopo si introduce un’ulteriore classe “Permission” il cui schema
è presentato in figura 5.23.
114
5 – Il programma su Palm
Permission
−locationId
−objectTyps
−writable
Figura 5.23.
Schema grafico della classe “Permission”
Ogni permesso ha come attributo l’identificatore della località, il tipo di elemento
a cui il permesso si riferisce (articolo di diario, immagine o reperto) e un valore
booleano che indica se l’utente può scrivere o modificare quell’elemento. All’interno
della logica del programma, quando l’utente vuole creare un nuovo diario o una
nuova immagine, viene consultato l’oggetto di classe “Permission” corrispondente e
se ne testa il campo “writable”: se asserito l’operazione viene consentita, altrimenti
viene mostrato un messaggio di errore e l’operazione bloccata.
5.4.4
Codifica
Al termine della progettazione si sono prodotti un’insieme di grafici che modellano
il funzionamento del software sia per quel che riguarda le strutture dati impiegate,
sia per quel che concerne le interazioni tra di loro e con l’utente. Si è cosı̀ potuto
descrivere in modo sufficientemente accurato l’intero funzionamento dell’applicativo
indipendentemente dall’architettura hardware destinata all’esecuzione. La fase di
codifica ha il compito di trasporre questi grafici in un liguaggio di programmazione
da cui ottenere l’eseguibile per una determinata piattaforma di riferimento, che nel
caso di ArcheoMap è un dispositivo Palm dotato di sistema operativo PalmOS. Il
passaggio da UML a codice non è complicato: se si utilizza un linguaggio di programmazione ad oggetti, infatti, è possibile tradurre quasi immediatamente le classi,
i loro attributi e i metodi in istruzioni; quel che richiede attenzione è l’implementazione dei metodi, ossia la scrittura della loro logica di funzionamento che durante la
fase di progetto è stata solo accennata ma non dettagliata.
Le problematiche che vanno affrontate nella fase di codifica sono principalmente
due:
• Scegliere che linguaggio di programmazione utilizzare;
• Scegliere di quali strumenti avvalersi durante la scrittura del codice.
115
5 – Il programma su Palm
Linguaggio di programmazione: C++
L’API fornita da PalmOS agli sviluppatori è scritta nativamente in linguaggio C, il
quale presenta il difetto di non supportare la programmazione ad oggetti. Ne esiste
però una versione più evoluta, che ne ricalca la sintassi e i costrutti fondamentali,
integrandoli con il paradigma della programmazione ad oggetti: tale linguaggio è il
C++, che è quello scelto per scrivere il codice dell’applicazione. Poichè il C è a tutti
gli effetti un sottinsieme del C++, è stato comunque possibile utilizzare le funzioni e
le procedure dell’API di PalmOS, mentre per la scrittura dei nuovi tipi di dato si sono
trascritte le classi con il loro attributi e metodi, cosı̀ come progettati nelle sezioni
precedenti. A supporto della stesura del codice si è inoltre utilizzata una libreria di
classi fornita dalla Towertech, le quali mettono a disposizione un’infrastruttura ad
oggetti che consente di accedere a numerose funzioni dell’API di PalmOS secondo
uno stile Object Oriented, migliorando l’organizzazione e la pulizia dei sorgenti. A
titolo d’esempio viene mostrato di seguito la sequenza di istruzioni in C++ per
definire la classe “Article”, il cui modello si è visto nella figura 5.18
class Article {
private:
Int32
UInt32
Boolean
DateTimeType
DateTimeType
Char
Char
Char
articleId;
locationId;
visible;
creationDate;
modificationDate;
*author;
*title;
*body;
public:
Article()
Article(db_articles *p)
~Article()
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
void
SetArticleId(Int32 id)
Int32
GetArticleId()
void
SetLocationId(UInt32 id)
UInt32 GetLocationId()
void
SetVisible(Boolean flag)
Boolean GetVisible()
void
SetCreationDate()
DateTimeType GetCreationDate()
void
SetModificationDate()
116
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
5 – Il programma su Palm
DateTimeType GetModificationDate()
void
SetAuthore(Char *name)
Char * GetAuthor()
void
SetTitle(Char *title)
Char * GetTitle()
void
SetBody(Char *body)
Char * GetBody()
Char * ToString()
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
SECTION_PLUSPLUS;
}
Si può vedere come la definizione della classe all’interno del codice segua da vicino
quanto tracciato nel Class Diagram, a ulteriore conferma che un buon progetto
consente di velocizzare la fase di codifica.
Dal precedente frammento di istruzioni si ha lo spunto per introdurre una particolarità della programmazione sui dispositivi Palm: le sezioni di codice. L’architettura
hardware adottata da Palm non è in grado di gestire programmi più grossi di 32
KB; si tratta di un limite rilevante perchè nel caso di applicazioni complesse come
quella sviluppata per ArcheoMap è facile eccedere tale dimensione. Esiste tuttavia
una soluzione: quella di creare codice multi-segmento. Per realizzarlo, si definiscono
delle sezioni, a cui viene assegnato un nome, e ogni qual volta si dichiara un metodo o una funzione è necessario indicare in quale sezione va inserito. Nel caso di
ArcheoMap si sono create quattro sezioni:
• “SECTION FORMS” nel quale è raccolto tutto il codice macchina che si occupa
della gestione dei form;
• “SECTION AUTODB” nel quale è raccolto il codice che gestisce le strutture dato
per l’accesso alla memoria in lettura o in scrittura;
• “SECTION PLUSPLUS” nel quale sono raccolti i metodi delle classi;
• “SECTION UTILS” nel quale sono raccolte le funzioni di utilità;
Nella definizione della classe “Article” vista sopra, ad esempio, i metodi sono tutti
assegnati alla sezione “SECTION PLUSPLUS”. Tale aspetto del processo di sviluppo
è strettamente legato alla piattaforma Palm, motivo per cui viene affrontato non
nella fase di progetto ma nella fase di codifica. Questo dimostra come la fase di
codifica, pur se adeguatamente supportata da un buon progetto iniziale, non va
comunque intesa come un procedimento meccanico, perchè può presentare, come in
questo caso, delle problematiche sue proprie.
117
5 – Il programma su Palm
Strumenti di sviluppo
Il linguaggio C++ è un linguaggio compilato, il che significa che, differentemente
dai linguaggi di scripting come il PHP, per essere eseguito non ha bisogno di un
interprete, ma necessita di essere tradotto in linguaggio macchina, operazione che
prende il nome di “compilazione”. In ambiente Linux, e più in generale nel mondo
Open Source, il compilatore per eccellenza è il GCC (Gnu C/C++ Compiler ), il
quale è in grado di eseguire il cosiddetto cross compiling, di cui ora viene fornita
una semplice spiegazione.
Normalmente un compilatore prende come input i file con il codice sorgente
scritto in C o C++, ne traduce le istruzioni in un formato intermedio su cui può
effettuare delle ottimizzazioni, ed infine crea il codice macchina. Il problema è che
il codice macchina utilizzato da un normale PC è diverso da quello riconosciuto
da un’architettura hardware completamente differente come quella di Palm. Per
poter quindi sviluppare su PC ma produrre in output un eseguibile per PalmOS
è necessario affidarsi ad un cross compiler. Sotto tale nome si identificano quegli
strumenti di sviluppo che eseguono su normale PC, ma che generano codice macchina
per architetture differenti.
La variante del GCC che permette di effettuare il cross compiling prende il
nome di “m68k-palmos-gcc”, dove “m68k” sta per Motorola 68000, la famiglia di
processori di cui sono dotati i dispositivi prodotti dalla Palm. Tale compilatore
mette a disposizione una serie di opzioni che consentono di modificare, entro certi
limiti, il codice macchina generato. Tali opzioni vengono passate al compilatore da
linea di comando seguendo una sintassi che è standard nel mondo Unix/Linux, con
il nome dell’opzione preceduto dal segno meno “-”. In particolare le opzioni che si
sono usate in fase di compilazione sono:
-fno-exceptions : disabilita l’uso delle eccezioni nella gestione degli errori;
-fno-rtti : disabilita l’uso dei template in C++;
-O2 obbliga il compilatore ad effettuare delle ottimizzazioni, se possibile, sul codice
generato.
In questo modo si è ottenuto un eseguibile dalle dimensioni più compatte, quindi
che non necessita di ulteriori sezioni di codice, e più veloce a svolgere le operazioni
richieste.
Per testare il programma ci si è avvalsi dell’uso dell’emulatore POSE (Palm OS
Emulator ). Un emulatore è un software che permette l’esecuzione di applicazioni
scritte per ambienti diversi da quello sul quale l’emulatore viene eseguito. Nel caso
di ArcheoMap con POSE è stato possibile far girare il programma scritto per Palm
su PC, senza il bisogno di installarne ogni volta una nuova versione sul dispositivo
reale, che avrebbe reso molto più lungo e tedioso il lavoro di sviluppo. A titolo
118
5 – Il programma su Palm
di esempio, tutte le immagini presenti in questo capitolo non provengono da un
dispositivo Palm reale ma dall’emulatore POSE.
5.5
Panoramica sul software finito
Per concludere il capitolo, viene presentata una carrellata di immagini che illustra
le caratteristiche del prototipo di software rilasciato al termine del progetto e della
codifica.
Quando l’utente avvia il programma la schermata che gli si pone di fronte è
quella di figura 5.24 e mostra l’elenco dei progetti di ArcheoMap. Se si seleziona un
progetto dall’elenco ne vengono mostrati i dettagli nel campo di testo subito sotto.
Figura 5.24.
Schermata con l’elenco dei progetti
Per poter accedere alle sezioni successive del programma è necessario inserire il
proprio username e la propria password nel form delle preferenze visualizzato in
figura 5.25, a cui si accede dal menu del form dei progetti. La coppia username e
password viene resettata dopo una sincronizzazione e memorizzata sul dispositivo.
Se l’utente che sta usando il programma non corrisponde a quello impostato al
momento della sincronizzazione non è possibile proseguire oltre.
Se l’utente ha effettuato correttamente il login, cliccando sul bottone “Apri” del
form dei progetti può accedere all’elenco delle località che fanno parte del progetto
selezionato, come mostrato in figura 5.26. Il pulsate “<” consente di tornare alla
119
5 – Il programma su Palm
Figura 5.25.
Figura 5.26.
Schermata delle preferenze
Schermata con l’elenco delle località
120
5 – Il programma su Palm
schermata precedente, mentre con il pulsante “Apri” si accede alla schermata di
figura 5.27 in cui sono riportati in modo più esteso e chiaro i dettagli inerenti alla
località selezionata e sono visualizzati dei nuovi pulsanti che consentono di accedere
alle sue parti: il diario di scavo, la galleria fotografica e l’elenco dei reperti.
Figura 5.27.
Schermata con i dettagli di una località
Il form del diario di scavo si presenta come in figura 5.28: nella parte superiore
c’è l’elenco degli articoli del diario ordinati in modo decrescente per data. Selezionando un articolo viene compilato automaticamente il campo sottostante in cui sono
mostrati l’autore, la data di creazione e modifica e il testo. Dei tre pulsanti presenti
al fondo del form: “Cancella” cancella l’articolo selezionato, “Nuovo” ne fa creare
uno nuovo, “Modifica” fa modificare l’articolo corrente. Tutte e tre le operazioni
sono sottoposte ad un controllo sui permessi dell’utente e vengono bloccate nel caso
in cui non si disponga delle necessarie autorizzazioni.
Se i requisiti sono soddisfatti, la creazione di un nuovo articolo o la modifica di
uno già esistente si effettuano in un form che si presenta come in figura 5.29. Dopo
aver compilato i campi si può scegliere se salvare l’articolo oppure annullare tutto e
tornare alla schermata precedente.
L’elenco dei reperti viene visualizzato come in figura 5.30: nella parte superiore è
la lista con i nomi dei reperti ordinati in modo decrescente per data. Quando l’utente
ne sceglie uno, sono compilati automaticamente i campi “Autore” e “Coordinate” e
viene popolata la lista sottostante con l’elenco dei riferimenti associati al reperto.
121
5 – Il programma su Palm
Figura 5.28.
Figura 5.29.
Schermata con l’elenco degli articoli di diario
Schermata per la modifica / creazione di un articolo
122
5 – Il programma su Palm
I bottoni “Cancella”, “Nuovo” e “Modifica” rispettivamente cancellano il reperto
selezionato (attenzione, il reperto e non il riferimento), ne creano uno nuovo oppure
modificano uno già esistente, sempre previa verifica della autorizzazioni. Il pulsante
“Vedi” visualizza invece il contenuto del riferimento selezionato.
Il form di creazione e modifica reperti non viene qui descritto perchè di esso se
ne parlerà più diffusamente nel capitolo successivo a proposito del GPS.
Figura 5.30.
Schermata con l’elenco dei reperti e relativi riferimenti
Se si vuole visitare la galleria fotografica bisogna cliccare sul pulsante “Galleria”
nel form dei dettagli della località per trovarsi di fronte alla schermata di figura
5.31. La disposizione degli elementi è quella ormai nota: in alto c’è l’elenco delle
immagini che compongono la galleria e sotto un campo di testo in cui vengono scritti
i dettagli dell’immagine quando ne viene selezionata una dalla lista. I pulsanti sul
fondo permettono di cancellare, creare e modificare le immagini, mentre il pulsante
“Vedi” visualizza la foto. Come specificato nei requisiti della sezione 5.4.1 al punto
nove, nella memoria del palmare sono contenute le sole immagini scattate dal dispositivo dopo l’ultima sincronizzazione, per cui solo queste sono visualizzabili; le altre
vengono omesse per risparmiare spazio.
Quando si vuole creare una nuova immagine o modificarne una già esistente si
opera nel form di figura 5.32. Oltre ai campi di testo da compilare per specificare
i dettagli da associare all’immagine, c’è il pulsante “Foto” che apre l’interfaccia di
123
5 – Il programma su Palm
Figura 5.31.
Figura 5.32.
Schermata con l’elenco delle immagini della galleria
Schermata per la creazione o modifica di un’immagine
124
5 – Il programma su Palm
Figura 5.33.
Schermata di gestione della fotocamera integrata
gestione della macchina fotografica integrata per quei dispositivi che ne possiedono
una (vedi figura 5.33).
125
Capitolo 6
Il GPS
6.1
Introduzione al GPS
Il sistema GPS (Global Positioning System) è un sistema satellitare con copertura
globale che consente di rilevare la propria posizione geografica e la propria altitudine
rispetto al livello del mare.
Figura 6.1.
Uno dei satelliti della rete GPS
Il progetto alla base del GPS nacque per opera del Dipartimento della Difesa
degli Stati Uniti a partire dagli anni ’70 e fu completato nel 1993. Inizialmente fu
progettato a scopi militari: il suo compito era quello di fornire un metodo di rilevamento della posizione per seguire gli spostamenti dei mezzi militari al suolo e la
navigazione di sommergibili e navi da guerra; fin dai primi anni ’90 però fu evidente
l’utilità del sistema anche a scopi civili, per cui si decise di rendere disponibile il servizio a tutti, pur continuando ad essere finanziato e gestito dal Dipartimento della
Difesa USA. Per questioni di sicurezza nazionale il segnale trasmesso dai satelliti che
126
6 – Il GPS
compongono il sistema GPS rimase differenziato fino all’anno 2000 in due differenti
livelli di precisione, in quella che veniva chiamata Selective Availability: un segnale
ad uso civile, trasmesso in chiaro, degradato alla fonte per consentire una correttezza nel rilevamento non inferiore ai 300 m, e un secondo segnale ad uso militare,
trasmesso cifrato, che consentiva una precisione molto maggiore, con incertezza inferiore al metro. Nel 2000 il presidente Bill Clinton decise di terminare la Selective
Availability e di aprire anche ai civili l’uso del segnale ad alta precisione, dando il
via alla diffusione di massa, a cui si sta assistendo in questi anni, di ricevitori GPS
a basso costo in grado di determinare la posizione con elevata precisione.
Il sistema GPS è costituito da 24 satelliti orbitanti ad un’altezza di circa 20000
km, di cui 21 effettivamente utilizzati nella trasmissione del segnale di georeferenziazione, mentre i restanti tre sono di scorta, ossia è previsto che entrino in azione solo
in caso di guasto o inoperatività degli altri. Ogni satellite ha una vita media prevista
di circa 10 anni, dopo i quali vanno sostituiti. Il segnale che viene trasmesso alle frequenze di 1.2 e 1.5 MHz contiene le cosiddette effemeridi, vale a dire le informazioni
necessarie a localizzare la posizione del satellite e il tempo di trasmissione.
I ricevitori GPS sono delle antenne in grado di agganciare la frequenza di trasmissione del segnale e ricavare da essi le informazioni necessarie alla determinazione
delle coordinate spaziali. Per ottenere questo risultato i ricevitori si basano sullo
scostamento esistente tra l’orario in cui il segnale è stato trasmesso e l’orario in cui
viene ricevuto. Se T1 è l’istante in cui il segnale viene trasmesso, T2 è l’istante in
cui viene ricevuto è c è la velocità delle onde elettromagnetiche nel vuoto, si ricava
che la distanza D tra antenna e satellite è:
D = c(T2 − T1 )
Conoscere la distanza da un solo satellite non è sufficiente a determinare la posizione
poiché, non sapendo nulla della relativa posizione dell’antenna (ad esempio se è su
una spiaggia o su una montagna e con che angolo vede il cielo) le posizioni possibili
ricadono in una sfera di raggio D. Se si ha il segnale di due satelliti la posizione è
determinata dall’incrocio di due sfere di raggio noto che geometricamente parlando
determinano un cerchio. Con il segnale di tre satelliti, la posizione del ricevitore
è data dall’intersezione di tre sfere di raggio noto che danno luogo a due punti, di
cui normalmente uno può essere scartato perché situato ad altissima quota (vedi
figura 6.2). Se ne deduce quindi che con tre satelliti è già possibile determinare la
posizione del ricevitore. Con il segnale di un quarto satellite la misurazione è certa
e precisa perché l’intersezione di quattro sfere individua un unico punto. In realtà
la misurazione non è precisissima, come già detto, ma è soggetta ad uno scarto di
circa mezzo metro dovuto principalmente alla differenza di precisione tra gli orologi
atomici al Cesio di cui sono dotati i satelliti e gli orologi al quarzo di cui sono dotati
i ricevitori.
127
6 – Il GPS
Figura 6.2.
Rilevamento della posizione dall’incrocio di tre sfere
I calcoli sopra riportati sono svolti dall’elettronica interna dei ricevitori e prendono il nome tecnico di fix. Normalmente la prima rilevazione è più lenta perché
necessita di una fase preliminare di sincronizzazione tra ricevitore e satelliti, mentre
le rilevazioni successive, che avvengono circa una volta al secondo, sono molto più
veloci.
Il principale difetto del sistema GPS è quello di poter funzionare solo se il cielo è
ben visibile, quindi non è possibile applicare le tecniche di rilevazione della posizione all’interno di edifici o grotte. Questo comporta che la mappatura dei reperti in
ArcheoMap possa procedere correttamente solo per i ritrovamenti avvenuti all’aria
aperta, negli altri casi rimane necessario affidarsi ad un sistema di grigliatura. Ad
esempio, nel caso di oggetti ritrovati all’interno di una tomba la soluzione proposta
è quella di georeferenziare l’ingresso della tomba, e poi di catalogare i reperti all’interno affidandosi ad una griglia di riferimento, cosa che comunque rientra già tra le
tecniche di misurazione adottate dagli archeologi.
6.2
Standard NMEA
NMEA sta per National Marine Electronics Associations ed è un’ente statunitense,
di cui fanno parte produttori e rivenditori di apparecchiature elettroniche in campo
nautico, che si occupa della definizione di alcuni standard utilizzati da tali apparecchi. Uno di questi, l’NMEA 0183, definisce le caratteristiche di interfacciamento
tra un dispositivo GPS e un calcolatore. Lo standard NMEA si occupa quindi di
128
6 – Il GPS
stabilire il tipo e la composizione dei messaggi che un’antenna GPS invia ad un computer o a un palmare per comunicargli le informazioni di localizzazione determinate
dopo la fase di fix. Si ricorderà dalla sezione precedente che lo standard GPS è nato
come ausilio alla navigazione delle navi da guerra, non deve quindi stupire che sia
proprio un ente che si occupa di apparecchiature marinare a definirne l’interfaccia
di comunicazione.
Il modello trasmissivo trattato nello standard NMEA è quello seriale: un unico
canale su cui i bit di informazione viaggiano uno per volta. Nel caso dei PC e
dei Palmari sono mezzi di comunicazione seriale le porte RS232, USB, bluetooth
e infrarossi. La velocità di riferimento è 4800 bps, ma sono comunque considerate
velocità superiori fino a 38.4 kbps.
I dati che un ricevitore GPS comunica ad un calcolatore sono delle frasi (o
sentence come definito nello standard) costituite da sequenze di caratteri ASCII e il
loro formato prevede un prefisso all’inizio, poi una serie di campi separati da virgola
senza spazi, ed i caratteri di “a capo” (CR + LF) per indicarne la fine.
$PREFISSO,campo1,campo2,...,campoN,CRLF
Lo standard NMEA, dovendo contemplare un’ampia varietà di apparecchiature, definisce un certo numero di frasi (circa una sessantina), ma nel caso dei GPS commerciali ne vengono utilizzate pochissime. In particolare una frase standard che tutti i
ricevitori GPS comunicano è quella che inizia con il prefisso “$GPRMC”.
$GPRMC (Recomended Minimum Specific) è una delle frasi più complete, comprendente dati essenziali relativi a data e ora del fix, posizione rilevata, velocità e qualità
della ricezione. I campi significativi trasmessi sono 10 e sono spiegati in dettaglio
nella tabella 6.1. Un esempio di stringa inviata dal ricevitore GPS è la seguente:
Campo
1
2
3
4
5
6
7
8
9
Formato
hhmmss.ss
A
nnnn.nn
A
nnnn.nn
A
n.n
n.n
ddmmyy
Tabella 6.1.
Descrizione
Ora
Stato: A = attivo, V = nullo
Latitudine
Emisfero: N = nord, S = sud
Longitudine
Verso: W = ovest, E = est
Velocità espressa in nodi
Direzione del movimento espressa in gradi
Data
Descrizione dei campi della frase $GPRMC
$GPRMC,204619.999,V,4530.6671,N,00916.9484,E,,,160706
129
6 – Il GPS
Le informazioni contenute sostanzialmente dicono che il messaggio è stato inviato
alle ore 20:46:19 del giorno 16/07/2006 e che la posizione rilevata è 45◦ 30.6671’ Nord,
009◦ 16.9484’ Est. Il secondo campo contiene il simbolo V, il che significa che la frase
di esempio è nulla, quindi va scartata (un motivo per cui l’informazione è nulla è
ad esempio perché si è perso il segnale del satellite). Si nota inoltre che non tutti i
campi sono presenti: nel caso del messaggio mostrato qui sopra i campi sette e otto
sono vuoti, ad esempio perché il ricevitore non è stato in grado di rilevarne il valore
oppure perché la particolare implementazione dello standard fornita dal costruttore
prevede di inviare questi dati in altri messaggi. I dati relativi ad ora e posizione
sono però presenti in tutte le sentence di questo tipo inviate da tutti i ricevitori.
6.3
Implementazione
Nell’ambito del progetto ArcheoMap il ricevitore GPS serve a realizzare la mappatura dei reperti. Lo scenario di utilizzo preso da riferimento prevede che gli archeologi
siano dotati di un dispositivo palmare dotato di ricevitore GPS; quando viene ritrovato un reperto l’utente può inserirlo direttamente nel programma e rilevarne sul
momento la posizione. Per raggiungere questo obiettivo è necessario innanzitutto
trovare un modo per far dialogare il palmare con il ricevitore; e in secondo luogo
effettuare il parsing delle frasi NMEA, ossia leggerle e distinguere il contenuto dei
vari campi.
6.3.1
Interfacciamento Palmare / GPS
I dispositivi di palmari dispongono di alcune interfacce seriali per comunicare con
altri apparecchi elettronici; i modelli più recenti sono dotati di interfaccia USB, Bluetooth e infrarossi, mentre i modelli più vecchi dispongono solamente dell’interfaccia
infrarossi e seriale RS232. Ognuna di queste interfacce utilizza lo stesso protocollo
di trasmissione, ma le modalità in cui viene aperta la connessione e la gestione degli
eventi associati è diverso da caso a caso. Per poter gestire la comunicazione verso
un GPS è dunque necessario sapere su quale porta questo è collegato e utilizzare i
comandi corretti per essa.
Per cercare di mantenere la modularità del codice, si è cercato di progettare
le classi per la comunicazione con il GPS in modo tale da slegarsi il più possibile dal tipo di hardware utilizzato. Si è dunque definito l’insieme di classi di
figura 6.3: una super-classe chiamata GPSConnector definisce gli aspetti comuni
della comunicazione verso il GPS, mentre un certo numero di classi derivate ne
sovrascrivono i metodi per adattarli alla specifica porta di comunicazione a cui è
connesso il dispositivo. Nella tabella 6.2 sono descritti brevemente i metodi della
super-classe GPSConnector. Come si vede dallo schema i metodi che necessitano di
130
6 – Il GPS
GPSConnector
−connected
+DeviceConnect()
+DeviceDisconnect()
+isConnected()
+ReadGPS()
+GetPosition()
BtGPSConnector
SerialGPSConnector
IrGPSConnector
+DeviceConnect()
+DeviceConnect()
+DeviceConnect()
+DeviceDisconnect()
+DeviceDisconnect()
+DeviceDisconnect()
+ReadGPS()
+ReadGPS()
+ReadGPS()
Figura 6.3.
Schema grafico delle classi di interfacciamento al GPS
Metodo
DeviceConnect()
DeviceDisconnect()
isConnected()
ReadGPS
GetPosition
Tabella 6.2.
Descrizione
Effettua la connessione al ricevitore GPS
Disconnette il ricevitore GPS
Restituisce true se il ricevitore è già connesso
Legge il flusso di dati emesso dal ricevitore
Indica la posizione ricavandola dalla frase $GPRMC
Documentazione dei metodi di GPSConnector
sovrascrittura sono DeviceConnect(), DeviceDisconnect() e ReadGPS(), che per
svolgere le proprie funzioni necessitano di conoscere le specifiche dell’hardware. I
metodi isConnected() e GetPosition() viceversa non necessitano di essere sovrascritti perché il primo effettua semplicemente un controllo sull’attributo booleano
connected, mentre il secondo si occupa di fare il parsing dei dati ottenuti dal ricevitore, quindi in entrambi i casi operazioni che sono indipendenti dall’hardware
utilizzato.
Quando nel codice deve essere interrogato il ricevitore GPS per ottenere la posizione, viene istanziata la classe specifica, ad esempio BtGPSConnector se l’antenna è
Bluetooth, ma per interagire vengono chiamati i metodi della classe GPSConnector.
In questo modo, sfruttando l’ereditarietà e il polimorfismo1 , se si cambia il tipo di
1
Si dice “polimorfismo” la proprietà della programmazione ad oggetti per cui, data una classe
padre e una classe figlia, è possibile chiamare sulla classe figlia i metodi della classe padre.
131
6 – Il GPS
connessione è sufficiente cambiare il solo tipo di oggetto da istanziare, mentre tutto
il resto del codice rimane il medesimo.
Per la creazione del prototipo del programma per palmari di ArcheoMap si è
deciso di dare implementazione della sola classe BtGPSConnector per la connessione
ai dispositivi Bluetooth, in quanto la maggior parte dei ricevitori GPS per apparecchi
mobile che si trovano in commercio sfruttano questo sistema di comunicazione.
6.3.2
Parsing delle frasi NMEA
All’interno del metodo GetPosition() della classe GPSConnector viene effettuata
una scansione dei dati trasmessi al palmare dal GPS e quando viene incontrata la
sequenza di caratteri $GPRMC vuol dire che il ricevitore sta trasmettendo la sentence
che contiene le informazioni sul fix da cui ricavare la posizione. L’operazione che
il software esegue prende il nome di parsing, intendendo con tale termine il processo atto ad analizzare il flusso continuo di dati proveniente dal dispositivo per
determinarne la struttura e verificarne la coerenza con quanto atteso.
$GPRMC
Ok
Ora
Errore
Est/Ovest
Stato
Longitudine
Latitudine
Nord/Sud
Figura 6.4.
Diagramma a stati di un parser NMEA
Il processo di parsing può essere modellato con la macchina a stati mostrata nella
figura 6.4. Una macchina a stati è un sistema dinamico in cui viene modellato un
processo discreto elencandone tutti gli stati possibili e tutte le transizioni che portano
da uno stato ad un altro. Nel caso del parsing di una frase NMEA gli stati possono
132
6 – Il GPS
essere identificati con il riconoscimento dei campi, più due stati ausiliari “Errore” e
“Ok” per contrassegnare il successo o l’insuccesso dell’operazione. Il funzionamento
di una macchina a stati può essere rappresentato tramite un diagramma in cui i
singoli stati sono mostrati come dei rettangoli dagli angoli smussati, e delle frecce
che li collegano per rappresentare le transizioni. Il punto di ingresso e di uscita del
diagramma sono indicati da un puntino e da un cerchio rispettivamente.
Nel caso della frase cercata, la macchina a stati che modella il parsing funziona
in questo modo:
1. All’avvio del metodo GetPosition(), si controlla se la stringa di testo corrente
inizia con la sequenza di caratteri $GPRMC;
2. Se cosı̀ non è si rimane sullo stato corrente fino a quando la condizione precedente non viene soddisfatta, al che ci si sposta nello stato successivo;
3. Se la stringa non è terminata, allora vuol dire che si è trovato il primo campo
della frase NMEA, quello contenente l’ora e ci si sposta allo stato successivo.
Se invece tale condizione non è soddisfatta vuol dire che si è verificato un
errore di trasmissione e si passa allo stato di errore;
4. Se al punto precedente non si è verificato errore, si testa nuovamente la stringa: se questa non è terminata, allora si è trovato il secondo campo della
frase NMEA, quello contenente la Latitudine, e ci si può spostare allo stato
successivo; altrimenti ci si sposta sulla condizione di errore;
5. Il funzionamento prosegue in questo modo fino all’ultimo stato, quello in cui
viene determinato il verso della longitudine (Est/Ovest), e se questa è corretta
si esce dalla macchina a stati.
Il sistema modellato rispetta tre requisiti essenziali delle macchine a stati: è
invariante (a parità di condizioni iniziali il risultato non cambia), è dinamico (evolve
nel tempo passando da una condizione ad un’altra in funzione dei dati di input e
degli stati precedenti) ed è discreto (le variabili di ingresso ed uscita, cosı̀ come
tutti gli stati intermedi, possono solo assumere valori discreti). Al termine del
processo di parsing il metodo GetPosition() restituisce perciò la posizione rilevata
dal ricevitore GPS, nel caso in cui tutti gli stati si succedano correttamente, oppure
un segnale di errore nel caso in cui il formato della stringa non sia quello atteso.
6.4
Il form di modifica e inserimento reperti
A questo punto si hanno gli strumenti necessari per capire tutte le funzionalità del
form di modifica e inserimento dei reperti, la cui trattazione era stata rimandata
nel capitolo precedente.
133
6 – Il GPS
Figura 6.5.
Schermata del form di modifica reperti
Nella figura 6.5 si vede un’immagine del form. Nella parte alta ci sono tre
campi di testo, di cui i primi due, il nome dell’autore e la data di creazione, sono
precompilati e non si possono modificare, mentre il terzo, il nome del reperto, deve
essere compilato dall’utente. In mezzo si trova il campo per l’inserimento delle
coordinate. Se si preme il bottone viene attivata la procedura di connessione al
GPS via Bluetooth.
Normalmente i dispositivi mobile tengono spento il Bluetooth per risparmiare
batteria e per ragioni di sicurezza (essendo il Bluetooth un collegamento Wireless è
una possibile fonte di intrusioni indesiderate nel sistema). Tenendo conto di questo,
il processo si sviluppa in questa sequenza:
1. Se il Bluetooth non è acceso, una finestra di dialogo chiede all’utente se vuole
accenderlo automaticamente;
2. Se la risposta alla domanda precedente è affermativa, avviene l’operazione
cosiddetta di discovery: il sistema operativo scansiona la rete alla ricerca di
dispositivi che utilizzino questo sistema di comunicazione;
3. I dispositivi rilevati sono elencati in una lista, da cui l’utente può selezionare
il GPS;
4. Una volta selezionato il ricevitore, viene effettuata la connessione vera e propria;
134
6 – Il GPS
5. A connessione stabilita il programma resta in ascolto sulla porta Bluetooth
fino a quando non arriva la frase $GPRMC da cui leggere la posizione; il tempo
d’attesa può variare da pochi secondi fino anche ad un minuto o due a seconda
della bontà del segnale di ricezione dai satelliti;
6. Una volta effettuato il parsing della frase NMEA, il campo di testo delle
coordinate viene compilato automaticamente dal programma;
7. La connessione al dispositivo viene terminata.
Alla fine del processo il nuovo reperto è mappato, in quanto se ne conosce la posizione
di ritrovamento, con uno scarto approssimativo di un metro nel caso dei comuni
dispositivi commerciali, ormai venduti a prezzi contenuti.
Nella parte bassa del form è contenuta la lista dei riferimenti. I bottoni “+” e
“−” a destra permettono di aggiungere e togliere elementi dalla lista. Quando si
vuole aggiungere un nuovo riferimento viene prima richiesto che tipo di riferimento
si intende collegare (immagine o articolo di diario) e viene quindi presentato un form
come quello di figura 6.6 da cui è possibile scegliere l’articolo da associare.
Figura 6.6.
Schermata del form di scelta degli articoli
Selezionando il bottone Scheda si apre infine il primo dei quattordici form per la
creazione / modifica della scheda ministeriale, mostrato nella figura 6.7.
135
6 – Il GPS
Figura 6.7.
Schermata del form di creazione della scheda ministeriale
136
Capitolo 7
La sincronizzazione tra palmare e
Database
7.1
Introduzione alla sincronizzazione dei palmari
Con il termine “sincronizzazione” si intende il coordinamento tra due fonti di elaborazione che operano su una risorsa condivisa per far sı̀ che tale risorsa sia allineata
e non presenti errori dovuti all’accesso concorrente. Tale definizione è generica e
si adatta ad una molteplicità di casi, per ognuno dei quali occorre studiare una
soluzione adatta. L’aspetto di interesse ai fini della presente tesi è lo studio della
sincronizzazione tra palmari e database server.
Nel caso dei dispositivi palmari la sincronizzazione è una funzionalità estremamente importante, per la quale viene fornito supporto sia dall’hardware del palmare
stesso sia da parte del sistema operativo. La ragione di questo risiede nella natura di
tali apparecchi: essendo dotati di capacità di memorizzazione molto limitate, sono
concepiti come sistemi di supporto per l’elaborazione dei dati in quelle condizioni
in cui l’impiego di un personal computer risulterebbe poco pratico o addirittura
impossibile, senza tuttavia poterne sostituire del tutto le funzionalità. Scopo della
sincronizzazione è salvare i dati modificati su PDA su un sistema di memorizzazione
più stabile, quale ad esempio un PC (nel caso di informazioni strettamente personali) o in un database server (nel caso di informazioni aziendali o di comune interesse).
La principale difficoltà che va affrontata nel progettare un sistema di sincronizzazione è la presenza di eventuali conflitti. Il palmare e il sistema di archiviazione
(PC o server ) sono degli elaboratori indipendenti che accedono in modo parallelo
ad una risorsa condivisa (i dati): al momento della sincronizzazione è dunque necessario verificare se ci sono conflitti, ed in tal caso, se possibile, risolverli. Si possono
normalmente adottare tre tipi di politiche differenti:
1. Sincronizzazione verso il server: i dati sono sempre copiati dal palmare verso il
137
7 – La sincronizzazione tra palmare e Database
server, e in caso di conflitto si sceglie di considerare valida la versione presente
sul palmare. Con questa politica il server contiene a tutti gli effetti una copia
di backup di quanto memorizzato su PDA;
2. Sincronizzazione verso il palmare: i dati sono sempre copiati dal server verso
il palmare, e in caso di conflitto si sceglie di considerare valida la versione
presente sul server;
3. Sincronizzazione a due vie: è il tipo di politica formalmente più corretto, ma
più complicato da gestire; le due versioni dei dati sono allineate ove possibile,
aggiungendo su PDA ciò che manca sul server e viceversa, e in caso di conflitto si può scegliere se considerare valida la versione più recente, oppure se
richiedere esplicitamente l’intervento umano per risolverlo.
Nel presente capitolo verrà studiato il problema della sincronizzazione tra i dati
contenuti nel database di ArcheoMap e quelli elaborati dagli archeologi sul palmare
in loro dotazione, analizzando i vari aspetti del problema e descrivendo la soluzione
proposta.
7.2
Requisiti per la sincronizzazione
Si vuole realizzare un sistema software che consenta la sincronizzazione tra i dati
presenti nel database server e quelli elaborati sul palmare. Il software ha duplice
scopo:
• Inizializzare il contenuto del palmare la prima volta che questo viene assegnato
ad un utente, caricando nella memoria del dispositivo i dati necessari;
• Assicurare l’allineamento tra la versione dei dati presente sul palmare dell’utente e quella mantenuta sul server di ArcheoMap.
Nello svolgere il secondo tipo di operazioni, occorre tenere in conto che tra le
due versioni dei dati possono esserci conflitti. Per come è strutturata la gestione
dei permessi in ArcheoMap, i dati inseriti da un utente (articoli del diario di scavo, immagini della galleria, schede ministeriali e reperti) possono essere modificati
unicamente dall’utente stesso oppure da un suo superiore (capo progetto e direttore scavo) per cui è ragionevole ritenere che tali conflitti non si verifichino troppo
frequentemente.
Volendo rendere il più centralizzata possibile la gestione delle informazioni di
ArcheoMap, il software che si occupa della sincronizzazione deve risiedere sul server
che ospita il database ed essere raggiungibile tramite collegamento di rete.
138
7 – La sincronizzazione tra palmare e Database
7.3
Inizializzazione del palmare
Nell’ambito del progetto di ArcheoMap ogni archeologo può venire dotato di un
palmare da utilizzare durante la campagna di scavo per annotare sul luogo le informazioni ritenute rilevanti, per poi immetterle, non appena possibile sul database
centrale. Quando un utente riceve il palmare, questo è come una tabula rasa: contiene solamente il programma di ArcheoMap ma nessun dato su cui lavorare. Per
effettuare l’inizializzazione per prima cosa l’utente deve inserire nell’apposito form
delle preferenze il proprio username e password. Effettua quindi la sincronizzazione
con il server, a seguito della quale vengono caricati nel palmare i dati di competenza dell’utente per permettergli di lavorare. Per svolgere questo tipo di operazione
il programma di sincronizzazione deve essere in grado di lavorare sul particolare
formato file utilizzato dai dispositivi Palm.
7.3.1
PDB, il formato file di PalmOS
I tradizionali personal computer conservano i dati su un dispositivo di memorizzazione permanente, l’hard-disk, fisicamente distinto dalla memoria volatile, la RAM,
in cui i dati sono suddivisi in cartelle e sotto-cartelle. Tale organizzazione gerarchica prende il nome di file system e necessita di un adeguato supporto da parte del
sistema operativo per essere letto e mantenuto. Nella maggior parte dei dispositivi
palmari non esiste un disco interno, esiste solamente una certa (ridotta) quantità
di memoria volatile, costantemente alimentata elettricamente dalle batterie, anche
quando il palmare è apparentemente spento. La memoria volatile viene utilizzata
contemporaneamente per conservare i dati e per l’esecuzione dei programmi. Per
una tale architettura l’uso di un file system non è una soluzione ottimale, per questo
PalmOS (il sistema operativo di Palm) non organizza i propri dati in cartelle o sottocartelle e il concetto di file è molto differente rispetto a quello noto dai Personal
Computer1 .
Tutti i dati del palmare sono organizzati in una struttura chiamata PDB, Palm
DataBase, il cui schema descrittivo è mostrato in figura 7.1. Ogni PDB è costituito
da un header in cui sono riportate informazioni a carattere globale quali il nome del
file, il tipo, il creatore del PDB, il numero di record di cui è composto e l’ordinamento
da applicare sui dati. Questi ultimi sono contenuti in una serie di record, ossia blocchi
di memoria, di dimensione non superiore ai 64KB, strutturati in un insieme di campi,
il cui numero e tipo dipendono dal genere di informazione che devono contenere. I
record sono disposti in memoria in locazioni diverse non necessariamente contigue
1
I dispositivi con PalmOS sono in realtà in grado di utilizzare delle schede di espansione di
memoria (Secure Digital o Memory Card, per lo più) per le quali esiste un file system e il concetto
di file è analogo a quello noto dai PC. Tuttavia, per compatibilità con i dispositivi meno recenti,
il software di ArcheoMap lavora esclusivamente sulla memoria interna e quindi sui PDB.
139
7 – La sincronizzazione tra palmare e Database
Figura 7.1.
Schema descrittivo della PDB
e, per tenere traccia della loro posizione, nell’header del PDB viene mantenuta
una lista dei puntatori ai record che lo compongono. In questo modo se occorre
aggiungere un nuovo record ad un PDB, il sistema operativo non deve spostare gli
altri dati ma è sufficiente allocare memoria e impostare opportunamente l’header.
Questo tipo di struttura ricorda molto da vicino le tabelle di un database, in cui i
record rappresentano le righe e i campi le colonne, ma l’analogia si limita a questo: i
PDB non dispongono infatti di un linguaggio di interrogazione come è l’SQL nel caso
dei database veri e propri, e l’accesso ai singoli record avviene in modo sequenziale
anziché indicizzato.
7.3.2
Classi Perl per la creazione dei PDB
L’API fornita da PalmOS non mette a disposizione strumenti Open Source per creare
e manipolare i PDB, occorre quindi rivolgersi altrove. La scelta è ricaduta su un
modulo scritto in Perl che mette a disposizione le funzioni adatte allo scopo.
Le informazioni che devono essere memorizzate nel palmare sono le stesse già
trattate nel database: località, progetti, articoli di diario, immagini, reperti e schede
ministeriali. Per ognuno di questi tipi di dato si è creata, a partire dagli strumenti
messi a disposizione dal modulo Perl, una classe apposita, il cui modello generico è
quello di figura 7.2. Gli attributi che sono passati al modulo Perl per la creazione
di un PDB sono tre:
• pdbName è il nome del PDB. Nella scelta del nome si è adottata la seguente
convenzione:
– Il PDB contenente l’elenco dei progetti, che è unico, ha nome am-projects.pdb;
140
7 – La sincronizzazione tra palmare e Database
PDBGeneric
−pdbName
−pdbCreator
−pdbType
+newRecord()
+packRecord()
+unpackRecord()
Figura 7.2.
Classe generica per la creazione dei PDB
– I PDB con l’elenco delle località appartenenti ad ogni progetto hanno nome am-locs-n.pdb dove n è la chiave primaria del progetto nel
database;
– I PDB con l’elenco degli articoli che compongono il diario di scavo di
ogni località hanno nome am-blog-n.pdb dove n è la chiave primaria
della località nel database;
– I PDB con l’elenco delle immagini che compongono la galleria fotografica
di ogni località hanno nome am-gal-n.pdb dove n è la chiave primaria
della località nel database;
– I PDB con l’elenco dei reperti appartenenti ad una località hanno nome
am-finds-n.pdb dove n è la chiave primaria della località nel database;
– Infine i PDB con l’elenco delle schede ministeriali appartenenti ad una
determinata località hanno nome am-sheet-n dove n è la chiave primaria
della località nel database.
• pdbCreator è una breve stringa della lunghezza massima di quattro caratteri
in cui è contenuto un identificativo della persona o della società che ha creato i
file; nel caso di ArcheoMap tale stringa è uguale per tutti i PDB ed è “TTam”;
• pdbType è un’altra stringa di quattro caratteri che identifica il tipo di dato
contenuto nel PDB. Nel caso di ArcheoMap le sigle utilizzate sono le seguenti:
– prjs per il PDB dei progetti;
– pjlo per i PDB delle località;
– blog per il diario di scavo;
– galr per la galleria;
141
7 – La sincronizzazione tra palmare e Database
– fnds per i reperti;
– msht per le schede ministeriali;
La coppia pdbCreator / pdbType consente di identificare in modo univoco
una tipologia di dati nella memoria del palmare. Ad esempio, se si vogliono
ottenere tutti i PDB dei diari di scavo è sufficiente ricercare quelli che hanno
nell’header creatore “TTam” e tipo “blog”.
I campi di cui è composto ogni record dipendono dal tipo di dato e ricalcano gli
attributi delle entità progettate per il database. Ad esempio nel caso di un PDB
per gli articoli di diario i campi sono gli attributi dello schema di figura 2.7. Oltre
ai campi derivati dal database, ogni record ne presenta tre aggiuntivi: in uno viene
riportata la data dell’ultima sincronizzazione; nel secondo la data di ultima modifica
del record sul palmare (nel caso in cui ne sia stata fatta una, altrimenti coincide con
la data di sincronizzazione); il terzo infine è un campo booleano che indica se nel
corso dell’ultima sincronizzazione si sono verificati dei conflitti. L’utilità di questi
campi aggiuntivi verrà spiegata in seguito.
Per gestire i record si sono definiti nelle classi tre metodi:
• newRecord(): crea la struttura del record che si vuole aggiungere al PDB
raccogliendone i campi costitutivi;
• packRecord(): trasforma il record creato precedentemente in una stringa di
bit da inserire in memoria. Questo tipo di operazione è necessaria perchè
i campi estratti dal database sono numeri o stringe in caratteri ASCII che
vanno compattati e ridotti in formato puramente binario;
• unpackRecord(): effettua l’operazione inversa del metodo precedente: dato
un record in forma binaria ne restituisce i singoli campi.
7.3.3
Processo di inizializzazione
Le classi definite secondo il modello visto nella sezione precedente vengono utilizzate
nel processo di inizializzazione per creare i PDB da installare nella memoria del
palmare. Tale processo si sviluppa secondo i passi descritti qui di seguito:
1. L’utente che riceve il palmare privo di dati apre il programma per immettervi
il proprio username e password;
2. Viene avviata la procedura di sincronizzazione via rete tramite il programma
HotSync che è parte integrante del sistema operativo PalmOS e perciò si trova
su ogni palmare;
142
7 – La sincronizzazione tra palmare e Database
3. Il software di sincronizzazione rileva la mancanza di PDB appartenenti ad
ArcheoMap (perché mancano PDB aventi creatore “TTam”) e riconosce quindi
che non si tratta di una normale sincronizzazione ma di una inizializzazione;
4. Lato server, viene aperta una connessione al database e si effettuano una serie
di query per ottenere i dati di competenza dell’utente che sta effettuando
l’inizializzazione. L’utente viene riconosciuto da username e password inserite
nelle preferenze;
5. Per ogni tipo di dato viene creato il corrispondente PDB assegnandogli nome,
creatore e tipo secondo le convenzioni stabilite più sopra;
6. Per ogni oggetto che va inserito nei PDB viene prima creato il record chiamando il metodo newRecord() e poi ridotto in forma binaria tramite il metodo
packRecord();
7. I PDB creati sono copiati nella memoria del palmare;
Al termine del processo l’utente si trova il dispositivo inizializzato, pronto all’uso. Se
infatti apre il programma di ArcheoMap trova l’elenco dei progetti di suo interesse
con i relativi contenuti.
7.4
HotSync, Coldsync e Conduit
Ogni palmare equipaggiato con PalmOS è dotato, di fabbrica, di un pacchetto software con cui iniziare ad utilizzare il dispositivo. Di tale pacchetto software fa parte
HotSync, il programma deputato alla sincronizzazione, di cui nella figura 7.3 è riportata la schermata di accesso. Dal menu in alto è possibile scegliere se il palmare
è connesso al computer con cui effettuare la sincronizzazione in modo diretto (per
mezzo di un cavo USB o seriale) oppure via rete, ed in tal caso permette di specificare se via modem o via TCP/IP. HotSync è anche in grado di sfruttare la connessione
via GPRS, utilizzando un cellulare che supporti questo protocollo di comunicazione
come mezzo per collegarsi alla rete Internet. Una volta scelta la modalità di connessione, l’utente deve cliccare sul bottone al centro della finestra per far avviare
il processo di sincronizzazione. HotSync si aspetta di trovare sull’altro capo della
comunicazione un programma residente in ascolto con cui scambiarsi le informazioni.
Tale programma, nel caso in cui la sincronizzazione debba avvenire verso un
personal computer, viene fornito gratuitamente da PalmOS e ha il nome di PalmDesktop. Pur svolgendo egregiamente i suoi compiti, presenta il problema di essere
disponibile solo per ambiente Microsoft Windows e dell’impossibilità di configurarlo
per l’utilizzo in ambiente server per accettare la connessione via rete di un certo
numero di utenti. Un software Open Source che risponde a tali requisiti è ColdSync,
143
7 – La sincronizzazione tra palmare e Database
Figura 7.3.
Schermata di apertura di HotSync
di cui si è fatto uso nel contesto di questa tesi. Quando ColdSync riceve una richiesta di sincronizzazione da HotSync risponde facendo eseguire un programma esterno
a cui egli provvede a passare come parametri le informazioni necessarie a lavorare
sui PDB. L’architettura di funzionamento prevede quindi che ColdSync si occupi
della sincronizzazione da un punto di vista generico, consentendo di instaurare una
connessione con il palmare e di creare, leggere o modificare i PDB nella memoria del
dispositivo; le operazioni specifiche che occorre effettuare sui dati vengono invece
devolute a dei programmi esterni, che ColdSync chiama al momento opportuno.
Questi programmi prendono il nome di “Conduit”. Per sapere quale Conduit
fare eseguire per trattare un determinato tipo di PDB deve essere scritto un file
di configurazione per ColdSync in cui si associa il tipo di PDB con il nome della
Conduit.
ColdSync distingue tra quattro diversi tipi di Conduit:
• Fetch Conduit: sono attivate subito dopo l’inizio della connessione e il loro
scopo è quello di creare o modificare la copia locale dei PDB prima che questi
vengano confrontati con la versione residente sul palmare;
• Dump Conduit: sono attivate prima di terminare la connessione e il loro
scopo è quello di aggiornare la copia locale dei PDB dopo che questi sono stati
modificati sul palmare;
144
7 – La sincronizzazione tra palmare e Database
• Sync Conduit: occupano la parte principale del processo di sincronizzazione
e il loro scopo è quello di realizzare un confronto tra i dati residenti in locale
e il contenuto dei PDB sul palmare per allinearne i contenuti;
• Install Conduit: sono attivate subito prima che un nuovo PDB venga caricaro nella memoria del palmare e il loro scopo è quello di permettere un
ultimo controllo del file prima di installarlo definitivamente nel dispositivo, ad
esempio per assicurarsi che sia nel formato corretto.
Una volta descritti gli strumenti messi a disposizione dal mondo Open Source
per la sincronizzazione tra un server e un palmare occorre scegliere quale tipo di
Conduit si intende sviluppare e che politica adottare per la risoluzione di eventuali
conflitti tra i dati.
7.5
La Conduit di sincronizzazione dei dati di ArcheoMap
Come richiesto nei requisiti, si deve sviluppare un sistema di sincronizzazione a due
vie, che non può essere ricondotto ad una semplice copia di dati, ma esige una
loro elaborazione per integrare il database con le modifiche effettuate su palmare e
viceversa.
La sincronizzazione a due vie può essere ottenuta tramite l’esecuzione di una
Fetch Conduit seguita da una Dump Conduit: i dati vengono prima aggiornati in
locale, poi le due versioni integrate l’una con l’altra, ed infine i PDB del palmare copiati sul server. Tale meccanismo, apparentemente molto semplice, presenta
tuttavia un paio di complicazioni:
• La sincronizzazione a due vie implementata in questo modo non tratta eventuali conflitti: dà per scontato che la versione presente sul server sia quella
corretta;
• Per come è strutturato il processo di sincronizzazione di ColdSync, le Fetch
Conduit e le Dump Conduit sono processi del tutto separati, e durante la loro
esecuzione viene garantita la connettività al palmare: infatti l’elaborazione
avviene esclusivamente sui dati copiati in locale per i quali non è necessario
colloquiare col dispositivo. Questo però significa che non è possibile interrogare
il palmare per ottenere le informazioni di autenticazione;
• Bisogna trovare un modo per gestire la copia su disco di file con lo stesso nome
ma appartenenti a persone diverse. Se ad esempio due utenti che collaborano
al medesimo sito di scavo (i cui palmari hanno quindi in memoria PDB con lo
145
7 – La sincronizzazione tra palmare e Database
stesso nome) effettuano la sincronizzazione nello stesso momento, è necessario
studiare un meccanismo per tener traccia di quali file appartengono ad un
utente e quali ad un altro.
Per le ragioni sopra elencate si è ritenuto preferibile scrivere una Sync Conduit
che, richiedendo la connessione con il dispositivo per poter essere eseguita, consente
di autenticare il palmare (e quindi l’utente a cui appartiene) nel momento stesso i
cui dati sono elaborati, e di poter gestire i PDB uno per volta, senza necessità di
farne una copia completa su disco, riducendo i rischi di gestione contemporanea dei
dati di più utenti.
Durante la scrittura della Sync Conduit di ArcheoMap si è fatto uso di una
serie di funzioni raccolte sotto il comune nome di SPC (Serialized Procedure Call ),
disponibili solo per tale tipo di Conduit, che offrono un’interfaccia di comunicazione
seriale con il palmare senza necessità di conoscere il protocollo di trasmissione che ne
sta alla base. Tra le funzioni offerte da SPC ve ne sono che permettono di ottenere
i singoli record di un PDB, di conoscere le informazioni mantenute da PalmOS per
ogni file (data di creazione e ultima modifica) e di leggere e impostare l’orologio di
sistema.
La procedura di sincronizzazione che si è progettata si svolge dunque nella
seguente serie di passi:
1. L’utente connette il palmare al server via rete e avvia il programma di HotSync
per effettuare la sincronizzazione;
2. Il software di ColdSync residente sul server rileva la presenza di PDB di ArcheoMap nel palmare, e riconosce che si tratta di una sincronizzazione e non
di una inizializzazione;
3. Viene avviata la Sync Conduit di ArcheoMap che si occupa di recuperare dalla
memoria del dispositivo la username e password dell’utente a cui è assegnato
il palmare e apre una connessione con il database;
4. Tramite le funzioni di SPC, la Sync Conduit elabora un PDB alla volta confrontando i record al suo interno con quanto contenuto nel database e trattando
quei record che generano conflitto;
5. Terminata l’elaborazione delle informazioni viene chiusa la connessione al database e i dati risultano allineati, fatti salvi quelli che hanno causato conflitto.
7.6
Trattamento dei conflitti di sincronizzazione
I conflitti si possono verificare sui dati perché questi sono stati modificati sul palmare
e sul database dopo l’ultima sincronizzazione. Per poter rilevare un conflitto è quindi
146
7 – La sincronizzazione tra palmare e Database
necessario tener traccia, per ogni record, di tre momenti: la data di ultima modifica
sul DB; la data di modifica sul palmare; e la data di ultima sincronizzazione. La
prima informazione risiede sul database, dove ogni entità ha come attributi una
data di creazione e una data di modifica. La data di ultima sincronizzazione e la
data di modifica sul palmare sono invece memorizzate tra i campi dei singoli record
contenuti nei PDB.
Durante il processo di sincronizzazione, prima di elaborare un record, si esegue
un algoritmo di verifica dei conflitti il cui flusso logico è riportato in figura 7.4. Nel
DS = DMP
and
Y
DS = DMD?
copia
Exit
N
Y
DS = DMP
su
and
Palm
DS < DMD?
N
copia
su
Database
Y
DS < DMP
and
DS = DMD?
N
Conflitto
Figura 7.4.
Algoritmo per la rilevazione di conflitti sui record
grafico, per brevità, si è indicato con DS la data di ultima sincronizzazione; con
DM P la data di ultima modifica sul palmare; ed infine con DM D la data di ultima
modifica sul database. Si possono verificare quattro condizioni:
1. Se le tre date coincidono allora i dati non hanno subito modifiche né sul
database né sul palmare, e quindi non è necessario elaborarli;
2. Se la data di modifica sul palmare coincide con la data di ultima sincronizzazione, ma la data di ultima modifica su DB è successiva, significa che la
versione residente sul database è più recente e quindi occorre aggiornare la
versione su palmare;
147
7 – La sincronizzazione tra palmare e Database
3. Viceversa, se la data di modifica sul database coincide con la data di ultima
sincronizzazione, ma la data di ultima modifica su palmare è successiva, significa che la versione residente sul dispositivo è più recente e occorre aggiornare
il database;
4. Se nessuna delle tre precedenti condizioni è verificata, allora i dati sono stati
modificati sia su palmare sia su DB e si è nelle condizioni di conflitto tra
versioni.
Qualora si cada nel caso quattro bisogna scegliere come procedere. Per decidere
quale politica adottare si deve tener conto che gli utenti di ArcheoMap si distinguono in due categorie: utenti normali, che possono modificare esclusivamente i dati da
loro stessi creati; e gli utenti privilegiati (direttore scavo e capo progetto) che possono modificare, oltre ai propri, anche i dati degli utenti che ricadono sotto la loro
responsabilità. Questo significa che un conflitto si può verificare solamente nel caso
in cui i dati immessi da un utente vengano modificati dopo l’ultima sincronizzazione
da un suo superiore.
La risoluzione del conflitto è complicata dalla presenza di due vincoli: un vincolo temporale, che suggerisce di considerare corretta la versione più recente; ed un
vincolo gerarchico che invece spinge a considerare valida la versione modificata dall’utente di grado superiore. I due criteri di scelta sono in contrapposizione, perché
non è detto che la versione modificata dall’utente di grado superiore sia anche la
più recente. Di comune accordo con i committenti del progetto, si è scelto di non
risolvere in modo automatico il conflitto, ma di limitarsi ad una segnalazione di esso
agli utenti interessati, demandando a questi la stesura di una versione definitiva da
memorizzare nel database.
Dal punto di vista implementativo, quando il software di sincronizzazione si
accorge della presenza di un conflitto di dati, imposta un apposito campo nel record
del PDB interessato, e spedisce agli utenti che hanno creato le versioni non allineate
una mail di avviso. Il software di ArcheoMap su palmare, quando deve visualizzare
il record in cui è notificato un conflitto, lo segnala in colore rosso. L’utente in questo
modo è avvisato e, consultando la mail, scopre quale dei suoi superiori ha modificato
i dati in concorrenza e accordarsi con questi per le necessarie correzioni.
148
Capitolo 8
Conclusione
Nella stesura del volume si è cercato di descrivere il lavoro svolto per il progetto Archeomap sotto un duplice punto di vista: quello teorico, con cui si sono prospettate
le diverse impostazioni che il progetto avrebbe potuto prendere, e quello reale, volto
a descrivere la soluzione adottata e a motivare le scelte che via via sono state individuate e accolte. L’obiettivo di quest’opera è infatti fornire al lettore l’idea della
complessità del progetto affrontato e le linee guida che hanno portato alla creazione
del prototipo.
Allo stato attuale è stata realizzata una versione beta del progetto, completa
delle soluzioni trattare nel corso dei capitoli e funzionante in ogni sua parte; inoltre
sono stati effettuati test per individuare e correggere gli eventuali errori. Questo è,
tuttavia, solo il punto di partenza per ulteriori sviluppi: in futuro il lavoro dovrà
essere presentato ad un numero rappresentativo di utenti generici, ossia archeologi
che potenzialmente potrebbero utilizzare questi strumenti, e valutare grazie al loro
contributo le modifiche e migliorie da adottare; il database dovrà essere completato
con maggiori informazioni; lo sviluppo dei software open source utilizzati o il lancio sul mercato di nuovi palmari potranno portare a nuove release del progetto. In
questa seconda fase di Archeomap sarà determinante l’appoggio delle società (Risolviamo e Towertech) che hanno supervisionato l’attività svolta e della I.I.C.E. che,
commissionato il progetto, ora è chiamata a valutarne il risultato.
C’è un ultimo aspetto da chiarire: l’innovatività di Archeomap. E’ giusto sottolineare che non è mai stato creato un sistema di mappatura di siti archeologici in
grado di seguire il lavoro degli studiosi in tutte le sue fasi: direttamente sul campo
grazie alla praticità dei dispositivi palmari per la raccolta delle informazioni, e in ambito decisionale grazie alla catalogazione dei singoli reperti, alla loro localizzazione e
mappatura tramite GPS nella speranza che dalla condivisione delle opinioni e delle
esperienze dei gruppi di ricercatori si possano trarre suggerimenti per indirizzare le
future campagne di scavo.
L’archeologia affascina ed è ancora in gran parte terreno inesplorato per l’utilizzo
149
8 – Conclusione
delle nuove tecnologie come ausilio per gli esperti di settore o come strumento di
diffusione verso il grande pubblico che accoglie sempre con grande fervore le notizie
di nuove scoperte sul nostro passato. Questa situazione potrebbe portare alla messa
a punto di nuove funzionalità in Archeomap attualmente non previste, o a utilizzi
diversi da quelli a cui si era inizialmente pensato che richiederebbero sviluppi del
progetto nuovi e del tutto inimmaginabili.
150
Capitolo 9
Appendice
9.1
Codice per creazione del database
Viene qui di seguito riportato il codice SQL per la creazione del database in PostgreSQL.
CREATE TABLE a r t i c o l o (
i d A r t i c o l o i n t e g e r NOT NULL,
t e s t o t e x t NOT NULL,
t i t o l o t e x t NOT NULL,
d a t a i n s e r i m e n t o timestamp NOT NULL,
d a t a m o d i f i c a timestamp ,
v i s i b i l e boolean ,
i d A u t o r e i n t e g e r NOT NULL,
i d M o d i f i c a t o r e i n t e g e r NOT NULL,
i d L o c a l i t a i n t e g e r NOT NULL
);
CREATE TABLE a u t o r i z z a z i o n e (
idPermesso s e r i a l NOT NULL,
i d U t e n t e i n t e g e r NOT NULL,
i d P r o g e t t o i n t e g e r NOT NULL,
i d L o c a l i t a i n t e g e r NOT NULL
);
CREATE TABLE immagine (
idImmagine s e r i a l NOT NULL,
note t e x t ,
d a t a i n s e r i m e n t o timestamp NOT NULL
151
9 – Appendice
d a t a m o d i f i c a timestamp NOT NULL,
f i l e c h a r a c t e r v a r y i n g ( 1 0 0 ) NOT NULL,
i d A u t o r e i n t e g e r NOT NULL,
i d M o d i f i c a t o r e i n t e g e r NOT NULL,
i d L o c a l i t a i n t e g e r NOT NULL
);
CREATE TABLE l o c a l i t a (
i d L o c a l i t a s e r i a l NOT NULL,
c i t t a c h a r a c t e r v a r y i n g ( 2 0 ) NOT NULL,
comune c h a r a c t e r v a r y i n g ( 2 0 ) NOT NULL,
n a z i o n e c h a r a c t e r v a r y i n g ( 2 0 ) NOT NULL,
s c a v o b o o l e a n DEFAULT t r u e NOT NULL,
i n d i r i z z o character varying (50) ,
coordinate character varying (25) ,
d e s c r i z i o n e t e x t NOT NULL,
i n d i r i z z o i n t e r n e t text ,
note t e x t ,
t e l e f o n o text ,
email text ,
i n d i c a z i o n i text ,
d a t a i n i z i o timestamp with time zone
DEFAULT now ( ) NOT NULL,
d a t a f i n e timestamp with time zone ,
nome nuovo c h a r a c t e r v a r y i n g ( 5 0 ) NOT NULL,
nome antico c h ara ct e r varying ( 5 0 ) ,
f l a g p u b b l i c o b o o l e a n DEFAULT t r u e NOT NULL,
i d P r o g e t t o i n t e g e r NOT NULL,
e l i m i n a t o b o o l e a n DEFAULT f a l s e NOT NULL
);
CREATE TABLE p r o g e t t o (
i d P r o g e t t o i n t e g e r NOT NULL,
nome c h a r a c t e r v a r y i n g ( 5 0 ) NOT NULL,
d e s c r i z i o n e t e x t NOT NULL,
i n d i r i z z o i n t e r n e t text ,
email text ,
t e l e f o n o text ,
d a t a a p e r t u r a timestamp with time zone
DEFAULT now ( ) NOT NULL,
d a t a f i n e timestamp with time zone
152
9 – Appendice
);
CREATE TABLE permesso (
idPermesso s e r i a l NOT NULL,
t i p o p e r m e s s o c h a r a c t e r v a r y i n g ( 2 0 ) NOT NULL
);
CREATE TABLE r e p e r t o (
i d R e p e r t o s e r i a l NOT NULL,
nome t e x t NOT NULL,
d a t a i n s e r i m e n t o timestamp NOT NULL,
d a t a m o d i f i c a timestamp NOT NULL,
coordinate character varying (25) ,
i d A u t o r e i n t e g e r NOT NULL,
i d M o d i f i c a t o r e i n t e g e r NOT NULL,
i d L o c a l i t a i n t e g e r NOT NULL,
e l i m i n a t o b o o l e a n DEFAULT f a l s e NOT NULL
);
CREATE TABLE r i f e r i m e n t o (
i d R i f e r i m e n t o s e r i a l NOT NULL,
i d R e p e r t o i n t e g e r NOT NULL,
i d O g g e t t o i n t e g e r NOT NULL,
t i p o i n t e g e r NOT NULL,
d a t a i n s e r i m e n t o timestamp NOT NULL,
i d U t e n t e i n t e g e r NOT NULL
);
CREATE TABLE s c h e d a m i n i s t e r i a l e (
i d s e r i a l NOT NULL,
u n i t a s t r a t i g r a f i c a text ,
n c a t a l o g o g e n e r a l e text ,
n c a t a l o g o i n t e r n a z i o n a l e text ,
l o c a l i t a i n t e g e r NOT NULL,
anno t e x t ,
area text ,
saggio text ,
s e t t o r e text ,
ambiente t e x t ,
quadrato t e x t ,
quote t e x t ,
153
9 – Appendice
us nat text ,
u s a r t text ,
piante text ,
s e z i o n i text ,
p r o s p e t t i text ,
d e f i n i z i o n e p o s i z i o n e text ,
c r i t e r i d i s t i n z i o n e text ,
modo formazione t e x t ,
componenti organici text ,
componenti inorganici text ,
c o n s i s t e n z a text ,
c o l o r e text ,
misure t e x t ,
s t a t o c o n s e r v a z i o n e text ,
d e s c r i z i o n e text ,
s e q f i s i c a u g u a l e a text ,
s e q f i s i c a s i l e g a a text ,
s e q f i s i c a g l i s i a p p o g g i a text ,
s e q f i s i c a s i a p p o g g i a a text ,
s e q f i s i c a c o p e r t o d a text ,
s e q f i s i c a c o p r e text ,
s e q f i s i c a t a g l i a t o d a text ,
s e q f i s i c a t a g l i a text ,
s e q f i s i c a r i e m p i t o d a text ,
s e q f i s i c a r i e m p i e text ,
s e q s t r a t i g r a f i c a p o s t e r i o r e text ,
s e q s t r a t i g r a f i c a a n t e r i o r e text ,
o s s e r v a z i o n i text ,
i n t e r p r e t a z i o n e text ,
e l e m e n t i d a t a n t i text ,
datazione text ,
p e r i o d o o f a s e text ,
d a t i q u a l i t a t i v i r e p e r t i text ,
campionature t e x t ,
f l o t t a z i o n e text ,
s e t a c c i a t u r a text ,
a f f i d a b i l i t a s t r a t i g r a f i c a text ,
d i r e t t o r e s c i e n t i f i c o text ,
d a t a i n s e r i m e n t o timestamp NOT NULL,
d a t a m o d i f i c a timestamp NOT NULL,
i d A u t o r e i n t e g e r NOT NULL,
154
9 – Appendice
i d M o d i f i c a t o r e i n t e g e r NOT NULL
);
CREATE TABLE u t e n t e (
i d U t e n t e s e r i a l NOT NULL,
nome c h a r a c t e r v a r y i n g ( 8 0 ) NOT NULL,
cognome c h a r a c t e r v a r y i n g ( 8 0 ) NOT NULL,
username c h a r a c t e r v a r y i n g ( 2 0 ) NOT NULL,
password c h a r a c t e r v a r y i n g ( 2 0 ) NOT NULL,
e m a i l c h a r a c t e r v a r y i n g ( 8 0 ) NOT NULL,
l i n g u a c h a r a c t e r ( 2 ) NOT NULL
);
9.2
Codice del mapfile
Viene qui di seguito riportato il codice del mapfile utilizzato per la definizione del
funzionamento di MapServer.
MAP
UNITS DD
EXTENT 6 . 3 3 3 5 . 5 0 0 1 9 . 6 3 4 9 . 0 0
RESOLUTION 360
SHAPEPATH ” data /”
IMAGECOLOR 164 221 255
FONTSET ” f o n t s / f o n t s . l i s t ”
SYMBOLSET ” symbols / symbols35 . sym”
NAME ”ITALIA”
STATUS ON
OUTPUTFORMAT
NAME png
IMAGEMODE RGB
DRIVER ”GD/PNG”
MIMETYPE ” image /png”
EXTENSION ”png”
FORMATOPTION ”INTERLACE=OFF”
END
WEB
TEMPLATE
’ i n d e x . html ’
155
9 – Appendice
IMAGEPATH ’ / opt / archeomap /www/tmp / ’
IMAGEURL ’ / tmp / ’
END
PROJECTION
” p r o j=l a t l o n g ”
e l l p s=WGS84
END
REFERENCE
IMAGE ” g r a p h i c s / r e f e r e n c e . j p g ”
EXTENT 6 . 3 3 3 5 . 5 0 0 1 9 . 6 3 4 9 . 0 0
SIZE 200 205
STATUS ON
MINBOXSIZE 10
COLOR −1 −1 −1
OUTLINECOLOR 255 0 0
END
SCALEBAR
IMAGECOLOR 102 153 204
LABEL
COLOR 255 255 255
SIZE TINY
END
STYLE 1
SIZE 200 2
COLOR 255 255 255
UNITS KILOMETERS
INTERVALS 4
TRANSPARENT OFF
STATUS ON
END
LEGEND
KEYSIZE 12 12
IMAGECOLOR 255 255 255
LABEL
TYPE BITMAP
SIZE MEDIUM
COLOR 0 0 0
156
9 – Appendice
END
POSITION LR
STATUS ON
TEMPLATE ” l e g e n d . html ”
END
# layer dei confini geografici
LAYER
NAME boundary
DATA ” Country Boundaries 3”
STATUS ON
PROJECTION
” p r o j=l a t l o n g ”
” e l l p s=WGS84”
”datum=WGS84”
END
TYPE POLYGON
TRANSFORM ON
METADATA
NOME ” N a z i o n i ”
END
TEMPLATE ’ n a z i o n i . html ’
CLASSITEM ”COLOR MAP”
LABELITEM ”CNTRY NAME”
CLASS
COLOR 170 178 137
OUTLINECOLOR 238 238 187
END
END
LAYER
NAME boundary2
DATA ” Country Boundaries 3”
STATUS ON
PROJECTION
” p r o j=l a t l o n g ”
” e l l p s=WGS84”
”datum=WGS84”
END
TYPE POLYGON
TRANSFORM ON
157
9 – Appendice
METADATA
NOME ” N a z i o n i ”
END
TEMPLATE ’ n a z i o n i . html ’
CLASSITEM ”COLOR MAP”
LABELITEM ”CNTRY NAME”
CLASS
COLOR 170 178 137
OUTLINECOLOR 0 0 0
LABEL
COLOR 0 0 180
TYPE TRUETYPE
FONT a r i a l −bold
SIZE 8
ANTIALIAS TRUE
POSITION AUTO
PARTIALS FALSE
MINDISTANCE 0
BUFFER 0
END
END
END
LAYER
NAME bound
DATA ” Country Boundaries 3”
STATUS ON
PROJECTION
” p r o j=l a t l o n g ”
” e l l p s=WGS84”
”datum=WGS84”
END
TYPE POLYGON
TRANSFORM ON
METADATA
NOME ” Contorno ”
END
CLASSITEM ”COLOR MAP”
LABELITEM ”CNTRY NAME”
CLASS
OUTLINECOLOR 0 0 0
158
9 – Appendice
END
END
# l a y e r con l e immagini d e i
LAYER
NAME ” r a s t e r ”
DATA ” i t a l i a . t i f ”
TYPE r a s t e r
STATUS OFF
METADATA
NOME ” L i v e l l i ”
END
CLASSITEM ” [ p i x e l ] ”
CLASS
EXPRESSION ( [ p i x e l ]
COLOR 139 146 112
END
CLASS
EXPRESSION ( [ p i x e l ]
COLOR 158 160 113
END
CLASS
EXPRESSION ( [ p i x e l ]
COLOR 176 172 124
END
CLASS
EXPRESSION ( [ p i x e l ]
COLOR 196 185 131
END
CLASS
EXPRESSION ( [ p i x e l ]
COLOR 217 199 135
END
CLASS
EXPRESSION ( [ p i x e l ]
COLOR 208 190 128
END
CLASS
EXPRESSION ( [ p i x e l ]
COLOR 204 180 120
END
159
r i l i e v i montuosi
>= 10 AND [ p i x e l ] < 200)
>= 200 AND [ p i x e l ] < 400)
>= 400 AND [ p i x e l ] < 600)
>= 600 AND [ p i x e l ] < 800)
>= 800 AND [ p i x e l ] < 1000)
>= 1000 AND [ p i x e l ] < 1100)
>= 1100 AND [ p i x e l ] < 1200)
9 – Appendice
CLASS
EXPRESSION ( [ p i x e l
COLOR 195 170 116
END
CLASS
EXPRESSION ( [ p i x e l
COLOR 190 160 108
END
CLASS
EXPRESSION ( [ p i x e l
COLOR 182 150 101
END
CLASS
EXPRESSION ( [ p i x e l
COLOR 179 155 111
END
CLASS
EXPRESSION ( [ p i x e l
COLOR 173 158 127
END
CLASS
EXPRESSION ( [ p i x e l
COLOR 170 162 139
END
CLASS
EXPRESSION ( [ p i x e l
COLOR 165 168 151
END
] >= 1200 AND [ p i x e l ] < 1400)
] >= 1400 AND [ p i x e l ] < 1600)
] >= 1600 AND [ p i x e l ] < 1800)
] >= 1800 AND [ p i x e l ] < 2000)
] >= 2000 AND [ p i x e l ] < 2200)
] >= 2200 AND [ p i x e l ] < 2400)
] >= 2400)
END
# l a y e r con l a d i s l o c a z i o n e d e l l e p r i n c i p a l i c i t t à
LAYER
NAME c i t y
DATA ” B Major C i t i e s 1”
TOLERANCEUNITS KILOMETERS
TOLERANCE 20
STATUS ON
PROJECTION
” p r o j=l a t l o n g ”
” e l l p s=WGS84”
”datum=WGS84”
160
9 – Appendice
END
TYPE POINT
TEMPLATE ’ c i t t a . html ’
CLASSITEM ”STATUS”
LABELITEM ”CITY NAME”
METADATA
NOME ” C i t t à ”
END
CLASS
NAME ” C i tt a ’ ”
SYMBOL ’ c i r c l e ’
SIZE 5
COLOR 0 0 0
OUTLINECOLOR 0 0 0
LABEL
COLOR 0 0 0
SHADOWCOLOR 255 255 255
SHADOWSIZE 1 1
TYPE TRUETYPE
FONT a r i a l −bold
SIZE 8
ANTIALIAS TRUE
POSITION UC
PARTIALS TRUE
MINDISTANCE 0
BUFFER 0
END
END
END
# l a y e r con l ’ o r o g r a f i a d e l l ’ I t a l i a
LAYER
NAME r i v e r s
DATA ” R i v e r s 2”
STATUS OFF
PROJECTION
” p r o j=l a t l o n g ”
” e l l p s=WGS84”
”datum=WGS84”
END
TOLERANCEUNITS KILOMETERS
161
9 – Appendice
TOLERANCE 20
TEMPLATE ’ r i v e r . html ’
TYPE LINE
CLASSITEM ”TYPE”
LABELITEM ”NAME”
METADATA
NOME ” Fiumi ”
END
CLASS
NAME ” Fiumi ”
COLOR 0 18 122
LABEL
COLOR 0 18 122
SHADOWCOLOR 255 255 255
SHADOWSIZE 2 2
TYPE TRUETYPE
FONT a r i a l −bold
SIZE 8
ANTIALIAS TRUE
POSITION CC
PARTIALS TRUE
MINDISTANCE 0
BUFFER 0
END
END
END
LAYER
NAME water
DATA ”Water B o di e s 2”
STATUS ON
PROJECTION
” p r o j=l a t l o n g ”
” e l l p s=WGS84”
”datum=WGS84”
END
TOLERANCEUNITS KILOMETERS
TOLERANCE 10
TYPE POLYGON
METADATA
NOME ” Laghi ”
162
9 – Appendice
END
TEMPLATE ’ water . html ’
CLASSITEM ”TYPE”
LABELITEM ”NAME”
CLASS
NAME ” Laghi ”
COLOR 29 73 212
LABEL
COLOR 56 165 255
SHADOWCOLOR 0 0 0
SHADOWSIZE 2 2
TYPE TRUETYPE
FONT a r i a l −bold
SIZE 8
ANTIALIAS TRUE
POSITION CC
PARTIALS TRUE
MINDISTANCE 0
BUFFER 0
END
END
END
#l a y e r con l a r a p p r e s e n t a z i o n e d e l l e p r i n c i p a l i s t r a d e
LAYER
NAME s t r e e t
DATA ” S t r e e t s and R a i l r o a d s 1”
STATUS OFF
PROJECTION
” p r o j=l a t l o n g ”
” e l l p s=WGS84”
”datum=WGS84”
END
TOLERANCEUNITS KILOMETERS
TOLERANCE 20
TYPE LINE
METADATA
NOME ” S t r a d e ”
END
TEMPLATE ’ s t r e e t . html ’
CLASS
163
9 – Appendice
NAME ” S t r a d e ”
COLOR 255 204 56
END
END
#l a y e r che sovrappone una g r i g l i a a l l a mappa
LAYER
NAME ” g r i d ”
PROJECTION
” p r o j=l a t l o n g ”
” e l l p s=WGS84”
”datum=WGS84”
END
TYPE LINE
STATUS OFF
METADATA
NOME ” G r i g l i a ”
END
CLASS
COLOR 0 0 0
LABEL
TYPE BITMAP
SIZE MEDIUM
COLOR 255 128 89
END
END
GRID
MINSUBDIVIDE 64
MAXSUBDIVIDE 64
LABELFORMAT ”DDMMSS”
END
END
#l a y e r con l ’ e l e n c o d e l l e l o c a l i t à d i ArcheoMap
LAYER
NAME archeo−l o c
DATA ” archeo−l o c ”
TOLERANCEUNITS KILOMETERS
TOLERANCE 20
STATUS ON
PROJECTION
164
9 – Appendice
” p r o j=l a t l o n g ”
” e l l p s=WGS84”
”datum=WGS84”
END
TYPE POINT
TEMPLATE ’ s i t i . html ’
CLASSITEM ”NAME”
LABELITEM ”NAME”
LABELMAXSCALE 40000000
METADATA
NOME ” S i t i ”
END
CLASS
NAME ” S i t i ”
SYMBOL ’ c i r c l e ’
SIZE 8
COLOR 255 0 0
OUTLINECOLOR 255 0 0
LABEL
COLOR 255 0 0
SHADOWCOLOR 0 0 0
SHADOWSIZE 1 1
TYPE TRUETYPE
FONT a r i a l −bold
SIZE 10
ANTIALIAS TRUE
POSITION UC
PARTIALS TRUE
MINDISTANCE 0
BUFFER 0
FORCE TRUE
END
END
END
END
#l a y e r con l ’ e l e n c o d e l l e l o c a l i t à d i ArcheoMap
LAYER
NAME archeo−r e p e r t i
DATA ” archeo−r e p e r t i ”
TOLERANCEUNITS KILOMETERS
165
9 – Appendice
TOLERANCE 20
STATUS OFF
PROJECTION
” p r o j=l a t l o n g ”
” e l l p s=WGS84”
”datum=WGS84”
END
TYPE POINT
TEMPLATE ’ r e p e r t i . html ’
CLASSITEM ”NAME”
LABELITEM ”NAME”
LABELMAXSCALE 40000000
METADATA
NOME ” R e p e r t i ”
END
CLASS
NAME ” R e p e r t i ”
SYMBOL ’ c i r c l e ’
SIZE 8
COLOR 128 77 0
OUTLINECOLOR 255 0 0
LABEL
COLOR 255 0 0
SHADOWCOLOR 0 0 0
SHADOWSIZE 1 1
TYPE TRUETYPE
FONT a r i a l −bold
SIZE 10
ANTIALIAS TRUE
POSITION UC
PARTIALS TRUE
MINDISTANCE 0
BUFFER 0
FORCE TRUE
END
END
END
END
166
Bibliografia
[1] Atzeni, Ceri, Paraboschi, Torlone, Basi di Dati, Mc Graw Hill, 1999
[2] Massimo Ruocchio, Progettare un database relazionale, articolo tratto dalla
rivista DEV 108 del maggio 2003
[3] Luca Sanarico, Ottimizzare le query, articolo tratto dalla rivista DEV 108 del
maggio 2003
[4] Tobias Ratschiller, Till Gerken, Web Application Development with PHP 4.0,
New Riders, 2000
[5] Lerdorf Rasmus, PHP. Pocket Reference, O’Reilly, 2003
[6] Eric A. Meyer, Cascading Style Sheets 2.0, Mc Graw Hill / Osborne, 2003
[7] Bill Kropla, Beginning MapServer, Open Source GIS Development, APress,
2006
[8] Jeff Thurston, Thomas K. Poiker, J. Patrick Moore, Integrated geospatial
technology : a guide to GPS, GIS, and data logging, Wiley Publishing, 2003
[9] Neil Rhodes & Julie McKeehan, Palm Programming: The Developer’s Guide,
O’Reilly 1998
[10] Lonnon R. Foster & Glenn Bachmann, PalmOS Programming, Wiley
Publishing, 2005
[11] Martin C. Brown, Perl. The Complete Reference, Mc Graw Hill / Osborne,
2001
167
Webografia
[1 ] http://www.postgresql.org/docs/7.4/interactive/index.html
Guida di riferimento di PostgreSQL
[2 ] http://www.apache.org/
Il sito ufficiale del Web Server Apache
[3 ] http://www.php.net/
Il sito ufficiale di PHP
[4 ] http://pear.php.net/manual/en/package.database.db.php
Guida di riferimento a PEAR::DB
[5 ] http://phpsavant.com/yawiki/
Il sito ufficiale del Template Engin Savant2
[6 ] http://mapserver.gis.umn.edu/
Il sito ufficiale di MapServer
[6 ] http://www.google.com/apis/maps/documentation/
Guida di riferimento per l’API di Google Maps
[7 ] http://www.palmos.com/dev/support/docs/palmos/
Guida ufficiale di riferimento per l’API di PalmOS
[8 ] http://www.coldsync.org/
Il sito ufficiale di ColdSync
168