EÖTVÖS LORÁND TUDOMÁNYEGYETEM INFORMATIKAI KAR PROGRAMOZÁSELMÉLET ÉS SZOFTVERTECHNOLÓGIAI TANSZÉK
Térinformatikai képfeldolgozó keretrendszer
Témavezető:
Szerző:
Giachetta Roberto
Ginal Eszter
egyetemi tanársegéd,
programtervező informatikus BSc,
ELTE IK PSZT
nappali tagozat
Budapest, 2011
A projekt
az Európai Unió
támogatásával,
az Európai Szociális
Alap
társfinanszírozásával valósul meg (a támogatás száma TÁMOP 4.2.1./B-09/1/KMR2010-0003).
Tartalomjegyzék 1.
Bevezetés ........................................................................................................ 3
2.
Technológiai háttér ......................................................................................... 6
3.
4.
2.1
Windows szolgáltatások ....................................................................... 6
2.2
MongoDB ............................................................................................ 7
2.3
WPF ..................................................................................................... 9
2.4
XML .................................................................................................. 10
2.5
ShapeFile ........................................................................................... 11
2.6
A GeoTIFF......................................................................................... 12
Felhasználói dokumentáció ........................................................................... 13 3.1
Előfeltételek és a rendszer telepítése ................................................... 13
3.2
Kezdőképernyő .................................................................................. 15
3.3
A File menü ....................................................................................... 16
3.4
A Server menü ................................................................................... 17
3.5
A térkép nagyítása és mozgatása......................................................... 20
3.6
A szerver ............................................................................................ 21
Fejlesztői dokumentáció ................................................................................ 22 4.1
A program fejlesztési folyamata ......................................................... 22
4.1.1
MongoDB ....................................................................................... 22
4.1.2
Windows szolgáltatások.................................................................. 23
4.1.3
Az adatbázis szerkezete .................................................................. 23
4.2
A rendszer felépítése .......................................................................... 24
4.3
A szerver ............................................................................................ 26
4.4
Az AEGIS.Data.................................................................................. 28
4.5
Az AEGIS.DesktopClient ................................................................... 30
4.6
Az AEGIS.Core ................................................................................. 33
4.7
Az AEGIS.IO ..................................................................................... 35
5.
4.8
Implementációs megoldások............................................................... 37
4.9
Tesztelés ............................................................................................ 37
Összegzés ..................................................................................................... 39
Irodalomjegyzék ................................................................................................... 40
1. Bevezetés A térképkészítés tudománya a régi történelmi múltba tekint vissza. A történelmi kutatások kimutatták, hogy az ember hamarabb rajzolt, mint írt. Már az ősemberek is használtak általuk rajzolt térképeket a lakóhelyükről vagy akár távolabbi tájakról is. A térképek készítése segítség volt az emlékezetben, kommunikációban és a társadalmi együttműködésben is. Idővel egyre pontosabb térképek születtek a geometriai pontosság növekedésével. Az 1. ábrán egy ókori térkép látható.
1. ábra: Ptolemaiosz világtérképe [1]
A nyomtatás felfedezése után egyre elterjedtebbek lettek a térképek. A XV. században felelevenítették és továbbfejlesztették az ókorban használt térképkészítési technikákat. A térképészet fellendülését elősegítették a kor nagy földrajzi felfedezései, a megélénkült gazdasági élet, a kereskedelem és az áruszállítás fokozódása. Ezek a tényezők követelték a pontosabb, tájékozódásra alkalmas térképeket. Először a tengeri, majd a szárazföldi térképek fejlődtek. A XVI. században már a városokat, utakat, hídakat, a jellemző várakat, templomokat is felüntetik a térképeken, de a domborzatot még mindig oldalnézetben vagy madártávlatban ábrázolták. A következő századra sokat változott a domborzat ábrázolása, megjelenik a csíkozás és a szintvonalakkal való ábrázolás. Megkezdődtek a nagy területet felölelő, részletes topográfiai felmérések is és elsősorban a katonai szempontok miatt fejlődik a háromdimenziós, a domborzatot jól érzékeltető ábrázolási mód.
3
Az 1990-es évek elején a számítástechnika térhódításával mélyreható változásokat születtek a térképkészítés terém. Ma már szinte minden térkép számítógépen készül.
2. ábra: digitális térkép [1]
A digitális térkép (2. ábra) a digitális tárgymodellből és a hozzá tartozó megjelenítési modellből áll. A megjelenítés lehet valós és lehet virtuális is. A térképek a térvonatkozású információ megjelenítésére szolgálnak. Az analóg, statikus térképek szerepe lecsökkent, az interaktív, dinamikus térképek javára. A szakdolgozat célja egy kliens-szerver architektúrára épülő szoftverrendszer egyszerűsített modelljének elkészítése, amely segítségével letölthetőek és módosíthatóak a digitális térképek. Kétféle térképet is képes a keretprogram feldolgozni, a vektoros és a raszteres térképeket egyaránt. Mivel vannak már hasonló szoftverek a piacon, ezért fontos, hogy hatékonyan és gyorsan kezeljük az információkat. Fontos szerepe van a felhasználóbarát megjelenítésnek és használatnak. A hálózaton történő, biztonságos kommunikáción alapuló szoftverek lényeges előnyökkel szolgálnak. A felhasználók egy grafikus felületen dolgoznak, az adatbázis pedig egy központi szerveren van, így elkerülhető az adatok redundáns tárolása. A kliens és a szerver között TCP kapcsolat épül ki. A hálózaton az adatok küldése XML szérializáció után valósul meg. A program nem rendelkezik teljeskörű szolgáltatásokkal, azoknak csak egy részét valósítja meg. A program .NET keretrendszerre épül, C# nyelvet használva. Az adatbázis alapja a MongoDB dokumentum elvű adatbázis-kezelő rendszer. A kliens felület WPF technológiára épül. A MongoDB használatával gyors az adatelérés és
4
sémafüggetlenségét kihasználva, egy adatbázisban tárolhatjuk hatékonyan mind a raszteres, mind a vektoros térképeket. A szakdolgozat az AEGIS projekt részeként valósult meg.
5
2.
Technológiai háttér Ebben a fejezetben a program fejlesztéséhez felhasznált technológiai háttér kerül
ismertetésre. A következő pontok jelentik a kiindulási koncepciókat: Windows szolgáltatás, dokumentum elvű adatbázis-kezelés, WPF grafikus felület, XML a ShapeFile és a GeoTIFF fájlok felépítése.
2.1 Windows szolgáltatások A Windows szolgáltatások olyan alkalmazások, amelyek nem rendelkeznek felülettel, a Windows operációs rendszer a háttérben futtatja őket. A szolgáltatásokat lehetőségünk van automatikusan kezelni, elindítani a Windows indításakor, s leállítani a Windows leállításakor vagy szüneteltetni. Ennek előnye az, hogy az alkalmazás nem igényel felhasználói beavatkozást a futás során. Előnyös szolgáltatásokat használni egy szerveren, amikor szükségünk van a hosszútávon futó alkalmazásra. A szolgáltatások nem zavarják az adott gépen dolgozó felhasználókat sem a munkájukban. Lehetőséget kapunk arra, hogy a szolgáltatásokat biztonságos környezetben futtassuk, megadva a felhasználót, aki futtathatja. Erről bővebben lehet olvasni az MSDN honlapján levő dokumentációban [2]. Fontos tudni, hogy a szolgáltatás betöltése nem egyezik meg a szolgáltatás elindításával. Mivel a szolgáltatások olyan alkalmazások, amelyek nem interaktívak, nincs
lehetőségünk
felhasználói beavatkozásra.
Ha ezt
mégis
megpróbáljuk,
előfordulhat, hogy a szolgáltatás leáll. Ezért is célszerű minden fontos eseményt naplózni, így nyomon követhetőek az esetleges hibák. A .NET keretrendszer nem támogatja azt, hogy egy szolgáltatás más interaktív munkaállomásokkal interakcióba kerüljön. Élettartama során több állapoton is átmegy egy szolgáltatás. Élettartalma elején történik meg a telepítése az adott számítógépre, ezt követi a betöltés a Services Control Manager-be. Betöltés után a szolgáltatást el kell indítani, ezután kezdődik meg a működése. A szolgáltatás elindítható a Server Explorerből manuálisan vagy a programból a Start metódussal, ez hívja meg az OnStart metódust.
6
Egy szolgáltatás mindaddig futhat, amíg le nem álljuk, nem szüneteltetjük vagy ki nem kapcsoljuk a számítógépet. Három állapota lehet: futtatott, szüneteltetett vagy leállítot. Lehet egy függőben levő állapota is (pending), ekkor egy parancs végrehajtására vár. A szolgáltatást szüneteltethető, leállítható vagy szüneteltetés után folytatható a futása. Ezt a Services Control Managerben megtehetjük maniálisan vagy a programban a megfelelő metódusok meghívásával (OnStop, OnPause, OnResume).
2.2 MongoDB A térképek kezelésekor sok adatot kell majd tárolnunk. Ennek érdekében fontos, hogy jól válasszuk meg az adatbázist. A gyakorlatban két típusú adatbázist használunk az adatok elérése szempontjából: − Relációs adatbázis (Relational Database Management System), amelyben az adatokat a relációs adatmodell elvén hozzuk létre, a meghatározott relációk egy véges halmaza. A relációs adatmodell legfontosabb alkotóeleme a matematikai
reláció.
Az
adatmodellek
definiálják
a
használt
adatszerkezeteket és a rajtuk definiált műveleteket. A relációs adatmodell előnye az egységes sémadefiníciók, a pontos leírások, valamint, hogy a műveletek adatbázis szinten vannak meghatározva. − Dokumentum vagy objemtum elvű adatbázis (Object-Oriented Database Management System), amely intelligens elemekből épül fel. Az intelligencia azt jelenti, hogy az egyes adatbázis elemek (objektumok) „tudják”, hogy kik ők, mire használhatók, s miként kapcsolódnak a többi adatbázis-elemhez, tehát bármennyire összetett típusok lehetnek. A szakdolgozat alapját a MongoDB dokumentum elvű adatbázis képezi, ezért ennek működése és felépítése kerül részletesebben ismertetésre. A dokumentum elvű adatbázisok előnye az, hogy nincs sémadefiníció, így a szerkezete lazább, mint a relációs adatbázisoké. Ezért az adatbázis könnyebben igazítható a programhoz, rugalmasan módosítható a programban fellépő módosítások
7
esetén, így egyszerűbb a fejlesztők feladata. Mivel az adatbázisban kétféle térképet akarunk tárolni, ezért dokumentum elvű adatbázis használatával elég 1 adatbázist használni a térképeknek. MongoDB-ben az adatok elérése gyors és hatékony, ez előny számunkra a programban. A használat során nem kell adatbázisműveleteket megvalósítanunk, elég csak az kiolvasás és a mentés műveleteket megvalósítani. A dokumentum attribútumokból áll, amelynek van neve és értéke, a rájuk történő hivatkozás pedig név alapján történik. Az értékük rendszerint elég összetett is lehet, egészen a primitív típusoktól kezdve akár egy másik dokumentum is előfordulhat, mint érték. Elsősorban az XML adatbázisrendszerek objektumelvűek. A MongoDB adatbázisrendszer JSON alapú adatkezelő rendszer, ami skálázható és magas teljesítményű. Felépítését tekintve gyűjteményekből (collection) áll, ezek elemei a dokumentumok (document), amelyek már tetszőleges attribútumokkal, értékekkel rendelkeznek (3. ábra). Mivel nincs sémadefiníció, az adatbázis kevésbé korlátozott, mint a relációs adatbázisok. A dokumentumok felépítése hierarchikus, mivel elhelyezkedésük flexibilis és egymásba ágyazhatóak. Az adatbázis felépítése az 3. ábrán látható. Az adatbázis TCP kapcsolaton keresztül kommunikál egy szerverrel, ahonnan az adatokat egy interfészen keresztül teszi elérhetővé a felhasználók számára.
Attribute1 Attributei Document1 Collection1 Documentl Database
Documentk
GridFS file
Collectionn
3. ábra: Egy MongoDB adatbázis felépítése
8
Azáltal, hogy a dokumentumnak nincsen előre rögzített típusa, könnyedén megfeleltethetőek objektumoknak, amelyek kezelése egyszerű a manapság használt objektumorientált
programozási
nyelvekben.
A
dokumentumok
reprezentálása
típusfüggetlen objektumok formájában történik. Előnyt jelent a nagymennyiségű adatkezelés esetén a dokumentum elvű hierarchia, mivel az ilyen adatbázisok fejlesztésének célja a minél gyorsabb adatelérés kezelése volt. Támogatja a replikálást, valamint a nagyméretű objektumok tárolását az adatbázison belüli saját fájlrendszerben, amit a MongoDB esetén GridFS-nek neveznek. A nagyméretű objektumokat kisebb részegységekre bontva tárolja, a fájl neve tartalmazza a meta-információkat, a típust és a fordítónak szükséges egyéb tájékoztatást. A GridFS-rendszerben kezeli a képek mentését és visszatöltését is, amit használunk a raszteres térképek esetén. Bővebb leírás található a MongoDB C# API-ban [3].
2.3 WPF A WPF (Windows Presentation Foundation) egy grafikus felhasználói keretrendszer, amely lehetőve teszi a gazdag, interaktív kliens alkalmazások létrehozását. A .NET Framework 3.0 verzióval jelent meg. Az XAML (eXtensible Application Markup Language) XML alapú leíró nyelvet használja, amely lehetővé teszi a grafikus felület teljes leírását. A WPF felbontásfüggetlen és vektor alapú megjelenítést alkalmaz. Rendelkezik beépített grafikus én animációs támogatással, az animációk direkt megfogalmazhatóak és végrehajthatóak. Lehetőség van stílusok és a megjelenítés átdefiniálására, megjelenítési
tulajdonságok
vezérlőfüggetlen,
erőforrásalapú
tárolására.
Kijelzőfüggetlen képpontot alkalmaz, amelyben a DPI felbontás nem befolyásolja a mértet. A megjelenítés és a vezérlet függetlenek. A WPF lehetővé teszi, hogy dinamikus, adatvezérelt rendszereket hozzunk létre. Az adatkötés alapvető szerepet kap, minden egyes réteg rendelkezik vele.
9
2.4 XML Az XML egy általános célú leíró nyelv, speciális célú leíró nyelvek létrehozására. Az XML egy szabályhalmaz a kódolandó dokumentum átalakításához. A megalkotáskor fontos szerepet kapott az egyszerűség, a generálhatóság és a használhatóság az Interneten keresztül, ezért széles körben felhasználható. Számos programozási nyelv ad lehetőséget az XML adatok feldolgozására. Felépítésileg tag-ekből, attribútumokból és elemekből épül fel. Egy XML dokumentum szövegből áll, Unicode karakterek sorozata. Amíg az XML megköveteli az UTF-8 és UTF-16 kódolás támogatását, melyek elterjedtek, addig más kódolások (például ISO-8859) nem túl gyakoriak. Egy helyesen formázott XML dokumentumnak az alábbi szabályoknak kell megfelelnie: − Egyetlen gyökér elem lehet egy dokumentumban. Azonban az XML deklaráció, feldolgozó utasítások és megjegyzések megelőzhetik a gyökér elemet. − Az elemeket mind nyitó (<), mind záró (>) tag-eknek kell határolni. − Minden attribútum érték idézőjelek között van, amely lehet szimpla(') vagy dupla(") idézőjelek is. A záró idézőjel meg kell egyezzena nyitó idézőjellel. − A tag-ek egymásba ágyazhatók, de nem lehetnek átfedők. Mindegyik nem gyökér elemet másik elemnek kell magában foglalnia. − Az elem nevek kisbetű-nagybetű érzékenyek. A programban a kliens és a szerver közti hálózaton a különböző rétegek XML dokumentummá szérializálva kerülnek átküldésre. Minden egyes adatküldés előtt megtörténik a szérializálása a megfelelő objektumnak, majd minden egyes fogadásnál az XML dokumentum deszérializálása után dolgozik vele a program. Példa a program által generát XML dokumentum tartalmára:
10
2.5 ShapeFile A ShapeFile formátum az elsőszámú formátuma a vektoros térinformatikai adattárolásnak. Ezt a formátumot a legtöbb térinformatikai szoftver támogatja. Egyszerű szerkezetet biztosít a tárolásra, az alakzatokhoz leíró adatokat rendel. Nem őrzi meg a topológiai információkat. A ShapeFile formátum fájlok halmazából áll. Minden fájlnévnek kötelezően meg kell egyeznie. A szükséges fájlok: − .shp: a geometriai információk tárolója − .shx: az shp fájl indexeként tekinthető, azzal ellentétben fix méretű rekordokat tárol, így könnyítve meg az adatok közti keresést − .dbf: egy dBase III típusú adatbázis fájl, melyben a Shapefile-ban tárolt összes alakzathoz egy-egy bejegyzés szerepel az adott alakzathoz tartozó különböző metainformációkkal A teljes geometriai leírás a .shp fájlban van az X és Y koordináták segítségével, ugyanis ezek reprezentálják a földrajzi koordinátákat is. A fájl bináris, fejlécből és az ezt követő rekordokból áll. Minden rekord egy alakzattípust és annak a leírását tárolja. Lehetőség van üres (null) alakzatok megadására is. A .shx fájl követi a .shp fájl szerkezetét. A leíró adatok dBase III formátumnak felelnek meg, de ezek korlátozottak, mivel a mezőnevek hossza és típusa meghatározott és a Unicode karakterkészletet sem támogatja. A geometriai leírás megengedi, hogy egy fájlba tetszőleges alakzatokat helyezzünk, azonban a specifikáció kiköti, hogy egy fájlban azonosos típusú alakzatok lehetnek. A megkötéseknek megfelelő ShapeFile csak egy vektoros réteg adatait képes eltárolni és a
11
különböző rétegeket külön fájlhalmazokba kell helyezni. Részletesebb ismertetés a technikai dokumentációban [4].
2.6 A GeoTIFF GeoTIFF-nek (GeoTagged Image File)
nevezzük a térbeli vonatkozásokat
tartalmazó TIFF fájltípust. Alapja a TIFF 6.0 specifikáció, képes koordinátarendszerek és azok tulajdonságainak kezelésére. Nincs önálló kiterjesztése, csak megszorítása az IFD mezőkre. Összesen 6 mezőt használ a térbeli információk tárolására. Ezek a mezők összetettek, önálló szerkezettel és formátummal bírnak és egy egyedi geokulccsal (GeoKey). Az elsődlegesen használt mező a kulcsok nyilvántartása. A kulcsnyilvántartás tömbszerűen tárolja a kulcsokat, 4-es blokkonként. A földi pozíciók kezeléséhez a GeoTIFF szerkezeten belük kezelni kell a rasztertér, illetve a modelltér információit. A modelltér a tényleges földi pozíciókat tartalmazza, de explicit módon nincs eltárolva a fájlban. A rasztertér megadja, hogy milyen vonatkozásban kell kezelni a képpontokat, amelyek lehetnek: − pont alapúak: minden képpont egy koordinátát reprezentál, − terület alapú: a képpontok sarokpontjai koordináták. Részletesebb ismertetése a GeoTIFF specifikációban [5].
12
3.
Felhasználói dokumentáció A felhasználói dokumentációban két oldalról kerül ismertetésre a rendszer
működése: a rendszergazdai szemszögből, aki a telepítést végzi, valamint a szerver oldalról felügyeli, illetve a kliens szempontjából, aki használja a kliens felületet. Rendszergazdai szemszögből a rendszer felépítése az 4. ábrán látható.
Kliens megjelenítés
Kliens logika
Windows Service
MongoDB
4. ábra: A rendszer felépítése
3.1 Előfeltételek és a rendszer telepítése A rendszer telepítéséhez szükséges minimális hardver-, és szoftverigények: − 1 Ghz-es processzor, − 1 GB memória, − Microsoft Windows XP vagy újabb operációsrendszer. A rendszer telepítését megelőzően szükségünk van az alábbi szoftverkörnyezetre: − Microsoft .Net 4.0 vagy későbbi keretrendszer,
13
− MongoDB 1.0 vagy későbbi adatbázis-kezelő rendszer. A MongDB dokumentum elvű adatbázis-kezelő elérhető a hivatalos honlapon [6]. Windows platformra a fájl letöltését követően kicsomagoljuk a .zip kiterjesztésű fájlt. A rendszernek készítenünk kell a gyökérkönyvtárban egy data és egy db könyvtárat (C:\data\db), ide kerülnek majd az adatbázis-gyűjtemények. A szervert a mongod.exe parancsfájllal indíthatjuk. A .NET keretrendszer telepítője telepítési útmutatóval letölthető a hivatalos honlapról [7]. Bővebben a .NET keretrendszerről a hivatalos dokumentációban [8]. 3.1.1 A rendszer telepítése a kliens oldalról A program a setup.exe fájllal telepíthető. A telepítés varázsló segítségével történik. Első lépésben a telepítő közli, hogy az AEGIS Server-t akarja telepíteni a számítógépre. A Next gombra kattintva megadható az útvonal, ahová szeretnénk telepíteni a szervert. Ugyanitt beállítható, hogy milyen felhasználók használhatják a programot. Ismét a Next gombra kattintva a varázsló jelzi, hogy a szerver készen áll a telepítésre, majd ismét a Next gombra kattintva feltelepül. A telepítés véget ér a Close gombra kattintással. Bármelyik lépésben, ha a Cancel gombra kattintunk, a telepítés leáll. Lehetőség van a Back gombbal visszatérni az előző lépéshez, ha valamit nem megfelelően állítottunk be. A szolgáltatás elindításához újra kell indítani a számítópet, s ekkor automatikusan elindul a szolgáltatás, vagy lehetőség van újraindítás nélkül is elindítani, manuálisan. Telepítés után már használható a kliens alkalmazás.
3.1.2 A rendszer telepítése rendszergazda oldalról A programot a setup.exe fájllal fel kell telepíteni, beállítva az utvonalat. Ekkor egy windows szolgáltatást telepítünk, amellyel egy szerver fut. A szolgáltatást és a szerver állapota felügyelhető a Vezérlőpult/Felügyeleti eszközök/Szolgáltatások menüpont alatt érhető el AEGIS Server néven. Itt a szerver leállítható és ujraindítható. Szerver leállításkor a csatlakozott klienseknek újra kell csatlakozni az adatbázis eléréshez, de ez nem jár információ elvesztésével. A szerver TCP kapcsolaton várakozik a kliensek csatlakozására a 3399-es porton. A szerver rendelkezik adatbáziseléréssel, így szolgálja
14
ki a klienseket. A program működéséhez szerver oldalon fel kell telepítsük a MongoDB adatbázist. Ennek a telepítése a 3.1.1 pontban leírtak alapján működik.
3.2 Kezdőképernyő A kliens felület elindításakor megjelenik egy ablak. Ez látható az 5. ábrán.
5. ábra: Kezdőképernyő
15
3.3 A File menü
6. ábra: A File menü
A File menüpontban (6. ábra) az Open menüponttal lehetőségünk van egy új réteg betöltésére, amely lehet ShapeFile vagy GeoTIFF. A betöltött fájlt megjelenítünk a felületen levő ablakokban (7. ábra). A program kétféle réteget támogat: a raszteres és a vektoros rétegeket. Ezután aktiválódnak a nagyítást és a mozgatás végző eszközök. Nagyítás vagy mozgatás után az ablakban a térkép megfelelő része látható.
7. ábra: Megjelenített térkép
16
Betöltés után az ablak alsó részében található listában megjelennek a réteg információi. A 8. ábrán látható a File menü betöltés utáni állapota.
8. ábra: A File menü betöltés után
Betöltött réteg esetén aktiválódik az Edit layerInfo menüpont, amellyel az adott réteg információi (réteg neve, a szerzői jog, illetve a leírása) módosíthatóak (9. ábra). Minden módosítás után az ablak alsó részében levő listában frissítődnek az adatok. A listában csak az értékkel rendelkező adatok látszanak.
9. ábra: A réteg információinak megadása
3.4 A Server menü
10. ábra: A Server menü
17
A Server menüben (10. ábra) léphetünk kapcsolatba a szerverrel és az adatbázissal, végezhetünk műveleteket az adatbázisban. Szerver hiba esetén a kliensnek megszűnik a kapcsolata a szerverrel, ekkor újra kell csatlakozni. Ez csak akkor derül ki, amikor a felhasználó üzenetet akar küldeni a szervernek.
11. ábra: Csatlakozás a szerverhez
A Connect to server menüpontot választva kapcsolódhatunk a szerverre (11. ábra). Ekkor előjön egy ablak, amelyben meg kell adnunk a szerver IP címét. A kliens csatlakozni próbál a címre. Sikertelenség esetén újra csatlakozhatunk. Sikeres csatlakozás esetén aktiválódik a Connect to database menüpont és a Connect to server menüpont helyett Disconnect menüpont jelenik meg, amellyel le tudunk kapcsolódni a szerverről (12. ábra). Lekapcsolódáskor ismét inaktívvá válnak a menüpontok. A kliens és a szerver között TCP kapcsolatot hozunk létre csatlakozáskor. Ezt a kapcsolat csak akkor bontjuk fel, amikor a kliens felületet bezárta a felhasználó.
12. ábra: A Server menü csatlakozás után
Lehetőségünk van csatlakozni az adatbázis-szerverhez a Connect to database menüponttal. A csatlakozáshoz előjön egy ablak, amelyben felhasználónevet és jelszót kell megadni (13. ábra). A helyességét a szerver egy adatbázisból kéri le, ezért csak regisztrált felhasználóknak van lehetőségük az adatbázist használni. Amennyiben ezek jó adatok lehetőségünk nyílik egy reteg mentésére illetve egy gyűjtemény lekérésére.
18
Rossz felhasználónév vagy jelszó esetén újra megpróbálhatunk csatlakozni az adatbázishoz.
13. ábra: Csatlakozás az adatbázishoz
Az adatbázishoz való kapcsolódás után lehetőség nyílik a térképek mentésére és lekérésére (14. ábra).
14. ábra: A Server menü adatbáziskapcsolódás után
A Save to database menüpontot választva az aktuálisan betöltött térképet elmenthetjük az adatbázisba. Ha nincs betöltve térkép vagy nem megfelelő a formátuma, hibaüzenetet kapunk.
15. ábra: Gyűjtemény lekérése
A Get collection menüpontot választva előjön egy ablak, amelyben kiválaszthatjuk, hogy a vektoros vagy a raszteres rétegeket szeretnénk lekérdezni az adatbázisból (15. ábra). Ekkor egy listában megjelennek az adott típusú elemek alapinformáció. A listában
19
egy elemre kattintva lekérhetjük a teljes réteget az adatbázisból. A megkapott réteget betölti a program és az alapinformációit a kliens felületen kilistázza (16. ábra). A megjelnő rétegek valamelyikére kattintva, majd OK gombot nyomva, a szerver elküldi az adott térképet a kliensnek.
16. ábra: A gyűjteményeket megjelenítő ablak
3.5 A térkép nagyítása és mozgatása A betöltött térképet nagyíthatjuk és kicsinyíthetjuk a + illetve – gombokra kattintva, (maximum kétszeresére nagyítható) illetve a csúszkát használva. A Left, Right, Up, Down gombokra kattintva a nagyított képet tolhatjuk balra, jobbra, fel illetve le. A 17. ábrán láthatóak az erre szolgáló gombok.
20
17. ábra: A nagyítást és mozgatást végző gombok
3.6 A szerver A szerver telepítése után a szolgáltatás megjelenik a Windows Services Control Manager felületen. Indítás után a szerver naplózza az eseményeket. A naplóból kiderül, hogy a szerver elindult-t, illetve, hogy milyen IP címekről és portokról csatlakoztak hozzá a kliensek. Hiba esetén a naplóból visszaolvasható a hiba oka. A szerver kommunikál az adatbázissal.
21
4. Fejlesztői dokumentáció A szakdolgozat célja egy kliens-szerver alapú térinformatikai keretrendszer egyszerű modelljének fejlesztése, amely alkalmas raszteres, illetve vektoros térképek adatbázisba importálására, visszatöltésére, és megjelenítésére. A program alkalmas alapja a rendszer későbbi fejlesztéseinek. Felhasznált technológiák: − C# nyelv − WPF − MongoDB
4.1 A program fejlesztési folyamata A fejlesztés mérföldkövek alapján történt. Az első mérföldkő a tervezés volt. Ennek keretében elkészültek a megfelelő osztálydiagramok és kapcsolataik, a felhasználói esetek diagramja. A következő lépést a .NET keretrendszer, a Microsoft Visual Studio 2010 és a MongoDB telepítése jelentette.
4.1.1 MongoDB A MongoDB adatbázis-kezelő rendszer működéséhez először el kell indítani a szerverét (mongod.exe), ezután TCP kapcsolaton csatlakozhat a felhasználó, fejlesztő az adatbázishoz. Az adatbázis az elemek tárolására dokumentumokat használt, amelyeket gyűjteményekben tárol, így a használathoz a parancsokat ennek megfelelően kell megadnunk. A MongoDB-nek több programozási nyelvhez is biztosít felületet. Ebben a programban a .NET API került felhasználásra.
Az API szinkron TCP kapcsolatot
használ az adatbázissal való kommunikáláshoz.
22
4.1.2 Windows szolgáltatások A Windows szolgáltatás egy olyan alkalmazás amelynek nincs grafikus felülete, nem igényel felhasználói beavatkozást és a háttérben fut, amíg fut a Windows. Ezeket a Vezérlőpulton keresztül kezelhetjük. Beállítható a szolgáltatás futásának módja direkt módon vagy előre beállítottan is (pl. automatikus indítása a rendszer indításakor vagy automatikus
leállítása).
A szolgáltatás kommunikálhat
más programokkal és
adatbázisokkal. Lehetőséget kapunk a naplózásra. Szolgáltatásokat létrehozhatunk Microsoft Visual Studio segítségével egy Windows Service projekttípussal. Szolgáltatásokat könnyen létrehozhatunk telepíthető alkalmazás megírásával. Erre van lehetőségünk Visual Studioban. A Visual Studioban sablonok is rendelkezésünkre állnak a szolgáltatás létrehozásához. Az alkalmazás megírása és lefordítása után parancssorból futtatva az InstallUtil.exe parancsfájl
segítségével telepítjük
a
szolgáltatást. Másik lehetőség a telepítésre a Visual Studio telepítési funkciója. Telepítés után a Vezérlőpulton felügyelhetjük a szolgáltatást. Itt lehet manuálisan indítani, leállítani és figyelni a naplózást. A szolgáltatások funkcióikat tekintve eltérnek a többi alkalmazástól. Minden egyes módosítás után nem elég csak újra lefordítani, hanem ismét telepíteni kell, hogy használhassuk a legfrissebb verziót. A szolgáltatást nem lehet nyomonkövetni vagy Visual Studioból az F5 vagy F11 gombokkal indítani. A szolgáltatásokhoz létre kell hozni telepítő komponenseket. A komponensek telepítik fel és regisztrálják a szolgáltatást a szerveren és egy bejegyzést hoznak létre a kezelőfelületen (Windows Services Control Manager). A szolgáltatás Main függvénye tartalmazza a Run eljárást, amely betölti a szolgáltatást a Services Control Manager-ben a kívánt beállításokkal. Ha a Visual Studio sablon osztályait használjuk, akkor ezt az eljárást nem kell megírnunk.
4.1.3 Az adatbázis szerkezete A .NET lehetőséget ad a MongoDB használatára. Ehhez a MongoDB.Driver-re van szükség illetve a MongoDB.GridFS-re a raszteres képek eltárolására. A program három adatbázist használ. Az első a központi adatbázis, melynek neve AEGISDB. Az adatbázis két gyűjteményből áll, a VectorLayer és a RasterLayer
23
gyűjteményekből. Minden egyes réteg a megfelelő gyűjteményben található. RasterLayer esetén a dokumentumban tárolom a kép méreteit illetve a radiometrikus felbontását, majd magát a képet egy GridFS fájlban. Vektoros réteg esetén tárolva vannak a réteg attribútumai, a FeatureType, a Feature elemekből álló lista és a lista hossza. A Feature típusú elemeket új dokumentumban, így a dokumentumok egymásba vannak ágyazva. Mindkét réteghez tárolva vannak a réteg információi is. A másik adatbázis a UserInfo. Egy gyűjteménye van az adatbázisnak, az Info gyűjtemény. Ebben vannak a eltárolva a felhasználónevek és a jelszavak. Az központi adatbázisba csak felhasználók tudnak menteni, módosítani és rétegeket lekérdezni. Ehhez az szükséges, hogy a kliensben megadott felhasználónév és jelszó páros szerepeljen az adatbázisban. A harmadik adatbázis az AEGISInfo. Az adatábiznak egy gyűjteménye van, a SystemInfo. Az ebben található dokumentum tárolja a vektoros réteg és a raszteres réteg legutóbbi azonosítóját, amelyik a központi adatbázisba került. Az azonosító felépítése két részből áll. Vektoros réteg esetén 1.x, ahol x egy pozítiv természetes szám. Raszteres réteg esetén pedig 2.x, ahol x egy pozítiv természetes szám. Mindkét réteg esetén az x 1től nő. Amikor új elemet teszünk az adatbázisba, akkor kiolvassuk a megfelelő értéket a réteg típusától függően, a második számot eggyel megnöveljük, ez lesz az új elem azonosítója, majd ezt az új azonosítót visszamentjük az adatbázisba. Felépítése: LayerType és MaxValue.
4.2 A rendszer felépítése A rendszer öt komponensből áll. Az első komponense az szerver, amely biztosítja a kapcsolatot a szerver és a kliens között és felelős az adatbázis-kapcsolatért. Másik fontos összetevő az AEGIS.Core komponens, amelyet több komponens is használ. Ebben vannak megvalósítva a rétegek tárolásához szükséges osztályok. Harmadik
komponens
az
AEGIS.Data,
amelyben
az
adatbázis-kapcsolat
megvalósítása szerepel.
24
Negyedik komponens az AEGIS.DesktopClient, egy GUI-s alkalmazás, amely segítségével a felhasználók csatlakozni tudnak a szerverhez és az adatbázishoz, illetve az adatbázisba tudnak menteni vagy réteget lekérni. Az ötödik komponens az AEGIS.IO, ez felel a rétegek megjelenítéséért. A szolgáltatás futtatja a szervert, amire a kliens alkalmazás csatlakozik. A szerver kommunikál az adatbázissal, amelyben tároljuk a raszteres és vektoros térképeket. A szerver kezeli a kliens kéréseit és kiszolgálja azokat. A szerver ellenőrzi, hogy a kliens által küldött adatok helyesek legyenek. Amennyiben nem tudja kiszolgálni a klienst, választ küld a sikertelenségről. A kliens megjelníti a térképeket, módosíthatja az információit, elküldheti a szervernek, illetve a szervertől lekérhet egyszerre egy térképet. A kliens és a szerver között aszinkron TCP kapcsolatot építünk fel. Ebben az esetben csak elindítjuk a kérést, majd lefut egy párhuzamos metódus (callback), ha az üzenet célba ért. Ezalatt a program nem blokkolódik. A 18. ábrán látható a rendszer komponens diagramja.
18. ábra: Komponens diagram
25
4.3 A szerver Az AEGIS.Server-ben a szerver működéséhez elengedhetetlen osztálydefiníciók találhatóak. Ezek bonyolítják le a kliens és a szerver közötti kommunikációt, valamint fenntartják a kapcsolatot az adatbázis-szerverrel, mentik az adatokat, illetve visszakeresik azokat. A 19. ábrán látható a szerver osztálydiagramja.
19. ábra: A szerver osztálydiagramja
A ServerService egy Windows szolgáltatás, amely az operációs rendszer indítása után elindul. Rendeltetése szerint folyamatosan futnia kell, hogy várja a kliensektől a csatlakozási szándékot, ezért is van megvalósítva szolgáltatásként, hogy nem kell mindig elindítani, hanem automatikusan induljon a rendszerrel együtt.
26
A szolgáltatás tartalmaz egy OnStart és egy OnStop metódust, amelyben előbbi elindítja a szervert, utóbbi pedig megszünteti a szerver futását. Ha ezek megtörténnek rögzítünk rólunk egy-egy bejegyzést a szolgáltatás eseménynaplójába. A Program osztály gondoskodik a szolgáltatás elindításáról. A ProjectInstaller osztály a szolgáltatás telepítését teszi lehetővé. Itt adható meg a neve, az indítás módja (automatikus vagy kézi), ezenkívül az eseménynapló elnevezése is itt állítható be. Ehhez tartozik a AEGISSetup nevű projekt, amely segítségével tudjuk feltelepíteni a szolgáltatást. A Server osztály valósítja meg szolgáltatás alapvető működését, azaz kiépíti egy külön szálban a TCP kapcsolatot a klienssel, majd várja a csatlakozási szándékot a kliensek részéről a 3399-es porton. Ha a csatlakozás megtörtént, létrehoz egy Client típusú objektumot, majd üzenetfogadás esetén a megfelelő választ küldi vissza a kliensnek. Ezen felül felügyeli a klienseket szintén külön szálba, ha valamelyik kapcsolata már nem áll fenn a szerverrel, törli a az adott klienst a listából. Ezeket a szálak a Start metódussal indíthatóak, amelyet a Run metódusban hívunk meg. A Stop metódusban lényegében leállítjuk a szervert és a vele folytatott összes kommunikációt is. A kliens különböző üzeneteket küldhet a szervernek: kapcsolódni akar a szerverhez, kapcsolódni akar az adatbázishoz, egy térképet szeretne az adatbázisba menteni, lekéri egy megadott gyűjteményben szereplő elemeket, egy adott térképet kér le az adatbázisból. Ennek megfelelően feldolgozza a szervertől kapott információt a végrehajtás sikeréről, majd sikeresség esetén a kapott üzenetet feldolgozza. A szerver kezeli a MongoDatabase projektbeli DatabaseManager osztályt. Ez felel az adatbáziskapcsolatért és a műveletekért. A program először kapcsolódik az adatbázishoz. Gyűjtemény lekérésekor a program lekéri az adott gyűjteményben levő dokumentumokat, amelyekből megfelelő Layer-eket hoz létre, melyeket egy listában ad vissza. Adott Layer lekérésekor Id alapján keresi meg a megfelelő dokumentumot, amely alapján létrehoz egy új Layer típusú objektumot, majd feltölti a dokumentumban tárolt adatokkal. Mentés esetén először megnézi a program, hogy az adott azonosító konzisztens-e az adatbázisbeli azonosítókkal, azaz vektoros réteg esetén 1.x alakú kell legyen az azonosító, ahol x pozitív természetes szám, raszteres réteg esetén pdig 2.x
27
alakú azonosítókkal dolgozik, ahol x szintén pozitív természetes szám. Ezt követően megkeresi, hogy a megadott Id-vel rendelkezik-e dokumentum a gyűjteményben. Amennyiben szerepel, akkor csak frissíti azt, ellenkező esetben elmenti a megfelelő azonosítóval.
4.4 Az AEGIS.Data Itt vannak megvalósítva az adatbázis-kapcsolatért és műveletekért felelős osztályok. A 20. ábrán látható adatbázis-kezelő rendszer osztálydiagramja.
20. ábra: Az adatbázist kezelő osztály diagramja
Az Exceptions nevű fájlban
kivételek találhatóak, amelyeket a program az
adatbázissal való kommunikáció alkalmával dobhat. Ezek a következőek: − DatabaseAuthenticationException: Jogosultsági hiba okozta kivétel típusa − ItemLoadException: Adatbázisbeli elem betöltésekor adódható kivételek típusa − ItemSaveException: Adatbázisbeli elem mentésekor adódható kívétekej típusa A ServerSettings osztály arra szolgál, hogy a megfelelő konfigurációt beállíthassuk az adatbáziselérés érdekében. Jelenleg kézzel beállítottak ezek az értékek, de természetesen tovább lehet fejleszteni a programot, úgy, hogy ezeket az értékeket egy
28
konfigurációs fájlból olvassuk be, pl egy XML fájlból. Az osztályban öt érték szerepel. Az első érték a MongoServerName, amely a MongoDB szerver neve, ez jelenleg a localhost, mivel a szerver és az adatbázis szerver egy gépen fut, de futtatható a két szerver külön számítógépeken is. A második érték a MongoServerPort, amely megadja azt a portot, amelyen csatlkozik a szerver az adatbázisserverhez. MongoDB esetén ez a port alapértéke 27017. A harmadik érték a SystemDatabaseName, amely annak az adatbázisnak a neve, amelyben tároljuk a térképeket. Az adatbázisnak két gyűjteménye van, a RasterLayer és a VectorLayer nevű gyűjtemények. Az előbbiben a raszteres képeket tároljuk, míg az utóbbiban a vektoros rétegeket. A negyedik érték a UserDatabaseName. Ebben az adatbázisban tároljuk a felhasználónév és jelszó párokat, amelyeket bejelentkezéskor kérünk le. Az adatbázis dokumentumainak két értéke van, az egyik a felhasználónév, a másik a jelszó. Az ötödik érték a SystemInfoDatabaseName, amelyben tároljuk a legutolsó vektoros réteg és a legutolsó raszteres réteg azonosítóját, így az adatbázisba való új réteg mentésekor a megfelelő értéket kiolvassuk, a második részét megnöveljük eggyel, ez az érték lesz az új réteg azonosítója, s a régi értéket pedig erre az újra módosítjuk, mivel ez a legutolsó azonosító, amivel rendelkezik réteg. Mind a szerver, mind a kliens használja az AEGIS.Core projektben levő osztályokban levő XML szérializációt, mivel a hálózaton a rétegeket XML formátumban küldjük át mindkét fél részéről. Az XML szérializációhoz szükséges az, hogy minden egyes Layer illetve Feature osztálybeli elemeket XmlNode-dá alakítsuk. Minden osztályban szerepel a megvalósítása egy toXmlDocument nevű függvénynek, egy fromXmlDocument nevű eljárásnak. Ezek az adott réteget XmlNode-dá szérializálják. Az XmlNode-ban az osztály minden attribútuma XmlAttribute-ként szerepel, az osztályban szereplő más osztálybeli elemek pedig gyerekként szerepelnek. Abban az esetben, amikor a teljes réteget küldjük át a kliensnek fontos, hogy megkapjuk a teljes réteget, viszont gyűjteménybeli elemek lekérdezésekor csupán a rétegek alapinformációi érdekesek számunkra, ennek érdekében használjuk a toXml nevű függvényt és a fromXml nevű eljárást. A fentebb említett XML szérializálástól abban tér el ezeknek a működése, hogy itt nem foglalkozunk az XmlNode gyerekeivel, csupán az attribútumaival. Az osztályban található még két metódus: a LoadXml és a LoadXmlDocument nevű eljárások. Amikor a programban nem tudjuk előre eldönteni, hogy VectorLayer vagy RasterLayer típusú elemmel fogunk foglalkozni, meghívjuk valamelyik eljárást, amelynek szerepe, hogy eldöntse a paraméterként kapott Layer
29
típusú elem típusát, majd meghívja rá a fromXml vagy fromXmlDocument eljárások közül a megfelelőt. A LoadXml és LoadXmlDocument közti különbség ugyanaz, mint a fentebb említett metódusok közötti különbség: másképp kell kezeljük a teljes rétegleírásokat és a részlegeseket. Az adatbázisba mentéskor is szükségünk van szérializációra, mivel csak dokumentumokat tudunk elmenteni. Erre a szérializációra csak a szerver oldalon van szüksége, mivel a kliens közvetlenül nem kommunikál az adatbázissal. Ennek érdekében kiegészítő metódusokként szerepelnek a LayerExtensions osztályban. Itt megtalálható minden
AEGIS.Core
projektben
szereplő
osztályok
szérializálása
MongoDB
dokumentummá. Minden osztályhoz tartozik egy toMongoDocument nevű függvény, amelynek
MongoDB
típusú
dokumentum
a
visszatérési
értéke
és
egy
fromMongoDocument nevű eljárás. A toMongoDocument minden egyes objektumot dokumentummá alakít és ezeket elhelyezi a réteg dokumentumában a megfelelő helyre. A fromMongoDocument kiolvassa a paraméterként megadott dokumentumból az objektum attribútumait. Az adatbázis-kapcsolatért és a műveletekért a DatabaseManager osztály felel. Itt jön létre az adatbázis-kapcsolat és itt vannak implementálva az adatbázisba mentés és adatbázisból olvasás műveletek. Itt ellenőrizzük le a felhasználó azonosítóját és jelszavát, amivel be próbál lépni a kliens felületen keresztül. Az adatbázisműveletek csak sikeres bejelentkezés után hajthatóak végre.
4.5 Az AEGIS.DesktopClient A kliens a WpfClient projektben van megvalósítva. Használja az AEGIS.Core csomagban levő osztályokban szereplő XML szérializációt a rétegek küldéséhez a hálózaton keresztül. A MainWindow osztály valósítja meg a kliens kezdőablakát. Itt kezelhetjük a rétegeket és ezen keresztül kommunikál a kliens a szerverrel. A ConnectWindow ablakban adhatjuk meg a szerverhez való kapcsolódáshoz szükséges IP címet. A TextBoxba beírt szöveget először megpróbáljuk átalakítani valós IP címmé. Ha OK gombra kattintunk, akkor kilépünk az ablakból és kiolvassuk az
30
adatokat. Ha ez az érték tényleg IP cím, akkor történhet kapcsolódás. Ha a Cancel gombra kattintunk, akkor bezárjuk az ablakot. A LoginWindow olyan ablak, amely az adatbáziskapcsolat létrehozásához szükséges. Ebben meg kell adnunk a felhasználónevet és a jelszót. OK gomb lenyomására történik meg az adatok kiolvasása és az ablakból való kilépés. Ha Cancel gombra kattintunk, akkor kilépünk az ablakból, s az adatokkal nem foglalkozunk. A LayerWindow ablakban kiválaszthatjuk a legördülő menüből, hogy az adatbázisból a vektoros rétegeket vagy a raszteres rétegeket akarjuk lekérni. A legördülő menüben csak az említett két típus szerepel, elkerülve a felhasználói hibákat. Ha az OK gombra kattintunk, akkor bezárjuk az ablakot, majd lekérjük a szervertől a kiválasztott típusú réteget. A Cancel gombra kattintva kilépünk az ablakból. A CollectionWindow szolgál arra, hogy egy listában megjelenítsük a szervertől lekért, adott gyűjteménybeli rétegek információit. A osztályban egy listában tároljuk a rétegek információit illetve az azonosítóikat. Az OK gombra kattintás után a program lekérdezi a kijelölt elemet, amely alapján meghatározza az azonosítóját, hogy a kijelölt elemet lekérhessük a szervertől. Ha kijelölés nélkül kattintunk az OK gombra, akkor csak bezájuk az ablakot. A Cancel gombra kattintva bezárodik az ablak. A LayerDrawer osztály szolgál arra, hogy a felhasználó számára megjelenítse a különböző rétegeket. Ezt kirajzolásssal oldja meg. Az 21. ábrán látható a kliens osztálydiagramja.
31
21. ábra: A kliens osztálydiagramja
A kliens szemszögéből az alábbi felhasználói esetek állhatnak fent: − File menü kiválasztása − új fájl betöltése, − betöltött fájl adatainak módosítása. − Server menü kiválasztása:
32
− csatlakozás a szerverhez, − csatlakozás az adatbázishoz, − fájl mentése adatbázisba, − gyűjtemény lekérése. A 22. ábrán látható a kliens felhasználói eseteinek a diagramja.
22. ábra: A kliens felhasználói eseteinek diagramja
4.6 Az AEGIS.Core Ebben a projektben találhatóak a megjelenítéshez szükséges Layer
és Feature
osztályokból leszármazott osztályok. Ennek a komponensnek szerepe van a kliens és a szerver közti kommunikációban, ugyanis itt került megvalósításra a rétegek XML dokumentummá való szérializálása, amelyet használ mind a kliens mind a szerver. A szérializálás bővebben leírása a szerver leírásánál szerepel. Szerepel az XmlDeserializationException osztály a komponensben, amely XML-ből történő visszalakaítás során keletkezett kivétel típusa. 33
A 23. ábrán látható a komponens osztálydiagramja.
23. ábra: Az AEGIS.Core osztálydiagramja
A Layer osztály az ősosztálya a VectorLayer és RasterLayer osztályoknak, amelyek valósítják meg a programban használt vektoros, illetve raszteres rétegeket. A vektoros 34
rétegek Feature típusú objektumokat tartalmaznak, amelyek lehetnek pont vonal vagy sokszög típusúak. Ezeket valósítja meg az absztrakt Feature ősosztályból leszármazó PointFeature, MultiPointFeature, LineFeature, MultiLineFeature és PolygonFeature osztályok. Ebben a komponensben szerepelnek a LayerMetadata és LayerGeodata osztályok, amelyek a rétegekről tárolnak különböző információkat.
4.7 Az AEGIS.IO Ez a komponens felelős a különböző fájlok (ShapeFile, illetve GeoTIFF) megjelenítéséért. A TaggedImageReader osztály olvassa be a TIFF formátumú fájlokat. A beolvasott fájlt a TaggedImageData osztály kezeli. Képes TIFF és GeoTIFF típusú fájlokat létrehozni fájlból olvasás segítségével. Az osztály feltölti az adott réteget a beolvasott értékekkel. A ShapeFileReader osztály ShapeFile-okat képes beolvasni, majd a beolvasott értékeket a ShapeFileData osztály kezeli. Az osztály feltölti az adott réteget a beolvasott értékekkel. A GeoTaggedImageData osztály a GeoTIFF fájlokat kezeli, ezeknek az értékeit tudja lekérdezni. A 24. ábrán látható az osztálydiagram.
35
24. ábra: Az AEGIS.IO osztálydiagramja
36
4.8 Implementációs megoldások A rendszer egy Visual Studio projektcsoportból áll, amely az alábbi projektekből épül fel: − AEGIS: a rétegekhez használt osztályokat tartalmazó projekt − MongDatabase: az adatbáziskezelő osztályt tartalmazó projekt − Server: a Windows szolgáltatás projekt − WpfClient: WPF alkalmazás − AEGISSetup: a telepítő előállító projekt
4.9 Tesztelés A rendszer tesztelése a szokásos fázisokon ment keresztül, leginkább fehérdoboz módszerű teszteléssel. Teszteléskor a klienst és a szolgáltatást is kellett tesztelni. A kliens és a szerver közti kommunikáció sikeresnek bizonyult. A tesztelés folyamatát nehezítette, hogy a Windows szolgáltatásokat nem lehet nyomkövetni Visual Studioban, így erre a megoldás a naplózás nyomkövetése volt. A szolgáltatások nagy hátránya, hogy minden egyes módosítás után újra kell őket telepíteni, hogy a mósosított változatot használhassuk. Az adatbázis tesztelésének egy részét egy konzolos TestDatabase nevű projekttel végeztem. A teszt során layereket próbáltam mentettem az adatbázisba. A mentés üres adatbázisba is működik, ekkor is csak az adatbázisban szereplő következő azonosítót kell megkeressük. Nem megfelelő formátumú fájl mentési kísérlete esetén az adatbázisba, a program kivételt dob, s így figyelmezteti a felhasznlálót a hibára. A szerver tesztelése főleg naplózással történt, naplózva a kapott és a küldött üzeneteket. A kliens felület tesztelésekor a menüpontok működését teszteltem. Fontos, hogy a megfelelő menüpontra kattintáskor a várt esemény következzen be. A felhasználó a 37
menüpontokat csak bizonyos sorrendben használhatja, ezeket is figyelni kellett. A felhasználót tájkékoztatni kell az esetleges sikertelenségről, ezért, ha a kívánt műveletet nem sikerült elvégezni, hibaüzenetet küldök. A megfelelő ablakok (szerverhez kapcsolódás, adatbázishoz kapcsolódás, mentés, lekérés) során ha Cancel gombra kattintunk, akkor újra legyen lehetőségünk használni az adott menüpontot. Fontos szerepe van az adatok elleőrzésének, nem fogadok el nem megfelelő értéket. Ekkor nem történik a programban semmi, még akkor sem, ha OK gombra kattintott a felhasználó. Figyelnünk kell a kliens kapcsolatát a szerverrel. Ha a szerver leáll, a kliens nem érzékeli rögtön, csak akkor, amikor szeretné használni a hálózatot. Ekkor hibaüzenetet kap a kliens és visszaállítom a szerver kapcsolat nélkül nem elérhető menüpontokat elérhetetlenné. A kliensből is tesztelhetjük az adatbázist. Új rétegek betöltését követően mentjük az adatbázisba, majd lekérjük a gyűjteményeket, hogy lássuk, hogy megjelenik-e. Egy adatbáziból lekért réteget módosíthatunk, majd visszamentés után ismét a gyűjtemény lekérésével ellenőrizhetjük, hogy megjelent-e a megfelelő változtatás. Teszteljük a belépést is. Adatbázisban nem létező felhasználónév és jelszó párosra hibaüzenetet kap a felhasználó a kliens felülettől. A felhasználónév és a jelszó tetszőleges szöveg lehet, nincs megszorítás, így a program minden szöveget elfogad.
38
5. Összegzés A szakdolgozat célja egy olyan program megírása volt, amely képes különböző formátumú térképeket kezelni, ezeket hálózaton küldeni és hatékonyan kezelni adatbázisban. Véleményem szerint a program megfelel ezeknek a követelményeknek. A program írása közben nem csak az eddig tanult ismereteimet használtam fel, hanem új ismereteket is. Ennek köszönhetően ismertem meg a MongoDB előnyeit és hátrányait. A
felhasználó
igény
szerint
használhatja
a
térképeket,
módosítás
után
visszamentheti, így hatékonyan naprakészek lehetnek az adatbázisban tárolt térképek. A programnak komoly továbbfejlesztési terve vannak. Cél egy működő és széleskörű funkcionalitású terinformatikai szoftvert megalkotni. A rétegekkel végzett műveleteket kiterjeszteni. A nehézségek ellenére úgy gondolom, a fejlesztőeszközök megfelelőek a program számára. A felhasználási lehetőségek széleskörűek. Úgy gondolom, hogy ilyen jellegű szoftverre szükség lesz a piacon is, így érdemes még tovább fejleszteni.
39
Irodalomjegyzék [1]
Forrás: http://hu.wikipedia.org/wiki/Térképészet, 2011
[2]
Az MSDN Library hivatalos weboldala http://msdn.microsoft.com/en-us/library
[3]
Az MSDN Library hivatalos weboldala http://msdn.microsoft.com/en-us/library, 2011
[4]
MongoDB C# API hivatalos weboldala http://api.mongodb.org/csharp/1.0/, 2011
[5]
ShapeFile technikai dokumentációja http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf, 2011
[6]
GeoTIFF specifikáció http://landsathandbook.gsfc.nasa.gov/pdfs/geotiff_spec.pdf, 2011
[7]
A MongoDB hivatalos weboldala http://www.mongodb.org/, 2011
[8]
.NET keretrendszer telepítője http://www.microsoft.com/net/download.aspx, 2011
[9]
.NET keretrendszer dokumentációja http://msdn.microsoft.com/en-us/netframework/aa663309
40
