Modelltranszformációk és -validációk

Miért készítenénk egy mindent leíró, gigaméretű és bonyolult metamodellt, ha egy alkalmazás kidolgozása kisebb lépésekkel, könnyebben kezelhető, egyszerűbb modellek sorozatos transzformálásával is megoldható?

A modelltranszformáció alapú alkalmazásfejlesztés lényege, hogy egy megbízás során nem különálló modellezés és fejlesztés történik, hanem a modell elkészítését transzformációk és a validációk sorozata követi, melyek segítségével a majdani alkalmazás alapjául szolgáló modell folyamatosan — akár több szereplő által is — alakítható és kiegészíthető, ha kell, egyre részletesebb adatokkal. Segítségével magasabb szinten lehet összefogni az egész folyamatot.

A módszer használatához először tisztázzuk az alapfogalmakat: a modell egy dolog olyan absztrakt egyszerűsítése, ami leír valamit, amivel foglalkozni szeretnénk, a metamodell az a leírás, ami a modellt definiálja, pl. egy repülőmodell esetében a metamodell írja le azt, hogy milyen alkotóelemeket milyen összeillesztésekkel használhatunk a modellkészítésnél — tulajdonképpen egy eszközpaletta. A metamodelleknek a következő részeket kell tartalmaznia:

• absztrakt szintaxis – megmondja, melyek a strukturális elemek és összefüggések egy modell definíciójánál -, a
• konkrét szintaxis – megmondja, hogy miként tudom ezt lerajzolni vagy leírni szövegesen -, és végül a
• szemantikus információk – az elemek magasabb szintű jelentését, használatának feltételeit írja le.

Egy állapotgép, ami a páros számokat fogadja el, elég jó példamodell lehet. Be lehet rajta mutatni a metamodell használatát, illetve azt, hogy miben tér el más definíciós lehetőségtől, mint például a nyelvtan.

A kétféle formális definíció közötti főbb különbségek:

• míg a metamodell lehetővé teszi gráfstruktúra leírását (irányított élek) is, nyelvtan esetén leginkább a fák a támogatottak (egy értelmező a feldolgozás alatti rész esetén a környezetet figyelembe tudja venni, de nem tud nagy távolságokat ugrani);
• míg a metamodell azt a struktúrát definiálja, amit a modell tartalmazni fog, a nyelvtan elsősorban a konkrét szintaxist definiálja;
• míg a metamodell ugyan megmondja, hogy hogy néz ki a struktúra, de azt, hogy ezt milyen formában kell majd leírni, ráér később eldöntenünk, a nyelvtannál a szöveges reprezentáció szabályait kell megfogalmazni;
• míg a metamodellek esetén a metamodell, illetve annak példánya, a modell, hasonló szabályokat követ (azaz a metamodellnek is van egy metamodellje, a metametamodell), ezért sok eszközbe hasonlóan betölthetők, nyelvtan esetén ez nincs meg: a nyelvtani szabályokat más struktúrában kell megadni, mint magának a nyelvtannak a mondatait.

A metamodellek alkalmazásának előnyei:

• megjelenít és feldolgozhatóvá tesz nagyméretű dokumentációkat (formális leírás), hasonlóan a nyelvtanokhoz;
• érvényes, jól formált szövegek (modellek) előállítását teszi lehetővé, hasonlóan a nyelvtanokhoz;
• deklaratívan, üzleti nyelven definiált szabályok ellenőrzése egy modell példányon, deklaratívan leírt transzformációs szabályok alapján történő átalakítások elvégzése;
• a modellből szöveges dokumentációt generál.

Validáljunk minél korábban!

‍

Az alkalmazásfejlesztés sikeréhez a metamodellek használata során is szükség van a validálásra. Ezek során azt nézzük meg, hogy megfelelően készült-e el a modell. Szintaktikai hibákat tartalmazó rajzok létrehozását általában az eszközök nem is teszik lehetővé. Ha a szemantikai szabályok nem teljesülnek, akkor sikeres lehet a mentés, de figyelmeztetések vagy hibaüzenetek tájékoztatják a modellezőket arról, hogy a további feldolgozás (beleértve más csapattagoknak való átadást is) még nem lehetséges. Így a felhasználó könnyebben megtalálja az okokat, és tudja javítani is azokat.

Nem árt azonban, ha észben tartjuk, hogy a szemantikai szabályok csoportosíthatók, és ha valamelyik egy másiknak az előfeltétele, akkor az alacsonyabb szintű szabály szükségtelenné teszi a rá épülő szabályok lefuttatását.

Erre nézzünk is egy Java példát! Ha hiba van egy Java forrásban, amit sok másik, akár több tucat komponens is használ, fölösleges az összes hibát kiírni, elég csak azt, ami az alapoknál van. A többi hibával úgysem tudunk mit kezdeni, ha az alaphiba nincs kijavítva. Hasonló megfontolásokból a később leírt transzformációk esetén is érdemes a validációt minél korábban lefuttatni, és a hibákat a lehető legkorábbi ponton javítani, mert egy későbbi helyen már nehezebben tudjuk kibogarászni, mihez is kell visszanyúlnunk.

‍

Több lépés, több beavatkozási lehetőség

‍

Ha már megfelelően validáltuk modelljeinket, jöhetnek a transzformációk. Ilyenkor a modelleket akár másik, akár azonos metamodell példányaivá alakítjuk, a metamodellek fogalmait felhasználva (transzformációs szabályok). Néha egy transzformációhoz több forráspéldány (bemeneti modell) is szükséges.

A transzformációk alkalmazása azért előnyös, mert nem szükséges egy, a fél vagy egész alkalmazást leíró, aprólékosan kidolgozott, de túl bonyolult metamodellt alkotni. Persze egy ilyennek is lehetnek előnyei — nagyon egyszerű, Hello World alkalmazások bemutatásakor —, csakhogy akkor egy kupacban lesznek az üzleti (magas szintű) és a technikai (alacsony szintű) fogalmak, és senki nem tudja majd igazán használni: az üzleti fogalmakkal foglalkozó embereknek túl részletes lesz, azoknak pedig, akik az alacsonyabb szintű részeket használják, túl terjedelmes, mivel ők egy időben csak egy-egy kis egységen dolgoznak.

A transzformációk azonban lehetővé teszik, hogy több eredeti modellből újabbat és újabbat transzformáljunk. Ily módon több lépésből jutunk el a célig — a futtatható alkalmazásig —, de minden lépés után lehetőségünk nyílik arra, hogy a megfelelő saját kiegészítéseket, forráskódokat, paraméterezést, konfigurációt mindenki beletegye a megfelelő helyre. Hatalmas előny, hogy így nem egy nagy közös helyen kell mindent megadni, ami mindenkinek túl bonyolult, hanem szét lehet bontani szerepek szerint.

Minden forrásmodellt (amelyeket önállóan hoztak létre, azaz nem egy transzformáció eredményeként keletkezett) külön-külön szükséges validálni, ezzel egyre alacsonyabb szintű technikai dolgokat lehet az alkalmazásba építeni.

‍

És hogy mindez miként működik például a JUDO rendszerben?

‍

A modellezők a megfelelő eszközzel rajzolnak egy modellt, ez lesz a JUDO PSM (platform specific model). A modellező eszköz elérhetővé és összekapcsolhatóvá teszi azokat az elemeket, melyeket a későbbi futtató környezet (platform) támogat. De mi van akkor, ha olyan elemre is szükség van, amit alapállapotban nem fogad a rendszer?

Ilyenkor kiegészítő forrásmodelleket alkalmazhatunk (például új relációs adatbázis esetén típusleképzések), vagy lehetőségünk van olyan annotációkat (kulcs-érték párokat) használni, melyek a transzformáció során végigmennek a rendszeren, a végén a fejlesztők elérik az abban leírt egyedi viselkedéseket, vagy használhatunk dinamikus működést, amikor előre nem definiált típusú adatokat visz fel a modellező, miközben rugalmasan alakítható marad a rendszer.

Abban az esetben, ha megváltoztatom a metamodellt, nagy körültekintéssel kell eljárnom. Ha az adott metamodellt több projekt is használja, akkor a módosítás ezek mindegyikére hatással van, viszont az életciklusok jelentősen különbözhetnek. Érdemes minden egyes rétegre nézve átgondolni, hogy a változtatásoknak milyen hatása lehet, és csak azután frissíteni az új verzióra, ha a szükséges kiegészítésen vagy javításon kívül (ami miatt a frissítésre szükség van) a többi változásra is felkészült a függő komponens.

Persze az is felmerülhet, hogy képes-e a több metamodell, validációk és transzformációk konzisztens egészet alkotni?

Abban az esetben igen, ha mindegyik egy-egy nem átfedésben lévő funkcionalitást fed le, világos szerepekkel és határokkal. Ilyen esetben a validációk és transzformációk unit tesztekkel alaposan lefedhetők. Validációk esetén ezek biztosítják, hogy a szabályok valóban az elvárt hibákat szűrjék ki és a metamodellek változása esetén az annak megfelelő modellekre továbbra is alkalmazhatók legyenek. Transzformációk esetén pedig azt biztosítják, hogy az előállított modellek érvényesek legyenek (azaz a célmodell szemantikai szabályai a létrehozó transzformációs szabályokba vannak kódolva).

A modelltranszformáció alapú alkalmazásfejlesztés egy hatékony munkamódszer olyan alkalmazások készítésére, melyek struktúrája (és bizonyos mértékben a viselkedése) modellekkel jól leírható. A Blackbelt I. Nyílt Meetupján azokat igyekeztem a témában képbe hozni, akik már modelleztek, például UML-lel: nekik fejlesztési módszertanként lehettek hasznosnak az elhangzottak, illetve olyan fejlesztőket, akik még nem használtak modellezést: nekik pedig azért, hogy lássák, hogyan kell magasabb szinten leírni az összefüggéseket.

‍