Progetto di tecnologie informatiche per la realizzazione di un Sistema Informativo finalizzato alla gestione di scavi archeologici

Transcript

1 POLITECNICO DI TORINO III Facoltà 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

2 Indice Prefazione 1 1 Introduzione L archeologia che si evolve Il progetto ArcheoMap ArcheoMap e l open source Organizzazione del volume Il Database di ArcheoMap Nozioni generali sui Database I requisiti del Database Progetto concettuale Modello entità-relazioni Stesura del modello E-R di ArcheoMap Progetto logico Ristrutturazione dello schema E-R Ristrutturazione del diagramma E-R di ArcheoMap Traduzione verso il modello logico Schema logico del progetto ArcheoMap Progettazione fisica L interfaccia Web Introduzione alla tecnologia Web Requisiti per la realizzazione del sito Architettura generale Apache e il linguaggio PHP L interfaccia del sito Creazione del template CSS Business Logic Le Web application

3 3.6.2 PEAR DB, l interfaccia al database Gestione della sicurezza L interfaccia multilingua Le pagine del sito Pagina di login Elenco dei progetti Dettagli della località Inserimento di una nuova località Diario si scavo Inserimento nuovo articolo Galleria fotografica Dettagli immagine Elenco dei reperti Dettagli reperto Gestione dei permessi Gestione delle mappe Introduzione ai sitemi GIS e al Web mapping Formati digitali delle mappe Gestori delle mappe GIS e Web Mapping Requisiti del sistema di Web Mapping Il gestore di mappe: MapServer Il mapfile I layer di ArcheoMap PHP/MapScript MapServer integrato nel sito di ArcheoMap Google Maps Il programma su Palm Introduzione ai dispositivi palmari Requisiti del programma su Palm TM Tecniche di ingegneria del software Progetto del programma su Palm Analisi dei requisiti Progetto del software, i diagrammi UML Diagramma delle classi di ArcheoMap Codifica Panoramica sul software finito

4 6 Il GPS Introduzione al GPS Standard NMEA Implementazione Interfacciamento Palmare / GPS Parsing delle frasi NMEA Il form di modifica e inserimento reperti La sincronizzazione tra palmare e Database Introduzione alla sincronizzazione dei palmari Requisiti per la sincronizzazione Inizializzazione del palmare PDB, il formato file di PalmOS Classi Perl per la creazione dei PDB Processo di inizializzazione HotSync, Coldsync e Conduit La Conduit di sincronizzazione dei dati di ArcheoMap Trattamento dei conflitti di sincronizzazione Conclusione Appendice Codice per creazione del database Codice del mapfile Bibliografia 167 Webografia 168 3

5 Elenco delle figure 2.1 Esempio di Database Formalismi grafici per i costrutti del modello E-R Schema grafico dell entità località Schema grafico dell entità scavo Schema grafico dell entità progetto Schema grafico delle entità diario, galleria e insieme reperti Schema grafico dell entità articolo Schema grafico dell entità immagine Schema grafico dell entità reperto Fac-simile della scheda ministeriale, fronte Fac-simile della scheda ministeriale, retro Schema grafico dell entità utente Schema grafico dell entità permesso Schema grafico delle entità capo progetto e direttore scavo Schema grafico della relazione composizione Schema grafico delle tre relazioni sezione diario sezione galleria e sezione reperti Schema grafico delle relazioni elenco articoli e scrittura Schema grafico delle due relazioni elenco immagini e foto Schema grafico delle relazioni che coinvolgono l entità reperto Schema grafico delle relazioni che coinvolgono gli utenti Schema grafico della relazione esportazione Schema E-R concettuale completo per il database di ArcheoMap Schema grafico dell entità località dopo l accorpamento degli attributi dell entità scavo Schema E-R concettuale ridotto per il database di ArcheoMap Schema di funzionamento di un indice per una tabella Diagramma temporale di una Web Application Il modello usato per la costruzione del sito di ArcheoMap Diagramma della classe di template tpl Esempio di diagramma delle classi per il sito Web di ArcheoMap

6 3.5 Schermata della pagina di login Schermata della pagina con l elenco dei progetti Schermata della pagina con i dettagli di una località Schermata della pagina per la creazione di una nuova località Schermata della pagina del diario di scavo Schermata della pagina per l inserimento di un nuovo articolo di diario Schermata della pagina con la galleria fotografica Schermata della pagina con i dettagli dell immagine Schermata della pagina con l elenco dei reperti Schermata della pagina con i dettagli di un reperto Schermata della pagina di gestione degli utenti Schermata della pagina con i dettagli sui permessi utente 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 della distanza Schermata della mappa di Google Maps Schermata con dettaglio di Google Maps ingrandita 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

7 5.16 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 località Schermata con i dettagli di una località 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 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 Schema descrittivo della PDB Classe generica per la creazione dei PDB Schermata di apertura di HotSync Algoritmo per la rilevazione di conflitti sui record

8 Prefazione ArcheoMap è il nome del progetto di mappatura di siti archeologici descritto in questo volume, il cui scopo è 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 è stato promosso da I.I.C.E. (Istituto Italiano per la Civiltà Egizia), associazione culturale che raccoglie i principali studiosi di archeologia dalle università 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 è stata accolta la proposta di realizzazione del progetto ArcheoMap da parte dei membri di I.I.C.E., si è previsto di realizzare una versione dimostrativa tesa a metterne in luce le potenzialità e gli eventuali limiti. Per la progettazione e implementazione si è 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 Università 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 qualità di committenti. La tesi è 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 è stato equamente suddiviso fra i due laureandi. In particolare, Davide Boltri si è 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 è occupato, parallelamente, del progetto del database 1

9 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

10 Capitolo 1 Introduzione 1.1 L archeologia che si evolve 4 Novembre 1922, Valle dei Re, Tebe, in Egitto: l inglese Howard Carter 1 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 più 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 Reeves 2 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 possibilità offerte da apparecchiature elettroniche ed informatiche per procedere ad affinare le ricerche sul passato e la ricostruzione storica. La tecnologia informatica può fornire un concreto aiuto agli archeologi in diversi 1 Howard Carter ( ), archeologo inglese. Giunto in Egitto come disegnatore, iniziò ad interessarsi all archeologia. La sua fortuna iniziò con l incontro di Lord Carnarvon, un nobile inglese appassionato di egittologia, che lo sovvenzionò economicamente per 7 anni. La tomba del faraone Tutanchamon nel 1922 è la sua principale scoperta. 2 Nicholas Reeves, egittologo inglese e autore di vari libri sull Antico Egitto, è attualmente direttore dell Amarna Royal Tomb Project, un progetto responsabile degli scavi nella Valle dei Re 3

11 1 Introduzione campi, uno dei quali, oggetto di questa tesi, è la catalogazione e mappatura dei reperti. Scopo dell archeologia è 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 è sufficiente una mera raccolta di oggetti, ma è necessaria soprattutto una loro efficiente catalogazione che permetta di scoprire le relazioni esistenti tra un oggetto e il luogo in cui è 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 Università e centri di ricerca in Italia e nel mondo. L obiettivo è 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 può essere visto come l integrazione di cinque componenti base: Database: è il cuore di ArcheoMap, dove vengono raccolti e gestiti i dati inerenti reperti e siti archeologici; Web: è 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: è 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 è stato sviluppato il progetto ArcheoMap è questo: gli archeologi, dotati del proprio computer palmare e di un GPS 4

12 1 Introduzione ad esso collegato, potranno muoversi lungo il sito dello scavo e annotare tramite il software presente sul loro PDA 3 i dati relativi ad ogni reperto. Sullo schermo del palmare compariranno vari form 4 da cui sarà possibile redarre annotazioni per il diario di scavo, scrivere dati per le schede di catalogazione, scattare fotografie (se il palmare è 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 complessità e la varietà degli strumenti di cui si compone il progetto ArcheoMap, è 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 è 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 già scritto. Il grande vantaggio dei prodotti Open Source è quello di poter disporre di strumenti di buona se non ottima qualità, perché frutto della libera collaborazione di una numerosa schiera di sviluppatori, e di cui esistono ampia documentazione e una serie di case studies da analizzare. Più in particolare, gli aspetti del mondo Open Source che principalmente interessano il progetto ArcheoMap sono riassumibili nei seguenti punti: Disponibilità di formati aperti: nell ottica di costruire un progetto duraturo, è 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 diventerà obsoleto; Possibilità di manipolare il codice sorgente degli strumenti utilizzati, in modo da garantirne l adattabilità a condizioni particolari o l implementazione di nuove caratteristiche, qualora se ne presenti la necessità; 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) è 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

13 1 Introduzione e il sistema operativo Linux che formano la piattaforma su cui dovrà 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 presenterà l occasione. 1.4 Organizzazione del volume Il volume è organizzato in nove capitoli, di cui il primo è 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 è 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, è stata aggiunta un appendice in cui sono riportati frammenti del codice sorgente scritto durante la fase di sviluppo del progetto. 6

14 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 più 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 semplicità ed efficienza, la soluzione più 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 è 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

15 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 Data di nascita Maria Rossi 25/11/ Anna Neri Fabio Verdi 23/04/ /02/1972 Studente Voto Corso Codice Titolo Docente TABELLA CORSI ANA 03CHI 02FIS 01ANA 02FIS 03CHI TABELLA ESAMI Analisi Fisica Chimica Giani Melli 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 è 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 può 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 è possibile instaurare delle relazioni che consentano di interrogare il database e scoprire senza ambiguità quali esami sono stati sostenuti da un determinato studente oppure quali studenti hanno superato l esame di un determinato corso. Proprio perché i campi univoci permettono di effettuare ricerche nelle tabelle senza ambiguità, vengono chiamati chiavi nella terminologia tecnica dei database. Di norma ogni tabella deve avere una chiave e se non è 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

16 2 Il Database di ArcheoMap termini, individuare le tabelle di cui è formata la base dati, la loro struttura, le loro chiavi e le relazioni che si possono formare, è 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 né della modalità con la quale le informazioni verranno codificate nel sistema reale né 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 realtà fisica (quindi dal prodotto finale) ma concreto perché disponibile nei sistemi di gestione delle basi dati; Progettazione fisica: è 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 è 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 è la prima fase del processo di progettazione del database. È 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 è interessato e costruire una solida base di partenza per la definizione del progetto. Il documento dei requisiti, che si può stilare al termine di questa fase, è 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 ambiguità e facilitare il successivo lavoro di analisi. Dai dialoghi avuti presso il committente del progetto e dalle opinioni dei futuri utilizzatori di ArcheoMap, si è giunti alla definizione dei seguenti punti: 9

17 2 Il Database di ArcheoMap 1. Il database deve tener conto delle informazioni relative a località geografiche interessate da studi archeologici. Ogni località è contraddistinta dal nome geografico attuale, dal nome del luogo nell antichità (se disponibile), dal nome della nazione, città e comune in cui è collocato, dal proprio indirizzo e dalle coordinate geografiche. L accesso ai dati ospitati nell ambito di una località può essere pubblico o privato; 2. Ogni località è corredata da un testo descrittivo ed eventualmente note di vario genere; 3. Ogni località può avere delle referenze per i contatti esterni: numero di telefono, indirizzo , indirizzo di un sito internet ed eventuali indicazioni stradali su come raggiungerlo; 4. Ogni località può 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 può essere ad accesso pubblico o ad accesso privato; 5. Le località sono organizzate in progetti: ogni progetto può contenere più località, ma ognuna di esse è legata ad un unico progetto. I progetti sono caratterizzati da un nome, una descrizione, un indirizzo internet di riferimento, un indirizzo , un numero di telefono, una data di apertura e una data di chiusura; 6. Ogni località è 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 è univoca nei confronti della località a cui appartengono; 7. Il diario di scavo è l insieme degli articoli scritti dai partecipanti ad una campagna archeologica per annotare tutto ciò 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 è stato scritto, l autore, la data in cui è stato modificato l ultima volta e l autore dell ultima modifica; 8. Poiché spesso l articolo non viene scritto di getto, ma può 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 è l insieme delle immagini inserite nel contesto della località. 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

18 2 Il Database di ArcheoMap 10. Ogni reperto è 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 è 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 più moduli ufficiali chiamati schede ministeriali. Si vuole dare la possibilità di inserire la scheda ministeriale nel database con i suoi singoli campi; 12. L accesso ad ogni componente di ArcheoMap può essere ristretto a singoli utenti, distinti da un nome, un cognome, uno username, una password, un indirizzo e la lingua parlata; 13. Ogni utente deve avere a disposizione un insieme di permessi che gli consentano di accedere in modo limitato alle località 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 più progetti, e i direttori di scavo, che si occupano della direzione di singole località. 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. Poichè ogni utente ha a sua disposizione un palmare, occorre tenere traccia dei progetti e delle località 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 entità-relazioni Modello entità-relazioni Il modello entità-relazioni, spesso abbreviato come modello E-R, è un modello concettuale di dati e, come tale, fornisce una serie di costrutti atti a descrivere la realtà 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: entità, relazioni e loro cardinalità, attributi, identificatori e generalizzazioni. 11

19 2 Il Database di ArcheoMap Le entità nel modello E-R rappresentano classi di oggetti (fatti, cose, persone, per esempio) che hanno proprietà comuni ed esistenza autonoma ai fini dell applicazione di interesse. Le relazioni descrivono legami logici significativi tra due o più entità. Il numero di entità legate prende il nome di grado della relazione. Solitamente si cerca, per quanto possibile, di inserire relazioni di grado due. Ad ogni relazione è assegnata una cardinalità, che specifica per ciascuna entità che partecipa alla relazione quante volte l occorrenza di una di queste entità può essere legata ad occorrenze delle altre. La cardinalità viene indicata con una coppia di numeri (a,b), in cui il primo valore è la cardinalità minima, il secondo è la cardinalità massima. La cardinalità minima è il numero minimo di partecipazione relativa e può essere zero o uno: se zero la partecipazione è opzionale; se uno la partecipazione è obbligatoria. La cardinalità massima è il numero massimo di partecipazione relativa e può essere uno o molti (abbreviato in N): se uno, vuol dire che a ogni occorrenza di una entità corrisponde al massimo una occorrenza dell altra; se N, vuol dire che ad ogni partecipazione di una entità corrisponde un numero arbitrario di occorrenze dell altra entità. Gli attributi descrivono le proprietà elementari di entità 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 è associato l insieme di valori che questo può 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 è 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 è possibile individuare un identificatore tra gli attributi presenti, è prassi comune aggiungere un ulteriore attributo, ad esempio un codice precostituito, che funga da identificatore. Nel costrutto di generalizzazione si distinguono due tipi di entità: una entità padre e una o più entità figlie relazionate in modo particolarmente stretto perché le entità figlie sono da considerarsi delle specializzazioni o casi particolari dell entità padre. Ad esempio, l entità persona è una generalizzazione delle entità uomo e dell entità donna. Ogni occorrenza delle entità figlie è anche occorrenza dell entità padre, e condividono gli stessi attributi. Ad ogni costrutto del modello E-R corrisponde un formalismo grafico, come si può vedere nella figura 2.2. Il grafico (a) rappresenta un entità con i suoi attributi: l entità è 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, perché questa informazione viene demandata alla documentazione di corredo allo schema. 12

20 2 Il Database di ArcheoMap attr1 (a) A (0,1) (1,1) Rel B Entity Id A (1,1) (0,N) Rel B attr3 attr2 Padre Figlio A (1,N) Rel (0,N) B (b) (c) Figura 2.2. Formalismi grafici per i costrutti del modello E-R Il grafico (b) illustra un esempio di generalizzazione: l entità Figlio è un caso particolare dell entità Padre, e tale legame viene delineato da una freccia che punta verso l entità più 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 entità che la relazione lega. Accanto alle entità viene riportata la cardinalità delle relazioni. Sulla base della cardinalità si distinguono tre tipi di relazione: Relazioni uno a uno (grafico (c), primo schema): un istanza dell entità A può legarsi al più con una istanza dell entità B, mentre un istanza dell entità B si lega ad una e una sola istanza dell entità A; Relazioni uno a molti (grafico (c), secondo schema): un istanza dell entità A si lega ad una e una sola istanza dell entità B, mentre un istanza dell entità B può legarsi con un numero imprecisato di istanze dell entità A; Relazioni molti a molti (grafico (c), terzo schema): un istanza dell entità A si lega a più istanze dell entità B, e analogamente un istanza dell entità B si lega a più istanze dell entità A Stesura del modello E-R di ArcheoMap Per tracciare il modello E-R del database che si intende progettare è necessario analizzare i requisiti esposti nella sezione 2.2 allo scopo di individuare quali siano le 13

21 2 Il Database di ArcheoMap entità di interesse. A tale risultato si perviene leggendo accuratamente il testo dei requisiti e annotando, tra i sostantivi e gli aggettivi presenti, i termini più rilevanti, quali identificano delle classi di oggetti con esistenza autonoma e quali invece sono attributi. Entità del progetto Leggendo i primi 3 punti dei requisiti, il sostantivo principale, quello che viene più naturale associare ad un entità, è sicuramente la parola località mentre i vocaboli nome, nazione, città, comune, indirizzo, coordinate, descrizione, note, numero di telefono, indirizzo , indirizzo internet e indicazioni stradali sono degli attributi che servono a meglio specificare le proprietà di ogni singola istanza della classe località. Una località, inoltre, può essere ad accesso pubblico o privato, e per tenerne traccia si aggiunge un ulteriore attributo pubblico di tipo booleano 1 che indica lo stato della località. Rimane da scegliere una chiave, ossia un attributo univoco. Dal momento che nessuno degli attributi elencati rispetta tale proprietà, si decide di aggiungere un campo idlocalità che serva allo scopo. Per brevità si anticipa che in tutte le successive entità si è optato di aggiungere un attributo chiamato id[nome entità] nella forma di un codice numerico progressivo da utilizzare come identificatore univoco. Nella figura 2.3 è riportato lo schema grafico mentre nella tabella 2.1 è riportata la documentazione, con, per ogni attributo, il tipo di valori che può assumere e una breve descrizione. Il quarto punto informa che le località 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 è quello di introdurre una nuova entità scavo che presenti gli stessi attributi dell entità località, con in più le due proprietà data inizio e data fine. Si è di fatto introdotta una generalizzazione, in cui località è l entità padre e scavo è l entità figlia. Nella figura 2.4 è riportato lo schema grafico e nella tabella 2.2 è riportata la documentazione degli attributi che sono da aggiungere a quelli dell entità località. Nel quinto punto il termine più rilevante, da trattare come entità, è progetto, che ha come attributi nome, descrizione, indirizzo internet, , telefono, data apertura e data chiusura. Nella figura 2.5 è riportato lo schema grafico per l entità progetto, mentre nella tabella 2.3 è riportata la documentazione degli attributi. Il sesto punto definisce le entità 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 può assumere solo due valori: si/no oppure on/off. 14

22 2 Il Database di ArcheoMap nome_antico idlocalità nome_nuovo città comune indicazioni Località pubblico nazione e mail telefono indirizzo note coordinate descrizione internet Figura 2.3. Schema grafico dell entità località data inizio località scavo data fine idscavo Figura 2.4. Schema grafico dell entità scavo criterio di univocità delle chiavi. Nella figura 2.6 è rappresentato lo schema grafico delle tre entità diario, galleria e insieme reperti mentre nella tabella 2.4 ne è data la documentazione. 15

23 2 Il Database di ArcheoMap Nome attributo Valori Descrizione id Località Numero progressivo Codice che identifica in modo univoco la località nome nuovo Stringa di caratteri Nome assunto dalla località correntemente nome antico Stringa di caratteri Nome assunto dal luogo nell antichità nazione Stringa di caratteri Nazione in cui è ubicata la località città Stringa di caratteri Nome della città in cui è situata la località comune Stringa di caratteri Nome del comune in cui è situata la località indirizzo Stringa di caratteri Indirizzo completo a cui è situata la località coordinate Numeri e caratteri Coordinate geografiche della località descrizione Stringa di caratteri Testo descrittivo della località note Stringa di caratteri Testo in cui vengono inserite annotazioni sulla località telefono Numeri Numero di telefono di riferimento per la località Stringa di caratteri Indirizzo di riferimento per la località internet Stringa di caratteri Indirizzo WWW di riferimento per la località indicazioni Stringa di caratteri Testo in cui vengono fornite indicazioni stradali utili per raggiungere la località pubblico Booleano Valore che indica se la località è ad accesso pubblico o privato Tabella 2.1. Documentazione per l entità località Il settimo e l ottavo punto hanno come comune denominatore il termine articolo, che quindi è il candidato più adatto a diventare un entità. I suoi attributi sono titolo, testo, data scrittura e data modifica. Il termine autore non viene trattato come attributo perché è un elemento troppo forte per essere trattato in tal senso. Alla luce di quanto specificato nei punti dodici e tredici dei requisiti, si è ritenuto più appropriato considerare gli autori istanza dell entità utente. Si specifica poi che è possibile scegliere, dopo aver scritto un articolo, se pubblicarlo 16

24 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 entità scavo da aggiungere a quella dell entità località nome descrizione idprogetto internet data chiusura progetto e mail data apertura telefono Figura 2.5. Schema grafico dell entità progetto iddiario diario insieme reperti idgalleria galleria idinsiemereperti Figura 2.6. Schema grafico delle entità diario, galleria e insieme reperti 17

25 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 è noto il progetto descrizione Stringa di caratteri Testo descrittivo del progetto internet Stringa di caratteri Indirizzo internet di riferimento per il progetto Stringa di caratteri Indirizzo 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 entità progetto Nome attributo Valori Descrizione iddiario Numero progressivo Codice che identifica in modo univoco un istanza dell entità diario idgalleria Numero progressivo Codice che identifica in modo univoco un istanza dell entità galleria idinsiemereperti Numero progressivo Codice che identifica in modo univoco un istanza dell entità insieme reperti Tabella 2.4. Documentazione per le entità 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 può scegliere se renderlo visibile oppure no. Nella figura 2.7 è riportato lo schema grafico dell entità articolo mentre nella tabella 2.5 ne è data la documentazione. I punti nove e dieci dei requisiti definiscono l entità 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 entità 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 può essere associato a una o più schede ministeriali. Poiché si tratta di un documento ufficiale, che gli archeologi devono 18

26 2 Il Database di ArcheoMap testo titolo idarticolo articolo data modifica visibile data scrittura Figura 2.7. Schema grafico dell entità articolo Nome attributo Valori Descrizione idarticolo Numero progressivo Codice che identifica in modo univoco un istanza dell entità articolo testo Stringa di caratteri Testo dell articolo titolo Stringa di caratteri Titolo dell articolo data scrittura Data Data in cui è stato scritto l articolo data modifica Data Data in cui è stato modificato l articolo Tabella 2.5. Documentazione dell entità articolo note data inserimento data modifica idimmagine immagine file Figura 2.8. Schema grafico dell entità immagine compilare in seguito al rinvenimento di un reperto, elencandone le caratteristiche rilevanti al momento della scoperta, non si è ritenuto opportuno specificare nei requisiti le singole parti di cui è composto. Nelle figure 2.10 e 2.11 sono mostrati il 19

27 2 Il Database di ArcheoMap Nome attributo Valori Descrizione idimmagine Numero progressivo Codice che identifica univocamente un istanza dell entità immagine note Stringa di caratteri Note di vario genere relative all immagine data inserimento Data Data in cui è 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 entità immagine nome data inserimento data_modifica idreperto reperto coordinate Figura 2.9. Schema grafico dell entità reperto Nome attributo Valori Descrizione idreperto Numero progressivo Codice che identifica univocamente un istanza dell entità reperto nome Stringa di caratteri Nome assegnato al reperto reperto data inserimento Data Data in cui è stato inserito il reperto data modifica Data Data di ultima modifica del reperto coordinate Stringa di caratteri Coordinate geografiche a cui è stato trovato il reperto Tabella 2.7. Documentazione dell entità reperto fronte e il recto di un fac-simile della scheda ministeriale. Dal momento che si vuole fornire la possibilità di memorizzare le schede ministeriali nel database, quello che si fa è di introdurre l entità 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 entità 20

28 2 Il Database di ArcheoMap Figura Fac-simile della scheda ministeriale, fronte 21

29 2 Il Database di ArcheoMap Figura Fac-simile della scheda ministeriale, retro 22

30 2 Il Database di ArcheoMap utente, con attributi nome, cognome, username, password, e lingua (si veda figura 2.12 per lo schema grafico e la tabella 2.8 per la documentazione) e l entità permesso con attributo tipo permesso (schema grafico alla figura 2.13 e documentazione alla tabella 2.9). In questo modo si ottiene la flessibilità richiesta, perché nel caso in cui si vogliano aggiungere nuovi permessi al sistema sarà 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 più naturale è di definirli come entità separate, capo progetto e direttore scavo, specializzazioni dell entità utente. Detto in modo più formale, si introducono tre generalizzazioni, in cui utente è l entità padre, capo progetto e direttore scavo sono le entità figlie (figura 2.14). nome cognome idutente utente username lingua password Figura Schema grafico dell entità utente Nome attributo Valori Descrizione idutente Numero progressivo Codice che identifica univocamente un istanza dell entità 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 Stringa di caratteri dell utente lingua Stringa di caratteri Lingua parlata dall utente Tabella 2.8. Documentazione dell entità utente 23

31 2 Il Database di ArcheoMap tipopermesso idpermesso permesso Figura Schema grafico dell entità permesso Nome attributo Valori Descrizione idpermesso Numero progressivo Codice che identifica univocamente un istanza dell entità permesso tipo permesso Stringa di caratteri Nome assegnato al tipo di permesso Tabella 2.9. Documentazione dell entità permesso capo progetto utente direttore scavo Figura Schema grafico delle entità capo progetto e direttore scavo L ultimo punto dei requisiti non introduce nessuna entità rilevante, e perciò ad esso non corrisponde alcuno schema. Relazioni del progetto Una volta ultimata la ricerca e la definizione delle entità, con i loro attributi e le generalizzazioni, il passo successivo è rileggere il documento dei requisiti mettendone in luce questa volta le relazioni, ossia i legami tra le entità. Per ogni relazione, oltre a stabilirne un nome simbolico che la identifichi nello schema finale, se ne deve fissare la cardinalità, stabilendo se è del tipo uno a uno, uno a molti o molti a molti. 24

32 2 Il Database di ArcheoMap I primi quattro punti dei requisiti si limitano a definire le entità località e scavo e i loro attributi, non vi compaiono relazioni. Al punto cinque si legge che le località sono organizzate in progetti: questa è la prima relazione da introdurre. Si definisce dunque una relazione di nome composizione 2 che lega le entità località e progetto. Tale relazione sta a significare che ogni progetto si compone di località, e che ogni località fa parte di un progetto. La relazione è di tipo uno a molti: ogni istanza dell entità progetto è relazionata a più istanze dell entità località, mentre ogni istanza dell entità località si relaziona a una e una sola istanza della classe progetto. Nella figura 2.15 è riportato lo schema grafico della relazione con le entità che essa lega e la cardinalità. località (1,1) (0,N) composizione progetto Figura Schema grafico della relazione composizione Il punto sei definisce tre relazioni che legano l entità località con l entità diario, l entità galleria e l entità 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 entità località si lega a una e una sola istanza delle entità diario, galleria e insieme reperti ; viceversa, ogni istanza di queste tre entità è legata in modo univoco a un istanza di località. Nella figura 2.16 è 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, perché ogni articolo fa parte di un solo diario, ma ogni diario è formato da più articoli. La seconda è la relazione che lega ogni articolo di diario al suo autore (vale a dire un istanza della classe utente ), a cui si dà nome scrittura. Tale relazione è ancora del tipo uno a molti: ogni articolo di diario viene scritto da uno e un solo autore, mentre ogni autore può scrivere più 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 perchè un utente può essere stato l ultimo a modificare una serie di articoli. Nella figura 2.17 è riportato lo schema risultante dall unione delle tre relazioni. 2 Contrariamente a quanto avviene con la definizione delle entità, nel dare un nome alle relazioni non è obbligatorio rimanere fedeli alla terminologia adottata nei requisiti: è sufficiente coglierne il senso senza stravolgerlo 25

33 2 Il Database di ArcheoMap località (1,1) sezione diario (1,1) diario località (1,1) sezione galleria (1,1) galleria località (1,1) (1,1) sezione reperti insieme reperti Figura Schema grafico delle tre relazioni sezione diario sezione galleria e sezione reperti diario (0,N) (1,1) elenco articoli (1,1) articolo (1,1) utente (0,N) (0,N) scrittura modifica diario Figura Schema grafico delle relazioni elenco articoli e scrittura Il punto nove definisce la relazione elenco immagini che lega ogni galleria a più immagini e ogni immagine ad una galleria (è 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 cardinalità uno a molti elenco reperti che lega le istanze dell entità reperto alle istanze dell entità insieme reperti ; la relazione uno a molti catalogo che lega i reperti all utente che li ha inseriti; 26

34 2 Il Database di ArcheoMap galleria (0,N) (1,1) elenco immagini (1,1) immagine (1,1) (0,N) foto utente (0,N) modifica foto Figura 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 entità reperto può fare riferimento a più immagini e più articoli di diario che lo descrivono, e viceversa ogni istanza dell entità immagine o dell entità articolo può fare riferimento a più reperti. Nel punto undici si legge che ogni reperto può essere legato a una o più 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 è riportato lo schema grafico che riassume tutte le relazioni che coinvolgono l entità reperto e l entità scheda ministeriale. Nei punti dodici e tredici viene trattata la gestione dei permessi. Tramite l entità permesso viene regolato l accesso degli utenti alle località, perciò l unica soluzione è quella di creare una relazione ternaria autorizzazione, del tipo molti a molti, che leghi contemporaneamente l entità permesso alle entità utente e località. Ci sono poi gli utenti privilegiati, vale a dire i capi progetto e direttori scavo, che sono legati alle entità da essi controllate (rispettivamente progetti e località) da opportune relazioni molti a molti gestione e direzione. Quest intreccio di associazioni viene rappresentato graficamente nella figura Infine nel punto quattordici si richiede di tener traccia dei progetti e delle località che un utente vuol esportare sul proprio palmare. Questo si ottiene introducendo un ultima relazione, a cui si dà nome esportazione, che lega ogni utente alle località e progetti che questo ha deciso di esportare. Si tratta di una relazione molti 27

35 2 Il Database di ArcheoMap insieme reperti (0,N) elenco reperti (1,1) (1,1) reperto utente (0,N) catalogo (0,N) (0,N) (1,1) modifica scheda (0,N) redazione modifica reperto (1,1) (1,1) scheda ministeriale (1,1) documentazione (0,N) articolo (0,N) riferimento diario (0,N) (0,N) immagine (0,N) riferimento immagine Figura Schema grafico delle relazioni che coinvolgono l entità reperto a molti (perchè ogni istanza delle entità coinvolte può partecipare alla relazione con cardinalità multipla), ed è una relazione ternaria per via del legame esistente tra località e progetti: non è infatti possibile esportare una località senza esportare contemporaneamente anche il progetto di cui fa parte. Nella figura 2.21 è dato lo schema grafico che risolve quest ultimo punto dei requisiti. Lo schema completo Una volta determinate le entità e le relazioni coinvolte nel progetto si uniscono i singoli grafici e si traccia il modello E-R completo del database, riportato nella figura Per ragioni di praticità e per evitare di rendere troppo intricato lo 28

36 2 Il Database di ArcheoMap direttore scavo utente capo progetto (1,N) (1,N) (1,N) direzione autorizza zione gestione (1,N) (0,N) (0,N) (1,N) località permesso progetto Figura Schema grafico delle relazioni che coinvolgono gli utenti (0,N) località utente (0,N) esportazione (0,N) progetto Figura Schema grafico della relazione esportazione schema, si sono rappresentate le entità 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 cardinalità delle relazioni. Si tratta di un modello concettuale, ancora distante da quello che sarà il prodotto definitivo, perché in esso sono presenti ridondanze e complessità che è possibile eliminare o semplificare. A partire da questo schema si può procedere quindi con la fase di progettazione logica. 29

37 2 Il Database di ArcheoMap modifica scrittura foto catalogo immagine riferimento immagine articolo immagine reperto elenco articoli riferimento articolo elenco immagini elenco reperti modifica diario utente direttore scavo direzione sezione reperti capo progetto scavo composizione località sezione diario gestione progetto esportazione sezione galleria permesso autorizzazione modifica reperto documen tazione modifica scheda diario galleria insieme reperti redazione scheda Figura Schema E-R concettuale completo per il database di ArcheoMap 30

38 2.4 Progetto logico 2 Il Database di ArcheoMap L obiettivo di questa fase di progetto è 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 perché 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 Ristrutturazione dello schema E-R Scopo della ristrutturazione logica è 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 perché privo di ridondanze e costrutti superflui. Le parti del diagramma concettuale che sono da considerare ridondanti sono quelle che possono essere derivate da altre entità o relazioni senza alterare la compatibilità con i requisiti. Tipicamente ricadono in questa categoria: attributi che corrispondono ad informazioni ottenibili con semplici operazioni da altre parti del modello; relazioni e entità che nel modello concettuale sono state introdotte per chiarezza ma che possono essere eliminate perchè 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 capacità del progettista che, anche sulla base di considerazioni prestazionali, può optare per una determinata scelta. Possono infatti esserci situazioni in cui un entità 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 più essenziale è l eliminazione delle generalizzazioni. Come si è detto nella sezione le generalizzazioni sono forme particolari di un entità più generica che condividono con quest ultima parte degli attributi, introducendone eventualmente di nuovi. È evidente quindi che la ripetizione degli attributi in entità così strettamente legate è un inutile ridondanza che va risolta. I modi di procedere sono sostanzialmente tre: 31

39 2 Il Database di ArcheoMap 1. Accorpamento dell entità figlia nell entità padre: si crea un unica entità, con il nome dell entità padre, e gli attributi dell entità figlia vengono accorpati agli attributi dell entità padre. È la soluzione più adatta quando le entità figlie introducono differenziazioni non sostanziali; 2. Accorpamento dell entità padre nelle entità figlie: si creano tante entità quante sono le entità figlie, ognuna di esse con gli attributi propri e, in aggiunta, quelli dell entità padre, che può così essere eliminata. È la soluzione più adatta quando la generalizzazione è totale, ossia quando le entità figlie sono ben differenziate tra di loro; 3. Sostituzione con relazioni: se le entità padre e le entità figlie sono ben distinte e si vogliono mantenere separati gli accessi alle singole entità, conviene sostituire la generalizzazione con una vera e propria relazione Ristrutturazione del diagramma E-R di ArcheoMap Dopo aver descritto cosa si intende per ristrutturazione di un diagramma E-R, se ne dà un esempio pratico di applicazione sul progetto ArcheoMap. Come sottolineato nella sezione precedente, il primo obiettivo è quello di ricercare gli elementi che si possono eliminare perché ottenibili da altre entità e relazioni già presenti nel progetto. Analizzando lo schema concettuale di figura 2.22 si possono fare le seguenti considerazioni: L entità diario è una ridondanza. Quello a cui si è effettivamente interessati è poter accedere all insieme di articoli scritti per una determinata località, quindi in tal senso diario rappresenta solo un ponte concettuale che non ha alcuna utilità pratica effettiva. Si opta dunque, per ragioni di efficacia, per la sua eliminazione, e per collegare direttamente l entità articolo con l entità località ; Discorso del tutto analogo può essere fatto per le entità insieme reperti e galleria ; Vi sono ridondanze nella gestione dei permessi. Se è vero che dal punto di vista concettuale le entità capo progetto e direttore scavo sono figlie dell entità utente, è 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 è automaticamente identificato come un capo progetto, senza necessità di assegnargli un entità distinta. Si è scelto quindi di eliminare queste due entità senza che ciò vada ad inficiare il corretto funzionamento del sistema; 32

40 2 Il Database di ArcheoMap Le relazioni riferimento immagine, riferimento articolo e documentazione hanno la stessa cardinalità 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 è ritenuto più 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 è eliminare le generalizzazioni rimaste, che nel caso in esame è una sola: quella che lega l entità padre località con l entità figlia scavo. Poiché le due entità non presentano sostanziali differenze, tra le possibili soluzioni prospettate nella sezione si è optato per la prima, cioè l accorpamento dell entità figlia nell entità padre: tutti gli attributi dell entità figlia vengono aggiunti all entità padre e per riconoscere quando una località è uno scavo, si aggiunge un ulteriore attributo booleano chiamato scavo. Nella figura 2.23 è riportato lo schema grafico dell entità località così come si presenta dopo l accorpamento degli attributi dell entità scavo. nome_antico data_fine nome_nuovo idlocalità città data_inizio comune indicazioni Località nazione pubblico e mail scavo telefono indirizzo note coordinate internet descrizione Figura Schema grafico dell entità località dopo l accorpamento degli attributi dell entità scavo Non essendoci altre ottimizzazioni da fare, si può considerare conclusa la fase di 33

41 2 Il Database di ArcheoMap ristrutturazione e applicare quanto detto allo schema concettuale per ottenerne il grafico di figura 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 sarà 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 è composta. Uno o più di questi campi sono sottolineati per indicare la chiave primaria, cioè 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 entità è una tabella, le cui colonne sono gli attributi e la cui chiave univoca è l identificatore; Ogni relazione molti a molti diviene una tabella, le cui colonne sono gli identificatori delle entità associate, che fungono anche da chiave primaria; Le relazioni del tipo uno a molti con partecipazione obbligatoria (cardinalità minima uno), vengono sciolte, e all entità che ha partecipazione massima uno viene aggiunto un attributo che è la chiava primaria dell entità a cui è associata; Le relazioni del tipo uno a molti con partecipazione opzionale (cardinalità 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 entità associate. La chiave primaria è la colonna corrispondente all identificatore dell entità che ha partecipazione massima uno; Le relazioni del tipo uno a uno con partecipazione obbligatoria da parte di entrambe le entità, vengono sciolte e ad una delle due entità (a scelta) viene aggiunta una colonna corrispondente all identificatore dell altra entità; 34

42 2 Il Database di ArcheoMap (0,N) utente (1,N) modifica scrittura foto catalogo immagine (1,1) (1,1) (1,1) tipo articolo (0,N) immagine reperto modifica diario (1,1) elenco articoli 0,N riferimento (1,1) (1,1) elenco immagini 0,N elenco reperti (0,N) esportazione (0,N) (0,N) (0,N) (0,N) (0,N) località (1,1) (1,N) composizione (0,N) progetto (1,N) permesso autorizzazione (1,N) modifica reperto redazione (1,1) scheda (0,N) (1,1) modifica scheda Figura Schema E-R concettuale ridotto per il database di ArcheoMap 35

43 2 Il Database di ArcheoMap Le relazioni del tipo uno a uno in cui una sola delle entità è a partecipazione obbligatoria sono tradotte in modo analogo alle precedenti, ma la colonna aggiuntiva corrispondente all identificatore dell altra entità è obbligatorio associarla all entità avente cardinalità minima zero; Le relazioni del tipo uno a uno in cui entrambe le entità hanno partecipazione opzionale non vengono sciolte, ma si trasformano in una tabella avente come colonne gli identificatori delle entità 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 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 entità 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); località(idlocalità, città, comune, nazione, scavo, indirizzo, coordinate, descrizione, indirizzo internet, note, telefono, , indicazioni, data inizio, data fine, nome nuovo, nome antico, pubblico); progetto(idprogetto, nome, descrizione, internet, , 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, , lingua); La mossa successiva è quella di tradurre le relazioni. Per cominciare, la relazione autorizzazione è del tipo molti a molti con partecipazione obbligatoria. Per quanto detto, la soluzione è quella di creare una nuova tabella che abbia come campi le chiavi delle entità utente, progetto, località e permesso : 36

44 2 Il Database di ArcheoMap autorizzazione(idpermesso, idutente, idprogetto, idlocalità); La relazione scrittura è 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 entità articolo, attributo che punta alla chiave dell entità utente, in questo modo: articolo(idarticolo, testo, titolo, data scrittura, data modifica, visibile, idautore); La relazione modifica diario è identica alla precedente, quindi allo stesso modo si aggiunge un nuovo attributo all entità articolo che punta alla chiave dell entità 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 entità che partecipano alla relazione con cardinalità 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 è ancora una relazione uno a molti con partecipazione opzionale, e nuovamente si preferisce il suo scioglimento e l aggiunta di un attributo all entità articolo, che quindi va un altra volta modificato, aggiungendogli la chiave dell entità associata, località : articolo(idarticolo, testo, titolo, data modifica, data scrittura, visibile, idautore, idmodificatore, idlocalità); Stessa cosa per le relazioni elenco immagini e elenco reperti : immagine(idimmagine, note, data inserimento, data modifica, file, idautore, idmodificatore, idlocalità); reperto(idreperto, nome, data inserimento, data modifica, coordinate, idautore, idmodificatore, idlocalità); 37

45 2 Il Database di ArcheoMap La relazione composizione, che lega le località ai progetti, è un altro caso di relazione uno a molti, ma questa volta a partecipazione obbligatoria (ogni località deve appartenere a uno e un solo progetto), quindi non si hanno scelte: nella traduzione verso il modello logico è necessario sciogliere la relazione e aggiungere un attributo all entità che ha partecipazione massima uno, ossia località : località(idlocalità, città, comune, nazione, scavo, indirizzo, coordinate, descrizione, indirizzo internet, note, telefono, , 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 è la chiave dell oggetto associato, che di volta in volta può 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 dà origine ad una nuova tabella costituita dalle sole chiavi primarie che essa lega: esportazione(idutente, idprogetto, idlocalità) Nel tentativo di rendere edotto il lettore su come si sviluppa passo per passo il progetto logico, alcune tabelle sono state modificate più volte nel corso della trattazione. Per chiarezza si mostra nella tabella 2.10 lo schema logico completo. Con questo il database può uscire dall astrazione progettuale per essere tradotto in realtà fisica, implementato su un DBMS reale Progettazione fisica La progettazione fisica è la fase finale del processo di pianificazione e creazione di una base dati. Lo scopo di questa fase è 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 integrità relazionale; 38

46 2 Il Database di ArcheoMap articolo(idarticolo, testo, titolo, data scrittura, data modifica, visibile, idautore, idmodificatore, idlocalità); autorizzazione(idpermesso, idutente, idprogetto, idlocalità); immagine(idimmagine, note, data inserimento, data modifica, file, idautore, idmodificatore, idlocalità); località(idlocalità, città, comune, nazione, scavo, indirizzo, coordinate, descrizione, indirizzo internet, note, telefono, , indicazioni, data inizio, data fine, nome nuovo, nome antico, pubblico, idprogetto); progetto(idprogetto, nome, descrizione, internet, , telefono, data apertura, data chiusura); permesso(idpermesso, tipo permesso); reperto(idreperto, nome, data inserimento, data modifica, coordinate, idautore, idmodificatore, idlocalità); 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, , lingua); Tabella Schema logico del database di ArcheoMap 4. Ottimizzazione delle prestazioni per mezzo di particolari strutture chiamate indici. È fondamentale chiarire che il progetto del database ottenuto dall applicazione successiva della progettazione concettuale e della progettazione logica è totalmente indipendente dalla realizzazione fisica finale. Questo significa che quanto esposto nei paragrafi seguenti rappresenta solo un esempio dei molti modi in cui è 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) è 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 più utenti. Nell obiettivo di utilizzare software Open Source per lo sviluppo di un prototipo del progetto ArcheoMap, si è cercato tra questi quale DBMS usare nell implementazione del database. La scelta è caduta su PostgreSQL nella sua versione 7.4, a oggi considerato uno dei migliori DBMS 39

47 2 Il Database di ArcheoMap Open Source in circolazione, in grado di confrontarsi senza timori con i più blasonati sistemi commerciali. Nato nel 1985 come derivato del DBMS commerciale Ingres sviluppato in seno all università di Berkeley, ha goduto dei contributi della comunità di sviluppatori di tutto il mondo, assumendo il nome attuale nel 1996 dopo che è stato introdotto il supporto al linguaggio di interrogazione dei database SQL 3. La versione 7.4 utilizzata come riferimento nella realizzazione del prototipo del progetto analizzato in questa tesi è stata rilasciata nel 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 integrità relazionale ed è 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 più importante è la sua espandibilità: è dotato di un linguaggio di programmazione interno, chiamato PL/SQL, che consente la creazione di tipi di dati complessi e di nuove funzionalità 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 più adatti a rappresentare i campi delle singole tabelle. Dalla documentazione delle entità viste nelle tabelle 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 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 avrà 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 può 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 possibilità: 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

48 2 Il Database di ArcheoMap caso è 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 più conveniente, in realtà una stringa di caratteri di tipo text occupa più spazio di una stringa con lunghezza massima dichiarata, quindi è conveniente utilizzare il tipo text solo quando strettamente necessario. Si è perciò 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 è adottato il tipo character varying(n) impostando il parametro n ad una dimensione appropriata. Per esempio l attributo nome della tabella utente è stato fissato ad una lunghezza massima di 80 caratteri, sufficienti ad ospitare nomi anche molto lunghi. Infine per l inserimento delle date si è 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, è 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 è 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 è 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 è possibile esprimere in meri termini di diagrammi E-R perché, essendo selettivi, hanno necessariamente bisogno del supporto di un linguaggio di programmazione più 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 è 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 località. Ogni utente presente nel database, per poter essere 41

49 2 Il Database di ArcheoMap considerato un collaboratore ad una località, 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 località, è stato privato dei suoi permessi senza che gliene siano stati assegnati di nuovi. Per trattare questa casistica, si è inserito un permesso fittizio chiamato na (abbreviazione di not assigned) agli utenti che si trovano nella situazione descritta. Si è creato allora il trigger set na che automaticamente, alla cancellazione dei permessi di un utente, se questo non ne ha altri nell ambito della località, gli assegna il permesso fittizio. Il terzo ed ultimo trigger, a cui si è dato nome delete na, è 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 località, il trigger automaticamente inserisce il nuovo permesso e cancella il permesso fittizio, di cui non c è più 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 è facile intuire, è 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 è rappresentato un albero binario e, con una linea tratteggiata, x4 x x5 x2 x7 x6 x3 x1 Figura Schema di funzionamento di un indice per una tabella il puntatore alla riga della tabella contenente lo specifico valore del campo. La proprietà saliente degli alberi binari è che per ogni nodo, nel sotto albero di destra 42

50 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 perché, partendo dal nodo superiore (nodo radice) e operando gli opportuni confronti sul valore che si intende cercare, è possibile spostarsi a destra o a sinistra lungo i singoli rami dell albero escludendo automaticamente dalla ricerca l intero sotto albero opposto. È possibile dimostrare in termini matematici che il tempo di ricerca medio negli alberi binari è log 2 N dove N è 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 è 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, è 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, è consigliato piuttosto stabilirne un numero ridotto solo per i campi più 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 perché tali campi, essendo utilizzati nella costruzione delle relazioni, sono spessissimo coinvolti nelle operazioni di ricerca. Ipotizzando quali possano essere le operazioni compiute più frequentemente sul database, si sono isolati, per ogni tabella, i campi più utilizzati e si è optato per la definizione dei seguenti indici: Un indice per il campo nome nuovo della tabella località per velocizzare la ricerca per nome delle località; 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 idlocalità della tabella articolo per velocizzare la ricerca degli articoli di diario collegati ad una determinata località; Un indice sul campo idlocalità della tabella immagine per velocizzare la ricerca delle immagini collegate ad una determinata località; 43

51 2 Il Database di ArcheoMap Un indice sul campo idlocalità della tabella reperto per velocizzare la ricerca dei reperti collegati ad una determinata località; Un indice sulla tripla di campi idreperto, idoggetto, e tipo della tabella riferimento per accelerare la ricerca dei riferimenti di un reperto. 44

52 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 può 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) è 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) è 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

53 3 L interfaccia Web pagine Web dinamiche. Le pagine Web di tipo statico sono il caso più semplice: il contenuto è 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, è 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 più 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 vedrà dapprima quale soluzione si è adottata per la creazione del sito di ArcheoMap, quale l architettura generale, strumenti e linguaggi utilizzati e infine si farà 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 è 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 più possibile user friendly, 46

54 3 L interfaccia Web i risultati, nascondendo all utente la complessità 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; Poiché 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; Poiché il progetto ArcheoMap è aperto alla comunità 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 ciò che si cerca di realizzare, per evitare ridondanze e rendere il prodotto finale facilmente mantenibile ed espandibile, è 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 usabilità 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 è 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 è il tempo, per cui ciò che è più in basso nel diagramma accade temporalmente dopo ciò che è più 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

55 3 L interfaccia Web Interfaccia Sicurezza Script DataBase Comando Verifica sicurezza Elaborazione comando Accesso dati timeline 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 può 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 più 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 può infine visualizzare quanto richiesto. 48

56 3 L interfaccia Web Le entità 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 script 2 per l implementazione della logica di funzionamento; infine il database che raccoglie i dati da elaborare. Nel seguito verranno descritte le prime tre entità, in quanto l ultima è già stata esaurientemente dettagliata nel capitolo Apache e il linguaggio PHP Prima di descrivere le componenti logiche in cui è suddiviso il progetto, è 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 è 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 è un Web Server sviluppato a partire dal 1995 dalla comunità 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 perciò presa come riferimento. Nonostante la concorrenza di prodotti proprietari, Apache è il Web Server più diffuso al mondo, perciò anche la documentazione relativa è abbondante. Conseguenza diretta del suo successo è 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 è un linguaggio di programmazione inventato da Rasmus Lerdorf nel 1994 e reso di pubblico dominio nel La versione del linguaggio presa come riferimento per lo sviluppo di ArcheoMap è PHP4. Si tratta di un linguaggio concepito appositamente per la gestione delle pagine Web dinamiche, e come tale si caratterizza per la semplicità di integrazione nel codice HTML e per l ampio supporto ai diversi DBMS. PHP è 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 è 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 è chiamato dal Web Server 49

57 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 verità non in modo completo, ma comunque sufficiente per le esigenze del caso) e quindi permette di scrivere codice più 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 Creazione del template Nella realizzazione dell aspetto grafico di un sito Internet non c è 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 più 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 più a suo agio nella navigazione e gli risulta più facile capire dove rivolgere lo sguardo alla ricerca di ciò 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 è 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 è preferito 50

58 3 L interfaccia Web utilizzare, per via della sua flessibilità e semplicità, Savant2, totalmente scritto in PHP e quindi ben integrabile con il resto del progetto. Il modello che si è pensato di utilizzare per il sito di ArcheoMap è un classico layout a tre colonne, con intestazione e fondo pagina. Nella figura 3.2 è 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 è 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 è divisa in tre pannelli: uno centrale, più ampio, riservato alla presentazione dei contenuti veri e propri (vuota nel caso della figura), e due pannelli laterali più 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 località sta operando in quel momento. Lo spazio a fondo pagina è 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 manutenibilità e chiarezza dal paradigma della programmazione ad oggetti, si è definita una classe di template chiamata tpl, che definisce attributi e metodi generali della pagina. Nel diagramma 3.3 è ri- 51

59 3 L interfaccia Web titolo nome_menu tpl +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 può 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 è 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 località 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 più 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 già effettuato login oppure no. Se si, nel menu di navigazione 52

60 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 loggato 3. Questa classe costituisce la base su cui sono create tutte le pagine del sito. In particolare, ogni pagina è a sua volta una classe, che estende la classe base tpl e ne sovrascrive i metodi per adattarli alle necessità proprie del contenuto da visualizzare e gestire. In termini di progettazione si realizza il diagramma di figura 3.4 dove progetto.php località.php reperti.php progetti.php reperto.php diario.php tpl scheda_min.php articolo.php immagine.php galleria.php Figura 3.4. 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 è una classe figlia di tpl. 3 Per brevità, si userà 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

61 3 L interfaccia Web CSS Se la realizzazione del template permette di definire la forma di ogni pagina, specificando di quante parti è composta e la relativa posizione nello spazio, tutto ciò 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 è abbreviazione di Cascading Style Sheet, che in italiano può essere reso come fogli di stile, e identifica lo standard definito dal W3C 4 nel 1996 per descrivere la resa grafica di una pagina HTML. La sintassi di un CSS è composta da una sequenza di istruzioni in cui, per ogni elemento, è possibile specificare una serie di attributi riguardanti il suo aspetto. È inoltre possibile creare delle categorie che racchiudono più elementi con un aspetto comune. Una delle caratteristiche più apprezzate dei CSS è la possibilità di poter raggruppare tutte le istruzioni che li formano in un file esterno alla pagina. Questo consente di rendere il codice del template più 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 è 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 è obbligatorio compilare siano in rosso. Con l accoppiata template e CSS si è 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 ciò 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 è 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 è composto il sito è a tutti gli effetti una Web application a sé stante che esegue tutte le operazioni necessarie e gestisce, ad alto livello, l accesso alla base dati. 4 W3C è il consorzio super partes che si occupa della definizione degli standard per le tecnologie del Web 54

62 3 L interfaccia Web 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 più input da parte dell utente, esegue delle elaborazioni e produce un output. I modi in cui è previsto l utente interagisca con una Web application in Archeo- Map 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 è 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 località 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 più 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 è scritto all interno dei metodi definiti dalla classe base tpl (vedasi figura 3.3), la cui implementazione effettiva dipende dal contesto. Nel caso più generico, l algoritmo seguito dalla Web application è 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 è così prosegue, altrimenti mostra un messaggio di avvertimento e termina l esecuzione; 3. Se è 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 è richiesto l inserimento di nuovi dati nel database: 55

63 3 L interfaccia Web (a) Controlla che i campi siano stati compilati correttamente. Se non è 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 è richiesta la cancellazione di dati già 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 PEAR DB, l interfaccia al database PEAR sta per PHP Extension and Application Repository ed è 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 può disporre di codice già scritto e testato dalla comunità open source che può essere da subito integrato nell applicazione abbreviando notevolmente i tempi. Tra i vari pacchetti presenti su PEAR è 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 è vero che come base di sviluppo di ArcheoMap si è scelto di utilizzare PostgreSQL, è 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 ciò è presto detta: se nel futuro si desiderasse sostituire PostgreSQL con altro prodotto analogo, è meglio poterlo fare con il minor numero di modifiche possibile. La progettazione a componenti utilizzata lungo tutto lo sviluppo di ArcheoMap è 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 è in ascolto, username, password, nome del database), si è provveduto a scrivere tutto il codice delle Web application utilizzando le sole funzioni di PEAR DB per creare e chiudere 56

64 3 L interfaccia Web connessioni, eseguire query, estrarre i risultati e gestire eventuali messaggi di errore. Per il suo ruolo di mediazione, si può affermare che dal punto di vista progettuale PEAR DB agisce come un connettore tra la Business Logic e la Data Access Logic Gestione della sicurezza Tra i requisiti di progetto del sito Web di ArcheoMap vi è la richiesta che il contenuto di una località, 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 località 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 realtà 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 sé che l autorizzazione può essere perseguita con successo solo dopo che un utente è stato correttamente autenticato. Adottando una prassi ormai comune tra i siti Web dinamici che vogliono garantire la riservatezza dei dati, si è scelto di mantenere diviso il software che si occupa dell autenticazione dalla parte che si occupa dell autorizzazione. L autenticazione è sostanzialmente affidata ad una coppia username e password: l utente, prima di accedere alle parti riservate del sito, deve dimostrare la propria identità scrivendo la giusta combinazione di username e password riservate. Se il test viene passato con successo, l utente è considerato autenticato e può 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, è necessaria una breve dissertazione sul protocollo HTTP e sulle sessioni. Cookie e sessioni Il protocollo HTTP ha i suoi pregi nella semplicità 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 unità 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

65 3 L interfaccia Web l autorizzazione, perché ad ogni richiesta è impossibile sapere se l utente si è già autenticato oppure no. Per ovviare a questa mancanza, fin dagli albori di Internet è valso l uso dei cookie. Un cookie è, 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 è autenticato. I cookie hanno una scadenza, oltre la quale non sono più 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 è 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 funzionalità direttamente al Web Server. Si è quindi scritto un modulo per far gestire ad Apache l autenticazione degli utenti e creare due cookie: in uno è 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 è 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 è andato a buon fine vengono generati i due 58

66 3 L interfaccia Web cookie di ArcheoMap di cui si è 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 è 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 è 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 è possibile assegnare ad un utente di ArcheoMap: scrittura diario: un utente che ha questo tipo di permesso può inserire nuovi articoli nel diario di scavo; lettura diario: un utente che ha questo tipo di permesso può leggere gli articoli correntemente presenti nel diario di scavo; scrittura galleria: un utente che ha questo tipo di permesso può inserire nuove immagini nella galleria fotografica; lettura galleria: un utente che ha questo tipo di permesso può 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 località che fanno parte del progetto da lui controllato; può creare nuove località nell ambito del suo progetto; può creare nuovi progetti; può infine gestire i permessi degli utenti associati al progetto e delle località 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 località da lui controllata; può gestire i permessi degli utenti associati alla sua località; 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 località in cui si sta navigando sia ad accesso pubblico, la getperm() restituisce automaticamente vero per ogni richiesta di un 59

67 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 L interfaccia multilingua Il pubblico fruitore di ArcheoMap può essere di qualsiasi nazionalità, non deve quindi essere legato ad una specifica lingua. Per questo nei requisiti si è richiesto esplicitamente di predisporre l interfaccia del sito in modo da poterla tradurre facilmente in altre lingue, oltre all Italiano. La soluzione adottata è predisporre dei file di dizionario contenenti la traduzione di ogni etichetta di testo e di ogni bottone dell interfaccia. Si è creata una cartella lang al cui interno sono tanti file quante sono le lingue in cui è 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 è 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 è registrato, nella tabella utente è riportato il campo lingua in cui è 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 è 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 potenzialità del progetto. Per ognuna di esse verrà data una descrizione dell interfaccia e delle operazioni compiute sul database, qualora ve ne siano. 60

68 3 L interfaccia Web Figura 3.5. Schermata della pagina di login Pagina di login Da questa pagina, di cui viene data un immagine nella figura 3.5 è data la possibilità 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 è, 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 è molto semplice: in centro è 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 dal modulo Perl. Se l utente è riconosciuto, viene impostata la sessione, memorizzati i cookie e infine mostrato un messaggio di benvenuto all utente, che da ora in avanti può proseguire con la navigazione. Altrimenti viene mostrato un messaggio di errore. 61

69 3 L interfaccia Web 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 località ospitati nel database di ArcheoMap. Il pannello di destra è vuoto, mentre nel pannello di sinistra è mostrato un menu Crea nuovo progetto da cui un utente con i privilegi di capo progetto può 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 è 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 località del database per recuperare l elenco di tutti i progetti e, per ognuno di essi, di tutte le località, gestite al momento da ArcheoMap. La tabella è organizzata in tre colonne: nella colonna di sinistra è il nome del progetto; nella colonna di centro è una breve descrizione e l elenco delle località 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

70 3 L interfaccia Web questi attivati solo per utenti che hanno permesso di capo progetto. Le località che sono ad accesso riservato sono indicate da una piccola icona di un lucchetto (nell esempio Pompei). I nomi dei progetti e delle località celano dei link parametrizzati: l utente, cliccando su di essi, viene rediretto ad una pagina contenente i dettagli per l elemento scelto Dettagli della località Dalla pagina riportata nella figura 3.7 si leggono le informazioni relative ad una località, e che sono contenute nella tabella località del database. Figura 3.7. Schermata della pagina con i dettagli di una località La grafica di questa pagina sfrutta tutte e tre i pannelli messi a disposizione dal template. Nel pannello di sinistra vi è 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 località, e due bottoni Cancella e Modifica per cancellare la località oppure per modificarne le informazioni associate. 63

71 3 L interfaccia Web Un bottone al fondo della colonna di sinistra permette di scegliere se la località deve essere esportata sul palmare dell utente oppure no. Il testo del bottone cambia sulla base dello stato corrente: se la località è già selezionata per l esportazione su palmare (come è il caso dell esempio in figura) allora il bottone permette di disabilitare tale opzione; viceversa, se la località non è 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 località 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 località si trova attualmente. Il progetto e la località attuali sono scritti in blu scuro su fondo azzurro, mentre le rimanenti sono scritte in bianco su sfondo azzurro. Pressoché identica è la pagina che mostra i dettagli per il progetto, su cui perciò non ci si soffermerà oltre Inserimento di una nuova località L operazione di inserimento di una nuova località in un progetto è riservata ai soli utenti che hanno privilegi di capo progetto per il progetto in cui la nuova località va inserita. Se questo requisito è soddisfatto, dalla pagina con i dettagli del progetto c è un pulsante Nuova località che apre la schermata di figura 3.8 da dove è possibile effettuare l inserimento. Lo spazio della pagina è 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 è 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 località. Se l inserimento è andato a buon fine e non si generano errori, la località viene inserita nel database e collegata al progetto corrente. Poichè è obbligatorio che una località abbia un proprio direttore scavo (vedasi figura 2.20: la relazione direzione è a partecipazione obbligatoria), di default viene assegnato 64

72 3 L interfaccia Web come direttore scavo lo stesso capo progetto. Starà poi a quest ultimo, se lo ritiene necessario, andare nella pagina di gestione degli utenti e assegnare un nuovo direttore scavo. Figura 3.8. Schermata della pagina per la creazione di una nuova località Diario si scavo Se alla pagina dei dettagli della località si clicca sul link Diario di scavo la pagina che viene mostrata è quella di figura 3.9. Qui è possibile leggere il diario di scavo scritto mano a mano dagli utenti che collaborano alla località. Nel menu di sinistra sono mostrati dei link che consentono di spostarsi verso le altre sezioni di interesse o di ritornare alla località, e un bottone per inserire una nuova nota al diario. Nel menu di destra è 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 località 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 località 65

73 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 Inserimento nuovo articolo Se l utente preme sul pulsante Nuova Nota accede alla pagina mostrata nella figura 3.10 da cui può inserire un nuovo articolo nel diario di scavo. Nella parte sinistra è 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, è 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

74 3 L interfaccia Web Figura 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 più visualizzati. Infine, il link Abbreviazioni da tastiera visualizza un breve help in linea in cui è mostrato il legame tra le funzioni della pagina e una scorciatoia da tastiera per velocizzarne l uso. Al centro della pagina, il contenuto è rappresentato dal form per l inserimento della nuova nota. L utente può inserire il titolo e il corpo dell articolo nei due campi di testo al centro. Il campo con il nome dell autore è automaticamente precompilato con il nome dell utente corrente. Per rendere l interfaccia il più famigliare possibile agli utenti, si è 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

75 3 L interfaccia Web oppure in grassetto; Pulsanti per cambiare la formattazione del testo: allineamento a destra, centrato oppure giustificato; allineamento a sinistra, 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 Galleria fotografica Dalla pagina galleria.php si accede alla galleria fotografica associata alla località, che si presenta come in figura Figura Schermata della pagina con la galleria fotografica 68

76 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 è 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 località 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 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 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, è sufficiente che operi una scelta dal menu a tendina immediatamente sopra alla 69

77 3 L interfaccia Web foto. Se invece si desidera vedere l immagine nelle sue dimensioni reali, è 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 è 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 è l autore stesso o non ha i privilegi di capo progetto o direttore scavo, tale pannello non viene visualizzato Elenco dei reperti Nella figura 3.13 è mostrata la schermata della pagina con l elenco dei reperti associati ad una località. Il contenuto è 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 località 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 Dettagli reperto La pagina con i dettagli dei reperti si presenta come in figura 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 è legato. La tabella è divisa in quattro colonne: la prima a sinistra dice il tipo di riferimento (galleria fotografica, nota da diario, scheda ministeriale); nella seconda 70

78 3 L interfaccia Web Figura Schermata della pagina con l elenco dei reperti colonna è 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 Gestione dei permessi L ultima sezione del sito presa in considerazione è quella che riguarda la gestione degli utenti. Si tratta di pagine a cui può accedere solamente il personale con permessi di capo progetto o di direttore scavo. Se dalla pagina con i dettagli della località (vedi figura 3.7) si clicca sulla voce Personale del menu di sinistra, si apre la schermata riportata nella figura Da questa pagina si vede l elenco degli utenti che sono al momento associati con la località 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 idlocalità corrisponde alla località corrente. Una volta ottenuto 71

79 3 L interfaccia Web Figura 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 è un campo che indica se l utente ha responsabilità di direttore scavo; infine nella quarta colonna più a destra sono due bottoni per cambiare le impostazioni dei permessi. Il nome dell utente è 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 località a cui l utente è associato e i relativi permessi. 72

80 3 L interfaccia Web Figura Schermata della pagina di gestione degli utenti 73

81 3 L interfaccia Web Figura Schermata della pagina con i dettagli sui permessi utente 74

82 Capitolo 4 Gestione delle mappe 4.1 Introduzione ai sitemi GIS e al Web mapping Una mappa è un modello bidimensionale della superficie terrestre che cerca di riportare nel modo più 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 attività umane, fin da tempi antichissimi. I primi tentativi di disegnare una mappa risalgono addirittura al 6500 a.c. (mappa di Chatalhöyük in Turchia), vale a dire ben 3000 anni prima dell avvento della scrittura. Sebbene indispensabili in più 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 attività 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 è l acquisto di una nuova mappa; 3. Non permettono di selezionare il tipo di informazione a cui si è interessati: la mappa riporta costantemente tutte le informazioni disponibili senza la possibilità di visualizzarne temporaneamente solo alcune per una maggior facilità 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 fruibilità e consentono la creazione di nuovi servizi. È il caso di ArcheoMap, in 75

83 4 Gestione delle mappe cui si è sviluppato un sistema per visualizzare, in tempo reale, su una mappa, la dislocazione delle località 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 complessità della materia, di seguito verranno date alcune definizioni e accennati aspetti utili a comprendere la gestione delle mappe e i servizi associati 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 è formata la mappa come l elenco dei punti che li definiscono e relative coordinate. Questo significa che una mappa memorizzata in formato vettoriale è come un complesso poligono, di cui sono forniti i punti, ad ognuno dei quali corrispondono delle coordinate per la georeferenziazione 1. 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, perché facilmente riconducibili ai concetti geometrici di linea e segmento. In formato raster sono invece le immagini satellitari o le mappe dei rilievi montuosi perché richiedono una resa grafica ricca di sfumature di colore e di dettagli dalle forme troppo complesse per poter essere riprodotte con punti e linee 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 è in grado di dire a quale coordinata geografica corrisponde, effettuando cioè la georeferenziazione. Una caratteristica propria dei software di gestione per le mappe digitali è 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 è una procedura che permette di assegnare le coordinate standard (secondo una data proiezione) ai punti di un immagine 76

84 4 Gestione delle mappe immagini satellitari del Paese, è possibile visualizzarle assieme (sovrapponendo le immagini satellitari con i tracciati stradali) oppure selezionare quali vedere in un dato momento. Si realizza cioè la selettività delle informazioni 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 più descrizioni. L obiettivo di un sistema GIS è di consentire all utente di cercare informazioni spaziali che possano essere utili per lo svolgimento di attività lavorative o private e di visualizzarle selettivamente su di una mappa. Un sistema GIS è 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 è 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 è in grado di interfacciarsi ad un Web Server: l utente, dal suo browser, fa richiesta di una pagina Web su cui è disegnata la mappa e può 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 è quello di creare per ArcheoMap un sistema informativo che consenta di visualizzare su una mappa la dislocazione delle località 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

85 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 (selettività 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 è MapServer. Realizzato presso l Università del Minnesota in collaborazione con la NASA, viene mantenuto oggi da una comunità di sviluppatori sparsi in tutto il mondo e impiegato in una pluralità di progetti che puntano ad offrire servizi via Web su base geografica. L obiettivo di MapServer è quello di fornire uno strumento per gestire e pubblicare mappe via Web, ma non è, per scelta degli autori, un sistema GIS in quanto non prevede strutture integrate per la connessione ai database e dispone di limitate capacità analitiche sui dati. Tuttavia le funzioni di MapServer sono rese disponibili tramite un API 2 per vari linguaggi di programmazione, tra cui il PHP: è 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 è 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 può 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 è 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

86 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 è il prodotto della sovrapposizione di più layer, ossia di livelli di informazione, ognuno contenente un insieme di dati omogenei che devono essere rappresentati insieme. La visualizzazione dei layer è sotto il controllo attivo dell utente, che può scegliere quale visualizzare. Durante la generazione della mappa, inoltre, MapServer può svolgere autonomamente determinate operazioni come la visualizzazione delle etichette di testo, con la possibilità di non mostrare le etichette al di sotto di un certo fattore di ingrandimento per evitare di sovraffollare la mappa; può generare autonomamente la legenda e l indicatore del fattore di scala; può 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 Il mapfile Il mapfile è 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

87 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 è ristretto all oggetto che li include, da cui sono dipendenti. Un esempio di sintassi di un mapfile è 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 è figlio del primo, in quanto dichiarato al suo interno, e viene perciò processato solo quando è 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 può vedere, alla testa di tutto è l oggetto map che fa da contenitore per tutti gli altri oggetti. Ciò che viene dichiarato al di fuori di esso è 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 unità 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 è composta la mappa. In un mapfile devono quindi essere dichiarati tanti oggetti layer quanti sono i livelli. Ogni layer è 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

88 4 Gestione delle mappe Figura 4.2. Schema gerarchico degli oggetti definiti in MapServer che indica se il layer è 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 può avere più oggetti class definiti al suo interno, l importante è che ve ne sia almeno uno. Il motivo per cui MapServer consente la definizione di più oggetti class è di poter applicare, selettivamente, stili di visualizzazione differenti ai dati memorizzati nei singoli file. Ad esempio, nel caso di una mappa geopolitica dell Italia, è 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

89 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 unità 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 è riportato il mapfile adottato per il progetto ArcheoMap. Per la creazione della versione dimostrativa si è 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 città. Un layer di tipo raster consente inoltre di sovrapporre delle immagini aeree che mostrano l andamento dei rilievi montuosi. Come formato di output si è scelto, per il buon rapporto qualità / dimensione, il formato PNG. Indicatore di scala, legenda e reference map sono fatti gestire in automatico da MapServer I layer di ArcheoMap Tra i layer definiti nel mapfile di ArcheoMap ve ne sono due su cui è necessario soffermarsi: il layer archeo-loc, contenente i punti di georeferenziazione delle località di ArcheoMap, e il layer archeo-reperti, contenente l insieme dei punti di georeferenziazione dei reperti di ArcheoMap. Ciò che rende particolari questi due layer è che i file in cui sono memorizzati i loro dati sono creati e modificati dinamicamente dal codice PHP delle pagine di gestione delle località e dei reperti ogni qual volta vengano creati o cancellati dei record nelle tabelle località e reperti del database. Il formato dei file è GML : si tratta di un formato vettoriale in cui viene descritta una collezione di punti utilizzando il formalismo XML: ogni punto è definito da dei marcatori, detti più propriamente tag, che specificano le singole proprietà di un dato. La sintassi definita nel GML per la dichiarazione di un punto è la seguente: <punti fid="1"> <ID>10</ID> <NAME>Nome della localita </NAME> 82

90 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 località e i reperti di cui è 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 località e i reperti del database di ArcheoMap possono comparire nella cartina geografica digitale, come richiesto dai requisiti PHP/MapScript PHP/MapScript è un insieme di funzioni e di classi che permettono al programmatore di accedere alle funzionalità 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 potenzialità 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 è costituita da un insieme di classi che ricalcano gli oggetti definiti da MapServer per i mapfile. Ad esempio, è 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 è di meglio chiarire come sono strutturate, perché nella realtà gli attributi e i metodi definiti per ciascuna classe sono molto più numerosi e consentono di modificare ogni singolo aspetto delle mappe generate da MapServer. È possibile, ad esempio, cambiare dinamicamente il 3 Shapefile è 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

91 4 Gestione delle mappe MapObj width height imagetype extente units +draw() +getlayer() +setextent() LayerObj status name data labelitem +draw() +querybypoint() ReferenceMapObj width heigth color +set() 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 è 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

92 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 più rispetto al modello della figura 4.1, la vera novità è costituita dal database, a cui lo script PHP può accedere per integrare le funzionalità di cartografia e georeferenziazione con le funzionalità di ricerca sui dati. Ogni operazione effettuata sulla mappa comporta una o più 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 è effettivamente cambiato. 4.4 MapServer integrato nel sito di ArcheoMap Una volta descritte le proprietà di MapServer, i concetti fondamentali che stanno dietro alla sua filosofia di funzionamento e come li si è 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 può effettuare. Quando si apre la pagina delle mappe, la schermata di fronte a cui si trova l utilizzatore è 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 è posta la mappa con l indicatore di scala. Sulla mappa sono mostrati in prima istanza i layer dei confini geografici, delle città, 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 è 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

93 4 Gestione delle mappe Figura 4.5. Schermata iniziale della mappa disegnata da MapServer Con lo strumento ricentra si cambia il punto che è al centro della mappa. Ad esempio, a partire dalla situazione di figura 4.6, se si punta il mouse sulla città 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, è sufficiente selezionarlo dal pannello e premere il bottone aggiorna : quello che si ottiene è l immagine di figura 4.8. Nel menu intitolato Informazioni si dispone di uno strumento per la misura 86

94 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 è riportato in figura 4.9: un segmento di puntini rossi indica i due punti tra cui si è 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 è 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 è un servizio di Web Mapping gratuito fornito dal celebre motore di ricerca Google e messo a servizio del pubblico a partire dalla fine del Ciò che ha reso famoso Google Maps rispetto agli altri servizi di Web Mapping presenti in rete è la disponibilità di un ricco repertorio di foto satellitari ad elevato dettaglio 87

95 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 più 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 è 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 più significative forme di utilizzo. Il vantaggio offerto dalla tecnologia AJAX è che, ad ogni richiesta dell utente, anzichè ricaricare completamente la pagina con i dati aggiornati, come avviene nelle applicazioni Web tradizionali, vengono modificate le 88

96 4 Gestione delle mappe Figura 4.8. Schermata della mappa con i rilievi montuosi 89

97 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 necessità, diminuendo così la quantità di dati che deve essere scambiata tra client e server e dando una sensazione di maggiore reattività all utente. Quando Google Maps è 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) è tale la qualità delle mappe messe a disposizione che si è pensato, a titolo sperimentale, di includerlo in ArcheoMap. Attualmente quindi sul sito sono disponibili due mappe: una gestita con MapServer, che può essere considerata la versione ufficiale, e una gestita con GoogleMaps a scopo di test. Nella figura 4.10 è mostrata la pagina con Google Maps: la schermata è 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, è la mappa satellitare; 90

98 4 Gestione delle mappe Figura 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 flessibilità 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 è mostrato il livello di dettaglio raggiungibile dalle immagini satellitari di Google Maps; si è fatto un ingrandimento sulla zona archeologica di Pompei: se ne può 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 utilità che possono rivestire mappe dettagliate come quelle proposte da Google, non si può 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 città 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

99 4 Gestione delle mappe Figura Schermata con dettaglio di Google Maps ingrandita 92

100 Capitolo 5 Il programma su Palm 5.1 Introduzione ai dispositivi palmari Il mondo dell informatica è stato rivoluzionato nella seconda metà 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 più complesse di una semplice calcolatrice e dotati di una certa quantità 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 potenzialità come veri e propri computer in miniatura tanto da coniare per essi il termine di mobile computing con cui si intende la possibilità di tenere sempre con sè i propri dati sensibili e le applicazioni più importanti per mezzo di dispositivi più 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 è divenuto per un certo periodo sinonimo di computer palmare. Le caratteristiche che hanno contribuito alla diffusione dei dispositivi di Palm sono la semplicità di utilizzo, il favorevole rapporto qualità / prezzo e la disponibilità 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 è mostrato un tipico dispositivo prodotto da Palm. La superficie è dominata dallo schermo touchscreen, diviso in due parti. Nella sezione superiore è visualizzata l area di lavoro, dove si vede l output dei programmi e del sistema operativo; la sezione inferiore è 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 attività e il 93

101 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 è 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 è spento. Va da sè che, qualora la batteria si scaricasse completamente, tutti i file e le applicazioni verrebbero persi irrimediabilmente. Queste peculiarità 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 analizzerà 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 concluderà con una carrellata di 94

102 5 Il programma su Palm immagini per illustrare nel dettaglio le funzionalità del prodotto finale. 5.2 Requisiti del programma su Palm TM L obiettivo è quello di produrre un applicazione da far eseguire su un dispositivo PDA 1 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 già prese da altri. Il legame palmare / utente è univoco, nel senso che ogni dispositivo, al momento di essere assegnato ad una persona, ne eredita implicitamente i permessi, ed è responsabilità 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 funzionalità già implementate sul sito, con la stessa organizzazione logica. In particolare si richiede che l utente, a partire dall elenco dei progetti, possa esplorarne le località 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 multimedialità, 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 può più essere affidata alla sola esperienza del programmatore. Si rende quindi necessaria una maggiore pianificazione che consenta di definire prima tutte le caratteristiche e le funzionalità 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, è sinonimo di palmare 95

103 5 Il programma su Palm concepito a quando ne termina la produzione. cinque: Queste fasi sono sostanzialmente 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 funzionalità 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 è un semilavorato di input per il passo successivo. Il grande pregio di questo 96

104 5 Il programma su Palm modello è la sua semplicità 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 può 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 più dinamici raggruppati sotto il nome di modelli evolutivi, di cui il modello incrementale ne è un esempio. Le fasi in cui viene scomposto il processo sono le stesse viste poco sopra, così come la loro successione, ma anzichè concludersi con un unico software definitivo si punta a rilasciare, nel più 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 più raffinati fino a giungere al prodotto finale. Prodotto finale che può 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 funzionalità 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 difficoltà dal lato progettuale, in quanto è 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 complessità crescente, si afferma nel corso degli anni 70 il paradigma della programmazione ad oggetti. Tradizionalmente la programmazione è 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 più 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 entità 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 è 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

105 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, è 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 è 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 potenzialità 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 è sfruttato il paradigma ad oggetti per la stesura di un software modulare ed efficiente, tenendo contemporaneamente conto delle difficoltà rappresentante dallo sviluppo su un sistema dalla limitate capacità come lo sono i computer palmari Analisi dei requisiti Lo scopo dell analisi dei requisiti è 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 più 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, è 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 località di ogni progetto e i suoi dettagli; per ogni località 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

106 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 già 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 perciò essere fattibili solo dal sito; 5. Essendo ogni PDA legato in modo diretto ad un utente, la gestione dei permessi è semplificata in quanto il programma eredita automaticamente i permessi dell utente a cui è 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 può leggere il diario di scavo, non vi dovranno essere articoli in memoria. Il programma deve però 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 è responsabile del dispositivo e del suo contenuto; è però richiesto l inserimento di username e password per l inizializzazione del programma; 7. Poichè il numero di progetti e località 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 località che sono di suo interesse; 8. Se il palmare è 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 località; 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 già 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

107 5 Il programma su Palm 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 è 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 attività (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 è 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 è l insieme degli attributi, cioè le caratteristiche che le sono proprie; l ultima fascia in basso è l elenco dei metodi, ossia le azioni che una classe può compiere. Molto spesso non è necessario dettagliare una classe esplicitandone gli attributi e i metodi; in tali frangenti, per semplicità si può 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 è dichiarato come privato, ad esso si può accedere solo dall interno della classe che lo contiene. Viceversa, un attributo o un metodo dichiarato pubblico è liberamente 100

108 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 è chiedere all oggetto stesso di modificarlo chiamando un suo metodo pubblico. É 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 semplicità, non si specificano i metodi getter e setter in quanto la loro presenza è implicita. Le relazioni che legano tra di loro le classi sono principalmente di tre tipi: Relazione di composizione: una classe A, detta componente, è in relazione di composizione con una classe B, detta contenitore, se ogni oggetto istanza di B contiene al suo interno una o più istanze di A; graficamente la composizione è indicata da una freccia con punta romboidale piena; Relazione di aggregazione: è concettualmente identica alla relazione di composizione, ma più 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

109 5 Il programma su Palm Relazione di generalizzazione: una classe A è 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 ereditarietà, in cui A è la classe padre (detta anche superclasse ) e B è la classe figlia; graficamente tale relazione viene resa con una freccia dalla punta triangolare vuota; Relazione di associazione: è la relazione più generica che lega due classi A e B per indicare che queste si relazionano tra loro: A può chiamare metodi di B e viceversa; sono associazioni tutte le relazioni che non possono considerarsi composizioni, aggregazioni o generalizzazioni. Nella figura 5.4 è riportato lo schema grafico delle relazioni che legano le classi in un Class Diagram. Poichè in un programma mediamente complesso è 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, è comodo organizzarle in insiemi omogenei che prendono il nome di package. Il criterio di omogeneità viene stabilito dai progettisti contestualmente all utilità 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

110 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 è 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 Diagramma delle classi di ArcheoMap Per tracciare il Class Diagram di ArcheoMap si parte dall analisi dei requisiti esposta nella sezione per estrarne i concetti fondamentali da modellare. Dal momento che i programmi su palmare utilizzano un interfaccia grafica, è 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 è 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, è possibile identificare un sottinsieme di caratteristiche comuni a tutti. In particolare 103

111 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. È possibile anche trovare dei metodi comuni, per definire i quali tuttavia è necessario prima fare una piccola digressione sulla programmazione ad eventi. Start evento? no si processa evento no coda piena? si wait no 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 cioè 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 perchè 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 è vuota l evento viene immediatamente servito, altrimenti rimane in attesa fino a quando non è 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 più specifiche sulla base del tipo di evento che deve gestire. Quando viene aperto un form FrmHandleEvent() chiama la funzione FrmOpenEvent() in cui 104

112 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 è 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. È 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 necessità. Nella figura 5.7 è illustrato lo schema grafico di tale classe e nella tabella 5.1 ne è 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 Archeo- Map 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

113 5 Il programma su Palm Attributi formid GUIObjects Menu Metodi FrmHandleEvent() FrmOpenEvent() FrmCloseEvent() CtlSelectEvent() LstSelectEvent() FldChangedEvent() MenuEvent() GetObjectPtr() 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 più specifici gestisce l evento associato all apertura del form gestisce l evento associato alla chiusura del form gestisce gli eventi generati dalla pressione di pulsanti nel form gestisce gli eventi generati dalla selezione di un elemento di una lista gestisce gli eventi generati dalla modifica di un campo di testo gestisce gli eventi scatenati dal menu restituisce il riferimento ad un oggetto grafico del form Tabella 5.1. Documentazione per la classe GenericForm GUIObject size status Button label List items TextField text Figura 5.8. Diagramma delle classi degli oggetti dell interfaccia grafica A questo punto si è definita l infrastruttura a partire dalla quale è possibie progettare l interfaccia grafica dell applicazione. Per definire quali e quanti form devono essere gestiti è necessario analizzare il punto tre dei requisiti. Innanzitutto è richiesto che il software mostri l elenco di progetti di ArcheoMap e per ognuno ne visualizzi le relative informazioni. La soluzione pensata è di creare un form che presenti 106

114 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 +LoadProjectData() +ShowProjectData() Project TextField 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 località; 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. Poichè infatti ogni reperto è accompagnato da informazioni testuali e da una lista di riferimenti, le liste da gestire sono due. Quando è 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 entità 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 è riportato il diagramma delle classi che modella questo form. 107

115 5 Il programma su Palm GenericForm Locations List LocationsForm +LoadLocationData() +ShowLocationData() Location TextField Figura Diagramma delle classi per LocationsForm GenericForm Articles List ArticlesForm +LoadArticleData() +ShowArticleData() Article TextField Figura 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 è riportato in figura Più complicata è la gestione della scheda ministeriale. Tale documento è 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 è dovuto giocoforza adottare è stata quella di dividere il contenuto della scheda ministeriale su più form, chiamati MinistrySheetEditForm, quattordici per l esattezza: ognuno di essi è composto da alcuni campi di testo, nei quali sono riportati i dettagli della scheda. 108

116 5 Il programma su Palm GenericForm Images List ImagesForm +LoadImageData() +ShowImageData() Image TextField Figura Diagramma delle classi per ImagesForm References List GenericForm Find List FindsForm +LoadFindData() +LoadReferencesData() +ShowFindData() +ShowFindReferences() Find TextField Figura 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 modalità lettura, modifica o inserimento, alle classi che li modellano si è aggiunto un attributo mode che può assumere uno dei tre valori. Se il form viene aperto in modalità sola lettura i campi sono precompilati e l utente può solo leggerli e non modificarli; in modalità modifica i campi sono precompilati e l utente può cambiarne il contenuto; in modalità inserimento i form sono vuoti e l utente deve provvedere da sè a compilarli. 109

117 5 Il programma su Palm Author TextField DateTime TextField Body TextField Title TextField ArticleEditForm mode +LoadArticleData() Figura Diagramma delle classi per ArticleEditForm Author TextField DateTime TextField Notes TextField ImageEditForm mode +LoadImageData() Figura Diagramma delle classi per ImageEditForm Progetto delle classi di dati Come specificato nei requisiti, l applicativo deve gestire i dati di progetti, località, articoli di diario, immagini, reperti e schede ministeriali. Ognuno di questi elementi può 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 entità relazioni del database in quanto il loro compito è 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 novità è costituita dal metodo tostring() il cui compito è quello di restituire al chiamante una stringa di testo in cui sono riportati gli attributi di un istanza della classe. Tale metodo non è l unico: sono definiti anche i metodi getter e setter per leggere e 110

118 5 Il programma su Palm impostare il valore dei singoli attributi, ma che per brevità non sono mostrati nei Class Diagram. Project projectid name description internetaddress phone datestart dateend +tostring() Figura Schema grafico della classe Project In modo analogo si definisce la classe Location (vedi figura 5.17) che corrisponde all entità località definita nella figura 2.3; la classe Article (vedi figura 5.18) che introduce nel progetto dell applicazione l entità articolo di figura 2.7; la classe Image (vedi figura 5.19) equivalente all entità 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 La relazione che lega queste due ultime classi è un aggregazione, cioè una composizione facoltativa, perchè un reperto può 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 interoperabilità 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 è riportato il diagramma temporale per ProjectsForm : 1. L utente apre il form. L evento di apertura viene gestito dal metodo FrmOpen- Event(), 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

119 5 Il programma su Palm Location LocationID public excavation datestart dateend modernname ancientname city state address coordinates description internetaddress phone notes +tostring() Figura Schema grafico della classe Location Article articleid locationid visible creationdate modificationdate author title body +tostring() Figura Schema grafico della classe Article i nomi di questi sono inseriti nella lista, operazione che viene compiuta dal metodo SetItems() della classe ListObject ; 112

120 5 Il programma su Palm Image imageid locationid creationdate author filename notes +tostring() Figura Schema grafico della classe Image Find findid locationid creationdate author findname coordinates +tostring() Reference referenceid objectid objecttype author creationdate +tostring() Figura 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 Load- ProjectData() 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 to- String() per ottenere la stringa che descrive il progetto e questa viene impostata nel campo di testo TextObject. Al termine di questo processo l utente può leggere i dettagli del progetto da lui selezionato. Sequenze del tutto analoghe si applicano agli altri form del programma ArcheoMap. 113

121 5 Il programma su Palm MinistrySheet sheetid findid creationdate locationid etc +tostring() Figura Schema grafico della classe MinistrySheet Figura 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 è 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 è presentato in figura

122 5 Il programma su Palm Permission locationid objecttyps writable Figura Schema grafico della classe Permission Ogni permesso ha come attributo l identificatore della località, 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 può 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 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 è 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 è un dispositivo Palm dotato di sistema operativo PalmOS. Il passaggio da UML a codice non è complicato: se si utilizza un linguaggio di programmazione ad oggetti, infatti, è possibile tradurre quasi immediatamente le classi, i loro attributi e i metodi in istruzioni; quel che richiede attenzione è l implementazione dei metodi, ossia la scrittura della loro logica di funzionamento che durante la fase di progetto è 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

123 5 Il programma su Palm Linguaggio di programmazione: C++ L API fornita da PalmOS agli sviluppatori è scritta nativamente in linguaggio C, il quale presenta il difetto di non supportare la programmazione ad oggetti. Ne esiste però una versione più evoluta, che ne ricalca la sintassi e i costrutti fondamentali, integrandoli con il paradigma della programmazione ad oggetti: tale linguaggio è il C++, che è quello scelto per scrivere il codice dell applicazione. Poichè il C è a tutti gli effetti un sottinsieme del C++, è 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 è 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 è visto nella figura 5.18 class Article { private: Int32 articleid; UInt32 locationid; Boolean visible; DateTimeType creationdate; DateTimeType modificationdate; Char *author; Char *title; Char *body; public: Article() Article(db_articles *p) ~Article() SECTION_PLUSPLUS; SECTION_PLUSPLUS; SECTION_PLUSPLUS; void SetArticleId(Int32 id) SECTION_PLUSPLUS; Int32 GetArticleId() SECTION_PLUSPLUS; void SetLocationId(UInt32 id) SECTION_PLUSPLUS; UInt32 GetLocationId() SECTION_PLUSPLUS; void SetVisible(Boolean flag) SECTION_PLUSPLUS; Boolean GetVisible() SECTION_PLUSPLUS; void SetCreationDate() SECTION_PLUSPLUS; DateTimeType GetCreationDate() SECTION_PLUSPLUS; void SetModificationDate() SECTION_PLUSPLUS; 116

124 5 Il programma su Palm } DateTimeType GetModificationDate() SECTION_PLUSPLUS; void SetAuthore(Char *name) SECTION_PLUSPLUS; Char * GetAuthor() SECTION_PLUSPLUS; void SetTitle(Char *title) SECTION_PLUSPLUS; Char * GetTitle() SECTION_PLUSPLUS; void SetBody(Char *body) SECTION_PLUSPLUS; Char * GetBody() SECTION_PLUSPLUS; Char * ToString() SECTION_PLUSPLUS; Si può 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 particolarità della programmazione sui dispositivi Palm: le sezioni di codice. L architettura hardware adottata da Palm non è in grado di gestire programmi più grossi di 32 KB; si tratta di un limite rilevante perchè nel caso di applicazioni complesse come quella sviluppata per ArcheoMap è 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 è necessario indicare in quale sezione va inserito. Nel caso di ArcheoMap si sono create quattro sezioni: SECTION FORMS nel quale è raccolto tutto il codice macchina che si occupa della gestione dei form; SECTION AUTODB nel quale è 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 utilità; Nella definizione della classe Article vista sopra, ad esempio, i metodi sono tutti assegnati alla sezione SECTION PLUSPLUS. Tale aspetto del processo di sviluppo è 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, perchè può presentare, come in questo caso, delle problematiche sue proprie. 117

125 5 Il programma su Palm Strumenti di sviluppo Il linguaggio C++ è 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 più in generale nel mondo Open Source, il compilatore per eccellenza è il GCC (Gnu C/C++ Compiler), il quale è 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 può effettuare delle ottimizzazioni, ed infine crea il codice macchina. Il problema è che il codice macchina utilizzato da un normale PC è 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 è 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 è 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 è ottenuto un eseguibile dalle dimensioni più compatte, quindi che non necessita di ulteriori sezioni di codice, e più veloce a svolgere le operazioni richieste. Per testare il programma ci si è avvalsi dell uso dell emulatore POSE (Palm OS Emulator). Un emulatore è 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 è 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 più lungo e tedioso il lavoro di sviluppo. A titolo 118

126 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 è 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 Schermata con l elenco dei progetti Per poter accedere alle sezioni successive del programma è 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 è possibile proseguire oltre. Se l utente ha effettuato correttamente il login, cliccando sul bottone Apri del form dei progetti può accedere all elenco delle località che fanno parte del progetto selezionato, come mostrato in figura Il pulsate < consente di tornare alla 119

127 5 Il programma su Palm Figura Schermata delle preferenze Figura Schermata con l elenco delle località 120

128 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 più esteso e chiaro i dettagli inerenti alla località 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 Schermata con i dettagli di una località Il form del diario di scavo si presenta come in figura 5.28: nella parte superiore c è 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 già esistente si effettuano in un form che si presenta come in figura Dopo aver compilato i campi si può 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 è 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

129 5 Il programma su Palm Figura Schermata con l elenco degli articoli di diario Figura Schermata per la modifica / creazione di un articolo 122

130 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 già 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 perchè di esso se ne parlerà più diffusamente nel capitolo successivo a proposito del GPS. Figura 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 località per trovarsi di fronte alla schermata di figura La disposizione degli elementi è quella ormai nota: in alto c è 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 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 già esistente si opera nel form di figura Oltre ai campi di testo da compilare per specificare i dettagli da associare all immagine, c è il pulsante Foto che apre l interfaccia di 123

131 5 Il programma su Palm Figura Schermata con l elenco delle immagini della galleria Figura Schermata per la creazione o modifica di un immagine 124

132 5 Il programma su Palm Figura Schermata di gestione della fotocamera integrata gestione della macchina fotografica integrata per quei dispositivi che ne possiedono una (vedi figura 5.33). 125

133 Capitolo 6 Il GPS 6.1 Introduzione al GPS Il sistema GPS (Global Positioning System) è 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 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 però fu evidente l utilità 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

134 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 è costituito da 24 satelliti orbitanti ad un altezza di circa km, di cui 21 effettivamente utilizzati nella trasmissione del segnale di georeferenziazione, mentre i restanti tre sono di scorta, ossia è previsto che entrino in azione solo in caso di guasto o inoperatività 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 è stato trasmesso e l orario in cui viene ricevuto. Se T 1 è l istante in cui il segnale viene trasmesso, T 2 è l istante in cui viene ricevuto è c è la velocità delle onde elettromagnetiche nel vuoto, si ricava che la distanza D tra antenna e satellite è: D = c(t 2 T 1 ) Conoscere la distanza da un solo satellite non è sufficiente a determinare la posizione poiché, non sapendo nulla della relativa posizione dell antenna (ad esempio se è 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 è 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 è data dall intersezione di tre sfere di raggio noto che danno luogo a due punti, di cui normalmente uno può essere scartato perché situato ad altissima quota (vedi figura 6.2). Se ne deduce quindi che con tre satelliti è già possibile determinare la posizione del ricevitore. Con il segnale di un quarto satellite la misurazione è certa e precisa perché l intersezione di quattro sfere individua un unico punto. In realtà la misurazione non è precisissima, come già detto, ma è 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

135 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 è più lenta perché necessita di una fase preliminare di sincronizzazione tra ricevitore e satelliti, mentre le rilevazioni successive, che avvengono circa una volta al secondo, sono molto più veloci. Il principale difetto del sistema GPS è quello di poter funzionare solo se il cielo è ben visibile, quindi non è 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 è 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 già tra le tecniche di misurazione adottate dagli archeologi. 6.2 Standard NMEA NMEA sta per National Marine Electronics Associations ed è 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

136 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 ricorderà dalla sezione precedente che lo standard GPS è 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 è 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 velocità di riferimento è 4800 bps, ma sono comunque considerate velocità 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 varietà 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 è quella che inizia con il prefisso $GPRMC. $GPRMC (Recomended Minimum Specific) è una delle frasi più complete, comprendente dati essenziali relativi a data e ora del fix, posizione rilevata, velocità e qualità 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 è la seguente: Campo Formato Descrizione 1 hhmmss.ss Ora 2 A Stato: A = attivo, V = nullo 3 nnnn.nn Latitudine 4 A Emisfero: N = nord, S = sud 5 nnnn.nn Longitudine 6 A Verso: W = ovest, E = est 7 n.n Velocità espressa in nodi 8 n.n Direzione del movimento espressa in gradi 9 ddmmyy Data Tabella 6.1. Descrizione dei campi della frase $GPRMC $GPRMC, ,V, ,N, ,E,,,

137 6 Il GPS Le informazioni contenute sostanzialmente dicono che il messaggio è stato inviato alle ore 20:46:19 del giorno 16/07/2006 e che la posizione rilevata è Nord, Est. Il secondo campo contiene il simbolo V, il che significa che la frase di esempio è nulla, quindi va scartata (un motivo per cui l informazione è nulla è ad esempio perché si è 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 perché il ricevitore non è stato in grado di rilevarne il valore oppure perché la particolare implementazione dello standard fornita dal costruttore prevede di inviare questi dati in altri messaggi. I dati relativi ad ora e posizione sono però 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 può inserirlo direttamente nel programma e rilevarne sul momento la posizione. Per raggiungere questo obiettivo è 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 Interfacciamento Palmare / GPS I dispositivi di palmari dispongono di alcune interfacce seriali per comunicare con altri apparecchi elettronici; i modelli più recenti sono dotati di interfaccia USB, Bluetooth e infrarossi, mentre i modelli più vecchi dispongono solamente dell interfaccia infrarossi e seriale RS232. Ognuna di queste interfacce utilizza lo stesso protocollo di trasmissione, ma le modalità in cui viene aperta la connessione e la gestione degli eventi associati è diverso da caso a caso. Per poter gestire la comunicazione verso un GPS è dunque necessario sapere su quale porta questo è collegato e utilizzare i comandi corretti per essa. Per cercare di mantenere la modularità del codice, si è cercato di progettare le classi per la comunicazione con il GPS in modo tale da slegarsi il più possibile dal tipo di hardware utilizzato. Si è 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 è 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

138 6 Il GPS GPSConnector connected +DeviceConnect() +DeviceDisconnect() +isconnected() +ReadGPS() +GetPosition() BtGPSConnector +DeviceConnect() +DeviceDisconnect() +ReadGPS() SerialGPSConnector +DeviceConnect() +DeviceDisconnect() +ReadGPS() IrGPSConnector +DeviceConnect() +DeviceDisconnect() +ReadGPS() Figura 6.3. Schema grafico delle classi di interfacciamento al GPS Metodo DeviceConnect() DeviceDisconnect() isconnected() ReadGPS GetPosition Descrizione Effettua la connessione al ricevitore GPS Disconnette il ricevitore GPS Restituisce true se il ricevitore è già connesso Legge il flusso di dati emesso dal ricevitore Indica la posizione ricavandola dalla frase $GPRMC Tabella 6.2. 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 perché 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 è Bluetooth, ma per interagire vengono chiamati i metodi della classe GPSConnector. In questo modo, sfruttando l ereditarietà e il polimorfismo 1, se si cambia il tipo di 1 Si dice polimorfismo la proprietà della programmazione ad oggetti per cui, data una classe padre e una classe figlia, è possibile chiamare sulla classe figlia i metodi della classe padre. 131

139 6 Il GPS connessione è 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 è 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 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 Est/Ovest Errore Stato Longitudine Latitudine Nord/Sud Figura 6.4. Diagramma a stati di un parser NMEA Il processo di parsing può essere modellato con la macchina a stati mostrata nella figura 6.4. Una macchina a stati è 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

140 6 Il GPS essere identificati con il riconoscimento dei campi, più due stati ausiliari Errore e Ok per contrassegnare il successo o l insuccesso dell operazione. Il funzionamento di una macchina a stati può 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 è 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 è terminata, allora vuol dire che si è trovato il primo campo della frase NMEA, quello contenente l ora e ci si sposta allo stato successivo. Se invece tale condizione non è soddisfatta vuol dire che si è verificato un errore di trasmissione e si passa allo stato di errore; 4. Se al punto precedente non si è verificato errore, si testa nuovamente la stringa: se questa non è terminata, allora si è trovato il secondo campo della frase NMEA, quello contenente la Latitudine, e ci si può 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 è corretta si esce dalla macchina a stati. Il sistema modellato rispetta tre requisiti essenziali delle macchine a stati: è invariante (a parità di condizioni iniziali il risultato non cambia), è dinamico (evolve nel tempo passando da una condizione ad un altra in funzione dei dati di input e degli stati precedenti) ed è 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 perciò 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 funzionalità del form di modifica e inserimento dei reperti, la cui trattazione era stata rimandata nel capitolo precedente. 133

141 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 è una possibile fonte di intrusioni indesiderate nel sistema). Tenendo conto di questo, il processo si sviluppa in questa sequenza: 1. Se il Bluetooth non è acceso, una finestra di dialogo chiede all utente se vuole accenderlo automaticamente; 2. Se la risposta alla domanda precedente è 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 può selezionare il GPS; 4. Una volta selezionato il ricevitore, viene effettuata la connessione vera e propria; 134