GIS alkalmazások I ⁽¹⁾

Az alkalmazások közül először a Térbeli Döntéstámogató Rendszereket - TDR (angol betűszóval SDSS) mutatjuk be, melyek lényegében lefedik mindazon GIS alkalmazásokat, melyek összetett térbeli, időbeli hatások feldolgozása és szimulálása eredményeképpen objektív módon támogatják a legkülönbözőbb területeket érintő tervezési és működtetési feladatokat. Mielőtt a részletes tárgyalásra rátérnénk felhívjuk az angolul értő olvasók figyelmét a téma arra a három évvel ezelőtt készült kiváló összefoglalására [1], mely az NCGIA Core Curriculum in GIScience 127. fejezeteként a WEB-en olvasható, illetve onnan letölthető. Különösen a hivatkozások lehetnek érdekesek, melyek közül sajnos néhány már elavult, de például a DSS Resources szinte korlátlan friss információt nyújt a témában.

A fentiek értelmében amikor GIS alkalmazásokról van szó, akkor vagy térképezési, szemléltetési, tájékoztatási azaz 'egyszerűbb' feladatokról beszélünk, melyek gyakran az általános vállalati információs rendszerbe beépülten jelentkeznek, vagy összetett sok tényezős, sok lehetséges megoldással rendelkező térbeli-időbeli rendszerekről, melyek valamilyen mértékben TDR-nek tekinthetők.

Mivel az egyszerűbb alkalmazások levezethetők az összetettekből, arról nem is beszélve, hogy a korábban megismert GIS függvények segítségével viszonylag egyszerűen kidolgozhatóak ezért először a Térbeli Döntéstámogató Rendszereket fogjuk viszonylag részletesen megvizsgálni. Az egyszerűbb alkalmazásokat rövidebben fogjuk tárgyalni már csak azért is, mivel az új GIS rendszerek létrehozására (implementálására) vonatkozó következő részben részletesen megvizsgáljuk azokat a feladatokat, melyek minden térinformatikai rendszer esetében, igy az egyszerű rendszerek esetében is, komoly munkát jelentenek a projekt szereplőinek.

Térbeli Döntéstámogató Rendszerek - TDR

Ebben a részben megismerkedünk:

• a döntések általános problematikájával és a GIS lehetőségeivel e problémák megoldására, röviden felvázoljuk a
• környezeti és társadalmi folyamatok modellezésének fogalmát és eszközrendszerét, megfogalmazzuk
• a Térbeli Döntéstámogató Rendszerek meghatározását, bemutatjuk a
• a TDR elemeit, azok funkcióit és
• az elemek összekapcsolását biztosító architektúrákat, ehhez kapcsolódóan megismertetjük a DIAS keret szoftver rendszert, végül példákat mutatunk be
• GIS szoftverben (IDRISI) realizált döntéstámogatási lehetőségekre,
• a GIS szoftverbe ágyazott külön programmal megvalósított döntés támogatásra és fordítottjára, ezek között
• a városi közlekedési hálózat torlódásait modellező rendszerre illetve
• az összetett rendszerekkel realizált megoldásokra, köztük egy olyanra,
  • az IDLAMS-ra, illetve az OO-IDLAMS-ra, mely a DIAS rendszert használja;
  • az egyik első tipikus architektúrájú SDSS-re az IPDS-re, bemutatjuk a
  • legújabb skót objektum orientált föld hozzárendelő és döntés támogató rendszert a LADSS-t ,
  végül
• rendszerezett összefoglalást adunk az SDSS keretrendszerek lehetőségeiről.

A döntések általános problematikája, a GIS szerepe a problémák megoldásában

A térbeli döntési problémákban rendszerint nagyszámú döntési alternatívából kell választanunk, melyek térbelileg változók. Az alternatívákat többszörös kritériumok alapján értékelik ki, néhány kritérium mennyiségi, mások minőségiek.

A munkát tipikusan több döntéshozó vagy csoport végzi és a döntéshozóknak különböző a preferenciájuk a kritériumok relatív fontosságára és a döntés következményeire vonatkozólag.

A döntéseket gyakran övezi bizonytalanság.

A fenti általános megállapítások talán világosabbá válnak, ha például arra gondolunk hogy a támogatandó tervezési feladat valamely község területének tagosítása és az optimális földhasználat megtervezése.

Mindenki számára világos, hogy több lehetséges megoldás van, ezek a területeket másként rendezik, a számtalan kritérium közül megemlíthetünk objektívokat, mint az optimális táblaméret, a tulajdonos házától (telephelyétől) mért távolság, de szubjektívokat is mint pld. kötődés egy bizonyos dűlőhöz vagy szomszédhoz, nem szubjektív de szintén minőségi kritérium a talaj típusa, stb.

A mezőgazdasági szakemberek valószínűleg másként súlyozzák a kritériumokat mint a helyi közigazgatási szakemberek. Az is valószínűsíthető, hogy nem áll rendelkezésünkre olyan sűrűn mintavételezett talaj mínőségi fedvény és belvíz veszélyt ábrázoló fedvény, mely az eredményt illetően teljes bizonyosságot garantál.

A döntési folyamat három részre bontható:

• az első lépésben azt kell felderíteni, hogy mit kell illetve mit lehet módosítani a döntési folyamatban;
• a második lépés - a tervezés alternatívákat dolgoz ki a megváltoztatandó dolgokra;
• a harmadik lépés - a választás során kell megalapozni azt, hogy melyik variánst javasoljuk a döntéshozónak.

6.1 ábra - a döntési folyamat logikai vázlata

Amint a 6.1 ábrából kitünik a döntési folyamat iterációkon keresztül jut el a végleges megoldáshoz. a felderítés keretében végrehajtandó feladatok: a környezet átvizsgálása döntést igénylő problémákra; a döntési helyzet feltárása; döntési helyzet információ elemzése különböző forrásokból; komplex információ megjelenítés. a tervezés során sor kerül: a variánsok kitalálására, kifejlesztésére, elemzésére; a formális modell variánsok létrehozására. a választás során: előre definiált döntési szabály alapján minden alternatívát kiértékelnek; a döntéshozók a saját preferenciájuk alapján döntenek.

Már eddigi ismereteink alapján is világos, hogy a GIS szoftverek önmagukban az esetek többségében nem alkalmasak valamennyi vázolt feladat megoldására.

Talán az első feladat - a felderítés az amely a GIS szoftverekkel többé kevésbé önállóan is végrehajtható. Persze ahhoz hogy ehhez a feladathoz hozzá tudjunk fogni meg kell adni azt a vizsgálandó tematikát, mely jelenlegi helyzete esetleg változtatást igényel. Ezután össze kell gyűjtenünk a szükséges térbeli és leíró adatokat és hozzákezdhetünk a GIS-szel a felderítés végrehajtásához.

Ha a bevezetőben már hívatkozott tagosítási példánál maradunk megvizsgáljuk, hogy hogyan viszonyul a jelenlegi táblanagyság az optimálishoz, megvizsgáljuk az egy tulajdonoshoz (bérlőhöz) tartozó mezőgazdasági ingatlanok szórását, a talajtípusok és a termesztett kultúrák összhangját, stb. A vizsgálatok során a tényleges helyzetet különböző források ütköztetésével igyekszünk feltárni, elsősorban friss távérzékelt képek bevonása segítheti a felderítést. A kapott eredményeket a GIS grafikus eszközeivel szemléletesen megjelenítjük.

Ha azonban a feladat az erózió elleni védelem szempontjából az erózió veszélyes helyek feltárása, úgy a GIS önmagában csak akkor alkalmas a feladatra, ha rendelkezünk a területről több időpontban készített nagypontosságú magassági felméréssel, melyek egybevetésével meg tudjuk határozni azokat a helyeket ahonnan a földet a víz elhordta. Ha azonban nincs multitemporális adatsorunk, úgy a veszélyes helyeket csak valamilyen eróziós modell segítségével határozhatjuk meg.

A tervezési és kiválasztási feladat még kevésbé oldható meg a GIS standard eszközeivel. Igaz, hogy egyes GIS szoftverek rendelkeznek bizonyos tervezési, kiválasztási funkciókkal (pld. a legrövidebb út keresés az IDRISI-ben vagy az ArcView Network Analyst-ban, ez utóbbi tulajdonképpen nem is az eredeti GIS szoftver, hanem annak kereskedelmi (nem ingyenes) kiterjesztése - pótfüggvény könyvtára), ezek azonban egyediek és a komplex alkalmazásokhoz nehezen alakíthatók.

A modellezés determinisztikus, empirikus vagy statisztikai számítási módszerek felhasználásával becsüli valamely keresett jelenség értékét adott bemenő adatok esetén. A figyelmes olvasó előtt már nem lehet új ez a fogalom, hisz a GIS műveletek kapcsán már bemutattuk, hogy miként lehet az overlay operáció segítségével egyszerű földrajzi modelleket realizálni a GIS-ben. Más egyszerű modellek is megvalósíthatók magában a GIS-ben, ha tartalmazási, összekötési, szomszédsági viszonyok feltárásán alapulnak, vagy egyszerű aritmetikai képletekkel leírhatók. Sok modell azonban olyan bonyolult számítási eljárást igényel, melyek a GIS eszközeivel nem oldhatók meg. Ilyenkor tulajdonképpen három megoldás lehetséges:

• a GIS fejlesztő nyelvével elkészítjük a modell programját, mely így tulajdonképpen a kérdéses GIS szoftver új függvényévé válik, melyet ugyanúgy használhatunk, mint az eredetileg beépített függvényeket;
• úgy készítjük el a modellt leíró algoritmus programját, hogy rendelkezzen grafikus megjelenítési képességgel;
• az adatokon keresztül kapcsoljuk össze a GIS-t és a modellező programot, azaz gondoskodunk arról, hogy a modellező program a bemenő adatokat a GIS adatbázisból vegye, a GIS pedig bemenő adatként kezelje a modellező program outputját.

A fenti általános alapelveket néhány gyakorlati kérdés erősen befolyásolja. Talán a legfőbb befolyásoló tényező az hogy az utóbbi két évtizedben számos szakterületen félig vagy teljesen szabványos tervező-modellező programok jöttek létre, melyek a GIS-től függetlenül keletkeztek, de a kérdéses szakterületek ragaszkodnak hozzájuk. A ragaszkodás a kipróbált szoftverekhez nem tekinthető indokolatlannak, hisz az újra programozás óhatatlanul hibákkal terhelné a modelleket. A kipróbált programok felhasználása az I/O modulok megváltoztatása után a harmadik megoldással képzelhető el legegyszerűbben.

Ennek az elvnek egy korszerű objektum orientált megvalósítására dolgozták ki a WISE architektúrát. A rendszer különböző szakterületek klasszikus FORTRAN-ban programozott modelljeit foglalja be az ezeknek megfelelően definiált bázis objektumba (az hogy milyen modellről van szó a kérdéses bázisobjektum tulajdonságaiban jelenik meg). Az órával szinkronizált rendszer az ökoszisztéma szimulálását hajtja végre kliens-szerver formában.

A GIS szoftverek fejlesztési irányai az első megoldás irányába mutatnak. Az idén - 2000-ben kibocsájtott ArcView Spatial Analyst ModelBuilder nevű modulja olyan grafikus folyamattervezővel rendelkezik, mely segítségével a szoftver saját függvényeiből grafikusan programot hozhatunk létre (6.2 ábra). Az ArcInfo és az ArcView jövő évi (2001) verziói pedig már azt is lehetővé fogják tenni, hogy a folyamatábrába a felhasználó által gyártott függvények is bekapcsolhatók legyenek. Feltehetőleg ezt az utat fogják választani azok a kutatók, akik új modellek segítségével specifikus rendszereket kívánnak kialakítani. Maguk az új modell programok is egyre gyakrabban készülnek grafikus (vagy vizuális) programozással. A Khoros programrendszerben működő cantata nyelv például az ikonokkal reprezentált saját és integrált külső programok összeköttetésével készíti el a programot, mely mind önállóan, mind a Khoros rendszerben futtatható.

6.2 ábra - ModelBuilder program az ArcView Spatial Analystban

6.3 ábra - cantata program a Khoros szoftver csomagban

A második megoldást tartjuk a legkevésbé előnyösnek, mivel az egyedi grafikai modul általában nem éri el a GIS szoftverek grafikai képességeit.

Mivel azonban minden osztályozás leegyszerűsíti a valóságot a második megoldás is jó eredményekre vezethet, ha a modellezést olyan szoftverrel végezzük mint a PCRaster, mely egy raszteres GIS és környezeti modellező szoftver kombinációja, s így természetesen a térbeli adatbevitel és megjelenítés is szerves alkotó elemét képezi. A szoftver modellező és GIS operátorait szkript jellegű környezeti modellező nyelve segítségével foglalhatjuk össze programokká. Ez megoldás azonban elsősorban feladatspecifikus rendszerek kialakítására alkalmas az operátorok által behatárolt szűkebb területen. A PCRaster korlátozott képességű DOS-os verziója a hivatkozott URL-ről ingyen letölthető.

Konklúzióként megállapíthatjuk, hogy

• a GIS korlátozott képességekkel rendelkezik különösen a tervezési és választási fázisban;
• nagyon statikus modellező környezetet biztosít s ezzel redukálja döntés támogató eszköz szerepét különösen a kollektív döntéshozatali folyamatban.

A Térbeli Döntéstámogató Rendszerek (TDR) definíciója

Az TDR interaktív, kompjúter-alapú rendszer, mely támogatja a felhasználókat vagy csoportjaikat a hatékonyabb döntéshozatalban a félig struktúrált térbeli döntési problémákban;

Az idézett három fogalom (félig struktúrált térbeli problémák, hatékonyság, és döntés támogatás) foglalják össze az TDR koncepció lényegét.

A 6.4 ábra segítségével szeretnénk megvilágítani ezt az első látásra talán nem túl világos kifejezést, hogy "félig struktúrált térbeli problémák". Amint az ábrából látható a struktúráltság a struktúrálatlanságtól a teljes struktúráltságig terjed. Egyszerűbben arról van szó, hogy lehet-e a kérdéses problémát matematikailag megfogalmazni. A matematikai problémák nem csak abból eredhetnek, hogy nem ismerjük a jelenségeiket és kölcsönhatásaikat, de abból is hogy megengedi-e a kérdéses közeg (társadalom, állam, stb.) morális felfogása a feladatok struktúrálását. Minden döntéstámogatás első tudománya az operáció kutatás ugyanis általában minden feladatot valamely pénzben kifejezett érték minimalizálására (költségek) vagy maximalizálására (nyereség) vezetett vissza. A struktúrálatlanságot gyakran az idézi elő, hogy nem minden történést lehet pénzben kifejezni (emberi élet, az élet minősége, ritka állat vagy növény fajok pusztulása, stb.).

6.4 ábra - a feladat-struktúráltság fokai

A struktúrát vagy a döntéshozó (politikus) vagy a természet-, vagy társadalom tudományok eredményein nyugvó elmélet biztosítja. A struktúrált feladat, mivel matematikai formában megfogalmazható programozható is. Bizonyos feladatokat sem a döntéshozó, sem az elmélet sem tud struktúrálni. Ekkor a döntéshozónak számítógép segítsége nélkül kell meghoznia a döntést. A TDR feladata a félig struktúrált feladatok megoldásának támogatása, a számítógép megoldja a feladat struktúrált részét, míg a döntéshozó az interaktív eszközök felhasználásával dönt a struktúrálatlan részben.

A döntéshozás hatékonysága egyrészt azt jelenti, hogy a rendszer a hagyományos módszerekhez képest jelentősen meggyorsíthatja a döntéshozást, ennek különösen a katasztrófa elhárításban van nagy szerepe. Mégis azt kell mondanunk, hogy a számítógép és emberi ítélőképesség kombinálásával inkább a hatásos döntés mint a hatékony döntéshozás a fontos, hiszen rossz, megalapozatlan döntéseket minden segítség nélkül is lehet nagyon gyorsan hozni. A hatékonyságot a rendszer könnyű kezelése segíti.

A döntés támogatás az ember és a rendszer rekurzív folyamatban végbemenő interaktív kapcsolatában fejeződik ki.

A TDR főbb részei - a TDR paradigma

6.5 ábra - a TDR elemei

A TDR főbb funkciói a dialógus szervezés, az adatkezelés, és a modellezés. A jó TDR kiegyensúlyozattan rendelkezik e képességekkel. Ezekre a funkciókra a TDR összetevői szolgálnak, melyek a következők (a rövidítéseket angol eredetijükben adjuk meg): Adatbázis Kezelő Rendszer (DBMS); Modellbázis Kezelő rendszer (MBMS); Párbeszéd Generáló és Kezelő rendszer (DGMS).

A következő táblázatban megadjuk az összetevők legfontosabb funkcióit.

Az adat-, és adatbázis kezelés funkciói	A modellbázis kezelés funkciói	A dialógus kezelés funkciói
adattipusok; helyzeti; topológiai ; attribútum; logikai adatszerkezet; relációs DBMS; hierarchikus DBMS; hálózat DBMS; objektum orientált DBMS; belső és külső adatbázis kezelés; adatelérés; tárolás; visszanyerés; manipuláció; címjegyzék; lekérdezések; integráció;	analízis; cél keresés; optimalizálás; szimuláció; mi lesz ha; statisztika és prognózis; feltáró térbeli adatelemzés; igazoló térbeli adatelemzés; idősorok; geostatisztika; döntéshozói preferencia model; érték struktúra; célok, kritériumok, attribútumok hierarchiája; páronkénti összehasonlítás; koncenzus modellezés; bizonytalanság modellezés; adatbizonytalanság; döntési szabály bizonytalanság; érzékenység elemzés; hibaterjedés elemzés.	felhasználó barát(i)ság; konzisztens természetes nyelvi magyarázatok; help és hibaüzenetek; kezdő és haladó mód; dialógus stílus változatok; parancs sorok; lehúzható menük; párbeszéd ablakok; grafikus felhasználói felület; grafikus és táblázatos megjelenítés; térképi (döntési tér); rajzok, diagrammok, táblázatok (eredmény tér).

TDR fejlesztési technológiák

A DSS (DSS =Decision Support System = Döntéstámogató Rendszer) technológia 3 színtje a következő: DSS eszközök, vagy a DSS generátort vagy a specifikus DSS-t támogatják: makro program nyelvek és könyvtárak a GIS szoftverek kibővítésére (AML makro nyelv az Arc/Info GIS szoftverhez, Avenue makro nyelv az ArcView GIS szoftverhez, GISDKTM fejlesztő eszköztár, mely értelmezi a caliper makro nyelvet - a TransCAD közlekedési GIS szoftverhez, MapBasic nyelv a Mapinfo GIS szoftverhez, stb.); vizuális program nyelvek (ModelBuilder az ArcView Spatial Analyst-ban, STELLA 6, cantata a Khorosban); alkalmazások közti kommunikációs szoftver, ezekkel már ha csak érintőlegesen is de foglalkoztunk a WEB GIS fejezetben (Dynamic Data Exchange = DDE, Object Linking and Embedding = OLE, Open DataBase Connectivity = ODBC, stb.); szimulációs, modellező nyelvek és szoftverek (FACET, PCRaster, SIMULINK, SIMULA, Swarm); Alkalmazói Program Interfészek (Application Programing Interface =API) (IBM geoManager API, Java Advanced Imaging API); applet-ek (GISApplet); grafikus interfészek (GUI).

6.6 ábra - a TDR technológia 3 színtje

• DSS generátor - hardver és szoftver csomag, mely egy sor képességgel segíti specifikus TDR könnyű és gyors felépítését. A felsorolásban szereplő szoftvereket kétszeresen is alternatívokként kell értelmezni: nem minden típusra van szükség a DSS generátorban, illetve gyakran a DSS generátor csak egy típuson alapul, egy típusból pedig általában elég egy csomag is;
  • Objektum orientált keret szoftverek (WISE, DIAS);
  • GIS rendszerek (ARC/INFO, ArcView, Spatial Analyst, ARCNetwork, MapObjects LT, GRASS, IDRISI, MapInfo,TransCAD);
  • adatbázis csomagok (dBase, FoxPro, Access, Paradox);
  • döntés elemző és optimalizáló szoftver (pld. Facet Decision Systems, LINDO, LINGO, EXPERT CHOICE, LOGICAL DECISION);
  • statisztikai, geostatisztikai szoftver (S-PLUS, SPSS, SAS);
  • szimuláció (Spatial Modelling Environment);
• Specifikus DR bizonyos döntési feladatcsoportot támogat a félig struktúrált feladatok csoportjából;
  • IDRISI Döntés Támogatás;
  • GeoMed;
  • Spatial Group Choice;
  • Active Response Geographic Information System;
  • winR+GIS Spatial Decision Support.

A megvalósult TDR-ek architektúrája lényegében három tényező kölcsönhatásának eredménye. A legfontosabb ezek közül a dátum, azaz, hogy mikor készült a rendszer. A második tényező a modellezett rendszer összetettsége és dinamizmusa. Harmadik tényezőként a kérdéses szakterületre vonatkozó, már programozott úgy nevezett "örökölt" modellek (lsd. az angol "legacy" model-t) megléte vagy hiánya említhető.

A korai rendszerekben (a korai ebben az összefüggésben 1997-98 előttit jelent), ha eltekintünk az egyedüli GIS szoftvertől az IDRISI-től, mely integrált (igaz sajátos) döntéstámogató modullal rendelkezik, két fő irányzatot figyelhetünk meg a TDR létrehozására.

Az elemek laza integrálása esetén a rendszer komponensek az adatok segítségével kommunikálnak. Ebben az esetben, ahogyan a fejezet bevezetésekor már utaltunk rá, a modellező, optimalizáló rutinok önállóan futnak a háttérben és a kezelő szoftvernek lényegében arról kell csak gondoskodnia, hogy a térbeli és nem térbeli adatok az adatbázisból kiválogatásra és betöltésre kerüljenek térbeli adatok esetén a GIS felhasználásával, illetve, hogy az előállt adatokat a modellező, optimalizáló rutinok bemenetként elfogadják, majd az eredmények a GIS segítségével megjeleníthetők legyenek. Ez a módszer alapvetően statikus feladatok megoldására alkalmas, nem optimalizálja a szoftver működését és képtelen kezelni az egymásra ható összetett jelenségeket.

A szoros integrálás esetén a modellező, optimalizáló rutinokat az alapul választott DSS generátor saját függvényeiként alakítják ki például a rendszerhez interfészelt dinamikusan kapcsolt könyvtárban (dll-ben). A szoros integrálás a program kezelése és futása szempontjából előnyösebb a laza integrálásnál, mégis a korábbi rendszerekben viszonylag ritka volt, ami több okkal is magyarázható. A legfontosabb ok, hogy csak akkor alkalmazható, ha a generátor (általában GIS) adatmodellje megegyezik a modellező szoftverek adatmodellével, például egy két dimenziós adatmodellű GIS-be nem lehet három vagy négy dimenziós modellező szoftvert beépíteni. A második ok az előre progra mozott "örökölt" modellekhez kapcsolódik, ezek kódját ugyanis nem lehet beépíteni ebbe az architektúrába, végül sok generátor jelölt szoftvernél hiányzott az architektúra létrehozásához szükséges nyitott, dokumentált interfész. A GIS szoftverek bővíthetősége csak az utóbbi években vált általános tendenciává.

A korszerű rendszerek az objektum orientált alapelven nyugvó keret szoftverek segítségével valósítják meg a különböző modellek és alkalmazások integrálását dinamikus módon. A bevezetőben már utaltunk a WISE rendszerre, mely az objektum orientált keretprogram korai realizálásának tekinthető. A továbbiakban röviden összefoglaljuk a DIAS keret szoftvert, majd az alkalmazások kapcsán bemutatjuk, hogy miként alakították át az ökoszisztéma modellező és szimuláló szoftver rendszert az IDLAMS-t a DIAS-ban való működésre.

A DIAS (Dynamic Information Architecture System) objektum orientált keret szoftvert egy amerikai állami kutató intézetben az Argonne National Laboratory-ban dolgozták ki döntően, de nem kizárólag katonai finanszírozással. A katonai feladatok egy része is olyan azonban, mely a polgári életben is használható.

A DIAS rendszer alapelemét az úgy nevezett entitás vagy tartományi objektumok képezik. Ezek az absztrakt objektumok alkalmasak arra, hogy egy tématerület modelljeit kezeljék, de konkrét modellhez csak a regisztrációs folyamatban kapcsolódnak. Azaz a megfelelően kialakított entitás objektumok a terület több féle modelléhez is kapcsolhatók.

A modellező, szimulációs folyamatban a kölcsönhatásban lévő modellek egymáshoz közvetlenül nem kapcsolódnak, az együtt működést a megfelelő entitás objektumok biztosítják. Ez az architektúra jelentősen növeli a rendszer hatékonyságát és megbízhatóságát (6.7 és 6.8 ábra).

6.7 ábra - a modellek együtdolgozása a hagyományos architektúrákban	6.8 ábra - a modellek együttdolgozása a DIAS-ban

A DIAS architektúráját a 6.9 ábrán vázoljuk fel.

6.9 ábra - a DIAS architektúrája

Az alábbiakban röviden bemutatjuk az architektúra főbb elemeit.

• Az analízis keret az az objektum, mely tartalmazza a szimulációban érdeklődésre számot tartó területet, összefogja a résztvevő részeket és megadja a szimuláció célját. Térbelileg explicit szimuláció esetén tartalmazza a terület határait. Mind térbeli, mind pedig nem térbeli szimuláció esetén meghatározza a probléma elvi korlátait.
• Az entitás objektumok olyan valós világbeli komponensek (épületek, személyek, légkör, stb.), melyek egymásra hatnak a szimuláció során. Minden entitás objektumnak van egy sor hozzá kapcsolt paraméter és aspektus objektuma. A paraméter objektumok tartalmazzák az entitás állapot jellemzőit, a az aspektus objektumok pedig leírják az entitás objektum tulajdonságait és azt, hogy miként lép akcióba a többi objektummal. A DIAS felépítésében igen fontos szerepet játszik, hogy magában a DIAS-ban az aspektus objektum absztrakt objektum, mely csak az alkalmazásokban instanciál implementációs részleteket.
• Az objektum könyvtár különböző típusú entitás objektumok állandó gyűjteménye. Ezeket az objektumokat viszi be a rendszer az analízis keretbe a szimulációk során. Új alkalmazás regisztrálása során új entitás objektumok hozzáadására lehet szükség, vagy sor kerülhet a meglévő entitás objektumok módosítására. Ily módon minden egyes alkalmazással bővülnek az újra felhasználható szoftver komponensek.
• Az adat import/export segédprogramok biztosítják a mechanizmust az entitás objektumok állapotváltozóinak feltöltésére. Az implementálás során arra törekedtek, hogy egy sor (elsősorban amerikai katonai) adatformátum (pld. DTED, ITD/PITD, GRIB, azaz katonai digitális magasságmodell, katonai digitális terepi síkrajz illetve nemzetközi meteorológiai adatformátum) fogadására legyenek alkalmasak.
• A modell csomagoló külső modellek és alkalmazások DIAS-hoz kapcsolására szolgál. Két összetevője a modell vezérlő és a modell objektum. A modell objektum egy DIAS objektum, mely referenciával rendelkezik az összes szükséges folyamat objektumhoz. A modell vezérlő explicit kapcsolatot létesít a modell/alkalmazás forrás kódjához, és adatstruktúráihoz, melyek a DIAS keret programon kívüliek. A modell objektum és modell vezérlő közti kommunikációra a CORBA-t használja a rendszer, biztosítva ezzel hogy a DIAS szimuláció az osztott hálózaton fusson.
• A folyamat objektum olyan DIAS objektum, mely lehetővé teszi valamely entitás objektum tulajdonság megcímzését. A folyamat objektum felelős a be-, és kimeneti paraméterekre, metaadatokra (pld. méretarányra), korlátozásokra és folyamat függőségre vonatkozó információkért. A folyamat objektum az egyedüli objektum a DIAS keretben, mely tartalmazza mind az entitás objektumokra vonatkozó információkat, mind a megfelelő modell speciális követelményeit. Felelős e mellett még a két irányban áramló adatok be és kicsomagolásáért, az adatok aggregálásáért és lebontásáért, a különböző koordináta transzformációkért, mértékegység konverziókért.
• A diszkrét esemény szimuláció kezelő az eseményeket időrendi sorrendben dolgozza fel. Az eseményeket elvileg az entitás tulajdonsága és a felhasználó beavatkozása generálja. Az eseményeknek időpont jelzésük van és adatok is kapcsolódhatnak hozzájuk, szelektíven közvetítődnek azokhoz az objektumokhoz, melyek érdeklődése regisztrált a kérdéses esemény típusra vonatkozóan.
• A GeoViewer a DIAS térbeli megjelenítő, adat bevivő és karbantartó valamint lekérdező modulja. Tulajdonképpen egy DIAS-ba integrált korlátozott funkcionalitású GIS.
• A térbeli adat együttes (SDS) 1, 2 és 3 dimenziós esetre tartalmazhat teljes geometriai térleírást. Az SDS nem entitás objektum, hanem az entitás objektum paramétere, mely kiterjeszti az entitás objektum attribútum specifikációit olymódon, hogy képes legyen kezelni a térbeli kapcsolatokat. Az SDS segítségével a fejlesztő könnyen transzformálhatja vagy partícionálhatja az adatokat a különböző modulok igényeinek megfelelően.
• A DIAS modellek vagy alkalmazások létrehozása képezi a keretszoftver célját. A 6.10 ábrán ismét bemutatjuk a 6.9 ábrán már általános esetre felvázolt DIAS architektúrát egy konkrét alkalmazás - A Dinamikus Környezeti Hatások Modellezése esetére. Amint az ábrából látható, itt az entitás objektumoknak, modelleknek, stb. már konkrét nevük van.

  6.10 ábra - Dinamikus Környezeti Hatások Modellezése a DIAS-ban

  
  Amint erről már többször szóltunk a DIAS lehetővé teszi, hogy a szimulációba olyan modelleket is bekapcsoljunk, melyeket korábban valamilyen tetszőleges program nyelven (FORTRAN, C, stb.) programoztak. Még arra is van lehetőség, hogy ezek a modellek a hálózat különböző helyein legyenek tárolva. Ahhoz azonban, hogy a különböző modellek egységes szimulációként a DIAS-ban működjenek végre kell hajtani formális regisztrációjukat. A regisztráció a következő lépésekből áll:

  1. Az alkalmazás formális meghatározása az alábbiakra:
     • az entitás objektumok attribútumai/állapotai;
     • folyamatok, melyek az entitás objektumok tulajdonágaiként jelentkeznek;
     • a folyamatok ki-, és bemenő paraméterei.
  2. Az egyes folyamatok elkülönítés (bejelölése) a forrás kódban.
  3. Becsomagoló program írása a modell számára.
  4. Új entitás objektumok létrehozása vagy a régiek felújítása (átszerkesztése).
  5. A forrás kód minden folyamatához folyamat objektum létrehozása.
  Természetesen magában a DIAS-ban is lehet új modelleket létrehozni. A bonyolult több entitás objektum közötti dinamikus alkalmazások DIAS-on belüli megalkotását segíti a FACET (Framework for Addressing Cooperative Extended Transactions = Kooperatív kiterjedt tranzakciókat megcélzó keretrendszer) nevű fejlsztő környezet.
• Az Intelligens összefüggés vezérelt grafikus felhasználói interfész röptében generálja az adat és paraméter bevitelhez szükséges képeket, és több modell egyidejű futásakor mindig csak azokat jeleníti, melyeket a felhasználó kijelöl.

Az egyszerűbb és gyorsabb betöltés érdekében a témát a következő lapon folytatjuk.

⁽¹⁾ A tanulmány része az OTKA T 031719 témaszámon folyó kutatásnak.

a következő részben folytatjuk a Térbeli Döntéstámogató Rendszerek tárgyalását

esetleg visszatérhet az előző részhez

illetve a tartalomjegyzékhez

Megjegyzéseit E-mail-en várja a szerző: Dr Sárközy Ferenc