AdaM WebApp: sviluppo di una web application per la gestione di dati di scavo archeologici

Transcript

1 Università degli studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica AdaM WebApp: sviluppo di una web application per la gestione di dati di scavo archeologici Anno Accademico Candidato Christian Cardin Relatore Prof. Massimo Marchiori

2

3 Ai miei genitori, per aver sempre creduto in me Ai miei nonni, per avermi sempre incoraggiato A Silvia, per essermi sempre stata vicina

4

5 Indice 1 Introduzione Scopo del documento La struttura Ospitante Scopo dello Stage Dominio Applicativo FileMaker Server & Client Funzionalità Engine Creazione e denizione di un nuovo database Critiche L'interfaccia AdaM: analisi dell'utilizzo La Base di Dati preesistente Schema Critiche Proposta di un nuovo schema Analisi dei Requisiti Descrizione funzionale Caratteristiche degli utenti Convenzioni per l'analisi dei requisiti Sigle e nomi per i requisiti Sigle e nomi per gli Use Case Use Cases Login System Main Application Gestione Unità Stratigrache Checkout Update Commit Requisiti Requisiti Funzionali Requisiti di Vincolo Requisiti Prestazionali Requisiti di Qualità

6 VI INDICE 4 Tecnologie Utilizzate PHP HTML Javascript & jquery Backbone.js Underscore.js QUnit Persistenza dei dati: YDN-DB Compressione Dati Progettazione Infrastruttura Architettura di alto livello Architettura Fisica Architettura Logica Struttura del Server Package Server & Crypto Package DataObject Struttura del Client Adam.Model Adam.RecordModel Adam.View Adam.Router Fase di Sviluppo e Risultati Sviluppo Server Sviluppo Client Modellazione delle classi Portare l'applicazione oine Views e Templates Test Riassunto dei requisiti soddisfatti Requisiti Funzionali Requisiti di Vincolo Requisiti Prestazionali Requisiti di Qualità Lavoro Futuro Nuove aggiunte Una meta ambiziosa Conclusioni Conoscenze acquisite Considerazioni Personali Bibliograa 73

7 Elenco delle gure 1.1 Logo Dipartimento dei Beni Culturali FileMaker 12 preview Comunicazione tra browser e Filemaker attraverso un server PHP Comunicazione tra browser e Filemaker attraverso richieste XML Interazione tra FileMaker e sorgenti dati esterne tramite ODBC Logic Layers di FileMaker Graco delle relazioni di FileMaker Aspetto di un semplice Layout Inserimento record con FileMaker Schema di AdaM Schema ER rielaborato Schema relazionale rielaborato UC_1: AdaM WebApp Login System UC_2: AdaM WebApp Main Application UC_2.1: Gestione delle schede Unità Stratigrache UC_2.1.2: Inserimento Nuova US PHP logo HTML5 Logo jquery logo Backbone Logo Messaggio sulla pagina del Web SQL Database Schema di risposta HTTP con compressione Richiesta AJAX con JSend Congurazione a due livelli dell'architettura sica Comunicazione tra client e server Schema delle classi della componente server Classi di supporto per l'interfacciamento al database Classi del client, packages e relazioni Client Package Model Client Package RecordModel Client Package View Client Package Router

8

9 Capitolo 1 Introduzione L'idea che sta alla base del progetto AdaM WebApp è di creare un'applicazione web per la gestione e memorizzazione dei dati provenienti da siti archeologici prendendo spunto da una soluzione Client - Server già esistente (Progetto AdaM ) e tuttora in uso presso la struttura ospitante. Non capita di rado che le spedizioni di scavo vengano condotte in luoghi dove la connettività alla rete Internet sia scarsa o del tutto assente, e in questi casi un tecnico specializzato è costretto a recarsi direttamente nel luogo d'interesse e istituire una rete locale che ricrei le condizioni ideali per il normale svolgimento delle attività di archiviazione, installandovi l'applicazione e portandovi una copia della base dati presente sul server principale. AdaM WebApp è pensato per non dover più ricorrere a questa necessità, introducendo quindi un sistema di storage oine durante l'assenza di connettività e successiva sincronizzazione automatica con il database principale una volta riacquisita la connessione. Tutto questo, senza alcun bisogno di particolari congurazioni o software aggiuntivi. 1.1 Scopo del documento La presente Tesi di Laurea, redatta dallo studente Christian Cardin, descrive la realizzazione del progetto svolto durante il periodo di stage, presso il Dipartimento dei Beni Culturali dell'università degli Studi di Padova. Verranno evidenziati gli aspetti relativi all'analisi, progettazione e sviluppo del software, nonché le tecnologie utilizzate, le nuove conoscenze acquisite e gli obiettivi raggiunti. 1.2 La struttura Ospitante Il Dipartimento dei Beni Culturali: archeologia, storia dell'arte, del cinema e della musica (dbc) nasce dalla recente fusione del Dipartimento di Archeologia e del Dipartimento di Storia delle Arti visive e della Musica. Si propone di diventare il polo di aggregazione di tutte le attività di didattica e di ricerca presenti in Ateneo nell'area dei Beni Culturali.

10 2 Introduzione Figura 1.1: Logo Dipartimento dei Beni Culturali In particolare, la sezione di Archeologia ha in attivo diversi scavi sparsi nel territorio nazionale ed internazionale, dove professori e studenti sono impegnati in attività di ricognizione e ricerca. Tra i principali possiamo citare la missione a Nora (Sardegna) di epoca Fenicio-Punica, Gortyna (Creta) di epoca Greca e Tyana-Kemerhisar (Turchia) di epoca Romana. Oltre a questo, sono molte le collaborazioni con enti di vario genere sia pubblici che privati, a partire dalle amministrazioni comunali, regionali, sovrintendenze, aziende locali, cooperative archeologiche e il CNR. Recentemente, grazie alla sinergia tra Università degli Studi di Padova, Soprintendenza per i Beni Archeologici del Veneto e Comune di Montegrotto, è nato il progetto Aquae Patavinae 1 : fulcro di un progetto di valorizzazione, che mira alla diusione della conoscenza del patrimonio archeologico, storico e culturale del territorio delle Terme Euganee che porta le tracce di oltre tremila anni di storia. Degno di nota è anche l'impegno verso progetti di Archeologia e Sviluppo, ramo avanguardistico dell'archeologia tradizionale operante su Paesi sottosviluppati, che si pregge di coniugare operativamente la ricerca allo sviluppo delle comunità locali. Un progetto nato dalla collaborazione con il dipartimento di Ingegneria dell'informazione è il PROGETTO NORACE 2 che integra archeologia, turismo e tecnologia consentendo di guidare il visitatore attraverso un'ampia varietà di percorsi storici, archeologici e artistici, ciascuno illustrato al meglio delle conoscenze disponibili, utilizzando un'infrastruttura tecnologica basata sull'utilizzo di speciali palmari integrati con un GPS e connettività wireless. Grazie agli access point disposti strategicamente nel percorso, l'utente può ottenere informazioni sugli elementi di interesse, visualizzare mappe dettagliate e ricostruzioni 3D. Il lavoro di ricerca condotto dai Docenti del Dipartimento, aiutati dai più giovani collaboratori laureati, Specializzandi, Dottorandi, Assegnisti trova spazio in una serie di Riviste e Collane, alcune delle quali vantano già una lunga tradizione, altre invece di più recente introduzione nella letteratura archeologica, con una varietà di oerta editoriale che risponde alle molteplici linee di ricerca del Dipartimento. Le Riviste si presentano come sede privilegiata per il dibattito e la riessione sui problemi relativi al metodo di indagine, dibattito che spesso

11 1.3 Scopo dello Stage 3 si arricchisce del prezioso apporto di studiosi italiani e stranieri, nonché per la presentazione dei più recenti risultati delle indagini sul terreno; le Collane accolgono invece volumi monograci e miscellanei che approfondiscono specici temi, sovente frutto di lunghi anni di studio. 1.3 Scopo dello Stage L'obiettivo del progetto di Stage è lo sviluppo e realizzazione di un'applicazione web in linguaggio PHP5 (parte Server) e HTML5 - Javascript (parte Client), residente nei server del Dipartimento ed accessibile solamente dai ricercatori coinvolti nelle attività di ricerca tramite un sistema di login, e permetta l'utilizzo del database AdaM per la memorizzazione e visualizzazione dei dati di scavo. L'interfaccia dovrà essere il più possibile simile a quella del software FileMaker attualmente in uso, e al tempo stesso migliorarla tentando di massimizzarne la facilità d'uso e l'intuitività in modo da renderla il più user-friendly possibile. Il software prodotto dovrà minimizzare il più possibile la comunicazione con il server, possibilmente utilizzando tecniche di compressione o caching dei dati, e mantenendo al minimo la dimensione in byte di ogni le trasmesso. Nel caso si perda denitivamente la connettività, o sia del tutto assente, il sistema deve poter continuare il suo funzionamento permettendo lo storing dei dati in locale, per poi mandarli al server una volta recuperata la connessione.

12 4 Introduzione

13 Capitolo 2 Dominio Applicativo La documentazione delle attività giornaliere e la catalogazione dei reperti rinvenuti durante le campagne di scavo avviene per via informatica, attraverso un'interfaccia fornita dal software FileMaker. Tali dati vengono salvati in un database relazionale, denominato AdaM (Archeological DAta Management ) ideato, progettato e realizzato dal dott. Paolo Kirschner. Una grande limitazione è data dalla frequente situazione di scarsa connettività internet in cui molti siti di scavo si trovano, impedendo una veloce comunicazione con il server centrale e un conseguente rallentamento nell'uso di tale strumento. Di conseguenza, all'inizio di ogni campagna un tecnico è costretto a recarsi direttamente in loco per cablare una rete locale, portandovi una copia del database e installando i programmi per la gestione del server e i relativi client, con notevoli problemi di ridondanza, sincronizzazione e aggregazione con i dati provenienti da altre campagne di scavo. 2.1 FileMaker Server & Client FileMaker Pro è un software multi piattaforma sviluppato da FileMaker Inc., conosciuto per essere un database relazionale di grande facilità d'uso che integra strumenti basilari alla gestione e organizzazione dei dati. Attualmente FileMaker Client e FileMaker Server hanno raggiunto la versione 12, rilasciata nell'aprile 2012 e disponibile nella modalità Pro o Advanced. La versione in uso dal Dipartimento è la Pro 10, risalente al Gennaio 2009 ma che condivide molte delle caratteristiche della nuova versione Funzionalità FileMaker Pro integra tools per la creazione di schemi logici relazionali e interfacce grache in un solo pacchetto. Oltre a questo, ci sono altre utili caratteristiche che vengono in aiuto all'utente: Network Sharing: Condivisione e accesso simultaneo al database tra diversi clients attraverso internet. Grazie ad un sistema di autenticazione l'amministratore può decidere i permessi di ogni singolo utente, i dati a cui ha accesso e il tipo le azioni che può compiere.

14 6 Dominio Applicativo Figura 2.1: FileMaker 12 preview Web Publishing: Strumento di pubblicazione automatica del database sul web, accessibile dagli utenti autorizzati tramite un browser senza alcun bisogno di software aggiuntivo. L'amministratore può decidere tra due diverse opzioni PHP Web Publishing: Un tool di generazione automatica produce del codice PHP misto ad HTML, ricalcando la stessa interfaccia graca e funzionalità realizzate. FileMaker API per PHP fornisce un'interfaccia PHP con il database FileMaker orientata agli oggetti. FileMaker API per PHP consente di accedere ai dati e alla logica memorizzati in un database FileMaker Pro e di pubblicarli sul web o di esportarli in altre applicazioni. API supporta anche comandi di ricerca complessi e composti per estrarre e ltrare i dati memorizzati nei database FileMaker Pro. Figura 2.2: Comunicazione tra browser e Filemaker attraverso un server PHP XML - XSLT Web Publishing: La Pubblicazione Web personalizzata XML di FileMaker consente di inviare richieste query a un database FileMaker Pro ospitato da FileMaker Server e visualizzare, modicare o trattare i dati risultanti. Utilizzando una richiesta HTTP con i parametri e i comandi di query appropriati, è possibile recuperare i dati FileMaker come documento XML.

15 2.1 FileMaker Server & Client 7 Figura 2.3: Comunicazione tra browser e Filemaker attraverso richieste XML Static Web Publishing: In questo modo è possibile creare pagine HTML statiche che riportino determinati dati non destinati a cambiare del tempo. External SQL Data Source: Dalla versione 9 è attivo il supporto dei driver ODBC e JDBC per collegare FileMaker ad una base di dati esterna, sostituendo così il DBMS interno ma mantenendo le stesse funzionalità e vantaggi della gestione dei dati attraverso interfaccia graca. In gura 2.4 è mostrato uno schema sulle connessioni logiche tra le componenti. Le origini dati supportate dalla versione 10 sono: 1. Oracle 11g Release 1; 2. MS SQL Server 2008; 3. MySQL 5.1 Community Edition. Allo stesso modo è possibile interagire con FileMaker da altre applicazioni e usarlo a sua volta come sorgente dati Engine Il DBMS non si basa sulla losoa della programmazione orientata agli oggetti anche se ne mutua molte caratteristiche, infatti viene denito un ambiente di sviluppo quasi-object dato che la base dello sviluppo è la manipolazione di entità chiamate oggetti, tuttavia il database non supporta molte delle caratteristiche avanzate previste dal paradigma della programmazione a oggetti. Questa peculiare gestione dei dati lo rende un prodotto unico e sotto molti punti di vista lo rende dicile da confrontare con i prodotti concorrenti dato che questi sono basati su paradigmi diversi.

16 8 Dominio Applicativo Figura 2.4: Interazione tra FileMaker e sorgenti dati esterne tramite ODBC All'inizio infatti, per chi è abituato a lavorare con database canonici come My- SQL, Oracle, SQLServer si troverà in dicoltà a cimentarsi nello sviluppo di applicazioni con FileMaker, in quanto il concetto di tabella è stato in parte rivisto, come per le modalità di accesso ai dati in esse contenuti. Mentre nei DBMS comuni i dati sono memorizzati in totale indipendenza dalla loro visualizzazione e le tabelle sono direttamente accessibili tramite query, in FileMaker l'accesso al database avviene esclusivamente tramite delle interfacce molto simili a quelle che nei database classici sono chiamate View. Tali interfacce, chiamate Layout si posizionano concettualmente un livello al di sopra della base dati relazionale, fungendo da ltro sulle operazioni che si possono compiere sui dati. Figura 2.5: Logic Layers di FileMaker

17 2.1 FileMaker Server & Client 9 Figura 2.6: Graco delle relazioni di FileMaker Creazione e denizione di un nuovo database Usando gli strumenti graci è molto semplice realizzare un nuovo database da zero e costruire un'applicazione che consenta l'interazione. Inizialmente, dal menù File Nuovo si aprirà una nestra di dialogo che dà la possibilità all'utente - amministratore di scegliere tra creare un database vuoto oppure avvalersi di diversi samples già pronti, con modelli e logiche che si adattano ai casi d'uso più comuni. Un'altra possibilità è quella di creare un modello a partire da una soluzione già esistente facendo uso di driver ODBC, come spiegato nella sezione Successivamente è possibile cominciare la denizione di un nuovo schema scegliendo, sempre dal menù, File Congura Database. Da una nestra suddivisa in schede si possono creare le tabelle, indicando per ognuna il nome e aggiungendo i campi che la compongono. Tutto ciò avviene esclusivamente per via graca, ed è possibile indicare il nome dei campi, il tipo e eventuali proprietà aggiuntive, ad esempio impostando un campo come chiave primaria, dare vincoli di unicità o di formato. Un canvas aiuta il programmatore visualizzando la totalità delle tabelle e le loro caratteristiche, come mostrato in gura 2.6. Una volta create le tabelle si procede alla creazione delle relazioni semplicemente scegliendo il tipo di relazione da creare e trascinando, tramite drag&drop, la chiave primaria di una tabella sopra al campo di un'altra tabella. In tal modo il secondo campo diventa la chiave esterna della nuova relazione. Una volta realizzata la base di dati, per potervi avere accesso è necessario creare i Layout di visualizzazione (o Formati nella versione italiana). Ogni Layout è costruito per via graca, prendendo come riferimento una tabella denita nello schema: all'inizio l'aspetto è molto simile a quello di un form, con delle coppie Nome_campo: Valore_campo per ogni campo che costituisce la tabella (un esempio nella gura 2.7). Successivamente è possibile personalizzare l'aspetto graco del Layout disponendo a piacere i componenti, aggiungere immagini e link per la navigazione tra diversi Layout, nonché personalizzare la palette di colori. Oppure è possibile impostare un tema predenito che fa tutto ciò automaticamente. Degli strumenti più avanzati permettono di personalizzare

18 10 Dominio Applicativo Figura 2.7: Aspetto di un semplice Layout la visualizzazione dei dati: essendo che ogni Layout è una View sul database, l'amministratore può impostare delle restrizioni, decidere quali Layouts sono visualizzabili da determinati utenti (o gruppi di utenti), ltrare i dati e abilitare o disabilitare le funzioni di modica. Una caratteristica importante che FileMaker ore è la possibilità di denire un numero nito di valori che un campo può assumere. Ad esempio, come mostrato in gura 2.7, il campo sex può assumere solo due valori: male o female. Poi la visualizzazione a RadioButton è stata settata tramite un apposito pannello. Questa funzionalità è molto utile nel caso di ComboBox, dove all'utente è chiesto di scegliere un valore tra alcuni proposti come avviene nel campo opertingsystem. Figura 2.8: Inserimento record con FileMaker Per nire l'overview su FileMaker, mostriamo un semplice esempio di inserimento dati tramite interfaccia: dal pannello principale (gura 2.8) basta scegliere il Layout che si vuole utilizzare selezionandolo dal menù a tendina Formato e successivamente cliccando sul pulsante Nuovo Record per abilitare l'inserimento dei dati nel form. Niente di più semplice. Sia lo schema, sia i dati, sia le informazioni sul layout e l'aspetto graco vengono salvati un un unico le dall'estensione.fp* (l'asterisco si riferisce alla versione con

19 2.2 L'interfaccia AdaM: analisi dell'utilizzo 11 cui il le viene creato) che ingloba tutta la logica dei Layouts. Può essere copiato, condiviso e subito utilizzato da altri utenti esattamente come l'amministratore l'ha programmato Critiche Dalla precedente descrizione si nota come tutte le operazioni siano assolutamente user-friendly, l'amministratore può settare qualsiasi impostazione direttamente dal programma, denire una base di dati senza scrivere nemmeno una riga di codice e programmare delle interfacce articolate con delle procedure semplici e intuitive. Purtroppo il lato negativo c'è. Non utilizza SQL. Non utilizza nessun specico linguaggio per eseguire richieste. Al massimo, supporta un linguaggio di scripting ad altissimo livello con cui è possibile programmare delle procedure da richiamare in concomitanza ad eventi particolari o su diretta esecuzione dell'amministratore. Le API per PHP fornite sono ad un livello molto alto. Non potendo eseguire delle query dinamiche, le funzioni forniscono solo un set basilare di operazioni che si possono compiere sui dati: inserimento record, cancellazione, update, selezione. Inoltre, non si ha una comunicazione diretta con la base di dati sottostante, ma si ha accesso solo ai Layouts. Il concetto di tabella non esiste al livello utente, tantomeno quello di relazione, è tutto nascosto dai Layouts. Di conseguenza, non esiste il concetto di join tra tabelle, aggregazione e manipolazione di dati provenienti da più tabelle. A causa di questo, se si volesse avere accesso a dati contenuti in diverse tabelle bisognerebbe creare dei layout appositi (sempre per via graca) che contengano anche i dati aggiuntivi. È chiaro che se un'applicazione richiede l'elaborazione di dati di diversa natura, fare comparazioni complesse o ricerche dinamiche, con FileMaker si avrebbero molte dicoltà. LA LENTEZZA! Eseguire un FindAllCommand da un Layout contenente appena 300 record impiega 2.5 secondi circa. Per un FindAllCommand su un layout contenente 3000 record da 56 campi ciascuno ci vogliono ben 21.5 secondi!! Per una grande applicazione è ovvio che tempistiche del genere sono totalmente inadeguate. In sostanza, FileMaker è adatto a quelle realtà che vogliono uno strumento facile e intuitivo da utilizzare, un prodotto che si appresti ad una gestione semplice dei dati senza particolari aspettative. E per questo funziona particolarmente bene. 2.2 L'interfaccia AdaM: analisi dell'utilizzo AdaM è propriamente un progetto realizzato con FileMaker che consta di un database e di Layouts personalizzati. La sua funzione è permettere agli archeologi di salvare e consultare dati quali i reperti rinvenuti durante lo scavo, la

20 12 Dominio Applicativo stratigraa, scrivere giornalmente un report sulle attività svolte su un diario, catalogare campionamenti eettuate nelle Unità stratigrache e aggregare delle Unità stratigrache dalle caratteristiche simili in contesti. In questa sezione analizzeremo i tratti fondamentali dell'interfaccia e come gli utenti usano il sistema. Di seguito sono illustrati tutti i Layouts navigabili dall'utente. (a) (b) (c) (d) (e) Figura 2.7: Layouts principali di AdaM su FileMaker (f) Schermata Iniziale (Figura 2.7a): Da qui gli utenti possono accedere direttamente alle schede di maggiore utilizzo e importanza. A partire da sinistra: Gestione US (Unità Stratigrache), Gestione Diario di Scavo, Gestione Materiali.

21 2.2 L'interfaccia AdaM: analisi dell'utilizzo 13 Gestione US (Figura 2.7b): Questo layout è diviso in tre schede per facilitare l'utente nella visualizzazione e l'inserimento dati. Da qui si possono vedere le informazioni riguardante una Unità Stratigraca, dalle generalità ai dettagli sici. È importante che ci siano così tanti elementi da memorizzare per ogni US, in quanto le datazioni e le deduzioni sui reperti partono proprio da questi dati. È possibile anche caricare foto o piante per una documentazione ancora più completa. Tale Layout fa largo uso delle Liste Valori per assicurarsi che l'utente dia una denizione chiara al valore del campo (ad esempio nei campi Soprintendenza e Località). Ogni US corrisponde ad un record nel database, ordinata per inserimento. Diario si Scavo (Figura 2.7c): Ogni giorno sono annotate le operazioni fatte durante la giornata: gli interventi, rimozione di straticazioni, rinvenimenti di reperti e qualsiasi altra cosa di rilevante. È possibile citare esplicitamente delle US e collegarle al loro Layout per un veloce consulto. Eventualmente, nel caso si abbia bisogno di linkare una nuova US che non è ancora stata creata, si può creare istantaneamente cliccando sul pulsante CREA NUOVA US e indicando il numero identicativo. Una bad practice degli utenti è creare in questo modo tutte le nuove US, relegando ad un secondo momento la loro completa denizione per poi dimenticarsene. Ogni pagina corrisponde ad un record, e i record sono ordinati per inserimento. Gestione Materiali (Figura 2.7d): Da qui si ha una panoramica sui reperti rinvenuti. Il layout non mostra un elenco dei reperti in generale, ma i reperti rinvenuti per ogni US. Infatti nella parte superiore si ha un breve riassunto dell'us di appartenenza e sotto tutti i reperti trovati in essa. Ci sono due categorie di reperti: Contabilizzati: Oggetti rinvenuti ma che non sono ancora catalogati, oppure non hanno una rilevanza tale da essere presi in considerazione singolarmente. Di un reperto di questo genere si vogliono conoscere solo le caratteristiche generali e non ha un proprio numero di inventario. Inventariati: Oggetti catalogati, con un proprio numero di inventario. È ritenuto rilevante ai ni della ricerca e per questo ha una propria scheda più dettagliata di un Contabilizzato. All'inizio, appena rinvenuti, tutti i reperti vengono contabilizzati. È in laboratorio che del personale esperto, analizzando ciò che è stato trovato, decide se un reperto ha rilevanza scientica oppure no. In tal caso sarà lui a denire i nuovi dettagli, oltre quelli già descritti nella sua scheda da contabilizzato. Gestione Campioni (Figura 2.7e):Come per il Layout Materiali, anche qui i record sono ordinati per US e la visualizzazione è simile: riassunto dell'us nella parte superiore e elenco dei campioni eettuati su tale Unità con le relative caratteristiche. La scheda Elenco mostra gli stessi dati ma organizzati in un elenco piuttosto che per esteso.

22 14 Dominio Applicativo Pannello amministratore (Figura 2.7f): Accessibile solo con un account di tipo amministratore. Questo Layout non mostra dati, ore solo dei collegamenti ad altri Layout a cui sono legati degli script per compiere determinate azioni. Tra queste, le più usate sono la gestione utenti e la denizione delle liste valori 2.3 La Base di Dati preesistente Schema L'interfaccia AdaM descritta nella sezione 2.2 consta di molti Layers che si appoggiano su un database. In questa sezione verrà presentato e descritto lo schema secondo il quale i dati sono organizzati. Possiamo vedere un graco completo nella gura 2.8. Dall'aspetto si presenta un tipico schema con entità, campi e relazioni. US: La tabella raccoglie le classiche informazioni normalmente contenute in una scheda di unità stratigraca di tipo ministeriale: sono presenti diversi campi corredati da liste valori a scelta obbligata o congurate in altre modalità di compilazione. La tabella US risulta essere il centro del diagramma entitàrelazioni di tutto il database: è relazionata praticamente alla quasi totalità delle altre tabelle presenti. Diario: raccoglie informazioni relative alle giornate di scavo e permette di richiamare al suo interno determinate unità stratigrache coinvolte durante la giornata di scavo selezionata: per il fatto che una giornata di scavo può richiamare più US, e una stessa US può essere citata da più pagine del Diario, la relazione tra le due entità è una relazione del tipo molti a molti. La tabella di collegamento tra i due principali insiemi di dati è denita come Citazioni nel Diario di US. Citazioni nel Diario di US: È la tabella di collegamento tra l'insieme dei dati relativo alle Unità Stratigrache e quello del Diario di Scavo: è relazionata reciprocamente ad entrambe le tabelle in modo uno a molti, permettendo di conseguenza una relazione molti a molti tra le due tabelle estreme. Contesti di US: Serve per raggruppare diverse US secondo criteri determinati dall'utente: in quanto un contesto di US può contenere più US e una stessa US può appartenere a più contesti la relazione tra le due entità è una relazione del tipo molti a molti. La tabella di collegamento tra i due principali insiemi di dati è quella precedentemente descritta e denita come Citazioni nei contesti di US. Citazioni di Contesti di US: è la tabella di collegamento tra l'insieme dei dati relativo alle Unità Stratigrache e quello dei Contesti di US.

23 2.3 La Base di Dati preesistente 15 Figura 2.8: Schema di AdaM

24 16 Dominio Applicativo Reperti Contabilizzati: Raccoglie i dati relativi alla totalità dei reperti presenti nel database: è prevalentemente una tabella di raccolta numerica con campi che eseguono operazioni su questo insieme di dati (conteggio e percentuali). Come la più estesa tabella Reperti inventariati possiede una serie di campi ai quali sono attribuite delle precise liste valori (confronto il capitolo dedicato). È presente, inoltre, una serie di campi che gestiscono in modo automatico la dimensione graca del diagramma a barra in modo corrispondente al valore della percentuale. La tabella Reperti contabilizzati è relazionata in modo uno a molti alla tabella principale del database, cioè la tabella US. Reperti Contabilizzati 2 e 3: Sono delle tabelle necessarie alla gestione delle liste valori della sezione materiali e che permettono di operare i ltri sui parametri inseriti dall'utente. In particolare la tabella Reperti contabilizzati 2 è necessaria per ltrare il campo Classe rispetto al campo Materiale, mentre la tabella Reperti contabilizzati 3 ltra il campo Forma rispetto al campo Classe mediante delle relazioni ricorsive. Reperti Inventariati: Raccoglie informazioni relative a tutte le caratteristiche che servono per una descrizione esaustiva di un reperto inventariato: sono raccolte prevalentemente informazioni in formato testo, ma sono collegate anche due tabelle esterne, che raccolgono documentazione fotograca e gra- ca (disegni) del manufatto mediante inserimento di le raster o di altro formato. La tabella è al centro di una serie di relazione con molte altre tabelle del database: in particolare da essa partono relazioni uno a molti verso le tabelle Documentazione fotograca, Documentazione disegno, Reperti inventariati 2 e Reperti inventariati 3 e una relazione molti a uno verso la tabella US. Reperti inventariati 2 e 3: Come le tabelle Reperti Contabilizzati 2 e 3, solo che in questo caso si applica alla tabella Reperti Inventariati. Pubblicazioni: Raccoglie informazioni relative ai contributi che vengono citati come riferimenti bibliograci per un determinato reperto inventariato. La tabella si congura come un archivio indipendente legato al sistema delle tabelle di ADaM mediante la tabella di collegamento Bibliograa. Bibliograa: La relazione di uno a molti permette di collegare ad un reperto inventariato innite Pubblicazioni inserite precedentemente nell'archivio ed aggiungendo l'informazione sull'intervallo delle pagine speciche (o pagine di interesse) relative al reperto selezionato. Tutti i campi presenti, tranne il campo delle pagine speciche di interesse, sono campi calcolati che traggono il valore secondo le regole determinate dalla relazione con la tabella Pubblicazioni. Campioni: Raccoglie informazioni relative ai prelievi di campioni di materiale dalle US.

25 2.3 La Base di Dati preesistente 17 Piante US e Fotograe US: Contengono i dati relativi al materiale fotograco che si vuole abbinare ad una determinata unità stratigraca (una tabella per le piante e un'altra per le fotograe): oltre ad un campo contenitore (che ingloba al suo interno l'immagine raster), sono presenti alcuni campi necessari al controllo dimensionale dell'immagine da inserire. Documentazione Disegno e Fotograca: Contengono i dati relativi al materiale graco (piante e disegni) che si vuole abbinare ad uno specico reperto inventariato: oltre ad un campo contenitore (tipo di campo capace di memorizzare un le multimediale) sono presenti alcuni campi necessari al controllo dimensionale dell'immagine da inserire. Le tabelle sono relazionate in modalità uno a molti alla tabella Reperti inventariati Critiche Lo schema appena descritto presenta diverse problematiche e punti critici. 1. Il problema più evidente è quello riguardante le relazioni tra US, Reperti Contabilizzati e Reperti Inventariati. Concettualmente, Reperti Contabilizzati contiene la totalità dei reperti, legati alla tabella US in una relazione molti ad uno: un reperto è rinvenuto in una sola US, mentre in una US si possono ritrovare più reperti. Ma la denizione di una relazione tra Reperti Inventariati e US non è corretta. Logicamente, Reperti Inventariati è una derivazione di Reperti Contabilizzati, visto che ne eredita i campi. Invece nella situazione attuale non c'è nulla che leghi le due entità. Addirittura c'è una forte ridondanza, in quanto ogni Inventariato ripete gli stessi dati del Contabilizzato dal quale proviene. Oltre al problema di ridondanza è problematico ricostruire il legame che c'è tra un Contabilizzato e un Inventariato, senza dimenticare che i campi che compongono la chiave primaria di Inventariati sono ridondanti, data la presenza di un IDreperti_inv. 2. Duplicazione di tabelle quando ne sarebbe bastata una. Questo problema si presenta con Piante US e Fotograe US: i loro campi sono identici, sarebbe bastato accorpare le due tabelle in una sola e prevedere un campo discriminatore. Lo stesso vale per le tabelle Documentazione disegno e Documentazione fotograca. 3. Rappresentazione non canonica delle relazioni ricorsive. Le tabelle Reperti inventariati 2 e 3, insieme a Reperti Contabilizzati 2 e 3, dovrebbero simulare un vincolo di ricorsione sui Materiali e Classi, per denire dei sotto-materiali e delle sotto-classi. Purtroppo FileMaker non supporta le relazioni ricorsive, e automaticamente le sostituisce creando nuove tabelle per simularle con una relazione molti a molti. 4. In alcune tabelle sono presenti dei campi non-chiave ma che hanno un vincolo di unicità. Ad esempio, nella tabella US, la chiave primaria è IdUS che è un intero progressivo, mentre il campo US è una stringa, inserita dall'utente alla creazione del record, che identica una US. Avrebbe più senso

26 18 Dominio Applicativo tenere il campo US come chiave primaria, e a questo punto IdUS diventerebbe ridondante. La stessa cosa vale per la tabella Campioni, con la chiave primaria IDcampione e il campo N campione. 5. Nello schema sono presenti dei campi che hanno a che fare con la presentazione dei dati nell'interfaccia graca, come ad esempio la lunghezza della barra su Contabilizzati, oppure le dimensioni di un'immagine. 2.4 Proposta di un nuovo schema In seguito alle anomalie riscontrate nello schema, e in vista di un'applicazione che dovrà lavorare con la base dati AdaM, è stato proposto uno schema alternativo che risolve le criticità, elimina la ridondanza e rispetta i vincoli logici sui dati. Lo schema ER è mostrato nella gura 2.9, mentre in gura 2.10 possiamo vedere lo stesso schema tradotto in relazionale. Figura 2.9: Schema ER rielaborato Le dierenze con il modello precedente sono sostanzialmente le seguenti: 1. Le tabelle Piante US e Fotograe US sono state intese come classi glie di una super-entità Immagini, accorpate poi secondo il modello a Tabella Unica con un campo discriminatore per distinguere le fotograe dalle piante. In questo modo si riduce la complessità e si ha una logica più stretta per attribuire delle immagini ad una US, ed un più facile accesso alla totalità delle immagini essendo memorizzate in una unica tabella.

27 2.4 Proposta di un nuovo schema 19 Figura 2.10: Schema relazionale rielaborato

28 20 Dominio Applicativo 2. La stessa cosa è stata fatta per le tabella Documentazione Disegno e Documentazione Fotograca. Essendo i loro campi uguali, si è pensato di rappresentarle come classi glie della super-entità Documentazione con un campo discriminatore per distinguere la documentazione fotograca da quella disegnata. 3. È stato risolto il problema che aiggeva la tabella reperti Inventariati: la gerarchia Reperti Contabilizzati = Reperti Inventariati è stata tradotta con un partizionamento verticale (REPERTI e REPERTI_INVENTARIATI), instaurando così un vincolo più forte che con una partizione orizzontale come prima avveniva. È stato dato ad un reperto contabilizzato un identicatore da permettere così ad un inventariato di risalire al proprio contabilizzato con più velocità, indicizzando tale campo. Si evita moltissima ridondanza in quanto un inventariato conterrà solo ed esclusivamente dati che non compaiono sul contabilizzato. 4. Le tabelle Contabilizzati 2,3 e Inventariati 2, 3 sono state rinominate con un titolo più signicativo, in quanto contenevano la lista dei possibili valori di materiali e classi di un reperto. È stata mantenuta la rappresentazione data da FileMaker per non stravolgere la logica di gestione della ricorsione. 5. Sono stati rimossi dallo schema i campi ridondanti con vincolo di unicità, ora le chiavi primarie rappresentano esattamente il numero identicativo deciso dall'utente. Sono stati rimossi anche i campi per la presentazione dei dati nell'interfaccia. 6. Sono state introdotte tre tabelle che aggiungono interessanti funzionalità: Modiche: Tabella che tiene traccia di ogni operazione eettuata sul database. La chiave primaria è un numero intero progressivo, e l'id dell'ultima modica eseguita (quindi il maggiore id nella tabella) viene inteso come il numero di revisione del database. Questa tabella è fondamentale per la funzionalità di sincronizzazione, permette di ricostruire la sequenza delle operazioni da eseguire per portare il database in stato consistente da una revisione ad una revisione successiva. La granularità è molto ne, ogni modica corrisponde ad un incremento di revisione. È vero che mantenendo una tabella delle modiche di questo genere farà aumentare di molto la dimensione del database, ma dato che serve solo per le elaborazioni interne non verrà mai spedita al client. In più avere questo tipo di informazioni ci permette di implementare un meccanismo di UnDo nel caso si volesse porre rimedio a degli errori umani. Utenti: Serve a risolvere una mancanza di FileMaker, ossia la verica dell'autenticazione degli utenti. Per capire se un utente ha diritti di accesso usando le API PHP, il server è costretto ad eseguire una operazione di lettura dal database e osservare se fallisce o meno. Se fallisce signica che l'utente non ha i diritti di accesso, altrimenti gli viene

29 2.4 Proposta di un nuovo schema 21 consentito l'accesso... veramente un grossolano workaround. Introdurre una tabella nella quale sono elencati tutti gli utenti, ognuno con un suo personale codice segreto, risolve sia il problema del controllo dell'accesso sia al problema di sicurezza legato alla trasmissione dei dati tra client e server: in questo modo ogni utente ha una propria chiave privata per criptare le proprie informazioni di login da memorizzare sul client, al posto di usare una unica chiave per tutti gli utenti. Il tutor interno ha apprezzato il modo in cui sono stati risolti i problemi, tuttavia si è preferito non attuare subito le modiche riservandole per un prossimo futuro. Solamente la tabella delle modiche è stata introdotta in quanto era indispensabile per il funzionamento del sistema. L'applicazione quindi si dovrà appoggiare sul database preesistente, e nella progettazione si dovrà tener conto che questo andrà incontro a importanti cambiamenti. Pertanto si dovrà rendere l'applicazione in grado di adattarsi alle modiche del database, garantendo un certo grado di separazione tra front-end, back-end e livello di persistenza dei dati.

30 22 Dominio Applicativo

31 Capitolo 3 Analisi dei Requisiti Il presente capitolo espone l'analisi dei Requisiti di Cad Editor. Dapprima verrà fatta una descrizione generale presentando i casi d'uso dell'applicativo. Poi saranno esplicitati tutti i requisiti, specicandone la tipologia e descrivendoli brevemente. 3.1 Descrizione funzionale Il progetto intende realizzare un'applicazione web, quindi deve essere utilizzabile tramite un web browser interamente senza il fabbisogno di plugin o software aggiuntivo. Essendo raggiungibile attraverso Internet, il sistema deve impedire l'accesso agli utenti non autorizzati richiedendo una login e una password decisa dall'amministratore tramite il pannello di FileMaker. Una volta ottenuto l'accesso, l'utente deve poter compiere le operazioni di lettura, inserimento, modica e cancellazione record sulle entità disponibili dall'interfaccia AdaM. Questa fase deve essere indipendente dalla presenza o meno della connettività, e anche se dovesse mancare del tutto l'utente deve riuscire comunque ad eseguire il login per accedere al sistema. Nel caso mancasse la connessione ad Internet devono essere disabilitate tutte le funzioni che sono svolte online. 3.2 Caratteristiche degli utenti L'applicazione è rivolta ad utenti con conoscenze nell'ambito archeologico, abituate ad utilizzare l'interfaccia AdaM per lo svolgimento delle loro normali attività. Si presuppone che l'utente non abbia particolari conoscenze nel campo informatico, pertanto l'applicazione sarà il più user-friendly possibile. L'applicazione prevede una sola tipologia di prolo utente, ovvero l'utente utilizzatore. Le funzioni avanzate per le quali è richiesto un amministratore non sono contemplate dall'applicazione, pensata solo per fornire un subset delle caratteristiche di base.

32 24 Analisi dei Requisiti 3.3 Convenzioni per l'analisi dei requisiti Sigle e nomi per i requisiti Per indicare il nome dei requisiti verranno utilizzate una serie di sigle che li descrivono. In particolare ogni requisito dovrà attenersi al seguente formato Tipologia sarà una lettera tra: F: Requisito funzionale; P: Requisito prestazionale; Q: Requisito di qualità; V: Requisito di vincolo. La priorità sarà una sigla tra: OB: Requisito obbligatorio; DE: Requisito desiderabile; OP: Requisito opzionale. TipologiaPriorità_n1.n2.....nk Il nome di un requisito deve essere univoco, per questo è previsto un sistema di numerazione gerarchica rappresentata con k numeri separati da un punto, tanti quanti i livelli dell'albero con radice in un macro-requisito padre. La struttura rappresentata dai requisiti è una foresta di insiemi e ad ogni requisito-padre è attribuito un numero progressivo univoco. I gli avranno come primo numero il codice del padre e in aggiunta un numero progressivo anch'esso univoco per i gli dello stesso livello. Ad esempio un requisito con nome FOB_3.2.1 indica un requisito funzionale obbligatorio con padre il requisito FOB_3.2 che a sua volta è glio del requisito FOB_ Sigle e nomi per gli Use Case Ogni caso d'uso avrà una numerazione univoca e gerarchica secondo il seguente pattern: UC_n1.n2.....nk Come per i requisiti, anche i casi d'uso sono organizzati gerarchicamente e la numerazione conseguentemente ne rispecchia la logica. Ad esempio un caso d'uso con nome UC_ indica che è una specializzazione del caso d'uso UC_6.4, che a sua volta è glio del caso d'uso UC_6. I diagrammi corrispondenti devono avere lo stesso nome del caso d'uso che rappresentano.

33 3.4 Use Cases Use Cases Login System Figura 3.1: UC_1: AdaM WebApp Login System Attori: Utente utilizzatore del sistema. Scopo e Descrizione: L'accesso all'applicazione è consentito solo agli utenti autorizzati dall'amministratore di AdaM attraverso il software FileMaker. Il login si svolge quindi in due passi: prima l'utente deve autenticare le sue credenziali nel server, una volta ricevuta una riposta positiva il sistema registra il nuovo utente e abilita il login con l'username e la password usate per l'autenticazione. Pre-Condizione: Il sistema è stato avviato e si trova nella schermata di login. Post-Condizione: Il sistema ha ricevuto un username e una password valide e l'utente risulta loggato e autenticato. Scenario Principale: 1. L'utente inserisce un username e una password nel form; 2. L'utente decide di eettuare il login (UC_1.1 ); 3. Se la login va a buon ne il sistema permette all'utente di accedere all'applicazione; 4. Se l'utente che tenta di fare il login non è prima stato autenticato dal server, gli verrà chiesto di eseguire un'autenticazione con credenziali valide (UC_1.3 ). Scenario Secondario: 1. L'utente inserisce un username e una password nel form; 2. L'utente decide di eettuare l'autenticazione (UC_1.2 ); 3. Se l'autenticazione va a buon ne, il sistema registra il nuovo utente abilitandone il login; 4. Se il server riuta le credenziali viene visualizzato un messaggio di errore (UC_1.4 ).

34 26 Analisi dei Requisiti Main Application Figura 3.2: UC_2: AdaM WebApp Main Application Attori: Utente utilizzatore del sistema. Scopo e Descrizione: È la schermata principale dell'applicazione, dove verranno proposte all'utente diverse sezioni corrispondenti alle entità da gestire, come nei vari Layouts dell'interfaccia AdaM. Pre-Condizione: L'utente ha eseguito correttamente il login e il sistema si trova nella schermata principale ed è pronto a soddisfare le richieste. Post-Condizione: Il sistema ha soddisfatto la richiesta dell'utente. Scenario Principale: UC_2.1: L'utente ha la possibilità di operare con i dati del Layout US, visualizzarli e modicarli. Deve essere stato eseguito un checkout del database. UC_2.2: L'utente ha la possibilità di operare con i dati del Layout Diario di Scavo, visualizzarli e modicarli. Deve essere stato eseguito un checkout del database. UC_2.3: L'utente ha la possibilità di operare con i dati del Layout Reperti Contabilizzati, visualizzarli e modicarli. Deve essere stato eseguito un checkout del database. UC_2.4: L'utente ha la possibilità di operare con i dati del Layout Reperti Inventariati, visualizzarli e modicarli. Deve essere stato eseguito un checkout del database.

35 3.4 Use Cases 27 UC_2.5: L'utente ha la possibilità di operare con i dati del Layout Campioni, visualizzarli e modicarli. Deve essere stato eseguito un checkout del database. UC_2.6: L'utente ha la possibilità di operare con i dati del Layout Contesti, visualizzarli e modicarli. Deve essere stato eseguito un checkout del database. UC_2.7: L'utente decide di avviare l'operazione di checkout, ossia di copiare i dati residenti nel database remoto nel database locale, abilitando di conseguenza le sezioni di gestione e modica dei record. Questa funzionalità richiede una connessione Internet attiva. UC_2.8: L'utente decide di eseguire un update del sistema, ossia di sincronizzare la propria versione del database locale con le nuove modiche eettuate sul database remoto. Nessun dato viene inviato, nel caso ci siano conitti l'utente deve poter scegliere quale azione intraprendere. Questa funzionalità richiede una connessione Internet attiva. UC_2.9: L'utente decide di eseguire un commit delle modiche eettuate in locale. Per eseguire questa operazione la versione locale deve essere aggiornata all'ultima revisione del database remoto, e tutti gli eventuali conitti devono essere stati risolti. Questa funzionalità richiede una connessione Internet attiva Gestione Unità Stratigrache Figura 3.3: UC_2.1: Gestione delle schede Unità Stratigrache Attori: Utente utilizzatore del sistema.

36 28 Analisi dei Requisiti Scopo e Descrizione: L'applicazione consente all'utente di agire sulle entità Unità Stratigrache, orendogli la possibilità di vederne l'elenco, i dettagli e compiere le operazioni di aggiunta, modica e rimozione dei record presenti. Pre-Condizione: L'utente ha eseguito correttamente il login e il sistema si trova nella schermata di gestione US ed è pronto a soddisfare le richieste. Post-Condizione: Il sistema ha soddisfatto la richiesta dell'utente. Creazione nuova US Figura 3.4: UC_2.1.2: Inserimento Nuova US Attori: Utente utilizzatore del sistema. Scopo e Descrizione: Il presente use case descrive le azioni che l'utente può compiere all'inserimento di una US. Pre-Condizione: L'utente ha eseguito correttamente il login e ha scelto l'azione di creare una nuova US. Il sistema si trova nella schermata di inserimento dati. Post-Condizione: È stata creata e salvata una nuova US. Scenario Principale: All'utente viene presentato un form vuoto nel quale può inserire i dati richiesti. Eventualmente per alcuni campi gli sarà chiesto di scegliere tra dei valori pressati. Al termine dell'inserimento i dati verranno convalidati e salvati solo se non violano i vincoli di integrità imposti dalla business logic dell'applicazione. Altrimenti l'operazione è interrotta e l'utente è invitato, tramite un messaggio di errore, a risolvere gli errori.

37 3.4 Use Cases 29 Modica US Attori: Utente utilizzatore del sistema. Scopo e Descrizione: Il presente use case descrive le operazioni di modica di una US. Pre-Condizione: L'utente ha eseguito correttamente il login e ha scelto l'azione di modicare una US. Il sistema si trova nella schermata di modica dati. Post-Condizione: Le modiche sono state salvate. Scenario Principale: All'utente viene presentato un form compilato con i campi attuali dell'us scelta. A questo punto l'utente è libero di modicare i campi come meglio crede. Al termine dell'inserimento i dati verranno convalidati e salvati solo se non violano i vincoli di integrità imposti dalla business logic dell'applicazione. Altrimenti l'operazione è interrotta e l'utente è invitato, tramite un messaggio di errore, a risolvere gli errori. Può alternativamente annullare l'operazione, in tal modo nessuna modica avrà eetto. Rimozione US Attori: Utente utilizzatore del sistema. Scopo e Descrizione: Il presente use case descrive l'operazione di rimozione di una US. Pre-Condizione: L'utente ha eseguito correttamente il login e ha scelto l'azione di cancellare una US. Il sistema si trova nella schermata di visualizzazione elenco US. Una o più US sono selezionate. Post-Condizione: La/e US sono state rimosse. Scenario Principale: L'utente sceglie dall'elenco le US che desidera rimuovere. Dopo la conferma dell'operazione il sistema rimuove i record selezionati dal database locale ed eventuali altri record correlati, secondo la buiness logic dell'applicazione Checkout Attori: Utente utilizzatore del sistema. Scopo e Descrizione: Il sistema ore la possibilità di inizializzare il database locale importando i dati dal database remoto per poterli visualizzare oine e modicarli. Pre-Condizione: L'utente ha eseguito correttamente il login e la connessione ad Internet è attiva.

38 30 Analisi dei Requisiti Post-Condizione: Il database è inizializzato e contiene la copia più recente del database remoto. Scenario Principale: L'utente sceglie dalla schermata principale di eettuare un checkout. Il database locale viene resettato e una richiesta di sincronizzazione viene inviata al server, che risponde inviando una copia dei dati in esso contenuti. Ricevuti i dati, il sistema li salva e nel frattempo mostra una barra di avanzamento del processo Update Attori: Utente utilizzatore del sistema. Scopo e Descrizione: Il sistema ore la possibilità sincronizzare la propria copia locale del database con le ultime modiche apportate al database remoto. In questo caso nessuna modica locale è inviata al server, vengono solo prelevati i nuovi dati e in caso di conitto verrà chiesto all'utente che operazione eettuare. Pre-Condizione: L'utente ha eseguito correttamente il login e la connessione ad Internet è attiva. Post-Condizione: Il database è inizializzato e contiene la copia più recente del database remoto. Scenario Principale: L'utente sceglie dalla schermata principale di eettuare un update. Una richiesta viene inviata al server, specicando il numero della revisione del database locale. Il server risponde inviando una copia dei dati modicati dal numero della revisione specicata in poi. Ricevuti i dati, il sistema applica le modiche necessarie aggiornando, creando o cancellando record. Nel caso una delle nuove modiche sovrascriva una modica fatta dall'utente utilizzatore, gli viene chiesto se mantenere la propria versione o accettare quelle in arrivo del server. Alla ne dell'operazione viene aggiornato il numero di revisione interno al database locale Commit Attori: Utente utilizzatore del sistema. Scopo e Descrizione: Il sistema deve permettere all'utente di inviare le modi- che del proprio database locale al server. Pre-Condizione: L'utente ha eseguito correttamente il login e la connessione ad Internet è attiva. La il database locale è aggiornato all'ultima revisione in linea con il database remoto. Post-Condizione: Le modiche eseguite dall'utente sono state inviate al server.

39 3.5 Requisiti 31 Scenario Principale: L'utente sceglie dalla schermata principale di eettuare un commit delle modiche. Al server vengono mandate le modiche effettuate, che risponderà con una conferma dell'avvenuta operazione e un nuovo numero di revisione. Se nel frattempo è in corso un commit da parte di un altro utente, l'operazione deve essere annullata e l'utente avvisato da un messaggio. 3.5 Requisiti Requisiti Funzionali Sigla FOB_1 FOB_1.1 FOB_2 FOB_2.1 FOB_2.2 FOB_2.3 FOB_3 FOB_3.1 FOB_3.2 FOB_4 FOB_4.1 FOB_4.1.1 FOB_4.1.2 FOB_4.2 FOB_5 FOB_5.1 Descrizione Il sistema deve permettere lo storing dei dati del database AdaM nel client Le funzionalità che non richiedono una comunicazione con il server devono poter essere disponibili oine Per accedere all'applicazione il sistema richiede l'autenticazione dell'utente L'utente per poter eseguire il login la prima volta deve richiedere un'autenticazione al server fornendo la stessa username e password usati per accedere all'interfaccia AdaM L'utente che ha ricevuto l'autenticazione dal server la prima volta, può accedere all'applicazione eseguendo il login con la sua username e password Se l'utente ha eseguito l'autenticazione deve poter eseguire il login senza essere connesso ad Internet Il sistema deve poter eseguire il checkout del database Il sistema deve poter tenere traccia del numero di versione del database Il sistema deve poter chiedere conferma all'utente per eseguire l'operazione di checkout Il sistema deve permettere l'operazione di sincronizzazione con il database remoto tramite update delle modiche Il sistema deve poter riconoscere situazioni di conitto con le nuove modiche nel database remoto e le modiche eettuate dall'utente nel database locale Il sistema deve mostrare all'utente le voci in cui si riscontra un conitto Il sistema deve dare la possibilità all'utente di scegliere l'azione da compiere nel caso in cui si rilevi un conitto Nel caso in cui l'update fallisse, nessuna modica deve essere fatta e il sistema deve avvisare l'utente Il sistema deve permettere l'operazione di sincronizzazione con il database remoto tramite commit delle modiche Nel caso in cui il commit fallisse, il sistema deve avvisare l'utente dell'errore e annullare l'operazione

40 32 Analisi dei Requisiti Sigla Descrizione FOB_6 1 L'utente deve poter gestire le entità Unità stratigrache FOB_6.1 Il sistema deve permettere di visualizzare l'elenco delle US presenti FOB_6.2 Il sistema deve permettere di visualizzare i dettagli di una US FOB_6.3 L'utente deve poter inserire una nuova US FOB_6.3.1 Il sistema deve eseguire controlli di integrità nell'inserimento e avvisare l'utente nel caso fossero violati, ed annullare l'operazione FOB_6.3.2 Il sistema deve proporre all'utente i valori di default delle Liste Valori per i campi per cui sono denite. FOB_6.4 L'utente deve poter modicare i dettagli di una US esistente FOB_6.5 L'utente deve poter eliminare una US esistente FOB_6.5.1 Il sistema deve poter eliminare automaticamente entità correlate alle US al ne di mantenerne la consistenza. FDE_7 L'utente deve poter eseguire una ricerca per id delle entità FDE_8 L'elenco delle entità deve essere presentato per pagine, ossia un certo numero di elementi alla volta FDE_8.1 L'utente deve poter navigare avanti e indietro nelle pagine FDE_8.2 L'utente deve poter andare direttamente alla prima o all'ultima pagina dell'elenco FDE_8.3 L'utente deve poter scegliere il numero di elementi visualizzati per pagina FDE_8.4 L'utente deve poter decidere a di andare direttamente ad un numero di pagina FOP_9 Il sistema deve permettere all'utente di ordinare un elenco di entità secondo gli elementi visualizzati (ordine alfabetico o di numero) FOP_9.1 Il sistema deve permettere un ordinamento ascendente o discendente FOP_10 Il sistema deve fornire strumenti per ripristinare il database a precedenti revisioni FOP_11 Il sistema deve fornire un layout di stampa apposito per ogni tipologia di entità per una visualizzazione ottimale Tabella 3.1: Lista dei Requisiti Funzionali Requisiti di Vincolo Sigla VOB_1 VOB_2 VOB_3 Descrizione Il server deve essere realizzato in linguaggio PHP Il server deve interfacciarsi al database usando le API uciali fornite da FileMaker Inc. Il client deve essere realizzando seguendo la proposta di standard HTML5 e Javascript 1 Oltre alle US, gli stessi requisiti vanno ripetuti per le entità Diario, Campioni, Contesti, Reperti Contabilizzati e Reperti Inventariati

41 3.5 Requisiti 33 Sigla Descrizione VOB_4 Il client deve poter funzionare correttamente nei browser Chrome 22 e Safari 5.1 e superiori VDE_4.1 Il client deve poter funzionare correttamente nei browser Firefox 15 e superiori VOB_5 Il sistema, per funzionare, non deve richiedere l'installazione di alcun software aggiuntivo Tabella 3.2: Lista dei Requisiti di Vincolo Requisiti Prestazionali Sigla POB_1 POB_2 PDE_2.1 POB_3 Descrizione Il sistema deve permettere lo storing di dati nel client no a 10MB Lo scambio di dati tra l'applicazione e il server deve essere ridotta allo stretto indispensabile I dati trasmessi tra server e client devono essere compressi per diminuire l'utilizzo di banda Eventuali immagini utilizzate per il layout devono essere in formato GIF o JPEG. Tabella 3.3: Lista dei Requisiti Prestazionali Requisiti di Qualità Sigla QOB_1 QOB_1.1 QOB_2 Descrizione Il sistema deve impedire agli utenti senza credenziali l'accesso all'applicazione Eventuali utenti malintenzionati, o comunque sprovvisti di valide credenziali di accesso, non devono riuscire ad accedere al server tramite l'applicazione Database, client e server devono mantenere un buon livello di separazione in vista di sostanziali modiche alla logica del database Tabella 3.4: Lista dei Requisiti di Qualità

42 34 Analisi dei Requisiti

43 Capitolo 4 Tecnologie Utilizzate 4.1 PHP Acronimo ricorsivo di PHP: Hypertext Preprocessor, è un linguaggio di programmazione interpretato, con licenza open source, originariamente concepito per la programmazione di pagine web dinamiche. Attualmente è utilizzato principalmente per sviluppare applicazioni web lato server ma può essere usato anche per usi diversi, ad esempio per scrivere script a riga di comando o addirittura applicazioni stand-alone. PHP riprende per molti versi la sintassi del C, come peraltro fanno molti linguaggi moderni, e del Perl. È un linguaggio a tipizzazione debole e dalla versione 5 migliora il supporto al paradigma di programmazione ad oggetti. Certi costrutti derivati dal C, come gli operatori fra bit e la gestione di stringhe come array, permettono in alcuni casi di agire a basso livello; tuttavia è fondamentalmente un linguaggio di alto livello, caratteristica raorzata dall'esistenza delle sue moltissime API, oltre funzioni del nucleo base. Inoltre è in grado di interfacciarsi a innumerevoli database tra cui MySQL, PostgreSQL, Oracle. Figura 4.1: PHP logo Nonostante stiano emergendo moltissime nuove tecnologie lato server adatte per sviluppo di web applications, PHP merita ancora una volta un posto d'onore tra i linguaggi di programmazione ero del suo 78.6% di utilizzo come linguaggio server-side, seguito da ASP.NET (20.5%), Java, ColdFusion e altri (dati aggiornati a Novembre ). 1

44 36 Tecnologie Utilizzate 4.2 HTML5 Figura 4.2: HTML5 Logo HTML5 è un linguaggio di markup per la strutturazione delle pagine web. Lo standard è ancora in fase di sviluppo, ed introduce nuovissime funzionalità, come la gestione dei multimedia e della georeferenziazione, mantenendo un markup semplice e facilmente leggibile. Altri importanti cambiamenti sono l'introduzione di elementi sintattici a livello di markup, permettendo di dare una denizione semantica ai blocchi che compongono una pagina, e permettere un design del contenuto più articolato ed espressivo. Sono state introdotte nuove API per Javascript, le più importanti sono: Manipolazione elementi graci in un'apposita area chiamata canvas, con l'integrazione delle immagini SVG. Gestione di ussi audio - video, con tutte le funzionalità annesse alla riproduzione senza il bisogno di un plugin o software apposito. Rilevamento delle informazioni di geolocalizzazione dell'utente sotto forma di coordinate X e Y, dopo che ha dato l'autorizzazione all'utilizzo. Validazione dati di form ed estensione dei tipi. Caratteristica utile per l'inserimento e modica dati, permette di denire dei vincoli sul tipo di dato inserito in un elemento <input> e impedire la sottomissione di dati che non rispecchiano il formato prestabilito. Rende possibile la navigazione anche oine, grazie al caching delle pagine in locale. Metodi per lo storage di dati presso il browser. 4.3 Javascript & jquery JavaScript è un linguaggio di scripting orientato agli oggetti, tipicamente usato per arricchire le funzionalità delle pagine web lato client, ma spesso viene sfruttato anche lato server ad esempio con il framework node.js. È un linguaggio interpretato, debolmente tipizzato e consente l'utilizzo del paradigma object oriented, tuttavia in JavaScript manca il concetto di classe, quindi

45 4.4 Backbone.js 37 anche concetti come information hiding, ereditarietà, polimorsmo. In ogni caso si possono simulare queste caratteristiche andando ad intervenire sul meccanismo di prototipazione, cioè l'utilizzo di oggetti come prototipi per la costruzione di altri oggetti. Altra caratteristica di Javascript è la programmazione funzionale, ossia l'utilizzo delle funzioni come comuni oggetti: possono essere ad esempio salvate nelle variabili e passati come parametri, denire funzioni innestate e anonime. Questa unione dei vari paradigmi di programmazione rende JavaScript molto duttile e permette agli sviluppatori di adottare lo stile di programmazione più adatto alle problematiche arontate ed alle proprie preferenze. Negli ultimi anni JavaScript ha acquisito un'importanza strategica per lo sviluppo delle applicazioni web e questo nonostante tutte le controversie legati alle varie, spesso inconsistenti, implementazioni di questo linguaggio dai vari browser. Nel progetto è stato utilizzato come linguaggio per il client, vincolato dal fatto che lo scopo dello stage è la realizzazione di una web application fruibile attraverso un browser. Figura 4.3: jquery logo Jquery è una libreria open source scritta in puro Javascript che contiene una serie di utility che aancano il programmatore facilitando lo sviluppo di applicazioni. Spesso fare alcune cose con Javascript può essere molto complicato sia a causa della natura particolare o a causa dell'incompatibilità dei browser per alcuni comandi, che il programmatore dovrebbe risolvere manualmente eseguendo quello che viene denito browser detection. Anche la gestione degli eventi è completamente standardizzata e automatica; stessa cosa per quanto riguarda l'utilizzo di AJAX, in quanto sono presenti alcune funzioni molto utili e veloci che si occupano di istanziare i giusti oggetti ed eettuare la connessione e l'invio dei dati. Altre caratteristiche per la quale viene usata è per i selettori, che permettono di selezionare elementi della pagina con pochi, semplici comandi e per la manipolazione dei CSS per creare eetti graci notevoli con pochissime linee di codice. L'utilizzo di jquery è incoraggiato dalla dolce curva di apprendimento iniziale, essendo una libreria pensata per essere facile ed intuitiva da usare, e dalla vastissima community che ha prodotto moltissimi plugins ed estensioni per praticamente ogni cosa, velocizzando lo sviluppo di applicazioni con soluzioni già fatte e pronte per essere usate. 4.4 Backbone.js Backbone.js è un framework per Javascript, dipendente dalla libreria jquery, incredibilmente leggero per aggiungere una solida struttura al codice client-side. Rende facile manipolare e disaccoppiare le entità logiche all'interno dell'applicazione, permettendo di produrre codice più facilmente mantenibile a lungo termine. È spesso usato per realizzare applicazioni single-page, come il progetto AdaM WebApp. In poche parole, abilita il browser a rispondere alle azioni dell'utente e caricare parti di markup solo quando necessario. Questo signica che non sono

46 38 Tecnologie Utilizzate Figura 4.4: Backbone Logo necessari refresh di pagina. Di seguito sono citati altri framework simili presi in considerazione durante la fase di studio delle tecnologie: Ember.js: Framework più recente e forse più strutturato di Backbone, ma ha una curva di apprendimento più alta e obbliga lo sviluppatore ad adottare una logica più stretta alla losoa del framework. Obbliga ad utilizzare un template engine interno logic-less e ha prestazioni inferiori di Backbone. Angular.js: Framework recente, con documentazione ancora non del tutto esaustiva. Mescola logica di controllo all'interno dell'html, permettendo di costruire tag personalizzati sulle esigenze dell'applicazione. Questa tecnologia promette bene, ma ha una curva di apprendimento più alta. Ext JS 4: Framework professionale per la costruzioni di grandi applicazioni. Supporta pienamente il design pattern MVC e fornisce tools per la creazione di widget graci HTML5. È fornita in due versioni, una commerciale e una GPLv3 per applicazioni open source. 4.5 Underscore.js Libreria standalone che incorpora metodi di utilità su array, oggetti, funzioni, eventi, senza dover estendere alcun oggetto di Javascript. Utilissimo il suo sistema di templating, in grado di renderizzare complesse strutture HTML iniettando dati in formato JSON. È anche una dipendenza del framework Backbone. 4.6 QUnit QUnit è una potente e versatile suite di test per Javascript, scritta dal team di jquery e usata da molti progetti opern source (anche in Backbone.js e nello stesso jquery) per testare il loro codice. È in grado di testare codice JavaScript standard nel browser come anche codice lato server (con ambienti di esecuzione come Rhino, V8 e SpiderMonkey). Questo la rende una robusta soluzione per un grande numero di use-cases.

47 4.7 Persistenza dei dati: YDN-DB Persistenza dei dati: YDN-DB La ricerca e la scelta di una soluzione di persistenza dei dati in locale è stata dicoltosa. Si voleva cercare una libreria che fosse performante, orisse buoni metodi di accesso ai dati e soprattutto il più possibile cross-browser. Sono state esplorate molte soluzioni, testate diverse librerie e alla ne è stata scelta una libreria sperimentale e ancora in fase di sviluppo, ma che è riuscita a soddisfare tutte le esigenze e i requisiti dell'applicazione: YDN-DB.js. Ore un'interfaccia unicata per accedere a LocalStorage, WebSQL e IndexedDB a seconda delle preferenze, la scelta viene fatta in automatico impostando a priori un grado di priorità. Grazie ad una pagina di test è stato possibile vericare immediatamente il supporto di tutti i browser e constatare che eettivamente questa soluzione funziona. Le API sono molto pulite, semplici e immediate da utilizzare. La denizione degli schemi è molto simile a quella di IndexedDB, essibile e non eccessivamente verbosa. Le API, al momento della progettazione, coprivano solo funzioni di inserimento e prelievo tramite put() e get(), ma con il passare dei giorni i programmatori hanno aggiunto sempre più funzionalità aggiungendo il supporto delle transazioni, dei cursori, un sistema di query componibili e operazioni complesse di manipolazione. Le prestazioni sono ottime in tutti i browser grazie ad operazioni asincrone: sono stati eseguiti dei test su inserimenti e letture di records, e le tempistiche andavano dai 2 ai 5 secondi. Internet Explorer non è stato considerato, in quanto risultava compatibile solo con il LocalStorage, non contemplato dall'applicazione per la limitazione di spazio. Di seguito è mostrato un sorvolo di tutte le soluzioni esaminate. HTML5 LocalStorage: questa tecnologia fa parte della nuova specica HTML5 per la persistenza dei dati sul client. Ore API molto semplici, si possono memorizzare coppie chiave - velore attraverso metodi put e prelevare tramite get(key). Lo scope è a livello di dominio, cioè che per ogni sito internet che invoca le funzioni del LocalStorage ne viene creata un'istanza ed assegnata a tale sito, in modo che possa leggere e scrivere solo sulla sua istanza, senza interferire con i dati degli altri siti. Le operazioni di lettura e scrittura sono sincrone, e non ha il supporto di transazioni. Seppur molto semplice, è una soluzione ecace e veloce, anche in termini di prestazioni. Purtroppo ha un limite intrinseco: la dimensione massima dello storage non può superare i 5MB. In alcuni browser è possibile estendere questo limite, seppur non da codice, mentre in Internet Explorer, Firefox e Chrome non è possibile. HTML5 Web SQL Database: tecnologia inclusa nella specica HTML5, mette a disposizione un database SQLite interrogabile con linguaggio SQL. Eredita tutti i vantaggi di un database relazionale, la essibilità, la potenza e le robustezza della base di dati, inoltre non c'è limite alla dimensione in MB. Le operazioni di lettura e scrittura sono asincrone ed è possibile eettuare operazioni in transazioni. È compatibile con tutti i browser webkit based,

48 40 Tecnologie Utilizzate Figura 4.5: Messaggio sulla pagina del Web SQL Database come Chrome e Safari, e Opera. Purtroppo ci sono due problemi con questa soluzione. Il primo è quello mostrato dalla gura 4.5, ossia che il W3C ha dichiarato di non supportare più lo sviluppo della specica. A lungo termine questo potrebbe essere un problema, i browser potrebbero dierire nell'implementazione o smettere di supportarla. Il secondo problema è direttamente legato a questo, ed è che i browser Firefox e Internet Explorer si sono riutati di supportare questa caratteristica. HTML5 IndexedDB: Altra specica del W3C che intende sostituire il Web SQL Database e diventare in futuro lo standard per il data storage clientside. Il sistema di storing dei dati si basa su dei surrogati di tabelle, chiamate ObjectStore, che deniscono solo il nome e la chiave primaria, ed è possibile salvare e prelevare i record conoscendo il loro ID. Come il Web SQL Database, anche IndexedDB supporta le transazioni e le operazioni in lettura e scrittura sono asincrone. Il problema per questa soluzione è che, purtroppo, lo standard è pienamente supportato, al tempo di scrittura, dalle versioni più recenti di Firefox e Chrome, e di una parziale copertura da parte di Internet Explorer 10. Nessuna delle soluzioni disponibili andava bene, da sola, per il progetto. Inizialmente si è pensato di creare da zero una libreria personalizzata che permettesse di utilizzare una soluzione o l'altra tra IndexedDB e Web SQL Database a seconda delle compatibilità tra browser. Mi sono accorto presto che il tempo a disposizione non sarebbe bastato per la costruzione di una libreria di interfacciamento che fosse interoperabile tra i diversi browser, così è stato necessaria la ricerca di soluzioni già pronte. Di seguito sono illustrate le altre librerie considerate: LawnChair.js: Libreria che di base fornisce un'interfaccia verso database di tipo LocalStorage, ma è espandibile attraverso plugins anche a Web SQL Database e IndexedDB, basta impostare manualmente (tramite browser detection) il sistema di persistenza. La soluzione sembrava funzionare bene per Chrome, Opera e Safari, ma il plugin per IndexedDB aveva considerevoli

49 4.8 Compressione Dati 41 problemi di performance nello storing e nella lettura massiva di dati. Firefox andava in freeze, probabilmente perché le chiamate erano fatte in modo sincrono, e l'unica soluzione era il kill del processo. JayData.js: Libreria cross-browser che fornisce un'interfaccia a IndexedDB o Web SQL Database a seconda della compatibilità. API molto complete ma verbose, costringevano il programmatore a denire a priori una struttura rigida tra le entità proprio come in una base di dati vera e propria. Il sito web riporta alcuni esempi di utilizzo che non hanno mai funzionato né con Firefox, né con Chrome e tantomeno con Internet Explorer. Ad ogni modo il pacchetto per l'applicazione pesa ben 500kb, perché nella versione core sono presenti molte altre funzionalità inutili per questo progetto. Persistence.js: Fornisce solo il supporto per LocalStorage e Web SQL Database. 4.8 Compressione Dati Come da requisiti, l'applicazione avrebbe dovuto minimizzare il più possibile il consumo di banda. Per raggiungere l'obiettivo si sono dovuti prendere in considerazione sia la dimensione dei le che formano la parte client che i dati scambiati tra client e server durante le chiamate AJAX. Per ridurre la dimensione dei le javascript si è usato il tool YUI Compressor, un miniaturizzatore di codice Javascript scritto in Java. Quando gli è richiesto di miniaturizzare un le.js, comincia a fare un parsing del codice per capirne la struttura e contemporaneamente eliminando quanti più spazi bianchi, tabulazioni e carriage returns possibili. In questa fase sono eliminati anche tutti commenti, e viene costruita internamente una tabella con tutti i nomi di variabili che possono essere sostituite da singole lettere (come ad esempio le variabili dichiarate localmente o i nomi dei parametri delle funzioni). Il risultato sarà un le.js contenente una singola, lunghissima riga contenente tutto il codice, e con lettere dell'alfabeto che sostituiscono i nomi delle variabili. Tale script non dovrà essere poi usato per lo sviluppo, essendo che il risultato non sarà quasi più comprensibile allo sviluppatore. Dopo la miniaturizzazione dei le.js si è eseguita anche una compressione degli stessi con l'algoritmo gzip: utility di compressione open source, basato sull'algoritmo Deate (che internamente utilizza la codica di Huffman insieme a LZ77) che produce dei le dall'estensione.gz usando una compressione lossless. Una volta compressi i le è suciente caricarli direttamente nel server, il browser si incaricherà di eseguire la decompressione. Nella gura 4.6 è riassunto il modo in cui avviene il passaggio dei le e le informazioni degli headers coinvolti nel processo.

50 42 Tecnologie Utilizzate Figura 4.6: Schema di risposta HTTP con compressione Le richieste e le risposte AJAX vengono anch'esse compresse: dal server verso il client utilizzando gzip, dal client verso il server usando una particolare libreria JSend.js. Tale libreria fornisce uno strumento di compressione lossless, basato su una rielaborazione dell'algoritmo Deate, che supporta il formato UTF-8 per le stringhe. È disponibile una versione Javascript per la compressione e una controparte PHP per la decompressione. In gura 4.7 si può vedere un esempio di utilizzo. Figura 4.7: Richiesta AJAX con JSend

51 Capitolo 5 Progettazione Infrastruttura Durante questa fase, si è adottata una visione top-down del problema, partendo con l'individuazione delle entità fondamentali derivate dall'analisi dei requisiti per poi aumentare il dettaglio e rinire lo schema denendo prima le componenti atte al raggiungimento dei requisiti obbligatori, lasciando solo alla ne quelle desiderabili e opzionali. In questo capitolo verrà descritta l'architettura dell'applicazione, a partire dalla logica ad alto livello no a scendere nel dettaglio delle varie componenti del sistema. Nella prima sezione verrà mostrata la divisione concettuale tra client e server, come interagiscono tra di loro e i meccanismi di astrazione per rendere le due parti indipendenti. Nelle sezioni successive verranno descritte in dettaglio le architetture, corredate da schemi delle classi e le relazioni tra i diversi packages. I diagrammi sono presentati seguendo lo standard Unied Modeling Language (UML), che permettono di rappresentare meglio le attività ed i compiti delle singole componenti, nonché le interazioni tra più elementi che determinano il funzionamento del sistema software realizzato. 5.1 Architettura di alto livello Architettura Fisica FileMaker Pro 10, in uso dal Dipartimento, giunge all'utente con una versione Server e una versione Client, come illustrato precedentemente nella sezione 2.1. Il funzionamento è molto semplice: una volta installato e congurato FileMaker Server, i client possono accedervi direttamente conoscendo l'indirizzo IP e fornendo le loro credenziali; a questo punto, a seconda dei loro privilegi, possono accedere ai le in esso residenti e svolgere le normali operazioni permesse. In pratica, sussiste una Congurazione a Server Singolo, dove tutto il software risiede presso una sola macchina insieme ai dati persistenti. Questa congurazione è una delle più semplici e veloci da installare in assoluto, non richiede molta manutenzione ed è adatta ad un carico di lavoro basso, e si adatta benissimo alle esigenze del dipartimento, nel quale il numero di utenti che lavorano contemporaneamente non supera mai la decina.

52 44 Progettazione Infrastruttura Figura 5.1: Congurazione a due livelli dell'architettura sica Ma in futuro le cose potrebbero andare diversamente: il sistema potrebbe crescere, insieme al numero di utenti utilizzatori, e aver bisogno di essere scalato. È chiaro che a questo punto un'infrastruttura sica a server singolo non potrebbe più andare bene, e sorgerebbe la necessità di avere un meccanismo di bilanciamento del carico che si avvale di più servers. La soluzione è quindi una congurazione a due livelli, (uno schema in gura 5.1) dove sono in gioco più componenti. 1. Il primo livello è composto dal AdaM WebApp Server: una macchina che ospita un Server Web e un Application Server. Il Web Server è il servizio a cui il client si connette per richiedere i contenuti statici necessari al funzionamento dell'applicazione (pagine HTML, script.js, immagini, css e così via). L'Application Server funge da interfaccia al livello sottostante, separando la logica dell'applicazione da quella del database sottostante. 2. Il secondo livello è rappresentato dal Database Server, che fornisce il servizio di persistenza dei dati. Nel nostro caso è dove risiederebbe il software FileMaker Server. I vantaggi di questa congurazione rispetto alla precedente sono tantissime: oltre a garantire un elevato grado di disaccoppiamento fornendo un vero e proprio Application Layer per l'accesso alla base di dati, l'infrastruttura consente di poter aggiungere altri Database Servers e garantire un'alta disponibilità del servizio utilizzando copie slave per la lettura dei dati, e un master per la scrittura. Oppure si potrebbe decidere di usare altri database come sources, ad esempio MySQL: in tal caso basterebbe aggiornare il software nell'application Server in modo che sia in grado di gestire le richieste verso un DBMS di quel tipo. Aggiungendo un altro livello all'infrastruttura si possono fare ottimizzazioni sul bilanciamento del carico anche sull'application Server, replicandone la logica su altre macchine e dando all'applicazione un ottimo livello di scalabilità. Naturalmente tutto questo per il momento non è necessario. Attualmente la soluzione adottata è la prima esposta, la congurazione a server singolo in cui Application Server (che funge anche da Web Server) e Database Server sono residenti

53 5.1 Architettura di alto livello 45 nella stessa macchina, considerato il modesto numero di utenti che utilizzeranno l'applicazione Architettura Logica L'architettura logica è progettata rispecchiando la struttura sica in cui l'applicazione dovrà risiedere. Il software si compone infatti di una parte server, scritta in linguaggio PHP e una parte client, realizzata usando Javascript, HTML e CSS. L'interazione tra le due parti si può vedere in gura 5.2 Figura 5.2: Comunicazione tra client e server La parte client è fruibile dall'utente attraverso un browser web, il quale renderizza l'interfaccia graca dell'applicazione per accedere a tutte le funzionalità. Qui, parte della logica di persistenza dei dati di FileMaker è replicata utilizzando le API web storage fornite dalla nuova specica HTML5, integrate in una libreria cross-browser per le operazioni CRUD. Più dettagliatamente, nel client è replicato solamente lo schema delle entità e le informazioni sulle relazioni tra di esse (quindi chiavi primarie ed esterne); questa scelta è stata necessaria per ridurre la complessità dell'operazione di importazione del database tramite il checkout. In ogni caso non si sta introducendo nessuna dipendenza, perché lo schema del database locale è totalmente indipendente dal modo in cui i dati sono rappresentati nel database remoto. L'Application Layer creato dal server ousca la logica di persistenza di FileMaker, e i dati sono presentati al client secondo una rappresentazione standard non destinata a cambiare nel tempo. In tal modo è stato possibile introdurre nel client uno schema consistente e logicamente coerente con la realtà da modellare già da subito, e quando si dovrà cambiare la struttura del database remoto basterà modicare la classe sul server incaricata dell'elaborazione delle richieste da e verso FileMaker. La comunicazione tra server e client avviene sfruttando la tecnologia AJAX, ed inviando i dati codicati nel formato JSON. A questo punto la richiesta viene

54 46 Progettazione Infrastruttura interpretata e validata in remoto, e se le credenziali sono valide verrà eseguita la richiesta specicata e i dati elaborati saranno ritornati in formato JSON secondo un pattern denito. 5.2 Struttura del Server La componente server è realizzata usando il linguaggio PHP5, scelta obbligata dettata dai vincoli del proponente dello stage e dal fatto che FileMaker non ore altri metodi di interfacciamento se non le sue API, scritte appunto in linguaggio PHP. Ha il compito di rispondere alle richieste inviate dal client, che possono essere: 1. Richiesta di autenticazione: dati un username e una password, il server deve vericare che l'utente abbia i diritti per accedere all'applicazione. In caso aermativo verrà creato un token di sicurezza, contenente la password criptata con l'algoritmo AES usando una chiave conosciuta solo al server. Tale token viene poi mandato al client che dovrà memorizzarlo: servirà per assicurare l'identità dell'utente che ha eseguito l'autenticazione e permettergli di accedere alle funzionalità. 2. Checkout: Richiesta di importazione dell'intero database, i record vengono prelevati usando delle funzioni fornite dalle API PHP per FileMaker e inviati al client in un pattern che minimizza la ridondanza. Insieme ai singoli record vengono mandate anche informazioni per le Liste Valori dei campi e il numero di revisione del database. 3. Update: Richiesta di aggiornamento del client. Dato un numero di revisione, vengono prelevate le modiche apportate al database da quella revisione in poi. Tali informazioni vengono elaborate in modo che il client sia in grado di replicare le modiche e rimanere in uno stato consistente. 4. Commit: Richiesta di sottoscrizione delle modiche eseguite sul client. Alla ne dell'operazione il database remoto sarà uguale al database locale dell'utente che ha eseguito il commit, e il numero di revisione viene aggiornato. 5. Ping: Ritorna un oggetto vuoto, serve per testare la disponibilità del servizio. Un dettaglio importante, come già detto nella sezione 2.3.1, è il ruolo giocato dalla tabella Modiche in cui sono salvate tutte le operazioni compiute sul database. Ogni operazione di modica, per assicurare la consistenza dei dati in un ambiente multiutente, è eseguita all'interno di transazioni: una transazione è una sequenza di operazioni, che può concludersi con un successo o un insuccesso In caso di successo, il risultato delle operazioni deve essere permanente, mentre in caso di insuccesso si deve tornare allo stato precedente all'inizio della transazione. Tale meccanismo è possibile attraverso dei LOCK in lettura o scrittura a livello di intere tabelle o di singoli record. Ci sono vari livelli di LOCK possibili, alcuni più

55 5.2 Struttura del Server 47 Figura 5.3: Schema delle classi della componente server permissivi e altri più restrittivi. Per assicurare un assoluto grado di consistenza si è scelto di impostare per tutte le transazioni un livello serializable: ciò sta a signicare che sono eseguite in modo sequenziale, senza nessuna sovrapposizione tra loro. Questo comporta un lock dell'intero database durante operazioni di scrittura, rendendo di fatto molto più lenti gli accessi al database nel caso di molte richieste di commit. Fortunatamente questo non creerà disagi all'utente nale, in quanto l'applicazione è stata pensata per un uso quasi esclusivamente locale e da parte di un numero limitato di utilizzatori. La probabilità che ci sia un burst di scritture è molto bassa Package Server & Crypto In gura 5.3 si può vedere l'organizzazione delle classi che compongono il server. Principalmente la classe Server funge da Facade ed è l'entità che si occupa di ascoltare le richieste del client, mandate tramite AJAX in formato JSON in modalità post. La funzione pubblica listen() riceve i dati e legge i parametri della richiesta. Un attributo operation indica la funzione da eseguire, sono richiesti parametri aggiuntivi a seconda del tipo di operazione: mentre per il ping non sono richieste credenziali, per l'autenticazione sono necessari gli attributi username e password; per le altre funzionalità le credenziali devono includere l'username in chiaro, un hash della password codicata con MD5 e il token di sicurezza creato in fase di autenticazione. La classe Crypter è incaricata di decodicare il token di sicurezza, in modo da recuperare la password dell'utente per accedere al database. Prima di eettuare

56 48 Progettazione Infrastruttura la connessione, deve essere eseguito un ulteriore confronto tra l'hash e il risultato della codica MD5 sulla password appena recuperata per accertarsi che siano eettivamente uguali. Questo assicura l'identità dell'utente e la sua precedente autenticazione riuscita con successo. Superato il controllo, Server fa uso dell'interfaccia DBInterface per eseguire le operazioni CRUD necessarie al soddisfacimento della richiesta. Sfruttando il polimorsmo di PHP è possibile fornire un'interfaccia comune a tutti gli eventuali servizi di persistenza, sollevando la classe utilizzatrice dalla responsabilità di gestire personalmente le operazioni speciche per ognuno. Nel nostro caso è disponibile solo il collegamento ad una base dati FileMaker, eettuato tramite la classe FileMakerDB che usa delle API speciche. DBCreator è una classe che gestisce la creazione dei servizi, ma ritorna l'interfaccia di tipo DBInterface. Una volta terminata l'elaborazione, i dati vengono spediti al client sotto forma di oggetto JSON. Tenendo conto che la dimensione di tale oggetto potrebbe essere molto grande (anche svariati MB nel caso di un checkout del database), prima di essere inviato passa attraverso una classe utility Compressor che comprime i dati usando l'algoritmo di compressione GZip. È possibile incaricare il browser di eettuare la decompressione semplicemente aggiungendo nell'header di risposta la stringa content-encoding: gzip. È risaputo che la compressione con Deate ha migliori prestazioni in termini di velocità di compressione, ma non è compatibile con tutti i browser mentre gzip è largamente supportato. La classe è in grado di decomprimere i dati mandati dal client, compressi con una libreria chiamata JSend e disponibile sia in Javascript (solo compressione) che per PHP (solo decompressione) Package DataObject Figura 5.4: Classi di supporto per l'interfacciamento al database

57 5.3 Struttura del Client 49 Ogni classe derivata da DBInterface potrebbe avere un proprio modo per rappresentare i dati, dipendente dalla struttura del database sottostante e le funzioni di interfacciamento. Basti pensare ad esempio al risultato di una query eseguita con API per MySQL e una eseguita con API per FileMaker. Sono molto diverse tra loro, e la classe utilizzatrice ha bisogno di una rappresentazione standard di tali dati. Per questo motivo sono state introdotte classi intermedie che facilitano lo scambio di dati tra le componenti. Le possiamo vedere in gura 5.4. Record: contiene una mappa indicizzata rappresentante un singolo record, come chiave i nomi dei campi e come valori i valori di tali campi. Table: contiene informazioni generiche su una tabella, il nome, la lista dei campi, la lista dei campi che formano la chiave primaria e le eventuali liste valori relative ai campi. È un contenitore di record e fornisce metodi per aggiungere e reperire un record. DbObject classe che rappresenta un intero database, è una collezione di tabelle in un array associativo identicate dal loro nome più un campo indicante il numero di revisione. È da notare che ogni classe possiede un metodo che consente di serializzare i dati in una stringa in formato JSON, così da poter essere facilmente compressa e inviata al client. 5.3 Struttura del Client Il client è composto da una serie di script JavaScript, le html e css. Organizzare un'applicazione javascript non è compito facile, in quanto la sintassi stessa non conosce il concetto di classe, ereditarietà e polimorsmo. Per ovviare a questo problema è stato scelto di utilizzare un framework che tenti di riprodurre queste funzionalità, simulandone i meccanismi sempre usando puro javascript. Tale framework è Backbone.js, nato per dare una struttura alle applicazioni web fornendo degli oggetti in grado di agire come delle classi, e attraverso un design pattern observer è possibile collegare dei metodi a degli eventi specici, ad esempio un click del mouse da parte dell'utente. La scelta che ha portato all'utilizzo di Backbone.js è stata la leggerezza in dimensione del framework e che non impone al programmatore nessuna struttura a priori, ma ha un grado altissimo di essibilità per adattare al meglio l'applicazione alle proprie esigenze. Fornisce un sistema automatizzato di sincronizzazione con il server tramite richieste RESTful, totalmente personalizzabili e utilizzando il formato standard JSON, che insieme al supporto di persistence layer si adatta benissimo agli scopi dell'applicazione. La maturità del progetto, la vasta community e la buona documentazione sono altri punti a favore interveunti nella scelta. Oltre a questo ci sono molte altre funzionalità, discusse nella sezione 4.4. Quale design pattern architetturale è stato scelto? Per facilitare il più possibile lo sviluppo e mantenere un alto livello di disaccoppiamento si è cercato un approccio il più vicino possibile ad un Model - View - Controller (MVC).

58 50 Progettazione Infrastruttura Figura 5.5: Classi del client, packages e relazioni

59 5.3 Struttura del Client 51 Tuttavia, molti dei framework Javascript disponibili non sempre rispecchiano fedelmente la interpretazione classica dell'mvc, ma la adattano a seconda della loro losoa. Ad esempio Backbone.js è orientato verso una soluzione mista tra il classico MVC e MVP (Model - View - Presenter), battezzato MV*: conserva la separazione tra la componenti dedite alla logica dell'applicazione e quelle necessarie alla presentazione, ma ottimizza il riuso delle componenti grache e semplica il meccanismo di binding tra eventi nella view e metodi da eseguire nel model. La funzione del Controller è stata distribuita tra le responsabilità delle View, che comunicano direttamente con il Model, e nella classe Router, che gestisce lo switch delle varie view per simulare una navigazione tra pagine diverse. Nella gura 5.5 possiamo vedere l'insieme generale delle componenti e dei diversi packages Adam.Model Figura 5.6: Client Package Model Il cuore pulsante di tutta l'applicazione, in questo package sono presenti le classi che modellano la logica di persistenza dei dati nel browser e che eettua la comunicazione con il server. Soddisfa le richieste della View-Controller eseguendo operazioni under the hood all'avvenire di determinati eventi azionati dall'utente. YDN-DB: Oggetto che funge da interfaccia al database del client. Le sue funzionalità sono simili a quelle della classe Server (vedere sezione 5.2.1), e aggiunge

60 52 Progettazione Infrastruttura altre funzioni per un accesso più eciente da parte dell'applicazione. Oltre che ai comuni comandi CRUD aggiunge la possibilità di resettare i dati presenti, di impostare un numero di revisione, creare un utente, leggere e scrivere intere tabelle in una sola volta. Tutte le chiamate avvengono in modo asincrono, non bloccando il browser aspettando la risposta. Il problema dell'ecienza delle operazioni (in termini di prestazioni), del mantenimento della consistenza e persistenza dei dati, ma soprattutto della compatibilità tra browsers è stato un grande ostacolo da superare, di gran lunga il più ostico incontrato in tutto il progetto. Per questo modulo è stata utilizzata una libreria sperimentale di nome YDN-DB.js, nella sezione 4.7 sono descritti i dettagli e il suo utilizzo. AppManager: Oggetto che assume il ruolo di Facade, permettendo alle view di richiedere dati dal database e compiere operazioni richieste dall'utente, come l'autenticazione, il login, modica, cancellazione, aggiunta di un record e operazioni di sincronizzazione. Ha anche il compito di creare le richieste da inviare al server, validare le risposte e mandare segnali alla View per mostrare messaggi all'utente. AppManager gestisce anche il processo di update e commit, producendo una tabella delle modiche riassumente lo stato del client da mandare al server. Può accedere ai modelli delle tabelle, conoscendo le relazioni e recuperando i record che sono correlati ad un altro da un vincolo relazionale. Ad esempio, se volessimo cancellare un record che sta in US, dovremo cancellare anche molti altri dati che stanno in altre tabelle per mantenere uno stato consistente. Network: Oggetto addetto alla trasmissione e alla ricezione di dati con il server, utilizzando la tecnologia AJAX. Il vantaggio di usare AJAX è che le chiamate avvengono in modo asincrono, pertanto il browser non andrà in freeze aspettando che il server mandi una risposta, in più grazie alla possibilità di inviare i dati con metodo post possiamo garantire l'anonimato dei dati. Servendosi dell'oggetto Compressor è in grado di comprimere i dati da mandare al server, particolarmente utile in caso di commit, dove si possono raggiungere dimensioni discretamente elevate. Per la compressione è usata la libreria JSend, come già citato precedentemente nella sezione Maggiori informazioni sono disponibili alla sezione 4.8. È possibile fare richieste di ping al server per vericare la disponibilità della rete Internet e se il servizio remoto è disponibile. Se uno dei due non lo fosse, allora AppManager dovrebbe comunicare alle viste di disabilitare le funzionalità che richiedono una connessione. State: Oggetto di utilità che contiene tutte le informazioni sullo stato dell'applicazione, comprese le tabelle che vengono caricate in memoria all'avvio. Il motivo di questo comportamento è per evitare inconsistenze o dare all'utente la sensazione di una navigazione poco uida, considerando il fatto che la visualizzazione di alcuni dati dipende da altri e se non sono in memoria bisogna caricarli dal database.

61 5.3 Struttura del Client 53 Table: Oggetto che memorizza le informazioni di una tabella, tra i quali le liste valori, il nome dei campi e i records. Visto che le operazioni sul database sono asincrone, una tabella può essere in diversi stati. Empty: La tabella è stata creata e non è stata soggetta a riempimento. Filling: La tabella è stata creata ma non è accessibile perché è in corso il caricamento dei dati dal database. Ready: La tabella è caricata e pronta per essere utilizzata. Missing: C'è stato un tentativo di caricamento ma la tabella non risulta essere nel database. Broken: Durante il caricamento ci sono stati degli errori che rendono la tabella non utilizzabile. Estende l'oggetto Backbone.Collection, un gestore di oggetti Backbone.Model incaricato di raccogliere e tener organizzati gruppi di entità. In questo caso il modello a cui Table fa riferimento è l'oggetto Record Adam.RecordModel Figura 5.7: Client Package RecordModel Questo package contiene tutte le entità derivate da Backbone.Model e che racchiudono le informazioni logiche di un record quali i campi, le relazioni con record di altro tipo e soprattutto metodi specici per la validazione dei dati. Il primo elemento della gerarchia è Record che simula il comportamento di una classe astratta, ossia dichiara i metodi ma non ne dà nessuna implementazione. Gli elementi che ereditano da Record sono specici di ogni tipologia di record che l'applicazione può gestire. L'oggetto RecordModelManager è un raccoglitore di modelli, salva nelle sue variabili interne i modelli non inizializzati. Bisogna specicare che Record e i suoi derivati non sono propriamente concretizzazioni di un record di tabella. Sono delle rappresentazioni logiche, tecnicamente non sono oggetti instanziati: dal punto di vista dell'applicazione sono come delle funzioni costruttore, che se dichiarate

62 54 Progettazione Infrastruttura Figura 5.8: Client Package View con new Record allora diventano a tutti gli eetti oggetti, e soltanto ad allora il loro signicato cambia e si trasformano in veri e propri record di tabella Adam.View La componente view gestisce le pagine che l'utente può navigare e le azioni che può compiere in ognuna di esse. La gerarchia principale comincia derivando i metodi principali da Backbone.View che fornisce un sistema di ascolto degli eventi. Le View in Backbone incapsulano il ruolo del controller, associando eventi a funzioni del Model. Per questo tutte le classi glie di GenericView interagiscono con l'oggetto Facade AppManager, potendo eseguire i suoi metodi e modicare lo stato dell'applicazione. Tutto l'html visualizzato non è generato dall'applicazione, ma è contenuto in le e caricati all'avvio. Tali le prendono il nome di Templates, modicabili a piacere per inserire contenuto statico e denire una strutturazione alle pagine, oltre che piacevoli eetti con i CSS. L'importante è non modicare alcuni <div> usati dal programma per inserire elementi del DOM renderizzati. Ogni oggetto glio di GenericView corrisponde ad una pagina che l'utente può visualizzare, corredata dalla propria lista di eventi a cui sono associati metodi personalizzati. Ognuna di esse ha un proprio le.html, che attraverso l'underscore template engine (sezione 4.5) importa e renderizza la pagina vera e propria usando HTML5 e CSS. Le più importanti sono due, che gestiscono la visualizzazione e modica dei dati archeologici:

63 5.3 Struttura del Client 55 ListView: Vista ad elenco, mostra una panoramica su una tabella visualizzando un'anteprima dei record. L'elenco è organizzato in pagine, tra le quali si può navigare con dei pulsanti e l'utente può decidere quanti record visualizzare per ogni pagina. Da qui alcuni link lo portano alla creazione di nuovi record, gli dà la possibilità di selezionarne alcuni tramite checkboxes ed eliminarli oppure vedere tutti i dettagli del record cliccandovi sopra. Oltre a questo, l'utente può ordinare i record in ordine ascendente o discendente, cliccando nel nome dei campi nell'intestazione dell'elenco. I dati visualizzati sono modicabili dal template.html, non è richiesta nessuna modica all'applicazione. Questa vista si adatta a tutte le tabelle, in quanto le funzioni che l'utente può compiere sono sempre le stesse. DetailView: Vista di dettaglio, mostra tutti i dettagli di un record. Da questo oggetto partono molte altri oggetti derivati, ognuno che incapsula funzionalità speciche per ogni tipo di record. Questo perché non sempre le funzioni che l'utente può eseguire sono le stesse in tutte le viste di dettaglio, ma cambiano da un tipo di dato all'altro. Ad esempio, nel Diario di Scavo deve essere possibile inserire una o più US relative a una giornata, cosa che non è possibile fare sulle altre. In più qui sono gestite le operazioni di modica e validazione dei dati, anche grazie alle API HTML5 per la validazione dei form. Altre due oggetti che collaborano per la creazione delle View sono: LayoutManager: Carica i template, dei semplici le.html con all'interno degli speciali delimitatori dentro i quali si possono iniettare stringhe di codice da eseguire, ad esempio delle funzioni getter per mostrare i valori di determinati dati. L'oggetto si limita di restituire il template giusto a seconda del nome della View da caricare. ViewsInstantiator: Utilizza un'istanza di RecordModelManager per associare le View con l'esatto modello di dato necessario alla visualizzazione. All'inizio il modello sarà vuoto, sarà compito del Router decidere se inizializzarlo con dei dati oppure lasciarlo vuoto, a seconda del percorso scelto dall'utente Adam.Router Classe che simula la navigazione utente tra le diverse view associando gli URL a delle funzioni. Tali funzioni invocano l'oggetto ViewsInstantiator anché crei la View non inizializzata, nel caso ce ne sia bisogno invoca anche la Facade AppManager per richiedere i dati che la view deve visualizzare nel suo template. Dopodichè richiama Render() che compila il template con i dati dell'oggetto passato e inserisce l'html così creato nel DOM. Le views sono cachate per aumentare la uidità e per poterne ripristinare esattamente lo stato quando l'utente naviga tra più schermate: ad esempio nelle Views elenco, non viene resettato il numero di pagine e nemmeno gli elementi per pagina.

64 56 Progettazione Infrastruttura Figura 5.9: Client Package Router