Generikus világmodellező nyelv

Varga Gábor, 2005. július 9.

Sokféle megoldás készült már az idők során a fellelhető ismeretek és a világ formalizált leírására, a különböző tudásterületeken más-más modellezési módszer az elfogadott. Az objektumorientált paradigma szerinti szoftvertervezés és az üzleti folyamatok rögzítésének nyelve, az UML például kevésbé alkalmas ontológia jellegű tudásmorzsák leírására. A leíró logika segítségével a tudományos világban anyanyelvnek számító matematikai formalizmust használhatjuk a modellezésre. Az internetes világ információbrókereinek számító webszolgáltatások leírására ismét más megoldás elfogadott, mely akár összetett típusok használatát is megkövetelheti - a WSDL szabvány szerint írhatjuk le ezeket.

A feladat annak megvizsgálása, hogy milyen módon hozható az UML, a leíró logikák és a webszolgáltatások világa egy közös fedél alá. A projekt célja egy olyan egységes modellezési nyelv létrehozása, mely alkalmas arra, hogy a jelenlegi legelterjedtebb leíró nyelveken megfogalmazott modelleket közös világban integrálja, lehetővé teszi a különböző nyelvek modellezési elemeinek együttes használatát. Specifikusabban megfogalmazva tehát egy olyan nyelv kiválasztása vagy megtervezése a feladat, mely képes leírni mind az UML, a DL és a WSDL nyelvén megfogalmazott állításokat.

1. Tervezési fázis

A tervezés során megtörténik a projekt méretének és korlátainak a felmérése, a cél pontos specifikációja, majd a megvalósítás lehetőségeinek vizsgálata. Ezek a lehetőségek prekoncepciók által kötöttek, hiszen a projekt nem önmagában létezik, hatást gyakorol rá a környezete is.

1.1. A kutatómunka lépései

A projekt időtartama 4-6 munkahét, ennek az időnek a hatékony beosztásához nyújt segítséget a következő ütemterv.

1.2. Meghatározó előfeltételek

A kutatás elsődleges célja egy létező információ- és tudásintegrációs rendszer, a SILK (System Integration via Logic and Knowledge) modellezési nyelvének lecserélése egy olyanra, amely képes a különböző leírónyelveken készített modellek menedzselésére. Ebből adódóan prioritást élveznek az integrálandó nyelvek közül azok, melyek a rendszer számára fontosak.

Előfordulhat az is, hogy a SILK rendszer által használt nyelveknek nem minden funkcióját fogom megvalósítani, csak azokat, amelyekre a rendszer építkezik. Erre abban az esetben kerülhet sor, ha egyes nem szükséges nyelvi elemek megvalósításához aránytalanul nagy ráfordítás lenne szükséges, vagy a választott célnyelv használatát valamely korlátjából adódóan kizárná. Az így kimaradó elemek megvalósítása a projekt szempontjából másodlagos, egy esetleges TDK dolgozat keretében kerülhet rá sor.

A másik fontos feltétel, hogy a nyelvhez minél könnyebb legyen olyan alkalmazásokat készíteni, melyek a rendszer számára fontos műveletek elvégzésére képesek: ilyenek a validálás és a következtetés. Még előnyösebb, ha kész megoldások léteznek, emiatt cél a már létező nyelven történő implementáció.

1.3. Prekoncepciók

Tervem a problémát az OWL DL kifejezőeszközeinek segítségével megoldani, tekintve hogy a leíró logika a következtetési feladatok elvégzésére, illetve az RDF az ontológia jellegű tudásbázisok leírására különösen alkalmas megoldásnak mutatkozik.

Az RDF (Resource Description Framework) koncepció lényege, hogy a világ egyedeiről állításokat mondhatunk ki, nyílt világot modellezve. Az állítások tulajdonképpen hármasok: egy alanyt és egy tárgyat kapcsolnak össze egy relációval. Relációk és fogalmi osztályok gyűjteményeként szolgálnak az OWL (Web Ontology Language) tudáshalmazok, melyek általában a világ egy szeletét modellezik. A szintaxis, mellyel ezeket az állításainkat leírhatjuk, XML alapú: flexibilis, egyszerű de ezzel párhuzamosan robosztus és erőteljes is.

Az XML ereje abban rejlik, hogy kellőképpen strukturált ahhoz, hogy gépek képesek legyenek értelmezni, ám elég olvasható is maradt, hogy az emberek is elboldoguljanak vele. Érthető választás tehát, ha az információt, aminek a birtokában vagyunk, amit létrehozunk vagy átalakítunk, ennek a technológiának a segítségével kívánjuk minél többekhez eljuttatni.

A problémát a nem leíró logikai nyelvek sajátosságainak integrálhatósága jelentheti majd (pl. összetett típusok), illetve kérdéses, hogy a korlátozások milyen mértékben valósíthatók meg, ugyanis az OWL DL nem ad lehetőséget néhány fajta megkötés tételére, illetve a létező következtetők is „megfeledkeznek” néhány nyelvi elemről.

Ennek a hiányosságnak az áthidalása az OWL nyelv kifejezőerejének bővítésével érhető el, ennek megvalósítását nagyban könnyíti az XML kiterjeszthetősége. A bővítés néhány, az elsőrendű logikából vett konstrukcióra terjedhet ki, melyek segítségével az OWL felnőhet a többi integrálandó nyelvhez.

Másképp tekintve az elgondolásra: a cél elsőrendű logikai alapokon megoldást nyújtani, majd ennek szintaxisát a modellezéssel rokon ontologiakezelés nyelvének számító OWL kiterjesztésével megadni, más szabványosított logikai formalizmus híján. Persze vannak mások, tehát ez nem igaz...

1.4. A forrásnyelvek kiválasztása

A projekt szempontjából alapvető fontosságú az UML támogatása, hiszen a jelenlegi modellek ezen a nyelven vannak tárolva. A megkötéseket az UML OCL kiegészítésének segítségével írja le a rendszer.

A SILK másik alappillére a leíró logika. A modellekben megjelenhetnek megnevezett vagy képzett fogalmak és köztük definiált szerepek is. Ezek szemantikája az UML-es környezetben nem pontosan definiált, többek között ezeknek a kérdéseknek a megválaszolása jelen dokumentum célja.

Az interneten fellelhető információk jelentősége sem elhanyagolható, és bár a ténylegesen szemantikus világháló még csak egy távoli álomkép, egyre több webszolgáltatás érhető el egységes, szabványos felületen keresztül, melyek leírására szolgál a WSDL nyelv.

Szintén modellezési feladatot látnak el az RDFS vagy OWL nyelvek. Az OWL DL kifejezőereje a leíró logikáéval azonos, az OWL Lite pedig ennek egy részhalmaza; az RDFS rendelkezik a legkisebb eszközkészlettel. Az OWL Full nyelv viszont annyira engedékeny, hogy néhol még értelmes szemantikát sem lehet hozzá társítani, így feldolgozása sem megoldott, tehát ezt eleve kizárom a megvalósítandó nyelvek köréből.

A SILK rendszerhez kapcsolódóan egy korábban lezajló, jelen projekthez hasonló kutatás keretében kifejlesztésre került a Kellene valami link, hogy jól mutasson ;) SILan nyelv, melynek célja az UML nyelvcsalád leíró logikai elemekkel és szemantikával történő kiegészítése volt. Így ez a projekt felfogható a SILan második generációjaként, célja vagy annak továbbvitele, vagy egy egészen új alapra helyezése. Fontos azonban, hogy az eddig implementált nyelvi elemek megmaradjanak.

2. Helyzetkép

Ez a fázis lényegében irodalmazási feladat. A forrásnyelvek specifikációját kell végigolvasni, a nyelvek elemei mellé feltüntetve a szemantikájukat, és megjelölni azokat az elemeket, melyeket a SILK rendszer használ. Itt érdemes - előremutatóan - megvizsgálni azt is, hogy egy-egy nyelvi elem igényel-e különleges figyelmet a későbbiekben összetettsége vagy nehéz implementálhatósága miatt.

2.1. Unified Modeling Language (UML)

Az UML egy leírónyelv, mely szoftverrendszerek elemeinek megjelenítésére, specifikálására, tervezésére és dokumentálására szolgál. Egy szabványos megoldást nyújt rendszerek terveinek rögzítésére, magában foglalva olyan fogalmi elemeket, mint az üzleti folyamatok és rendszerfunkciók, és egészen konkrét dolgokat is, mint például programozási nyelveken megfogalmazott parancsok, adatbázis-sémák, újrahasznosítható szoftverkomponensek.

Az UML a gyakorlati objektumorientált modellezés leginkább bevált praktikáinak gyűjteménye. Létrejötte annak az erőfeszítésnek köszönhető, hogy a világon leginkább használt módszereket egyesítse, az iparban alkalmazott legjobb ötleteket ötvözze, és mindenek felett egyszerű megoldást nyújtson.

Az UML specifikáció jelenleg érvényes 1.5-ös verziójáról mostanság történik az átállás a 2.0-ás változatra. Az új verziót négy külön dokumentumban írják le, melyek a specifikáció egy-egy nagyobb részterületét fedik le:

Az UML képességeinek elemzéséhez ezeket a dokumentumokat kell feldolgozni, a tapasztalatok a következő szakaszokban olvashatók.

2.1.1. UML 2.0 Infrastructure

Az UML Infrastructure dokumentum az UML 2.0 alapvető szerkezeteit tárgyalja. Ezt egészíti majd ki az UML Superstructure a felhasználói szintű nyelvi szerkezetekkel. Ez a két, egymást kiegészítő dokumentum alkotja a teljes UML 2.0 modellező nyelv specifikációját.

Az UML tervezésekor szerepet játszó legfontosabb elvek a következők voltak:

  • modularitás
  • réteges szerkezet
  • particionáltság
  • bővíthetőség
  • újrafelhasználhatóság

A modularitás elve az erős kohézióval rendelkező, gyengén kötött nyelvi csomagokba kialakításakor került előtérbe.

Réteges szerkezetet mutat egyrészt az UML metamodellt leíró nyelv és a magasabbrendű modellező szerkezetek elválasztása, illetve a nyelvi szerkezetek négy rétegbe szervezése.

A partícionálást a fogalmi elemeknek az egyes rétegeken belüli elkülönítésére használták, egyes modulok esetében kellőképpen finoman, de az UML metamodell esetében a minél nagyobb kohézió és a minél lazább csatolás végett viszonylag durvább közelítéssel.

Az UML-t kétféleképp bővíthetjük:

  • a Profiles modul segítségével új UML dialektust definiálhatunk különböző platformok vagy alkalmazási területek számára
  • az InfrastructureLibrary újrafelhasználásával és megfelelő metaosztályok és metakapcsolatok definiálásával egy új UML-hez kapcsolódó nyelv hozható létre

Az így történő bővíthetőség esetleg szerepet játszhat abban az esetben, ha a közös modellező nyelvként egy UML-en alapulú új nyelvet választunk majd.

A fejlesztők szem előtt tartották, hogy az UML elemei újra felhasználhatóak legyenek, segítve ezzel például a nyelv kiterjesztését.

Az InfrastructureLibrary csomagot két másik alkotja: a Core és a Profiles. A Core csomag a metamodellezés során használt alapvető fogalmakat definiálja, a Profiles pedig az ezek testreszabásához szükséges mechanizmusokat rögzíti.

Valójában a Core csomag egy teljes metamodell, melyet magasszintű újrafelhasználhatóságra terveztek: ez adja a közös alapot az UML-nek, a MOF-nak (Meta Object Facility) és a CWM-nek (Common Warehouse Metamodel); felfogható az MDA (Model Driven Architecture) magjának.

Négy újabb csomagra van bontva:

  • PrimitiveTypes
  • Abstractions
  • Basic
  • Constructs

Ezeknek a nagy része még tovább osztott, elősegítendő, hogy minél specializáltabban lehessen újra hasznosítani más metamodellek létrehozásakor.

Ezeket a részcsomagokat kellene számba venni és a lényeget leírni.

2.1.2. UML 2.0 Superstructure

Az UML Superstructure dokumentum teszi teljessé az UML 2.0 modellező nyelv specifikációját, felhasználói szintű nyelvi szerkezetekkel egészíti ki az UML Infrastructure dokumentumban leírtakat.

A modellezési fogalmakat úgynevezett nyelvi egységekként csoportosítva tárgyalja. Egy-egy nyelvi egység egy adott paradigma vagy formalizmus szerint szorosan kapcsolódó fogalmak gyűjteménye. Az UML felhasználója a nyelvi egységek közül szabadon választhat, az UML alkalmazásához nem kell a teljes nyelvet ismerni, elég a kíválasztott nyelvi egységek ismerete. Ennek következményeként akár az is elképzelhető, hogy a teljes UML specifikációnak egy szignifikáns hányadát, melyet a gyakorlatban kevéssé alkalmaznak, ki fogok hagyni a tárgyalásból.

A nyelv ilyen horizontális szegmentációja mellett létezik egy réteges szerkezet is: négy szintet különböztetünk meg, melyek a kifejezőerő szerint csoportosítják a nyelvi elemeket.

  • 0. szint: osztályalapú modellezési struktúrák
  • 1. szint: use-case-ek, interakciók (interactions), cselekvések (actions) és tevékenységek (activities)
  • 2. szint: elhelyezés (deployment), állapotgépes modellezés (state machine modeling), profilok (profiles)
  • 3. szint: információáramlás (information flow), sablonok (templates), csomagok (packages)

Ezek között kell relevancia szerint egy sorrendet felállítanunk, és eldöntenünk, hogy a létrehozandó nyelvben melyeket implementáljuk.

A tényleges modellalkotás szempontjából az osztályalapú modellezési struktúrák bírnak valódi jelentőséggel. Statikus modelleket írnak le osztályokkal, ezek tulajdonságaival, és köztük húzódó relációkkal. Az áttekinthetőség és a kezelhetőség miatt lehet szükségünk a csomagok koncepciójának használatára.

Nosza, vegyük sorra a kiválasztott csomagokat!
2.1.2.1. Osztályalapú modellezési struktúrák

2.1.3. UML 2.0 Diagram Interchange

A Diagram Interchange dokumentum az UML modellekből vizualizálható diagramok szabványos formátumát adja meg. Az XMI (XML Metadata Interchange) nyelv szabályai szerint előállíthatunk belőlük XMI[UML+DI] nyelvű dokumentumokat, melyekből például XSL segítségével SVG formátumú képeket készíthetünk.

A modellek megjelenítése is a SILK rendszer funkciói közé tartozik, így fontos, hogy a tárolt modellekből előállítható legyen valamiféle vizuális reprezentáció. Ennek egyik elképzelhető megoldása az, hogy köztes XMI információkat is tárol a rendszer a modell mellé, ezzel biztosítva bizonyos felhasználói megkötések lehetőségét. Ezesetben a modellező nyelvnek rendelkeznie kell az XMI-t leképezni képes kiterjesztéssel. A másik lehetőség, hogy a grafikus megjelenítést szigorúan egyirányú exportálásnak tekintjük, a modellekből - vagy XMI-n keresztüli, vagy anélküli - transzformációval előállítani a kívánt képi információt. Automatikus gráfrajzolásra képes például a GraphViz szoftver.

2.1.4. UML 2.0 Object Constraint Language

Az UML diagramok tipikusan nem elég finomak ahhoz, hogy egy specifikáció minden részletét ábrázolni tudják. Többek között szükséges, hogy a modell objektumaira további korlátokat alkalmazzunk. Ezeket megtehettük természetes nyelven, de ekkor gyakran értelmezési nehézségek és félreértések születtek. Az egyértelmű korlátok megfogalmazásának képességére több formális módszer is készült, ám ezek inkább csak a matematikai kifejezőeszközökben jártas felhasználók számára nyújtottak megfelelő alternatívát, ugyanis az átlagos, üzleti- vagy rendszerfolyamatokat modellező ember nehezen értette őket.

Ennek az űrnek a betöltésére született az OCL.

Az OCL segítségével invariánsokat fogalmazhatunk meg az UML leírásainkban, melyeknek a modellezett rendszer minden állapotában fenn kell állniuk, vagy egy lekérdezés igazsághalmazát kell adniuk.

Az OCL kifejezések jellemzője tehát, hogy igaz-hamis értéket vehetnek fel, és fontos megkötés velük szemben, hogy kiértékelésük során nem változtathatják meg a rendszer állapotát. Az OCL kifejezések kiértékelése azonnali, ami azt jelenti, hogy a rendszer állapota a végrehajtás során állandó, nem változhat meg.

Az invariánsok mellett az OCL részét képezik az elő- és utófeltételek, melyek segítségével műveletek feltételhez kötését, illetve hatásuk befolyásolását lehet elérni.

A nyelvnek elsősorban az invariánsok koncepcióját kell támogatnia, mint a modellben leírt világ elemeivel szemben támasztott megkötések leíróját, az elő- és utófeltételekre esetleg a WSDL azon tulajdonsága miatt lehet majd szükség, hogy operációk meghívásának módját definiálja.

2.2. Leíró logika (DL)

AL, C, N, E, U, S, H, O, I, N, D, F, Q kiterjesztések szemantikáját mindenképp le kell írni. Mi jöhet még pluszban? (Találtam valamit neten arról, hogy milyen további kiterjesztések léteznek, és ezeken milyen bonyolultságú a következtetés, csak jól elfelejtettem megjegyezni, hogy hol...)

2.3. Web Ontology Language (OWL)

Az OWL nyelv legbővebb még feldolgozható és ellentmondásokat nem megengedő halmaza az OWL DL, mely bizonyos leíró logikai konstrukciók alkalmazását teszi lehetővé XML szintaxissal.

A SHOIND nyelvkiterjesztések, melyekre az OWL építkezik, az előző szakaszokban kerültek tárgyalásra, így az OWL integrálhatósága is megoldott.

2.4. Web Service Description Language (WSDL)

A WSDL egy XML alapú nyelv, mely webszolgáltatások leírására szolgál. A szolgáltatások képességeit üzenetek küldésére és fogadására képes kommunikációs végpontok halmazaként definiálja.

A webszolgáltatások technológiájának segítségével válik elérhetővé rengeteg, a mély weben tárolt információ, melyhez az emberi beavatkozás nélküli hozzáférés szabványos megoldás hiányában eddig nem volt megoldott. Az RDF koncepció mellett egy másik lépés a szemantikus világháló irányába.

A WSDL többek között az UDDI (Universal Description, Discovery and Integration) szerves része, ami egy XML alapokon működő világméretű tárház az üzleti szolgáltatások számára. A WSDL az UDDI által is alkalmazott nyelv.

Tehát egy WSDL dokumentum a szolgáltatásokat hálózati végpontok, azaz portok gyűjteményeként definiálja. A WSDL-ben a végpontok és üzenetek absztrakt definíciója elválik a konkrét hálózati megvalósításuktól vagy a hozzájuk kötődő hordozó formátumuktól. Ez az absztrakt definíciók újra felhasználhatóságát teszi lehetővé: az üzenetek a forgalmazott adatok modellszerű leírásai, a port típusok pedig műveletek általánosított csoportjai. A konkrét protokoll- és adatformátum-leírások egy kiválasztott porttípus számára egy többször felhasználható kötést alkotnak. A portokat tehát hálózati címek és hordozó kötések határozzák meg, és portok halmaza definiál egy-egy szolgáltatást. Így a WSDL dokumentumok a következő elemeket alkalmazzák a webszolgáltatások leírására:

2.4.1. Típusok

Az XSD szerint lehet típusokat definiálni, tehát itt azt a specifikációt is include-olni kellene. A specifikáció előírja, hogy bármi egyéb módon is lehet típusokat megadni, de ilyen kijelentésekre nem igazán tudunk uniform megoldást adni.

2.5. SILan

Van egy jó kis doksi, azt kell majd feldolgozni.

3. Megvalósítás

Ide jön majd, hogy az előző szakaszokban felsorolt nyelvi elemek miképpen tükröződhetnek az új nyelv fényében.