Thursday, June 24, 1999

Néhány kvázi szabványos illetve szabványos információtechnológiai eszköz I

Ezen a lapon

• bevezetjük a szükséges kiegészítő ismereteket,
• felvázoljuk az objektum/kapcsolat, röviden ER diagramok lényegét és térbeli kiterjesztésüket,
• bemutatjuk az IDEF1x grafikus relációs adatbázis tervező szabványt,
• megismerkedünk a CORBA hálózati szoftver közvetítő rendszerrel (u.n. midleware-rel),
• végül összefoglaljuk az UML grafikus modellező nyelvet.

Milyen eszközökkel akarunk foglalkozni és miért van rájuk szükségünk?

Ebben a részben néhány adósságunkat törlesztjük, illetve néhány olyan eszközzel ismerkedünk meg, melyekre a következő alpontokban az "Open GIS" koncepció, a magyar térbeli adatátviteli szabvány és a WEB GIS ismertetésekor lesz szükségünk.

Tulajdonképpen azt is írhattuk volna, hogy kibővítjük ismereteinket az 1. fejezetben megismert adatleíró nyelvekről (DDL), ez azonban nem fedi teljesen a fejezet tartalmát. Az egyik adatleíró nyelvvel (EXPRESS) kapcsolatban ugyanis ha csak röviden is, de utalnunk kell a STEP nevű nemzetközi mérnöki termék szabványra, két másik leíró nyelv (UML, IDL) illetve maga az "Open GIS" koncepció igényli, hogy a CORBA rendszer példáján bemutassuk az úgynevezett "midleware" hálózati szoftver rendszerek lényegét.

Előre kell bocsátanunk, hogy ezeket az ambiciózus terveket csak magas fokú generalizálással, azaz csak eléggé felületesen lehet megvalósítani egy alponton belül. Ezért az érdeklődő olvasóknak megadjuk azokat az irodalmi esetleg Internet címeket, ahol a témáknak utána olvashatnak.

Hálózati és relációs adatmodellező módszerek: az Objektum-Kapcsolat (Entity-Relationship), röviden ER diagrammok és az IDEF1x modellező nyelv

Az ER diagrammok

Az ER diagrammok a korszerű adatbázis-kezelő rendszerek kialakulásával, a modellezési igények megjelenésével jöttek létre. Feladatuk az volt, hogy áttekinthető grafikus eszközökkel megkönnyítsék az adatbázisok logikai tervezését. Az eredeti formájában az ER diagramm entitásokat, hozzájuk tartozó attribútumokat és kapcsolatokat tartalmazott abban a formában, ahogyan ezt az 5.35 ábrán látjuk.

A kapcsolat típusok az alábbiak lehetnek:

• tartozik valamihez;
• halmaz és részhalmaz kapcsolatok;
• szülő - gyermek kapcsolat;
• objektum részei.

Eredmény a formálisan specifikált entitások, attribútumaik, kapcsolataik, a kapcsolatok esetében fontos a kapcsolat jellege (1:1, 1:N, N:M), melyet az ábrán a kapcsolatot reprezentáló vonal mellett tüntettünk fel.

A földrajzi adatok esetében a fizikai objektum meghatározásnak (ház) mindég absztrakt térbeli objektum meghatározás (poligon) felel meg.

A térbeli adatok esetére, újabban kiegészítő jelöléseket alkalmaznak az 5.36 ábrán bemutatott módon:

Az új jelölések lehetővé teszik a térbeli objektumok és kapcsolatok ábrázolását. Érdekes megfigyelni az objektumok kiterjesztett formalizmusát (típus, geometriai kód, topológiai kód) illetve a térben vagy időben többszörös objektumok jelölését. A térben többszörös objektum azt jelenti, hogy különböző méretarányban más geometriai objektum is ábrázolhatja ugyanazt a fizikai objektumot, pld. kis méretarányban az utat vonal ábrázolja, míg nagy méretarányban poligon.

A térbeli kitérőnk alkalmazásának illusztrálására nézzünk meg egy részletet egy város térbeli adatbázisának ER diagramjából (5.37 ábra).

Az ER diagramok a hálós adatbázis koncepciónak köszönhették létrejöttüket és az adatbázis létrehozásának vizuális segítésére szolgáltak. A programozó a diagrammok szemlélésével könnyebben tudta a kérdéses adatbázis-kezelő szoftver DDL-jében programozni a gazda és tag rekordokat.

Az idő múlásával azonban a relációs adatbázis kezelők fokozatosan kiszorították a hálózati modellt és az ER diagramokat relációk létrehozására kezdték használni. Ez elvileg lehetséges, hiszen a relációs adatbázis-kezelők kezdetben a programozást megkönnyítő interfészek voltak a hálózati modellű adatbázis-kezelő rendszereken.

Ez a megoldás azonban nem volt tökéletes részben azért, mert az ER nem támogatta közvetlenül a relációs adatmodellt, részben pedig azért mivel a finomabb részletekben (elnevezések, megírási szabályok, részdiagramok összekapcsolása, stb.) számtalan "szokás" alakult ki, mely egyrészt megnehezítette a diagramok portabilitását, másrészt, és ez a fontosabb, megnehezítette az ER módszer alkalmazását a logikai adatbázis séma automatizálásra.

Az IDEF1X szabvány

A korai 80-as években ugyanis megkezdődött a programozás automatizálását támogató programok az úgynevezett CASE (Computer Aided Software and Systems Engineering), azaz magyarul Automatizált Szoftver és Rendszer Készítő eszközök elterjedése, melyek egy csoportja aktívan támogatja az adatbázisok létrehozását diagram rajzolással (koncepcionális tervezés), és a diagramok alapján kódgenerálással (logikai tervezés).

Az automatizálás alatt a relációs adatbázisok esetén tehát azt kell érteni, hogy a diagramot típus elemekből a számítógépen építik fel, kitöltve szabványos formátumú elnevezésekkel az elemek írható részét, majd a kész diagramot a gép automatikusan SQL szkriptre fordítja, mely alkalmazva valamely relációs adatbázis-kezelőre létrehozza a diagramban definiált táblázatokat, hasonlóan ahhoz, ahogy ezt a TSSDS SQL generátora csinálta.

A célból hogy a relációs adatbázis tervezés egész folyamatát konzisztenssé és szabványossá tegyék az amerikai Légierő létrehozta az IDEF1X modellező módszert, melyet az amerikai szabványügyi és technológiai intézet (NIST) 1993-ban föderális informatikai szabványként publikált FIPS 184 néven [6].

Mielőtt felvázolnánk az IDEF1X néhány jellemzőjét két dolgot elöljáróban el kell mondanunk. Az első az, hogy a viszonylag részletesen bemutatott TSSDS szabvány (illetve szabványos adatbázis) is az IDEF1X felhasználásával készült, már csak azért is, mivel az USA Védelmi Minisztériuma rendeletileg előírta kötelező használatát minden minisztériumi kompetenciájú informatikai tervezésre, a második megjegyzésünk pedig arra vonatkozik, hogy a Knowledge Based Systems, Inc. (KBSI) cég által kifejlesztett SmartER automatizálja a módszerrel tervezett adatbázis létrehozását.

Az IDEF1X módszert direkt a relációs adatbázis koncepcionális tervezésre hozták létre.

Egyik alapkoncepciója, hogy egy doboz a hasonló objektumok együttesét tartalmazza, mely objektumok mindegyikéhez attribútum csatlakozik, melyet a dobozba írt attribútum név képvisel. Minden, az egyedek közötti relációnak neve van, ami biztosítja az integritást. A relációkat a dobozok összekötő vonala jellemzi.

A rendszer támogatja a logikai adatstruktúrákat megkönnyítve ezzel az adatok csoportosítását és rendszerezését.

Az IDEF1X modell három színtű grafikából, szójegyzetből és modell megjegyzésekből áll. Az elnevezések formáját lexikális konvenciók korlátozzák. A grafika lehet

1. ER színtű, melyben nem szerepelnek a kulcsok;
2. Kulcs alapú (KB), melyben megjelenik a különbség a független és függő objektumok között és meghatározott szabályok szerint beírásra kerülnek az elsődleges és másodlagos kulcsok, az M:N relációk 1:N relációkká átalakítva jelennek meg;
3. Teljes attribútumú (FA), melyben az előző pontban leírtak mellett az összes fontos attribútumot feltüntetik az objektumok dobozában.

A szabvány egyszerű és gyors összefoglalását talán az segíti a legjobban, ha megnézünk egy FA színtű diagram példát a szabványból (5.38 ábra) és ezzel kapcsolatban mutatjuk be a legfontosabb tartalmi és jelölési kérdéseket. Megjegyzendő, hogy ha pld. a SmartER program segítségével a magyar elnevezésekkel próbáljuk megszerkeszteni a modellt, úgy az ékezetes betűket kerülnünk kell.

Az ábra felső sorában négy téglalapot látunk, fölöttük egy-egy névvel (Student=Diák, Course=Tantárgy, Semester=Szemeszter, Instructor=Oktató), melyek a diagramm független entitásait jelölik. A föléírt nevek az entitások nevei. Az entitást akkor nevezzük függetlennek, ha a téglalap elválasztó vonala felett beírt attribútum nevet az úgy nevezett elsődleges kulcsot (mely egyértelműen azonosítja az entitás valamennyi elemét, azaz valamennyi diákot, valamennyi tantárgyat, stb.) az entitás nem örökli más entitástól, hanem saját maga birtokolja.

Az elsődleges kulcsok esetünkben: Soc-Sec-No (TB-szám), Course-Code (Tantárgy-Kód), Semester-No (Szemeszter-Szám), Instructor-ID (Oktató-Azonosító).

Az elválasztó vonal alatt helyezkednek el az entitások egyéb attribútumai: Student-Name (Diák-Neve), Student-Address (Diák-Címe); Course-Name (Tantárgy-Neve), Std-Cred-Hrs (Szbv-Kred-Órsz); Start-Date (Kezdő-Dátum), End-Date (Bef-Dátum); Instructor-Name (Oktató-Neve), Instructor-Addr (Oktató-Címe), Degree (Fokozat), Instructor-Type (Oktató-tipusa).

A következő sorban elhelyezkedő entitásokat legömbölyített sarkú téglalapok ábrázolják. Ez az úgynevezett függő entitások jelölése. Az entitásokat akkor nevezzük függő entitásoknak, ha a szülő (előző) entitás(ok) teljes elsődleges kulcsát egy reláción keresztül átveszik és beépítik a saját elsődleges kulcsukba. Az ilyen relációt azonosító relációnak nevezik. Utalni szeretnénk a relációs adatbázisok ismertetésére, ahol megmagyaráztuk, hogy az elsődleges kulcs nem csak egyszerű hanem összetett is lehet. Azaz a teljes kulcs alatt az összetett kulcs valamennyi részét értjük. A szülőtől átvett kulcsot idegen kulcsnak (Foreign Key) nevezik és az attribútum után írt (FK) betűkombinációval jelölik a diagramban.

Az Enrollment (Beiratkozás) entitás elsődleges kulcsa négy átvitt idegen kulcsból áll, melyek közül egy a Soc-Sec_No a Student entitás teljes elsődleges kulcsa, míg a következő három Course-Code, Semester-No és Section-No (Csoport szám) a harmadik sorban lévő Class-Section (Osztály-Csoport) entitás teljes összetett elsődleges kulcsa , azaz az Enrollment függő entitás. Az entitás nem kulcs jellegű (azaz vonal alatti) attribútumai a következők: Date-Enrolled (Beiratkozás-Dátuma), Enrollment-Status (Beiratkozási-Státus), Enrollment-Type (Beiratkozási-Tipus).

Az Offering (Kínálat) entitás összetett elsődleges kulcsát két idegen kulcs a Course entitás elsődleges kulcsa - Course-Code és a Semester entitás elsődleges kulcsa - Semester-No alkotják. Mivel az átvitt kulcsok mindegyike komplett elsődleges kulcs, az Offering entitás függő entitás. A vonal alatt még egy, nem kulcs jellegű attribútumot az Act-Cred-Hrs (Akt-Kred-Órk) találunk.

A következő két entitás a Full-time (Fő-állás) és Part-time (Mellék-állás) különleges, úgy nevezett kategorizáló relációval származik az Instructor entitásból, egyszerű elsődleges kulcsuk Instructor-ID pedig megegyezik az eredeti entitás elsődleges kulcsával, ami úgy lehetséges, hogy a tanárok entitás egyedei megoszlanak a két entitás típus között. A fentiek szerint tehát ezek az entitások is függő entitások. A reláció teljes, mivel valamennyi oktató a két kategória egyikébe tartozik. Az egyéb attribútumok közül a Full-time entitás az Annual-Salary (Éves-Fizetés)-t, a Part-time entitás pedig a Hourly-Rate (Óra-Díj)-at tartalmazza.

Mielőtt a következő entitásokra rátérnénk ismerjük meg a specifikált relációk fogalmi és grafikai jellemzőit.

Az IDEF1X a relációs kapcsolat három fő típusát különbözteti meg:

• a specifikus összeköttetési relációt, mely lehet
• azonosító reláció,
• nem azonosító reláció, ezen belül
• kötelező nem azonosító reláció, és
• opcionális nem azonosító reláció;
• a kategorizálási relációt, melynek két lehetséges variánsa a
• teljes kategorizálási reláció és a
• nem teljes kategorizálási reláció;
• a nem specifikus relációt.

Az 5.39 ábrán felvázoltuk a különböző relációk jelölési módját, a reláció típusok tartalmi jelentését pedig az alábbiakban foglaljuk össze.

Minden specifikus összeköttetési relációt egy a szülőtől a gyerek felé mutató vonal reprezentál, melynek a gyermekoldali végén kitöltött pont van. A reláció gyerek oldali mutatója (kardinalitása) alapértelmezésben (ha nincs semmi a pötty mellé írva) 0, 1 vagy sok (azaz megszokott jelölésünkkel 1:0, 1:1, 1:N). Ne felejtsük el, hogy az M:N relációkat nem specifikus relációknak hívja a szabvány és a felsőbb szinteken feloldja specifikus relációkkal.

Az ábra felső sora szerinti jelekkel az alapértelmezési értékeket finomítani lehet.

Az azonosító relációról már beszéltünk a függő entitások kapcsán. Ezt csak azzal kell kiegészítenünk, hogy azonosító reláció esetén a gyerek entitás mindég függő, tehát legömbölyített téglalappal ábrázolandó, illetve hogy a relációnak nevet is kell adni (ez különben minden összeköttetési relációra igaz), aminek valamilyen igei kifejezésnek kell lennie (szemben az entitások és attribútumok nevével, amik főnevek).

A nem azonosító relációk gyerek entitásai nem öröklik elsődleges kulcsukat a szülő entitástól, ezért a gyerek entitásokat szögletes téglalap ábrázolja. Ezenkívül még az összeköttetés rajzi megjelenítésére szaggatott vonalat alkalmaznak. A kötelező nem azonosító reláció azt jelenti, hogy a gyerek entitás minden egyede a szülő entitás egy-egy meghatározott egyedéhez kapcsolódik (amint majd példánkból látni fogjuk minden tankörnek lesz egy konkrét oktatója). Az opcionális nem azonosító relációra ez a szabály már nem igaz, itt a gyerek entitás egyedei zérus vagy egy egyedhez csatlakoznak a szülő entitásban. Rajzilag ezt a reláció típust a szülő entitás alá rajzolt rombusz különbözteti meg a kötelező nem azonosító relációtól.

A kategorizálási reláció lehetővé teszi, hogy az eredeti entitás (ez felel meg itt az összeköttetési reláció szülő entitásának) elemeit típusokba csoportosítsuk. A csoportosítást az eredeti entitás egyik attribútuma alapján végezzük. Ezt az attribútumot diszkriminátornak hívjuk és a diagrammon az eredeti entitásból kiinduló vonal alá rajzolt kör mellé írjuk. Ezeknek a relációknak nincs nevük, ezt pótolja a diszkriminátor. E relációkban a gyerek entitásoknak megfelelő kategória entitások minden esetben függő entitások és lekerekített téglalappal ábrázolandók. Teljes kategorizálási reláció esetén a kategória entitások teljes halmazt alkotnak, azaz az eredeti entitás minden egyede besorolható valamelyik kategóriába. Nem teljes kategorizálási reláció esetén lesznek olyan egyedek az eredeti entitásban, melyek kategóriájának megfelelő kategória entitás hiányzik. A kategorizálási reláció grafikus vonatkozásai jól szemlélhetők az 5.39 ábrán.

A nem specifikus relációt amint már említettük a KB és FA szinteken specifikus azaz 1:N relációkká kell alakítani. Hogy ez miként történik újabb entitások bevonásával már bemutattuk a hálós adat modellről szóló pontban (igaz fordított értelemben).

Ezután a kis kitérő után visszatérhetünk példánk elemzésére.

A következő két entitás a Grade (Fokozat) és Audit (Vendég-Hallgató) teljes kategorizáló relációval származik az Enrollment (Beiskolázás) entitásból, összetett elsődleges kulcsuk pedig megegyezik az eredeti entitás elsődleges kulcsával, ami úgy lehetséges, hogy a beiskolázott entitás egyedek megoszlanak a két entitás típus között. A fentiek szerint tehát ezek az entitások is függő entitások. A reláció teljes, mivel valamennyi hallgató a két kategória egyikébe jelentkezhet. A kategorizálás az Enrollment-Type (Beiskolázási-Tipus) nevű diszkriminátor attribútum segítségével történik.

A függő Attendance (Jelenlét) nevű entitás azonosító relációval kerül az Enrollment (Beiskolázás) entitásból levezetésre. A gyerek entitás összetett kulcsa a szülő összetett kulcsából és a Class-Date (Foglalkozás-Dátuma) attribútumból áll. A nem kulcs jellegű attribútumok közül (a vonal alatt) az Attendance-Status (Jelenléti-Státus) szerepel az entitásban.

A Class-Section (Osztály-Csoport) függő entitás összetett kulcsának első részét az Offering (Kinálat) entitástól kapta, melyhez még hozzárakja a saját Section-No (Csoport-Szám) kulcsrészét. Arról már szóltunk, hogy ez az entitás maga is szülő az Enrollment (Beiskolázás) entitás vonatkozásában. E mellett még kötelező nem azonosító reláció kapcsolja az Instructor (Oktató) entitáshoz, melyből kiderül, hogy melyik oktató melyik tanulókört vezeti. Vonal alatti attribútuma az Instructor-ID (Oktató-Azonosító) szintén idegen kulcs (FK), de ez nem része az entitás összetett elsődleges kulcsának. A Class-Section (Osztály-Csoport) nem csak az Enrollment, de a Class-Text (Osztály-Tankönyv) függő entitás felé is szülőként szerepel.

A Class-Text (Osztály-Tankönyv) függő entitás egyik szülőjét már említettük, másik szülője a Textbook (Tankönyv) független entitás. Ez utóbbi a rendelkezésre álló tankönyvek tárolására szolgál, elsődleges kulcsa a Textbook-No (Tankönyv-Szám), vonal alatti attribútumai a Textbook-Name (Tankönyv-Címe) és a Pub-Co-Name (Kiadó-Neve).

Bár a felvázolt példa kapcsán több részletkérdésre nem tértünk ki, reméljük hogy ismertetésünk megkönnyíti valamely IDEF1X-et értelmezni képes CASE szoftver használatát.

A Common Object Request Broker (CORBA) [7]

A Közös Objektum Kérés Közvetítő (CORBA) architektúra új, hálózaton elosztott különféle (heterogén) objektumok közös felhasználását lehetővé tevő infrastruktúra, mely specifikációt az Objektum Kezelő Csoport (Object Management Group vagy OMG) dolgozta ki.

A rendszer architektúrája két fő részre osztható: az objektum modellre és a referencia modellre. Az objektum modell azt határozza meg, hogy a hálózaton szétosztott objektumok milyen módon írhatók le. A referencia modell az objektumok egymásra hatását jellemzi.

Az objektum modell elemei különálló, egyedien azonosított entitások, melyek szolgáltatásait csak jól meghatározott interfészeken keresztül lehet elérni. Az objektumok szolgáltatásait igénylő kliensek számára az egyes objektumok implementációja és helye rejtve van.

A CORBA számos közös hálózati programozási feladatot automatizál, többek közt az objektum regisztrálást, elhelyezést, aktiválást, a kérések lebontását, illesztését és a hiba kezelést, a paraméterek rendezését, a műveletek szervezését.

Az 5.40 ábra bemutatja a CORBA funkcionális blokk-vázlatát. Az ORB feladata főként a kliensek és objektumok közötti kommunikáció lebonyolítása. Az ORB az alábbi négy objektum interfész kategórián keresztül használható.

Az Objektum Szolgáltatásokat alkalmazási területtől függetlenül számos osztott objektumokkal dolgozó program használja. Pld. az olyan szolgáltatás, mely lehetővé teszi más elérhető szolgáltatások feltárását szinte mindég hasznos függetlenül a felhasználási területtől.

Példaként megemlítjük a Név Szolgáltatást, mely segítségével a felhasználó az objektumokat nevük alapján érheti el vagy a Kereskedelmi Szolgáltatást mely segítségével a kliensek objektumokat kereshetnek azok tulajdonságai alapján. Létezik még specifikáció az élet ciklus kezelésre, biztonságra, tranzakciókra, esemény jelzésre, stb.

A Közös Segítők is az Objektum Szolgáltatásokhoz hasonlóan szintén horizontálisan irányított interfészek azzal az eltéréssel, hogy kizárólag végfelhasználói alkalmazásokra irányulnak.

Példaként említjük az Osztott Dokumentum Komponens Segítőt (Distributed Document Component Facility (DDCF)), mely az OpenDoc specifikáción alapul és lehetővé teszi például hogy a jelentésbe különböző helyekről táblázatokat illesszenek.

A Tartomány Interfészek hasonló szerepet játszanak mint az Objektum Szolgáltatások és a Közös Segítők azzal a különbséggel, hogy egy speciális alkalmazási tartományra irányulnak. Az első specifikációt a gyáripar számára adták ki, készülőben a távközlési, orvosi és pénzügyi tartományok specifikációi. Itt kell megemlítenünk, hogy a térinformatikai tartomány specifikációja is készül, részben ezt szolgálják az OpenGIS törekvések.

Az Alkalmazási Interfészek egy speciális alkalmazásra készülnek és ezért nem szabványosítottak, ha azonban egy alkalmazás igen népszerűvé válik, úgy az OMG elhatározhatja, hogy elkészíti a specifikációit és ezzel átkerül a szabványos tartományi interfészek közé.

A CORBA főbb komponensei a következők:

• ORB Mag,
• OMG Interfész Definíciós nyelv (IDL),
• Interfész Raktár,
• Nyelv Leképezések,
• Csonkok és Vázak,
• Dinamikus hívás és küldés,
• Objektum Adapterek,
• Belső ORB Protokollok.

Az 5.41 ábra bemutatja a CORBA ORB (sötétkék blokk az 5.40 ábrán) főbb komponenseinek architektúráját.

Amint már említettük a CORBA heterogén hálózati objektumok átlátszó elérését teszi lehetővé a kliens számára. Ahhoz, hogy ez megtörténhessen az objektumokat implementálni kell, ami azoknak a műveleteknek együttesét jelenti, melyek létrehozzák a CORBA IDL interfészt (IDL = Interface Definition Language azaz interfész definíciós nyelv). Maga az implementálás számtalan nyelven, többek közt C, C++, Java, Smalltalk, és Ada nyelven is íródhat.

Kliensnek nevezik azt a programot, mely műveletet kezdeményez az objektum implementáción. A távoli objektum szolgáltatásainak elérése átlátszó kell hogy legyen a meghívó számára, ideális esetben ez az aktus nem kell hogy különbözzön valamely helyi objektum módszer hívásától.

Az 5.41 ábra többi eleme ezt az átlátszóságot hivatott támogatni.

Az ORB Magja vezérli azt a folyamatot mely átlátszóan kezeli a cél objektum implementációk felé irányuló kliens kéréseket. Az ORB egyszerűsíti az osztott programozást mentesítve a klienst a módszer meghívások részleteitől, ezért a kliens kérés úgy tűnik mint egy helyi eljárás meghívása.

Amikor a kliens egy műveletet kezdeményez az ORB felel azért, hogy megtalálja az objektum implementációt és transzparensen aktiválja azt szükség esetén, átadva az objektumnak a megkeresést és továbbítva minden választ a hívó felé.

Az ORB Interfész - Az ORB egy olyan logikai entitás, mely számtalan módon implementálható, mint például egy vagy több eljárás vagy egy könyvtár gyűjtemény segítségével. Azért hogy az alkalmazásokat ne terheljék az implementációs részletek a CORBA specifikáció meghatározza az absztrakt ORB Interfészt. Az interfész számtalan segítő funkcióval is rendelkezik - pld. sztringgé alakítja az objektum referenciákat vagy fordítva, és az alább ismertetendő dinamikus hívás interfészen (DII) keresztül argumentum listákat készít a megkereséseknek.

Az objektum interfészeket az Interfész Definíciós Nyelven (Interface Definition Language=IDL) határozza meg a CORBA specifikáció. Az IDL deklaratív nyelv mely segítségével létrehozott objektum interfész megmondja, hogy az objektum milyen típusokat és műveleteket támogat.

Mivel az IDL nem programozási nyelv az alkalmazásokat nem lehet benne megírni, de azért hogy ezek a más nyelven írt alkalmazások megértsék az IDL interfészeket Nyelvi Leképezéseket (Language Mappings) alkalmaz a CORBA, azaz lefordítja az IDL interfészeket az alkalmazások nyelvére (C, C⁺⁺, Smalltalk, Ada 95, JAVA, stb.).

A CORBA IDL csonkok és vázak a ragasztó szerepét játsszák a kliens alkalmazás illetve a szerver alkalmazás és az ORB között. A csonkokat, más néven helyettesnek (proxy) is hívják. Ezek az alkalmazás nyelvére lefordított IDL szerkezetek képviselik az alkalmazói program számára a kérdéses objektumot, azaz a program a csonkra adja ki a helyi függvény hívást, melyet a csonk az ORB interfészen keresztül az objektumba épített vázra továbbít, mely az objektum felé helyi hívásként jeleníti meg a távoli megkeresést. A fent leírt mechanizmus feltételezi, hogy a csonkok és vázak a priori információval rendelkezzenek a meghívott objektumok IDL interfészéről.

A transzformációt a CORBA IDL definíciók és a tárgy program nyelv között a CORBA IDL Kompájler automatizálja. A kompájler használata csökkenti az inkonzisztenciák lehetőségét a kliens csonkok és a szerver vázak között e mellett növeli az automatizált kompájler optimalizálás lehetőségét.

A Dinamikus Hívási Interfész (Dynamic Invocation Interface (DII)) lehetővé teszi, hogy a kliens közvetlenül elérje az ORB által nyújtott megkeresési mechanizmust, ezért a DII olyan általános csonknak tekinthető, mely független a meghívott objektumok IDL interfészétől, s melyet közvetlenül az ORB biztosít. Az alkalmazások arra használják a DII-t, hogy dinamikus kérést adjanak ki az objektumoknak a nélkül, hogy az IDL interfész specifikus csonkok bekapcsolásra kerülnének. Az IDL csonkok ugyanis csak RPC (Távoli Eljárás Hívás) típusú kérésekre alkalmasak, míg a DII alkalmas nem blokkoló késleltetetten szinkronizált (külön művelet az elküldés és a fogadás) és egy irányú (csak elküldött) hívások kezelésére is.

A Dinamikus Váz Interfész (Dynamic Skeleton Interface (DSI)) a kliens oldali DII szerver oldali analógja. Lehetővé teszi, hogy az ORB meghívjon egy olyan objektum implementációt, melynek nincs előzetes ismerete az implementált objektum típusáról. A megkereső kliens pedig szintén nem tudja, hogy az objektumnak van e típus specifikus váza, vagy pedig az ORB dinamikus vázait használja.

Az Objektum Adapterek (Object Adapters) kapcsolatot alkotnak a CORBA valamely programozási nyelven implementált objektuma és az ORB között. Tulajdonképpen arról van szó, hogy az objektum adapteren keresztül a hívó olyan objektumokat is meg tud keresni, melyek valódi interfészét nem ismeri.

A Belső ORB Protokollok a hálózaton különböző helyeken elhelyezkedő ORB-k együttdolgozását hivatottak biztosítani. A GIOP (General Inter-ORB Protocol) rögzíti az átviteli szintakszist és a szabványos üzenet formátumokat bármely összeköttetés orientált átvitel esetén. Az IIOP (Internet Inter-ORB Protocol) azt specifikálja, hogy miként épül fel a GIOP a TCP/IP Internetes hálózati átviteli protokoll felhasználásával.

Az Univerzális Modellező Nyelv = Universal Modeling Language (UML) [8]

Az objektum orientált programozás általánossá válásával szükség volt olyan szabványos grafikus nyelvre, melyet az objektum orientált elvek alapján fejlesztettek ki. Ez a nyelv az ULM.

A nyelv kifejlesztésére 1996-ban 12 nagy szoftvergyártó konzorciumot alapított. A specifikáció elkészítése nem váratott sokáig magára. 1997-ben az OMG (Object Management Group) szabványosította az UML 1.1 verzióját, jelenleg (1999-ben) elkészült az UML 1.3 verzió tervezete, melyet még az idén kívánnak elfogadni. A nyelv kidolgozásában döntő szerepet játszott a Rational Software cég három munkatársa Grady Booch, Jim Rumbaugh és Ivar Jacobson. Az említett Rational Software honlapján található az UML-hez kapcsolódó irodalom leggazdagabb tárháza. Megemlítjük még hogy a cég Rational Rose nevű szoftvere talán a legjobb UML alapú CASE szoftver, mely shareware verziói az említett honlapról letölthetők.

Az UML objektum orientált elveken alapuló grafikus modellező nyelv, melyet elsősorban bonyolult szoftver rendszerek tervezésére és dokumentálására használhatunk, de tulajdonképpen minden bonyolult üzleti, szolgáltatási, termelési folyamat modellezésére alkalmas. A nyelv azonban "csak" eszköz a modellezéshez, de nem módszer, azaz azok számára hasznos, akik ismerik az objektum orientált rendszerek tervezési, modellezési eljárásait.

Maga a specifikáció 6 fő részből áll: UML összefoglaló, Tartalmi szabályok (szemantika), Jelölési szabályok, UML kiterjesztések, UML CORBA Interfész definíció, A korlátozásokat leíró nyelv (OCL) specifikációja.

Az UML a modellezés tárgyát képező jelenséget a következő öt nézeten keresztül közelíti meg:

·         Használati nézet (use-case view)

·         Logikai nézet (logical view)

·         Komponens nézet (component view)

·         Versengési nézet (concurrency view), ez a nézet a Rational Rose szoftverben nem szerepel, ezért ismertetésétől eltekintünk

·         Megvalósítási nézet (deployment view).

Lényeges megemlíteni, hogy ez a nézet kívülről szemléli a rendszert, azaz a rendszer belső építkezése nem e nézet struktúráját, hanem funkcionalitását hivatott megvalósítani.

Az 5.43 ábra eredetijét (a kék magyarázó szöveg és nyilak kivételével) a Ratianal Rose 98 kiértékelési (30 napig használható) verziójával készítettem egy egyetemi nyilvántartási rendszer használati modelljeként. Mielőtt a magyarázatokat megkezdeném elmondom, hogy a szereplőknek és felhasználásoknak igyekeztem ékezet nélküli magyar neveket adni, ezt természetesen nem tehettem meg ott, ahol a szoftver adta meg a szabványos angol nyelvű szöveget.

A használati nézetet három diagram típus modellezi, ezek közül az első az 5.43 ábrán látható felhasználási (use-case) diagram. A diagram elemei a szereplő (Actor) pálcika emberrel jelölve, a felhasználás (Use-Case) – a jele ellipszis, az egyszerű vonallal jelölt kommunikációs kapcsolatok és két üres nyíllal jelölt <<uses>> vagy <<extends>> sztereotípiákkal címkézett generalizáló kapcsolat típus.

Strukturális szempontból még érdekes megjegyezni, hogy valamely szereplő különböző felhasználásait csomagba (package) lehet szervezni, ez történt meg esetünkben a Nyilvantarto Felhasznalasai-val.

A példa gondolati tartalma talán nem igényel különösebb magyarázatot (gondoljunk a Neptunra).

A második diagram típus a folyamat diagram (Sequence Diagram) felhasználásonként készíthető, és a felhasználás megvalósításának folyamatában lejátszódó eseményeket szemlélteti.

A folyamat diagramok szereplőket, objektumokat és üzenetekettartalmaznak. A szereplő jelölése hasonló a felhasználói diagramhoz, a név megírás azonban már arra utal, hogy a professzor szereplő tulajdonképpen osztályt reprezentál. Az objektumok jelölésére szolgálnak a sárga téglalapok, melyekben az objektum neve után megtaláljuk annak az osztálynak a nevét is, melyhez az objektum tartozik. Az üzeneteket a küldő (kliens) és a fogadó közötti nyíl reprezentálja kiegészítve az üzenet sorszámával és nevével. A sorszám ebben a diagram típusban el is volna hagyható, mivel a diagram függőleges koordinátája egyben az időt reprezentálja (azaz ami lejjebb van az később következik be). Az objektumok önmaguknak is küldhetnek üzenetet, ezeket az üzeneteket reflexív üzenetnek hívják, jelölése a visszahajló nyíl (az 5: üzenet az 5.44 ábrán). A konkrét példa esetében a folyamat diagram azt reprezentálja, hogy milyen végrehajtási sorrendben jelenik meg a professzor szereplő félévre vonatkozó tantárgyjavaslata a hallgatók számára felkínált tantárgy kínálatban.

Míg a folyamat diagram a felhasználásban szereplő függvény hívások (üzenetek) egymásutániságát domborítja ki, addig a felhasználási nézet harmadik diagram típusa az együttműködési diagram (Collaboration Diagram) a felhasználásban résztvevő objektumok közötti kapcsolatokra helyezi a hangsúlyt.

Az együttműködési diagram a Rational Rose szoftverben a folyamat diagramból automatikusan állítható elő, ami azt jelenti, hogy nem használ fel új információt, hanem a rendelkezésre álló modell ismereteket más formában mutatja be.

Új dolgot nem igen tartalmaz ez a diagram típus, legfeljebb arra érdemes figyelni, hogy az objektumok közötti kapcsolatok illetve a kapcsolatokat felhasználó üzenetek külön jelölésként jelentkeznek.

Mind a használati nézetben, mind a továbbiakban ismertetendő logikai nézetben lehetőség van úgy nevezett csomagok (package) létrehozására. A csomagok lehetővé teszik, hogy a valamilyen szempontból összetartozó felhasználásokból illetve osztályokból csomagokat hozzunk létre s ily módon egyszerűsítsük a diagrammok megrajzolását. Ebben az esetben ugyanis külön lehet választani a csomagok közötti kapcsolatok modellezését a csomagon belüli kapcsolatok modellezésétől.

A logikai nézet, ha szabad így fogalmazni, az UML fő nézete. Tulajdonképpen két fő diagram típusa van: az osztály diagramok (Class Diagram) és az állapot átmeneti diagramok (State Transition Diagram). Az osztály diagramok a rendszer statikus állapotát modellezik, míg az állapot diagramok a rendszer dinamikus sajátosságait mutatják be.

Mielőtt az osztály diagramok részleteire rátérnénk nézzük meg a tantárgy választási rendszerünk példáján a logikai nézet csomagokra bontását (5.46 ábra).

Amint látjuk a rendszert három csomagra bontottuk, melyek belső kapcsolatait az osztály diagramokon modellezhetjük. Megjegyezzük, hogy egy-egy csomag osztálydiagramja tartalmazhat más csomaghoz tartozó objektumokat is, de ebben az esetben az objektumok csomag-tartozása az ábrán feltüntetésre kerül.

5.46 ábra - logikai nézet csomagokra bontása

Az 5.48 ábrán bemutatjuk az Egyetemi Eszkozok csomag osztálydiagramját, mely segítségével meg fogjuk ismerni az osztály diagramok tartalmára és jelölésrendszerére vonatkozó legfontosabb tudnivalókat.

Az osztálydiagramok legfontosabb alkotói az osztályok. Népszerűen szólva, az osztályok hasonló tulajdonságú objektumok közös tulajdonságait reprezentáló képződmények. Az osztályok jelölésére három rekeszre osztott téglalapot használ az UML, ahol az első rész tartalmazza az osztály nevét, a második rekeszben helyezkednek el az osztály attribútumai a harmadik rekesz pedig az osztályra értelmezett műveleteket foglalja magába. A jelölési rendszer lehetővé teszi, hogy a név rekeszen kívüli rekeszek, ha nincs rájuk szükség, ne legyenek ábrázolva. A név felett francia idézőjelben szerepelhet az osztály sztereotípiája (a nyelvben előre definiált használati aspektusa), ha ilyen van.

Az osztályokra vonatkozóan, a már említett sztereotípián kívül ábrázolhatjuk még az osztály láthatóságát (más csomagokból illetve programokból való elérhetőségét) is, ez azonban az alapértelmezésű nyilvános (public) mellett csak az export vagy import státus deklarálását teszi lehetővé. Az első esetben semmit sem írunk az osztály név alá, a második esetben (impl.), a harmadik esetben (from Valahonnan) szöveget, ahol a Valahonnan az a csomag ahonnan importáljuk. Az 5.47 ábra tanulsága szerint az osztály attribútumainak láthatóságát a kék téglalap ikon, míg a műveletek láthatóságát a lila téglalap ikon kulccsal, lakattal vagy kalapáccsal történő kiegészítése mutatja.

5.47 ábra - láthatósági ikonok

Az attribútumok jellemzésére a sztereotípián és néven kívül szerepeltethetjük még a típusát és kezdőértékét is. Hasonlóképpen a műveleteket is kiegészíthetjük az argumentum név és a visszaadott típus megadásával. Ha a diagrammokat nem szabad kézzel rajzoljuk, hanem valamely CASE szoftver felhasználásával, úgy az említett kiegészítő jellemzők (ha már modelleztük őket) bármikor megjeleníthetők, ezért az áttekinthetőség érdekében csak akkor jelenítjük meg őket ha a további modellezési lépések igénylik.

Kiemelkedő fontosságúak az osztályok közötti kapcsolatokat megjelenítő szimbólumok.

A felhasználási diagram kapcsán már megismert egyszerű kétirányú kommunikációs kapcsolat vagy asszociáció (jelölése folyamatos vonal) az osztály diagramban is felhasználható. A kapcsolatot egy irányúvá tehetjük a megfelelő végén alkalmazott egyszerű nyíllal. Az asszociációnak nevet is adhatunk vagy - ahogy ezt példánk esetében tettük - a megfelelő végeihez úgy nevezett szerep neveket (role name) rendelhetünk annak a szerepnek megfelelően amit a kérdéses végződés a konkrét modellben játszik.

Az ER diagramok kapcsán már megismert multiplicitást is jelölhetjük a kapcsolatok végén alkalmazott 1, 0..*, 1..*, +m..n számok illetve intervallumok megadásával. Érdemes megemlíteni, hogy a két számmal megadott intervallum szerep névhez kapcsolódik, ezért előtte a + jelet is ki kell írni.

Az 5.48 ábrán még két más jellegű kapcsolat típussal is találkozunk.

A függést egyszerű nyílban végződő szaggatott vonal jelöli, ahol a nyíl a független osztályra mutat. Példánkban az összes tantárgyat tartalmazó Tantargy osztály a független, a Katalogus osztály pedig, mely információkat tartalmaz a kérdéses félévben meghirdetett tárgyakról függő, mivel nem hirdethető meg olyan tárgy, amely nem szerepel a Tantargy-ban.

Az aggregáció (összegzés) jele egy folytonos vonal az egyik végén egy üres rombusszal. A rombusz az egészet jelentő osztály mellett van, következésképpen a vonal másik vége a részt jelölő osztályhoz csatlakozik.

Példánkban a Tantargy osztály valamennyi lehetséges tantárgyat tartalmazza, melynek része a kérdéses szemeszterre meghirdetett tárgyakat tartalmazó TantargyKinalat osztály. Létezik az aggregációnak egy szigorúbb formája is amit kompozíciónak hívnak. Lényege, hogy a részeket az egész egyidejűleg birtokolja. Jelölése a kitöltött rombusz. Erre szolgáló példákkal találkozunk majd az OpenGis adatmodell ismertetésénél is, egyelőre, a tantárgy választási példánktól függetlenül, azt mutatjuk be az 5.49 ábrán, hogy miként alkotják az ablakot két görgetősáv egy cím és egy szövegtest szerep nevű objektum.

Az 5.50 ábrán bemutattuk a Szemelyiinformacio csomag osztály diagramját. E diagram segítségével megismerhetjük az utolsó, negyedik kapcsolat típust a generalizáló kapcsolat típust, mely az objektum orientált fogalomkörben oly fontos öröklődés modellezésére szolgál.

A logikai nézet másik diagram típusa az állapot diagram. Ez a diagram azt modellezi, hogy milyen állapot átmeneteken megy keresztül a vizsgált osztály a feladat indítása és zárása között. Míg az osztály diagram a feladat statikus szerkezetét dokumentálja, addig az állapot diagram a feladat dinamikáját szemlélteti.

Tárgy választási példánknál maradva szerkesszük meg az EgyetemiEszkozok csomag TantargyKinalat osztályának állapot diagramját (5.51 ábra).

Az állapot diagram kezdő illetve vég állapotát az indulj és állj ikonok jelölik: az indulj ikon teli fekete kör, az állj ikon a tömött fekete kört még körülveszi egy üres koncentrikus körrel. Minden állapot diagramnak egy indulj és egy vagy több állj állapota van.

A következő új szimbólum a közbenső állapotokat reprezentáló legömbölyített sarkú téglalap. Az állapot szimbólumot egy vízszintes vonal ketté vágja. A felső részben foglal helyet az állapot neve, az alsó részben pedig az általa végrehajtott akció. Annak a függvényében, hogy az akció mikor hajtódik végre 'entry' = belépés, 'exit' = kilépés és 'do' = belépéstől kilépésig jelző valamelyike előzi meg az akció megnevezését.

Maga a végrehajtandó cselekmény háromféle lehet. Vagy tulajdonképpeni akció (művelet végrehajtás), vagy esemény (üzenet) küldés attribútummal vagy attribútum nélkül. Az utóbbi két esetben a fogadó objektumot is meg kell nevezni. Maga az esemény ^ jellel kezdődik és pont választja el a fogadó objektum nevétől. Ha az esemény attribútumokat is tartalmaz azok zárójelben követik az esemény nevét.

Az állapot átmeneteket nyíllal végződő vonalak jelölik. Tulajdonképpen ezek az átmenetek is rendelkezhetnek azokkal a jellemzőkkel (akciók, események) mint az állapotok csak az a különbég, hogy átmenet esetén nem lehet megadni az akció idejét, illetve hogy az átmeneteknél feltételeket is lehet megadni az akció végrehajtásához. A feltételek szögletes zárójelben jelennek meg a rajzon. A példánkon látható Nyit állapotot reflexív átmenet kapcsolja önmagához, azaz az állapot mindaddig visszacsatol a belépésre és regisztrálja a diákokat amíg a regisztrált diákok száma el nem éri a 10-et.

Az ábra jobboldalán található Nyit és Lezár állapotokat Regisztrálás néven összevont (szuper) állapottá foglaltuk össze. Az ilyen összefoglalás a bonyolult állapot diagrammok egyszerűbb áttekintését célozza.

A komponens nézet a logikai nézet elemeit program modulokra képezi le. A szoftver szervezés komponens diagrammok segítségével valósul meg. E diagramok információval szolgálnak a rendszer végrehajtó (exe) fájljairól és könyvtárairól (dll fájlok).

5.53 ábra - szoftverkomponensek ossztályokhoz rendelése

Ezután létre kell hoznunk a Regisztralas csomag komponenseit: a Regisztralo.exe, Tantargyak.dll és Emberek.dll program modulokat, majd az 5.53 ábra szerint hozzá kell rendelnünk a logikai nézet megfelelő osztályaihoz a realizálásukra hivatott szoftver komponenseket. A hozzárendelést a Rational Rose program tallózó részében végeztük a szokásos 'ráhúzásos' technikával.

Az utolsó lépésben megrajzoljuk a diagramban a függőségeket, kézenfekvő, hogy a végrehajtó modul (Regisztralo.exe) függ a dinamikusan kapcsolt könyvtáraktól (dll), míg ez utóbbiak függetlenek az exe programtól.

A megvalósítási nézet a futás ideji feldolgozó csomópont architektúrát vizsgálja a kapcsolódó komponensekkel, folyamatokkal és objektumokkal. A nézetnek egy diagramja van - a megvalósítási diagram. A diagram kétféle csomópont típust és összeköttetéseket tartalmazhat. A csomópont típus vagy feldolgozó kapacitással rendelkező processzor, vagy legalább memóriával rendelkező úgy nevezett eszköz lehet.

Az 5.54 ábrán bemutatott megvalósítási diagram csak processzor csomópontokat tartalmaz. A diagram típus másik alkotó eleme az összeköttetés, mely a csomópontok közötti kommunikációt modellezi. Az összeköttetés jellemzésére használhatunk sztereotípiát is, ilyen lehet az átviteli csatorna vagy hálózat típusa. Ábránk esetében eltekintettünk a jellemzőktől.

A téma befejezéseként ismét aláhúzzuk, hogy e rövid összefoglaló semmiképpen sem célozta meg az UML részletes ismertetését, különösen nem az objektum orientált programozás modellezési technikája szempontjából. Célunk csak az volt, hogy az UML segítségével definiált térbeli adatmodellek az összefoglaló segítségével könnyebben legyenek megérthetők.

·         a következő részben megismerkedünk a STEP szabvánnyal és az EXPRESS adatleíró nyelvvel

·         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