Tesi - Cumin Paolo v2

UNIVERSITA’ DEGLI STUDI DI TRIESTE
FACOLTA’ DI INGEGNERIA
TESI DI LAUREA
IN INGEGNERIA INFORMATICA
SVILUPPO DI UN DATABASE IN ORACLE 9i

E MS SQL SERVER 2005 PER MAPPE GEOGRAFICHE
Laureando: Relatore:
Cumin Paolo Chiar.mo Prof Maurizio Fermeglia
Back to thy punishment,
False fugitive! and to thy speed add wings,
Lest with a whip of scorpions I pursue
Thy lingering, or with one stroke of this dart
Strange horrour seize thee, and pangs unfelt before.
Paradise Lost, John Milton
He hath heart who knoweth fear, but vanquishes it; who

sees the abyss, but with pride.
He who sees the abyss, but with eagle's eyes...
Thus Spake Zarathustra, F.W.Nietzsche
2
Indice
1 Introduzione.....................................................................................................................................4
Introduzione
2 Analisi...............................................................................................................................................6
Analisi
2.1 Interviste ed obbiettivi.......................................................................................................6
2.2 Situazione precedente al sistema informativo......................................................................8
2.2.1 Caratteristiche delle immagini.............................................................................9
2.3 Prototipo..........................................................................................................................12
2.4 Requisiti...........................................................................................................................13
2.5 Strumenti utilizzati........................................................................................................ ...15
2.5.1 SQL Server 2005 e Oracle9i..............................................................................15
2.5.2 .NET Framework e C#....................................................................................15
2.5.3 Visual Studio 2005............................................................................................16
2.5.4 Web-Service in .NET………...........................................................................17
2.5.5 IIS....................................................................................................................18
2.5.6 UML per la progettazione del Database e del Software......................................19
2.6 Architettura della soluzione software.................................................................................19
2.6.1 Database...........................................................................................................19
2.6.2 Servizi Web......................................................................................................20
2.6.3 Interfacce GUI..................................................................................................20
3 Progettazione e realizzazione..............................................................................................................22
realizzazione
3.1 Progettazione e realizzazione del Database..........................................................................22
3.1.1 Tabelle...............................................................................................................23
3.1.2 Relazioni............................................................................................................29
3.1.3 Viste...................................................................................................................32
3.1.4 Stored Procedures e User Defined Functions.......................................................37
3.1.5 Trigger................................................................................................................38
3.1.6 Schema generale e gerarchia................................................................................41
3.2 Progettazione e realizzazione della logica dell'applicazione...................................................43
3.2.1 Dataset................................................................................................................43
3.3.1 Metodi Esposti dal Servizio Web.........................................................................43
3.3.1 Libreria Principale...............................................................................................48
3.3 Progettazione dell'interfaccia...............................................................................................58
3.3.1 Interfaccia di inserimento....................................................................................58
3.3.2 Interfaccia di ricerca........................................................................................... 64
3.3.3 Interfaccia di amministrazione.............................................................................67
3.3.4 Plug-in ArcMap..................................................................................................71
3.3.5 Pagine di consultazione ASP...............................................................................72
3.3.6 Schema generale e gerarchia................................................................................74
3.4 Vista d'insieme della struttura del sistema informativo.........................................................77
4 Conclusioni........................................................................................................................................78
Conclusioni
5 Bibliografia..........................................................................................................................................79
Bibliografia
3
1. Introduzione
Questo lavoro illustra tutte le fasi della progettazione e della realizzazione che hanno portato alla creazione di
un applicativo client-server, per l’archiviazione e organizzazione d’immagini raster e vettoriali d’interesse
geografico.
La soluzione software proposta deve consentire il facile immagazzinamento, reperimento e consultazione di

immagini archiviate da parte degli utenti di un laboratorio di GIS.
Questo applicativo è stato realizzato per porre rimedio alla disorganizzazione e alla difficile rintracciabilità
degli studi effettuati e delle immagini disponibili nel Laboratorio di GIS del Dipartimento di Scienze
Geografiche e Storiche dell’Università di Trieste.
Non esistendo sul mercato un’applicazione con tutte le caratteristiche richieste dal committente si è deciso di
procedere alla sua realizzazione.
Presso il laboratorio erano presenti le licenze per i DBMS Oracle e MS Sql Server, è stato deciso di utilizzarle
entrambe per la creazione della base dati, per il front end è stato utilizzato l’ambiente di sviluppo Microsoft
Visual Studio 2005 che ha consentito l’interfacciamento agevole ad entrambe le basi dati. Il notevole costo in
termini economici della licenza Oracle e la possibilità di portare il db sviluppato sotto quest’ultima su sistemi
operativi non windows, in un’ottica di diversificazione del parco macchine (in particolar modo del server
predisposto a db) ha motivato la volontà di sviluppare su entrambi i DBMS la struttura dati.
Durante il lavoro sono affiorate molteplici differenze tra i due DBMS che non hanno impedito il regolare
funzionamento e perfezionamento dell’applicativo
Durante l’elaborazione sono stati affrontati i seguenti punti:
• Sono stati sostenuti diversi colloqui con il committente per individuare il problema da risolvere
• Sono state effettuate diverse interviste e confronti con i ricercatori del laboratorio per comprendere le
loro esigenze e i loro bisogni.
• Sono stati definiti i requisiti, i vincoli e le specifiche.
• È stato realizzato un prototipo basato esclusivamente su un’interfaccia web per testarne le prestazioni e
ottenere i primi feedback dagli utenti riguardo alle migliorie e i cambiamenti da apportare alla
soluzione finale.
• Sono state vagliate le diverse tecnologie disponibili per scegliere la più efficace e adatta al nostro caso.
• Sono state progettate e realizzate la base di dati, la logica del web service e le interfacce.
• È stato realizzato un manuale per gli utenti.
• È stata installata la soluzione software nel server e nei clients del laboratorio per testarla sul campo e
far affiorare e correggere bugs residui.
• Sono stati risolti gli errori riscontrati durante le prime fasi d’utilizzo.
4
L’applicazione e le basi di dati connesse dovevano essere sviluppate e testate con l’hardware ed il software
messo a disposizione dal laboratorio di GIS del Dipartimento, in particolar modo la licenza precedentemente
acquistata del rdbms Oracle versione 9i.
Sul server e clients sono stati utilizzati come sistema operativo Windows XP SP2 32 bit in versione Italiana, è
stato poi acquistato un server Dell con installato Windows Server 2003 R2 x64 che funge tuttora da database
server.
5
2. Analisi
La prima fase del processo di progettazione richiede l’ottenimento dei dati, richieste e informazioni necessarie
per poter soddisfare alle esigenze del committente.
Tutto ciò è stato raggiunto a più riprese, ogni requisito veniva definito formalmente, validato e riportato nelle
specifiche funzionali del programma da realizzare che veniva sottoposto al vaglio del committente. Se l’esito
era positivo, queste specifiche venivano codificate nei moduli e presentate nuovamente al committente per
un’ulteriore verifica e un collaudo approfondito.
Numerose volte richieste e modifiche sono state richieste nella fase successiva alla codifica dei moduli e alla
loro implementazione.
In questa prima parte verranno affrontati i rapporti iniziali con il cliente e la definizione dei requisiti e delle
spacifiche della soluzione software.
2.1 Interviste e Obiettivi
Al fine di comprendere, nel modo più approfondito possibile, il problema da risolvere riguardo alla gestione
delle immagini utilizzate nel laboratorio, si è deciso di effettuare alcune interviste ed osservare tutti i
procedimenti intrapresi dai ricercatori del Laboratorio di Gis durante tutte le fasi del loro lavoro.
Sono state quindi create una check-list e delle interviste al fine di ottenere più informazioni possibili a
riguardo.
La check-list, utilizzata come promemoria delle informazioni da ottenere, comprende i seguenti punti:
• Numero d’immagini già presenti da gestire e previsioni sul loro futuro quantitativo.
• Caratteristiche delle immagini.
• Hardware e Software già a disposizione.
• Sistema d’organizzazione correntemente in uso (carenze e punti di forza).
• Fasi dell'intero processo.
• Obbiettivi ed aspettative del committente.
• Numero di futuri utilizzatori del servizio.
• Proposta di soluzione e confronto con il committente.
6
Le interviste sottoposte ai membri del personale del laboratorio puntano ad ottenere le seguenti informazioni:
• Comprendere a grandi linee il problema generale, addentrandosi poi in casi più specifici.
• Analizzare ogni tipo d’immagine che potrà essere gestita dalla soluzione software e conoscerne le
principali caratteristiche: il numero, le dimensioni, i tipi d’informazioni comuni a tutte le immagini e
quelle invece più particolari ecc...
• Apprendere il processo d’elaborazione delle immagini, dal suo inizio sino alla sua conclusione,
includendo anche i dettagli che a priori sembrano essere di poco conto.
• Capire le problematiche che s’incontrano durante il processo, i miglioramenti che si desidererebbero

introdurre e le parti che si vorrebbe rimanessero invariate.
• Conoscere i software utilizzati sino a quel momento, le preferenze dei ricercatori e il loro livello di
conoscenza delle applicazioni e del sistema operativo.
Da queste interviste sono state ottenute numerose informazioni riguardo al problema da risolvere. Esse sono le
seguenti:
• Il metodo di lavoro in vigore sino a quel momento non prevedeva una gestione ottimizzata degli
elaborati svolti.
• Gli utenti non erano soddisfatti del metodo d’archiviazione delle immagini per le quali risultava
difficile il successivo reperimento con una conseguente perdita di tempo.
• Gli utilizzatori del sistema finale nel laboratorio saranno al massimo 10, mentre la consultazione da
parte di utenti esterni sarà inizialmente limitata alla sola rete universitaria.
• Le conoscenze informatiche dei ricercatori si limitano al normale utilizzo del sistema operativo
Windows XP e ad una conoscenza avanzata d’applicazioni specifiche per l'elaborazione delle
immagini (ArcGis ed Erdas IMAGE).
• L'Hardware a disposizione consiste in una decina di PC equipaggiati con processori Pentium 4 od

AMD Athlon64 con un quantitativo di memoria RAM media di 1GB ed Hard Disk di 250GB.
Gli obbiettivi da raggiungere, concordati assieme al committente, tramite la realizzazione della soluzione
software sono quindi i seguenti:
• Gestire tutti i tipi d’immagini correntemente in uso e quelle degli studi futuri.
• Poter ricercare ed ottenere facilmente le immagini archiviate.
• Offrire buone prestazioni nella sopradetta per non introdurre ritardi nel lavoro.
• Non richiedere uno studio per la comprensione del funzionamento del nuovo applicativo.
• Esporre l'elenco delle immagini disponibili anche da internet.
Si passerà ora ad una descrizione più approfondita delle fasi del lavoro svolto nel laboratorio e delle
caratteristiche delle immagini trattate.
7
2.2 Situazione precedente al sistema informativo
Nell'ambito del laboratorio di scienze geografiche e storiche vengono eseguiti principalmente studi ed analisi
d’immagini satellitari, con lo scopo di ricavare, da esse, informazioni riguardanti l'evoluzione dell'ambiente di
una determinata area della terra in un certo arco di tempo.
L'iter tipico dello svolgimento di tali elaborazioni ha inizio con il reperimento dell'immagine rappresentante
l'area oggetto dello studio. Possono venir scelte differenti immagini della stessa zona catturate in periodi
diversi, al fine di poter individuare le modificazioni apportate dall'uomo o dalla natura al territorio in esame.
La presenza di numerosi satelliti in orbita offre inoltre l'opportunità di scegliere quello più adatto al proprio
studio, valutando le sue caratteristiche di ripresa differenti l’uno dall’altro per risoluzioni spaziale, risoluzione
spettrale, risoluzione radiometrica ecc... Dopo aver inoltrato l'ordine delle immagini, esse sono recapitate, da
parte delle aziende che gestiscono i singoli satelliti, al laboratorio in formato digitale, solitamente su di un
supporto che può essere un CD o un DVD. A questo punto il ricercatore, se ritiene che le immagini a sua
disposizione sono di qualità soddisfacente può iniziare il suo lavoro di estrapolazione delle informazioni
necessarie ed elaborazione con l'utilizzo di software specifici (come ad esempio ERDAS Imagine).
Le immagini in oggetto occupano, solitamente, grandi dimensioni in termini di spazio digitale, sia a causa
dell'estensione delle aree rappresentate, sia per la moltitudine di layers presenti. Durante il periodo di studio
ed analisi inoltre, da una stessa immagine di partenza, possono esserne state ottenute diverse, ognuna delle
quali volta ad evidenziare determinate caratteristiche del territorio preso in considerazione. Lo spazio
complessivo quindi, richiesto per l'archiviazione di tutti questi files, sarà cospicuo e si presenterà il problema di
una loro efficiente organizzazione.
Figura 2.1 Schema iter tipico acquisto e utilizzo immagini
8
Sino a prima dell'utilizzazione del sistema che verrà descritto, nel laboratorio, dopo aver terminato uno studio,
il ricercatore salvava queste immagini su di un CD o in dischi rigidi esterni assieme ai files riguardanti gli studi
effettuati. Questo portava a due principali inconvenienti: la possibile perdita dei dati (a seguito di una rottura
o un deterioramento dei supporti fisici) e alla difficoltà di rintracciare le immagini archiviate. Recuperare
facilmente queste ultime è molto utile per un confronto con gli studi odierni o semplicemente per rintracciare
le immagini originali necessarie per svolgere nuove elaborazioni. Ogni immagine, infatti, ha un costo
piuttosto elevato che non consente un loro nuovo acquisto.
Un procedimento d’elaborazione di tipo leggermente diverso è quello che porta alla creazione d’immagini
vettoriali. In questo caso, infatti, si utilizzano principalmente altre applicazioni (come il programma ArcGis). Il
processo ha inizio, in questo caso, o con il reperimento di un’immagine satellitare o di una carta (sia essa
acquisita da un supporto cartaceo o già disponibile in formato digitale), si prosegue poi con la creazione dei
layers tematici al di sopra del riferimento utilizzato e con l’ottenimento finale di una o più immagini
contenenti uno o più layers. Le fasi e le problematiche successive dell’archiviazione sono invece identiche a
quanto abbiamo visto per le
immagini raster.
2.2.1 Caratteristiche delle immagini (cfr. bibliografia [1])
Le immagini da gestire con la nostra soluzione software, possono essere principalmente di due tipi raster o
vettoriali. Oltre alla loro diversità strutturale nella rappresentazione delle informazioni, che non è di nostro
interesse in questo momento, esse presentano un'altra fondamentale differenza: la quantità di spazio occupato
in termini di bit. Mentre le immagini vettoriali occupano dai pochi KiloByte a qualche decina di MegaByte,
le immagini di tipo raster possono avere dimensioni che vanno dai 5-6 MegaByte a diverse centinaia di
Megabyte. Attualmente, nel laboratorio, vengono eseguiti, per la maggior parte, studi su immagini raster. Le
altre caratteristiche di nostro interesse delle immagine da gestire sono le seguenti:
• Esse, se sono in formato raster, sono state catturate da uno specifico sensore installato su di un
satellite o sono state acquisite tramite uno scanner.
• Sono rappresentate utilizzando una ben determinata proiezione del globo terrestre su di una
superficie piatta.
• Sono state realizzate o elaborate con un software ed hanno quindi uno specifico formato ed
estensione.
• Rappresentano una zona della terra e di conseguenza ogni loro punto può essere individuato
da una coppia di coordinate.
• Rappresentano un territorio in una ben determinata epoca.
9
• Possono esser state eseguite delle correzioni su di esse (ad esempio una correzione
atmosferica).
Ogni sensore installato nei satelliti orbitanti addetto all'acquisizione d’immagini ha delle caratteristiche
particolari ed esse sono:
• l'orbita del satellite sul quale il sensore è installato.
• L'altezza media mantenuta da terra.
• Una data di lancio del sensore in orbita.
• Una denominazione specifica per identificarlo.
Tra i sensori possiamo annoverare anche il semplice scanner da tavolo che quindi non avrà alcune delle
caratteristiche elencate. È chiaro che ognuno di questi sensori produrrà immagini con differenti caratteristiche
come la risoluzione spaziale. Essa indica quanti metri del mondo reale vengono rappresentati da un singolo
pixel.
Un'altra risoluzione importante è quella spettrale che indica invece l'intervallo di lunghezza d'onda della luce
che il sensore riesce ad acquisire. Nel caso dello scanner da tavolo questa andrà dai 380 ai 780 nanometri che
corrispondono allo spettro del visibile (v. Figura 2.1).
Figura 2.1
I sensori satellitari invece, possono acquisire immagini con più bande, ognuna delle quali coprirà un certo
intervallo di lunghezze d'onda, che potranno andare dall'ultravioletto all'infrarosso. Ciò comporta la presenza,
nei file dell'immagine, di più layers ognuno associato ad una banda. Nel caso dello scanner avremo tre soli
layers uno per ogni colore primario.
10
Figura 2.2 Distribuzione delle bande nei sensori Aster e Landsat [2]
Infine avremo un’ultima risoluzione, quella radiometrica. Essa indica il quantitativo di bit utilizzati per
registrare l’informazione di un singolo pixel.
Sostanzialmente essa può essere definita come la capacità del sensore di registrare diversi livelli di radianza.
L’elettronica del sensore trasforma, infatti, il segnale analogico dell’obiettivo in segnale digitale, che associa un
numero binario ad una certa tonalità di grigio. In una banda con risoluzione radiometrica di 8bit avremo
perciò a disposizione 256 tonalità diverse di grigio per rappresentare l’immagine.
Principalmente nel caso delle immagini vettoriali, si possono trovare dei layers tematici che rappresentano una
singola caratteristica di un territorio (un insieme di strade, di case, di condutture idrauliche ecc...).
Le immagini satellitari grezze vengono fornite dagli enti che gestiscono i sensori installati sui satelliti, mentre
immagini già elaborate possono provenire ad esempio da altri laboratori di ricerca.
Nel caso d’immagini vettoriali, durante la loro realizzazione, si utilizza un riferimento per rappresentare in
modo esatto il territorio secondo la proiezione e la scala utilizzate per la creazione della carta di supporto. È
indispensabile indicare il riferimento anche nel caso di carte acquisite tramite uno scanner per conoscerne la
scala.
Per concludere, su ogni immagine elaborata possono esser eseguiti degli studi che spiegano l’obbiettivo del
lavoro svolto ed i risultati ottenuti. Tali studi possono essere eseguiti da diverse persone che realizzano un
documento riassuntivo che descrive l’elaborato.
L’immagine oltre alle sue caratteristiche può quindi avere o meno altri attributi che la contraddistinguono:
• essa potrà avere uno o più layers.
• Sarà in relazione con un solo sensore (nel caso d’immagini vettoriali si tratterà in ogni caso
d’elaborazioni derivanti da immagini acquisite con un sensore). Tale sensore potrà avere delle bande
che saranno associate ai layers.
• Potrà o meno aver subito una o più correzioni.
11
• Potrà avere un riferimento ad una carta di origine.
• Potranno esser stati eseguiti su di essa degli studi da parte di uno o più autori ed esser stati creati dei
documenti relativi.
2.3 Prototipo
Inizialmente, al fine di testare le prestazioni offerte dalle diverse possibili tecniche di realizzazione della nostra
applicazione, è stata creata una prima soluzione software che prevedeva delle pagine ASP per l’accesso ad un
Database realizzato sul DBMS SQL Server 2005 con l’aiuto del tool Microsoft , in contemporanea è stato
predisposto un computer con installato Oracle 9i versione 9.2.0.4 ed è stato utilizzato l’applicativo TOAD
versione 7.2 per la creazione agevole di tabelle, queries, procedure e viste, la creazione della struttura
principale era identica per entrambe le basi dati, cambiavano le modalità di creazione degli elementi che la
componevano e molte delle loro caratteristiche.
L’applicativo operava in modalità connessa ed utilizzava alcune stored procedure realizzate a supporto della
base di dati. Le altre operazioni d’accesso avvenivano invece tramite l’invio di comandi SQL generati a
runtime.
Questa prima soluzione ha permesso di ottenere ulteriori feedback dagli utenti, evidenziando le sue carenze in
termini di velocità. Altri aspetti invece apprezzati dai ricercatori sono stati ripresi e migliorati per questo
lavoro. Sono stati evidenziati infine gli errori più comuni commessi durante l’inserimento dei dati nelle form
da parte degli utenti.
È affiorato quindi, dall’esperienza d’utilizzo di questo primo applicativo, come le pagine web dinamiche non
siano lo strumento adatto al nostro caso. Il sistema di trasferimento di file di grandi dimensioni, infatti, non
garantisce buone prestazioni portando anche, in alcuni casi, a problemi di time-out e al non completamento
delle transazioni. Viceversa, i database management systems non hanno evidenziato alcun tipo
di degrado delle prestazioni durante il tempo d’utilizzo. Tutto ciò ha potuto dare delle prime indicazioni sui
possibili strumenti da utilizzare per la nostra soluzione software e sulle caratteristiche da implementare.
Successivamente, e alla luce dei dati ottenuti dal prototipo, è stato eseguito uno studio di fattibilità durante il
quale sono stati analizzati gli obiettivi da raggiungere in rapporto alle risorse disponibili e ai vincoli temporali
imposti. Si è quindi valutato inizialmente se, con gli strumenti a disposizione, fosse stato possibile realizzare
concretamente un applicativo che fornisse il supporto necessario alla gestione delle immagini.
È stato quindi constatato che, per l’utilizzo interno al laboratorio, le risorse hardware erano adeguate,
considerando un accesso simultaneo (nella fase di upload dei files) alla base di dati da parte di, al più, tre
persone contemporaneamente. Per un ampliamento futuro e per un accesso dall’esterno, esteso anche al
download dei file, è stata presa in considerazione la possibilità di procedere ad un aggiornamento della sezione
storage della macchina server.
Riguardo alla parte software si è deciso di non apportare nessuna modifica ai sistemi correntemente in uso,
lasciando invariati applicativi e sistemi operativi. Si è deciso inoltre di utilizzare i software di sviluppo già a
disposizione, integrando la licenza di Oracle con il tool di sviluppo Toad versione 7.2.
In termini di tempo si è stimato un periodo per lo sviluppo compreso tra i tre e i quattro mesi.
Successivamente è stato previsto un periodo d’altri tre mesi da dedicare al debugging assistendo gli utenti
nell’utilizzo di una prima versione dell’applicativo che verrà quindi migliorata analizzando i feedback ricevuti
e i bugs rilevati.
12
2.4 Requisiti
Nel documento finale dei requisiti sono stati elencati quindi tutti gli aspetti funzionali, i vincoli, gli strumenti
che saranno utilizzati e le informazioni sulla manutenzione del pacchetto software.
Il documento descrive quindi i seguenti punti:
• aspetti funzionali del sistema: la soluzione software deve permettere di gestire tutti i tipi d’immagini
raster e vettoriali d’interesse geografico. Deve essere in grado di registrare tutte le loro caratteristiche
che possono essere: l’estensione del file, una sua descrizione, la fonte e il riferimento, l’eventuale
satellite utilizzato per la rilevazione, la proiezione geografica, la data d’acquisizione, le coordinate della
zona rappresentata, le bande e i layers presenti, le correzioni applicate durante le elaborazioni e gli
studi associati. Si dovrà poter disporre dei files degli studi fatti e conoscerne gli autori. Si dovrà poter
mantenere il sistema con semplicità modificando tutti i dati inseriti.
• Dovrà essere presente un sistema di ricerca adeguato che permetta il reperimento delle immagini
secondo diversi parametri. Un’interfaccia web dovrà permettere la consultazione dell’archivio ma
non la sua modifica o l’ottenimento diretto delle immagini. Queste dovranno venir richieste tramite il
riempimento di una form.
• Vincoli: le prestazioni dovranno consentire un facile accesso al sistema di gestione, una rapida sua
consultazione e inserimento dei files. Le interfacce utente dovranno essere sufficientemente intuitive
da poter essere utilizzate anche senza la lettura di un manuale ed impedire, quando possibile, l’errato
inserimento di valori nei campi. L’hardware a disposizione non potrà essere modificato o aggiornato,
se non quello della postazione server. Il sistema operativo dovrà rimanere Windows Xp e sarà
permesso, sulle postazioni client, l’aggiornamento delle sole librerie di base eventualmente necessarie
all’esecuzione della nuova soluzione software.
• Hardware necessario: i PC presenti nel laboratorio offriranno prestazioni più che sufficienti a fruire
dell’applicazione in modo ottimale.
• Il server che offrirà il servizio non ha, per ora, bisogno di aggiornamenti hardware, necessari solo in
futuro nell’eventualità di un ampliamento delle funzioni rese disponibili in internet. In tal caso sarà
necessario provvedere ad un aggiornamento dei controller e degli hard disk presenti.
• Potrebbe essere necessario procedere ad un upgrade della memoria dello stesso e ad una installazione
di una versione a 64bit del sistema operativo nel caso in cui le esigenze di velocità (in seguito ad un
aumento esponenziale degli utenti concorrenti) e la quantità di immagini immagazzinate diventi tale
da richiederlo, questo al momento della scrittura non è ancora avvenuto e il server è adeguatamente
dimensionato.
• Il software dovrà poter essere aggiornato con relativa facilità e potranno venir aggiunte in futuro
nuove funzioni.
13
Figura 2-
2-4.1 Diagramma logico funzionamento applicativo
14
3. Strumenti utilizzati
Di seguito verrà presentata una descrizione di tuttigli strumenti utilizzati per la progettazione, la realizzazione
e l’uso della soluzione software e le motivazioni della loro scelta.
3.2.1 SQL Server 2005 e Oracle 9i (cfr bibliografia [2])
Nel laboratorio erano già a disposizione i DBMS SQL Server 2005 nella versione standard ed una licenza
Oracle 9i Release 2 Standard la licenza Oracle era stata acquistata nell’ottica di poter utilizzare Oracle Spatial
un componente opzionale che supporta pienamente le funzionalità 3D e i Web service consentendo la
gestione di tutti i tipi di dati geospaziali, inclusi vettori, dati rasterizzati, topologie e modelli di rete, purtroppo
questa feature era disponibile solo con la versione Enterprise del DBMS e quindi non è stato possibile
sfruttarla. Valutando l'esistenza di una prima struttura del database realizzata già in SQL Server, la sua maggior
semplicità di utilizzo, la conoscenza di base, da parte di alcuni utenti del laboratorio, delle operazioni di
backup e ripristino è stato scelto di continuare ad utilizzare tale DBMS e di realizzare la base di dati
partendo dallo schema esistente.
Allo stesso tempo si è scelto di utilizzare comunque la licenza Oracle 9i verificandone la compatibilità con i
tools di sviluppo e tecnologie Microsoft, prevalenti nel laboratorio; come si vedrà anche in seguito, tale
versione di Oracle è pienamente compatibile con le API windows ed è installabile sui sistemi operativi
windows presenti.
Sulla stessa macchina di test dove è stato realizzato il prototipo è stato quindi installato il DBMS Oracle ed è
stata creata un’istanza con le stesse tabelle e relazioni presenti sulla base dati SQLServer2005, le inevitabili
differenze e si è provveduto a consultare l’ampia manualistica in dotazione per utilizzarlo come alternativa al
SQL Server 2005, il software utilizzava quindi senza soluzione di continuità il DBMS Oracle e quello SQL
Server 2005, questo ci consentiva di procedere in modo spedito al test dell’applicativo e al suo debug.
Il database Oracle può essere quindi comodamente trasferito su un’altra macchina windows oppure linux (nel
caso si scegliesse una soluzione in cui il server web e quello database fossero distinti, pratica comune
A consolidare tale scelta hanno contribuito anche la gran quantità di documentazione esistente in rete e
l'integrazione con l'ambiente di sviluppo utilizzato (Visual Studio 2005) e con il framework .NET. È infatti
molto semplice, da VS2005 creare una connessione diretta al database, importare le strutture delle tabelle nei
dataset, eseguire il debug delle stored-procedure ecc.
Per la creazione di tabelle, viste, triggers e stored procedures in MS Sql Server 2005 si è utilizzato il tool di
default Microsoft SQL Server Management Studio, mentre per quanto riguarda Oracle 9i si è acquistata una
licenza TOAD 7.2, tale applicativo consente un’agevole creazione di questi oggetti e consente di svolgere
tutta una serie di pratiche amministrative (dba) senza ricorrere all’Enterprise Manager che dovrebbe avere le
stesse funzioni del Management Studio ma che all’atto pratico presentava diversi limiti e in alcuni casi era
addirittura inferiore alla linea di comando come praticità.
L’utilizzo del DBMS Oracle ha richiesto uno sforzo ingente in ore di studio per raggiungere lo stesso livello di
dimestichezza ottenuto in precedenza con Microsoft SQL Server, la documentazione allegata e quella
facilmente reperibile da vari siti internet (ufficiali e non) ha però sopperito in maniera ottimale alla mancanza
di un training formale che sarebbe costato troppo in termini di tempo e risorse finanziarie.
Le maggiori difficoltà sono state riscontrate nelle procedure di amministrazione (dba) come la creazione
15
dell’istanza e base dati, gestione delle strutture dati e dei backup, la quantità di controllo e flessibilità
raggiungibile con questo DBMS giustificano la curva di apprendimento decisamente elevata.
2.5.2 .NET Framework e C#
Trovandoci in un ambiente Windows ed avendo già a disposizione il DBMS di casa Microsoft, non
prevedendo un porting della parte server su altri sistemi operativi, e appurata la compatibilità con il DBMS si
casa Oracle si è deciso di ricorrere all'utilizzo del Framework .NET per la realizzazione della nostra soluzione
software. Esso consente di realizzare l'applicazione utilizzando diversi linguaggi ad oggetti, permette di
ottenere prestazioni sufficienti ai nostri scopi ed offre una buona integrazione con SQL Server 2005 e Oracle
9i. Sono presenti, infatti, numerose librerie che permettono un accesso agevole alla base di dati
permettendone lo sfruttamento di tutte le potenzialità.
Per quanto riguarda Oracle, Microsoft Visual Studio 2005 consente il reperimento dei dati nativamente anche
dal DBMS Oracle e la compatibilità è assicurata dai diversi providers (Oracle Data Providers for .NET) è
inoltre possibile utilizzare l’heterogeneous services: questo componente integrato di Oracle permette ad un
DBMS della stessa casa di interfacciarsi ad un DBMS Microsoft in modo trasparente (è possibile eseguire
queries su un DBMS Microsoft semplicemente aggiungendo un parametro al nome della tabella su cui si vuole
operare). Anche la creazione di viste e procedure è aiutata notevolmente, nonostante vi siano differenze
sostanziali nella gestione del database a livello database administrator e nelle procedure di backup.
Ci sarebbe stata la possibilità dell'utilizzo della piattaforma Java, che, però non introduceva nessun vantaggio
rispetto alla soluzione da noi scelta, almeno per la logica residente al lato server. Il suo utilizzo sarebbe stato
utile nel caso della presenza di un server Linux ed eventualmente del DBMS MySql.
Il linguaggio C# è stato scelto invece per il suo completo supporto a tutte le funzioni offerte dal framework
.NET, per la sua somiglianza al già ottimo linguaggio Java, per la sua semplice rilettura e comprensione ed
infine per la gran quantità di documentazione disponibile in rete [3].
2.5.3 Visual Studio 2005
L'integrated development environment (IDE) utilizzato è stato Visual Studio 2005. Non esistendo molte
alternative che supportino a pieno la programmazione con i linguaggi del Framework .NET ed avendo già a
disposizione nel laboratorio l'IDE in questione si è deciso per il suo utilizzo.
Esso offre buone opzioni per il debug, potendo controllare a runtime il flusso del programma, i valori delle
variabili e le comunicazioni con i databases, il supporto nativo a MSSqlServer 2005 e Oracle9i ha aiutato nella
scelta.
Mentre il design delle Windows Form è agevole e intuitivo, l'organizzazione degli oggetti all'interno delle
pagine dinamiche ASP, è meno agevole risultando quindi d’impedimento alla programmazione. Purtroppo
però, avendo il bisogno di fruire del debugger del codice associato alle pagine e delle altre funzioni offerte
dall’IDE, non è stato possibile organizzare il layout tramite l’utilizzo di altri software e si è continuato ad
utilizzare quindi il Visual Studio.
16
2.5.4 Web-Service in .NET
La scelta di realizzare la nostra applicazione client–server basandosi sulla tecnologia dei Web Service è stata
dettata da numerosi fattori che verranno di seguito elencati e descritti:
• primo su tutti, la possibilità, in futuro, di sfruttare i servizi da esso offerto, anche da applicazioni
client programmate ad esempio in Java e che possono essere eseguite anche su diversi sistemi operativi come
ad esempio Linux.
Esistono, infatti, diverse applicazioni GIS per questo sistema operativo ed in tal modo non si preclude
l’utilizzo della nostra soluzione software ai soli client Windows.
• Un controllo approfondito sui messaggi scambiati tra client e server, essendo essi in formato
testuale, che consente un debugging più agevole ed approfondito.
• L'eliminazione del problema della presenza, e quindi della necessaria configurazione, di firewall
intermedi tra i due nodi, in quanto tutto il traffico transita sulla porta 80.
• Una suddivisione netta tra il lato server e client della soluzione software che permette di modificare
l'una senza dover intervenire sull'altra se non si modificano le interfacce ma soltanto la logica.
Ovviamente con l'utilizzo di tale soluzione si è incontrato anche il suo principale svantaggio, vale a dire le
prestazioni. Rispetto ad una soluzione classica, infatti, le velocità di risposta del software nelle transazioni
client-server, sono più basse. Nel nostro caso però esse non hanno pesato eccessivamente sul lavoro
complessivo svolto dall'applicazione, permettendo, ad ogni modo, all'utente di operare senza percepire gravi
limitazioni. Un tipo di comunicazione classica tra client e server avrebbe garantito sicuramente velocità
maggiori, togliendo però modularità e adattabilità all’applicazione.
2.5.4.1 WSE 3.0
Le Web Services Enhancements (WSE) [4], sin dalla loro prima versione, sono state pensate come un
prodotto volto a migliorare lo sviluppo dei web service rendendoli sempre più avanzati e più semplici da
realizzare. I web service con il tempo si sono evoluti tramite il miglioramento continuo dei protocolli WS-*
che continua tuttora con l'obbiettivo di offrire maggior sicurezza, affidabilità e performance delle
comunicazioni.
Nelle WSE 3.0, che sono state utilizzate per lo sviluppo di questa soluzione software, è presente il nuovo
Message Transmission Optimization Mechanism (MTOM) che definisce la "Transmission Optimization" e
rimpiazza il precedente sistema DIME e le WS-Attachments. Esso introduce tre principali migliorie:
• riguardanti la sicurezza: ora gli allegati rispondono alle WS-Security tanto quanto i messaggi,
cosa che non accadeva con il DIME dove bisognava ricorrere ad una connessione SSL
affinché il contenuto degli allegati non potesse venir letto in chiaro.
17
• Con MTOM i dati sono trasmessi come un allegato MIME, ma mentre sino ad ora, per poter
fare ciò, era necessario ricorrere alla codifica base64 che causa un aumento delle dimensioni
dei dati originali attorno al 33%, al fine di utilizzare solamente i caratteri consentiti dalle
specifiche XML 1.0, ora con la nuova decodifica MTOM ciò non accade riducendo quindi la
richiesta di larghezza di banda.
• Infine, con l’utilizzo di MTOM non è più necessario, come in DIME, creare un allegato
separato da unire al messaggio SOAP. Basterà configurare il servizio web per il supporto a
MTOM e tutti i valori di tipo byte[] scambiati con i client, saranno automaticamente
codificati tramite esso.
Nella nostra applicazione tutto ciò è risultato molto utile per il trasferimento dei file delle immagini. Sarebbe
stato infatti impossibile utilizzare la normale codifica base64 che avrebbe portato ad un allungamento estremo
dei tempi di trasferimento rendendo di fatto inutilizzabile l'applicazione.
2.5.5 IIS
L’applicazione scelta per eseguire la funzione di server web è stata Internet Information Services (IIS) di
Microsoft.
Anch'essa è infatti ben integrata con il pacchetto Visual Studio, Framework .NET e SQL Server. L'unica
alternativa risultava essere il web server Apache, compatibile dalla versione 2.0 anche con il Framework
.NET, ma nato principalmente per l'utilizzo su macchine Linux dove può essere utilizzato al pieno delle sue
potenzialità, Apache viene fornito di serie nelle distribuzioni Linux e anche nei cd di installazione di Oracle9i,
facendo parte della release Standard e deselezionabile nel processo di installazione, nel nostro caso non lo si è
installato per non creare conflitti di occupazione di porte.
IIS viene fornito assieme al sistema operativo Windows XP Professional ed offre la possibilità di installare,
senza troppe difficoltà, anche un server di posta utilizzato nel nostro caso per la ricezione delle richieste
d’immagini da parte degli utenti di una rete esterna.
Riguardo a questo, al fine di garantire un buon livello di sicurezza, sarà necessaria un'accurata configurazione
dei privilegi d’accesso nel sistema finale ed eventualmente una suddivisione del servizio web in due sezioni
distinte: una destinata a servire la sola rete interna che offra tutti servizi disponibili e l'altra
limitata ai soli servizi di consultazione da rendere fruibili dall’esterno.
2.5.6 UML per la progettazione del Database e del Software
L'ultimo strumento presentato è il linguaggio UML. Esso fornisce un ottimo aiuto alla corretta progettazione
dei software e dei database, ma anche allo studio dei modelli di risoluzione dei problemi reali ecc. Mette a
disposizione, infatti, numerosi oggetti grafici utili a rappresentare tutte le componenti del software al fine di
organizzarlo e progettarlo nel modo migliore.
I grafici UML mostrano maggiormente la loro utilità qualora le persone coinvolte nella realizzazione della
soluzione software siano due o più. In tal caso è necessario, infatti, conoscere il lavoro svolto dagli altri
18
componenti e come esso s’integra con il nostro conoscendone i metodi e le interfacce esposte. Nel nostro
caso, nonostante non esista un team di sviluppo ma il lavoro sia svolto totalmente da una sola persona,
l'UML offre comunque alcuni importanti vantaggi che ora verranno elencati:
• una visione d'insieme dell'applicazione e del database, rapportata alla situazione reale, utile ad
organizzare le idee in fase di progettazione e a verificarne la completezza.
• Verifica della presenza, nella logica del software, di tutti i metodi d’accesso alla base di dati necessari.
• Possibilità di esporre in modo più semplice al committente, attraverso i diagrammi del database o dei
workflow della logica, le intenzioni sul proseguimento della programmazione e l'organizzazione dei
dati.
• Consente di esporre in modo più veloce e diretto il lavoro svolto, mettendo in luce i legami tra le
classi implementate o le tabelle del database, rendendone più immediata la comprensione.
2.6 Architettura della soluzione software
L'applicazione è suddivisa principalmente in tre parti: la base di dati, i servizi web e le interfacce. Si vedrà ora
quindi una breve descrizione delle strategie usate per la loro progettazione, organizzazione e realizzazione.
2.6.1 Database
Il database relazionale è stato realizzato con uno schema a stella. Partendo infatti dal tipo di dati da gestire sono
state analizzate le relazioni tra le varie entità, passando poi alla creazione di uno schema logico, per finire con
la progettazione fisica.
Sono state quindi implementate alcune funzioni interne alla base di dati, come alcuni trigger e user defined
function. Inoltre sono state create diverse viste allo scopo di presentare i risultati di una query all'utente.
Per interfacciare infine il database con la logica dell'applicazione sono state implementate tutte le stored
procedure necessarie all'inserimento, la modifica e la ricerca dei dati.
Nella creazione del database sono state prese in considerazione le differenze intrinseche ai due DBMS e si è
cercato di sfruttare al meglio i punti di forza di questi ultimi, un considerevole sforzo è andato nello studio
delle attività di amministrazione e gestione di Oracle 9i (utilizzo della memoria di sistema, occupazione e
gestione dei file di dati, procedure di backup), per quanto riguarda MSSql Server la quantità di lavoro per le
stesse procedure è risultata inferiore in quanto attività già studiate in corsi universitari o rese più agevoli
19
2.6.2 Servizi Web
La parte dei servizi Web è stata suddivisa al suo interno in due progetti principali: una libreria dedicata
all'accesso al database, all'elaborazione dei risultati ecc. ed un secondo progetto dedicato solamente alla
pubblicazione dei servizi che sfrutta la libreria per ottenere i risultati da pubblicare.
Tutti i metodi esposti dal servizio web sono fortemente tipizzati, ricevendo in ingresso e restituendo
solamente dati contenuti in istanze d’oggetti opportuni. Ciò evita di poter inviare in input ai metodi tipi di
dati non esatti e di non conoscere il formato della risposta della funzione richiamata. Affinché ciò funzioni i
tipi in ingresso ed in uscita dei metodi devono poter essere serializzati e quindi dovranno avere le variabili
membro pubbliche ed un costruttore di default. Bisogna infatti considerare che tali dati dovranno essere
tradotti in formato XML per effettuare il tragitto client server e dovranno quindi contenere sostanzialmente i
soli dati.
Al fine di ridurre il numero d’accessi al database, per alcuni insiemi di valori che vengono aggiornati con
frequenza molto bassa, vengono creati, nel web server, dei file XML contenenti tali dati. Ciò permette, al
momento della richiesta, di evitare l'accesso al database e ricorrere semplicemente alla lettura dei file XML.
È stato utilizzato inoltre un dataset all'interno della libreria al fine di poter organizzare i dati operando su
questa cache evitando nuovi accessi alla base di dati.
2.6.3 Interfacce GUI
Le interfacce sono principalmente due: una realizzata con le Windows Form ed una in ASP. La prima è stata
realizzata in due varianti, una come applicazione a sé stante ed una come plug-in di ArcGis direttamente
attivabile dal suo interno. Nell'interfaccia realizzata in Windows Form sono presenti tre sezioni principali: una
per l'inserimento delle immagini, una per la consultazione ed un’ultima per la
manutenzione. L'interfaccia ASP invece prevede la sola consultazione.
La fase d’inserimento è stata strutturata come Wizard sia per motivi tecnici sia per consentire una suddivisione
logica dell'inserimento dei dettagli e permettere la correzione immediata degli eventuali errori.
L'amministrazione consente la modifica di tutti i dati delle immagini inserite e l'aggiunta, modifica e
rimozione delle informazioni contenute nelle lookup table.
La ricerca infine consente di filtrare i risultati attraverso l'inserimento di parametri multipli e la selezione su di
una carta delle zone interessate. In tutti i casi si è fatto uso dei dataset al fine di poter lavorare sempre in
modalità disconnessa.
20
3. Progettazione e realizzazione
Viene trattata, in questo capitolo, la progettazione e la realizzazione delle componenti della soluzione
software. In questa fase, partendo dai dati ottenuti dal processo d’analisi, viene data forma ai moduli
componenti l’intera applicazione. Si parte dal database, per passare poi alla logica del Web Service e finire
quindi con le interfacce GUI.
3.1 Progettazione e realizzazione del Database
In questo capitolo sono esposte tutte le componenti della base di dati come le tabelle, le loro relazioni, le viste
e la logica d’accesso. Infine sarà illustrata anche la gerarchia di queste parti evidenziando le interfacce d’accesso
per la fruizione della base di dati.
Il punto di partenza per la realizzazione della struttura del database è lo schema entity-relationship di Figura
3-1 che evidenzia le componenti in gioco e le loro principali relazioni.
Figura 3-
3- 1
21
Partendo da questa base è stata studiata la migliore realizzazione delle entità disponibili, scomponendo le
informazioni contenute al loro interno al fine di raggiungere almeno la terza forma normale.
In seguito, dopo aver realizzato le tabelle e il loro schema relazionale, sono stati analizzati tutti i possibili tipi
di accesso alla base di dati e sono stati creati quindi i trigger, le viste e le stored procedure.
La creazione di questi elementi è avvenuta in parallelo su MS Sql Server 2005 e Oracle9i, nel primo caso si è
utilizzato nella totalità dei casi il Management Studio di Microsoft, mentre nel secondo caso si sono utilizzati
Toad 7.2 e l’Oracle Enterprise Manager (perlopiù nella creazione del db e per la gestione della memoria e file
di dati).
Figura 3-
3-1.2 (Microsoft Sql Server Management Studio)
Figura 3-
3-1.3 (Oracle 9i Enterprise Manager)
22
3.1.1 Tabelle
Considerando le tabelle periferiche alla base di dati, s’inizia con la struttura dell’immagine che, nel nostro caso,
potrà essere vettoriale o raster. In un futuro utilizzo, però, potrà presentarsi la necessità di gestire immagini a
struttura mista raster e vettoriale. In tal caso basterà aggiungere quest’ultima alle strutture esistenti, nel seguito
saranno mostrate le strutture delle tabelle, identiche per tutti e due i DBMS (cambieranno le nomenclature dei
datatypes ma non la struttura).
La tabella si presenta quindi come in Figura 3-2:
Figura 3-
3- 2
Abbiamo una chiave primaria costituita da un identificativo numerico, questo è stato realizzato in
MSSQLServer con la funzione autonumber e in Oracle con una sequenza e un trigger, ) e due campi testo
che descrivono il tipo di struttura e una sua eventuale descrizione.
Passiamo ora alla tabella delle proiezioni utilizzate per rappresentare le immagini.
Anche in questo caso ne potremmo incontrare di diversi tipi ed è necessario quindi poterli descrivere con
sufficiente dettaglio. In Figura 3-3 vediamo la struttura della tabella:
Figura 3-
3- 3
Oltre all’identificativo, al tipo e alla descrizione, si può osservare il campo “Codice_EPSG”. Esso è volto a
contenere un codice che identifica univocamente un tipo di proiezione. L’EPSG[5]
(European Petroleum Survey Group http://www.epsg.org/) fornisce, infatti, una tabella contenente tutte le
proiezioni geografiche esistenti associandole ad un codice identificativo. Tale campo è quindi di
grand’utilità in caso si ricerchino immagini rappresentate tramite l’utilizzo di una ben determinata proiezione
presente nelle tabelle EPSG. Non si è utilizzato tale codice come chiave primaria della tabella, per il fatto che
alcune immagini potrebbero non essere proiettate o avere caratteristiche di proiezioni diverse da quelle
presenti nei listati EPSG; si conserva in tal modo una maggiore adattabilità a situazioni particolari non
prevedibili durante le fasi di realizzazione.
La tabella seguente rappresenta le estensioni dei file dell’immagine caricata. Esistono, infatti, numerosi software
d’elaborazione d’immagini che consentono il loro salvataggio in altrettanti numerosi formati. In Figura 3-4
vediamo la struttura della tabella:
23
Figura 3-
3- 4
Anche in questo caso ritroviamo un identificatore come chiave primaria, un tipo d’estensione che conterrà
sostanzialmente la sigla del formato digitale e una sua descrizione dove potrà essere specificato ad esempio il
programma utilizzato per la creazione.
La tabella delle correzioni che possiamo vedere in Figura 3-5 contiene i dati riguardanti gli interventi eseguiti
sulle immagini per ottenerne informazioni più chiare.
Un esempio può essere la correzione atmosferica che cerca, nei limiti del possibile, di eliminare il rumore
introdotto dalla riflessione e diffusione della luce durante l’attraversamento degli strati di gas presenti attorno
alla terra.
Figura 3-
3- 5
Anche in questo caso potremo inserire, oltre al tipo di correzione, una sua descrizione.
Passando alla tabella riguardante i sensori visibile in Figura 3-6 si possono notare al suo interno diversi campi
che ora andiamo a descrivere. Possiamo indicare una denominazione del sensore in oggetto, una descrizione
dell’orbita mantenuta dal satellite sul quale il sensore è installato ed un’altezza da terra alla quale esso si trova.
Inoltre si possono indicare una data di lancio in orbita del sensore, delle eventuali altre informazioni ed infine
il nome del satellite sul quale esso è installato.
Figura 3-
3- 6
Per la descrizione delle fonti, che indicano la provenienza dell’immagine, è stata realizzata la tabella in Figura
3-7.
Figura 3-
3- 7
Anche in questo caso è possibile inserire tutti i dati necessari ad identificare la fonte come un tipo, una
descrizione, l’eventuale sito Web ed altre informazioni.
24
Discorso analogo anche per la tabella dei riferimenti in Figura 3-8. Al suo interno, oltre al tipo ed alla
descrizione può venir definita una scala (dove per indicare ad esempio 1:5000 basterà inserire il valore
numerico 5000) utile per conoscere le dimensioni dell’immagine di riferimento utilizzata.
Figura 3-
3- 8
Nella tabella degli studi in Figura 3-9 può essere descritto il tipo di studio, il suo titolo, un riassunto ed infine
il file dell’articolo completo. In questo campo è memorizzato il percorso nel quale il file dello studio viene
archiviato.
Figura 3-
3- 9
Nella tabella degli autori degli studi in Figura 3-10 l’utente può memorizzare tutti i dati anagrafici necessari
all’identificazione della persona.
Figura 3-
3-10
Questi possono essere, oltre al nome e cognome, il suo titolo, un recapito, un numero di telefono e fax ed
infine un indirizzo E-Mail.
Poiché ogni studio può esser stato redatto da diversi autori e su ogni immagine possono esser stati eseguiti
numerosi studi, sono state create due tabelle che consentono l’immissione di questa combinazione di dati.
Possiamo osservare le due tabelle in Figura 3-11
Figura 3-
3-11
Si nota, nella tabella di sponda tra studi ed immagini, il campo “Id_Immagine” che non abbiamo ancora visto
in nessuna tabella. Esso è, infatti, la chiave primaria della tabella centrale del nostro database che descrive una
singola immagine. Possiamo vedere i suoi campi in Figura 3-12
25
Figura 3-
3-12
Al suo interno risiedono le chiavi esterne d’alcune tabelle già descritte come quella dei sensori, della
proiezione, della struttura della fonte e del riferimento. È possibile inserire una data di acquisizione
dell’immagine e, automaticamente, verrà memorizzata anche una data del suo inserimento nel database. Gli
ultimi quattro campi descrivono le coordinate espresse in gradi decimali dei margini dell’immagine.
Il campo “Id_File” è una chiave esterna riferita alla tabella del file dell’immagine.
Possiamo vederla in Figura 3-13.
Figura 3-
3-13
Qui è possibile inserire una descrizione dell’immagine, il nome dell’archivio con estensione ZIP (contenente
al suo interno tutti i file dell’immagine) che comprende anche il percorso dove esso risiede nel filesystem e la
dimensione espressa in byte.
Nel campo “CRC_File” viene salvata una stringa di hash creata con l’utilizzo dell’algoritmo MD5 al fine di
verificare, dopo un trasferimento dell’immagine, la sua consistenza evitando quindi di consegnare all’utente
file corrotti. Il campo “Id_Estensione” è chiave esterna riferita alla tabella delle estensioni e il campo
dell’anteprima contiene il percorso di salvataggio dell’immagine in formato JPEG.
Un’altra tabella di sponda è quella concernente le correzioni. Essendo possibile, infatti, eseguire diversi tipi di
correzioni su di un’immagine è stata creata la tabella in Figura 3-14 per assolvere questo compito.
Figura 3-
3-14
Una tabella di grande importanza è quella relativa alle bande dei sensori che possiamo vedere in Figura 3-15.
Si possono osservare gli attributi assegnabili ad ogni singola banda come il nome, una descrizione, la
risoluzione radiometrica, la dimensione di un singolo pixel e l’inizio e la fine dell’intervallo spettrale.
Troviamo anche la chiave esterna del sensore in quanto, come si è già visto nel capitolo dedicato alla
descrizione delle immagini, ognuno di questi presenta un numero ben determinato di bande.
26
Figura 3-
3-15
La tabella in Figura 3-16 è volta a contenere i nomi dei layer dell’immagine. Mentre nelle immagini acquisite
con lo scanner si avranno solitamente i tre layer uno per ogni colore primario (R, G, B), nelle immagini
satellitari si troveranno tanti layer quante saranno le bande utilizzate.
Figura 3-
3-16
Nel caso d’immagini vettoriali, o di particolari elaborazioni di bande d’immagini satellitari, potremmo trovare
un tematismo associato ad un layer. Questo è il caso, ad esempio, d’immagini DEM (Digital Elevation
Models) o elaborazioni NDVI (Normalized Difference Vegetation Index) ecc.. È stata quindi implementata la
tabella di Figura 3-17 nella quale notiamo i campi del nome, della descrizione e delle informazioni
riguardanti il tematismo.
Figura 3-
3-17
La tabella che consente di associare ad una singola immagine una o più bande, layer e tematismi è la tabella di
sponda “tblSp_Bande” di Figura 3-18. In questa troviamo anche un altro campo necessario ad indicare la
risoluzione del layer nel caso esso sia stato ricampionato con una definizione diversa da quella originariamente
offerta dalla banda del satellite.
Figura 3-
3- 1 8
L’ultima tabella che analizziamo è quella riguardante le zone utilizzate per raggruppare geograficamente le
immagini memorizzate. Essa è tratta direttamente dal database EPSG e possiamo vederne i campi in Figura 3-
19. Al suo interno risiede l’elenco di tutti gli stati del mondo e le coordinate di questi.
27
Figura 3-
3-19
Oltre al codice dell’area, utilizzato come chiave primaria, troviamo il nome dell’area, la zona nella quale esso è
utilizzato, ulteriori sue informazioni, tre tipi di codici ISO riguardanti l’area specifica e l’indicazione se si tratti
o no di un’area non più esistente (nel caso d’unioni di più stati sotto un unico nome o la suddivisione in più
frazioni). Come ultimo campo troviamo la sottoarea. Essa è stata aggiunta alla tabella originale al fine di poter
inserire delle sottoaree d’interesse specifico, che si trovano all’interno di uno stato (come ad esempio una
regione o una provincia). In tal caso al suo interno sarà indicato l’”AREA_CODE” del quale tale zona è
sottoarea.
28
3.1.2 Relazioni
Vengono ora analizzate le relazioni create tra le tabelle presentate nel capitolo precedente. In Figura 3-20 si
può osservare una rappresentazione grafica di tutte le relazioni esistenti questa rappresentazione grafica si
applica indistintamente alla base dati MS Sql Server e a quella Oracle9i.
Figura 3-
3-20
29
Partendo dalla tabella principale “tblImmagini” si vede come essa presenti al suo interno diverse chiavi
esterne che legano, con relazioni “uno a molti”, le tabelle rappresentanti le principali caratteristiche
dell’immagine.
Si osserva, infatti, come ad ogni record della “tblImmagini” possano essere associati i diversi record delle
seguenti tabelle:
• tblFile
• tblSensori
• tblProiezioni
• tblStrutture
• tblFonti
• tblRiferimenti
A sua volta la “tblFile” presenta una chiave esterna per associare, sempre in una relazione “uno a molti”, ad
ogni suo record un’estensione della tabella “tblEstensioni”.
Al fine di poter far corrispondere ad una singola immagine più correzioni, all’interno della tabella
“tblSp_Correzioni” trovano posto le due chiavi esterne, quella della “tblImmagini” e quella della
“tblCorrezioni” per realizzare una relazione “molti a molti”.
Altre due relazioni “molti a molti” si trovano tra le tabelle “tblStudi” e “tblImmagini” e tra “tblStudi” e
“tblAutori” ed anche in questo caso sono state create le due tabelle di collegamento “tblSp_StudiImmagini” e
“tblSp_StudiAutori”.
Per quanto concerne le bande troviamo una tabella di congiunzione “tblSp_Bande” che permette, sempre con
una relazione di tipo “molti a molti”, di associare ad un’immagine più bande rappresentate in un determinato
layer con una certa risoluzione ed eventualmente con la specificazione di un tematismo.
Infine, poiché ogni sensore ha un ben determinato numero di bande aventi delle caratteristiche specifiche, la
tabella “tblBande” presenta la chiave esterna per esser messa in relazione (del tipo “uno a molti”) alla
“tblSensori”.
30
3.1.3 Viste
Durante la fase di progettazione è apparso necessario ottenere dati provenienti da diverse tabelle
contemporaneamente ed è stato utile realizzare quindi alcune viste.
Qui sotto le elencheremo, entrando nel dettaglio di quella più significativa e con più campi: la
VistaRisultatiImm.
• VistaBande
• VistaCorrezioni
• VistaStudi
• VistaAutoriStudio
• VistaZoneRic
• VistaRiepilogo
• VistaRisultatiImm
La vista in questione, visualizzata qui sotto in Figura 3-21, Questa vista comprende più campi relativi alle sole
tabelle immediatamente collegate alla tblImmagini. Ciò significa che non sono rappresentati, tramite essa, i
dati collegati attraverso le tabelle di sponda. Il suo utilizzo principale avviene nelle fasi di ricerca e di modifica
dei dati immessi.
Con il suo utilizzo, infatti, è possibile eseguire ricerche senza la necessità di accedere a numerose tabelle e,
tranne nel caso delle operazioni d’amministrazione, i dati da essa ottenuti non percorrono il tragitto client-
server che risulta, a causa delle numerose informazioni da trasferire, molto oneroso in termini d’occupazione
di banda. La vista, infatti, è acceduta solamente dalla parte server dell’applicazione per eseguire ricerche a più
parametri.
Durante le fasi d’amministrazione invece, tale vista fornisce gran parte delle informazioni modificabili
dall’utente dopo l’inserimento dell’immagine. La quantitàdi dati trasferiti in rete, durante tale operazione, è in
ogni caso esigua, in quanto vengono trasferiti i dati relativi ad un solo record alla volta.
31
Figura 3-
3-21
32
3.1.4 Stored Procedures e User Defined Functions
Per accedere al database sono state create numerose stored procedures checontengono tutti i comandi sql
necessari ad inserire, ottenere e modificare i datiregistrati.
Le stored procedures d’inserimento sono le seguenti:
• AddAutore
• AddBanda
• AddCorrezione
• AddEstensione
• AddFile
• AddFonte
• AddLayer
• AddProiezione
• AddRiferimento
• AddSensore
• AddSpondaAutoriStudio
• AddSpondaBande
• AddSpondaCorrezioni
• AddSpondaStudi
• AddStruttura
• AddStudio
• AddTematismo
• AddZona
Il codice sql d’inserimento dei dati di alcune di esse è simile e qui ne viene fornito un esempio in formato T-
SQL, La sintassi per Oracle è leggermente diversa ma non ne cambia il funzionamento:
1 PROCEDURE [dbo].[AddFonte]
2 @Tipo_Fonte NVARCHAR(60),
3 @Descrizione_Fonte NVARCHAR(150),
33
4 @Sito_Fonte NVARCHAR(150),
5 @Informazioni_Fonte NVARCHAR(200)
6 AS
7 BEGIN
8 SET NOCOUNT ON;
9 INSERT INTO [tblFonti]
10 ([Tipo_Fonte],[Descrizione_Fonte],[Sito_Fonte],[Informazioni_Fonte]) VALUES
11 (@Tipo_Fonte,@Descrizione_Fonte,@Sito_Fonte,@Informazioni_Fonte)
12 RETURN
13 END
Vengono in questo caso richiesti dei parametri d’ingresso ed eseguito quindi ilcomando d’inserimento. Al suo
completamento viene restituito un codice d’uscitache conferma l’avvenuto inserimento con il valore 0 od un
eventuale errored’esecuzione con un valore diverso da 0.
Tre di queste stored procedures d’inserimento (la AddStudio, AddSensore e AddFile)restituiscono anche un
altro tipo di valore e vale a dire quello della chiave primariadel record appena inserito. Vediamo di seguito
l’esempio della “AddStudio”:
1 PROCEDURE [dbo].[AddStudio]
2 @Tipo_Studio NVARCHAR(80),
3 @Titolo_Studio NVARCHAR(MAX),
4 @Abstract_Studio NVARCHAR(MAX),
5 @File_Studio NVARCHAR(MAX),
6 @Id_Studio BIGINT OUTPUT
7 AS
8 BEGIN
9 SET NOCOUNT ON
10 INSERT INTO [tblStudi]
11 (Tipo_Studio,Titolo_Studio,Abstract_Studio,File_Studio)VALUES(@Tipo_Studio,
12 @Titolo_Studio,@Abstract_Studio,@File_Studio)
13 SELECT @Id_Studio= SCOPE_IDENTITY()
14 RETURN @Id_Studio
15 RETURN
16 END
Nella riga 13 si nota il comando “SCOPE_IDENTITY” che ha proprio la funzione direstituire il valore della
chiave primaria appena inserita nell’ambito della storedprocedure correntemente in esecuzione. In tal modo
viene assicurato che, in presenzadi un altro accesso contemporaneo in inserimento, non venga restituito al
chiamanteun identificativo errato creato in un’altra sessione.
Le stored procedure realizzate ed utilizzate per rimuovere dei record dalle tabellesono le seguenti:
• RemoveAutore
• RemoveBanda
• RemoveCorrezione
• RemoveEstensione
• RemoveFonte
• RemoveImmagine
• RemoveProiezione
• RemoveRiferimento
• RemoveSensore
34
• RemoveSpondaAutoriStudio
• RemoveSpondaBande
• RemoveSpondaCorrezioni
• RemoveSpondaStudi
• RemoveStudio
• RemoveTematismo
• RemoveZona
Il codice sql all’interno di ognuna di queste stored procedure è molto semplice esostanzialmente identico.
Vediamo l’esempio della “RemoveFonte”:
1 PROCEDURE [dbo].[RemoveFonte]
2 @Id_Fonte BIGINT
3 AS
4 BEGIN
5 SET NOCOUNT ON;
6 DELETE FROM tblFonti WHERE Id_Fonte=@Id_Fonte
7 RETURN
8 END
Le stored procedure utilizzate invece per l’aggiornamento dei dati contenuti nelletabelle sono le seguenti:
• UpdateAutore
• UpdateBanda
• UpdateCorrezione
• UpdateEstensione
• UpdateFile
• UpdateFonte
• UpdateImmagine
• UpdateProiezione
• UpdateRiferimento
• UpdateSensore
• UpdateSpondaBande
• UpdateSpondaCorrezioni
• UpdateStudio
35
• UpdateTematismo
• UpdateZona
Anche in questo caso, come nel precedente, il codice sql delle stored procedurerisulta essere analogo per tutte.
Vediamo sempre l’esempio dell’UpdateFonte:
1 PROCEDURE [dbo].[RemoveFonte]
2 @Id_Fonte BIGINT,
3 @Tipo_Fonte NVARCHAR(60),
4 @Descrizione_Fonte NVARCHAR(150),
5 @Sito_Fonte NVARCHAR(150),
6 @Informazioni_Fonte NVARCHAR(200)
7 AS
8 BEGIN
9 SET NOCOUNT ON;
10 UPDATE tblFonti SET Id_Fonte=@Id_Fonte, Tipo_Fonte=@Tipo_Fonte,
11 Descrizione_Fonte=@Descrizione_Fonte, Sito_Fonte=@Sito_Fonte,
12 Informazioni_Fonte=@Informazioni_Fonte WHERE Id_Fonte=@Id_Fonte
13 RETURN
14 END
Il reperimento di tutti i dati contenuti in una determinata tabella avviene, da partedell’applicazione, con i
metodi già offerti dai dataset che vedremo successivamente.
Nei casi in cui, invece, sia necessaria un’estrazione particolare dei dati, sono staterealizzate delle apposite
stored procedure:
• GetCoordinateZona
• GetFileAntName
• GetFileStudioName
• GetImmagineNextID
• GetStudioNextID
La prima di esse “GetCoordinateZona” recupera dalla tabella tblZoneNuove lecoordinate di un’area specifica
e le restituisce nel formato VARCHAR. Essacomprende al suo interno i seguenti comandi sql:
1 PROCEDURE [dbo].[GetCoordinateZona]
2 @AREA_CODE BIGINT,
3 @EAST VARCHAR(8) OUTPUT,
4 @NORTH VARCHAR(8) OUTPUT,
5 @SOUTH VARCHAR(8) OUTPUT,
6 @WEST VARCHAR(8) OUTPUT
7 AS
8 BEGIN
9 DECLARE @AREA_EAST_BOUND_LON FLOAT
10 DECLARE @AREA_NORTH_BOUND_LAT FLOAT
11 DECLARE @AREA_SOUTH_BOUND_LAT FLOAT
12 DECLARE @AREA_WEST_BOUND_LON FLOAT
13 SET NOCOUNT ON;
14 SELECT @AREA_EAST_BOUND_LON = AREA_EAST_BOUND_LON, @AREA_NORTH_BOUND_LAT =
15 AREA_NORTH_BOUND_LAT, @AREA_SOUTH_BOUND_LAT = AREA_SOUTH_BOUND_LAT,
16 @AREA_WEST_BOUND_LON = AREA_WEST_BOUND_LON FROM tblZoneNuove WHERE (AREA_CODE
17 = @AREA_CODE)
18 SELECT @EAST = dbo.FloatToVarCharDec(@AREA_EAST_BOUND_LON)
36
19 SELECT @NORTH = dbo.FloatToVarCharDec(@AREA_NORTH_BOUND_LAT)
20 SELECT @SOUTH = dbo.FloatToVarCharDec(@AREA_SOUTH_BOUND_LAT)
21 SELECT @WEST = dbo.FloatToVarCharDec(@AREA_WEST_BOUND_LON)
22 RETURN
23 END
Da riga 18 a riga 21 si nota l’utilizzo della user defined function“FloatToVarCharDec”. Essa è utilizzata al fine
di ottenere una trasformazione deivalori di tipo FLAOT in entrata in valori di tipo VARCHAR. Il codice di
questafunzione è rappresentato di seguito:
1 FUNCTION [dbo].[FloatToVarCharDec]
2 (
3 @ValoreCorrente AS FLOAT
4 )
5 RETURNS VARCHAR(8)
6 AS
7 BEGIN
8 DECLARE @Ret VARCHAR(8)
9 DECLARE @Decimal DECIMAL(6,3)
10 SELECT @Decimal = CONVERT(DECIMAL(6,3),@ValoreCorrente)
11 SELECT @Ret = CONVERT(VARCHAR(8),@Decimal)
12 RETURN @Ret
13 END
Le due stored procedure “GetFileAntName” e “GetFileStudioName” sono simili e restituiscono al

richiedente i campi contenenti i nomi dei file nei quali sono statesalvate le immagini, le loro anteprime o i file
di studio. Di seguito vediamo il codicedella “GetFileAntName”:
1 PROCEDURE [dbo].[GetFileAntName]
2 @Id_Immagine BIGINT,
3 @Nome_File NVARCHAR(4000) OUTPUT,
4 @Anteprima_File NVARCHAR(4000) OUTPUT
5 AS
6 BEGIN
7 SET NOCOUNT ON;
8 DECLARE @Id_File BIGINT
9 SELECT @Id_File = Id_File FROM dbo.tblImmagini WHERE Id_Immagine=@Id_Immagine
10 SELECT @Nome_File = Nome_File FROM dbo.tblFiles WHERE Id_File=@Id_File
11 SELECT @Anteprima_File = Anteprima_File FROM dbo.tblFiles WHERE
12 Id_File=@Id_File
13 END
Le altre due procedure “GetImmagineNextID” e “GetStudioNextID” restituisconoinvece il successivo

identificativo della chiave primaria della tabella in oggetto. Taleprocedura è utilizzata solamente per
modificare i nomi dei file delle immagini al finedi poter in seguito identificarli nella cartella di salvataggio in
modo più semplice. Diseguito il codice della procedura:
1 PROCEDURE [dbo].[GetImmagineNextID]
2 @Id_Immagine BIGINT OUTPUT
3 AS
4 BEGIN
5 SET NOCOUNT ON;
6 SELECT @Id_Immagine = MAX(Id_Immagine)+1 FROM dbo.tblImmagini
7 RETURN @Id_Immagine
8 END
Il valore restituito è il numero dell’identificativo di chiave primaria che sarà

impostato nel prossimo record creato in quanto esso è di tipo auto-incrementale.
37
3.1.5 Trigger
Ad alcune tabelle della base di dati, sono state associate delle funzioni trigger, in corrispondenza d’alcune fasi
d’inserimento rimozione o aggiornamento dei dati.
All’evento INSERT della tabella “tblFiles” viene scatenato il trigger “TriggerFileInsert” del quale di seguito
vediamo il codice:
1 TRIGGER [dbo].[TriggerFileInsert]
2 ON [dbo].[tblFiles]
3 AFTER INSERT
4 AS
5 BEGIN
6 SET NOCOUNT ON;
7 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
8 BEGIN TRANSACTION
10 DECLARE @Id_Immagine BIGINT
11 SELECT @Id_File = Id_File FROM inserted
12 SELECT @Id_Immagine = MAX(Id_Immagine) FROM tblImmagini
13 IF @Id_Immagine IS NULL SET @Id_Immagine=1
14 SET @Id_Immagine=@Id_Immagine+1
15 INSERT INTO tblImmagini ([Id_Immagine],[Id_File]) VALUES
16 (@Id_Immagine,@Id_File)
17 COMMIT TRANSACTION
18 RETURN
19 END
Poiché all’inserimento di un record nella tabella “tblFiles” deve corrispondere lacreazione di un record nella
“tblImmagini” questo trigger si occupa di eseguire talecompito evitando che altri accessi al database
modifichino, durante la transazione, idati da essa utilizzati. A tale scopo a riga 7 vediamo l’impostazione
dell’isolamentodella transazione che assicura che l’”Id_Immagine” letto a riga 12 non venga
modificato prima di giungere alla riga 15.
La “tblImmagini” presenta altri due trigger “TriggerImmagineDelete” e“TriggerImmSensore”. Il primo si
scatena alla richiesta di cancellazione di un recorde, poiché la chiave primaria della “tblImmagini” è presente
come chiave esterna in diverse tabelle di collegamento, il trigger deve provvedere ad eliminare tutti i record
nei quali è presente l’identificativo del record da eliminare. Il codice è rappresentatodi seguito:
1 TRIGGER [dbo].[TriggerImmagineDelete]
2 ON [dbo].[tblImmagini]
3 INSTEAD OF DELETE
4 AS
5 BEGIN
6 SET NOCOUNT ON;
7 DECLARE @Id_Immagine BIGINT
8 SELECT @Id_Immagine = Id_Immagine FROM deleted
10 DELETE FROM dbo.tblSp_Bande WHERE Id_Immagine=@Id_Immagine
11 DELETE FROM dbo.tblSp_StudiImmagini WHERE Id_Immagine=@Id_Immagine
12 DELETE FROM dbo.tblSp_Correzioni WHERE Id_Immagine=@Id_Immagine
13 SELECT @Id_File = Id_File FROM deleted
14 DELETE FROM dbo.tblImmagini WHERE Id_Immagine = @Id_Immagine
15 DELETE FROM dbo.tblFiles WHERE Id_File=@Id_File
16 RETURN
17 END
Come si vede dal codice, viene preso l’”Id_Immagine” del record da eliminare, vieneeliminato qualsiasi
record eventualmente presente nelle tabelle di sponda“tblSp_Bande”, “tblSp_StudiImmagini” e
38
“tblSp_Correzioni”, infine vienerecuperato l’“Id_File”, eliminato il record nella “tblImmagini” ed infine
quello nella“tblFiles”.
Il trigger “TriggerImmSensore” invece, è richiamato durante la fase d’aggiornamentodella tabella
“tblImmagini”. Esso ha il compito di riempire la tabella di sponda dellebande con quelle associate al sensore
selezionato durante le fasi d’inserimento. InFigura 3-22 è visibile un diagramma del funzionamento del
trigger.
Figura 3-
3-22
Il codice è invece il seguente:
1 TRIGGER [dbo].[TriggerImmSensore]
2 ON [dbo].[tblImmagini]
3 AFTER UPDATE
4 AS
5 BEGIN
6 SET NOCOUNT ON;
7 DECLARE @IDIMMAGINE NVARCHAR(20)
8 DECLARE @IDSENSORE NVARCHAR(20)
9 DECLARE @IDSENSOREDEL NVARCHAR(20)
10 SELECT @IDIMMAGINE = Id_Immagine FROM deleted
11 SELECT @IDSENSORE = Id_Sensore FROM inserted
12 SELECT @IDSENSOREDEL = Id_Sensore FROM deleted
13 IF @IDSENSORE != @IDSENSOREDEL OR @IDSENSORE = 1
14 BEGIN
15 DELETE FROM dbo.tblSp_Bande WHERE Id_Immagine=@IDIMMAGINE
16 BEGIN
17 IF @IDSENSORE = 1
18 BEGIN
19 INSERT INTO dbo.tblSp_Bande (Id_Immagine, Id_Banda,
20 Id_Layer, Id_Tematismo) VALUES(@IDIMMAGINE,1,1,1)
39
25 END
26 ELSE IF @IDSENSORE = 9
27 BEGIN
30 END
31 ELSE
32 BEGIN
33 DECLARE @IDBANDA NVARCHAR(20)
34 DECLARE @NUMOR INT
35 DECLARE @LAYER INT
36 SET @LAYER = 4
37 DECLARE Cursore CURSOR LOCAL SCROLL FOR SELECT Id_Banda
38 FROM dbo.tblBande WHERE Id_Sensore = @IDSENSORE
39 OPEN Cursore
40 SELECT @NUMOR = COUNT(*) FROM dbo.tblBande WHERE
41 Id_Sensore = @IDSENSORE
42 SET @NUMOR=@NUMOR+3
43 WHILE (@NUMOR!=3)
44 BEGIN
45 FETCH NEXT FROM Cursore INTO @IDBANDA
46 INSERT INTO dbo.tblSp_Bande (Id_Immagine,
47 Id_Banda, Id_Layer, Id_Tematismo)
48 VALUES(@IDIMMAGINE,@IDBANDA,@LAYER,1)
46
49 SET @LAYER=@LAYER+1
50 SET @NUMOR=@NUMOR-1
51 END
52 END
53 END
54 END
55 END
Dalla riga 17 alla 25, nel caso sia selezionato lo scanner o la fotocamera comesensore, vengono inserite
automaticamente nella tblSp_Bande i tre layer relativi aitre colori primari RGB. Dalla riga 27 alla 34, nel caso
il sensore selezionato sia ilcampionamento, viene creato un solo layer e, dalla riga 32 alla 52, vengono
ricercatele bande associate al sensore scelto e vengono aggiunte le corrispondenze di“Id_Immagine”,
“Id_Banda”, “Id_Layer” e “Id_Tematismo” alla “tblSp_Bande”. Ilciclo “while” dalla riga 43 alla 51, con
l’utilizzo di un cursore, cicla la “tblBande”per inserire il suo identificatore nel record della tabella di sponda
assieme al nomedel layer.
Anche la “tblSensori” richiede l’intervento di due triggers nel caso d’inserimento edeliminazione dei suoi
record.
Al richiamo di un’azione di tipo “DELETE” viene scatenato il trigger“TriggerSensoreDelete” che vediamo di
seguito:
1 TRIGGER [dbo].[ TriggerSensoreDelete]

2 ON [dbo].[tblSensori]
3 INSTEAD OF DELETE
4 AS
5 BEGIN
6 SET NOCOUNT ON;
8 SELECT @IDSENSORE=Id_Sensore FROM deleted
9 DELETE FROM tblBande WHERE Id_Sensore = @IDSENSORE
10 DELETE FROM tblSensori WHERE Id_Sensore = @IDSENSORE
11 END
Come si vede dal codice, il trigger elimina qualsiasi banda associata al sensore da rimuovere ed infine cancella
il suo record.
40
Il secondo trigger “TriggerSensoreInsert” inserisce, alla creazione di un sensore, unnuovo record nella
“tblBande”, nel quale esso viene associato ad una banda didefault. Il suo codice è il seguente:
1 TRIGGER [dbo].[ TriggerSensoreInsert]

2 ON [dbo].[tblSensori]
3 AFTER INSERT
4 AS
5 BEGIN
6 SET NOCOUNT ON;
8 SELECT @IDSENSORE=Id_Sensore FROM inserted
9 INSERT INTO tblBande (Nome_Banda,Descrizione_Banda,Id_Sensore) VALUES
10 ('Nessuna Banda','Nessuna Banda',@IDSENSORE)
11 END
Un ultimo trigger, molto simile al “TriggerSensoreDelete”, è il“TriggerStudioDelete” che, al momento della

richiesta di rimozione va ad eliminaretutte le sue corrispondenze presenti nella “tblSp_StudiAutori”.
3.1.6 Schema generale e gerarchia
Ora che sono state analizzate tutte le componenti del database, vediamo, in Figura 3-23, il suo schema
generale e le modalità d’accesso disponibili all’applicazione.
41
Figura 3-
3- 2 3
Com’è possibile osservare, le tabelle e i triggers si trovano nella parte più interna enon subiranno accessi in
scrittura diretti ma solamente indiretti con l’intermediazionedelle stored procedures e l’intervento dei triggers
stessi. Le sole operazioni di letturagenerica saranno dirette in quanto realizzate automaticamente nel lato
applicazionedai “DataSetTableAdapters” che vedremo.
I risultati delle ricerche o i dati composti dall’unione di tabelle collegate da sponde,sono ottenuti tramite la
consultazione delle viste.
42
3.2 Progettazione e realizzazione della logica
dell' applicazione
La logica dell’applicazione lato server è composta principalmente da tre entitàfondamentali: il dataset, il file
.asmx con il suo codice per l’esposizione dei metodidel web service e la libreria GeoWS.Library.dll
contenente tutto il codiced’elaborazione delle richieste e formulazione delle risposte.
Di seguito saranno quindi analizzate queste componenti evidenziando le porzioni dicodice di principale
importanza, la loro progettazione e il loro comportamentofornendo in conclusione, anche in questo caso, la
gerarchia esistente e le interfaccedisponibili all’applicazione client.
3.2.1 Dataset
Il dataset, implementato nella libreria principale, comprende al suo interno tutte letabelle del database
d’origine, le relazioni tra di esse e le viste. Ad ogni oggettoDataTable è fatto corrispondere un oggetto
TableAdapter. Esso garantisce laconnessione diretta con il database vero proprio e fornisce di default già dei
metodiutili a reperire tutti i dati contenuti in una determinata tabella: alla DataTable “tblFonti” è stato
associato il “tblFontiTableAdapter”.Esso contiene le funzioni “Fill”, “GetData” di default ed anche gli altri
metodi comeinsert, delete e update. A questi sono stati aggiunti quelli necessari a sfruttare lestored procedure
create all’interno della base di dati.
Nell’esempio in figura si osservano, infatti, le tre funzioni “AddFonteSP”,“RemoveFonteSP” e

“UpdateFonteSP”.
Solamente nel caso delle viste, invece, non saranno presenti altre funzioni oltre aquelle fornite di default.
3.2.2 Metodi Esposti dal Servizio Web
Il file “GeoWebS.cs” contiene il codice c# della pagina “GeoWebS.asmx”. Al suointerno si trovano, infatti,
tutte le direttive “WebMethod” necessarie ad offrireall’utente le funzioni del web service. Queste sono
numerose in quanto devonooffrire tutto il necessario affinché l’applicazione client possa avere il pieno
controllodei dati da memorizzare e reperire dal database.Di seguito viene presentato l’elenco di tutti i metodi
utilizzati per l’invio dei datiall’applicazione server da parte dei client:
• AddAutore
• AddBanda
• AddCorrezione
• AddEstensione
• AddFile
43
• AddFonte
• AddLayer
• AddProiezione
• AddRiferimento
• AddSensore
• AddSpondaAutoriStudio
• AddSpondaBande
• AddSpondaCorrezioni
• AddSpondaStudi
• AddStruttura
• AddStudio
• AddTematismo
• AddZona
Questi metodi possono essere suddivisi in due gruppi: quelli che utilizzanodirettamente una funzione messa a
disposizione della libreria principale passandocome parametro il solo oggetto da aggiungere alla base di dati, e
quelli che oltreall’oggetto inviano anche la path di un file XML.
Vediamo di seguito un esempio di un metodo del primo tipo:
1 [WebMethod]
2 public int AddBanda(Banda banda)
3{
4 return this.locGeoEngine.AddBanda(banda);
5}
Si osserva come venga, in questo caso, semplicemente chiamato un metodo dellalibreria (in questo caso
“AddBanda”) inviandogli l’oggetto di tipo Banda comeargomento.
Nel caso invece di dati che, durante l’intero ciclo di vita del software, subirannopresumibilmente poche
modifiche, ma saranno letti frequentemente, sono stati creatidei file XML contenenti gli stessi dati presenti
nelle tabelle originali.
Ad esempio, nel caso dei tipi di strutture delle immagini, avremo una granprobabilità che essi rimangano per
lungo tempo (se non per l’intero ciclo di vita dell’applicazione) pressoché invariati. Al fine quindi di ridurre
gli accessi alla base didati, per ottenere i tipi di strutture delle immagini (nel nostro caso uguali sempre a
vettoriale o raster), verranno semplicemente letti dall’applicazione i file XMLevitando in tal modo l’accesso al
database.Il codice quindi di uno dei metodi di questo tipo è simile al seguente:
1 [WebMethod]
2 public int AddStruttura(Struttura struttura)
3 {
4 return this.locGeoEngine.AddStruttura(struttura,
5 this.Server.MapPath("StruttureData.xml"));
6 }
Viene inviato quindi al metodo il percorso del file contenente i tipi di strutture,affinché esso poi possa
aggiornare la base di dati. Questa tecnica è utilizzata per idati delle estensioni, delle fonti, dei layers, delle
proiezioni, dei riferimenti, deisensori e delle zone. Il metodo restituirà al richiedente un numero intero che
44
indicherà l’esito dell’aggiornamento della base di dati.
L’unico metodo d’inserimento diverso da queste due tipologie è l’”AddFile”. Il suocodice è il seguente:
1 [WebMethod]
2 public ResponseAddFile AddFile(FileImmagine file)
3 {
4 if (file.Identificator != Guid.Empty &&
5 System.IO.File.Exists(this.Server.MapPath(@”\GISWS\FileImmagineCaricati\
6 tempImm" + file.Identificator)) &&
7 System.IO.File.Exists(this.Server.MapPath(@”\GISWS\FileAnteprimaCaricati\
8 tempAnt" + file.Identificator)))
9 return this.locGeoEngine.AddFile(file);
10 else return null;
11 }
Questo metodo è chiamato alla fine dell’upload dei files dell’immagine edell’anteprima e permette di
aggiungere il record alla “tblFiles”, solamente se icontenuti sono stati ricevuti dal server. Vedremo, nel
capitolo in cui sarà analizzata lalibreria principale, tutto il comportamento, nel dettaglio, delle azioni d’upload.
I metodi utili ad ottenere i dati contenuti nelle tabelle della base di dati sono iseguenti:
• GetAutori
• GetBande
• GetCorrezioni
• GetEstensioni
• GetFileImmagine
• GetFileStudio
• GetFonti
• GetLayer
• GetProiezioni
• GetRiferimenti
• GetRisultatiRicerca
• GetSensori
• GetStrutture
• GetStudi
• GetTematismi
• GetVistaAutoriStudio
• GetVistaBande
• GetVistaCorrezioni
• GetVistaRiepilogo
45
• GetVistaRisultatiImm
• GetVistaStudi
• GetVistaStudiTot
• GetZone
• GetZoneRic
In questo, caso i metodi di reperimento delle informazioni, corrispondenti a quellid’inserimento, che

richiedevano l’utilizzo dei files XML, dovranno inviare, almetodo offerto dalla libreria, il nome del file dei
contenuti. Di seguito vediamoquindi il codice della “GetStrutture”:
1 [WebMethod]
2 public Struttura[] GetStrutture()
3 {
4 return
5 this.locGeoEngine.GetStrutture(this.Server.MapPath("StruttureData.xml"));
6 }
Il metodo “GetStrutture” della libreria restituirà un array d’oggetti “Struttura” che verranno inviati al
richiedente.
Anche in questo caso, ovviamente, i metodi di tale tipo sono quelli che si appoggianoai file XML contenenti i
dati delle estensioni, delle fonti, dei layers, delle proiezioni,dei riferimenti, dei sensori e delle zone.
Tutti gli altri metodi, invece, che si collegano alla base di dati per ottenerne leinformazioni hanno un codice
di questo tipo:
1 [WebMethod]
2 public Banda[] GetBande(SensoreRef sensRef)
3 {
4 return this.locGeoEngine.GetBande(sensRef);
5 }
In questo caso vengono richieste tutte le bande appartenenti ad un sensore specifico e viene restituito un array
d’oggetti di tipo “Banda”.I metodi per la rimozione dei dati sono del tutto simili a quelli per l’inserimento
esono:
• RemoveAutore
• RemoveBanda
• RemoveCorrezione
• RemoveEstensione
• RemoveFonte
• RemoveImmagine
• RemoveProiezione
• RemoveRiferimento
• RemoveSensore
• RemoveSpondaAutoriStudio
46
• RemoveSpondaBande
• RemoveSpondaCorrezioni
• RemoveSpondaStudi
• RemoveStruttura
• RemoveStudio
• RemoveTematismo
• RemoveZona
Anche il loro codice è analogo ai metodi d’inserimento, con la sola differenza delmetodo richiamato.
Vediamo l’esempio della “RemoveStruttura”:
1 [WebMethod]
2 public int RemoveStruttura(StrutturaRef strutturaRef)
3 {
54
4 return this.locGeoEngine.RemoveStruttura(strutturaRef,
6 }
E l’esempio della “RemoveBanda”:
1 [WebMethod]
2 public int RemoveBanda(BandaRef bandaRef)
3 {
4 return this.locGeoEngine.RemoveBanda(bandaRef);
5 }
Le funzioni utilizzate per l’aggiornamento dei dati sono le seguenti:
• UpdateAutore
• UpdateBanda
• UpdateCorrezione
• UpdateEstensione
• UpdateFile
• UpdateFonte
• UpdateImmagine
• UpdateProiezione
• UpdateRiferimento
• UpdateSensore
• UpdateSpondaBande
• UpdateSpondaCorrezioni
47
• UpdateStruttura
• UpdateStudio
• UpdateTematismo
• UpdateZona
Il codice seguente si riferisce al metodo “UpdateStruttura”:
1 [WebMethod]
2 public int UpdateStruttura(Struttura struttura)
3 {
4 return this.locGeoEngine. UpdateStruttura (struttura,
6 }
E di seguito l’”UpdateBanda”:
1 [WebMethod]
2 public int UpdateBanda(Banda banda)
3 {
4 return this.locGeoEngine.UpdateBanda(banda);
5 }
È visibile, in questo caso, la somiglianza con il codice dei metodi d’inserimento deidati.
Per finire, analizziamo altri due metodi particolari utilizzati per l’upload dei files dell’immagine e degli studi.
Essi sono l’”UploadFile” e l’”UploadStudio”.
Il primo presenta il seguente codice:
1 [WebMethod]
2 public UploadId UploadFile(ContenutoFile contFile)
3 {
4 if (contFile.identificatore == Guid.Empty)
5 {
6 contFile.identificatore = Guid.NewGuid();
7 }
8 UploadId uploadId = new UploadId();
9 uploadId.identificatore = contFile.identificatore;
10 this.locGeoEngine.UploadFile(contFile);
11 return uploadId;
12 }
Si osserva che, nel caso il metodo sia chiamato per la prima volta, esso crea uncodice GUID e dopo aver
chiamato il metodo “UploadFile” della libreria, restituisce tale codice al richiedente. Nell’analisi dettagliata
della libreria principale vedremo iprincipi di funzionamento di tale azione.
Il metodo “UploadStudio” è del tutto identico; sono diversi soltanto i tipi e la funzione richiamata.
3.2.3 Libreria principale
Il file “GeoEngine.cs” contiene tutto il codice che gestisce le chiamatedell’applicazione client ed elabora
quindi le sue richieste, comunica con la base di dati e prepara le risposte.
48
Al fine di creare un sistema totalmente tipizzato, ogni richiesta ed ogni risposta tra il client e il server, avviene
tramite lo scambio d’oggetti. Sono stati creati quindi tanti oggetti quanti sono i tipi di dati da scambiare. Di
seguito vediamo un loro elenco:
• Autore e AutoreRef
• Banda e BandaRef
• Correzione e CorrezioneRef
• Estensione e EstensioneRef
• FileImmagine e FileImmagineRef
• Fonte e FonteRef
• Immagine e ImmagineRef
• Layer e LayerRef
• Proiezione e ProiezioneRef
• Riferimento e RiferimentoRef
• Sensore e SensoreRef
• Struttura e StrutturaRef
• Studio e StudioRef
• Tematismo e TematismoRef
• Zona e ZonaRef
• ZonaRic e ZonaRicRef
Come rappresentanti di questi, viene di seguito illustrato il codice dei tipi Banda e
BandaRef:
1 namespace GeoWS.Library
2 {
3 public class BandaRef : IEquatable<BandaRef>
4 {
5 public long Id_Banda;
6 public static BandaRef NewR(long idBanda)
7 {
8 BandaRef bandaR = new BandaRef();
9 bandaR.Id_Banda = idBanda;
10 return bandaR;
11 }
12 #region IEquatable<BandaRef> Members
13 public bool Equals(BandaRef other)
14 {
15 return (this.Id_Banda == other.Id_Banda);
16 }
17 #endregion
18 }
19 }
49
2 {
3 public class Banda
4 {
5 public BandaRef ID;
6 public string Nome_Banda, Descrizione_Banda;
7 public float Risoluzione_Radiometrica, Dimensione_Pixel,
8 Inizio_Intervallo_Spettrale, Fine_Intervallo_Spettrale;
9 public long Id_Sensore;
10 public override int GetHashCode()
11 {
12 return ID.GetHashCode();
13 }
14 }
15 }
Come si nota il tipo “BandaRef” è utilizzato per contenere solamente il datodell’identificativo della banda ed
è utile in tutte le situazioni nelle quali ci si vuolriferire ad un particolare oggetto di tipo “Banda”
identificandolo con il suo ID (checorrisponde al valore della chiave primaria della “tblBande” del database di
origine).
Ciò avviene ad esempio nelle operazioni di rimozione, nelle quali sarà necessarioindicare solamente il
riferimento al dato da eliminare. Dalla riga 13 in poi si trova ilcodice necessario a raffrontare due oggetti di
tipo “BandaRef” attraverso il confrontodel loro identificativo.
Il tipo “Banda”, invece, contiene tutti i restanti dati della banda ed in piùl’indicazione di eseguire il
”GetHashCode” sull’ID dell’oggetto al fine di potereseguire un eventuale confronto tra due bande utilizzando
la comparazione deglihash applicata ai valori degli identificativi.
Si può osservare come tutti i campi dei dati sono di tipo pubblico al fine dipermettere una corretta
serializzazione dell’oggetto istanziato al momento del suotrasferimento in formato XML nell’”Envelope
SOAP”.
Per quanto riguarda i tipi che si appoggiano al salvataggio dei dati nel file XML,ritroviamo nel loro codice le
direttive necessarie ad interpretare tali file e ricrearequindi gli oggetti salvati. Un esempio è dato dal tipo
“Struttura” e di seguito vediamoil codice necessario a decodificare il solo “StrutturaRef”:
1 public static StrutturaRef ReadFrom(XmlReader reader)

2 {
3 StrutturaRef strutturaRef = new StrutturaRef();
4 if (reader.IsEmptyElement)
5 {
6 reader.Read();
7 }
8 else
9 {
10 while (true)
11 {
12 if (reader.NodeType == XmlNodeType.EndElement)
13 {
14 break;
15 }
16 else if (reader.NodeType == XmlNodeType.Text)
17 {
18 reader.Read();
19 }
20 else if (reader.NodeType == XmlNodeType.Whitespace)
21 {
22 reader.Read();
23 }
24 else if (reader.LocalName == "GeoWSDataSet")
25 {
26 reader.Read();
27 }
28 else if (reader.LocalName == "tblStrutture")
29 {
30 reader.Read();
31 }
32 else if (reader.LocalName == "Id_Struttura")
33 {
50
34 strutturaRef.Id_Struttura =
35 reader.ReadElementContentAsLong();
36 break;
37 }
38 else if (reader.LocalName != "Id_Struttura")
39 {
40 reader.Read();
41 }
42 }
43 }
44 return strutturaRef;
45 }
Bisogna considerare che il file XML è prodotto da un metodo esposto dal dataset checonsente di crearlo
direttamente. Esso contiene, come si osserva a riga 24 e 28 il nome del dataset di provenienza e il nome della
tabella dei dati che esso contiene. Alfine quindi di estrapolare i dati utili, il ciclo “while” che va da riga 10 a
riga 42, percorre il file XML ed estrae da esso il valore di “Id_Struttura” per assegnarloall’apposito campo
dell’istanza di strutturaRef che verrà restituita al richiedente. Iltipo “Struttura” conterrà un codice analogo che
consentirà di estrarre invece i restantidati delle caratteristiche della struttura. Questo tipo di codice perciò sarà
presente ntutti i tipi che si appoggiano al file XML per il salvataggio dei dati.
Oltre ai tipi rappresentanti le caratteristiche delle immagini, sono stati realizzati quelli utili a contenere i dati
delle viste presenti nel database. Questi tipi sono:
• VistaAutoriStudio e VistaAutoriStudioRef
• VistaBande e VistaBandeRef
• VistaCorrezioni e VistaCorrezioniRef
• VistaRiepilogo e VistaRiepilogoRef
• VistaRisultatiImm e VistaRisultatiImmRef
• VistaStudi e VistaStudiRef
In questo caso, i file “Ref” delle viste degli studi, delle bande, delle correzioni e degli autori contengono gli
identificativi contenuti nelle tabelle di sponda. Vediamo l’esempio dei tipi “VistaCorrezioni” e
“VistaCorrezioniRef”:
2 {
3 public class VistaCorrezioniRef : IEquatable<VistaCorrezioniRef
4 {
5 public long Id_Sponda,Id_Correzione, Id_Immagine;
6 public static VistaCorrezioniRef NewR(long idSponda,long idCorr,long
7 idImm)
8 {
9 VistaCorrezioniRef spondaR = new VistaCorrezioniRef();
10 spondaR.Id_Sponda = idSponda;
11 spondaR.Id_Correzione = idCorr;
12 spondaR.Id_Immagine = idImm;
13 return spondaR;
14 }
15 #region IEquatable<VistaBandeRef> Members
16 public bool Equals(VistaCorrezioniRef other)
17 {
18 return (this.Id_Sponda == other.Id_Sponda);
19 }
20 #endregion
60
21 }
22 }
51
2 {
3 public class VistaCorrezioni
4 {
5 public VistaCorrezioniRef ID;
6 public string Descrizione_Correzione, Tipo_Correzione;
7 public override int GetHashCode()
8 {
9 return ID.GetHashCode();
10 }
11 }
12 }
Com’è visibile, nel file VistaCorrezioniRef si trovano i tre identificativi della sponda dell’immagine e della
correzione, mentre nel file VistaCorrezioni ci sono le caratteristiche della correzione.
I tipi VistaRiepilogo e VistaRisultatiImm contengono invece l’insieme dei dati ottenuti dalle rispettive viste e
nei files “Ref” si trovano solamente gli identificativi delle immagini.
Un ultimo gruppo di tipi è stato creato per trasportare tutte quelle informazioni che non potevano essere
contenute all’interno degli oggetti già visti. Vediamo qui di seguito un loro elenco:
• ArgomentoRicerca
• ContenutoFile
• ContenutoFileStudio
• DWFile
• DWStudio
• ResponseAddFile
• ResponseAddStudio
• UploadId
“ArgomentoRicerca” contiene tre campi: “campoRicerca”, “sezioneRicerca” e“condizione”. L’oggetto di

questo tipo è utilizzato nelle fasi di ricerca per inviare icriteri secondo i quali eseguirla.
I tipi “ContenutoFile” e “ContenutoFileStudio” sono pressoché simili e possiamo vedere di seguito il
contenuto del primo:
2 {
3 public class ContenutoFile
4 {
5 public byte[] contenutoImmagine;
6 public byte[] contenutoAnteprima;
7 public long offsetImmagine;
8 public long offsetAnteprima;
9 public bool uploadImmComplete = false;
10 public bool uploadAntComplete = false;
11 public Guid identificatore;
12 }
13 }
I due campi di tipo “byte[]” sono gli array contenenti i bytes trasmessi durantel’upload da parte
dell’applicazione client, i due campi di tipo long contengonol’offset raggiunto durante le fasi di caricamento
delle immagini sul server e i duevalori bool sono utilizzati per comunicare la terminazione del processo. Il
campo ditipo “Guid” è utilizzato dal server per identificare il file sul quale scrivere durante le
fasi dell’upload.
52
Anche i tipi DWFile e DWStudio sono quasi identici e sono utilizzati durante le fasidi download delle
immagini e degli studi da parte del client. Vediamo di seguito ilcodice del primo di essi:
2 {
3 public class DWFile
4 {
5 public FileImmagineRef fileRef;
6 public byte[] contenutoImmagine;
7 public long offsetImmagine;
8 public bool downloadComplete = false;
9 public long grandezzaTot;
10 public string CRC_File;
11 }
12 }
In questo caso viene inviato al client il riferimento al file richiesto, l’array dei bytes del contenuto, l’offset
raggiunto durante le fasi del download, un valore booleano per la conferma della terminazione del
procedimento, un valore con la grandezza totale del file ed infine l’hash md5 memorizzato nel database
affinché il client possa verificarlo.
I due tipi ResponseAddFile e ResponseAddStudio contengono l’identificativo e larisposta dell’avvenuto
inserimento del record nel database rispettivamente del file e dello studio inseriti.
Infine il tipo UploadId contiene solamente il GUID generato dal server e inviato al client per consentirgli di
spedire i file dell’immagine dell’anteprima e dello studionel modo che vedremo descritto in seguito.
Passando ora al codice vero e proprio verrà presentato quello relativo all’aggiunta diuna banda alla base di dati
con l’utilizzo della funzione “AddBanda”:
1 public int AddBanda(Banda banda)

2 {
3 GeoWSDataSetTableAdapters.tblBandeTableAdapter tba = new
4 GeoWSDataSetTableAdapters.tblBandeTableAdapter();
5 int returnCode = Convert.ToInt32(tba.AddBandaSP(banda.Nome_Banda,
6 banda.Descrizione_Banda, banda.Risoluzione_Radiometrica,
7 banda.Dimensione_Pixel, banda.Id_Sensore, banda.Inizio_Intervallo_Spettrale,
8 banda.Fine_Intervallo_Spettrale));
9 return returnCode;
10 }
Come si può vedere, il codice risulta molto semplice grazie alla creazione nel dataset delle funzioni associate
alle stored procedure. Viene creata un’istanza del “TableAdapter”, chiamata la funzione “AddSpondaSP” e
restituito il codice della funzione SQL.
Prendendo in esame la funzione “AddStruttura” che vediamo qui sotto, notiamo l’utilizzo del metodo
“WriteXml” per creare il file XML dalla tabella “tblStrutture”presente nel dataset.
1 public int AddStruttura(Struttura struttura, string path)

2 {
3 GeoWSDataSetTableAdapters.tblStruttureTableAdapter tba = new
4 GeoWSDataSetTableAdapters.tblStruttureTableAdapter();
5 int returnCode =
6 Convert.ToInt32(tba.AddStrutturaSP(struttura.Tipo_Struttura,
7 struttura.Descrizione_Struttura));
8 tba.Fill(geoWSDataSet.tblStrutture);
9 geoWSDataSet.tblStrutture.WriteXml(path);
10 return returnCode;
11 }
Il codice delle altre funzioni d’aggiornamento e rimozione risultano identiche a quelle viste con la differenza
delle funzioni dei “TableAdapters” richiamate.
I metodi utilizzati invece per ottenere dei dati, risultano abbastanza diversi nel caso questi siano estratti dalla
base di dati o dai file XML. Vediamo un esempio del primocaso:
53
1 public Tematismo[] GetTematismi()
2 {
3 GeoWSDataSetTableAdapters.tblTematismiTableAdapter tba = new
4 GeoWSDataSetTableAdapters.tblTematismiTableAdapter();
5 tba.Fill(geoWSDataSet.tblTematismi);
8 Tematismo[] tematismi = new Tematismo[geoWSDataSet.tblTematismi.Rows.Count];
9 int iteratore = 0;
10 foreach (GeoWSDataSet.tblTematismiRow currentRow in
11 geoWSDataSet.tblTematismi.Rows)
12 {
13 tematismi[iteratore] = new Tematismo();
14 tematismi[iteratore].ID = new
15 TematismoRef();
16 tematismi[iteratore].ID.Id_Tematismo =
17 Convert.ToInt64(currentRow.Id_Tematismo);
18 tematismi[iteratore].Nome_Tematismo = currentRow.Nome_Tematismo;
19 tematismi[iteratore].Descrizione_Tematismo =
20 currentRow.Descrizione_Tematismo;
21 tematismi[iteratore].Informazioni_Tematismo =
22 currentRow.Informazioni_Tematismo;
23 iteratore += 1;
24 }
25 return tematismi;
26 }
Dopo che la “tblTematismi” è stata riempita, nel ciclo “foreach” viene attribuito, ad ogni campo dell’istanza
dell’oggetto di tipo tematismo, il valore della caratteristica specifica. Alla fine del processo si ottiene quindi un
array contenente tutti gli oggetti da inviare come risposta al client.
Nel caso i dati vengano estratti dal file XML abbiamo invece un codice di questo tipo:
1 public Estensione[] GetEstensioni(string path)

2 {
3 if (!System.IO.File.Exists(path))
4 {
5 GeoWSDataSetTableAdapters.tblEstensioniTableAdapter tba = new
6 GeoWSDataSetTableAdapters.tblEstensioniTableAdapter();
7 tba.Fill(geoWSDataSet.tblEstensioni);
8 geoWSDataSet.tblEstensioni.WriteXml(path);
9 }
10 XmlTextReader xmltr = new XmlTextReader(path);
11 Estensione[] locEstensioni = Estensione.ReadFrom(xmltr);
12 return locEstensioni;
13 }
Come si può osservare, viene verificata l’esistenza del file xml (in modo da crearlo incaso esso non esistesse),
viene letto, ed in seguito creato l’array d’oggetti darestituire.
Due metodi di rimozione leggermente differenti dagli altri sono il“RemoveImmagine” e il “RemoveStudio”.
Essi si occupano, infatti, dellacancellazione di un’immagine e di uno studio dalla base di dati. Ma, mentre della
rimozione dei dati collegati ad una singola immagine o studio si occupano già itriggers e le stored procedures,
la cancellazione dal file system dei files deve essereeseguita utilizzando il metodo statico “File.Delete” offerto
dal framework.
Un discorso a sé stante è richiesto per le fasi d’upload dell’immagine: per garantire infatti l’opportunità, a più
clientnello stesso momento, di caricare un’immagine, ci si è serviti degli identificatoriunici globali (GUID).
Il primo passaggio è svolto dal client che invia al server una prima parte del filelasciando il campo relativo al
GUID vuoto. Il server crea un file temporaneoassegnandogli un nome uguale ad una particella sempre
identica seguita dal GUID edinvia questo codice al client. Esso, durante le successive chiamate, dovrà servirsi
ditale identificativo per inviare le porzioni successive del file. In questo modo, in caso di più upload
contemporanei, il server riconoscerà sempre il file sul quale proseguirel’operazione di scrittura.
Le chiamate alla funzione “UploadFile” sono numerose, in quanto, trattandosi di trasferimenti di file corposi,
è necessario inviarli in piccole parti in modo da noncreare troppo traffico continuo in rete, consentendo anche
ad altre applicazioni concorrenti di fruire della banda a disposizione.
54
In tal modo, inoltre, è possibile informare l’applicazione client dello stato della transazione, indicando la
percentale di completamento raggiunta Al termine della procedura, il client richiama il metodo AddFile che si
occupa delcaricamento nel database dei dati relativi all’immagine e alla rinominazione dei file.
Successivamente risponderà al client comunicandogli l’esito della transazione.Per comprendere meglio tale
processo vengono esposti gli spezzoni più importanti del codice:
1 while (byteRead > 0)

2 {
3 upId = locGeoWebS.UploadFile(contFile);
4 contFile.identificatore = upId.identificatore
5 SentBytes += byteRead;
6 contFile.offsetImmagine = SentBytes;
7 byteRead = fs.Read(contFile.contenutoImmagine, 0, ChunkSize);
8 if (byteRead != contFile.contenutoImmagine.Length)
9 {
10 ChunkSize = byteRead;
66
11 byte[] TrimmedBuffer = new byte[byteRead];
12 Array.Copy(contFile.contenutoImmagine, TrimmedBuffer, byteRead);
13 contFile.contenutoImmagine = TrimmedBuffer;
14 }
15 if (contFile.contenutoImmagine.Length == 0)
16 {
17 contFile.uploadImmComplete = true;
18 locGeoWebS.UploadFile(contFile);
19 GeoWS.Services.ResponseAddFile respAdd = new
20 GeoWS.Services.ResponseAddFile();
21 respAdd = locGeoWebS.AddFile(locFile);
22 fs.Close();
23 break;
24 }
25 }
Qui sopra è visibile il codice del client che legge il suo file locale e lo invia in fasi successive sino a concludere
l’operazione richiamando il metodo AddFile a riga 21.
La dimensione d’ogni singola parte inviata al client è di 2MB.
Prima di tutte queste operazioni, il client esegue una compressione dei files dell’immagine e crea con esso un
codice di hash md5 da inviare al server riempiendo un campo dell’oggetto “locFile”.
1 if(System.IO.File.Exists(@"c:\inetpub\wwwroot\GISWS\FileImmagineCaricati\tempImm" +
2 contFile.identificatore))
3 {
4 if (contFile.uploadImmComplete == false)
5 {
6 try
7 {
8 using (FileStream fs = new
9 FileStream(@"c:\inetpub\wwwroot\GISWS\FileImmagineCaricati\
10 tempImm" + contFile.identificatore, FileMode.OpenOrCreate,
11 FileAccess.Write))
12 {
13 fs.Seek(contFile.offsetImmagine, SeekOrigin.Begin);
14 fs.Write(contFile.contenutoImmagine, 0,
15 contFile.contenutoImmagine.Length);
16 contFile.offsetImmagine +=
17 contFile.contenutoImmagine.Length;
18 fs.Close();
19 }
20 }
21 catch
22 {}
23 }
24
55
Qui sopra invece è rappresentato il codice del server per accettare le parti di file inviate dal client e scriverle
nel file temporaneo.
Le operazioni del metodo AddFile sono troppe per essere esposte brevemente, ma sostanzialmente esso si
occupa di rinominare i file con i nomi definitivi, controllare l’hash del file inviato, aggiornare tutti i dati nel
database riguardanti i files ricevuti e creare la risposta da inviare al client. Quest’ultima contiene i valori delle
chiavi primarie delle tabelle tblImmagini e tblFiles relativi ai record appena inseriti, assieme al codice che
indica il successo o l’insuccesso dell’operazione.
I metodi AddStudio e UploadStudio, offrono lo stesso sistema visto per i files, garantendo anche in questo
caso due o più upload contemporanei.
Per quanto riguarda la parte riguardante il download dei files dal server, le azioni eseguite da entrambi i lati
sono minori, ma ad ogni modo progettate per garantire il funzionamento corretto in un ambito multi-utente.
Per soddisfare questo requisito sono stati creati due metodi “GetFileImmagine” e “GetFileStudio”.
Com’è possibile osservare in Figura 3-31 il client inizia la comunicazione inviando un oggetto di tipo
“DWFile” contenente al suo interno un campo che indica il “FileImmagineRef” e la posizione dell’offset
desiderato. Il server risponde inviando a sua volta un oggetto di tipo “DWFile” contenente però l’array di
bytes, l’offset raggiunto, l’hash md5 e la grandezza complessiva del file richiesto.
L’operazione continua sino a quando il server non invia anche un valore booleano che indica il
raggiungimento della file del file. A tal punto il client controllerà l’hash ed estrarrà i files per renderli
disponibili all’utente. Le operazioni nel caso dei files dello studio sono identiche con l’utilizzo però degli
oggetti DWStudio e del metodo “GetFileStudio”.
Per chiarire i concetti esposti, viene mostrata di seguito parte del codice client e
server:
1 GeoWS.Services.DWFile rest = geoWs.GetFileImmagine(dwf);
2 while (rest.downloadComplete != true)
3{
4 fs.Seek(dwf.offsetImmagine, SeekOrigin.Begin);
5 fs.Write(rest.contenutoImmagine, 0, rest.contenutoImmagine.Length);
6 dwf.offsetImmagine += rest.contenutoImmagine.Length;
7 rest = geoWs.GetFileImmagine(dwf);
8}
9 if (rest.downloadComplete == true)
10 {
11 fs.Seek(dwf.offsetImmagine, SeekOrigin.Begin);
12 fs.Write(rest.contenutoImmagine, 0, rest.contenutoImmagine.Length);
13 ChangeProgressBar(100);
14 ChangeLabel("Download in corso (100%)");
15 fs.Close();
16 FileStream fsHash = new FileStream(fileNameTemp, FileMode.Open,
17 FileAccess.Read);
18 MD5CryptoServiceProvider md5 = new MD5CryptoServiceProvider();
19 byte[] hash = md5.ComputeHash(fsHash);
20 if (rest.CRC_File.CompareTo(BitConverter.ToString(hash)) == 0)
21 md5Ok = true;
22 fsHash.Close();
23 }
Qui sopra si osserva come il server, verificato che il download è stato completato, da riga 16 in poi, esamina
l’hash per confrontarlo con quello inviatogli dal server. A queste righe seguono poi quelle relative alla
decompressione del file.
Il codice del lato server invece è il seguente:
1 public DWFile GetFileImmagine(DWFile rDWF)
2{
3 DWFile locDW = new DWFile();
4 GeoWSDataSet.tblFilesRow[] dr =
5 (GeoWSDataSet.tblFilesRow[])geoWSDataSet.tblFiles.Select("Id_File=" +
6 rDWF.fileRef.Id_File);
7 string nomefile = dr[0].Nome_File;
8 locDW.CRC_File = dr[0].CRC_File;
9 int ChunkSize = 2097152;
10 locDW.contenutoImmagine = new byte[ChunkSize];
11 using (FileStream fs = new FileStream(nomefile, FileMode.Open,
12 FileAccess.Read))
13 {
14 locDW.grandezzaTot = fs.Length;
15 fs.Seek(rDWF.offsetImmagine, SeekOrigin.Begin);
56
16 int byteRead = fs.Read(locDW.contenutoImmagine, 0, ChunkSize);
17 if (byteRead != locDW.contenutoImmagine.Length)
18 {
19 ChunkSize = byteRead;
20 byte[] TrimmedBuffer = new byte[byteRead];
21 Array.Copy(locDW.contenutoImmagine, TrimmedBuffer, byteRead);
22 locDW.contenutoImmagine = TrimmedBuffer;
23 locDW.downloadComplete = true;
24 }
25 fs.Close();
26 }
27 return locDW;
28 }
Anche in questo caso come si osserva a riga 9, vengono inviate parti di file della grandezza di 2MB. A riga 23,
quando viene raggiunta la fine del file, il server invia al client l’oggetto di tipo DWFile con il campo
“downloadComplete” impostato su “true”.
L’ultimo metodo analizzato è il “GetRisultatiRicerca”. Esso riceve come argomento in ingresso un array
d’oggetti di tipo “ArgomentoRicerca” e restituisce un array d’oggetti “ImmagineRef” contenenti appunto i
riferimenti alle immagini rispondenti ai criteri di ricerca scelti. Nella tabella seguente sono indicate tutte le
combinazioni dei valori “campoRicerca” e “sezioneRicerca” possibili.
Utilizzando appropriatamente tali codici, è possibile inviare al server la richiesta di svolgere la ricerca secondo
i criteri scelti. Il server analizzerà l’array degli argomenti e creerà un comando sql accodando tutti i criteri
desiderati tramite l’operatore booleano “AND”. Vediamo di seguito solo una parte iniziale e finale dell’intero
metodo:
1 foreach (ArgomentoRicerca ricCorr in ric)

2{
3 switch (ricCorr.campoRicerca)
4{
5 case "00":
6 if (ricCorr.sezioneRicerca == "0")
7 filtroRicerca[iter] = "Descrizione_File" + ricercaLike +
8 ricCorr.condizione + fineLike;
9 else if (ricCorr.sezioneRicerca == "1")
10 filtroRicerca[iter] = "Dimensione_File" + ricercaMinore +
11 ricCorr.condizione;
12 else if (ricCorr.sezioneRicerca == "2")
13 filtroRicerca[iter] = "Id_Estensione" + ricercaUguale +
14 ricCorr.condizione;
15 break;
In questo spezzone è possibile vedere come viene analizzato l’argomento della ricerca tramite la clausola case e
come venga creato, all’interno dell’array “filtroRicerca” il comando SQL di ogni singola condizione.
1 if (iter > 1)
2{
3 filtroRicerca[0] = filtroRicerca[0] + " AND ";
4 for (int i = 1; i < iter-1; i++)
5{
6 filtroRicerca[0] = filtroRicerca[0] + filtroRicerca[i] + " AND ";
7}
8 filtroRicerca[0] = filtroRicerca[0] + filtroRicerca[filtroRicerca.Length - 1];
9}
10 geoWSDataSet.VistaRisultatiImm.Clear();
11 string sqlCmd = "SELECT dbo.VistaRisultatiImm.* FROM dbo.VistaRisultatiImm WHERE
12 (" + filtroRicerca[0] + ")";
Mentre qui sopra viene creata la stringa SQL finale da inviare al database con l’aggiunta, tra le diverse
condizioni, dell’operatore “AND”.
Per quanto concerne la ricerca per zona, sono state distinte due situazioni: che la zona scelta sia una macro-
area o una micro-area. Nel primo caso il comportamento dell’azione di ricerca è quello visibile in Figura 3-
32. Com’è osservabile, se la zona d’interesse è ad esempio l’Italia, le immagini comprese tra i risultati restituiti
da un’operazione di ricerca sono quelle che rientrano, anche se non interamente, nei limiti della zona.
Saranno restituite cioè, tra i risultati, le sole immagini che rientrano completamente all’interno dei limiti della
zona. Questo comportamento è stato scelto per il fatto che, nella maggior parte delle occasioni, se la ricerca
viene eseguita su di una sotto-area, l’utente ha l’intenzione di restringere i suoi risultati alle sole immagini
57
comprese all’interno della zona, evitando quelle a cavallo della delimitazione rintracciabili eventualmente
tramite una micro-area più estesa o una macro-area.
3.3 Progettazione dell' interfaccia
In questo capitolo sono esposte tutte le interfacce create per usufruire, nel modo più completo possibile, delle
funzioni offerte dalla parte server della soluzione software.
Tali interfacce sono l’unico punto d’accesso all’applicazione che l’utente ha a disposizione e devono
rispondere quindi a numerosi requisiti d’accessibilità ed usabilità. Per raggiungere tale obbiettivo
l’applicazione è stata sottoposta, in fasi successive dello sviluppo, agli utenti finali. Sono stati osservati i loro
più comuni errori d’inserimento dei dati e prese in considerazione le loro difficoltà nel reperire una qualsiasi
tipo d’informazione desiderata. In tal modo si è cercato di forgiare un’interfaccia utente cucita su misura delle
preferenze dei suoi futuri utilizzatori. Le interfacce sono sostanzialmente di due tipi: una realizzata con le
Windows Form ed utilizzata per tutti i processi d’accesso in lettura e scrittura ed un’altra consistente
in alcune pagine ASP dinamiche per la sola consultazione dell’archivio delle immagini. Inoltre, al fine di
garantire una fusione con uno degli strumenti più utilizzati dal personale del laboratorio, è stato realizzato un
Plug-In per l’applicazione ArcGis.
3.3.1 Interfaccia di inserimento
All’avvio dell’applicazione ci si ritrova dinnanzi alla form di Figura 3-24 che offre tre scelte: l’inserimento di
una nuova immagine, la ricerca e l’amministrazione.
Figura 3-
3-24
Dalla barra degli strumenti è possibile accedere alla configurazione dell’indirizzo di residenza del server.
All’applicazione è stato infatti aggiunto un file di configurazione “user.config” necessario a preservare
l’informazione sull’indirizzo del server impostato. Se all’avvio la comunicazione con il server risulta
impossibile l’utente viene direttamente invitato ad inserire il corretto indirizzo e, nel caso questo
non risultasse ancora valido, verrà richiesta un’ulteriore conferma. In Figura 3-25 è possibile osservare tale
form.
58
Figura 3-
3-25
Quando il collegamento con il server ha successo risultano attivi anche i tre tasti per entrare nelle tre differenti
sezioni. Iniziando quindi con la parte relativa all’inserimento, la prima form offerta all’utente è quella di Figura
3-26.
Figura 3-
3-26
Da essa l’utilizzatore può aggiungere i files relativi all’immagine ad una lista, deve inserire un file d’anteprima
in formato JPG, scegliere il formato dei files dell’immagine ed inserire una descrizione generica. Quando tutti
i campi sono completati è consentito premere il tasto “Avanti” che procederà alla compressione dei files e al
loro invio al server. Per il processo di compressione si è fatto uso della libreria “SharpZipLib”[6] distribuita
con licenza GPL che consente la creazione e l’estrazione d’archivi compressi in formato “zip”. Il codice
dell’intero processo compressione-invio è contenuto nella classe “UploadFileFunction” che contiene un
metodo “UploadWork” eseguito in modalità di thread separato ed addetto anche all’aggiornamento della
barra del progresso.
La form successiva è quella di Figura 3-27 riguardante la scelta della fonte. Da essa è possibile anche inserire
un nuovo tipo di fonte qualora esso non sia già presente nella lista.
59
Figura 3-
3-27
Simile è anche la form seguente di Figura 3-28 relativa alla selezione del riferimento.
Figura 3-
3-28
Anche in questo caso l’utente ha la possibilità di aggiungere un nuovo riferimento impostandone la scala. Dei
controlli sui diversi campi testo assicurano che il loro contenuto sia accettabile come nel caso della scala che
richiede l’inserimento di un valore numerico.
Procedendo alla fase successiva si passa all’inserimento di tutti i dettagli aggiuntivi dell’immagine. La form
preposta a tale funzione è visibile in Figura 3-29. Tramite essa è possibile scegliere il tipo di sensore, la
proiezione, la struttura, la data d’acquisizione e le coordinate in gradi decimali dei bordi dell’immagine.
60
Figura 3-
3-29
Per inserire la data è possibile fare uso anche di un calendario a scomparsa e, se si conoscono le sole coordinate
in formato sessagesimale è possibile utilizzare lo strumento di conversione di Figura 3-30 accessibile tramite
l’apposito tasto.
Figura 3-
3-30
Anche in questo caso, tutti i campi d’inserimento sono controllati affinché rientrino nei limiti consentiti. Le
latitudini devono essere comprese tra i 90° e i -90° e le longitudini tra i 180° e i -180°. La data infine deve
essere esistente e, se un qualche campo obbligatorio non viene riempito, risulta impedito il procedimento alla
fase successiva.
Qualora tutto fosse corretto, con la pressione del tasto “Avanti” si passa ad una form di riepilogo visibile in
Figura 3-31 nella quale l’utente può controllare l’esattezza dei dati inseriti sino a quel momento ed
eventualmente procedere nel senso inverso per correggere gli errori. In essa si possono notare anche tre tasti
necessari ad inserire le bande e i tematismi, le correzioni e gli studi.
61
Figura 3-
3-31
La sezione riguardante le bande e i tematismi è visibile in Figura 3-32.
Figura 3-
3-32
Qui è possibile modificare ogni corrispondenza banda-layer, associare a questa un temastimo e aggiungerne
uno nuovo in caso non sia già presente. È consentito inoltre eliminare intere bande o aggiungerne di nuove.
Nel pannello nominato “Banda” è infine possibile osservare le caratteristiche di quella selezionata.
Per inserire una correzione basta aggiungerla dalla form di Figura 3-33.
62
Figura 3-
3-33
Infine, alla pressione del tasto “Studi”, ci si ritrova di fronte alla form di Figura 3-34.
Figura 3-
3-34
63
Da qui è possibile scegliere uno studio esistente dalla lista ed aggiungerlo a quelli associati all’immagine o
crearne uno nuovo. Per ogni studio selezionato, nella tabella in basso vengono elencati i suoi autori.
Nel caso si desideri creare un nuovo studio l’utente viene posizionato sulla form in Figura 3-35.
Figura 3-
3-35
Da essa possono essere inseriti il titolo, il tipo di studio, il file e l’abstract. Inoltre possono venir associati allo
studio diversi autori spostandoli dalla tabella di sinistra a quella di destra ed, eventualmente, aggiungendone di
nuovi. Quando viene data la conferma, se è stato aggiungo un file dello studio, esso viene caricato con un
processo simile a quello visto per i files delle immagini. Il codice è contenuto nella classe
“UploadStudioFunction” che contiene il metodo “UploadWork” eseguito in modalità di thread separato ed
addetto anche all’aggiornamento della barra del progresso.
Con questo si conclude la descrizione della sezione relativa all’archiviazione delle immagini e si passa a quella
della consultazione.
3.3.2 Interfaccia di ricerca

La prima form visibile dopo la pressione del tasto “Ricerca” è quella di Figura 3-36.
Essa presenta una lista di tutti i possibili criteri secondo i quali svolgere una ricerca nell’archivio delle
immagini.
64
Figura 3-
3-36
È possibile quindi scegliere, tramite dei menu a tendina, per ogni campo una sezione e una condizione di
ricerca. Con la pressione dei tasti con il simbolo “+” a destra, la regola viene aggiunta alla lista dei filtri e,
quando si è soddisfatti, tramite la pressione del tasto “Ricerca” si otterranno le immagini rispondenti ai criteri.
Nel caso delle zone, c’è la possibilità di scegliere tra delle macro o micro-aree. Queste ultime sono
sottoinsiemi delle macro-aree e permettono una ricerca per zona più ristretta. Non tutte le zone
comprendono al loro interno delle sottoaree, ma solamente quelle definite dall’utente. Quindi, se la macro-
area selezionata presenta delle sottoaree, esse vengono visualizzate nel menu a tendina sulla destra, altrimenti
no.
Ad ogni inserimento di una nuova regola di ricerca nella tabella in basso, viene creato anche il codice di
ricerca da inviare al server per ottenerne i risultati e, con il tasto “Elimina” alla destra d’ogni riga è possibile
cancellare il filtro.
Con la pressione del tasto raffigurante la terra alla destra della zona, si giunge alla form di Figura 3-37. Essa
offre una visuale della terra con al di sopra rappresentati tutti i rettangoli delle zone macro esistenti. Scorrendo
con il mouse al di sopra di esse, queste si evidenziano di colore rosso e, al di sotto della carta, appare l’elenco
delle zone sottostanti al puntatore.
65
Figura 3-
3-37
Se l’utente preme con il tasto sinistro del mouse al di sopra di una zona selezionata, questa viene aggiunta alla
lista in basso e se la “CheckBox” alla sua sinistra è selezionata le zone vengono aggiunte a quelle inserite in
precedenza. È possibile anche ravvicinare o allontanare la visuale, tramite i due tasti raffiguranti una lente
d’ingrandimento, per avere un maggiore dettaglio.
Conclusa la ricerca, vengono presentati i risultati all’utente come in Figura 3-38.
Con il tasto “Scarica Immagine” è possibile selezionare la cartella nella quale ritrovare in seguito i files
dell’immagine. Il codice eseguito durante questa fase è contenuto nella classe “DownloadFileFunction” che
contiene il metodo “DownloadWork”.
Figura 3-
3-38
66
Esso si occupa di ricevere il file dal server, controllarne l’integrità e di seguito decomprimerlo nella cartella
scelta dall’utente. Similmente agisce anche il codice della classe “DownloadStudioFunction” per il
reperimento del file dello studio.
3.3.3 Interfaccia di amministrazione

Sempre dalla schermata principale, premendo l’ultimo tasto a destra si ha accesso
alla sezione di amministrazione visibile in Figura 3-39.
Figura 3-
3-39
Da questa è possibile modificare aggiungere ed eliminare tutti i dati contenuti nelle lookup tables.
67
Con la pressione del primo tasto in alto alla form si accede ad una schermata di ricerca uguale a quella già
vista nel capitolo precedente, che consente all’utente di trovare tutte le immagini delle quali desidera
modificare le informazioni associate.
Questa form, visibile in Figura 3-40 permette, tramite la pressione del tasto “Aggiorna dati” di inviare i
cambiamenti effettuati al server. Il tasto con la “X” rossa consente invece di eliminare l’immagine.
I tasti “Bande e Tematismi”, “Correzioni”, e “Studi” riportano a delle form simili a quelle già viste duranti le
fasi d’inserimento che consentono appunto di intervenire sulle loro associazioni alle immagini. È a
disposizione, anche in questo caso, lo strumento di conversione delle coordinate nel caso esse debbano subire
dei cambiamenti.
Figura 3-
3-40
Vediamo ora alcune di queste form utilizzate per l’amministrazione dei dati nelle
lookup tables come ad esempio quella relativa ai sensori di Figura 3-41
68
Figura
Figura 3-
3-41
Da essa è possibile inserire o modificare un sensore descrivendone tutte le caratteristiche principali. Con il
tasto “Imposta bande”, inoltre, è possibile descrivere tutte le bande offerte dal sensore in modo tale da poterle
successivamente associare ai layer dell’immagine. La form che consente queste operazioni è visibile in Figura
3-42. Com’è possibile osservare, per ogni banda l’utente può specificarne il nome, una descrizione, la
risoluzione radiometrica, la dimensione del pixel e l’inizio e la fine degli intervalli spettrali rappresentati.
Figura 3-
3-42
69
La form utilizzata per aggiungere ed aggiornare le zone è invece rappresentata in Figura 3-43.
Figura 3-
3-43
Qui si possono aggiungere nuove macro-aree e micro-aree indicandone le coordinate dei limiti superiore,
inferiore, sinistro e destro. Nel caso si desideri inserire una sottoarea è necessario spuntare la “CheckBox” in
basso a sinistra e selezionare la macro-area della quale la zona inserita è un sottoinsieme.
Un’ultima form analizzata è quella relativa agli autori degli studi. Essa è visibile in Figura 3-44 e permette di
aggiungere o modificare un autore di uno degli studi memorizzati. Dalla sezione relativa agli studi sarà
possibile poi aggiungere, come nella fase di inserimento, l’associazione studio-autore desiderata.
Figura 3-
3-44
Va ricordato che in tutte le fasi di modifica delle tabelle di lookup, l’utente viene sempre avvertito del numero
d’immagini che utilizzono la risorsa che si desidera modificare e, nel caso in cui l’utente voglia eliminare ad
esempio una fonte utilizzata da diverse immagini, questo gli sarà impedito.
Se l’utente, infatti, desidererà eliminare, ad esempio, la fonte utilizzata da 5 immagini, dovrà preventivamente
modificare tale associazione in modo da non poter creare inconsistenze nella base di dati.
70
3.3.4 Plug-in ArcMap
La realizzazione di un plug-in per l’applicazione ArcMap, richiede l’installazione dell’apposito developer kit
che fornisce gli strumenti necessari per realizzare comandi e menu di diverso tipo all’interno dell’applicazione.
Per realizzare il plug-in di questa soluzione software è stato creato un nuovo comando, denominato
GeoDatabase e lo si è inserito tra i comandi della categoria “File” dell’applicazione. Il developer kit crea
automaticamente tutto il codice necessario a registrare il nuovo comando in ArcMap ed è necessario
indicarne soltanto la categoria, un nome, un’icona e altre caratteristiche per identificarlo.
Dopo aver eseguito l’applicazione è possibile quindi ritrovare il proprio comando tra quelli disponibili ed
aggiungerlo ad esempio al menu file della barra degli strumenti come si vede in Figura 3-45.
Figura 3-
3-45
L’intera applicazione disponibile all’utente è pressoché identica a quella già vista nella modalità “stand-alone”
con l’eccezione di alcune parti.
In particolare, al momento dell’esecuzione, verrà imposto all’utente di salvare il lavoro correntemente in uso
e, quando egli sceglierà la cartella dei files da caricare nel sistema, verrà già posizionato nella directory di
lavoro corrente di ArcMap.
Allo stesso modo, quando verrà scelto di eseguire il download di un’immagine, alla fine del processo verrà
proposta l’apertura della stessa all’interno del programma.
71
3.3.5 Pagine di consultazione ASP
L’ultima interfaccia presentata è quella web che offre in sostanza la sola sezione di ricerca e consultazione viste
in precedenza con l’eccezione dell’impossibilità di eseguire il download diretto delle immagini. Per ottenerle,
l’utente ha la possibilità di compilare una form di richiesta che viene recapitata via e-mail ad un indirizzo
scelto.
In Figura 3-46 si osserva la prima pagina presentata all’utente al momento dell’accesso.
Figura 3-
3-46
Il visitatore può, anche in questo caso, applicare i filtri di ricerca che desidera o eliminarli ed inviare infine la
richiesta al server. Questo risponderà, nel caso si ottengano dei risultati, con la pagina visibile in Figura 3-58.
La pagina dei risultati è navigabile e consente di spostarsi tra i record con i tasti “Avanti” e “Indietro” oltre
che inserendo il numero della pagina nel campo di testo apposito.
Con il link in alto a sinistra si ritorna invece alla pagina di ricerca.
72
Figura 3-
3-47
Da questa pagina dei risultati sarà possibile osservare i dettagli sulle bande, le correzioni e gli studi, premendo
sugli appositi pulsanti, come visibile in Figura 3-48.
Figura 3-
3-48
Infine, se il visitatore ha il desiderio di ricevere l’immagine selezionata dovrà compilare il modulo di Figura 3-
49.
73
Figura 3-
3-49
Il detentore dell’indirizzo e-mail di destinazione preimpostato, riceverà un messaggio contenente tutti i

dettagli del richiedente e dell’immagine e potrà in seguito, se lo riterrà opportuno, inviarla ad esempio tramite
il servizio cargo dell’Università di Trieste.
3.3.6 Schema generale e gerarchia
Vengono di seguito presentati degli schemi indicanti la successione della visualizzazione delle diverse form
dell’interfaccia utente. Partendo dalla form di presentazione di Figura 3-49, si passa alle interfacce
d’inserimento di Figura 3-50, a quelle di ricerca di Figura 3-51 e a quelle di amministrazione di Figura 3-52.
Figura 3-
3-49
74
Figura 3-
3-50
Figura 3-
3-51
75
Figura 3-
3-52
76
3.4 Vista d' insieme della struttura del sistema informativo
In Figura 3-53 è illustrato il funzionamento generale di accesso al servizio e le sue componenti. Nel lato server
risiedono il database, la libreria principale e il web service che espone i web methods. Sul lato client risiedono
invece le tre differenti interfacce tutte e tre affiancate da una propria web reference indispensabile per
usufruire dei servizi offerti dal web service. Le comunicazioni tra le due parti avvengono con lo scambio di
messaggi SOAP.
Figura 3-
3-53
Nella Figura 3-54 vengono messe invece in evidenza le differenti modalità d’accesso al servizio e le unità che
entrano in comunicazione con il server centrale.
Figura 3-
3-54
Mentre i client del laboratorio usufruiscono pienamente di tutti i servizi offerti dal web service, i client esterni
(che potranno essere quelli di un dipartimento universitario o, eventualmente in futuro, utenti internet)
possono esclusivamente consultare le pagine ASP. Viene inoltre inserito un firewall tra il server e la rete
esterna al laboratorio.
77
4. Conclusioni
Con la realizzazione della soluzione software è stato posto rimedio ai problemi d’organizzazione delle
immagini utilizzate nel laboratorio, consentendo una loro facile ed efficace archiviazione, catalogazione e
successivo reperimento.
Essa consente, infatti, di memorizzare su di un server tutte le immagini d’interesse geografico, elaborate e non,
archiviandone tutte le caratteristiche e gli studi su di esse effettuati. Inoltre viene offerta la possibilità di
modificare i dati già memorizzati e di consultare l’intero archivio recuperandone le immagini presenti.
La tecnologia adottata per le comunicazioni client-server è quella dei web service che permette una totale
indipendenza delle due parti anche per quanto riguarda la piattaforma utilizzata.
La scelta di sviluppare la base dati anche in Oracle permette di portare facilmente quest’ultima su macchine
con sistemi operativi non Windows e, nel caso di un aumento esplosivo delle richieste o di dati
immagazzinati, un’eccellente scalabilità e affidabilità, che però ha un prezzo non indifferente in costi di licenza
e hardware, inoltre, a differenza del DBMS di casa Microsoft, Oracle ha, secondo me una curva di
apprendimento decisamente elevata e richiede, se lo si vuole sfruttare al meglio, corsi formali o di livello
universitario per avere una conoscenza adeguata dell’architettura, questo lavoro mi ha consentito di
approfondire la conoscenza di questo DBMS e di poterlo confrontare in modo immediato con il suo più
diretto concorrente.
Purtroppo le limitate dimensioni della base dati, il poco tempo a disposizione e le limitate capacità
dell’hardware non ci hanno consentito di eseguire dei test sui diversi tempi di risposta a seconda del carico,
questi ultimi sono però presenti in pubblicazioni specializzate e riflettono una situazione abbastanza livellata in
quanto a prestazioni e features, la scelta tra i due ricade su fattori come il supporto, il Total Cost of Ownership
e la compatibilità e trasportabilità con applicazioni e basi di dati preesistenti.
L’intera soluzione software comprende due databases distinti, una logica e le interfacce. Ogni database è
costituito da 20 tabelle, 7 viste, 56 stored procedures e 6 trigger. Il codice della logica del web service è
composto da poco più di 5400 righe, 54 classi ed offre 77 metodi ai clients. L’interfaccia per l’applicazione
Windows è costituita da 38 Forms, affiancate da più di 10850 righe di codice e 5 classi per la gestione degli
upload e download delle immagini. Altrettante Forms sono presenti nel plug-in per l’applicazione ArcMap.
L’interfaccia web è invece costituita da 6 pagine affiancate da poco più di 1100 linee di codice.
Si è cercato di ottenere uno strumento sufficientemente veloce nelle comunicazioni di rete, versatile e
modulare nelle sue componenti e semplice da utilizzare. Questi obiettivi sono stati ottenuti con l’utilizzo
della tecnologia dei web service, delle WSE 3.0, delle interfacce Windows Form e delle pagine ASP, tutti
basati sul Framework .NET.
L’utenza finale si è trovata più che soddisfatta del lavoro svolto e si è prevista una serie di aggiornamenti e
integrazioni nel futuro.
78
5. Bibliografia
• [1] Strumenti per l’analisi geografica G.I.S. e telerilevamento – Andrea Favretto – Patron editore
• [2] http://www.oracle.com/pls/db92/ranked?word=oracle+for+windows&partno=a95490 – Oracle

9i Documentation Library – Getting started for Windows
• [3] msdn2.microsoft.com – Microsoft Developer Network
• [4] msdn2.microsoft.com/en-us/library/ms977317.aspx - Web Services Enhancements (WSE) 3.0
• [5] www.epsg.org - European Petroleum Survey Group
• [6] www.icsharpcode.net/OpenSource/SharpZipLib/ - SharpZipLib
79
Ringraziamenti
Vorrei ringraziare le persone che mi hanno aiutato direttamente e indirettamente nel raggiungere questo
traguardo, purtroppo il tempo che ho impiegato toglie parecchia soddisfazione e valore a questo risultato e
quello che rimane è anche un pò di rimpianto.
Per cominciare, grazie al mio collega e amico Alberto: grazie per il tuo aiuto, i tuoi consigli e la tua amicizia.
Un grazie ad Andrea per l’opportunità di sostenere il tirocinio sotto di lui e per la gentilezza dimostratami.
Ringrazio la mia famiglia per avermi sostenuto economicamente in questa impresa, che a tratti aveva l’aspetto
di una fissazione.
Ringrazio quei professori che volontariamente o meno hanno reso la mia vita universitaria quasi piacevole
con la loro competenza, capacità di insegnare e giudicare: una minoranza che ha fatto la differenza, se non ho
abbandonato a metà il mio percorso è soprattutto grazie a voi.
Un grazie ai miei ex colleghi che hanno trascorso con me le infinite ore di lezione e le hanno rese divertenti e
interessanti.
80

Tesi - Cumin Paolo v2

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tesi - Cumin Paolo v2

Caricato da

Copyright:

Formati disponibili

UNIVERSITA’ DEGLI STUDI DI TRIESTE

SVILUPPO DI UN DATABASE IN ORACLE 9i

Paradise Lost, John Milton

He hath heart who knoweth fear, but vanquishes it; who

Thus Spake Zarathustra, F.W.Nietzsche

La soluzione software proposta deve consentire il facile immagazzinamento, reperimento e consultazione di

Durante l’elaborazione sono stati affrontati i seguenti punti:

• Sono stati definiti i requisiti, i vincoli e le specifiche.

• È stato realizzato un manuale per gli utenti.

2.1 Interviste e Obiettivi

• Caratteristiche delle immagini.

• Hardware e Software già a disposizione.

• Sistema d’organizzazione correntemente in uso (carenze e punti di forza).

• Fasi dell'intero processo.

• Obbiettivi ed aspettative del committente.

• Numero di futuri utilizzatori del servizio.

• Proposta di soluzione e confronto con il committente.

• Capire le problematiche che s’incontrano durante il processo, i miglioramenti che si desidererebbero

• L'Hardware a disposizione consiste in una decina di PC equipaggiati con processori Pentium 4 od

• Poter ricercare ed ottenere facilmente le immagini archiviate.

• Esporre l'elenco delle immagini disponibili anche da internet.

Figura 2.1 Schema iter tipico acquisto e utilizzo immagini

2.2.1 Caratteristiche delle immagini (cfr. bibliografia [1])

• Rappresentano un territorio in una ben determinata epoca.

• l'orbita del satellite sul quale il sensore è installato.

• L'altezza media mantenuta da terra.

• Una data di lancio del sensore in orbita.

• Una denominazione specifica per identificarlo.

• essa potrà avere uno o più layers.

• Potrà o meno aver subito una o più correzioni.

3.2.1 SQL Server 2005 e Oracle 9i (cfr bibliografia [2])

2.5.2 .NET Framework e C#

2.5.3 Visual Studio 2005

2.5.4.1 WSE 3.0

2.5.6 UML per la progettazione del Database e del Software

2.6 Architettura della soluzione software

2.6.3 Interfacce GUI

3.1 Progettazione e realizzazione del Database

Le stored procedures d’inserimento sono le seguenti:

Le due stored procedure “GetFileAntName” e “GetFileStudioName” sono simili e restituiscono al

Le altre due procedure “GetImmagineNextID” e “GetStudioNextID” restituisconoinvece il successivo

Il valore restituito è il numero dell’identificativo di chiave primaria che sarà

Il codice è invece il seguente:

1 TRIGGER [dbo].[ TriggerSensoreDelete]

1 TRIGGER [dbo].[ TriggerSensoreInsert]

Un ultimo trigger, molto simile al “TriggerSensoreDelete”, è il“TriggerStudioDelete” che, al momento della

3.1.6 Schema generale e gerarchia

Nell’esempio in figura si osservano, infatti, le tre funzioni “AddFonteSP”,“RemoveFonteSP” e

3.2.2 Metodi Esposti dal Servizio Web

In questo, caso i metodi di reperimento delle informazioni, corrispondenti a quellid’inserimento, che

Le funzioni utilizzate per l’aggiornamento dei dati sono le seguenti:

Il codice seguente si riferisce al metodo “UpdateStruttura”:

3.2.3 Libreria principale

1 public static StrutturaRef ReadFrom(XmlReader reader)

“ArgomentoRicerca” contiene tre campi: “campoRicerca”, “sezioneRicerca” e“condizione”. L’oggetto di

1 public int AddBanda(Banda banda)

1 public int AddStruttura(Struttura struttura, string path)

1 public Estensione[] GetEstensioni(string path)

1 while (byteRead > 0)

1 foreach (ArgomentoRicerca ricCorr in ric)

3.3 Progettazione dell' interfaccia

3.3.1 Interfaccia di inserimento

La sezione riguardante le bande e i tematismi è visibile in Figura 3-32.

3.3.2 Interfaccia di ricerca