MODELLTRANSZFORMÁCIÓS SZABÁLYOK AUTOMATIKUS GENERÁLÁSA PÉLDÁK ALAPJÁN

Átírás

1 Diplomaterv MODELLTRANSZFORMÁCIÓS SZABÁLYOK AUTOMATIKUS GENERÁLÁSA PÉLDÁK ALAPJÁN Balogh Zoltán Konzulens Dr. Varró Dániel Egyetemi adjunktus Méréstechnika és Információs Rendszerek Tanszék Budapesti Műszaki és Gazdaságtudományi Egyetem Budapest, május

2

3 Ezúton szeretnék köszönetet mondani mindazoknak, akik valamilyen formában támogatták a jelen diplomaterv elkészítését. Elsősorban témavezetőmnek, Dr. Varró Dánielnek, aki a témaválasztással kezdve folyamatosan ösztönözte és támogatta munkámat. Továbbá Huszerl Gábornak a komplex esettanulmány kapcsán tett tanácsokért, észrevételekért, illetve mindazon doktorandusz hallgatóknak, akik hasznos kommentekkel, ötletekkel segítették a kutatást.

4 Nyilatkozat Alulírott Balogh Zoltán, a Budapesti Műszaki és Gazdaságtudományi Egyetem műszaki informatika szakos hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomatervben csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben de átfogalmazva más forrásból átvettem, egyértelműen a forrás megadásával megjelöltem.... Balogh Zoltán

5 Összefoglaló Napjainkban a modelltranszformáció egyre nagyon szerephez jut az informatika számos területén. A szoftvertervezésben egy nagyon jó példa erre az MDA (Model-driven architecture, Modell vezérelt architektúra), ugyanis ezen a területen kiemelten fontos lépés a különböző absztrakciós szinteken lévő modellek automatikus egymásba átalakítása. A modelltranszformáció terjedésével a szabályok megadásának módja egyre nagyobb szerephez jut és egyben nagy kihívást jelent hatékony megvalósítása. Egy modelltranszformáció specifikációjához meg kell adnunk a forrás- és célnyelv leírását, a kiinduló forrásmodellt és a transzformációs szabályokat. A tervezőnek tehát jól kell ismernie az adott környezet transzformációkat leíró nyelvét, ami azért problematikus, mert a transzformáció tervezője legtöbbször csak a forrás és a célnyelvet ismeri, a transzformációs technológiában való jártassága azonban csekély. E probléma megoldására kidolgozásra került egy olyan újszerű megközelítés, amely a transzformációs szabályokat automatikus (vagy fél-automatikus) módon állítja elő, amihez elegendő néhány összekötött forrás- és az annak megfelelő célmodellt megadni, melyek lefedik a transzformáció kritikus eseteit. A megközelítés a Model Transformation by Example (MTBE) elnevezést kapta, ami onnan ered, hogy a transzformációs szabályokat a példaként megadott összekötött modellpárokból gyártjuk le. A transzformáció tervezőjének általában rendelkezésére állnak összetartozó forrás- és célmodellek, így az MTBE használatával az egyetlen feladata, hogy kézzel megalkossa a modellek közti összekötést. Ebből következően a transzformáció megadását nagy mértékben meg lehetne az által gyorsítani, ha megfelelő támogatást biztosítanánk az összekötés megalkotására. A diplomatervben az induktív logikai programozás (Inductive Logic Programming, ILP) paradigmájára és eszközkészletére építve automatikus módszert adok az MTBE megközelítésre. Az ILP az elsőrendű logikai programozást és az induktív gépi tanulást felhasználva képes hatékonyan hipotéziseket kikövetkeztetni, amelyek lefedik az ILP bemenetére adott példákat, megadott háttértudást feltételezve. Ezen felül kiterjesztem a módszert azáltal, hogy bemenetnek elegendő csupán összetartozó forrás- és célmodelleket megadni, amelyekből ezek után a modellben tárolt értékek mintaillesztéses alapon történő terjesztésével létrejön egy javaslat a modellek közti összekötésre. A diplomatervben esettanulmány segítségével igazolom a módszerem gyakorlati alkalmazhatóságát, megállapítom a koncepcionális, ill. gyakorlati korlátokat.

6 Abstract In the field of software engineering, model transformation has become increasingly important. MDA (Model-driven architecture) is a really good example for it, because it depends on the transformation of various models on different abstraction levels. Thus the efficient design of automated model transformation languages has become a major challenge to model-driven engineering by now. For the specification of a model transformation, source and target languages describing the models need to be given, as well as the source model and the transformation rules. As a consequence, the transformation designer not only needs to understand the transformation problem, i.e. how to map source models to target models, but also significant knowledge is required in the transformation language itself to formalize the solution. To bridge this conceptual gap, a novel approach is proposed: Model Transformation by Example (MTBE). The essence of the approach is to derive model transformation rules fully or semi-automatically from an initial prototypical set of interrelated source and target models, which describe critical cases of the transformation. The transformation designer usually holds some coherent source and target models, so only the interrelation between these models need to be specified manually by the MTBE approach. Thus, the transformation generation process becomes more efficient by giving support for the designer for the creation of interrelation semi-automatically. In this thesis, I introduce an automated process for MTBE using Inductive Logic Programming (ILP). ILP can be defined as an intersection of inductive learning and logic programming. It aims at the inductive construction of first-order clausal theories from examples and background knowledge, thus using induction instead of deduction as the basic mode of inference. Next, I extend the main approach with another semi-automatic process. By this technique, a proposal for matched elements is automatically derived, based on similarities in the source and target models. My approach makes use of the correlation of certain attributes (e.g. the name of model elements) and propagates them using pattern matching, thus deducing an initial interrelation between the source and the target models. Finally, I describe a case study proving the practical usage of the approach and discuss conceptual and practical limitations.

7 Tartalomjegyzék 1. Bevezetés Modellvezérelt rendszertervezés Modelltranszformáció Modelltranszformáció példák alapján Célkitűzés A dolgozat felépítése Modelltranszformáció Motivációs példa: Objektum-relációs leképezés Objektum-relációs leképezések a gyakorlatban MOF metamodellezés A MOF metamodellezés áttekintése Az objektum-relációs leképezés metamodelljei A referencia metamodell Gráftranszformációs szabályok Gráftranszformációs szabályok a modelltranszformációban VIATRA Metamodellező nyelv a VIATRA2 rendszerben Transzformációs nyelv Összegzés Hasonlóság keresési technikák Hasonlóság elárasztása algoritmus Gráfok előállítása és a kezdeti összekötés generálása Hasonlóságok elárasztása Végső összekötés Karakterlánc-hasonlósági metrikák A szerkesztésen alapuló modell, Levenshtein távolság Lokális hasonlóság, Smith-WaterMan algoritmus Összegzés Induktív Logikai Programozás Példa Elméleti háttér Abdukció Hipotézisek igazolása ILP algoritmusának az alapelve Aleph Aleph használata A példák és a háttértudás megadása az Aleph-ben Algoritmus

8 Elméletek létrehozása Rekurzív szabályok megtanítása Kényszerek megtanítása az Aleph-ben Redundáns kényszerek kiszűrése Összegzés MTBE automatizálása Automatizálás lépései Feltételezések Példa modellpárok összekötése Kontextus analízis Referencia elemek kontextus analízise Célelemek kontextus analízise Célelemeket összekötő relációk analízise Gráftranszformációs szabályok generálása Elemeket létrehozó szabályok Célrelációkat létrehozó szabályok Segédinformációk További példák hozzáadása (szabályok finomítása) MTBE megközelítéshez kapcsolódó munkák Összegzés Modellek közti összekötés generálása Célkitűzés Áttekintés A módszer főbb lépései A módszer által használt adatstruktúrák Összekötések létrehozása Kezdeti párosítások létrehozása Párosítások terjesztése Összekötések létrehozása Az összekötések metamodelljének létrehozása A metamodell létrehozása Az összekötéseknek a metamodellhez való igazítása Felhasználói módosítások Visszajelzések Felhasználói beavatkozás Példa Kapcsolódó munkák Összegzés Modelltranszformáció példák alapján az Induktív Logikai Programozás használatával Automatizálás lépései Összekötött modellekből Prolog klózok Alternatív megadása a referencia modellnek Referencia elemek kontextusa Negatív kényszerek a kontextusban Célelemek kontextusa Célrelációk kontextusának analízise Segédinformációk generálása Aleph specifikus részletek Determináció deklarációk

9 Mód deklarációk A keresési tér méretét befolyásoló paraméterek Koncepcionális korlátok Nem-determinisztikus transzformáció Számolás a transzformációban Változó multiplicitású összekötés Negatív kényszerek és pozitív feltételek külön generálása Összegzés Implementáció a VIATRA2 keretrendszerben Áttekintés Általános szabálygeneráló modul Problémamodell ILP problémamodell létrehozása Prolog szabályok importálása a modelltérbe Gráftranszformációs szabályok modelljének létrehozása Összegzés Esettanulmány Összekötés létrehozása Példamodellek Szabályok generálása Beadott példamodellek Segédinformáció megtanítása Aleph fájlok létrehozása Aleph futtatása Gráftranszformációs szabályok Összegzés Mérési eredmények Gyakorlati korlátok A futási időre kiható tényezők Futási idő mérése Gyorsítási lehetőségek Összegzés Eredmények értékelése A dolgozat főbb eredményei Koncepcionális eredmények Implementációs eredmények Továbbfejlesztési irányok A. Aleph példa 103 B. Esettanulmány gráftranszformációs szabályai 104 C. Esettanulmány Aleph eredményei 107 8

10 9

11 1. fejezet Bevezetés 1.1. Modellvezérelt rendszertervezés Napjainkban a szoftvertervezésben a modellezés egyre nagyobb szerephez jut. A modell alapú rendszertervezés de facto szabványa a Modellvezérelt Architektúra [16] (MDA = Model-driven architecture), mely az OMG [3](Object Management Group) által javasolt és támogatott szoftverfejlesztési megközelítés. Az MDA alapgondolata, hogy a rendszerfejlesztést egy precíz modellezési fázis vezeti be, melynek során egy platformfüggetlen modellt (PIM = platform-independent model) készítünk el. Egy PIM modell előnye, hogy kizárólag a rendszer (üzleti) funkcionalitását tartalmazza, azaz mentes a célplatform specifikus részleteitől. A következő fázisban a platformfüggő modellek (PSM = platform-specific model) megalkotása történik, amely már magában hordozza a kiválasztott szoftver platformra specifikus adatokat is. A PIM-ből a PSM-ek származtatása lehetőség szerint automatikusan vagy fél-automatikusan megy végbe. A célalkalmazás forráskódját ezután a PSM modellből automatikus kódgenerálás segítségével származtathatjuk. Ezáltal az MDA támogatja a magas szintű modellezést, kódgenerálást, könnyű tesztelhetőséget és nem utolsó sorban platformok közti átjárhatóságot biztosít növelve így a fejlesztés hatékonyságát. Számos OMG szabvány áll az MDA megközelítés mögött, melyek közül a fontosabbak: The Unified Modeling Language (UML) [24]: AZ UML egy egységes modellezési nyelvet biztosít a modell alapú fejlesztéshez, támogatva a kezdeti specifikációt, a vizualizációt, a fejlesztést és a dokumentáltságot. Meta Object Facility (MOF) [21]: A MOF Metamodellek (, azaz modellezési nyelvek specifikálásának) definiálására szolgáló absztrakt nyelv és keretrendszer. XML Metadata Interchange (XMI) [23]: Az XMI integrálja az W3C-nek az XML szabványát, valamint az OMG MOF szabványát azzal a céllal, hogy lehetővé tegye a metaadatok és az általuk leírt példányok együttes kezelését. Common Warehouse Metamodel (CWM) [22]: A CWM szabványosítja azokat a metamodelleket, amik a különböző adatbázisok együttműködését és az adatbázisok közti átjárhatóságot biztosítják Modelltranszformáció Az MDA egyik kritikus pontja az egyes modellek közötti modelltranszformációk tervezése és automatikus végrehajtása. Az MDA számos gyakorlati fázisában felmerül a modelltranszformációk alkalmazásának lehetősége, például a PIM-ből PSM-be, vagy PSM-ből implementálható kódba transzformálás, illetve modellek analizálásához szükség lehet olyan modellekbe transzformálni, melyek támogatják a precíz matematikai vizsgálatokat. Ezen kívül a modelltranszformációk további fontos alkalmazási területeiként 10

12 megemlíthetőek a különböző refactoring lépések, vagy akár a különböző adatstruktúrák közötti konverziók. A modelltranszformáció egységes kezelése érdekében az OMG kiadta a QVT [20] (Queries/ Views/ Transformations) szabványt mely egy relációkon alapuló, deklaratív transzformációs nyelvet biztosít. A QVT szabványhoz azonban még csak most jelentek meg a kezdetleges implementációk. Egy modelltranszformáció hagyományos tervezési folyamatában tipikusan meg kell adnunk a forrásés célnyelv leírását, a kiinduló forrásmodellt és a transzformációs szabályokat. A tervezőnek ehhez az általa jellegzetesen ismert forrás- és célnyelven kívül a modelltranszformációkat leíró nyelvet is ismernie kell. Míg egy létező transzformációs leírás legtöbbször jól érthető (olvasható) a tervező számára, egy modelltranszformáció elkészítése (megírása) ugyanakkor nagyfokú jártasságot követel az adott transzformációs technológiában Modelltranszformáció példák alapján A modelltranszformációk hagyományos megadásában rejlő probléma áthidalására az [28]-ben kidolgozásra került egy olyan megközelítés, amely a transzformációs szabályokat automatikus (vagy félautomatikus) módon állítja elő. Mindehhez elegendő néhány forrás- és az annak megfelelő célmodellt megadni, melyek lefedik a transzformáció kritikus eseteit. A megközelítés az MTBE (Model Transformation by Example) elnevezést kapta, ami onnan ered, hogy a transzformációs szabályokat a példaként megadott modellpárokból származtatjuk. Az MTBE megközelítés az 1.1. ábrán összefoglalt lépéseket javasolja a modelltranszformációs szabályok megalkotásához: 1.1. ábra. MTBE lépései 1. Kezdeti példák manuális létrehozása: A transzformáció tervezője létrehozza a kezdeti összetartozó példa- és forrásmodelleket, illetve megadja az azok közti összekötéseket. 2. A szabályok automatikus származtatása: A megadott példák alapján az adott eszköznek le kell gyártania a transzformációs szabályokat, mely szabályokkal legalább a példamodelleket mindenképpen helyesen kell tudjuk transzformálni. 3. Szabályok manuális finomítása: A transzformáció tervezője bármikor képes a szabályok finomítására, ha az automatikusan generált szabályok nem megfelelőek számára. 11

13 4. A kapott szabályok automatikus futtatása: Lehetőség nyílik a kapott szabályok kipróbálására bármilyen további forrás- és célmodell párokon, ezáltal egyfajta validációt végrehajtva a szabályokon. E modellek természetesen ugyanúgy felhasználhatók a későbbiekben a szabályok tanításának finomhangolására. Az MTBE megközelítést először bemutató [28] cikk alapvetően magának a megközelítésnek az alapjait írja le, a javasolt algoritmikus lépések azonban nagyrészt heurisztikusak és csak részlegesen automatizálhatók. E dolgozat előzményeként elmondható tehát, hogy nemzetközi viszonylatban sem létezik olyan szisztematikus megvalósítása az MTBE módszernek, amely automatikusan lenne képes származtatni a modelltranszformációs szabályokat a forrás- és célmodellekből kiindulva. Továbbá a [28] cikkben közölt megközelítés a forrás és célmodellek közti összekötések megadását teljes mértékben a felhasználóra bízza, így ahhoz, hogy valaki használni tudja az MTBE-t, az összetartozó forrás- és célmodelleken kívül kézzel le kell gyártania az azok közötti összekötést is. Az összekötések kézzel történő megadása nagyobb modellek esetében igen körülményes és időigényes folyamat lehet, így nagyban növelné az MTBE hatékonyságát, ha az összekötések létrehozására bizonyos szintű támogatást adnánk a tervezőnek Célkitűzés A dolgozatban a modelltranszformációs szabályok példák alapján történő származtatását tárgyalom. Első lépésként a példát jelentő összetartozó modellekből fél-automatikusan létrehozom az azok közti összekötéseket, majd ezek alapján automatikusan generálom a transzformációs szabályokat ábra. Célkitűzés: MTBE teljeskörű automatizálása A következő saját eredményeket mutatom be, amelyeket az 1.2. ábrán foglaltam össze: 1. Modellek közti összekötés fél-automatikus előállítása: Fél-automatikus módszert adok a modellek közti összekötések generálására. 12

14 (a) Összekötés automatikus generálása: Megadok egy módszert, amely névhasonlósági érétkek mintaillesztésen alapuló terjesztésével automatikusan generál egy javaslatot a végső összekötésre az összetartozó forrás- és célmodellekből kiindulva. (b) Generált összekötések megtámogatott kézi finomítása: Az automatikusan keletkezett összekötéseknek különböző aspektusaival magas szintű támogatást biztosítok a finomítási fázishoz. 2. Szabálygenerálás automatizálása: Automatikus módszert adok az MTBE szabálygenerálási fázisára az induktív logikai programozás (ILP) paradigmájára és eszköztámogatására építve. (a) ILP bemenet generálása: Első lépésként a megadott forrás- és célmodellekből szisztematikus és automatikus úton előállítom az ILP számára szükséges információt, ami az induktív tanuláshoz szükséges. (b) Következtetési szabályok induktív származtatása: Az ILP rendszer automatizmusát kihasználva meghatározom a forrás- és célnyelvi kontextusokat Prolog-szemantikára épülő következtetési szabályok formájában. (c) Modelltranszformációs szabályok generálása: A Prolog-szemantikára épülő következtetési szabályokból modelltranszformációs szabályokat származtatok. 3. Gyakorlati célként megvalósítom a módszer egy prototipikus implementációját a VIATRA2 rendszerbe integrálva, továbbá kiértékelt mérési eredményekkel és esettanulmányok segítségével támasztom alá a módszer gyakorlati használhatóságát. Az összekötések automatikus előállításához az alapötletet a hasonlóság elárasztása (Similarity Flooding = SF) algoritmus[15] adta, mely hasonló modellek között képes az összekötés előállítására a névegyezésen alapuló hasonlóságok terjesztésével. Viszont az algoritmus csak igen speciális terjesztési feltételeket képes kezelni, aminek következményeképpen számos általános esetben nem használható. A dolgozatban ezzel szemben olyan módszert adok az összekötések előállítására, amely a terjesztést mintaillesztéses alapon valósítja meg, lehetőséget teremtve ezáltal szinte bármilyen komplexitású terjesztési feltétel megadására. A szabályok automatikus generálásához felhasznált Induktív Logikai Programozás [18] (ILP = Inductive Logic Programming) a mesterséges intelligencia egy ágazata, mely két lényeges irányzat, az induktív gépi tanulás és az elsőrendű logikai programozás egyesítéséből született. Ennek köszönhetően képes a bemenetére adott háttértudás és példák alapján Prolog következtetési szabályok formájában hipotéziseket megalkotni, mely hipotézisekkel a háttértudást feltételezve előállíthatjuk a pozitív példákat A dolgozat felépítése A dolgozat két nagyobb egységre különíthető el: az első egységben részletesen bemutatásra kerülnek a fontosabb fogalmak és a felhasznált technikák, a második egységben pedig az elért eredmények. Az első egység három fejezetből tevődik össze: A 2. fejezetben a modelltranszformációhoz kapcsolódó fontosabb fogalmak, illetve eszközök lesznek bemutatva példákkal szemléltetve. Szó lesz a transzformáció alapját képező metamodellekről és gráftranszformációs szabályokról, illetve röviden bemutatásra kerül a javasolt eljárás teljes automatizálásához használt VIATRA2 modelltranszformációs keretrendszer. A 3. fejezetben bemutatjuk a Similarity Flooding algoritmus alapelvét, továbbá ismertetünk két név-hasonlósági metrikát. Az első egység utolsó fejezeteként, a 4. fejezetben részletesen szó lesz az induktív logikai programozás-hoz kapcsolódó fogalmakról, illetve bemutatásra kerül egy népszerű ILP implementáció. A második egység öt fejezetből tevődik össze: Az 5. fejezetben bemutatjuk az MTBE főbb lépéseit azon kiterjesztésekkel, amik a célkitűzésben megfogalmazottakhoz szükségesek. Ezek után, a 6. fejezetben bemutatjuk az összekötések megalkotásához javasolt módszert. A 7. fejezetben bemutatjuk az 5. fejezetben leírt lépések ILP-vel történő végrehajtását, illetve részletesen elemezzük az ILP-vel megvalósított módszer koncepcionális korlátait. A 8. fejezetben bemutatjuk a módszer implementációját 13

15 érintő főbb részleteket, mely elsősorban a VIATRA2 keretrendszer használatával történt. A 9. fejezetben egy konkrét esettanulmány segítségével igazoljuk a módszer gyakorlati használhatóságát, a 10. fejezetben pedig kiértékelt mérésekkel vizsgáljuk meg a módszer skálázhatóságát, gyakorlati értelemben vett korlátait. 14

16 2. fejezet Modelltranszformáció Ebben a fejezteben bemutatjuk a modelltranszformáció legfontosabb alapfogalmait. A 2.1. alfejezetben a modelltranszformációs megközelítések összevetésére gyakorta használt példát fogunk bemutatni, amit a 2.2. alfejezetben bemutatásra kerülő MOF használatával tovább részletezünk. A 2.3. alfejezetben a modelltranszformáció fontos részét képező gráftranszformációs szabályokról lesz szó, amely egy népszerű megközelítés a szabályok matematikailag is szabatos megfogalmazására. A 2.4. alfejezetben bemutatásra kerül egy népszerű modelltranszformációs eszköz, a MIT tanszék által kifejlesztett VIATRA2, mely a modellek manipulálásához gráftranszformációs szabályokat használ Motivációs példa: Objektum-relációs leképezés A példában az Objektum-Relációs leképezésnek (O/R Mapping) egy változatát fogjuk bemutatni. Az O/R leképezést sűrűn használják a gyakorlatban (például adatbázis tervezés UML alapon) és emellett nagyon jó esettanulmányként szolgál modelltranszformációs eszközök tesztelésére, kipróbálására. A forrásmodell ilyenkor egy UML osztálydiagram, a célmodell pedig ennek a relációs adatmodellje. A konkrét példánk forrásmodellje a 2.1(a). ábrán, a célmodellje pedig a 2.1(b). ábrán látható. (A példát a [28] cikkből vettem át.) Mind a forrás-, mind pedig a célmodellnél az UML, illetve a relációs modelleknél megszokott grafikus ábrázolási módot használtuk. A példából megfigyelhető, hogy minden osztálynak, aminek nincsen őse, illetve az asszociációknak egy-egy tábla felel meg a relációs modellben. A különböző gyerek osztályokat az annak megfelelő ősosztály táblájának kind oszlopa segítségével tudjuk nyilvántartani. Ha egy osztálynak van attribútuma, akkor annak egy, az adott táblában felvett oszlop felel meg. Ez továbbá a tábla egy idegen kulcsa lesz, ami az attribútum típusának megfelelő osztályból (illetve annak ősosztályából) képzett táblára fog mutatni. Egy asszociációhoz tartozó táblában két oszlopot fogunk felvenni, melyek a táblának egyben az elsődleges és idegen kulcsai is lesznek a megfelelő forrás- és céltáblára mutatva. Az objektum-relációs leképezés modelltranszformációjának informális szabályai a következők: Minden, az öröklésben legmagasabban álló UML osztályból egy tábla képződik és automatikusan két oszlop is belekerül. Az egyik lesz a tábla elsődleges kulcsa, a másik pedig az osztály fajtáját fogja megadni (ha az leszármazott osztály). Egy UML osztályhoz tartozó attribútum egy oszlopba képződik, mely oszlop ahhoz a táblához fog tartozni, mely tábla az UML osztályból (vagy az osztály legfelsőbb őséből) képződött. Az egyszerűség kedvéért a dolgozatban egy attribútum típusa csak felhasználó által már definiált osztályokra korlátozódik. Az attribútum oszlopához egy idegen kulcs tartozik, mely a típusnak megfelelő tábla elsődleges kulcsára mutat. Minden UML asszociációnak egy tábla felel meg, melyben felveszünk az asszociáció forrására és céljára mutató idegen kulcsot, melyekhez egy-egy elsődleges kulcs is tartozik majd a táblában. 15

17 (a) UML modell (b) Relációs modell 2.1. ábra. O/R példa A fenti leírás természetesen csak egy informális váza az objektum relációs leképezésnek, a transzformáció automatizálásához formális leírásra is szükségünk lesz. Erre nyújt megfelelő megoldást a metamodellezés és a gráftranszformáció paradigmája, melyekkel a következő fejezetekben fogunk foglalkozni Objektum-relációs leképezések a gyakorlatban A bemutatott objektum-relációs leképezésen kívül természetesen egyéb megközelítések is léteznek, melyekből a teljesség igénye nélkül pár szóban bemutatunk kettőt. Ezek mellesleg részét képezik az Enterprise Java Beans (EJB) 3.0-ás szabványának [27]. Egy tábla a hierarchiákra. Lényegében ez felel meg a példánknak. Ilyenkor nem hozunk létre minden osztályhoz egy külön táblát, hanem csak az öröklési hierarchiában legfelül állóknak. A gyerek osztályok tárolására pedig létre hozunk egy külön oszlopot. Ennek a megközelítésnek az előnye, hogy egyszerű, hátránya pedig, hogy ha nagy a hierarchia, akkor fölöslegesen foglalunk le tároló kapacitást. Minden osztálynak külön tábla. Ebben az esetben minden osztályhoz létrehozunk egy külön táblát. Azt, hogy egy osztálynak van szülő osztálya, egy idegen kulcs felvételével tároljuk, ami a szülő osztály elsődleges kulcsára fog mutatni. Előnye, hogy könnyen megérthető az egy-egy leképezés miatt és nem foglalunk le fölöslegesen tároló kapacitást. Hátránya, hogy sok tábla lesz az adatbázisban és nehézkes lehet néha adatokat kiolvasni, illetve írni, ha több táblán keresztül kell ezt megtennünk. 16

18 2.2. MOF metamodellezés Az interneten számos problémát eredményezett, hogy a különböző eszközök saját modelleket használtak a metaadatok leírására és így nagy mértékben meggátolták az adatok cseréjét az eszközök között. Ennek a problémának a kiküszöbölésére született meg az OMG által javasolt metamodellek kezelésére és leírására szolgáló absztrakt nyelv és keretrendszer, a MOF. Metamodell. A metamodell egy olyan modell, mely egy másik modell általános tulajdonságait írja le. A MOF metamodell a modellező nyelvek statikus struktúrájának grafikus (egyszerűsített UML osztálydiagram) specifikációja A MOF metamodellezés áttekintése A MOF egy négyrétegű architektúrát ad a különböző modellszintek információinak az integritására: Meta-metamodell réteg: Egy absztrakt leírást ad a metamodellek elemeiről. Például a MOF, vagy a VPM metamodell [29]. Metamodell réteg: Információkat tartalmaz a különböző modellnézetek komponenseiről, ezek struktúrájáról és szemantikájáról. Például az UML, vagy a relációs metamodell. Modell réteg: Információkat tartalmaz a valós folyamatokról, adatokról. Például a 2.1(a). ábrán és a 2.1(b). ábrán látható példák. Információs réteg: A vizsgált valós rendszer sajátosságait írja le. megfelelő konkrét adatbázisban tárolt elemek. Például a 2.1(b). ábrának A megközelítés fő gondolata, hogy a metamodellek egyazon meta-metamodellből példányosíthatóak, így azokat egységesen tudjuk kezelni. A metamodellek alapkövei az osztályok, amelyek a modellezési nyelv alapfogalmait adják. Az egyes osztályok tartalmát attribútumok által fejthetjük ki bővebben. Az osztályok közötti relációkat asszociációk (referenciák) formájában adhatjuk meg. Lehetőségünk van továbbá tartalmazási (aggregációs) és öröklési (generalizációs) viszonyt definiálni két modellelem között Az objektum-relációs leképezés metamodelljei Visszatérve a kezdeti O/R példánkhoz, megadjuk az UML, illetve a relációs modell metamodelljeit. A 2.2(a). ábrán az általunk használt UML 1, a 2.2(b). ábrán pedig az általunk használt Relációs metamodell látható. Az UML metamodell három entitásból áll: Class (Osztály), Association (Asszociáció), Attribute (Attribútum). Egy Osztály egy, vagy több Attribútumot tartalmazhat az attrs reláció révén, mely Attribútum type relációban áll egy Osztály entitással (ez a szokványos ábrázolás esetében egy sor felvételét jelentette az attribútum számára az osztályban, a kettőspont után megadva az attribútum típusát). Egy Osztály egy másik Osztállyal állhat szülő (parent) kapcsolatba (a szokványos ábrázolásnál ez egy üres háromszögben végződő nyílnak felel meg a gyerek osztálytól a ősosztály felé). Az Asszociáció src relációban áll a forrás entitással és dst relációban a cél entitással (az UML ábrázolása erre egy nyilat használ a forrás osztálytól a cél osztályba mutatva). A relációs metamodell, hasonlóan az UML-hez, több egyszerű entitásból tevődik össze és így nem kapunk olyan kompakt ábrákat, mint a szokásos táblás ábrázolásmódnál, ahol inkább kevesebb, de összetettebb entitások szerepeltek. A metamodell entitásai: Table (Tábla), Fkey (Idegen kulcs), Column (Oszlop). Egy Tábla az fkeys reláció révén Idegen kulcsokat, a tcols reláció révén pedig Oszlopokat tartalmaz, továbbá egy (vagy több) Oszloppal pkey relációban van (ez határozza meg az elsődleges kulcsot). 1 Az itt közölt UML modell egy egyszerűsítése a szabványnak az MTiP workshop példája alapján [1] 17

19 (a) UML metamodell (b) Relációs metamodell 2.2. ábra. metamodellek Egy Idegen kulcs kcols, illetve cref relációban áll egy oszloppal, melyek rendre megadják, hogy az idegen kulcs melyik saját táblabeli, illetve melyik (általában) idegen táblabeli oszlopra vonatkozik. A teljesség kedvéért megadjuk a fenti metamodellekből példányosított modelleket is, ahogyan majd a transzformációs eszközökben is megjelenítésre kerülnek. A 2.1(a). ábra UML modellje a 2.3(a). ábrán, a 2.1(b). ábra relációs modellje pedig a 2.3(b). ábrán látható. Vegyük észre, hogy a MOF metamodell használatával elveszett az adott modellekre jellemző tömör, áttekinthető ábrázolás, ugyanakkor a metamodellek egyszerűségének köszönhetően a modelljeinket hasonlóan definiálhattuk, aminek köszönhetően egységesen kezelhetőek és ábrázolhatók bármilyen transzformációs eszközben A referencia metamodell A forrás- és célmodellek összekapcsolásához szükség van egy referencia modellre, illetve az annak megfelelő referencia metamodellre is. A referencia modell felvétele azért szükséges, hogy nyomon lehessen követni, melyik forrásobjektumnak melyik célobjektum felel meg és ezáltal lehetővé válik a két modell konzisztensen tartása. Pédaként tekintsük az általunk használt O/R transzformáció metamodelljét, mely a 2.4. ábrán 2 látható. Nézzük meg például, hogy a Ref_Cls elem mit árul el a transzformációról: Ha egy Class elem példánya kapcsolatban áll egy Ref_Cls elem példánnyal, akkor a következő elemek fognak a Relációs modellben létrejönni: Egy Table elem példánya, mely cls2tab relációban áll Ref_Cls elem példányával és két Column elem példánya, melyek cls2colid és cls2colkind relációban állnak a Ref_Cls elem példányával. (Az első oszlop szolgál az elsődleges kulcs tárolására, a második pedig a gyerek osztályokról tárol információt.) A referencia metamodellben szükséges, hogy a referencia elemekből kimenő relációk multiplicitása pontosan egy legyen. Ezáltal a referencia modell elemei egyértelműen kijelölik a hozzá tartozó forrás-, ill. célelemeket. Vegyük észre, hogy a referencia metamodell önmagában nem elég a transzformáció megadásához, ugyanis nem ad semmilyen információt például arról, hogy a keletkezett célmodellbeli elemeket hogyan kell majd összekötni. A referencia metamodellen kívül szükséges még további szabályok formális megadása is Gráftranszformációs szabályok A gráftranszformációs szabályok egyszerű és precíz eszközként szolgálnak szabály és mintabázisú modellmanipuláció megvalósításához, éppen ezért egy nagyon népszerű eszköz modelltranszformációk leí- 2 Az áttekinthetőség érdekében ha két entitás között egynél több él ment, azokat nem rajzoltuk be kétszer. Például a Ref_asc entitásból az Fkey entitásba két él megy, de ez az ábrán csak a rajta levő két névből derül ki. 18

20 (a) UML modell (b) Relációs modell 2.3. ábra. O/R példa rására (lásd: GReAT [12], FUJABA [19], VMTS [14], VIATRA2). A következő részben bemutatjuk a szabály felépítését, utána pedig ismertetjük egy szabály végrehajtását. Szabály felépítése Egy r : LHS RHS gráftranszformációs szabály egy LHS és egy RHS gráfból áll, ahol LHS RHS jól definiált. A bal oldal (LHS) jelenti a szabály élőfeltételeit, a jobb oldal (RHS) pedig a szabály utófeltételeit. LHS RHS határozza meg a modellgráfnak azt a részét, aminek létezése szükséges a szabály végrehajtásához, de a szabály elvégzése után változatlan marad. LHS \ (LHS RHS) határozza meg azt a részt, amit majd törölni kell és RHS \ (LHS RHS) pedig azt, amit majd létre kell hozni. Egy szabály alkalmazhatóságát további feltételekhez lehet kötni. Ilyen például a negatív alkalmazási feltétel, mely az előfeltételek részeként megtiltja az illeszkedést bizonyos gráf részekre. A negatív alkalmazhatósági feltétel szintén egy gráf (NAC) és LHS NAC szintén jól definiált. NAC sikeres illesztése esetén a szabály nem alkalmazható. Szabály alkalmazása Egy gráftranszformációs szabály alkalmazása az M modellgráfra a következő lépésekből áll: Az M gráfban az LHS gráffal izomorf részgráfot kell találjunk és erre illeszteni kell az LHS gráfot. Legyen ez az illesztés m. Ellenőrizni kell ezek után, hogy kiterjeszthető-e az m illesztés úgy, hogy NAC is illeszkedjen, mert ha igen, akkor ez megtiltja a szabály alkalmazását. 19

21 2.4. ábra. Referencia metamodellek Példa Törölni kell az M azon részét, mely szerepel az LHS-ben, de nem szerepel az RHS-ben. Létre kell hozni M-ben azokat a részeket, amelyek szerepelnek az RHS-ben, de nem szerepelnek az LHS-ben. Álljon a modellgráfunk processzekből (proc), melyek egy bufferen (buff) keresztül tudnak egymásnak üzeneteket (msg) küldeni, mely buffer maximum egy darab üzenetet tud tárolni. Tekintsük a 2.5(a). ábrán látható gráftranszformációs szabályt, ami egy üzenet elküldését írja le egy processzből egy bufferbe, feltéve, hogy nincs még üzenet a bufferben. A 2.5(b). ábra bal oldalán egy példa modell látható, melyre alkalmazni szeretnénk a gráftranszformációs szabályunkat: (a) A gráftranszformációs szabály (b) A szabály alkalmazása 2.5. ábra. Gráftranszformációs szabály alkalmazása Az első lépésben a következő illesztéseket találhatjuk: 20

22 1. P = pr1,b = b1,p2 = pr2,m = m1 2. P = pr1,b = b2,p2 = pr3,m = m1 A következő lépésben vizsgáljuk, hogy illeszthető-e a negatív feltétel: Ha az (1) szerint indulunk el, akkor itt meghiúsul a végrehajtás, mivel M2 = m2 esetében illeszthető a negatív feltétel. Mivel a (2) esetben nem illeszthető a negatív feltétel, végrehajthatjuk a gráftranszformációs szabályt. Az utolsó lépésben egyszerűen áthelyezzük az m1 üzenetet pr1 processzből b2 bufferbe Gráftranszformációs szabályok a modelltranszformációban Láthatjuk, hogy a gráftranszformációs szabályok kiváló eszközként szolgálnak a modelltranszformációs szabályok formalizálására egyszerűségük és a mögöttük lévő precíz matematikájuk miatt. (a) A szabály az általános jelöléssel (b) A szabály az általunk használt jelöléssel 2.6. ábra. Példa gráftranszformációs szabályra Az ábrázolásmódok között akadnak kisebb eltérések, mi a jelen leírásban az egyszerűség kedvéért csak az LHS oldalt fogjuk ábrázolni és itt fogjuk a NEG és a NEW kulcsszavak segítségével jelölni az előfeltétel negatív feltételeit, illetve az újonnan keletkező komponenseket. Az újonnan keletkező komponenseknél a NEW mellett a NEG kulcsszót is fel kell tüntetni, ami azért szükséges, hogy a szabályt ne tudjuk többször ugyanarra a részre alkalmazni. Ez a tömörebb ábrázolásmód azért alkalmazható a modelltranszformációs szabályoknál, mert ezen szabályok esetében nincsen egyáltalán törlés, illetve áthelyezés (a jobb oldalon minden olyan elemnek szerepelnie kell, ami a bal oldalon szerepel). A 2.6. ábrán bemutatunk egy transzformációs szabályt (mely a későbbiekben, egyéb kiegészítésekkel részletesen bemutatásra kerül) csupán azzal a céllal, hogy a jelöléseket szemléltessük. A 2.6(a). ábrán a szokásos ábrázolást használva feltüntettük a bal oldalt (LHS) és a jobb oldalt (RHS), a 2.6(b). ábrán pedig az általunk használt tömörebb ábrázolásmódot alkalmazva csak a kiegészített bal oldalt tüntettük fel. A NEG részek jelölik a negatív feltételeket, a NEW részek jelölik az újonnan létrehozandó komponenseket. A példa szabálya azt állítja, hogy ha van a modellünkben olyan osztály, aminek nincsen szülő osztálya, akkor hozzunk létre egy Ref_Cls és egy Table entitást, melyeket az ábrán látható módon kössünk össze és kössük az adott Class entitáshoz. 21

23 2.7. ábra. Példa a szabály alkalmazására Ha a szabályt a 2.7. ábra bal oldalán álló modellre alkalmazzuk, akkor a jobb oldali modellt kapjuk eredményül. A bal oldali modellben csak a Customer illeszthető a szabályban C1-el jelölt entitásra. A jobb oldalon újonnan keletkező elemeket New1- és New2-nek neveztük el. Jelen esetben az illesztést egyértelműen el lehetett végezni, mivel csak egy elem felelt meg az feltételeknek, de előfordulnak olyan esetek is melyek bonyolult vezérlést igényelnek az illesztések elvégzésére VIATRA2 A VIATRA2 a MIT tanszék által kifejlesztett népszerű modelltranszformációs keretrendszer, mely két népszerű, formális technikát használ gráf alapú modellek manipulálására: a gráftranszformációt [9] és az absztrakt állapotgépeket [6]. A VIATRA2 a modellek és a metamodellek leírására a VPM [29] megközelítést használja, mely a MOF szabvánnyal ellentétben korlátlan számú szintet enged meg a metamodellek számára, ezáltal többféle modellezési paradigmához (pl. MOF, XML Schema, stb) is jól illeszthetők. A VPM modellek megadására szolgál a VTML (Viatra Textual Metamodeling Language) metamodellező nyelv, a modellek különböző manipulálására pedig a VTCL (Viatra Textual Command Language) nyelvet használhatjuk Metamodellező nyelv a VIATRA2 rendszerben VPM A VPM egy matematikailag is precíz szemantikára épülő többszintű metamodellezési technika. Kifejlesztését leginkább az motiválta, hogy bár az eddig tárgyalt MOF metamodellezés elég jónak bizonyult, számos hiányossága akadt. A MOF hiányosságainak kiküszöbölésére született meg a VPM metamodellezési megközelítés. A 2.8. ábrán a VPM metamodellje szerepel néhány szükséges kiegészítéssel kényelmi és olvashatósági okokból. A VIATRA2 ezt a metamodellt használja. A VPM modell 2 fő komponensből áll: az entitásból (Entity) és a relációból (Relation). Mind a kettő egyazon ősosztály, a modellelem (ModelElement) leszármazottja. Az entitások jelképezik a modell alapelemeit, míg a relációk a modell elemei közti kapcsolatokat. Az entitáshoz tartozó value értéke eszköztől függően használható. Minden entitás szigorú tartalmazási hierarchiába (containment) van rendezve, így egy entitásnak van egy egyedi helyi neve és a hierarchiába való elhelyezkedésétől függő teljes neve (FQN = Fully Qualified Name). A relációnak a szükséges paraméterein kívül (from és to) megadhatjuk a multiplicitását (multiplicity), illetve az isaggregation paraméterrel azt, hogy a reláció forrása tartalmazza-e a reláció célját a metamodellre épülő modellben. Lehetőségünk van egy reláció inverz párját is megadni, (ha létezik ilyen). A modellelemek között két speciális reláció lehet: A supertypeof segítségével lehet öröklési hierarchiát létrehozni, az instanceof reláció segítségével pedig a különböző meta-szintek közötti kapcsolatot adhatjuk meg (Ezáltal lehetséges a korlátlan szintű metamodellezés). A VPM modellek felfoghatók gráfként oly módon, hogy az entitások legyenek a gráf csúcsai, a relációk pedig a gráf élei, ezáltal egyszerűen alkalmazhatók rájuk gráftranszformációs szabályok. 22

24 2.8. ábra. A VPM metamodell VTML A részletes szintaxis ismertetése helyett lássunk egy egyszerű példát a nyelv használatára. A 2.2(a). ábrán látható metamodellt a következő rövid kód segítségével adhatjuk meg: entity( UML) //Forrás domén { entity( metamodel ) //Forrás metamodell { entity( class) //entitás definiálása { relation( parent, class, class ); //reláció definiálása relation( attrs, class, attribute ); isaggregation( attrs, true); //tartalmazás beállítása multiplicity( attrs, one_to_many); //multiplicitás beállítása } entity( association ) { relation( src, association, class ); relation( dst, association, class ); } entity( attribute ) { relation( type, attribute, class ); } } } Látható, hogy egyszerű állítások segítségével megadhatjuk a különböző modelleket. A fenti metamodellt alapul véve már egyszerűen megadható bármilyen UML modell a 2.8. ábra konvencióit használva. Ha egy következő meta-szintre akarunk lépni, nem kell az instanceof relációt használni, hanem például a customer megadásához elég a class(customer) sort beírni és ezáltal a customer entitásra teljesülni fog az instanceof(customer, class) reláció. A példában a class entitás a metamodel entitásban helyezkedik el, a metamodel pedig az UML-ben. (Célszerű ezek után a metamodellre épülő modelleket a metamodel-lel egy szintre az UML-ben elhelyezni például egy models entitásban.) A példában a class entitás helyi neve egyszerűen class, a teljes neve pedig UML.metamodel.class. A modellek megadása a VIATRA2 számára általában egyszerűen valamilyen Importer segítségével történik, így nincs szükség a fenti kód manuális beadására. 23

25 Transzformációs nyelv A transzformációs nyelv segítségével lehetőségünk van a megadott modellek különböző manipulálására. A nyelv alapjául a gráftranszformációs szabályok (GT) és az absztrakt állapotgépek (ASM) szolgálnak. A gráftranszformációs szabályok segítségével alapvető modell manipulációs szabályok fogalmazhatók meg, melyek alapját a gráfminták (GP = Graph Pattern) képezik, az absztrakt állapotgépek segítségével pedig a vezérlési struktúrát írhatjuk le. Nézzük meg ezeket kicsit részletesebben: Gráfminták A gráfminták a gráftranszformációs szabályok alapjai. Különböző feltételek (, illetve kényszerek) fogalmazhatóak meg a segítségükkel, melyek például a gráftranszformációs szabályok előfeltételeként szolgálhatnak, vagy komplex lekérdezések valósíthatók meg velük. Egy modell kielégít egy gráfmintát, ha az sikeresen illeszthető az adott modell valamely részmodelljére (hasonlóan egy Prolog mintaillesztéshez). Fontos, hogy a Prolognál egy jobb mintaillesztés valósul meg a VIATRA2-ben, mert a klózok tetszőleges sorrendben szerepelhetnek, az öröklés is kezelve van és tényleges típusok is léteznek. A következő példa egy gráfmintát szemléltet: pattern hasparent (X) = { class(x); class(a); class. parent(p, A, X); } A fenti minta egyszerűen azokra a Class entitásokra illeszthető, melyeknek van szülőjük (létezik olyan osztály, mely parent relációban áll velük). A mintának jelen esetben egy paramétere van, az X. Egy minta meghívásánál lehetőségünk van változókat lekötni, ilyenkor egyszerűen megkapjuk, hogy sikerült-e illeszkedést találni az adott lekötött változókra, illetve lehetőségünk van változókat kimeneti paraméterként meghagyni, ilyenkor visszatérésként megkapjuk sikeres illesztés esetén a változók értékeit (analóg módon a Prologgal). A gráfminták használatánál lehetőségünk van negatív mintákat, rekurzív mintákat, illetve egy mintán belül több alternatívát hagyva vagylagos mintákat megadni. Nézzünk meg ezekre is egy-egy példát: Negatív minták. Negatív mintára nézzük meg az előbbi példa ellentettjét (keressük meg azokat a Class entitásokat, melyeknek nincsen ősük): pattern hasnoparent (X) = { class(x); neg find hasparent (X); } A fenti kódban egyszerűen negatív feltételként meghívtuk a már létező hasparent mintát az X paraméterrel. Negatív mintákat a neg parancs segítségével készíthetünk és a find parancs szolgál a korábban definiált minták meghívására. Vagylagos és rekurzív minták. A rekurzív mintákra és a mintán belüli alternatívákra nézzünk meg egy kicsit összetettebb példát, melyre az olyan Class entitás-párok fognak illeszkedni, ahol az egyik entitás a másik őse (parent relációkkal elérhető egyikből a másik): pattern ancestor (X, Y) = { class(x); class(y); class. parent(a, X, Y); } or { class(x); 24

26 } class(y); class(z); class. parent(a, Z, Y); find ancestor (X, Z); Az ancestor mintát az or kulcsszóval két részre bontottuk, ilyenkor a mintaillesztés sikeres lesz, ha valamelyik rész illeszthető. A rekurzió egyszerűen úgy valósul meg, hogy a find parancs használatával meghívjuk magát az ancestor mintát. Generikus minták. A VPM modell instanceof relációjának köszönhetően egyszerűen hozhatunk létre generikus mintákat. Generikus minták segítségével típus paramétereket adhatunk át és egyszerre hívhatunk meg modell- és metamodellbeli elemeket. pattern ent(x, Y) = { entity(x); entity(y); instanceof(y, X); } A fenti mintát például használhatjuk az összes X típusú elem meghatározására, mely elemeket az Y változóba fogjuk megkapni. Ehhez az X változót kell lekötni és Y változót szabadnak hagyni. Látható, hogy a gráfminták segítségével egyszerűen fogalmazhatunk meg a modellünkre különböző lekérdezéseket. Nézzük meg, hogyan használhatjuk a gráfmintákat gráftranszformációs szabályok megfogalmazására. Gráftranszformációs szabályok Gráftranszformációs szabályokat, mint azt már korábban leírtuk, az LHS és az RHS megadásával lehet definiálni. Az LHS és az RHS a VIATRA2-ben, az előbb tárgyalt gráfminták segítségével adható meg. A 2.6. ábrán látható gráftranszformációs szabályt a következő kóddal adhatjuk meg a VIATRA2-nek: (A változók nevei megfelelnek az ábrán használt nevekkel.) gtrule gt_example (in C1, out R, out TC, out Rel1, out Rel2) = { precondition pattern lhs( C1) = { class(c1); neg pattern haspar( C1) = { class(c1); class(c2); class.parent(a, C1, C2); } } } postcondition pattern rhs(c1, R, TC, Rel1, Rel2) = { class(c1); ref_class (R); ref_class.cls2(rel1, R, C1); table(tc); ref_class.cls2tab(rel2, R, TC); } action{ rename(tc, "t"+name(c1 )); rename(r, "r"+name(c1 )); } A gtrule paranccsal hozhatjuk létre a gráftranszformációs szabályt, melynek jelen esetben a gt_example nevet adtuk. A precondition részben adhatjuk meg az LHS gráfnak megfelelő feltételeket (ezek az illesztés előfeltételei), a postcondition részben pedig a RHS gráfot adhatjuk meg (ezek az illesztés 25

27 utófeltételei). A VIATRA2-ben lehetőség van még egy úgynevezett action rész megadására, ahol egyéb utasításokat adhatunk meg, melyek a szabály elvégzése után kerülnek meghívásra (jelen esetben egyszerűen nevet adtunk az újonnan létrejövő entitásoknak). A szabálynak továbbá megadhatunk paramétereket, illetve azok jellegét, ami lehet bemenő (in), kimenő(out), illetve egyszerre be- és kimenő (inout). Vezérlési szerkezetek absztrakt állapotgépekkel Komplex transzformációs szabályok esetében bonyolult szabály egymásra-hatások lehetnek, ilyenkor a vezérlési szerkezetek nagy mértékben le tudják egyszerűsíteni a szabályok végrehajtását. Az ASM program alapelemei az ASM szabályok, a változók és az ASM függvények. Az ASM függvények speciális matematikai függvények, melyek az értéküket egy asszociatív tömbben tárolják. A VTCL-ben speciális ASM függvények is szerepelnek (úgynevezett natív függvények), amelyek transzformációkból hívható, a felhasználó által definiált Java metódusok. Ezek a metódusok bármilyen Java könyvtárhoz és egyben a VIATRA2 modell-teréhez kapcsolódhatnak. Az absztrakt állapotgépek komplex modelltranszformációkat biztosítanak számos vezérlési struktúrával: call: A call parancs segítségével tudunk másik ASM szabályt meghívni. seq és random: A seq parancs a törzsében lévő szabályokat végrehajtja a megadott sorrendben, a random pedig véletlenszerűen kiválaszt egyet. let és update: A let paranccsal inicializálhatunk változókat, melyek a let törzsében lesznek érvényesek. Az update paranccsal a változók értékeit módosíthatjuk. if-then-else szerkezet: Az if-then-else szerkezettel tudunk feltételes eljárást létrehozni. try-else és iterate: A try és az iterate a törzsében lévő parancsokat próbálja meg elvégezni. try megpróbálja egyszer elvégezni és ha nem sikerül, meghívásra kerül az opcionális else rész. Az iterate megpróbálja a törzsében lévő szabályt addig alkalmazni, amíg lehetséges. choose X with cond(x) do body és forall X with cond(x) do body: Mindkét parancs a fej részében lévő változókat próbálja meg a cond feltételre illeszteni és az illesztés után meghívódik a body részben szereplő utasítás. A feltétel lehet egyszerű Boolean feltétel, lehet gráfminta-illesztés, illetve gráftranszformációs szabály. A különbség a choose és a forall között, hogy míg a choose nem-determinisztikusan választ egy behelyettesítést, addig a forall az összes lehetőségen végig megy. Nézzük meg, hogy a fenti vezérlő elemekkel hogyan valósíthatunk meg különböző gráfminta-illesztéseket és hogyan alkalmazhatunk gráftranszformációs szabályokat. rule main () = choose X below UML. models with find hasnoparent (X) do print(name(x)); A fenti kód a hasnoparent mintát illeszti egy, az uml.models elemeiből véletlenszerűen választott X elemmel (A choose parancsnál megadjuk, hogy az X váltózó honnan veheti fel az értéket a below használatával és a with után adjuk meg a feltételt jelentő gráfmintát). A UML.models tartalmazza jelen esetben az UML metamodellre épülő UML modelleket. A find parancs hatására megtörténik az illesztés és a sikeresen illesztett X nevét kiíratjuk a kimenetre. A main() ASM szabály fog elsőnek meghívódni, amikor egy állapotgépet futtatunk. 26

28 rule main () = seq{ let R = undef, T = undef, Ref1 = undef, Ref2 = undef in forall X below uml. models with apply gt_example (X, R, T, Ref1, Ref2) do print(" Sikeres illesztes!") } Az előbbi példával ellentétben itt nem egyetlen elemet választunk, hanem a forall hatására az összes illeszkedő X-re elvégezzük a transzformációt. Mivel az ASM-ben nem lehetnek deklarálatlan változók, mindegyiket kezdetben undef értékre kell állítani. Az apply hatására hívódik meg a gráftranszformációs szabály. A fenti leírás csupán a VIATRA2 képességeit szemlélteti, nem volt célunk a részletes bemutatása, a részletes bemutatás a [5]-ban található Összegzés A fejezetben ismertetésre kerültek a modelltranszformációt érintő legfontosabb fogalmak. Ezek közül részletesen foglalkoztunk a metamodell, illetve a gráftranszformáció paradigmájával és bemutattunk egy népszerű modelltranszformációs eszközt, a VIATRA2-t, mely az előbbi két megközelítést felhasználva kényelmes keretrendszert nyújt modellek manipulálásához. 27

29 3. fejezet Hasonlóság keresési technikák A fejezetben különböző hasonlóság keresési technikákat fogunk röviden ismertetni. Az első részben egy olyan módszer váza kerül bemutatásra, amely két modell között létrehoz egy összekötést a hasonlónak vélt elemek között, a második részben pedig különböző név-hasonlósági metrikák kerülnek röviden ismertetésre Hasonlóság elárasztása algoritmus Sokszor szükség lehet megadni, melyek a logikailag összetartozó elemek egy forrás- és az ahhoz tartozó célmodellben. A továbbiakban nevezzük ezt a műveletet egyszerűen összekötési műveletnek. Egy adott összekötés megadása sok esetben nem triviális feladat, legtöbbször számos, a modellekből közvetlenül nem kinyerhető információt is igényel. Ebből fakadóan nem adható egy általános, bármely doménben alkalmazható megoldás, ami a felhasználó beavatkozása nélkül képes lenne az összekötés előállítására. A hasonlóság elárasztása (Similarity Flooding, továbbiakban SF) algoritmuson[15] alapuló megoldás célja, hogy közvetlenül a két modellekből minél több információt kinyerve a lehető legjobb közelítéssel előállítsa a szükséges összekötéseket. A megközelítés a következő főbb lépéseken keresztül jut el a végső célig: 1. A bemenetre kapott modellekből címkézett élű, irányított gráfok (G1 és G2) generálódnak. 2. Létrejön egy kezdeti hasonlóság G1 és G2 elemei között. 3. A kezdeti hasonlóságok finomítása SF-ot használva. 4. Különböző szűröket és küszöbértékeket használva létrejön egy javaslat a véső összekötésre az előbbi pontban kiszámított hasonlóságértékekből kiindulva Gráfok előállítása és a kezdeti összekötés generálása A modellekből első lépésben címkézett élű irányított gráfok generálódnak (G1 és G2). Ez a lépés az egyszerűség kedvéért felfogható úgy, mintha a modell szöveges(vagy egyéb absztrakt) leírásából a 2.4. részben bemutatott VPM alapú modell generálódna, ahol az entitások felelnek meg a gráfok csúcspontjainak, a relációk pedig a címkézett irányított éleknek. A következő lépésben megállapítunk a G1 és G2 modellben lévő összes elempárra egy hasonlóságértéket. Ezt úgy tesszük meg, hogy egyszerűen minden elempárra kiszámítunk egy név-hasonlósági éréket (a különböző név-hasonlósági metrikákkal a 3.2. részben fogunk részletesen foglalkozni). Ezen két kezdeti lépés után kialakult a G1 és a G2 között egy teljes párosítás, mely tartalmazza a modellben lévő elemek közti hasonlóságot. Vegyük észre, hogy ehhez egyenlőre csupán csak az elemek neveit használtuk fel, a struktúrából fakadó információ még érintetlen. 28

30 Hasonlóságok elárasztása A következő lépés a kezdeti hasonlóságértékek elárasztása a két modell között a SF algoritmus használatával. Az algoritmus azon a feltevésen alapszik, hogy ha van a G1 és a G2 modellben két hasonló elem, akkor növeljük a környezetükbe eső elemek hasonlóságát. Ezek alapján két elem közti hasonlóságérték tovább fog terjedni a teljes gráfban számos iteráció után. Az algoritmus akkor fejeződik be, ha stabil állapotot ér el (, vagyis a megváltozás mértéke egy adott küszöb alá kerül). Terjesztési segédgráf A modelleket reprezentáló gráfban minden él felfogható egy (s, p, o) hármasként, ahol s jelöli az él kezdőpontját, o a végpontját, p pedig a címkéjét. A hasonlóság elárasztásához vezessünk be egy segédgráfot, amelyre egy példát a 3.1. ábrán láthatunk. Jelöljük az A és B modellekhez tartozó segédgráfot T SG(A, B)-vel. Egy segédgráf csúcspontja az A B elemeiből tevődik össze és a következő formulával definiálható: ((x,y), p,(x,y )) T SG(A,B) (x, p,x ) A,(y, p,y ) B. Tekintsük a 3.1. ábrán látható példát: Ha a és b között hasonlóság áll fenn, akkor nagy valószínűséggel ez igaz lesz a1 és b1 között is. Ezt a feltevést a l1 címkéjű él miatt tehetjük, mivel (a,a1) között és (b,b1) között is vezet ilyen él. Ezt a feltevést a T SG-ban az ((a,b),l1,(a1,b1)) él behúzásával jelöltük. A továbbiakban az olyan párokat, mint (a,b) (a1,b1)-et, szomszédoknak nevezzük ábra. Példa a terjedési segédgráfra Általános algoritmus Jelöljük az aktuális (i.-ik terjesztés utáni) hasonlóságértéket a és b elem között σ i (a,b)-val. A terjesztett hasonlóság (σ i+1 (a,b)) kiszámítása ezek után úgy történik, hogy az aktuális hasonlóságértékhez hozzáadjuk (egy esetleges terjedési együtthatóval megszorozva) az összes szomszéd aktuális hasonlóságértékét. Formálisan: σ i+1 (a,b) = σ i (a,b) + σ i (x,y) π r ( x, p,a), y,q,b ) (a,p,x) A,(b,q,y) B + (x,p,a) A,(y,q,b) B σ i (x,y) π l ( x, p,a), y,q,b ) A formulában először vesszük a kimenő élekhez tartozó-, utána a bemenő élekhez tartozó szomszédokat. Vegyük észre, hogy ez a formális definíció a fent definiált T SG-nél egy sokkal általánosabb terjedési feltételt enged meg a π r és π l függvények használatával(, ráadásul magában foglalja a terjedési együtthatókat is). Példaként a T SG-nek megfelelő π {r,l} függvény a következőképpen néz ki állandó terjedési éréket használva: { 1, ha p = q π {r,l} ( x, p,a), y,q,b ) = 0, ha p q. 29

31 Értékek normalizálása Mivel a terjesztési folyamatban bármelyik hasonlósági érték könnyűszerrel 1 fölé nőhet, szükség van az egyes terjesztési lépések után az értékek normalizálására. Ehhez egyszerűen az összes terjesztés utáni értéket el kell osztani az azok közötti maximális értékkel. Formálisan: (a,b) A B : normailze(a,b) = σ(a, b) max{s x,y : σ(x,y) = s}. A terjesztés akkor fejeződik be, ha a hasonlósági értékek megváltozása egy bizonyos ε küszöb alá csökken Végső összekötés Mivel a legtöbb alkalmazás számára az elárasztás révén keletkezett hasonlóságértékek kezelhetetlenek a túl nagy számuk miatt, egyfajta szűrést kell eszközölni rajtuk, hogy így álljon elő egy végső javaslat az összekötésekre. A szűrési fázisra számos alternatívát definiál a módszer, érdemes lehet az alkalmazáshoz legjobban illőt választani. A teljesség igénye nélkül röviden bemutatunk néhányat a javasolt szűrési megoldások közül: Bevezethetünk különféle kényszereket a szűréshez. Például egy kényszer lehet, ha kikötjük az összekötések számosságát ([1, 1], [n, 1], stb.). Bevezethetünk egy abszolút küszöbszintet és csak az afölötti összekötéseket hagyjuk meg. Bevezethetünk egy relatív küszöbszintet és így például minden célmodellbeli elemhez az ahhoz tartozó összekötések közül csak azokat hagyjuk meg, amelyek hasonlóságértéke az adott elemből nézve a relatív küszöb felett van. Lehet a cél, hogy minden elem benne legyen egy összekötésbe, úgy hogy az abban lévő élek száma minimális legyen, ugyanakkor a hasonlóságértékek összege maximális legyen Karakterlánc-hasonlósági metrikák A karakterláncok közti hasonlóság számos területen kerül elő és ennek köszönhetően széles körben lehet válogatni a különböző megoldások között. Két karakterlánc között meghatározható az azok közti távolság (ill. duális fogalomként a hasonlóság) és ez az érték legfőbb mértékben attól függ, hogy milyen modellt választottunk a kiszámítására. A szerkesztésen alapuló modell[13] az egyik legelterjedtebb megközelítés, amely úgy méri meg a karakterláncok közti távolságot, hogy megvizsgálja, különböző szerkesztési/átalakítási műveletekkel hogyan lehet az egyik karakterláncból a másikat megkapni. Az egyes műveletekhez költségeket rendel és a végső távolság érték ezen költségek összegeként fog előállni. Egy másik modell a lokális hasonlóságon alapuló modell[13], ekkor a rész-karakterláncok között kerülnek kiszámításra az egyes hasonlóságértékek és ezek közül választódik ki a legnagyobb. Ezen kívül természetesen léteznek egyéb modellek is, mint például a q-gram modell, de ezen leírásban ezekkel nem fogunk foglalkozni, ugyanis a későbbi céljainknak az előbbi két modell elegendőnek bizonyult. Egy kicsit kilóg a sorból, de szintén érdemes lehet megjegyezni a szinonima alapú hasonlóságot. Ekkor egy külső szinonima adatbázisból vesszük a hasonlósághoz szükséges információt A szerkesztésen alapuló modell, Levenshtein távolság A modell alapját a szerkesztési műveletek képezik Definíció. Szerkesztési művelet egy (α,β) (A 1 {ε}) (A 1 {ε})\{ε,ε} pár. 30

32 α és β jelöli az A halmazon vett két karaktert (tényleges karakter, vagy az üres karakter(ε)). A továbbiakban egy (α, β) szerkesztési műveletet egyszerűen α β-val fogunk jelölni. A gyakorlatban általában három fő művelet létezik: α ε, mely egy α karakter törlését jelenti. ε β, mely egy β karakter beillesztését jelenti. α β, mely egy α karakter β-val történő helyettesítését jelenti Definíció. Egy u és v közötti A igazítás (α 1 β 1,...,α h β h ) átalakítások sorozata, ahol u = α 1...α h és v = β 1...β h. Igazítás során az egyik karakterláncot szerkesztési műveletek sorozataként a másikhoz igazítunk. Legyen u = bcacd és v = dbadad. Ekkor egy példa A igazításra: A = (ε d,b b,c a,ε d,a a,c ε,d d). A fenti A-n kívül természetes számos egyéb igazítása is létezik u-nak és v-nek. Ahhoz, hogy az egyes igazítások között valamilyen rangsort tudjunk felállítani, szükségünk van egy költségfüggvényre Definíció. Minden egyes α β szerkesztéshez rendeljünk egy δ költségfüggvényt, melyre a következők teljesülnek: δ(α α) = 0 Ha δ(α β) = δ(β δ), akkor δ szimmetrikus. Ha minden α β,α β szerkesztési műveletre δ(α β) = 1, akkor δ az egységes költségfüggvény. A δ egyszerűen kiterjeszthető az igazításokra is: Egy A igazítás δ(a) költségfüggvénye az A = (α 1 β 1,...,α h β h )-ban szereplő szerkesztési műveletek költségeinek összege: δ(a) = h i=1 δ(α i β i ). Ennyi felvezetés után már definiálhatjuk a szerkesztésen alapuló modellben értelmezett távolságértéket Definíció. Jeljök az u és v közti távolságértéket edist δ (u,v)-vel adott δ mellett. edist δ (u,v) = min{δ(a) A az u és v közti igazítás }. Egy A igazítás optimális, ha δ(a) = edist δ (u,v). Ha δ az egységes költségfüggvény, akkor edist δ (u,v)-t egységes-, vagy más néven Levenshtein távolságnak nevezzük. A fenti feltételeket kielégítő megoldások megkeresésnek legkézenfekvőbb módja dinamikus programozás használata. Számos ilyen algoritmus létezik, melyek lineáris tár és időben megtalálják a minimális távolságot. 31

33 Lokális hasonlóság, Smith-WaterMan algoritmus Vegyük észre, hogy a fenti Levenshtein távolság egy u és egy v karakterlánc között a távolságot globális értelemben adja meg, a számításnál mindig mind a két karakterláncot teljes egészében figyelembe veszi. Ez legtöbb esetben megfelelő eredménnyel szolgáltat, de előfordulhat olyan eset is, hogy nem ez a megfelelő számunkra. Egy egyszerű példa erre, ha egy rövidebb nevet akarunk egy annál jelentősen hosszabb névvel összehasonlítani és tegyük fel, hogy a hosszabb név teljes egészében tartalmazza a rövidebbet. Ekkor a Levenshtein távolság várhatóan nagyon nagy lesz, míg mi ilyenkor kis távolságértéket várnánk eredményül a teljes tartalmazás miatt. Az ilyen és hasonló esetekben az vezet megoldáshoz, ha lokális hasonlóságértéket számolunk. A megoldás alapelve, hogy az összes u-ban és v-ben lévő rész-karakterláncokra vizsgálunk hasonlóságértéket és ezek közül válasszuk a legmagasabbat. A továbbiakhoz vezessünk be egy jósági függvényt Definíció. Rendeljünk minden α β szerkesztési művelethez egy σ(α β) jósági érétket és nevezzük σ-t jósági függvénynek. Hasonlóan σ(a) = h i=1 σ(α i β i ) egy A = (α 1 β 1,...,α h β h ) igazításhoz tartozó jósági érték. Példaként tekintsük a következő jósági függvényt: 1 ha α = ε β = ε σ(α β) = 1 ha α = β 2 ha α β A függvény egyszeresen bünteti a beszúrást és a törlést, duplán pedig a kicserélést. Az előbb definiált jósági függvény használatával a következő módon vezessünk be egy hasonlóságértéket: Definíció. Legyen u és v közti hasonlóságérték definíciója a következő score σ (u,v) = max{σ(a) A az u és v közti igazítás } Vegyük észre, hogy míg az edist δ esetében egy távolságértéket definiáltunk, amelyet az optimum kiszámítása érdekében minimalizálni kellett, addig most egy hasonlóságértéket definiáltunk, amit épp ellenkezőleg maximalizálni kell ahhoz, hogy a számunkra optimális értéket kapjuk Definíció. Legyen σ egy adott jósági függvény. Definiáljuk a következőket: 1. loc σ (u,v) = max{score σ (u,v ) u része u-nak és v része v-nek}. 2. Legyen u része u-nak és v része v-nek, úgy hogy score σ (u,v ) = loc σ (u,v). Ekkor u és v egy A igazítását az u- és v-hez tartozó lokális optimális igazításnak nevezzük, ha score σ (u,v ) = σ(a). 3. A lokális hasonlósági probléma tehát kiszámolni a loc σ (u,v)-t és meghatározni a lokális optimális igazítást. A fenti probléma megoldására egy dinamikus programozást használó, általános megoldást ad a Smith-Waterman algoritmus, amely technikai részleteitől megkíméljük az olvasót. A algoritmus az összes rész-karakterlánc kipróbálása helyett egy ügyes trükkel szintén lineáris tár és időben előállítja a maximális hasonlóságértéket. Megj.: A későbbiekben a Smith-Waterman algoritmust fogjuk használni a fenti példaként bemutatott jósági függvénnyel Összegzés E fejezetben ismertettük a Similarity Flooding algoritmust és egy gyakorlati alkalmazását, ezzel megalapozva a 6. fejezetet, amelyben ezen megoldásból fogunk ötleteket meríteni. Ezen felül részletesen bemutattuk két név-hasonlósági metrika alapelvét, amelyekre szintén a 6. fejezetben fogunk támaszkodni. 32

34 4. fejezet Induktív Logikai Programozás A fejezetben az Induktív Logikai Programozás kerül bemutatásra, amit egy rövid példával kezdünk (4.1. rész), majd kitérünk az ILP algoritmusának alapelvére (4.3. rész), elméleti hátterének bemutatása (4.2. rész) után. A fejezet végén (4.4. rész) az ILP egy általunk is használt implementációját mutatjuk be kiragadva számos felhasználási módja közül egyet, melyre a modelltranszformációs szabályok előállításához nekünk is szükségünk lesz. Az ILP bemutatása az [18] alapján történik. Induktív Logikai Programozás. Az Induktív Logikai programozás (ILP = Inductive Logic Programming) a mesterséges intelligencia egy ágazata, mely, két lényeges irányzat, az induktív gépi tanulás és az elsőrendű logikai programozás egyesítéséből született. Az előbbinek köszönhetően képes hipotéziseket létrehozni megfigyelésekből (esetünkben: példákból), másrészt reprezentációs eszközként az elsőrendű logikát használja, így képes túllépni a klasszikus gépi tanulás korlátain. Tudásreprezentáció. A gépi tanulásban általában erős korlátot jelent az ítéletlogika, mint tudásreprezentációs eszköz. A probléma az ítéletlogikával, hogy csak egyetlen reprezentációs eszközünk van, az ítéletszimbólum és így kisebb tudások reprezentálására is tömérdek ítéletszimbólumot kell kezelnünk ezáltal nagy mértékben lelassítva a következtetési eljárást. Továbbá csupán az ítéletszimbólumokkal a változásokat sem tudjuk kezelni, így sajnos számos tudás ábrázolására nem bizonyul elegendőnek ez a tudásreprezentáció. Azáltal, hogy az ILP az elsőrendű logikát használja tudásreprezentációs eszközként, a fenti hiányosságokat sikerült áthidalnia. Az elsőrendű logika konstans, predikátum- és függvényszimbólumokból épül fel, melyek megválasztása teljes mértékben a felhasználón múlik. Induktív tanulás. Az induktív tanulás az ILP alapját képezi. Az indukció a specifikusból az általánosra való következtetést jelenti. A mi esetünkben ez annyit jelent, hogy a tanulási algoritmus képes megadott háttértudás és példák alapján általános szabályokat, hipotéziseket létrehozni. A kapott hipotéziseket és a háttértudást felhasználva legalább a példákat elő kell tudjuk állítani Példa Mielőtt rátérnénk az ILP elméletére, nézzünk meg egy egyszerű példát, ami azt szemlélteti, hogyan képes az ILP megtanulni a nagyapa családi kapcsolatot. Tekintsük a következő háttértudást és jelöljük B-vel. 33

35 B = szulo(tamas, zoltan). szulo(tamas, eva). szulo(zoltan, adam). szulo(adam, gergo). szulo(eva, jozse f ). szulo(eva, andrea). szulo(andrea, gabor). f er f i(tamas). f er f i(zoltan). f er f i(adam). f er f i( jozse f ). f er f i(gabor). f er f i(gergo). no(eva). no(andrea). Megadtunk a család néhány tagja között kapcsolatokat 1. Ez egy olyan tudás, ami már a birtokunkban van és erre tudunk a későbbiekben építeni ábra. Példa családfa A szulo(x,y ) predikátum azt fejezi ki, hogy Y szülője X, a f er f i(x) predikátum pedig azt, hogy X férfi. A jobb szemléltetés érdekében a 4.1.ábrán megadtuk a fenti szolu(x,y ) kapcsolatokat egy egyszerű (család)fában is, ahol a nyilak jelzik a kapcsolat meglétét. A nagyapa predikátumot akarjuk megtanítani, ehhez szükség lesz pozitív és negatív példákra. Jelöljük a pozitívokat E + -szal: nagyapa(tamas, adam). E + nagyapa(tamas, jozse f ). = nagyapa(tamas, andrea). nagyapa(zoltan, gergo). A negatív példákat jelöljük E -szal: nagyapa(tamas, tamas). E nagyapa(tamas, zoltan). = nagyapa(tamas, gergo). nagyapa(eva, gabor). A B tudás birtokában, a pozitív (E + ) és negatív (E ) példákkal együtt a következő H hipotézist állíthatjuk fel: H = nagyapa(x,y ) szulo(x,z) szulo(z,y ) f er f i(x) 1 A leírásban Prolog-szerű jelölést használtunk. 34

36 A hipotézis azt állítja, hogy X akkor lesz Y nagyapja, ha van egy Z, aminek X szülője és Z szülője Y -nak. Továbbá fennáll, hogy X férfi. Vegyük észre, hogy a hipotézisből és a háttértudásból levezethetjük a pozitív példákat. Más szóval a hipotézisünk teljes: e E + : B H e Továbbá a háttértudásból és a hipotézisből nem levezethetők a negatív példák. Más szóval a hipotézisünk konzisztens: e E : B H e A következő fejezetben azzal fogunk foglalkozni, hogy az ILP milyen módszerekkel tudja kikövetkeztetni a hipotéziseket Elméleti háttér Az előbbi példák után a hipotézisekhez vezető út további magyarázatra szorulhat. Bontsuk az indukciót az ILP-ben a következő két részre: Abdukció Indukció = Abdukció + Igazolás Az abdukció a hipotézis képzés folyamata. Abdukcióról beszélünk, ha adott E evidencia és E H implikáció mellett a hipotézis H lesz. Az ILP esetén pontosan megadjuk a szemantikát. Ugyan a normál szemantika megenged a hipotézisben, a háttértudásban és a példákban is bármilyen (jól formált) logikai formulát, a legtöbb ILP rendszerben (amit mi is használni fogunk) a hipotézisben és a hátértudásban csak definit klózok, a példákban pedig csak egyszerű állítások szerepelhetnek. Ezt hívják definit szemantikának: Definíció. Adott a B háttér tudás, és az E példák halmaza (az E pozitív és negatív példákból áll. E = E + E ). Keressük a H hipotézist, hogy a következő feltételek teljesüljenek: e E : B e (a priori konzisztencia) (4.1) e E + : B e (a priori szükségesség) (4.2) e E : B H e (a poszteriori konzisztencia) (4.3) e E + : B H e (a poszteriori szükségesség) (4.4) A 4.1 feltételt nevezik a priori konzisztenciának, a 4.2 feltételt pedig a priori szükségességnek. Ezek a feltételek kell hogy teljesüljenek a kezdeti (priori) háttértudásra és pozitív példákra. A 4.3 feltételt a poszteriori konzisztenciának, a 4.4 feltételt pedig a poszteriori teljességnek szokás nevezni. Ezek a H hipotézisre vonatkozó utólagos feltételek, melyeket minden hipotézisnek teljesítenie kell. 4.1 feltétel azt állítja, hogy egyik negatív példa se legyen levezethető a háttértudásból. Ha ez nem teljesülne, a háttértudásunk inkonzisztens lenne a példákkal. 4.2 feltétel azt állítja, hogy néhány pozitív példa ne legyen levezethető a háttértudásból. Ha ez nem teljesülne, akkor a pozitív példák szükségtelenek lennének. 4.3 feltétel azt állítja, hogy egyik negatív példa se legyen levezethető a háttértudásból és a hipotézisből. A 4.1 feltételnél ez annyiban mond többet, hogy a hipotézist is hozzáveszi a háttértudáshoz. 4.4 feltétel azt állítja, hogy mindegyik pozitív példa legyen levezethető a hipotézissel kibővített háttértudásból. Ez jelenti a hipotézis teljességét. 35

37 Hipotézisek igazolása Miután megkaptunk egy hipotézist, valamilyen formában igazolni kell a helyességét. Az igazolás talán nem is a legmegfelelőbb szó, hiszen az eljárásból következik, hogy egy hipotézis helyességéről nem tudunk száz százalékosan megbizonyosodni. Pontosabb ha azt mondjuk, hogy több hipotézis közül kiválasztjuk, illetve megerősítjük a legmegfelelőbbet. Szükségünk lesz arra, hogy valamilyen formában rangsoroljuk a kapott hipotéziseket. Ezt sokféleképpen megtehetjük. Kezdve a legegyszerűbbektől, amikor csak a lefedett pozitív és negatív példák számát figyeljük, egészen a legösszetettebbekig, amikor felhasználjuk a különböző valószínűségeket és a legnagyobb információtartalommal rendelkező hipotézist részesítjük előnyben. Az általunk használt eljárásban mi azt fogjuk figyelembe venni, hogy egy hipotézis hány pozitív példát fedett le, illetve egyáltalán nem fedhet le negatív példákat ILP algoritmusának az alapelve Ebben az alfejezetben az ILP algoritmikus vázát fogjuk bemutatni a főbb lépésekre koncentrálva. A leglényegesebb megállapítás, hogy az ILP algoritmusa egy keresési probléma: az előző részben bemutatott szemantikának megfelelő hipotéziseket kell megtalálnunk. Mint a legtöbb hasonló problémánál, a számítási igény csökkentése érdekében a keresési teret le kell szűkítsük (le kell vágnunk bizonyos utakat). A kérdés, hogy ezt milyen módon tegyük meg. Az ILP esetében a keresési tér egyfajta kettős nézet szerint strukturálható: ez az általánosítás és a specializáció. Esetünkben az általánosítás összefügg az indukcióval, a specializáció pedig a dedukcióval Definíció. Egy G hipotézis általánosabb egy S hipotézisnél, akkor és csak akkor, ha G S. Ekkor azt is mondhatjuk, hogy S specifikusabb, mint G Definíció. Egy r R következtető szabályra akkor mondjuk, hogy deduktív, ha egy G-t S-be képez, hogy G S, ahol G és S klózok konjunkciója. Más néven r specializációs szabály. Egy deduktív következtető szabályra egy jó példa a rezolúció Definíció. Egy r R következtető szabályra akkor mondjuk, hogy induktív, ha egy S-t G-be képez, hogy G S, ahol G és S klózok konjunkciója. Más néven r általánosító szabály. Egy induktív következtető szabályra jó példa az abszorpció: Abszorpció: p A,B p q,b q A q A Az ilyen induktív szabályok, mint például az abszorpció nem feltétlenül egyeznek meg a deduktív logikai következtetéssel. Ezt feloldásképpen minden H hipotézishez egy L-lel jelölt valószínűséget rendelnek L = p(h B E). L annak a valószínűségét fejezi ki, hogy feltéve a háttértudás és a példák ismeretét mennyi az esélye a H hipotézisnek. Ha a hipotéziseket mindig kiegészítjük a fenti információval az indukciót deduktív következtetésnek is felfoghatjuk. Nézzük meg az általánosítás és a specializáció hogyan is segít a keresési tér leszűkítésében: Specializáció: Ha B H e, ahol e E +, akkor nincs olyan H specializációja H-nak, amire már igaz lenne, hogy B H e. Az összes ilyen hipotézisre igaz, hogy L = p(h B E) = 0, így ezek levághatók a keresésből. Általánosítás: Ha B H e, ahol e E, akkor az összes H általánosítására, H -re is igaz lesz, hogy B H e, vagyis, hogy inkonzisztens lesz a háttértudással és a példákkal. Az összes ilyen hipotézisre igaz, hogy L = p(h B E) = 0, így ezek is levághatók a keresésből. Az eddigi kulcsgondolatok alapján megadjuk az ILP algoritmusának a vázát: 36

38 JH := Initialize repeat Delete H from JH Choose the inference rules r 1,...,r k R to be applied to H Apply the rules r 1,...,r k to H to yield H 1,H 2,...,H n Add H 1,H 2,...,H n to JH Prune JH until stop-criterion(jh) satisfied Az algoritmus a következőképpen működik: A jelölt hipotézisek tárolására fenntart egy JH nevű tömböt. Folyamatosan töröl egy H hipotézist a JH-ból, amit majd kiterjeszt a következtetési szabályok segítségével. Ezek a kiterjesztett hipotézisek hozzáadódnak a JH tömbhöz, amit a már tárgyalt módszerekkel, ha szükséges megszabadítanak a sikertelennek tűnő hipotézisektől. Ez a folyamat addig ismétlődik, amíg a megállási kritérium nem teljesül. A fenti algoritmusban az általános eljárások Courier betűtípussal szerepelnek. Ezek a következőek: Az Initialize állítja össze a kezdeti hipotézis-halmazt. R jelöli a használható következtetési szabályok halmazát. A Delete eljárás a keresési stratégiára van hatással. Különböző megvalósításai más és más algoritmust eredményeznek, mint például mélységi (Delete = LIFO), vagy szélességi (Delete = FIFO). A Choose eljárás határozza meg, hogy mely következtetési szabályok legyenek hatással H-ra. A Prune eljárás azt határozza meg, hogy mely hipotézis jelöltek legyenek törölve az JH tömbből. Ezt általában a hipotézisekhez tartozó L valószínűségekkel valósítják meg, vagy egyszerűen rábízzák a felhasználóra. A Delete és a Prune kombinálásával lehet komoly keresési stratégiákat kialakítani. A stop-criterion azt a feltételt tartalmazza, aminek a teljesülése szükséges az algoritmus megállásához. A leggyakrabban használt ilyen kritérium, hogy legyen meg a megoldást jelentő hipotézis. Eddig az ILP általános elméletével, illetve algoritmusával foglalkoztunk. Az implementációk ezektől kis mértékben persze eltérhetnek, de az alapelv nem fog változni. A következő fejezetben egy konkrét ILP alkalmazást fogunk bemutatni, amit a modelltranszformációs szabályok előállításához használunk a későbbiekben Aleph Az Aleph [26] (A Learning Engine for Proposing Hypotheses) egy Prologban megírt ILP rendszer, mely számos beállítási lehetőséget biztosít a felhasználónak (többségére nekünk nem lesz szükségünk) Aleph használata Az Aleph Prologban íródott. Futtatásához szükséges van egy SWI, vagy egy Yap Prolog fordítóra. Az SWI-Prolog esetében az Aleph elindítása annyiból áll, hogy kiadjuk a [aleph]. utasítást. Ezek után a következő fő lépéseket kell tegyük: 1. Három fájlt készítünk a következő nevekkel: name.b, name.f, name.n, ahol a name egy általunk választott név. A három fájl fogja tartalmazni rendre a háttértudást, a pozitív és a negatív példákat. 2. A read_all(name) paranccsal beolvassuk az adatokat. 3. Az induce paranccsal létrehozzuk a hipotéziseket. 37

39 A példák és a háttértudás megadása az Aleph-ben A name.b fájl tartalmazza a háttértudást, ami a Prologban megszokott klózok formájában van leírva. Itt lesz minden olyan információ, amire az Aleph majd a hipotézisek létrehozása közben támaszkodhat. Ezen kívül a name.b fájl fogja tartalmazni a mód és típus, valamint a determináció deklarációkat, amikről hamarosan szó lesz. A name.f és name.n fájlok tartalmazzák a pozitív, illetve a negatív példákat, mely fájlokban (a definit szemantikának megfelelően) csak egyszerű állítások szerepelhetnek. Nézzünk meg, hogyan kell például a 4.1 szakaszban bemutatott példát az Aleph programnak beadni (a mód, típus és determináció deklarációk nélkül, amiket mellesleg később meg fogunk adni). Nevezzük a fájlokat nagyszulo.*-nak és nézzük meg a fájlok tartalmát külön-külön. A nagyszulo.b tartalma: %%%%%%%%%%%%%%% A nagyszulo.b tartalma %%%%%%%%%%%%%% szulo( tamas, zoltan ). szulo( tamas, eva ). szulo( zoltan, adam ). szulo( adam, gergo ). szulo(eva, jozsef ). szulo(eva, andrea ). szulo( andrea, gabor ). ferfi( tamas ). ferfi( zoltan ). ferfi( adam ). ferfi( jozsef ). ferfi( gabor ). ferfi( gergo ). no(eva ). no( andrea ). %%%%%%%%%%%%%%% A nagyszulo.f tartalma %%%%%%%%%%%%%% nagyapa( tamas, adam ). nagyapa( tamas, jozsef ). nagyapa( tamas, andrea ). nagyapa( zoltan, gergo ). %%%%%%%%%%%%%%% A nagyszulo.n tartalma %%%%%%%%%%%%%% nagyapa( tamas, tamas ). nagyapa( tamas, zoltan ). nagyapa( tamas, gergo ). nagyapa(eva, gabor ). Látható, hogy egyszerűen a Prolog-jelölését használva meg kellett adni a szükséges állításokat. Mód és típus deklarációk. A mód deklarációk adják meg, hogy egy predikátumot hogyan hívjon meg az Aleph, amikor hipotézist gyárt. A mód deklaráció a következőképpen néz ki: mode(recallnumber, PredicateMode) A RecallNumber korlátozza a predikátum meghívásának a nem-determinizmusát, a PredicateMode pedig megadja a predikátum hívásának módját. A RecallNumber lehet egy szám, mely megadja a predikátum sikeres hívásainak a számát, vagy lehet nem determinisztikus, amit egy *-gal jelölünk. Általában a legegyszerűbb a RecallNumber-t *-ra állítani. A PredicateMode alakja a következő: p(modetype, ModeType,...) A predikátum neve p, a ModeType pedig a következők egyike lehet: +T azt mondja, hogy amikor a p predikátum megjelenik a hipotézisben, akkor az adott helyen lévő argumentum T típusú bemenő változóként kell, hogy szerepeljen. 38

40 -T azt mondja, hogy amikor a p predikátum megjelenik a hipotézisben, akkor az adott helyen lévő argumentum T típusú kimenő változóként kell, hogy szerepeljen. #T azt mondja, hogy amikor a p predikátum megjelenik a hipotézisben, akkor az adott helyen lévő argumentum T típusú konstansként kell, hogy szerepeljen. A típus deklarációk 2 így implicit módon benne vannak a mód deklarációkban. Példaként megmutatjuk 4.1 szakasz példájának mód deklarációit (A :- jelölés a Prolog konvencióknak megfelelően az ( ) implikációt jelenti.): % A megtanulandó predikátum. Minden argumentuma bemeneti :- mode (1, nagyapa (+ember, +ember )). :-mode (*, szulo (+ember, -ember )). :-mode (*, szulo(-ember, +ember )). :-mode (*, ferfi (+ ember )). :-mode (*, no(+ ember )). A típusokat tekintve jelen esetben csak egy van, az ember típus. A megtanulandó predikátum (esetünkben a nagyapa) minden argumentuma bemenő szokott lenni, mint ahogy jelen esetben is így van. Ezek után következnek a hipotézis törzsében megjelenhető predikátumok, melyeket az általánosság kedvéért nem-determinisztikusra állítottunk. A szulo/2 predikátum először úgy szerepel, hogy első argumentuma bemenő, második pedig kimenő. Másodszor meg pont fordítva. A no/1 és ferfi/1 predikátumok bemenő argumentummal szerepelnek. Determináció. Egy Determináció a következő formátumú lehet: determination(targetname/arity, BackgroundName/Arity) A TargetName adja meg annak a predikátumnak a nevét és aritását, ami a hipotézis klóznak a fej részében fog szerepelni, a BackgroundName pedig annak a predikátumnak adja meg a nevét és aritását, ami a hipotézis klóz törzsében szerepelhet. Mivel az Aleph egyszerre csak egy predikátumra tud hipotézist(hipotéziseket) gyártani, így csak egyetlen predikátum van megengedve a TargetName-nek. Tipikusan nagyon sok determináció van egy Target- Name-hez. Példaként itt is megmutatjuk a 4.1 szakasz példájának determináció deklarációit: :- determination ( nagyapa /2, no /1). :- determination ( nagyapa /2, ferfi /1). :- determination ( nagyapa /2, szulo /2). Keresési paraméterek. A háttértudást tartalmazó fájlban a fenti kötelező paraméterek megadásán kívül az Aleph számos beállítási lehetőséget biztosít a felhasználó számára, hogy optimalizálja, illetve egyedivé tegye az eljárást. Ezek közül azok kerülnek most bemutatásra, amiket majd mi is használni fogunk. A set(parameter, Value) predikátum segítségével tudjuk a Parameter-nek megadott paramétert Value értékre állítani. Literálok maximális száma: set(clauselength, +V); V pozitív egész. Megadhatunk egy felső korlátot a hipotézis klózokban szereplő literálok számára (a fej is számít). A clauselength értéke alapértelmezésben 4. Változók keresési mélysége: set(i, +V); V pozitív egész. Megadhatunk egy felső korlátot, hogy milyen mélységű változók szerepelhetnek a hipotézis klózokban. A változók keresési mélysége meghatározza, hogy a hipotézis képzésekor meddig vehetünk fel új változókkal új predikátumokat. Az i értéke alapértelmezésben 2. 2 A típusok jelen esetben nem valódi típusok, hanem csak szimbólikus nevek. 39

41 Algoritmus A 4.3 szakaszban már megadtuk az általános ILP algoritmust, most megadjuk az Aleph algoritmusának főbb lépéseit. Általános esetben az Aleph 4 fő részt különböztet meg az algoritmusban, melyek a következők: 1. Egy példa választása: Kiválaszt egy példát, amit általánosítani fog. Ha nincs már példa, az algoritmus befejeződött, ha van, a következő pontra lép. 2. Szaturáció (Saturation) A legspecifikusabb klóz elkészítése: Megalkotja a legspecifikusabb klózt, ami maga után vonja a kiválasztott példát. Ez általában egy definit klóz nagyon sok literál. (Az Aleph-ben úgy nevezik, hogy bottom clause.) Megj.: A bottom clause mérete nagyban befolyásolja az Aleph futási idejét, de ezzel a témakörrel az MTBE kapcsán a 10. fejezetben még részletesen fogunk foglalkozni. 3. Redukció (reduction) Keresés: Keres egy általánosabbat a bottom clause-nál. Ezt úgy teszi meg, hogy a bottom clause literáljainak keresi meg azokat a részhalmazait, amelyek a legjobb értéket érik el. Az érték meghatározásának számos alternatívája létezik. 4. Redundancia eltávolítása: A legjobb értékkel rendelkező klózt hozzáadja a hipotézisekhez és a redundánssá vált példákat eltávolítja. Ezek után visszatér az első pontra. A fenti alapalgoritmus kiegészítésére az Aleph mindegyik lépésben számos beavatkozást enged meg, így az általánostól elég nagy mértékben eltérő algoritmust is létre tudunk hozni. Ezek közül mi csak egyre fogunk részletesebben kitérni, amit a későbbiekben használni fogunk Elméletek létrehozása A háttértudás felállítása és beolvasása után, az induce parancs hatására létrejönnek a hipotézisek. A kimeneten a kapott hipotéziseken kívül sok más is megjelenik, mint például az adott példához tartozó bottom clause. Példaként nézzük, meg, hogy milyen hipotézist/hipotéziseket kapunk a 4.1 szakasz példájára (A három fájl teljes tartalmát az A függelékben találhatjuk). Az Aleph miután megkapta az induce parancsot, a következő eredményt adja: [theory] [ Rule 1] [ Pos cover = 4 Neg cover = 0] nagyapa(a, B) :- ferfi(a), szulo(a, C), szulo(c, B). Az Aleph-nek egyetlen szabályt sikerült találnia, ami megfelel az elvárásainknak. A [Rule 1] után az szerepel, hogy a szabály hány pozitív, illetve negatív példát fed le Rekurzív szabályok megtanítása Az Aleph segítségével nagyon egyszerűen tudunk akár rekurzív szabályokat is megtanítani. Nézzünk meg erre egy egyszerű példát. Tanítsuk meg az os(ős) predikátumot, miszerint akkor lesz egy A ember egy B ember őse, ha A B-nek a szülője, vagy B-nek van egy szülője, melynek A őse. Vegyük az eddigi példánkat és az os.b fájlba tegyük bele a nagyszulo.b háttértudást a mód és a determináció deklarációk, valamint a no/1 és a ferfi/1 predikátumok nélkül. Az utóbbi két predikátumra nincsen szükségünk, a deklarációkat pedig újra írjuk. A mód és determináció deklarációk legyenek a következők: :- mode (1, os(+ember, +ember )). :-mode (*, szulo (+ember, -ember )). :-mode (*, szulo(-ember, +ember )). :-mode (*, os(+ember, +ember )). :- determination ( os/2, szulo /2). % A rekurzió végett a hipotézis törzsében megjelenhet % a megtanulandó os predikátum. :- determination ( os/2, os /2). 40

42 Látható, hogy egyszerűen belevettük a megtanulandó os/2 predikátumot a törzsben használható predikátumok közé is. Adjunk meg pozitív és negatív példákat az os.f, illetve os.n fájlokba: %%%%%%%%%%%%%%% A os.f tartalma %%%%%%%%%%%%%% os( tamas, zoltan ). os(tamas, eva ). os( zoltan, adam ). os(adam, gergo ). os(eva, jozsef ). os(eva, andrea ). os(tamas, adam ). os( tamas, jozsef ). os( tamas, andrea ). os( zoltan, gergo ). os(eva, gabor ). os( tamas, gergo ). os( tamas, gabor ). %%%%%%%%%%%%%%% A os.n tartalma %%%%%%%%%%%%%% os( tamas, tamas ). os(zoltan, eva ). os(andrea, eva ). os( gabor, tamas ). Az Aleph az induce parancs hatására a következő két szabályt adja: [theory] [ Rule 1] [ Pos cover = 6 Neg cover = 0] os(a, B) :- szulo(a, B). [ Rule 2] [ Pos cover = 7 Neg cover = 0] os(a, B) :- szulo(c, B), os(a, C). Az Aleph kimenete pontosan megfelel az elvárásainknak. Látható, hogy az Aleph kiválóan alkalmas rekurzív szabályok előállítására is Kényszerek megtanítása az Aleph-ben Az Aleph eddigi használatánál nem volt szükségünk negatív feltételek megtanítására. Az Aleph rendszerben a negatív feltételek (kényszerek) megtanításához egy úgynevezett Costraint Learning módot kell használnunk. A Constraint Learning lehetővé teszi az adatokra kényszerek megfogalmazását. Ilyenkor nincs szükség pozitív és negatív példákra, egyszerűen a háttértudásként reprezentált rendszerünkre fogjuk megkapni a kényszereket a következő klózok formájában, ahol a1, a2,... tetszőleges literálok: false:- a1, a2,... Ez azt jelenti, hogy ami a törzs részbe kerül, egyszerre nem lehet igaz. Így ha egy predikátumról negatív kényszereket akarunk megkapni, bele kell tenni a törzsbe a mód deklarációk segítségével. Az induce helyett itt induce_constraints parancsot kell használni. Nézzünk meg erre is egy konkrét példát. Példa. A példában az árva (arva) relációra fogunk kényszereket megtanítani. Érezni lehet, hogy ehhez valahogy a szülője (szuloje) predikátumot kell majd negálva felhasználni. Tekintsük a következő háttértudást: :- mode (1, false ). :-mode (1, arva(-gyerek )). :-mode (*, szuloje(-szulo, +gyerek )). :-mode (*, szuloje (+szulo, -gyerek )). :- mode (1, gyerek (+ gyerek )). 41

43 :-mode (1, szulo (+ szulo )). :- determination ( false /0, arva /1). :- determination ( false /0, gyerek /1). :- determination ( false /0, szulo /1). :- determination ( false /0, szuloje /2). :- set( clauselength, 3). szulo( agi ). szulo( tamas ). gyerek( endre ). gyerek( eva ). gyerek( zoltan ). gyerek( jozsef ). gyerek( attila ). szuloje( tamas, endre ). szuloje(agi, eva ). szuloje(agi, zoltan ). arva( attila ). arva( jozsef ). Megadtunk pár szülői kapcsolatot és néhány gyereket, akik közül akad, akinek nincsen szülője. Látható a determináció deklarációkból, hogy a keresett klóz fej részében false fog szerepelni. A mód deklarációkban csak az arva predikátum szerepel csak kimeneti argumentumokkal, ami azt jelenti hogy innen tud úgymond elindulni a klóz készítése. A :-set(clauselength, 3) azért kell, mert sejteni lehet, hogy nem kell sok literál a klózba, viszont ha az értéket nagyobbra állítjuk, akkor sok redundáns kényszer fog keletkezni. Ezek után nézzük meg, mit ad az Aleph eredményül az induce_constraints parancs hatására: [ constraints ] false :- arva(a), szuloje(b, A). [pos -neg] [0] Ez tökéletesen megfelel az elvárásainknak, mivel azt fejezi ki, hogy nem lehet valaki egyszerre árva és valakinek a gyereke. Nézzük meg mi történik, ha a clauselength paramétert 4-re állítjuk: [ constraints ] false :- arva(a), szuloje(b, A). [pos -neg] [0] false :- arva(a), szuloje(b, A), arva(c). [pos -neg] [0] false :- arva(a), szuloje(b, A), gyerek(a). [pos -neg] [0] false :- arva(a), szuloje(b, A), szulo(b). [pos -neg] [0] false :- arva(a), szuloje(b, A), szuloje(c, A). [pos -neg] [0] false :- arva(a), szuloje(b, A), szuloje(b, C). [pos -neg] [0] false :- arva(a), gyerek(a), szuloje(b, A). [pos -neg] [0] false :- arva(a), arva(b), szuloje(c, A). [pos -neg] [0] false :- arva(a), arva(b), szuloje(c, B). [pos -neg] [0] [ definition ] [ false /0] [ total clauses constructed ] [23] Látható, hogy az eredménybe számos redundáns kényszer is belekerül. Itt szembesülnünk kellett egy gyakorlati problémával, mégpedig, hogy az Aleph sajnálatos módon nem szűri ki a redundáns kénysze- 42

44 reket, így a keletkezett kényszerek közül nekünk kell kiszűrni a redundáns kényszereket, hogy végül csak a legáltalánosabbat (legkevesebb klózt tartalmazót) használjuk fel Redundáns kényszerek kiszűrése A számunkra redundáns kényszerek kiszűrésére a következő eljárást javasoljuk: Ha egy kényszer úgy is kényszer marad, ha kihagyjuk belőle a kérdéses (jelen esetben ez az arva(a)) literált, akkor az biztosan redundáns, így azt törölhetjük. Ezt megtehetjük például úgy, hogy beadjuk a Prolognak a törzsben szereplő literálokat arva(a) nélkül és megnézzük ad-e rá megoldást. Ha egy kényszer tartalmaz egy másikat, akkor azt is el lehet hagyni a többi közül. Ehhez ezt a tartalmazást kell csak egyszerűen végig nézni és ha egy nagyobb literál számú klózban megtalálható egy kisebb literál számú klóz, akkor az elhagyható. Ha a fenti két lépést elvégezzük a másodszorra kapott kényszerekre, pont a szükséges kényszereket fogjuk visszakapni Összegzés A fejezetben bemutattuk az ILP elméleti hátterét és részletesen megismerkedtünk egy konkrét implementációjával, az Aleph-fel. Láthattuk, hogy az ILP képes elméleteket létrehozni csupán háttértudás és példák alapján. Az Aleph hatékony eszköznek bizonyult elméletek és kényszerek létrehozására, melyeket kombinálva lehetőségünk van összetett szabályokat megalkotni. 43

45 5. fejezet MTBE automatizálása Ebben a fejezetben részletes bemutatásra kerül az MTBE megközelítést egyéb szükséges kiegészítésekkel és pontosításokkal annak érdekében, hogy a továbbiakban az ILP rendszerrel végezhessük el a szabályok generálását Automatizálás lépései 5.1. ábra. MTBE főbb lépései A javasolt eljárás, melyet az 5.1. ábra foglal össze, a következő főbb lépéseken keresztül jut el a végső modelltranszformációs szabályokig: 1. A példa modellpárok megalkotása: A transzformáció tervezőjének el kell készítenie a példákat jelentő összetartozó forrás- és célmodell párokat, melyek le kell fedjék a transzformáció kritikus eseteit. Megj.: Sok esetben a tervezőnek rendelkezésre állnak már összetartozó példa modelljei. 2. Összekötések generálása: A beadott összetartozó forrás- és célmodellből fél-automatikus módon generálódik a modellek közti összekötés. Ezt a lépést a 6. fejezetben fogjuk részletesen bemutatni. 44

46 3. (Segédinformációk megadása): Ebben a lépésben a transzformációra vonatkozó segédinformációkat lehet opcionálisan megadni, melyek segítik a transzformációs szabályok készítését, illetve kompaktabbá teszik azokat. 4. Modelltranszformációs szabályok automatikus generálása: Az automatizált lépések a következő főbb alpontokból állnak: (a) Referencia elemek kontextusának analízise: Megvizsgáljuk, hogy mi mondható egy adott típusú referencia modellbeli elem forrásmodellbeli kontextusáról. Így megkapjuk azokat a kontextusból adódó feltételeket, amelyek a referencia elemek létrehozásához szükségesek. (b) Célelemek kontextusának analízise: Megvizsgáljuk mi mondható egy célmodellbeli elem referencia modellbeli kontextusáról. Megkapjuk azokat a feltételeket, amelyek a célmodellbeli elemek létrehozásához kellenek. (c) Célelemeket összekötő relációk analízise: A célmodellben lévő összes relációra meg kell határozni a reláció létezéséhez szükséges kontextusból adódó feltételeket. (d) Célelemeket létrehozó szabályok generálása: Legeneráljuk azokat a gráftranszformációs szabályokat, amelyek segítségével létre tudjuk hozni a célmodell szükséges elemeit. Ehhez az (a) és a(b) pontban kapott eredményeket használjuk fel. (e) Relációkat létrehozó szabályok generálása: Legeneráljuk a célmodellbeli relációk létrehozásához szükséges szabályokat. Ezeket a gráftranszformációs szabályokat a (c) pontban kapott eredmények felhasználásával kapjuk meg. Az (a), (b) és (c) lépéseket a 7. fejezetben az ILP használatával fogjuk megvalósítani, míg a (d) és a (c) lépések megvalósításának mikéntjét a 8. fejezetben fogjuk tárgyalni. 5. Szabályok finomítása: A kapott szabályok elemzése után lehetőségünk van esetleges újabb példák felvételével előröl kezdeni a folyamatot a 4.ponttól, illetve manuálisan módosítani a kapott szabályokat, ha azok nem felelnek meg a kívánalmainknak. 6. Szabályok alkalmazása: Lehetőség van a kapott szabályok kipróbálására bármilyen további forrásés célmodell párokon, ezáltal egyfajta validációt végrehajtva a szabályokon. E modellek természetesen ugyanúgy felhasználhatók a későbbiekben a szabályok tanításának finomhangolására. A fent bemutatott eljárás az alapul vett [28] cikket követi, attól a következő főbb pontokon tér el, ill. egészíti ki azt: Az MTBE összekötési fázisára beiktattunk egy szintén fél-automatikus támogatást. Az összekötések megalkotása az eredeti cikkben teljes mértékben a felhasználóra volt bízva. Lehetőséget adunk opcionálisan segédinformációk megadására, melyek használatával tömörebb szabályaink keletkezhetnek. A fenti lépésekben határozottan megkülönböztetjük a célelemek, ill. a célrelációk létrehozásához szükséges szabályokat. Specializáltuk a kontextusok fogalmát abban az értelemben, hogy három jól elkülöníthető kontextust definiáltuk, melyek megléte már elegendő a transzformációs szabályok megalkotásához Feltételezések A fenti eljárás elvégzéséhez a következő feltételezéseket tesszük a referencia/összekötés modellre: 1. Minden referencia elem össze van kötve az összes olyan forráselemmel, amelyektől közvetlenül függ a létezése. Ez a feltétel biztosítja, hogy a referenciamodell pontosan a tervező szándékait tükrözi. 45

47 2. Minden referencia elem össze van kötve az összes olyan célmodellbeli elemmel, amelyek nem létezhetnek külön-külön, kizárólag együtt. Objektum-relációs példánkban egy osztályhoz tartozó táblához minden esetben tartozik egy id és egy kind oszlop. 3. Minden célmodellbeli elem hozzá van kötve pontosan egy referencia elemhez. Ez a feltétel biztosítja a transzformáció determinisztikus voltát abban az értelemben, hogy célelemek létrehozása csakis pontosan a hozzájuk tartozó referencia elemtől függ, nem szükséges a forrásmodell megléte. Megj.: Egy forráselemhez akár több referencia elem is tartozhat. 4. A célmodellbeli elemek létezésének feltétele közvetlenül csak bizonyos referenciaelemek létezésétől függ. Ezáltal a forráselemek a célelemektől csupán a referencia modell elemein keresztül függenek. 5. A célmodellben lévő relációk létezése csak a forrásmodelltől függ, illetve annak bizonyos struktúrájától, nem függ magától a célmodelltől. A fenti feltételezések nagy számú transzformációt lefednek, de előfordulhatnak olyan esetek is, amikor a fenti feltevések nem teljesíthetőek és akkor az MTBE nem alkalmazható. A 7.9. fejezetben többek között ilyen eseteket fogunk bemutatni Példa modellpárok összekötése Példaként tekintsük a 2.3 ábrán látható modelleket. Tegyük fel, hogy a tervezőnek ezek a kezdeti tanító modelljei. A következő lépésként meg kell adni az ezek közti összekötést. Az összekötések fél-automatikus megadásával a 6. fejezetben fogunk részletesen foglalkozni, éppen ezért jelen esetben csupán megadjuk a szükséges összekötést, amely az 5.2. ábrán látható. Megj.: Az áttekinthetőség érdekében az 5.2. ábrán nem tüntettük fel a célmodell relációit, azok a 2.3. ábra alapján odaképzelendők ábra. Referencia modell Megj.: A valóságban most következne a segédinformációk megadása, de mivel a segédinformáció megadása opcionális, ezért a bemutatását későbbre hagyjuk. 46

48 5.4. Kontextus analízis Ebben a fázisban meghatározzuk a referencia elemekre és a célelemekre vonatkozó kontextust, mely meghatározza az elemek létezésének feltételét Referencia elemek kontextus analízise A referencia elemek kontextus analízisét a forrásmodellben kell elvégezni, ugyanis az 5.2. részben tett 1. feltételezés biztosítja, hogy a referencia elemek létrehozásának kontextusból fakadó feltétele csakis a hozzá tartozó forrásmodelltől és annak struktúrájától függjön. Példaként nézzük meg, hogyan nézhet ki a Ref_Cls elemhez tartozó kontextus. A Ref_Cls referenciához a transzformáció leírása alapján olyan Class elemek kapcsolódnak, melyeknek nincsen ősosztálya (Ez látható az 5.3(b). ábrán.), tehát a kontextus elemzésből legjobb esetben ezt az információt kellene, hogy megkapjuk. Figyeljük meg, hogy a példa modellpárunk nem tartalmaz elég információt, ahhoz hogy az előbbi, általános következtetést megkapjuk. A példából arra ugyan tudunk következtetni, hogy csak az olyan Class elemeket kell Ref_Cls elemmel összekötni, aminek nincsen ősosztálya, de helytelenül arra is következtethetünk, hogy kell legyen leszármazott osztálya és nem lehet attribútuma (Ezt az 5.3(a). ábrán láthatjuk). (Ha alaposan szemügyre vesszük az ábrát ezek az állítások csakugyan mind a két Class típusra igazak, amelyek a Ref_Cls elemmel össze vannak kötve, tehát a példamodellben a kontextus minden további nélkül igaz.) Ezek alapján ezt a modellt mindenképpen ki kell majd bővítenünk, ha megfelelő transzformációs szabályokat akarunk kapni. (a) Kezdeti, hibás kontextus (b) Végső, helyes kontextus 5.3. ábra. A Ref_Cls referenciához tartozó forráselemek kontextusa Célelemek kontextus analízise A célelemek kontextus analízisét a referencia modellben kell elvégezni, ugyanis az 5.2. részben tett a 4. feltételezés biztosítja, hogy a referencia elemek létrehozásának kontextusból fakadó feltétele csakis a hozzá tartozó referencia modellbeli elemtől és annak kontextusától függjön. Továbbá a a 3. feltételezésnek köszönhetően a kérdéses kontextus csupán a referencia elem meglétét jelenti. Ezek alapján például a Table elem pontos kontextusa az 5.4(a). ábrán látható. Tovább egyszerűsíthetünk a kontextusokon, ha kihasználjuk a 2. felételezést, ugyanis ezáltal összevonhatjuk az összetartozó célelemek kontextusát. Erre láthatunk példát az 5.4(b). ábrán, ahol a Ref_Cls elemhez tartozó célelemek kontextusát egyszerre kezeljük Célelemeket összekötő relációk analízise A célelemeket összekötő relációk analízise közben az 5. feltevésre támaszkodva minden célmodellbeli reláció típusra meg kell állapítani azokat a forrásmodell struktúrájából fakadó feltételeket, amelyek szükségesek a reláció létrehozásához. Megj.: Egy adott típusú reláció létrehozása több egymástól különböző 47

49 (a) A Table kontextusa (b) Több elem együttes kontextusa 5.4. ábra. Példa célelemek kontextusára feltételhez is köthető, így egy adott típusú reláció létrehozásához általában több különböző feltételt fogunk kapni. Például az fkeys reláció különböző feltételeknek köszönhetően jön a létre a 2.3. ábrán látható tcustomet és ffavourite-, ill. treviews és r_src_fkey elemek között. Példaként vizsgáljuk meg, mi mondható a 2.3. ábrán látható modellek alapján az fkeys reláció létrehozásához szükséges feltételektől: 5.5(a). ábra: Minden olyan Table típusból vezessen Fkey elembe reláció, melyek egyazon Ref_Asc elemhez vannak kötve (két feltételt foglal magába). 5.5(b). ábra: Minden olyan Table típusból vezessen Fkey elembe reláció, mely táblához tartozik egy Class elem, és az parent relációban áll egy olyan másik Class elemmel, ami attrs relációban áll egy olyan Attribute elemmel, ami a szükséges Fkey elemhez tartozik. A tartozik jelen esetben azt jelenti, hogy össze vannak kötve egy közös referencia elemmel. (a) Első feltétel(ek) (b) Második feltétel 5.5. ábra. fkeys elem kontextusa Megj.: Vegyük észre, hogy a fenti két feltétel nem elég az fkeys reláció teljes körű jellemzéséhez. Gondoljunk arra, hogy ha egy olyan osztálynak van attribútuma, aminek nincsen őse, akkor arra egyik feltételt sem lehetne illeszteni (igaz, hogy a második feltétel majdnem jó ). Látszik, hogy ebben az esetben sem ad elegendő információt a jelenleg beadott példánk. Erre a problémára később még visszatérünk, amikor a segédinformációk megadását tárgyaljuk az 5.7. részben. 48

50 5.6. Gráftranszformációs szabályok generálása A következő automatizálási lépésben a fenti kontextusokból (létrehozáshoz szükséges feltételekből) meg kell alkotni a végső gráftranszformációs szabályokat. A gráftranszformációs szabályok megadásánál a részben bemutatott egyszerűsített ábrázolásmódot fogjuk alkalmazni. A szabályok létrehozásához szükséges algoritmus vázát a 8. fejezetben fogjuk megadni, e rész célja csak az eljárás szemléltetése Elemeket létrehozó szabályok Az elemeket létrehozó szabályok szigorúan véve két fajta szabályból tevődnek össze. Az első szabály a referencia elemek kontextusa alapján a referencia elemek létrehozásáért felel, a második pedig a célelemek kontextusa alapján a célelemek létrehozásáért. Példaként az 5.6(a). ábrán látható a Ref_Cls referencia elemet létrehozó szabály, mely az 5.3(b). ábrán feltüntetett kontextusból származtatható. Az 5.6(b). ábrán feltüntettük azoknak a célmodellbeli elemeknek a létrehozásához szükséges szabályt, amelyeknek a kontextusa a Ref_Cls referencia elem meglétét szabja ki feltételül. Vegyük észre, hogy az eddigiek alapján a referencia- és a forráselemek létrehozása egy szabályba foglalható össze. Például az 5.6(a). ábrán és az 5.6(b). ábrán látható szabályok összevonásaként az 5.6(c). ábrán látható szabály fogalmazható meg. (a) Referencia elemet létrehozó szabály (b) Célelemeket létrehozó szabály (c) Összetett szabály 5.6. ábra. Példa elemeket létrehozó szabályra Célrelációkat létrehozó szabályok A következő fázis a célrelációk létrehozásához szükséges gráftranszformációs szabályok létrehozása. Ezek a szabályok fogják a már létrehozott célmodellben létrehozni a szükséges célmodellbeli relációkat. Példaként nézzük meg, hogy az fkeys relációra vonatkozó szabályok milyen egyszerűen ábrázolhatók gráftranszformációs szabályok használatával, felhasználva az 5.5. ábrán látható kontextus analízis eredményeit. Az 5.7(a). ábrán az első szabály, (miszerint minden olyan Table típusból vezessen Fkey elembe reláció, melyek egyazon Ref_Asc elemhez vannak kötve), az 5.7(b). ábrán pedig a másik szabály látható. 49

51 (a) fkeys reláció első és második szabálya (b) fkeys reláció harmadik szabálya 5.7. ábra. fkeys reláció szabályai 5.7. Segédinformációk Számos modelltranszformációs megközelítés segédinformációk bevezetésével csökkenti az egyes transzformációs szabályok komplexitását. A jelen megközelítésben mi is hasonlóan, segédinformációk használatával próbálunk tömörebb szabályokat előállítani. Amikor megadjuk az összekötött forrás- és célmodellt minden információt megadunk a transzformációs szabályok létrehozásához (persze ez csak akkor igaz, ha a példa minden kritikus esetet lefed). Gondoljuk végig például, mennyi példa szükséges az fkeys reláció végleges szabályának megtanításához, ha feltételezzük, hogy az osztályok egymással korlátozott mélységig állhatnak parent relációban (a feltételezés erős korlátozás jelent az általános felhasználhatóságot illetően, ugyanakkor elengedhetetlen, ha véges számú példát szeretnénk megadni): A korláttól függően fog változni a példák nagysága és a megtanulandó szabályok száma, ugyanis ha egy sok parent reláción keresztül elérhető osztálynak van attribútuma, ahhoz is fel kell vennünk egy oszlopot a szükséges táblában. A 2.1. részben az O/R leképezés informális leírásban a következő állítás szerepel az Attribute entitások kezelésére: Egy UML osztályhoz tartozó attribútum egy oszlopba képződik, mely oszlop ahhoz a táblához fog tartozni, mely tábla az UML osztályból (vagy az osztály legfelsőbb őséből) képződött.. A kiemelt információ bizonyos Class entitásokat együttesen kezel, ezáltal kompaktabban tudja megfogalmazni a transzformációs szabályt. A segédinformációk megadása alatt ilyen jellegű információkat értünk, melyek megadása nem nélkülözhetetlen a transzformációs szabályok generálásához, csupán tömörebbé teszi azokat, illetve lehetőséget teremt összetettebb szabályok megtanítására 1. Nézzük meg, hogy esetünkben milyen segédinformációt adhat meg a transzformáció tervezője, hogy kompaktabbá tegye például az fkeys relációt. A Class entitásokat és leszármazottjaikat kellene valamilyen módon egységesen kezelni. Ennek érdekében vegyünk fel egy ancestor nevű relációt, mely akkor lesz behúzva egy A Class entitásból egy B Class entitásba, ha A B-nek az őse (pontosabban fogalmazva parent relációkkal elérhető A-ból B), illetve (az ős jelentésével kissé ugyan ellentmondásban) ha A megegyezik B-vel. Feltevődik a kérdés, hogy hogyan adjuk meg ezt az információt, ugyanis ha képesek vagyunk ilyen jellegű információ közvetlen megadására, akkor ellentmondásba jutunk a kezdeti feltételezésünkkel, 1 Ilyenek például a rekurzív szabályok 50

52 5.8. ábra. Példa az ancestor relációra miszerint a felhasználónak elegendő csak a forrás- és célnyelveket ismernie. A megoldás, hogy a fő koncepciót használva ezt a szabályt is generáljuk le példák alapján. Az 5.8. ábrán egy példát látunk, ami elegendő információt tartalmaz az ancestor reláció megtanítására. Az ábrán, egy az UML modellből kiragadott kisebb részletet, illetve egy további elemet láthatunk (a VeryVipCustomer). Az ancestor relációt a szaggatott nyilak jelölik. A fenti példamodellt beadva elő kell állítani az ancestor reláció kontextusát a példamodellben és az alapján generálhatjuk a szükséges transzformációs szabályt. Az 5.9. ábrán feltüntettük azt a transzformációs szabályt, ami leírja az ancestor relációt ábra. Az ancestor reláció szabályai E rész zárásaként nézzük meg, hogyan is néznek ki az fkeys reláció szabályai az ancestor reláció felhasználásával. Az eddig kapott szabályok az 5.7. ábrán láthatók. Vegyük észre, hogy az 5.7(a). ábrán lévő szabály ugyanaz marad a kiegészített modellben is, de 5.7(b). ábra által ábrázolt szabályt a ábrán látható kompaktabb alakra lehet hozni a kapott segédinformáció felhasználásával (megj.: vegyük észre, hogy az új szabály magába foglalja az eddigi szabályt is). A változás csupán annyi, hogy a vastagon szedett ancestor szerepel az eddigi parent helyett, de ezáltal sikerült a végső szabályokat megkapni az fkeys relációra, sőt a rekurzív ancestor relációnak köszönhetően nem kell semmilyen korlátozást feltételeznünk az egymással parent relációban álló Class entitások számára sem További példák hozzáadása (szabályok finomítása) Az eddigi példa alapján az 5.3(a). ábrán látható, téves kontextus fogalmazódhat meg bennünk a Ref_Cls referencia elemhez. Ezek alapján szükséges lehet újabb példa modellpárokat megadni. Egy olyan példa 51

53 5.10. ábra. Az fkeys reláció második végleges szabálya modellpárral kellene kiegészíteni az eddigi példákat, hogy azzal együtt már az 5.3(b). ábrán látható kontextust lehessen kikövetkeztetni ábra. Új példa Adjuk meg további példának az ábrán látható modell-párt és referencia modellt. Az UML modell két Class entitásból áll, melyek a clerk(adminisztrátor) és a manager(igazgató). A clerk boss(főnök) relációban áll a manager elemmel. Látható, hogy mindkét osztály össze van kötve Ref_Cls entitással, mivel egyiknek sincs őse, viszont leszármazott osztályuk sincs és van amelyiknek van attribútuma, ellentmondásba kerülve így az 5.3(a). ábrán látható kontextussal. Az így kiegészített példák alapján már az 5.3(b). ábrán látható, helyes kontextusra tudunk következtetni MTBE megközelítéshez kapcsolódó munkák A jelenlegi munka alapjául teljes mértékben a [28] cikk szolgált, ettől teljesen függetlenül a [30] cikkben egy nagyon hasonló megközelítést mutattak be, ami szintén transzformációs szabályok automatikus generálását tűzte ki célul. Az alapvető koncepcionális különbség a két megközelítés között, hogy míg a [30]-ben egy objektum alapú megközelítést adtak, mely során ATL ([11]) szabályokat hoznak létre modelltranszformációs szabályokként, addig a [28] gráf alapú és ebből fakadóan gráftranszformációs szabályokat hoz létre. Bár a modelltranszformáció területén a példák alapján történő szabálygenerálás (MTBE) egy teljesen újszerű javaslat, a szoftvertechnológia más területén gyakorta előfordult a by example megközelítés. A következőkben röviden bemutatunk néhány nagyobb jelentőséggel bíró by example megközelítést. 52

54 Programozás példa alapján. A megközelítést korai szakaszában Automatikus programozásnak nevezték. Később, hogy rávilágítsanak a lényegi koncepcióra miszerint a példa be-/kimenet párokból generálódik a végső program a Programozás Példa alapján (Programming by Example [7]), vagy más néven Programming by Demonstration elnevezést kapta. Az elképzelést az motiválta, hogy a felhasználónak általában ugyanazokat, vagy nagy mértékben hasonló szekvenciákat kell leprogramoznia különböző feladatokhoz. Viszont ha a számítógépek pont a sokszori ismétlésben jók, miért kell a felhasználónak ezt elvégeznie. További előnye a megközelítésnek, hogy a felhasználónak nem kell a saját fejében lévő vizuális elképzelésből egy teljesen más szöveges reprezentációra áttérnie. A megközelítésben a felhasználó minta adatokon demonstrálja a program működését és a számítógép megpróbál általános következtetéseket levonni a program működését illetően. Lekérdezés példák alapján. A Lekérdezés példák alapján (Query by Example = QBE [31]) az IBM által kifejlesztett oszlopkalkulus alapú lekérdező nyelv relációs adatbázisokhoz 2. Alapkoncepciója, hogy a tényleges lekérdezések helyett (Például SQL szkriptek) a felhasználó példát ad meg a kívánt végeredményre. A példák jelen esetben olyan sablonok, melyek speciálisan kitöltött táblákból állnak. A táblák soraiban konstansok, kényszerek és változók szerepelhetnek. A lekérdezés megalkotásához a felhasználónak nem kell bonyolult lekérdező nyelveket ismernie, elegendő csupán a minimális tudást igénylő példa táblákat megadnia, így olyan felhasználók is képesek bonyolultabb lekérdezéseket megfogalmazni, akik nem ismernek komplexebb lekérdező nyelveket. XSLT automatikus generálása. Komolyabb XSLT alkalmazások lehetővé teszik XSLT stíluslapok generálását sémákból (például a MapForce az Altova-tól [4]), illetve konkrét minta példányokból (például a Stylus Studio [2]). A megközelítés előnye az előbbiekhez hasonlóan az, hogy a felhasználónak nincsen szüksége az XSLT ismeretére, elég a konkrét XML dokumentumokat megadni, illetve drag-and-drop módon összekötni azokat és az adott eszköz ezek alapján automatikus módon legenerálja a szükséges XSLT dokumentumot Összegzés A fejezetben részletesen bemutattam az MTBE egyes fázisait, továbbá általánosítottam a [28] cikkben leírtakat azzal, hogy beletettem az automatikus összekötési fázist és pontosítottam azokat a megkötéseket, amelyek a technika használatának előfeltevései. Továbbá, specializáltam a kontextusok foglamán, melynek következtében a szabálygenerálás az ILP használatával mehet végbe. 2 Ilyen lekérdető nyelv a jól ismert SQL is 53

55 6. fejezet Modellek közti összekötés generálása A fejezetben bemutatunk egy módszert, amellyel a forrás- és célmodellek közti összekötéseket félautomatikus módon lehet előállítani. Az első részben leírjuk a módszer célját, azután bemutatjuk a módszer legfőbb lépéseit, illetve a módszer által használt adatstruktúrákat. A további részekben egy kisebb példán végigvezetve részletesen tárgyaljuk a módszer egyes lépéseit, az utolsó részben pedig bemutatjuk, hogy milyen támogatást nyújtunk a felhasználói beavatkozásokhoz a pontosabb összekötés megalkotása érdekében Célkitűzés Az MTBE megközelítés bemenetének meg kell adni a forrás- és célmodelleken kívül az ezek közti összekötéseket is. Tapasztalataink alapján az összekötések létrehozása korántsem triviális feladat és nagy modellek esetében igen sok időt is igénybe vehet. Érződik tehát, hogy egy módszer, amely támogatást ad az összekötések létrehozására, nagy mértékben megkönnyítheti és meggyorsíthatja a tervezést. Célunk tehát az MTBE kiegészítése egy olyan módszerrel, amely képes összetartozó forrás- és célmodellekből igen jó közelítéssel legyártani a modellek közt fennálló kategorizált összekötéseket. A kategorizálás jelen esetben annyit jelent, hogy megvizsgálva az összekötések struktúráját az azonos struktúrájú összekötéseket egy kategóriába sorolunk be (másképp fogalmazva megadjuk az összekötések metamodelljét). Továbbá a keletkezett összekötésnek teljesítenie kell az 5.2. részben tett feltételezések közül az összekötés struktúrájára vonatkozókat. A 3. feltételezés teljesíthető az összekötések megfelelő gyártásával, míg a többi feltételezés teljesülésének ellenőrzéséhez mindenképp szükségünk lesz némiképp a tervezőre. Az általunk javasolt megközelítés alapötletét a 3.1. részben bemutatott Similarity Flooding algoritmus adta, ugyanakkor számos esetben jelentősen eltértünk attól. Ezekre a leírás során ki fogunk térni és magyarázatot adunk a döntésünkre. Az eltérések fő oka abban rejlik, hogy a SF-nál valamivel általánosabb módszert kellett kidolgozni, ugyanis az erősen épített az elemek közti relációkra (SF-nál a relációk a címkéknek felelnek meg), esetünkben viszont a forrás- és a célmodellben lévő relációk elnevezése a legtöbb esetben semmi hasonlóságot nem mutat Áttekintés A módszer főbb lépései A módszer a bemenetre adott forrás- és célmodellből legenerálja a javasolt modellelemek közti összekötéseket és létrehozza a javasolt összekötésekhez tartozó metamodellt (megj.: ez az összekötés metamodell teljes mértékben megfelel a részben bemutatott referencia metamodellnek, így a továbbiakban a két kifejezést ugyanazon értelemben fogjuk használni.). A folyamat két fő lépése a 6.1. ábrán látható. A beadott modellpárból először létrejönnek az elemek közti összekötések. (Megj.: az összekötés fogalom tágabb értelemben vett összekötést jelent, ugyanis általánosan több forrásmodellbeli ele- 54

56 6.1. ábra. Szükséges bemenetek, ill. generált kimenetek met kötünk össze több célmodellbeli elemmel. A továbbiakban ha ki akarjuk hangsúlyozni, hogy egy összekötés pontosan két elemet köt össze, azt párosításnak fogjuk nevezni.) Az elemek közti összekötésekből létrejön a hozzájuk tartozó összekötés/referencia metamdell. Az összekötéseket ezek után hozzáigazítjuk az újonnan keletkezett metamodellhez. A visszakapott összekötések támogatott módosítása A módszer által használt adatstruktúrák A javasolt módszer két jól elkülöníthető adatstruktúrával dolgozik: A összekötések kezelésére szolgál a mapping csomag (6.2(a). ábra). Ebben definiálunk egy absztrakt mapping(összekötés) elemet, amely az összekötés egy nagyon általános leírását adja. A mapping elemnek vannak forrás-, és célelemei(sourceclass és targetclass), amit rendre a src és tar relációkkal fejezünk ki. A mapping elemből példányosítható elemek adott multiplicitású összekötést jelentenek. A név első értéke utal az összekötéshez tartozó forráselemek multiplicitására, a második pedig az összekötéshez tartozó célelemek multiplicitására. Például egy N_to_1 típusú összekötés 1-nél több forráselemet és pontosan 1 célelemet köt össze. A javasolt módszer számára fontos információk tárolására szolgálnak a mappingstates csomagban (6.2(b). ábra) definiált elemek. Egy statefulm (állapottal rendelkező összekötés) elemet definiálunk az állapotokkal rendelkező összekötések absztrakt ősosztályaként. A következő négy állapotot különböztetjük meg a folyamat során, amelyekbe az összekötések kerülhetnek : initm: kezdeti összekötések állapota. propm: terjesztett összekötések állapota. auxm: segédösszekötések állapota. finalm: végső összekötések állapota. Az initm és propm elemek számára létrehoztunk egy matching (párosítás) absztrakt elemet, amely lehetőséget biztosít a későbbiekben ezen elemek kényelmes, egységes kezelésére. A propm elem from relációjával jelezzük, hogy az adott elem mely párosítás révén keletkezett a terjesztés során. A auxm és a finalm elem from relációja azt jelzi, hogy az adott összekötés mely párosításokból tevődik össze. Megj.: A későbbiekben minden elem részletesen elő fog még kerülni. 55

57 (a) Az összekötéseket leíró adatstruktúra (b) A módszer számára szükséges információk tárolására szolgáló adatstruktúra 6.2. ábra. A módszer által használt adatstruktúrák A 6.3. ábrán látható az egyes csomagok egymáshoz való viszonya. A sourcemodel, targetmodel, sourcemetamodel, és a targetmetamodel a beadott forrás- és célmodell az azoknak megfelelő metamodellekkel. A refmetamodel és a mappingmodel a generált kimenet, az előbbi az összekötés metamodellje, az utóbbi pedig maga az összekötés. A módszer számára fontos az előbb bemutatott mapping, illetve a mappingstates csomag. Amikor a modellek között összekötéseket hozunk létre (és még nem ismert azok metamodellje), akkor a mapping-re lesz szükségünk. A összekötésekhez tartozó, a módszer szempontjából fontos információk megadásához a mapping states elemeit kell használni ábra. Adatstruktúrák kapcsolata 56

58 A 6.1. ábrán látható folyamat egyes lépéseit jelöltük a 6.3. ábrán látható számokkal. Az 1-es jelöli az összekötések létrehozását, a 2-es a összekötés metamodell létrehozását. A 2/a jelenti a metamodellek létrehozását, a 2/b pedig az összekötések hozzáigazítását az újonnan létrehozott metamodellhez Összekötések létrehozása A módszer a 6.4. ábrán látható főbb lépéseken keresztül jut el a végső összekötési javaslathoz: A beadott forrás- és célmodellhez először legyártunk egy kezdeti párosítást az elemek között. Megtörténik a kapott párosítások mintaillesztéses alapon történő terjesztése. Végül alapul véve az összes párosítást (kezdeti, illetve terjesztett) létre hozzuk a modellek közti összekötéseket ábra. Az összekötések létrehozásának folyamata Kezdeti párosítások létrehozása A kezdeti párosítás létrehozása a 6.5. ábrán látható 2 fő lépésre bontható. Először létrejön a forrás- és a célelemek között egy teljes párosítás, ezután egy szűrési lépés eredményeként előáll a kezdeti párosítás ábra. A kezdeti párosítások létrehozásának folyamata Vegyük észre, hogy az általunk javasolt módszer itt lényegesen eltér a SF-nál. Míg a SF minden kezdeti hasonlóságértéket figyelembe vesz a végső összekötés létrehozásánál és csak a folyamat végén történik meg a szűrés, addig a mi megközelítésünkben már a kezdeti értékeken történik meg a szűrés és ezekből (a már megszűrt) elemekből építjük fel a végső összekötéseket. Ennek köszönhetően már diszkrét értékekkel (párosításokkal) dolgozunk és ezáltal lényegesen általánosabb terjesztő logikát valósíthatunk meg a mintaillesztések alkalmazásával. Megj.: A SF esetében azért nem alkalmazható akármilyen mintaillesztésen alapuló terjesztési logika, mert a terjesztés során a hasonlóságértékek összeadódnak és ezáltal sokszor előnyben részesít bizonyos elempárokat, aminek következtében nem adna helyes eredményt. 57

59 A hasonlóságértékeket tartalmazó teljes párosítás létrehozása A SF ajánlásához hasonlóan a modellelemek közti hasonlóságértékek meghatározásához különböző, a 3.2. részben bemutatott karakterlánc-hasonlósági metrikákat fogunk alkalmazni. Az eddigi tapasztalataink alapján egyetlen metrika használatával nem lehet kielégítő szűréseket alkalmazni a későbbiekben. Éppen ezért a hasonlóságértékeknél két metrika (a részben bemutatott Levenshtein és a részben bemutatott Smith-Waterman) kerül tárolásra, hogy a szűrést később precízebben elvégezhessük ábra. Példa forrás- és célmodell Tekintsük a 6.6. ábrán látható példamodelleket, amelyek a 2.1. részben bemutatott O/R leképezéshez tartozó példák egy-egy összetartozó részletét tartalmazzák. Példaként megadtuk a 6.1. táblázatban a példamodellek nevei közti összes hasonlóságértéket. A per jel előtt a Levenshtein szerinti, a per jel után pedig a Smith-Waterman szerinti hasonlóságértéket tüntettük fel táblázat. Hasonlóságértékek Lev / S-W tcustomer id cfavourite custmoer 0.89 / 1 0 / / VIPcustomer 0.72 / / / 0.1 favourite 0 / / / 1 A hasonlóságértékek szűrése Ebben a lépésben az előbb keletkezett teljes párosításból kell kiszűrni azokat a párokat, amelyek nagy valószínűséggel a tényleges összekötés részei. Ehhez a következő feltételeket alkalmazzuk: Ha a rövidebb név hossza 4-nél kisebb, akkor a S-W legyen 1, egyébként pedig a S-W legyen nagyobb, mint 0.3 és a Lev legyen nagyobb, mint Megj.: A 4-nél rövidebb neveknél azért kötjük ki a S-W 1 voltát, mert ez pontosan azt a feltételt jelenti, hogy teljes tartalmazás áll fenn a nevek között. Márpedig, ha ilyen rövid neveknél nincsen teljes tartalmazás, nyugodtan feltételezhetjük, hogy nem hasonlóak. Megj.: Elképzelhető, hogy adott esetekben egyéb szűrő függvényre lehet szükségünk, éppen ezért lehetőség van saját függvény megalkotására. Megj.: az általunk használt szűrő feltétel és az abban szereplő határértékek számos kísérlet eredményeként születtek meg és a legtöbb esetben megfelelő szűrést biztosítottak. Ha a 6.1. táblázat értékeire elvégezzük a fenti szűrést, akkor a 6.7. ábrán látható kezdeti párosításokat fogjuk eredményül kapni. A 6.7(a). ábrán egyszerű vonalként jelöltük az összekötéseket, a 6.7(b). ábrán pedig felvettük a ténylegesen tárolásra kerülő elemeket. 58

60 (a) Egyszerű, vonalas ábrázolás (b) initm típusú elemek felvételével 6.7. ábra. A példa kezdeti párosításokkal Párosítások terjesztése A párosítások terjesztése, mint azt már korábban is említettük, mintaillesztések segítségével, gráftranszformációs szabályok alkalmazásával történik. Ennek köszönhetően a SF algoritmusban használt terjesztéseknél sokkal általánosabbakat is készíthetünk. Esetünkben a hasonlóságértékek terjesztése felfogható úgy, mint egy nagyon egyszerű transzformáció: A kezdeti összekötésekből kell transzformációs szabályokat alkalmazva további (értelmes) összekötéseket generálnunk. A célunk tehát olyan terjesztési szabályok megalkotása, amelyek használatával minél több további hasznos párosítás generálódjon a kezdetiekből kiindulva. Terjesztési szabályok Míg a kezdeti párosítások létrehozásánál a modellekben rejlő nevekből informálódtunk, az összekötések terjesztésénél a modellek struktúrájában rejlő információra fogunk alapozni. Az eddigi tapasztalataink alapján a következő struktúrából adódó általános feltételezésekre építhetünk a terjesztéseknél: Ha egy S1 forráselem össze van kötve egy T 1 célelemmel, akkor S1 nagy valószínűséggel össze van kötve T 1 tartalmazott elemeivel. Megj.: Ezen a feltételen a későbbiekben még pontosítunk. Ha egy A elem össze van kötve egy B elemmel, akkor az A-t és a B-t tartalmazó elemek is nagy valószínűséggel össze vannak kötve. A fenti feltételezéseket felhasználva már készíthető egy jól működő, általánosan használható terjesztő modul, ugyanakkor számos transzformáció-csoportra készíthetőek további, speciális feltételezések (például hasonló metamodellekkel rendelkező transzformáció esetében ki lehetne használni a metamodellek hasonlóságát), hogy azáltal is pontosabbá váljon a terjesztés. A különböző terjesztési feltételezések és az azoknak megfelelő transzformációs szabályok megadása akár egy kisebb kutatásnak is témát adhatna, a leírásban ezzel csupán csak a módszer bővíthetőségére szerettünk volna utalni. Példaként nézzük meg, hogy a fenti feltételezésekből hogyan készíthetünk gráftranszformációs szabályokat. Tekintsük az első feltételezést és az annak megfelelő gráftranszformációs szabályt, amit az a 6.8. ábrán láthatunk (megj.: a részben bemutatott rövidített jelölést használjuk a szabály grafikus megjelenítéséhez). A 6.8(a). ábrán pontosan a fenti feltételezés van formalizálva, miszerint ha az S1 59

61 (a) Kezdeti szabály (b) Javított szabály (c) Végső szabály 6.8. ábra. Egy terjesztési szabály grafikus reprezentációval forráselem össze van kötve T 1 célelemmel M1 párosításon keresztül és T 1-nek létezik T 2 tartalmazott eleme, akkor hozzunk létre egy új, terjesztett M2 elemet S1 és T 2 között. Továbbá állítsuk be az újonnan keletkezett M2 párosítás from relációját M1-re. Mivel ez a szabály még azokhoz a célelemekhez is létrehozna új párosítást, amelyek már össze vannak kötve forráselemmel, szükség van a szabály apró kiegészítésére: Ha T 2-höz tartozik egyéb M3 párosítás, akkor ne hozzunk létre új M2-t. A 6.8(b). ábrán látható negatív feltétel pont ezt a kiegészítést írja le. Ez a szabály még mindig nem egészen pontos, mivel hogyha T 2 célelem az M3 összekötés révén pont egy olyan S2-vel van összekötve, ami meg pont T 1-gyel van összekötve, akkor mégis meg kéne engedni a terjesztést. Ezt formálisan a 6.8(c). ábrán látható második negatív feltétellel tudjuk kikötni, ami ha illeszkedést talál, meghiúsítja az előbbi negatív feltétel illeszkedését, ami viszont a teljes minta elfogadását fogja eredményezni. A szabályok alkalmazása A gráftranszformációs szabályokat egyszerűen a VIATRA2 keretrendszerben a részben bemutatott módon tudjuk futtatani a modellünkön. A futtatás eredményeként az eddig csak kezdeti párosításokat tartalmazó modellben megjelennek az esetleges terjesztett párosítások is. A terjesztés abbahagyható, ha nem jelenik meg újabb párosítás. Példaként a 6.9. ábrán feltüntettük, hogy milyen terjesztett összekötéseink keletkeznek ha a 6.7(b). ábrán látható modellen a 6.8(c). ábrán látható terjesztési szabályt alkalmazzuk Összekötések létrehozása Eljutottunk a 6.4. ábrán látható utolsó fázishoz, amikoris a kezdeti- és terjesztett párosításokat felhasználva létrejönnek a célelemek egy halmazát forráselemek egy halmazának megfeleltető végső össze- 60

62 6.9. ábra. A példa terjesztett párosításokkal kötések ábra. A végső összekötések létrehozásának folyamata A folyamat a ábrán látható két fő lépésre bontható. Első lépésben létrehozzuk a segédösszekötéseket, amelyek felhasználásával a második lépésben már előállítjuk a végső, javasolt összekötéseket. Segédösszekötések létrehozása A segédösszekötés létrehozásakor olyan auxm típusú elemek jönnek létre, amelyek előállítási módszerüknek köszönhetően pontosan egy darab célmodellbeli elemet tartalmaznak (megj.: tehát n_to_1, vagy 1_to_1 típusúak). A adott elemek létrehozásának algoritmusát a következő VIATRA2 kódrészlettel 1 mutatjuk be: // A szabály létrehozza azokat a segédösszekötéseket, amelyek pontosan egy // célmodellbeli elemhez tartoznak és 1 v. több forrásmodellbelihez. rule createauxmapping () = seq { // Végigmegyünk az összes olyan célmodellbeli elemen, // amely relációban áll matching típusú elemmel. forall T below target. models with find ismatched (T) do let CM = undef, TRel = undef in seq{ // Létrejön egy új, auxm típusú elem. new ( matchings. metamodels. mappingstates. auxm( CM) in matchings. models );... // Bekötjük az egyetlen célmodellbeli elemet. new ( matchings. metamodels.mapping.mapping.tar(trel, CM, T)); } // Végig megyek az adott célmodell összes összekötésén és bekötöm // azokat a "from" relációval, ill. a hozzájuk tartozó összes // forrásmodellbeli elemet is bekötöm az új elemhez a "src" relációval. forall M below matchings. models, S below source. models with find ismatched2 (S, T, M) do let SRel = undef, FRel = undef in seq{ new ( matchings. metamodels.mapping.mapping.src(srel, CM, S)); new ( matchings. metamodels. mappingstates.auxm.from(frel, CM, M)); } 1 A közölt algoritmus nem tartalmaz minden információt, csak a megértéshez szükséges részek szerepelnek benne. Például a multiplicitások átállítását teljesen kihagytuk. 61

63 } Az algoritmus során egyszerűen összehúzzuk minden célmodellbeli elemhez a hozzá tartozó párosításokat egyetlen segédösszekötést létrehozva. Ez a segédösszekötés ezentúl magában foglalja az adott párosításokat és a from relációk felhasználásával tárolja, melyek ezek az ( összehúzott ) párosítások. A ábrán bemutatjuk, hogy a példamodelleken milyen segédösszekötések fognak keletkezni, ha lefuttatjuk a fenti algoritmust. Az ábrán az áttekinthetőség kedvéért nem tüntettük fel a from relációkat, de a teljesség kedvéért írásban megadjuk: from relációval az a1-hez hozzá van kötve az i1 és az i2, az a2-höz a p1 és a p2, az a3-hoz pedig az i ábra. A példa segédösszekötésekkel A segédösszekötések létrehozása követhetőbbé és kezelhetőbbé teszi a végső összekötések létrehozását, továbbá a segédösszekötések célmodell felöl történő létrehozása szükséges ahhoz, hogy biztosítsuk az 5.2. részben a referenciamodellre(összekötésre) tett 3. feltevés azon részét, miszerint a célmodellbeli elemek pontosan egy referencia elemmel lehetnek csak összekötve (megj.: azt viszont itt nem tudjuk biztosítani, hogy ténylegesen minden célmodellbeli elem össze legyen kötve a referenciaelemmel). Végső összekötések létrehozása A végső összekötések létrehozásánál jönnek létre az végső, finalm típusú összekötések, amelyek már tetszőleges számú forrás és szintén tetszőleges számú célelemet kötnek össze. Tehát multiplicitásuk már tetszőleges lehet (1_to_1, 1_to_N, N_to_1, N_to_N). Az alábbi VIATRA2 kódrészletben bemutatjuk az algoritmus vázát: // Bemenetként megadunk egy AuxM típusú elemet. // A szabály megvizsgálja, hogy van-e olyan FinalM típusú elem, // amihez pontosan azok a forráselemek tartoznak, mint amik AuxM-hez. // Ha talált ilyen elemet, akkor azzal visszatér SimFM-ben, // ha nem, akkor SimFM = undef-fel tér vissza. rule isexistfinalmatcingsimilartoaux (in AuxM, out SimFM ){... } // A szabály létrehozza a végső összekötéseket. rule createfinalmapping () = seq{ // Végigmegyünk az összes AuxM típusú elemen. forall AuxM below matchings. models with find isauxm( AuxM) do let SimFM = undef in seq{ // Lekérdezzük, hogy van-e olyan finalm típusú elem, amihez pontosan // ugyanazok a forráselemek tartoznak. call isexistfinalmatcingsimilartoaux ( AuxM, SimFM ); // Ha nincs "hasonló" FinalM elem, akkor létre kell hozni. if ( SimFM == undef) let NewFM = undef in seq{ // Letrejön az új finalm elem. new ( matchings. metamodels. mappingstates. auxm( NewFM) in matchings. models ); // Bekötöm NewFM-nek az AuxM-hez tartozó célelemet... // Bekötöm NewFM-nek from relációval 62

64 // AuxM összes from-hoz tartozó elemét... } // Bekötöm NewFM-nek az AuxM összes forráselemét... } } // A SimFM a "hasonló" elem, hozzá kell kötni a szükséges elemeket else seq{ // Bekötöm SimFM-nek AuxM-hez tartozó célelemet.... } // Bekötöm SimFM-nek from relációval // AuxM összes from-hoz tartozó elemét... Az algoritmus során a segédösszekötések gyártásához hasonlóan, itt is egyfajta összehúzást végzünk a segédösszekötéseken és így áll elő az eredmény. Az összehúzás során most segédösszekötésekből indulunk ki, amelyek mindegyikéhez létrehozunk egy végső összekötést, amelybe olyan további segédösszekötéseket húzunk össze, amelyekhez ugyanazon forráselemek tartoznak. Az algoritmus során végigmegyünk minden segédösszekötésen és megvizsgáljuk, hogy létezik-e már olyan végső összekötés, amelyhez ugyanazok a forráselemek tartoznak (a továbbiakban nevezzük ezt hasonló-nak), mint a vizsgált segédösszekötéshez. Az isexistfinalmatcingsimilartoaux (in AuxM, out SimFM) szabály megnézi, hogy létezik-e már a bemenetre adott AuxM-hez hasonló végső összekötés és ha létezik, akkor visszatér vele a SimFM kimeneti változóban, ha nem akkor undeffel tér vissza. Ezek után ha nem találtunk hasonló elemet, akkor létre kell hozni egy új végső összekötést, aminek a from, src és tar relációit a vizsgált segédösszekötésről le kell másolni. Ha pedig találtunk, akkor bele kell húzni az éppen vizsgált segédösszekötést, ami jelen esetben annyit jelent, hogy át kell másolni a from relációit és a tar relációját (a src reláció a hasonlóság miatt megegyeznek) ábra. A példa a végső összekötésekkel A ábrán feltüntettük, hogy milyen végső összekötéseink keletkeznek, hogyha a ábrán látható segédösszekötésekből indulunk ki. Az ábrán az áttekinthetőség kedvéért nem tüntettük fel a from relációkat, de a teljesség kedvéért írásban megadjuk: from relációval az f1-hez hozzá van kötve az i1, i2, p1 és a p2, az f2-höz pedig az i Az összekötések metamodelljének létrehozása Eljutottunk a 6.1. ábra második lépéséhez. A legenerált összekötésekhez meg kell alkotni azok metamodelljét. Vegyük észre, hogy esetünkben egyfajta visszafele irányuló gondolkodásra van szükség, ugyanis az esetek nagy többségében először szokás megadni egy modell struktúráját leíró metamodellt és ezt használva szokás a modell felépítéséhez nekikezdeni. Nekünk most rendelkezésre áll egy modell és ehhez kell a struktúráját jellemző legspeciálisabb metamodellt megalkotni. A legspeciálisabb jelző azért 63

65 fontos, mert például a 6.2(a). ábrán látható modell is metamodellje az összekötéseknek, viszont csupán nagyon általános struktúrabeli tulajdonságokat közöl A metamodell létrehozása A metamodell létrehozásánál olyan elemek fognak keletkezni, amelyek a mapping típusú elem (pontosabban 1_to_1, 1_to_N, N_to_1, vagy N_to_N típusú elemek közül egy) leszármazottjai lesznek. Az algoritmus elve nagyban hasonlít a végső összekötések létrehozásánál alkalmazottakhoz, miszerint végigmenve a végső összekötéseken ugyanúgy megvizsgáljuk, hogy létezik-e már annak megfelelő metamodellbeli elem. Ha nem létezik létrehozunk egyet, ha pedig létezik, akkor első körben nem csinálunk semmit, ugyanis megvan már a megfelelő meta-elem, amihez majd az adott összekötés tartozni fog. A megfelelő ebben a kontextusban azt jelenti, hogy a metamodellbeli elemnek ugyanazok a forrás- és célelemeknek a típusai, mint a vizsgált végső összekötésnek (megj.: ez kell ugyanis ahhoz, hogy a 6.3. ábrán látható 2/b pontnak megfelelően, az adott meta-elemből tudjuk később példányosítani az adott végső összekötést). Az algoritmus vázát most is VIATRA2 kódrészletként adjuk meg. // Bemenetként megadunk egy finalm típusú elemet. // A szabály megvizsgálja, hogy létrehoztunk-e már olyan meta-elemet // amihez pontosan azok a TÍPUSÚ forrás- és célmodellbeli elemek tartoznak, // mint amik FinM-hez. // Ha talált ilyen elemet, akkor azzal visszatér MM-ben, // ha nem, akkor MM = undef-fel tér vissza. rule isexistmetamatcingsimilartofinal (in FinM, out MM){... } // A szabály létrehozza a meta-elemeket. rule createrefmetamodel () = seq{ // Végigmegyünk az összes finalm típusú elemen. forall FinalM below matchings. models with find isfinalm ( FinalM) do let MM = undef in seq{ // Lekérdezzük, hogy van-e már megfelelő meta-elem call isexistfinalmatcingsimilartoaux ( FinalM, MM); // Ha nincs "megfelelő" meta-elem, akkor létre kell hozni. if ( MM == undef) let NewMM = undef in seq{ // Letrejön az új meta-elem. new ( matchings. metamodels.mapping.mapping(newmm) in matchings. metamodels. refmetamodel ); // Bekötöm NewMM-be a szükséges elemeket a forrás metamodellből.... } // Bekötöm NewMM-be a szükséges elemeket a cél metamodellből.... } } // Az MM a "megfelelő" elem, // a létrehozást illetően nincs semmi dolgunk else seq{ } Példaként ha a fenti algoritmust a ábrán látható végső összekötésekre elvégezzük, akkor a ábrán látható referencia/összekötés metamodellt fogjuk eredményül kapni. Az ábrán az öröklést úgy jelöltük, hogy az ősosztályt szögletes zárójelek között szerepeltettük az adott leszármazott elemnél. 64

66 6.13. ábra. A példában generált összekötések metamodellje Az összekötéseknek a metamodellhez való igazítása A 6.3. ábrán 2/b-vel jelezett utolsó lépés, hogy a meglévő összekötéseket az általános mapping metamodell helyett az előbb létrehozott speciálisabb refmetamodel metamodellhez igazítsuk (pontosabban fogalmazva beállítsuk a megfelelő típusokat az újonnan létrehozott referencia metamodell elemeire). Az elemek típusának beállítása A legegyszerűbben ezt úgy tehetjük meg, ha a referencia metamodell létrehozása közben egyben beállítjuk a szükséges öröklési relációkat. A fenti VIATRA2 kódban ez a következő minimális módosításokat jelenti: (i) Ha MM == undef (tehát új meta-elemet hozunk létre), akkor be kell állítani, hogy a FinalM típusa legyen az újonnan létrehozott NewMM. (ii) Ha MM!= undef (tehát már van MM megfelelő elem), akkor FinalM-nek ezt a már meglévő MM meta-elemet kell típusnak beállítani. A relációk típusának beállítása A fenti típus átállítást a relációkra (src és tar) is el kell végezni, azonban ekkor nem mindig triviális a típusok beállítása. Ha a referencia metamodellbeli elem minden egyes forrás- és cél metamodellbeli elemre mutató relációját egyértelműen meghatározza a referált elem típusa, akkor a relációk típusának meghatározása egyértelmű, tehát hasonlóan a fentiekhez elvégezhető (ilyen például a ref2 meta-elem a ábrán). Ha viszont a relációkat a referált típusok nem határozzák meg egyértelműen, akkor további műveletek szükségesek (ilyen pl. a ref1 meta-elem a ábrán, mivel a class_1 és a class_2 relációi közül nem lehet a forráselem típusa alapján különbséget tenni, ugyanis mind a kettő a class típusra referál). Az (i) esetben (mivel ez az első típus-példány egyeztetés) akárhogyan elvégezhetjük a típusok beállítását az azonos típusú elemekre referáló relációkra is. A jobb szemléltetés érdekében tekintsük a ábrán látható példát. A 6.14(a). ábrán látható az előállt végső összekötés, a 6.14(b). ábrán pedig az összekötésekhez generált metamodell. A modellen pirossal feltűntettük azokat a típus beállításokat, amelyek gond nélkül elvégezhetőek. Feltételeztük, hogy f1 vizsgálata közben jött létre a ref1 elem, így f1-nél az (i) eset állt fenn, tehát önkényesen megválaszthattuk a relációk típusát (esetünkben column1-et és column2- t). Továbbá f2 esetén is beállíthattuk a table_1 típust, mivel az egyedüli table elemre referáló reláció. A nehézségek ezek után jönnek, ugyanis el kell dönteni, hogy f2-ből melyik reláció típusa legyen column_1 és melyik column_2. Valami alapján el kell döntenünk, hogy melyek a transzformáció szempontjából logikailag összetartozó párok az (id_c, kind_c) és a (id_p, kind_p) csoportok között. Ehhez újból alkalmazhatjuk a név-hasonlósági metrikákat, ugyanis szerencsés esetben a logikailag összetartozó elemek nevei mutatnak némi hasonlóságot. Vegyük észre, hogy itt messzemenően egyszerűbb feladatot kell megoldani, mint az összekötések létrehozásánál, ugyanis két azonos elemszámú halmazon kell megtalálni a legvalószínűbb párosítást. Tekintettel a halmazok kis elemszámára vehetjük 65

67 (a) Végső összekötéseket tartalmazó példa (b) Az összekötések generált metamodellje ábra. Példa relációk típusának megadására az összes párosítást és azt a teljes párosítást fogjuk legvalószínűbbnek megválasztani, amelyikben a legnagyobb a hasonlóságértékek összege. Megj.: Elképzelhető, hogy a nevek semmilyen mértékben nem utalnak a összetartozásra, ekkor nincs más, minthogy a felhasználót kérjük meg az összetartozó elemek összerendelésére. A ábrán a teljesség kedvéért bemutatjuk a ábra metamodelljéhez igazított ábrán látható összekötéseket ábra. A példában generált összekötések a metamodellhez szinkronizálva 6.5. Felhasználói módosítások Az összekötések megadása sok esetben igen komplex feladat, így nem biztos, hogy a módszer minden esetben tökéletes eredményeket fog produkálni csupán a struktúrából és nevekből vett információk alapján. Erre egy jó példa, amikor a modellekben néhány, egyébként összetartozó elem teljesen máshogyan van elnevezve valamilyen oknál fogva. A cél, hogy ilyenkor a felhasználó beavatkozásával ugyan, de még mindig jóval egyszerűbben és gyorsabban generálódjanak az összekötések. Egy szélsőséges eset lehet, ha egyáltalán nem generálódik kezdeti párosítás és a felhasználónak a kezdeti összekötéseket kézzel kell megadnia. A módszer ebben az esetben is ott van a háttérben és ilyenkor egyfajta content assist jelleggel támogatja a felhasználó munkáját a metamodell származtatásával, a több forrás- és célmodellt magába foglaló összekötések automatikus létrehozásával, vagy akár a megadott párosítások terjesztésével. A cél tehát egy olyan felhasználói interfész biztosítása, amely olyan információkkal látja el a felhasználót, melyek segítenek gyorsan és jó eséllyel eldöntetni egy létrehozott összekötés helyes voltát, továbbá átlátható és kényelmes felületet biztosítson az esetleges kézi finomítás elvégzéséhez. 66

68 Visszajelzések A felhasználói visszajelzések során tehát olyan tájékoztató jellegű adatokat kell a folyamatosan létrejövő összekötésekről közölni a felhasználóval, melyek különböző aspektusokból, tömör formában jellemzik azokat. A lefedetlen célmodellbeli elemek alapján közölt információk Az 5.2. részben a referenciamodellre(összekötésre) tett 3. feltétevés azon részét, miszerint a célmodellbeli elemek pontosan egy referencia elemmel lehetnek csak összekötve, már biztosítottuk az összekötések megalkotásának módjával, viszont semmit nem mondtunk még arról, hogy ténylegesen minden célmodellbeli elem össze legyen kötve a referenciaelemmel. Ezt a feltételt kihasználva megadhatjuk a lefedetlen (összekötésben nem szereplő) összekötéseket, mert azoknál biztosan mondható, hogy meg kell még adni a szükséges összekötést. A metamodell alapján közölt információk A metamodell azon felül, hogy szükséges az MTBE további fázisaihoz, önmagában nagyon sok hasznos információt tartalmaz az összekötésekről Nagyon tömör, mégis számos információt hordoz magában, hogy egy bizonyos metamodellbeli elemnek hány példánya létezik az összekötések között. Ezek alapján például a felhasználónak gyanússá válhatnak olyan metaelemek, amelyeknek kirívóan kevés (esetleg csak egyetlen) példánya van és korrigálhat az adott összekötéseken. Szintén tömör információ a metaelemek multiplicitása. Ezek alapján olyan esetleges helytelen összekötések szűrhetők ki, amelyek multiplicitása a vártakkal nem egyező. Például a 2.1. részben bemutatott O/R transzformáció esetében helytelen, ha N_to_1-, vagy N_to_N-es multiplicitású összekötések keletkeznek. Kilistázhatjuk az egyes metaelemekhez tartozó összekötés példányokat, hogy ezáltal a felhasználó ellenőrizze, hogy az egyazon típusú összekötések ténylegesen logikailag összetartoznak-e. Ez ugyan nem jelent tömör információt, mégis jobban követhető, mintha kategorizálás nélkül kéne az összekötéseket ellenőriznünk Felhasználói beavatkozás A felhasználói beavatkozások lehetőségének megadása során ügyelnünk kell arra, hogy lehetőleg minimalizáljuk a beavatkozási pontok számát, de ezek használatával akármilyen fontos változtatás elvégezhető kell legyen. Ahol nem szükséges beavatkozás Először ejtsünk szót arról, hogy hol nem szükséges a felhasználó kézi beavatkozás. Az párosításoktól eltérő összekötések (auxm és finalm), illetve a metamodell kézi változtatása nem szükséges, mivel azok teljes mértékben automatikusan és determinisztikusan generálódnak a kezdeti és a terjesztett párosításokból. Ez azért kényelmes a felhasználó számára, mert hogyha szükséges is az esetleges beavatkozás, elegendő csak az egyszerű párosításokat módosítani. Módosítási lehetőségek A felhasználó a from relációnak köszönhetően bármely összekötéshez megkaphatja az azoknak megfelelő elemi párosításokat, így azokon kényelmesen és egyszerűen elvégezheti a szükséges módosításokat (esetleges törlést, vagy újabb párosítás felvételét). 67

69 Fontos beavatkozási pont még a terjesztési modul, amelyben lehetőség nyílik a felhasználásra kerülő terjesztési minták kiválasztására, továbbá lehetőség van további, egyéb forrásból 2 származó minták megadására Példa Rövid példaként tekintsük a 6.6. modellekhez generált ábrán látható metamodellt. Ez alapján a 2.1. részben bemutatott O/R transzformációinak ellent mond a ref1 metaelem, mivel két osztály tartozik hozzá. Ezáltal a felhasználó kézzel kitörölheti a helytelen i2, p2 párosításokat (vagy elegendő csupán az i1-et törölni és a from relációnak köszönhetően törlődik az abból terjesztett p1 is). Megj.: Ez az eset egy nagyon jó példája annak, amikor elengedhetetlen a felhasználói beavatkozás, ugyanis a generált összekötés egy másik szemléletben jogos lehetne, amikor minden osztályt (így nem csak az ősosztályt, hanem az összes gyereket) hozzákötjük a szükséges célelemekhez Kapcsolódó munkák A legnagyobb koncepcionális hasonlóságot a [8] cikkben bemutatott megközelítés mutatja. Az általuk úgynevezett weaving model-lek generálása a matching transformation használatával közeli viszonyban van az általunk bemutatott összekötések generálásával. Továbbá a weaving model egyfajta specifikációként használatos modelltranszformáció szabályok generálásához. A [8] cikkben ezt a HOT (higherorder transformation)-nel kivitelezik, míg esetünkben az ILP-t használjuk a szabálygeneráláshoz. A két megközelítés célját tekintve szinte teljesen azonosnak tekinthető, ugyanakkor az összekötések megalkotása nagymértékben eltérő módon megy végbe. A [8] esetében kezdetben minden potenciális összekötést létrehoznak és ezután eliminálják az alacsony prioritású összekötéseket, végül pedig elrendezik az összekötéseket az úgynevezett link rewriting technikával. A mi megközelítésünk ezzel szemben fordított irányból közelíti meg a problémát: először egy minimális kezdeti összekötés halmazból indulunk ki és ezen halmazt egészítjük ki fokozatosan egyre összetettebb összekötésekké modelltranszformációs szabályok használatával. A legnagyobb előnye ennek a módosításnak, hogy a mi összekötés generátorunk nagy modellekre is jól fog teljesíteni, ugyanakkor elképzelhető, hogy nagyobb eséllyel generálódnak helytelen összekötések. A [8] cikk végső fázisában megalkotott final weaving model még mindig általános lesz abban az értelemben, hogy az általános metamodellből lesz példányosítva, míg a mi végső összekötésünk a transzformációhoz igazított mapping metamodel-ból lesz példányosítva, ezáltal az adott forrás- és célnyelvhez lesz specializálva. Úgy látjuk, hogy ez egy jelentős előny, ami megkönnyíti a tervező munkáját, végül pedig ezáltal és az ILP használatával kiküszöbölhetjük a kézzel írott higher-order transformation részt a transzformációs szabályok előállításához, ami a [8] esetében szükséges ahhoz, hogy a weaving model-ből transzformációs szabályokat gyártsanak Összegzés A fejezetben részletesen ismertetésre került egy új megközelítés, amely használatával fél-automatikus módon generálhatunk modellek közti összekötéseket. A bemutatás során megadtuk a módszer által használt architektúrát, adatstruktúrát, illetve megadtuk a végső összekötés előállításához szükséges lépéseket, ezek algoritmusát. Bemutattuk a metamodell megalkotásához használt algoritmust, továbbá az összekötés típusainak meghatározásának problémáját és ennek megoldását. A fejezet végén megadtuk azokat az eljárásokat, amelyekkel támogatni tudjuk a felhasználót a javasolt összekötés módosításában. 2 Ez lehet például egy adott transzformáció-csoportra jól működő, már megírt terjesztési minta 68

70 7. fejezet Modelltranszformáció példák alapján az Induktív Logikai Programozás használatával A fejezetben bemutatjuk, hogyan valósul meg a kontextusok automatikus előállítása az induktív logikai programozás használatával, továbbá kitérünk azokra a Aleph specifikus beállításokra is, amelyeket az eszköz számára szintén meg kell adni a háttértudáson és a pozitív, ill. negatív példákon kívül. A fejezet végén részletesen kitérünk a módszer koncepcionális korlátaira Automatizálás lépései Ahhoz, hogy az ILP rendszer segítségével tudjuk elvégezni a kontextus analíziseket, a következő műveleteket kell elvégezni egy adott konkrét kontextus megállapítása érdekében: 1. Az összekötött modellekből az ILP rendszer számára beadható Prolog klózokat kell generálnunk, továbbá ezeket az adott célnak megfelelően kell szeparálni háttértudásra, ill. pozitív- és negatív ILP példákra. 2. Az ILP rendszer futtatása az előbbi pontban legyártott háttértudással, ill. pozitív és negatív példákkal. Ennek hatására Prolog következtetési szabályok formájában fogjuk a kérdéses kontextust megkapni. 3. Az eredményül kapott következtetési szabályokat gráftranszformációs szabályokká kell átalakítanunk. A fenti műveleteket a 7.1. ábrán foglaltuk össze Összekötött modellekből Prolog klózok A forrás-, a cél- és a referencia modellek megfelelő Prolog klózok formájában kerülnek megadásra az ILP rendszernek. Egy adott entitás típusát egyoperandusú predikátumként reprezentáljuk, egy adott relációt pedig ennek megfelelően kétoperandusú predikátumként. Példaként megadjuk az ábrán látható forrás- és célmodelleket a megfelelő Prolog klózok formájában. A % jel jelenti a Prolog-ban a megjegyzéseket, így megadhatunk tájékoztató jellegű információkat. Jelen esetben megadtuk, hogy melyik modellről van szó (forrás, vagy cél), illetve a kétoperandusú predikátum argumentumainak típusát. %%%%%%%%%%%%%%%% % Forrásmodell % %%%%%%%%%%%%%%%% 69

71 7.1. ábra. MTBE szabálygenerálása ILP használatával %%%%%%%%%% class %%%%%%%%%%% class( manager ). class( clerk ). %%%%%%%%%% attribute %%%%%%%%%%% attribute ( boss ). %%%%%%%%%% attrs(class,attribute) %%%%%%%%%%% attrs(clerk,boss ). %%%%%%%%%% type(attribute,class) %%%%%%%%%%% type(boss,manager ). %%%%%%%%%%%%%%%% % Célmodell % %%%%%%%%%%%%%%%% %%%%%%%%%% column %%%%%%%%%%% column( clerkboss ). column( mngrid ). column( clerkkind ). column( clerkid ). column( mngrkind ). %%%%%%%%%% table %%%%%%%%%%% table( tclerk ). table( tmngr ). %%%%%%%%%% fkey %%%%%%%%%%% fkey( clerkfboss ). %%%%%%%%%% tcols(table,column) %%%%%%%%%%% tcols( tclerk, clerkid ). tcols( tclerk, clerkkind ). tcols( tclerk, clerkboss ). tcols(tmngr,mngrid ). tcols( tmngr, mngrkind ). %%%%%%%%%% pkey(table,column) %%%%%%%%%%% pkey( tclerk, clerkid ). pkey(tmngr,mngrid ). %%%%%%%%%% fkeys(table,fkey) %%%%%%%%%%% fkeys( tclerk, clerkfboss ). %%%%%%%%%% kcols(fkey,column) %%%%%%%%%%% kcols( clerkfboss, clerkboss ). %%%%%%%%%% cref(fkey,column) %%%%%%%%%%% cref( clerkfboss, mngrid ). 70

72 Alternatív megadása a referencia modellnek A referencia modell az adott használattól függően (hogy éppen mely kontextust akarjuk megtanítani) az előzőekhez képes eltérően is ábrázolásra kerülhet. Ha re f a referencia elem típusa, r i egy példány neve és src 1,...src n, ill. tar 1,...,tar m rendre az r i -hez tartozó forrás ill. célmodellek, akkor r i referencia elem leírható re f (r i,src 1,...,src n,tar 1,...,tar m )-vel. A részben a referencia metamodellre tett feltételezésünk (miszerint egy modellbeli referencia elemet egyértelműen meghatároznak a hozzá tartozó forrás-, ill. célmodellek) szerint egy referencia elemet meghatározhatunk a hozzá tartozó forrás-, vagy akar a hozzá tartozó célelemekkel. A fenti jelölés az előbb tett feltételezéssel következőképpen fogalmazható meg: re f (r i,src 1,...,src n,tar 1,...,tar m ) re f (src 1,...,src n ) re f (tar 1,...,tar m ). Ebből nekünk a későbbiek során re f (src 1,...,src n )-ra lesz szükségünk. Példaként megadjuk a r2_1 referencia leírását az általános-, illetve az előbb bevezetett jelöléssel. Megj.: A két jelölés nem keverhető egymással, egy adott kontextus kitalálása esetében vagy az egyiket, vagy a másikat fogjuk használni. % Egy lehetséges megadás (az általános jelölésekkel) ref_cls( r2_1 ). cls2(r2_1,manager ). cls2tab(r2_1,tmngr ). cls2colid (r2_1,mngrid ). cls2colkind ( r2_1, mngrkind ). % Egy másik lehetséges megadás (a forráselemek megadásával) ref_cls( manager ) Referencia elemek kontextusa Információ szeparálása. Minden egyes referencia típushoz tartozó kontextus legenerálása egy adott ILP problémát fog jelenteni. A B háttértudásunk tartalmazni fogja a teljes forrásmodellt, az E + pozitív példák közé bekerülnek az adott referencia típus példányi, az E negatív példák közé pedig az összes többi szóba jöhető elem, amelyet nem tartalmaz az E +. A referencia elemek leírásánál nem az általános, hanem a célelemeket tartalmazó alternatív jelölést fogjuk alkalmazni. Például az ábrán látható modelleket alapul véve a ref_class elem kontextusának megalkotásához a következőképpen kell az információt az ILP-nek beadni: %%%%%%%%%%%%%%%%%% Háttértudás %%%%%%%%%%%%%%%%% class( manager ). class( clerk ). attribute ( boss ). attrs(clerk,boss ). type(boss,manager ). %%%%%%%%%%%%%%%%%% Pozitív példák %%%%%%%%%%%%%%% ref_cls( manager ). ref_cls( clerk ). %%%%%%%%%%%%%%%%%% Negatív példák %%%%%%%%%%%%%%% ref_cls( boss ). Származtatott Prolog szabályok. Ha az ILP-nek beadjuk a fenti példának megfelelően a 2.3. ábra modelljeit használva a ref_class referencia elemhez tartozó bemeneteket, akkor a következő Prolog következtetési szabályt fogja nekünk származtatni: [theory] [ Rule 1] [ Pos cover = 2 Neg cover = 0] cls2(a) :- parent(b, A). A szabály megegyezik az 5.5(a). ábrán látható kontextus egyetlen pozitív feltételével. Az 5.5(a). ábrán látható kontextus nem csak pozitív feltételeket, hanem negatív kényszereket is tartalmaz a kontextust illetően. 71

73 7.4. Negatív kényszerek a kontextusban Egy tipikus modelltranszformációban bizonyos referencia modellbeli elemek létezése függhet bizonyos elemek nem-létezésétől a forrásmodellben. Ezeket különböző kényszerek formájában lehet az ILP rendszerekkel előállítani, melyre a legtöbb ilyen rendszer (mint amilyen az Aleph is) támogatást biztosít. A különböző kényszereket f alse : b1,b2,...,bn formában lehet előállítani az ILP rendszerrel, ahol ugyebár a törszben szereplő bi-k konjunkciója soha nem állhat fenn. Információ szeparálása. Kényszerek megtanítása esetében nincs szükség az információk szeparálására, mivel a pozitív példák is a háttértudást jelentő fájlban fognak szerepelni és éppen ezért negatív példákat sem kell megadnunk. Példaként nézzük meg, hogyan néz ki kényszerek megtanítása esetén a háttértudást a Ref_Cls entitáshoz tartozó kontextus analízisnél. Megj.: A helytakarékosság végett az alábbi demonstrációs kód az ábrát alapul véve készült, viszont az utána következő kényszert a 2.3. ábra modelljeiből generáltuk: %%%%%%%%%%%%%%%%% Háttértudás %%%%%%%%%%%%%%% class( manager ). class( clerk ). attribute ( boss ). attrs(clerk,boss ). type(boss,manager ). ref_cls( manager ). ref_cls( clerk ). Származtatott Prolog szabályok. kapjuk meg: false :- cls2(a), attrs(a, B). false :- cls2(a), parent(a, B). [pos -neg] [0] A ILP rendszer által generált kényszerek a következő formában A kényszerek megfelelnek az 5.3(a). ábrán látható kontextus negatív kényszereinek. Megj.: Valójában az Aleph rendszer nem csak a fenti kényszereket adja vissza, a fentiek a redundáns kényszerek szűrése után (lásd rész) keletkezett kényszerek Célelemek kontextusa Célelemek kontextusának meghatározására nincsen szükség az ILP használatára, ugyanis ezen kontextusok egyértelműen meghatározhatóak a referencia metamodellből. Például a Table elem kontextusa Prolog következtetési szabályokkal leírva a metamodellből kiolvasva: table(a) :- asc2tab(b, A). table(a) :- cls2tab(b, A) Célrelációk kontextusának analízise Információ szeparálása. Ekkor minden egyes célmodellbeli reláció típushoz meg kell alkotni a hozzá tartozó ILP problémát. A B háttértusába most bekerül a teljes forrásmodell és a teljes referencia modell immár az általános leírást használva. Az E + pozitív példák közé bekerülnek az adott reláció-típus összes példánya, a E negatív példák közé pedig az összes célmodellbeli típushelyes elem párosítás, amelyek nem szerepeltek az E + -ban. Példaként megadjuk az ábrán szereplő modell fkeys relációjához tartozó ILP bemenetet: %%%%%%%%%%%%%%%% Háttértudás %%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%% % Forrásmodell % 72

74 %%%%%%%%%%%%%%%% class( manager ). class( clerk ). attribute ( boss ). attrs(clerk,boss ). type(boss,manager ). %%%%%%%%%%%%%%%%%%%%%%% % Referencia modell % %%%%%%%%%%%%%%%%%%%%%%% ref_cls( r2_1 ). cls2(r2_1,manager ). cls2tab(r2_1,tmngr ). cls2colid (r2_1,mngrid ). cls2colkind ( r2_1, mngrkind ). ref_cls( r2_2 ). cls2(r2_2,clerk ). cls2tab( r2_2, tclerk ). cls2colid (r2_2,clerkid ). cls2colkind ( r2_2, clerkkind ). ref_attr ( r2_3 ). attr2( r2_3, boss) attr2col ( r2_3, clerkboss ). attr2fkey ( r2_3, clerkfboss ). %%%%%%%%%%%%%%%% Pozitív példák %%%%%%%%%%%%%%%%% fkeys( tclerk, clerkfboss ). %%%%%%%%%%%%%%%% Negatív példák %%%%%%%%%%%%%%%%% fkeys( tmngr, clerkfboss ). Származtatott Prolog szabályok. A származtatott Prolog szabályok megadásánál ismét a 2.3. ábra modelljeit választottuk bemeneti modelleknek. A futtatás után a következő szabályokat kaptuk: [theory] [ Rule 1] [ Pos cover = 2 Neg cover = 0] fkeys(a, B) :- attr2fkey (C, B), attr2(c, D), attrs(e, D), cls2tab(f, A), cls2(f, G), parent(e, G). [ Rule 2] [ Pos cover = 2 Neg cover = 0] fkeys(a, B) :- asc2tab(c, A), asc2fkeydst (C, B). [ Rule 3] [ Pos cover = 2 Neg cover = 0] fkeys(a, B) :- asc2tab(c, A), asc2fkeysrc (C, B). Például az első szabály változóinak némi átnevezése után a következő szabályunk adódik, fkeys(tc, FK) :- attr2fkey (R2, FK), attr2(r2, A), attrs(cc, A), cls2tab(r1, TC), cls2(r1, C), parent(cc, C). ami megfelel az 5.5(b). ábrán látható kontextusnak. Ugyanígy a másik két generált szabály is pontosan az 5.5(a). ábrán látható kontextust adja vissza Segédinformációk generálása A teljesség kedvéért bemutatjuk, hogy lehet az ILP használatával az 5.7. részben bemutatott ancestor segédinformációt előállítani. Információ szeparálása. Az 5.8. ábra alapján (emlékeztetőül a szaggatott nyilak jelölik az ancestor relációt) a B háttértudásba mindent megadunk, kivéve a szaggatott nyilakkal jelzett ancestor relációt, az E + pozitív példáknak kerülnek be az ancestor relációk, az E negatív példáknak pedig az összes olyan elem párosítás bekerül, amelyek nem állnak ancestor relációban egymással. 73

75 A származtatott Prolog szabályok. eredményül: [theory] Az ILP rendszer futtatása után a következő szabályokat kapjuk [ Rule 1] [ Pos cover = 4 Neg cover = 0] ancestor (A, B) :- parent(a, B). [ Rule 2] [ Pos cover = 7 Neg cover = 0] ancestor (A, B) :- parent(a, C), ancestor (C, B). [ Rule 3] [ Pos cover = 5 Neg cover = 0] ancestor (A, A). Ez pontosan megfelel az 5.9. ábrán látható szabályoknak. Segédinformáció használata. Miután előállítottuk a szabályt, két lehetőségünk van: A továbbiakban hozzáadhatjuk a kapott szabályt a háttértudáshoz, vagy a szabály segítségével létrehozhatjuk a konkrét relációkat és a kapott modellt elemezzük tovább. A két megközelítés végeredményét tekintve teljesen azonos, mi az első szerint fogunk eljárni, tehát ki fogjuk egészíteni a háttértudást a ancestor (A, B) :- parent(a, B). ancestor (A, B) :- parent(a, C), ancestor (C, B). ancestor (A, A). sorokkal Aleph specifikus részletek A következőkben megadjuk az általunk használt Alpeh számára szükséges eszköz specifikus beállításokat. A leírásban erősen építünk a 4.4. fejezetben leírtakra Determináció deklarációk A determináció deklarációk megadása során megadjuk azokat a klózokat, amelyeket az Aleph felhasználhat a hipotézis megalkotásához. A megadáskor minden szóba jöhető klózt megadunk az általánosságra való tekintettel. Például az fkeys reláció kontextusának megtanítása esetében a determináció deklarációk a következőképpen néznek ki: :- determination ( fkeys /2, attribute /1). :- determination ( fkeys /2, class /1). :- determination ( fkeys /2, association /1). :- determination ( fkeys /2, type /2). :- determination ( fkeys /2, attrs /2). :- determination ( fkeys /2, src /2). :- determination ( fkeys /2, dst /2). :- determination ( fkeys /2, parent /2). :- determination ( fkeys /2, ancestor /2). :- determination ( fkeys /2, attr2 /2). :- determination ( fkeys /2, attr2fkey /2). :- determination ( fkeys /2, asc2tab /2). :- determination ( fkeys /2, asc2 /2). :- determination ( fkeys /2, asc2fkeydst /2). :- determination ( fkeys /2, asc2fkeysrc /2). :- determination ( fkeys /2, cls2tab /2). :- determination ( fkeys /2, cls2 /2). Vegyük észre, hogy a felsorolásban nem szerepelnek olyan referencia elemekből kiinduló relációk (mint például a cls2colid), amelyek biztosan nem szükségesek fkeys-hez tartozó hipotézis megalkotásához. Továbbá vegyük észre, hogy a :-determination(fkeys/2, ancestor/2). sorral jelezzük azt, hogy használjuk ki a segédinformáció adta lehetőségeket. 74

76 Mód deklarációk A mód deklarációk során adjuk meg, hogy a hipotézisben egy adott predikátum milyen módon szerepelhet. Példaként megadjuk az fekys reláció kontextusának megtanításához szükséges mód deklarációka: % A megtanulandó reláció % Mind a két változója bemeneti. % Pontosan egyszer kell felhasználni. :- mode (1, fkeys (+table, +fkey )). % A célmodellből a referencia modellbe kell "eljutni". % Ehhez a célmodellbeli elem bemeneti változó, a referencia elem kimeneti. % A predikátumot pontosan egyszer kell felhasználni. :- mode (1, attr2fkey (- ref_attribute, +fkey )). :- mode (1, asc2tab(- ref_association, +table )). :- mode (1, asc2fkeydst (- ref_association, +fkey )). :- mode (1, asc2fkeysrc (- ref_association, +fkey )). :- mode (1, cls2tab(- ref_class, +table )). % A referencia modellből a forrásmodellbe kell "eljutni". % Ehhez a referencia modellbeli elem bemeneti változó, a forráselem kimeneti. % A predikátumot pontosan egyszer kell felhasználni. :- mode (1, attr2 (+ ref_attribute, - attribute )). :- mode (1, asc2 (+ ref_association, - association )). :-mode (1, cls2 (+ ref_class, -class )). % A forrásmodellben nem tehetünk semmilyen megszorítást. % A legáltalánosabb mód deklarációkat használjuk. % Csupán a típusok szűkítenek keresési téren. :-mode (*, type (+ attribute, -class )). :-mode (*, type(-attribute, +class )). :-mode (*, attrs (+class, -attribute )). :-mode (*, attrs(-class, + attribute )). :-mode (*, src (+ association, -class )). :-mode (*, src(-association, +class )). :-mode (*, dst (+ association, -class )). :-mode (*, dst(-association, +class )). :-mode (*, parent (+class, -class )). :-mode (*, parent(-class, +class )). :-mode (*, ancestor (+class, -class )). :-mode (*, ancestor (-class, +class )). :-mode (*, table (+ table )). :-mode (*, fkey (+ fkey )). :- mode (*, attribute (+ attribute )). :-mode (*, class (+ class )). :- mode (*, association (+ association )) A keresési tér méretét befolyásoló paraméterek Előfordulhat, hogy az Aleph túl sokáig számol, vagy a Constraints learning esetében túl sok redundáns kényszert ad, illetve nem ad olyan eredményt, amit elvárnánk (az utóbbinak persze a rossz példamodell is oka lehet). A fenti esetek kiküszöbölhetők, ha tudatosan állítjuk be az Aleph paramétereit és engedjük azok megváltoztatását szükség esetén. Emlékeztetőül a két paraméter, melyekre szükségünk lehet: Az i, mely az új változók mélységére ad egy felső korlátot. (Alapértelmezésben i = 2) A clauselength, mely az elfogadható klózokban szereplő literálok számára ad felső korlátot. Alapértelmezésben clauselength = 4 Változók keresési mélysége A 7.2. ábrán azt próbáljuk szemléltetni, hogy például az fkeys reláció megtanításánál az Aleph meddig tud elmenni az i paraméter különböző értékei mellett. 75

77 7.2. ábra. Az i paraméter szemléltetése A ábrán látható szabályt nem fogjuk megkapni, ha az i értéke kisebb, mint 3. Ahhoz, hogy a szabályt megkapjuk a default i értéket mindenképpen át kell állítsuk egy 2-nél nagyobb számra. Gondoljuk meg, hogy csak azok a relációk taníthatók meg i = 2 érték mellett, melyek szabályához a forrásmodell elemei között közvetlen reláció van. (A 7.2. ábrán látható fkeys reláció azért nem ilyen, mert a C Class entitás és az A Attribute entitás közé beékelődik még egy Class entitás is.) Látható tehát, hogy az i értékét érdemes lehet elég magasra beállítani és csak akkor csökkenteni, ha túl sokáig tart az eredmények kiszámítása. Literálok maximális száma A 7.2. ábrán látható fkeys reláció szabálya az Aleph szerint a következő volt: fkeys(a, B) :- attr2fkey (C, B), attr2(c, D), attrs(e, D), cls2tab(f, A), cls2(f, G), parent(e, G). Ha megszámoljuk, a literálok száma hét, így ha ennél kisebb értéket adunk meg, nem fogjuk megkapni a kívánt szabályt. Érdemes lehet a clauselength értékét is elég nagyra beállítani. Kivételt képez ez alól, ha kényszereket kívánunk megtanítani, ugyanis ekkor az Aleph kihasználja a clauselength-ben beállított értéket és így rendkívül sok redundáns kényszert kaphatunk. Ilyenkor célszerű lehet kis értékről indulni és ha úgy érezzük nem kaptunk meg minden kényszert, az értéket növelhetjük Koncepcionális korlátok Ahhoz, hogy megállapítsuk a módszer koncepcionális korlátait, elvégeztünk egy komplex esettanulmányt. Az esettanulmány során a [10] hivatkozásban bemutatott transzformációt vettük alapul, amiben egy UML Statechartot, transzformálnak át petri hálóba. Habár a transzformáció olyan szabályokat is tartalmazott, amelyek példák alapján történő generálása a jelenlegi MTBE megközelítéssel koncepcionális korlátokba ütközött, fontos megjegyezni, hogy a nagy komplexitás ellenére a transzformációs szabályok jelentős része automatikus módon példák alapján előállítható. Azért, hogy elkerüljük transzformáció (amúgy sem túl egyszerű) technikai részleteinek bemutatását, a felfedett korlátokat kiragadva a saját kontextusukból, az eddig használt objektum-relációs transzformáción mutatjuk be Nem-determinisztikus transzformáció Tegyük fel, hogy az objektum-relációs leképezésünk azt igényli, hogy az osztályokat az öröklési hierarchiájuk alapján sorrendezzünk azzal a megkötéssel, hogy a sorrendben egy szülő osztály mindig meg kell előzze a hozzá tartozó gyerek osztályokat. Ezek alapján definiálnunk kell egy sorrendet az osztályok között, amihez használjuk például a next relációt. 76

78 A 7.3. ábrán látható egy példamodell, amelyben c1 a c2 és a c3 osztályok szülője, c4 pedig nem áll szülő kapcsolatban az előző osztályok egyikével sem. Egy lehetséges megfelelő sorrend lehet a (c1, c2, c3, c1), de ugyanúgy egy szintén jó sorrend a (c4, c1, c3, c2) is. Ebben az esetben a transzformációnak nem-determinisztikus eredménye adódik. Mindazonáltal egy ilyen szabály két egymást követő lépésből tevődik össze. Példánkban az legelső next reláció generálásához eltérő szabály kell, mint a további next reláció(k) generálásához. Ennek következtében az ILP rendszer használatával az ilyen nem-determinisztikus szabályok nem generálhatók példák alapján ábra. Példa osztály hierarchia Számolás a transzformációban A következő gondot az okozza, hogyha egy transzformációban egyfajta számolást hajtunk végre. Példaként tegyük fel, hogy minden egyes táblához az objektum-relációs leképezésben létre kell hozni egy attribútumot, amely tárolja, hogy hány forrásbeli osztálynak felel meg. A mi esetünkben ez a szám annyi lesz, ahány leszármazott osztálya vannak annak az osztálynak, amiből a táblát képeztük. Ha a 7.3. ábrán látható osztályhierarchiát akarjuk a fenti kiegészítéssel transzformálni, akkor két tábla generálódik, melyek a c1, ill. a c4 osztályhoz tartoznak. A c1-hez tartozó attribútum értéke 3 kell legyen, a c4-é pedig 1. A gondot itt az okozza, hogy ilyen fajta számolás csak akkor lehetséges, ha (i) magasabb rendű logikát használunk, vagy (ii) a mintákat szekvenciálisan hajtjuk végre addig, amíg találunk feldolgozatlan illesztést Változó multiplicitású összekötés A következő problémát az okozza, ha egy referenciaelemhez változó számú forrásmodellbeli elem tartozik. Példaként módosítsuk annyiban az eredeti objektum-relációs leképezést, hogy ne csak az öröklési hierarchiában legfelül álló osztályhoz tartozzon a generált tábla, hanem a leszármazott elemekhez is. Ez olyan összekötés típust fog eredményezni, amelyhez tartozó forráselemek száma nem állandó. Emlékezzünk vissza a 6. fejezet példájához létrehozott a ábráján látható összekötésekre. A létrehozott f1 összekötés pontosan a módosított leképezés logikájához illeszkedik. A változó multiplicitású meta referenciákat (*_to_n) a jelenlegi módszer nem tudja egységesen kezelni, így a logikailag egybe tartozó összekötéseket különbözőként fogjuk kezelni Negatív kényszerek és pozitív feltételek külön generálása A forráselemek kontextus analízise közben problémát tud egyes esetekben okozni az, hogy a negatív kényszereket és a pozitív feltételeket két egymástól teljesen független fázisban generáljuk. Képzeljük el a következő transzformációt: A forrásmodell azon osztályaiból kell a célmodellben például egy táblát létrehozni, amely osztályok (az eddigiekhez hasonlóan) az öröklési hierarchiában legfelül állnak (tehát nincs ősosztályuk) és létezik attribútumuk. Példaként tekintsük a 7.4(a). ábrán látható példamodelleket: A transzformációnak megfelelően csak a customer osztály tartozik referenciaelemhez. A 7.4(b). ábrán látható a fentebb informálisan leírt szabály, amely a példán a ref1 elemet hozza létre. 77

79 (a) Példamodellek (b) A referenciához tartozó szabály ábra. Példa a problémát jelentő referenciára. A szükséges szabályhoz tartozó negatív kényszerek gond nélkül előállíthatóak az ILP rendszerrel, mivel minden egyes pozitív példára teljesülni fog, hogy a pozitív példaként beadott osztálynak nincsen őse. Megj.: Ez annak köszönhető, hogy ekkor az Aleph-nek csak pozitív példákat kell megadnunk. A pozitív feltételek megtanítása közben azonban problémába ütközünk. Tekintsük a példán látható osztályokat. A ILP pozitív példái közé ugyebár csak customer fog bekerülni, míg negatív példaként bekerül a vipcustomer, product és a számunkra problémát okozó book is. Ha az ILP ki is találná a szükséges pozitív szabályt, a negatív példák közt lévő book is illeszkedi fog arra (ugyanis book-nak is van attribútuma), ami a szabály elvetését fogja jelenteni. A probléma áthidalásához a negatív kényszerek és a pozitív feltételek létrehozását valahogyan össze kéne kapcsolni. A legegyszerűbb módja ennek, hogy először hozzuk létre a negatív kényszereket és a pozitív feltételek megtanításánál ezeket a kapott kényszereket felhasználjuk akképpen, hogy az ILP negatív példái közül töröljük azokat, amelyekre a negatív kényszerekre illeszkednek. A példa esetében azokat az osztályokat, amelyeknek van ősük Összegzés A fejezetben bemutattam, hogyan valósítható meg hatékonyan az Induktív Logikai Programozás használatával az MTBE kontextusainak létrehozása. Definiáltam, milyen konverziókat kell elvégeznünk ahhoz a modelleken, hogy azokat az ILP számára beadhassuk, továbbá definiáltam, hogyan kell az információt szeparálni az egyes kontextusok létrehozása esetében. Kitértem a szükséges Aleph specifikus beállításokra, illetve a keresés idejére kiható értékekre. Az utolsó részben bemutattam egy komplex esettanulmány kapcsán előálló koncepcionális korlátokat. A fejezetben leírtak alapján elmondható, hogy az ILP a várakozásunknak megfelelően rendkívül jó eszközként szolgál a szabályok példák alapján történő létrehozásához. 78

80 8. fejezet Implementáció a VIATRA2 keretrendszerben A fejezetben az eddigi fejezetben leírt elméleti alapokra támaszkodva az MTBE implementációját fogjuk részletesen bemutatni. A fejezet központi részében egy olyan általános modul implementációját mutatjuk be, amelynek használatával magasabb szinten lehet a szükséges célelemeket-, ill. célrelációkat létrehozó szabályokat generálni. A bemutatott szabálygeneráló modul akár függetlenül is alkalmazható olyan esetekben ahol valamilyen háttértudást feltételezve különböző szabályok meglétének feltételére akarunk szabályokat megfogalmazni Áttekintés A szabályok létrehozása közben többször kell az összekötött példamodelleket különböző módon háttértudásra és ILP pozitív/negatív példákra szeparálni, de minden egyes esetben az adott problémához ugyanazt az eljárást kell végrehajtani a szabályok létrehozásához. A fenti tény teszi indokolttá egy általános szabálygeneráló modul kidolgozását, melyet általános módon lehet felparaméterezni és ezen felparaméterezés után képes az adott problémához a szükséges szabályokat előállítani. Egy probléma definiálása esetünkben úgy történik, hogy megadunk egy úgynevezett problémamodellt a szabálygeneráló egységnek, amelyből az kiolvassa, hogy mely elemek jelentik a háttértudást, illetve mely elemekhez kell generálni az azokat definiáló szabályokat ábra. MTBE az általános szabálygeneráló modullal A 8.1. ábrán látható, hogy az általános modullal hogyan lehet az MTBE esetében a szükséges szabályokat előállítani. 79

81 Problémamodellek létrehozása: Első lépésben létre kell hozni a szükséges problémamodelleket az összekötött forrás- és célmodellből. Problémamodellt minden olyan esethez létre kell hozni, amikor különböző lesz a háttértudás, így a 7. fejezetben leírtak alapján különböző problémamodellt kell létrehozni például a referencia elemek kontextus analíziséhez és különbözőt a célrelációk kontextusának analíziséhez. Gráftranszformációs szabályok modelljének generálása: Az általános generáló modul létrehozza a megtanulandó elemek létrehozásához szükséges gráftranszformációs szabályok modelljeit. A modellekből a transzformációs keretrendszer által értelmezhető gráftranszformációs szabályok létrehozása: Ebben a lépésben az általános modellből létrehozzuk az adott transzformációs keretrendszer számára beadható gráftranszformációs szabályokat. Megj.: Jelen esetben a VIATRA2 számára értelmezhető vtcl fájlokat fogjuk létrehozni. A továbbiakban az általános szabálygeneráló modul működéséről és konkrét megvalósításáról lesz részletesen szó Általános szabálygeneráló modul 8.2. ábra. Általános szabálygeneráló modul Az általános szabálygeneráló modulnak bemenetként meg kall adni a problémát definiáló problémamodellt, eredményül pedig meg fogjuk kapni azon szabályokat, amelyek a megtanulandó elemekre vonatkoznak. A főbb lépések a 8.2. ábrán láthatóak: 1. ILP problémamodell létrehozása (transzformáció): Egy adott problémamodellből létrehozunk VIATRA2 transzformációval egy úgynevezett ILP problémamodellt, mely modell minden részletes információt tartalmaz ahhoz, hogy abból mát egyszerűen lehessen legenerálni egy konkrét ILP rendszer számára a szükséges fájlokat (jelen esetben az Alpeh számára, de a kódgeneráló egység kicserélésével bármilyen konkrét ILP rendszer is szóba jöhet). 2. ILP rendszer számára értelmezhető fájlok létrehozása (kódgenerálás): Ebben a lépésben létrehozzuk azokat a fájlokat, amiket közvetlenül be lehet adni az adott ILP rendszernek. 3. Prolog szabályok generálása az ILP-vel: Futtatjuk az ILP rendszert és előállnak a szükséges Prolog szabályok. 80

82 4. Prolog szabályoknak megfelelő modell létrehozása (modell generálás): A kapott Prolog szabályokat egy erre a célra megírt importerrel beolvassuk és felépítjük a Prolog szabályokat reprezentáló modell részeket a modelltérbe. 5. Prolog szabályok modelljéből gráftranszformációs szabályokat reprezentáló modellek generálása (transzformáció): Az utolsó lépésben VIATRA2 transzformációval legeneráljuk a kapott Prolog szabályokat tartalmazó modellből a megfelelő gráftranszformációs szabályokat tartalmazó modelleket. Adatstruktúra 8.3. ábra. Adatstruktúra áttekintés Az általános szabálygeneráló modul a 8.3. ábrán látható metamodelleket használja. A Generic Metamodel tartalmazza azokat az elemeket, amelyekkel definiálni tudunk egy problémamodellt. Az ILPproblem Metamodel elemeivel lehet részletesen egy teljes ILP problémát megadni. A GTRule Metamodel szükséges a gráftranszformációs szabályok megadásához. Az ábrán látható még egy metamodell (Model2ILP Mapping Metamodel), amely ahhoz szükséges, hogy a problémamodell- és az ILP problémamodell elemeit szinkronban tartsuk azáltal, hogy egyfajta megfeleltetést hozunk létre az összetartozó elemek között. Ez azért szükséges, hogy a későbbiekben egyszerűen meg tudjuk találni egy adott ILP problémabeli elem megfelelőjét az adott problémamodellben. A 8.3. ábrán az egyes számok jelölik azt, hogy az egyes lépések közben mely modellek jönnek létre, illetve mely modellekben hozunk létre új elemeket. Látható, hogy amikor az 1. lépésben létrehozzuk az ILP problémát definiáló modellt, akkor azzal együtt létrejön a későbbi szinkronizáláshoz szükséges Model2ILPMapping model. A 4. lépésben a Prolog szabályokat reprezentáló modell részeket az ILP problémamodellbe illesztjük be a megfelelő helyre, az utolsó, 5. lépésben pedig létrejön a gráftranszformációs szabályokat reprezentáló modell Problémamodell Ebben a részben részletesen áttekintjük, hogy miképpen lehet egy adott problémát specifikálni a Generic metamodel használatával. Amikor problémamodellről beszélünk, az alatt valójában egy olyan metamodellre kell gondolni, amely elemei a Generic metamodel elemeinek példányai és a metamodellhez 81

83 8.4. ábra. Core metamodel tartozó modellre. Tehát ha adott egy modell a hozzá tartozó metamodellel és abból szeretnénk az általános szabálygeneráló modul számára beadható problémamodellt alkotni, nem kell mást tenni, mint hogy a 8.4. ábrán látható elemekből megfelelően példányosítjuk az adott metamodell elemeit (a modellt változatlanul hagyjuk). A generic metamodel elemei a következő jelentéssel bírnak: A BackgroundEntity és a backgroundrelation példányai jelentik a háttértudás részét képező entitásokat, illetve relációkat. Az auxiliaryrelation is a háttértudás részét fogja képezni, viszont hozzá fel kell venni a relációt definiáló szabályokat is 1. A relationtolearn példányai lesznek azok a relációk, amelyek létrehozásához szükséges szabályokat meg kell majd tanítani az ILP rendszernek, az EntityToLearn példányai pedig azok a speciális entitások, amelyek létrehozásához szükséges szabályokat szintén elő kell állítani. Azért írtuk, hogy speciális entitások, mivel csak olyan entitásokhoz lehet szabály generálni, amelyekbe nem vezet reláció, ezek az entitások csak relációk forrásai lehetnek (a metamodellben azok a relációk, amik az EntityToLearn példányaiból mennek ki, a refrelation példányai lesznek) ábra. Példa probléma modellre Példaként a 8.5. ábrán megadtunk egy olyan metamodellt, amely azt definiálja, hogy a ref_asc, a ref_cls és a ref_attr típusú elemekhez kell szabályokat generálni amihez a ábrán látható további elemeket használhatjuk fel háttértudásként. Megj.: A probléma mellesleg a példaként tárgyalt O/R leképezés azon részét fedi le, amikoris a referencia elemek kontextusát akarjuk meghatározni ILP problémamodell létrehozása Az ILP problémamodell létrehozása esetében valójában nem történik más, minthogy a 7. fejezetben tárgyaltak alapján az eredeti modellből az adott problémának megfelelően létrehozzuk az összes olyan 1 Mivel a VIATRA2 megengedi a relációk közti öröklést is, a VIATRA2 -ban az auxiliaryrelation a backgroundrelation leszármazottja lesz 82

84 elemet immár az ILP doménjében, amire szüksége lehet az ILP rendszernek ábra. ILP probléma metamodellje A 8.6. ábrán látható a teljes metamodell, ami lefed minden lehetséges elemet, ami szükséges az ILP problémamodell létrehozásához. A metamodell gyökér eleme az ILPProblemSet, melyből egy adott ILP problémához egyetlen példány fog létrejönni. Megj.: A névben a set arra utal, hogy ugyan egyetlen ILP problémáról van szó, de ez több elemi ILP problémát foglalhat magába, ugyanis a megtanulandó elemek száma bármennyi lehet. Az ILPProblemSet a következő elemeket fogja tartalmazni: ElementaryILPProblem: Ezen elemek példányai fogják jelenteni az elemi ILP problémákat. Minden egyes megtanulandó elemhez létre fog jönni egy példány. PredicateDeclaration: Prolog predikátumok deklarációjaként szolgáló elem. Egy predikátum deklarációnak van egy neve, tartalmazza az argumentumainak számát (arity) és egy rendezett listát, amely a predikátum attribútumait deklarálja. A predikátum deklarációk a 7.2. részben leírtak alapján generálódnak. Predicate és Rule: Az előbbi elem példányai predikátumokat reprezentálnak, míg az utóbbi példányai Prolog szabályokat. Az ILPProblemSet-nek ezen elemek példányaival adjuk meg a háttértudás egészét (a háttértudás részét képező elemi predikátumokat és az esetleges szabályokat). Az ElementaryILPProblem minden olyan elment tartalmaz, amire az ILP rendszernek szüksége lehet a 7.8. részben leírtak szerint. Tartalmaz mód deklarációkat, determináció deklarációkat, különböző beállításokhoz tartozó elemeket, pozitív, ill negatív példákat az adott megtanulandó elemhez, továbbá a piros 83

85 asszociációkkal megjelölve tartalmazza a későbbiekben generálásra kerülő következtetési szabályokat (inferencerules) és lefedetlen példákat (uncoveredexamples). Kódgenerálás. A kódgenerálás az előző részben bemutatott ILP problémamodell felépítése után egy elég egyszerű feladat. Egyszerűen az adott ILP rendszer szintaxisát használva ki kell íratni megfelelően az egyes elemeket és létre kell hozni az ILP számára közvetlenül megadható fájlokat Prolog szabályok importálása a modelltérbe Miután futtattuk az ILP rendszert, a kapott következtetési szabályokat importálnunk kell a modelltérbe a megfelelő ElementaryILPProblem típusú elem következtetési szabályai közé. Ehhez egyszerű következtetési szabályok esetében Rule típusú elemet kell létrehozni és természetesen a fej, ill. törzs részben szereplő predikátumoknak megfelelően létre kell hozni a szabály teljes modelljét. Kényszerek esetében (lásd 4.5. rész) egy Constraint típusú elemet példányosítunk és egy Rule-hoz képest még be kell állítani a kényszer fókuszát, ami a kényszer törzsében szereplő predikátumok közül az, amelyikre a kényszert generáltuk. Megj.: Ez általában a kényszer törzsében szereplő első predikátum szokott lenni. Miután minden egyes elemi ILP problémához (ElementaryILPProblem) importáltuk a modelltérbe az ILP által generált szabályokat, ill. kényszereket, a modelltérben minden rendelkezésre áll ahhoz, hogy létrehozzuk a szükséges gráftranszformációs szabályokat reprezentáló elemeket Gráftranszformációs szabályok modelljének létrehozása 8.7. ábra. Gráftranszformációs szabály metamodellje Metamodell. A gráftranszformációs modell létrehozásakor a 8.7. ábrán látható metamodell elemeit fogjuk példányosítani. A metamodell elemeinek felhasználásával gráftranszformációs szabályokat tudunk definiálni absztrakt módon. Ahogy az a 2.3. részben is olvasható egy szabály (GTRule) egy előfeltételből (precondition) és egy utófeltételből (postcondition) áll. Mind az előfeltételt, mind az utófeltételt egy gráfminta (GTPattern) reprezentálja, pontosabban annak egy konkrét meghívása (GTPatternCall), amely a gráfmintán kívül tartalmazza az aktuális hívás paraméterlistáját (GTPatternCall.firstParameter). Egy gráfminta egy, vagy több gráftörzsből (BasicGTPatternBody) áll, mely tartalmaz kötelezően egy mintagráfot(patterngraph), illetve opcionálisan pozitív, vagy negatív gráfminta hívásokat (patterncall, 84

86 ill. negativcall). A mintagráf tartalmazza azt a részgráfot az adott modellből, amely a teljes gráfmintát jelenti. Megj.: A mintagráf akár üres is lehet. Ha egy gráfminta több törzsből áll, akkor a teljes gráfminta ezen törzsek vagy-kapcsolatának tekinthető. Modell generálása. Mielőtt részletesen tárgyalnánk a gráftranszformációs szabályok létrehozásának menetét, tekintsük át röviden, hogy milyen információ halmaz áll rendelkezésünkre az eddig megalkotott modelltérben. Minden egyes elemi ILP problémához rendelkezésünkre állnak a kikövetkeztettet szabályok, illetve kényszerek. Ezen szabályok/kényszerek predikátumaihoz, illetve a predikátumok attribútumaihoz a type reláció segítségével megállapíthatjuk az azokhoz tartozó predikátum-, illetve attribútum deklarációkat. A korábbiakban említésre kerülő Model2ILPMapping model segítségével egyszerűen megkaphatjuk egy adott deklarációról, hogy annak pontosan melyik konkrét probléma metamodellbeli elem felel meg. Vegyük észre, hogy ezzel a két lépessel hozzá tudunk egyszerűen jutni ahhoz, hogy egy adott predikátum melyik probléma metamodellbeli elemhez tartozik. Ezek alapján megmutatjuk, hogyan tudjuk a most már csak a probléma- modelltől, ill. metamodelltől függő graftranszformációs szabályokat tartalmazó modellt létrehozni. Ehhez először tekintsük az 1. algoritmust, amely egy szabályhoz fogja létrehozni az annak megfelelő gráfmintát. Tehát a bemenetére adott Rule típusú elemből egy új, a bemeneti szabálynak megfelelő GTPattern típusú elemet fog létrehozni. Algorithm 1 Predikátumból gráfmintát létrehozó függvény R: Egy Rule típusú elem. fun generate_gt_pattern_for_rule(r)= 1: Létrehozunk egy új GTPattern típusú PAT elemet 2: Létrehozunk egy új BasicGTPatternBody típusú BODY elemet és beállítjuk PAT -nek 3: Létrehozunk egy új PatternGraph típusú PG elemet és ezt beállítjuk BODY -nak 4: for all R-rel body relációban álló összes PRED predikátumra do 5: for all PRED összes Attribute típusú AT T R elemére do 6: Legyen MODEL_ENT az AT T R típusához tartozó probléma metamodellbeli entitás 7: Hozzunk létre a PG-ben egy példányt MODEL_ENT -ből AT T R nevével. 8: end for 9: Legyen MODEL_ELEMENT a PRED-hez tartozó probléma metamodellbeli elem 10: if Ha MODEL_ELEMENT reláció then 11: Hozzunk létre egy MODEL_ELEMENT típusú relációt az előbb létrehozott két példány között 12: else 13: Hozzunk létre egy MODEL_ELEMENT típusú elemet tetszőleges egyedi névvel 14: Hozzunk létre az összes MODEL_ELEMENT -ből kiinduló refrelation típusú relációból egy példányt MODEL_ELEMENT -ből egy megfelelő, korábban létrehozott MODEL_ENT típusú elembe 15: end if 16: end for 17: Legyem H_PRED az R-nek a fej predikátuma (head relációval jelzett elem) 18: Létrehozunk H_PRED attribútum láncához egy megfelelő ParameterList láncot és beállítjuk az első elemet PAT -nak firstparameter-re 19: return PAT A generate_gt_pattern_for_rule(r) függvény működésének főbb lépései a következőek: Létrehozzuk egy új gráfmintát az egyetlen törzs részével és abban létrehozunk egy új mintagráfot. (1-3. sorok) Létrehozzuk a mintagráf entitásait egy adott predikátum attribútumaihoz(5-8. sorok) 85

87 Attól függően, hogy a vizsgált predikátumhoz tartozó probléma metamodellbeli elem egy reláció, vagy egy entitás (entitás esetében csak EntityToLearn lehet), létrehozzuk a előbb megalkotott entitások közötti reláció(t/kat). EntityToLearn esetében ez az adott entitásból kiinduló refrelation-ök létrehozását jelenti. (9-15. sorok) A szabály fej predikátumából létrehozzuk a gráfminta formális paraméterlistáját. ( sorok.) Az generate_gt_pattern_for_rule(r) függvényhez hasonlóan szükségünk lesz egy olyan függvényre, amely hasonlóan a szabályokhoz, kényszerekhez hozza létre a megfelelő gráfmintát. Ezt a függvényt külön nem tüntettük fel, mivel működése ugyanaz, mint a szabályok esetében, azzal az apró különbséggel, hogy a mintagráfban ugyanúgy a kényszer törzs részében lévő predikátumok fognak szerepelni, de a fókusszal jelölt kivételével, a formális paraméterlista pedig a fókusszal megjelölt predikátumból fog előállni. Megj.: A gráfminta negatív feltétel jellege majd a meghívásában fog megmutatkozni, ugyanis negatív hívásként fog szerepelni. Ezt a függvényt ami kényszerekből fog gráfmintát előállítani nevezzük generate_gt_pattern_for_constraint(c)-nek, ahol C a bementre adott kényszer. Az előbbiekben bemutatott két segédfüggvény használatával már megadhatjuk azt az eljárást, ami a bemenetére adott elemi ILP problémához legenerálja a problémához tartozó gráftranszformációs szabály modelljét. A 2. algoritmusban megadtuk az eljárás főbb lépéseit. Algorithm 2 Elemi ILP problémához gráftranszformációs szabályt létrehozó függvény ILP: Egy ElementaryILPProblem típusú elem fun generate_gt_rule_for_ilpproblem(ilp)= // Generáljuk a szabály bal oldalát képező gráfmintát, mely csupán gráfminta hívások vagykapcsolatából fog állni. 1: Létrehozunk egy új GTPattern típusú LHS_MAIN_PAT elemet 2: for all ILP minden RULE elemére, mellyel inferencerules relációban áll do 3: Létrehozunk egy új BasicGTPatternBody típusú PB elemet és beállítjuk LHS_MAIN_PAT -nak body-ként 4: if Ha RULE Constraint típusú then 5: Legyen LHS_PAT = generate_gt_pattern_for_constraint(rule) 6: Létrehozunk egy negativecall típusú relációt PB és LHS_PAT között. 7: else 8: Legyen LHS_PAT = generate_gt_pattern_for_rule(rule) 9: Létrehozunk egy patterncall típusú relációt PB és LHS_PAT között. 10: end if 11: end for // Generáljuk a szabály bal oldalát képező gráfmintát. 12: Létrehozunk egy új GTPattern típusú RHS_MAIN_PAT elemet 13: Létrehozunk egy új BasicGTPatternBody típusú PB elemet és beállítjuk RHS_MAIN_PAT -nak bodyként 14: Létrehozunk egy új PatternGraph típusú PG elemet és beállítjuk PB-nak patterngraph-ként 15: Választunk egy tetszőleges RULE elemet ILP inferencerule asszociációval jelzett elemei közül 16: Legyen RULE-nak a head asszociációval jelzett eleme HEAD 17: HEAD elemhez generálunk gráfot a generate_gt_pattern_for_rule(r) függvényben látott módon a PG-ben // A gráftranszformációs szabály létrehozása 18: Létrehozunk egy új GTRule típusú GT R elemet 19: Beállítjuk GT R-nak precondition-nak LHS_MAIN_PAT gráfmintát 20: Beállítjuk GT R-nak postcondition-nak RHS_MAIN_PAT gráfmintát A generate_gt_rule_for_ilpproblem függvény működésének főbb lépései a következőek: 86

88 Létrehozzuk a szabály bal oldalát/előfeltételét jelentő gráfmintát, ami egyszerűen az ILP problémához tartozó szabályok/kényszerek hívásainak vagy-kapcsolatából fog állni. Szabály esetében a mintát egyszerűen meghívjuk, kényszer esetében ez negatív hívás lesz. (1-11. sorok) Létrehozzuk a szabály jobb oldalát/utófeltételét jelentő gráfmintát, ami az ILP problémának egy tetszőlegesen választott szabályának fej részéből fog létrejönni. ( sorok) Végül pedig létrehozzuk a gráftranszfromációs szabályt az előbb generált két gráfmintával, mint előfeltétellel és utófeltétellel. ( sorok) Keretrendszer-specifikus transzformációs szabályok generálása Azután, hogy rendelkezésünkre áll a szükséges gráftranszformációs szabályok absztrakt modellbeli reprezentációja, bármilyen transzformációs keretrendszer számára, az annak megfelelő szintaxis használatával előállíthatjuk a szabályok keretrendszer-specifikus alakját. A VIATRA2 esetében generáljuk a szabályoknak megfelelő (a részben röviden ismertetett) vtcl fájlokat Összegzés A fejezetben bemutattuk a konkrét implementációs megvalósítását a transzformációs szabályok előállításának. Ehhez a leírásban egy általános szabálygeneráló modul bemutatásán volt a hangsúly, aminek a használatával magas szinten lehet a beadott összekötött példamodellekből előállítani a transzformációs szabályokat. A szabálygeneráló modulnál az egyes struktúrákat absztrakt modellek formájában tároltuk, így a megvalósítás jól elkülöníthető (és egyszerűen kiterjeszthető) pontokon épít a konkrét alkalmazott technológiára (gondolunk itt a konkrét ILP rendszerre, ill. a konkrét transzformációs keretrendszerre). 87

89 9. fejezet Esettanulmány A fejezet során átfogó esettanulmányként megalkotjuk az O/R leképezés transzformációs szabályait. Ehhez kiindulunk a kezdeti összetartozó forrás- és célmodellből, amihez az első részben legeneráljuk a szükséges összekötést, a második részben pedig az így keletkezett immár összekötött modell-párból legeneráljuk a szükséges transzformációs szabályokat Összekötés létrehozása A összekötés létrehozása során három különböző elven összekötött modellt fogunk alapul venni, hogy minél több esetet szemléltessünk. Megj.: A szabályok generálásához mind a három modell-párra szükségünk lesz Példamodellek Első példamodell Az első példamodellnek vegyük a 2.3. ábrán látható modellpárost, amelynek a helyes végső referencia modellje az 5.2. ábrán, míg az automatikusan generált végső összekötések a 9.1. ábrán láthatóak. Megj.: A 9.1. ábrán látható összekötésekhez tartozó elnevezések a 6. fejezetben használtakat követik, míg az 5.2. ábrán találhatóak a részben bemutattakat. Viszont vegyük észre, hogy ha az összekötések generálása során helyes összekötések jönnek létre, akkor a nevek kölcsönösen megfeleltethetőek egymásnak. Például a 9.1. ábrán látható ref1 típus megfelel a 2.2. ábrán látható ref_attr típusnak, ill. ref1 elem column_1 relációja megfelel a ref_attr elem attr2col relációjának. A 9.1. ábrán pirossal jelöltük meg azokat a generált összekötéseket, amelyek hibásan keletkeztek (r2-höz tartozó normalcustomer, ill. vipcustomer). Azt hogy ezek hibásan keletkeztek, könnyen kiszúrhatjuk a ref4 metamodellbeli elem multiplicitásáról, ugyanis három forráselemre referál. Ez egyetlen teendőnk a finomítási fázisban, hogy töröljük a két hibásan keletkezett összekötést és megkapjuk a végső helyes összekötést. Második példamodell Második példaként beadott modellpárunk az ábrán látható forrás- és célmodell. Az első körben generált összekötéseket a 9.2. ábrán tüntettük fel. A nem túl szerencsés elnevezések miatt a helyzet ebben az esetben kicsit rosszabb, mint az előzőnél. Két esetben nem tudta megfelelően produkálni az összekötéseket a módszer. Az első helytelen összekötésre a ref5 metamodellbeli elem hívja fel a figyelmet, ugyanis az előző példához hasonlóan egynél több forráselem tartozik hozzá. A második figyelmeztető jel a pár nélkül maradt célmodellbeli tmngr, mngrid, illetve mngrkind elemek. 88

90 9.1. ábra. Generált összekötések az első példához 9.2. ábra. Generált összekötések a második példához A finomítási fázisban tehát le kell törölni a hibásan keletkezett cler elembe mutató összekötést, illetve fel kell venni a hiányzó manger és tmngr párosítást, ugyanis ebből már a terjesztés következtében előáll a másik két hiányzó párosítás. Harmadik példamodell A harmadik példamodellnek egy eddig még nem használt modellpárost fogunk beadni, amelyek forrásmodellje a 9.3. ábrán látható. A forrásmodell a 9.3(a).-, míg a célmodell a 9.3(b). ábrán látható. 89

91 (a) UML modell (b) relációs modell 9.3. ábra. Harmadik példamodell-pár A modellekhez tartozó első körben generált összekötés a szerencsésen elnevezett elemeknek köszönhetően pontosan a szükséges összekötéseket fogja eredményül adni. A szükséges végső összekötést a teljesség kedvéért a 9.4. ábrán láthatjuk Szabályok generálása Az összekötés létrehozása után legeneráljuk a szükséges gráftranszformációs szabályokat. Az esettanulmány során megadjuk a példamodelleket, a kapott Aleph kimenetet és végül az automatikusan generált gráftranszformációs szabályokat Beadott példamodellek A rendszernek pontosan az előbbi három példamodell-párt fogjuk a bemenetére adni. Az első modell volt a kezdeti modell-párosunk, a második azért kellett, mert a kezdeti nem tartalmazott elegendő példát a helyes szabálygeneráláshoz, az új harmadik modell-páros pedig az Association entitásra tartalmaz további példákat. A fenti három példa modellpárokat megadtuk a MTBE-nek az adott névterekbe (A forrásmodelleket a source.models-be, a célmodelleket a target.models-be), utána megadtuk a legenerált (finomított) referencia modelleket is (a ref.models-be) Segédinformáció megtanítása A szabályok generálásához felhasználtunk egy segédinformációt, hogy azáltal kompaktabb szabályokat kaphassunk. A segédinformáció a már sokat tárgyalt ancestor reláció. 90

92 9.4. ábra. Generált összekötések a harmadik példához Az ancestor reláció megtanításához megadtuk az 5.8. ábrán látható modellt, ami után a VIATRA2 legenerálta a ancestor.b-, ancestor.f-, ancestor.n fájlokat. Ezek alapján az Aleph a 7.7. részben már bemutatott szabályokat fogja eredményül adni, amiket segédinformációkként a háttértudásban fogunk felhasználni Aleph fájlok létrehozása Miután megadtuk a fenti modelleket a VIATRA2-nek, az a következő fájlokat generálta: A célmodell relációinak megtanításához szükséges fájlok, ahol a fájl neve: reláció_neve.* cref.b cref.f cref.n fkeys.b fkeys.f fkeys.n kcols.b kcols.f kcols.n pkey.b pkey.f pkey.n tcols.b tcols.f tcols.n A referencia elemekhez tartozó pozitív feltételek megtanításához szükséges fájlok, ahol a fájl neve: referencia_neve _p.* ref_class_p.b ref_class_p.f ref_class_p.n A referencia elemekhez tartozó negatív feltételek megtanításához szükséges fájlok, ahol a fájl neve: referencia_neve _n.b ref_class_n.b Mivel a felhasználó tisztában azzal, hogy a ref_class-on kívül más referencia elem megléte nem köthető negatív kényszerekhez, nem szükséges a ILP felesleges futtatása. 91

93 Aleph futtatása Az Aleph futtatásának eredményeként például az fkeys esetében a következő Prolog szabályokat adta kimenetére: [ Rule 1] [ Pos cover = 4 Neg cover = 0] fkeys(a, B) :- asc2fkeydst (C, B), asc2tab(c, A). [ Rule 2] [ Pos cover = 4 Neg cover = 0] fkeys(a, B) :- asc2tab(c, A), asc2fkeysrc (C, B). [ Rule 3] [ Pos cover = 3 Neg cover = 0] fkeys(a, B) :- attr2fkey (C, B), attr2(c, D), attrs(e, D), cls2tab(f, A), cls2(f, G), ancestor (E, G). Megj.: Az összes kimeneti eredmény megtalálható a C. függelékben Gráftranszformációs szabályok Összesen három darab elemet létrehozó és öt darab célmodellbeli relációkat létrehozó gráftranszformációs szabály-csoportot kaptunk, melyek közül például az fkeys esetében a 9.5. ábrán látható szabály generálódott. Megj.: Az összes szabály grafikus reprezentációjával megtalálható a B. függelékben ábra. fkeys relációt létrehozó GT szabályok A kapott szabályok segítségével, amiket sikerült a példák alapján legenerálni, a VIATRA2-t használva már bármilyen UML modellt képesek vagyunk megfelelően áttranszformálni relációs adatmodellé. Fontos megjegyezni, hogy a beadott modellek alapján az MTBE automatikusan legenerálta az összes szükséges szabályt, azokat nem kellett a felhasználónak finomítania Összegzés Az esettanulmány segítségével megmutattuk az O/R leképezésen a módszer gyakorlati alkalmazhatóságát. Az esettanulmány első felében bemutattuk az összekötések fél-automatikus módon történő előállítását különböző esetekben, amiből kiderült, hogy a bemutatott módszer nagyban segíti a tervezést még nem túl szerencsésen megadott nevek mellett is. Az esettanulmány második felében sikerült viszonylag kevés kis példamodell- és egy egyszerű segédinformáció megadásával az O/R leképezéshez szükséges végleges modelltranszformációs szabályokat teljesen automatikus módon előállítani. 92

94 10. fejezet Mérési eredmények A fejezet célja, hogy egy nagyobb méréssorozat eredményeként megállapítsuk a bemutatott módszer skálázhatóságát. Ehhez először megállapítjuk a fontosabb, számítási időt befolyásoló paramétereket, utána pedig a mérés elvégzése után részletes kiértékelést adunk a kapott eredményekről Gyakorlati korlátok Ebben a részben a módszer gyakorlati korlátai kerülnek vizsgálat alá. Az ILP számítási idejét fogjuk megvizsgálni különböző paraméterek függvényében, hogy azáltal képet kapjunk a módszer skálázhatóságáról, gyakorlati értelemben vett korlátairól A futási időre kiható tényezők Tekintsük át, hogy az ILP keresési elvéből fakadóan milyen főbb tényezők befolyásolhatják számottevően a hipotézisgyártás időtartamát: Forrásmodellek mérete, elemeinek száma. Forrásmodell összekötöttsége, avagy a forrásmodell relációinak száma. A bottom clause megalkotása során az újonnan bevehető változók maximális száma (Aleph esetében ez az i paraméter). A továbbiakban erre úgy fogunk hivatkozni, mint i éréke. A hipotézisben előfordulható literálok maximális száma (Aleph esetében ez a clauselength). Megj.: Csupán a célmodell mérete közvetlenül nem hat jelentősen a futási időre, mivel csak a pozitív, ill. negatív példák száma fog megnőni Futási idő mérése Mérési stratégia A mérési stratégia kialakítása közben célunk az volt, hogy minél jobban meg tudjuk határozni a fenti feltételek milyen mértékben hatnak a futási időre. Három fő dimenziót határoztunk meg, amelyek alapján a méréseket elvégeztük. A három dimenzió a fentiek alapján a forrásmodel nagysága, a forrásmodell összekötöttsége és az i, valamint a clauselength paraméterek együttese. 93

95 Modellek. A méréshez az O/R leképezés egy relációját (cref) vettük alapul, mivel ezen reláció létrehozása tartott mindig a legtöbb ideig. A forrásmodelleket szisztematikusan, de véletlenen alapuló struktúrába hoztuk létre, ezáltal elég egységes modelleket kaptunk ahhoz, hogy összemérhetőek legyenek a változások, de elég általánosakat is, hogy ne legyenek speciális megkötéseink. A forrásmodellekhez a megfelelő célmodellt a már meglévő transzformációs szabályok használatával generáltuk. Az így kapott generált modellpárokat adtuk be az ILP rendszernek példa modelleknek. Modellek összekötöttsége. A forrásmodell összekötöttségét az ancestor, illetve két további reláció bevételével szimuláltuk, mivel alapestben nem tartalmaztak volna kellő számú relációt a forrásmodellek. A három reláció előállításához a következő sorokkal egészítettük ki a háttértudást: % ancestor reláció ancestor (A, B) :- class_parent (A, B). ancestor (A, B) :- class_parent (A, C), ancestor (C, B). ancestor (A, A). % ancattrs reláció. ancattrs (A, B) :- ancestor (C, A), class_attrs (C, B). % anctype reláció. anctype(a, B) :- ancestor (B, C), attribute_type (A, C). Az ancattrs reláció A osztályból mutat az A leszármazott osztályok B attribútumába, az anctype reláció pedig A attibútumból mutat A attribútum C típusának ősosztályaiba. Vegyük észre, hogy az ILP rendszernek irreleváns, hogy a fenti szabályok formájában ismerik-, vagy közvetlenül tartalmazzák a modellek az adott relációt. Átlátszó módon fogja a bottom clause megalkotásánál használni azokat. Mérési eredmények A mérési eredmények bemutatásához a táblázatban összefoglaltuk az általunk generált négy forrásmodell (és a teljesség kedvéért az ahhoz tartozó célmodell) paramétereit. Az egyes oszlopokban balról jobbra szerepel a modellpáros neve, a forrásmodell entitásaira vonatkozólag az öröklési hierarchiában legfelül álló osztályok száma (l. o.), a további osztályok száma (o.), az attribútumok száma (at.) és az asszociációk száma (as.). Szerepel, hogy az adott forrásmodellben hány relációt fog jelenteni az ancestor, az ancattrs ill. az anctype megjelenése. Végül szerepel egy összesítés a célmodell és forrásmodell entitásainak, ill. relációinak számát illetően. A forrásmodellben lévő relációk számánál zárójelben feltüntettük mennyi relációt jelent összesen a három szimulált reláció felvétele táblázat. Teszt modellpárok Forrásmodell Célmodell Entitások További relációk Összesítés Összesítés l. o. o. at. as. ancestor ancattrs anctype f. e. f. r. c. e. c. r A (21) B (38) C (56) D (107) E (211)

96 10.2. táblázat. Futási idők (sec) Beállítások Futási idők Teszt modell i clauselength normál ancestor ancattrs anctype A 4 9 0,22 0,82 0,95 1,03 A ,39 1,72 1,88 1,90 A ,43 1,85 2,01 2,11 B 4 9 0,54 3,26 3,63 4,29 B ,90 5,49 5,70 6,01 B ,56 5,53 5,82 6,20 C 4 9 0, 56 7, 97 12, 15 13, 24 C , 27 10, 46 11, 49 14, 72 C , 65 10, 59 12, 20 14, 63 D 3 7 1, 46 9, 20 18, 00 19, 00 D 4 9 4, 16 46, 00 65, 00 70, 00 D , 50 54, 00 72, 00 83, 00 D , 80 55, 00 74, 00 90, 00 E 3 8 9, 80 22, 50 62, 00 64, 00 E , 70 32, 70 65, 00 71, 00 E , , , , 00 E , , , , 00 E , , , , 00 A mérési eredmények a táblázatban vannak összefoglalva, ahol megadtuk az cref relációhoz tartozó szabály megalkotásának idejét másodpercben. A táblázatban a modellek nagysága A-tól E fele növekszi, a modellek összekötöttsége balról jobbra és végül az i, ill. clauselength értékek egy adott modellméreten belül fentről lefelé. A teszteseteknél megadtuk, hogy éppen melyik modellben dolgoztunk, milyen i és clauselength paraméterek voltak beállítva, illetve hogy milyen relációk voltak a modellben: normál esetben nem adtunk további relációkat a forrásmodellhez, a következő oszlop jelzi azokat az eseteket, amikor bekerül a forrásmodellbe az ancestor reláció. Ezt követi, amikor az előbbi ancestor mellé bevettük a modellbe az ancattrs-t és utoljára, amikor az anctype is bekerül a forrásmodellbe. Megj.: A clauselength paramétert úgy állítottuk be az i-hez, hogy az adott mélységű szabályhoz elegendő literál-szám álljon rendelkezésre (kivételt képez ez alól az E teszmodell esete, ilyenkor ugyanis megvizsgáltuk, hogyan hat a futási időre az i és a clauselength paraméter külön-külön történő növelése). A futási időkön kívül fontos említést ejteni a keletkezett szabályokról, azok helyességéről. Röviden elmondható, hogy az ancestor reláció bevételével az A modellpáros kivételével minden esetben megkaptuk a helyes szabályokat. A 9. fejezetben bemutatott esettanulmány során mi persze ennél kevesebb elemet tartalmazó- és ráadásul teljesen különálló modellekből értük el, hogy minden szabály előálljon. De ne feledkezzünk el, hogy a fenti modellek esetében automatikusan generált modellekről van szó, nem pedig a tervező által tervezett esetekről. Ennek függvényében igen jónak mondható az eredmény. A másik gondolat, amit az eredmények értékelése előtt érdemes megjegyezni, hogy a szabályok generálásánál a végkimenetbe a felesleges információk (mint pl. a ancattrs) csak futási idő növekedéssel szóltak bele, a helyes szabályokra nem voltak kihatással. Eredmények érékelése Értékeljük immár az eredmények függvényeként, hogy milyen következtetéseket lehet a futási időt befolyásoló tényezőkre tenni. 95

97 Forrásmodell mérete: Tekintsük minden egyes modellhez például az i=4 és clauselength=9 sorokat, továbbá ezek közül is például az ancestor oszlopban lévőket: A esetében 0,82, B esetében 3,26, C esetében 7, 97, D esetében 46 és E esetében már 133 másodperc a reláció előállításához szükséges idő. Látszik, hogy a forrásmodell növekedésével jelentősen növekszik a számítási idő. Ez nem meglepő, mivel egy példához történő legspeciálisabb klóz(bottom clause) mérete nagyban függ a forrásmodell nagyságától és ezáltal növekszik a keresési tér, aminek következtében a számítási idő is. Az i és a clauselength paraméterek: Az E esetben megvizsgáltuk, hogy az előbbi paraméterek külön-külön történő állítása hogyan hat a futási időre. Az eredmények azt mutatják, hogy ha csak a clauselength paramétert állítjuk nagyobbra, az i-t pedig változatlanul hagyjuk, akkor nem nő meg túlságosan a futási idő, viszont fordítva ez annál inkább igaz lesz. Az i érték növelésével az ILP sokkal nagyobb bottom clause-t fog megalkotni az egyes példákhoz és ez jelentősen megnöveli a keresési teret. Vegyük észre, hogy kis modellek esetén hiába növeljük az i-t bizonyos érték fölé, a futási idő csak legfeljebb csekély mértékben növekszik. Ez azzal magyarázható, hogy kis modellekben már kisebb i értékek esetében is gyorsan eléri a bottom clause azt a méretet, amivel már lényegében az egész forrásmodellt lefedi és ezáltal nem lesz rá hatással az i további növelése. Megj.: A fenti példákban nem véletlen, hogy i érékét csak 6-ig vizsgáltuk. Az eddigi tapasztalataink alapján (főképp a koncepcionális korlátok vizsgálatához használ Sc2PN transzformáció alapján) elmondható, hogy ritkán fordulhat elő olyan, hogy ennél nagyobb értékre van szükségünk. Ha mégis előfordulna, az nagy valószínűséggel bizonyos segédinformáció megadásával orvosolható (mint például az O/R leképezés rekurzív szabálya esetében). A forrásmodell relációinak száma: Az ancestor relációk megjelenésével mindegyik modellben gyakorlatilag megdupláztuk a benne lévő relációk számát. Ez minden esetben jelentősen megnövelte a futási időt. Ha további relációkat vettünk hozzá a forrásmodellhez, ez további futási idő növekedéshez vezetett. Ennek oka, hogy az a bottom clause akár kétszeresére is nőhet, ha a relációk száma megduplázódik a forrásmodellben. A mérés eredményeként kijelenthető, hogy a számítási idő főleg a példákhoz tartozó bottom clause méretétől függ. A problémát olyan gyakorlatban előforduló esetek jelenthetik, amikor nagy absztrakciós szintű szabályokat kell megtanítani (ami magasra állított i érékkel jár), illetve ezt nagyon sok relációt tartalmazó, vagy nagy modellben kell megtenni. A mérések eredményeként kijelenthető, hogy kézzel beadott modellek esetében nem valószínű, hogy a számítási idő elfogadhatatlanul nagyra nőjön Gyorsítási lehetőségek A fenti példák egyetlen nagy és összefüggő forrásmodell eredményeként álltak elő, ami szintén jelentősen kihatott a számítási időre. Azonnal adódik egy kézenfekvő gyorsítási lehetőség, miszerint próbáljuk meg a példamodelleket minél több, egymástól független kisebb részmodellekből megalkotni (ahogyan ezt mi is tettük a 9. fejezetben). Ráadásul a tervező számára sokkal egyszerűbb több kisebb modellt megalkotnia, mint egy nagyot. A következő gyorsítási lehetőség különböző keresési stratégiák, illetve általunk megadott vágások jelentik az ILP számára. Fontos megjegyezni, hogy a fenti eredményeket az Aleph alapbeállításaival használtuk, nem próbálkoztunk egyéb keresési stratégiákkal. Számos cikk ([25], [17]) foglalkozik az ILP hatékonyabbá tételével, amelyek alkalmazásával gyorsítható lehet a módszer Összegzés A fejezetben különböző paraméterű modelleken végzett mérések alapján megállapítottuk a módszer skálázhatóságát, gyakorlati értelemben vett korlátait. A méréseket értékelve összességében elmondható, hogy a tervező által generált, éppen ezért korlátort méretű modellek esetében nem kell attól tartani, hogy 96

98 a számítási idő terén korlátokba ütköznénk. Ugyanakkor a gyorsabb futás érdekében javasolhatjuk, hogy a felhasználók használjanak (amúgy is kényelmesebben kezelhető) több kisebb modellt, mint egyetlen nagyot. 97

99 11. fejezet Eredmények értékelése A diplomatervben az induktív logikai programozás paradigmájára és eszközkészletére alapozva automatikus módszert adtam a modelltranszformációs szabályok példák alapján történő származtatására, ahol a modelltranszformációs szabályok automatikusan kerülnek származtatásra a beadott összekötött forrás- és célmodellből. Továbbá felismerve a módszerben az összekötés létrehozásának egy központi és eddig teljes mértékig kézi folyamatként definiált mivoltát, kidolgoztam egy eljárást, aminek a használatával hatékonyabban, fél-automatikus módon nyílik lehetőség a modellek közti összekötések létrehozására A dolgozat főbb eredményei Koncepcionális eredmények MTBE kiegészítése A dolgozat alapjául az [28] cikkben leírtak szolgáltak, ugyanakkor ahhoz képest koncepcionális szintű újításokat is bevezettem, amelyek a következők: Kidolgoztam az ILP automatizmusát kihasználva a transzformációs szabályok automatikus generálási fázisát. Kidolgoztam az összekötések fél-automatikus módon történő megadását. Kidolgoztam a segédinformációk megadásának lehetőségét, amit szintén példák alapján lehet generálni. Kiegészítettem a referencia modellre tett feltételezéseket, illetve pontosítottam a kontextusok fogalmán, aminek köszönhetően megvalósítható az ILP-hez való igazítás. Összekötés generálása A dolgozatban kidolgoztam egy újszerű megoldást, amelynek segítségével a felhasználó egy automatikus generálási fázison és egy fél-automatikus finomítási fázison keresztül hatékonyan tudja két általános modell között az elemek közti kategorizált összekötéseket megalkotni. Kidolgoztam egy mintaillesztéses terjesztési elvet használó módszert, amely kezdeti megszűrt hasonlóságértékek terjesztésével képes egy kezdeti javaslatot adni modellek közti összekötésre, amihez csupán a modell elemek nevéből, ill. a modellek struktúrájából informálódik. Kidolgoztam egy megközelítést, amely segítségével a felhasználót szisztematikusan tudom támogatni az esetleges manuális módosítások elvégzéséhez. Ehhez a keletkezett összekötések különböző nézeteit mutatom be a felhasználónak. 98

100 Szabálygenerálás A dolgozatban kidolgoztam a szabálygenerálási fázist az induktív logikai programozás használatával. Megalkottam a szükséges konverziós eljárást, amellyel a modelleket az ILP számára kezelhető formában tudjuk megadni. Ez a háttértudás, valamint pozitív- és negatív példák létrehozását jelentette. Az ILP automatizmusát kihasználva megadtam a szükséges kontextusok létrehozásának menetét, melyek Prolog predikátumok formájában jönnek létre. Megadtam azt a pontos algoritmust, amivel a keletkezett Prolog predikátumokból automatikus módon létrehozhatók a kívánt gráftranszformációs szabályok, illetve definiáltam az ehhez használatos adatstruktúrákat. Esettanulmányon igazoltam a módszerem gyakorlati alkalmazhatóságát. Megállapítottam a módszerem koncepcionális korlátait, amelyekhez egy igen absztrakt transzformációs példát vettem alapul Implementációs eredmények Szabályok előállítása Résztelesen kidolgoztam a teljes rendszer architektúráját nagyrészt a VIATRA2 keretrendszer használatával, illetve elkészítettem annak egy teljes, prototipikus implementációját Eclipse plugin-ként. Ehhez elsősorban egy általánosan alkalmazható, moduláris felépítésű szabálygeneráló egységet készítettem el, amelyből a következő főbb pontokat emelném ki: Elkészítettem egy olyan metamodellt, amellyel általánosan lehet az ILP rendszer számára megfogalmazni problémákat. Megírtam azt a transzformációt, amely egy jól definiált problémamodellből legenerálja a megfelelő ILP probléma modelljét. Elkészítettem egy egyszerű kódgenerátort, amely az előbbi modellből előállítja az Alpeh-specifikus bemenetet. Elkészítettem azokat az eljárásokat részben VIATRA2 transzformációkként, részben JAVA-ban megírva, amelyekkel be lehet importálni prolog szabályokat a modelltérbe és azokat gráftranszformációs szabályokká lehet transzformálni. Elkészítettem egy egyszerű kódgenerátort, amellyel a gráftranszformációt reprezentáló általános modellből VIATRA2 specifikus kódot lehet generálni. Összekötés megalkotásának támogatása Kidolgoztam a VIATRA2 keretrendszer használatával az összekötés generálásához szükséges architektúrát. Megterveztem a módszer által használt adatstruktúrát és megadtam egy magasabb absztrakciós szintű leírását az összekötéseknek. VIATRA2 transzformációkként kidolgoztam a kibővíthető hasonlóság terjesztő egységet és megadtam néhány, az általánosságban is használható terjesztő mintát. Elkészítettem a felhasználót a finomítási fázisban támogató eljárásokat VIATRA2 szabályok formájában. 99

101 Mérési eredmények Elvégeztem egy méréssorozatot annak érdekében, hogy körvonalazódjon a módszer skálázhatósága, gyakorlati értelemben vett korlátai. A mérést részletesen kiértékeltem és levontam a megfelelő konzekvenciákat. A jelen dolgozatban elért eredmények továbbá szorosan kapcsolódnak a SENSORIA FP6 IST nemzetközi kutatási projekthez Továbbfejlesztési irányok A diplomatervben elkészített rendszer jó kiindulási alapként szolgál ahhoz, hogy nagy mértékű támogatást nyújtsunk az átlagos felhasználóknak modelltranszformációk megadására. Számos kecsegtető eredmény született, ugyanakkor maradtak nyitott kérdések, továbbfejlesztési lehetőségek. Mivel a dolgozatban bemutatásra került néhány koncepcionális és gyakorlati korlát, így jövőbeli tervek között elsősorban ezek áthidalása szerepelhet, ezen felül a további fejlesztési lehetőségeket találom ígéretesnek: Az ILP rendszer számításának gyorsítása érdekében különböző keresési stratégiák alkalmazása, illetve a problémára jellemző vágások megadása a keresési térben, amihez szorosan kapcsolódhat különböző prolog kényszerek felhasználási lehetőségeinek megvizsgálása. Felkészíteni a módszert bizonyos mértékű hiba tolerálására az összekötések esetében, ami egyfajta zajként jelenne meg az ILP rendszerben. Ezáltal egyes apróbb felhasználói hibákat tolerálhatna a rendszer, ami nagyban növelhetné a gyakorlati alkalmazhatóságot. Az összekötések létrehozásánál alkalmazott finomítási lépés támogatásához hasonlóan, célunk egy jól átgondolt támogatás nyújtása a transzformációs szabályok finomítási lépésére is. A módszer fölé egy jól átgondolt felhasználói felület megalkotása, mely intelligens grafikus elemekkel képes támogatni a felhasználó munkáját. Érdekes lehet megvizsgálni, hogyan lehetne a módszert felkészíteni különböző attribútum feltételek megadásának lehetőségével a transzformációs szabályokban. 100

102 Irodalomjegyzék [1] Model Transformations in Practice Workshop. [2] Stylus Studio. [3] OMG: Object Management Group, [4] Altova. MapForce [5] A. Balogh and D. Varró. Advanced model transformation language constructs in the VIA- TRA2 framework. In ACM Symposium on Applied Computing Model Transformation Track (SAC 2006) URL sac2006_vtcl.pdf. In press. [6] E. Borger and R. F. Stark. Abstract State Machines: A Method for High-Level System Design and Analysis. Springer-Verlag New York, Inc., Secaucus, NJ, USA, [7] A. Cypher, D. C. Halbert, D. Kurlander, H. Lieberman, D. Maulsby, B. A. Myers, and A. Turransky (eds.). Watch what I do: programming by demonstration. MIT Press, Cambridge, MA, USA, [8] M. D. Del Fabro and P. Valduriez. Semi-automatic model integration using matching transformations and weaving models. In SAC 07: Proceedings of the 2007 ACM symposium on Applied computing, pp ACM, New York, NY, USA, [9] H. Ehrig, G. Engels, H.-J. Kreowski, and G. Rozenberg (eds.). Handbook on Graph Grammars and Computing by Graph Transformation, vol. 2: Applications, Languages and Tools. World Scientific, [10] G. Huszerl, I. Majzik, A. Pataricza, K. Kosmidis, and M. D. Cin. Quantitative analysis of uml statechart models of dependable systems. The Computer Journal, vol. 45(3):pp , [11] F. Jouault and I. Kurtev. Transforming models with atl. In Satellite Events at the MoDELS 2005 Conference, LNCS 3844, pp Springer, URL univ-nantes.fr/publications/2006/jk06a. ISBN= [12] G. Karsai, A. Agrawal, F. Shi, and J. Sprinkle. On the use of graph transformation in the formal specification of model interpreters. Jurnal of Universal Computer Science, vol. 9(11):pp , [13] S. Kurtz. Foundations of sequence analysis, URL uni-bielefeld.de/media/seqanalysis/prscript.pdf. [14] T. Levendovszky, L. Lengyel, G. Mezei, and H. Charaf. A Systematic Approach to Metamodeling Environments and Model Transformation Systems in VMTS. In Electronic Notes in Theoretical Computer Science, pp [15] S. Melnik. Generic Model Management: Concepts And Algorithms (Lecture Notes in Computer Science). Springer-Verlag New York, Inc., Secaucus, NJ, USA,

103 [16] J. Miller and J. Mukerji. MDA Guide. Object Management Group, Inc., org/cgi-bin/apps/doc?omg/ pdf,version (omg/ ). [17] S. Muggleton and C. Feng. Efficient induction of logic programs. pp Ohmsma, Tokyo, Japan, [18] S. Muggleton and L. D. Raedt. Inductive logic programming: Theory and methods. J. Log. Program., vol. 19/20:pp , [19] U. Nickel, N. Niere, and A. Zundorf. The fujaba environment. 22nd International Conference on Software Engineering (ICSE), vol. 00:p. 742, [20] Object Management Group, Inc. QVT: Request for Proposal for Queries, Views and Transformation. [21] Object Management Group, Inc. Meta Object Facility (MOF) Specification, omg.org/docs/formal/ pdf, Version 1.4 (formal/ ). [22] Object Management Group, Inc. Common Warehouse Metamodel (CWM) Specification, Version 1.1 (formal/ ). [23] Object Management Group, Inc. XML Metadata Interchange (XMI) Specification, http: // Version 2.0 (formal/ ). [24] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, [25] A. Srinivasan. A study of two sampling methods for analysing large datasets with ILP. Data Mining and Knowledge Discovery, vol. 3(1):pp , URL citeseer.ist.psu.edu/ srinivasan99study.html. [26] A. Srinivasan. The Aleph Manual, areas/machlearn/aleph/aleph.html. [27] Sun Microsystems. Enterprise Java Beans 3.0. [28] D. Varró. Model transformation by example. In In Proc. 9th International Conference on Model Driven Engineering Languages and Systems (MODELS 2006). Springer, In press. [29] D. Varró and A. Pataricza. VPM: A visual, precise and multilevel metamodeling framework for describing mathematical domains and UML. Journal of Software and Systems Modeling, vol. 2(3):pp , [30] M. Wimmer, M. Strommer, H. Kargl, and G. Kramler. Towards model transformation generation by-example. In Proc. of HICSS-40 Hawaii International Conference on System Sciences. Hawaii, USA., [31] M. M. Zloof. Query-by-example: the invocation and definition of tables and forms. In VLDB, pp

104 A. Függelék Aleph példa %%%%%%%%%%%%%%%%%%%% A háttértudás (nagyapa.b) tartalma: :-mode (1, nagyapa (+ember, +ember )). :-mode (*, szulo (+ember, -ember )). :-mode (*, szulo(-ember, +ember )). :-mode (*, ferfi (+ ember )). :-mode (*, no(+ ember )). :- determination ( nagyapa /2, no /1). :- determination ( nagyapa /2, ferfi /1). :- determination ( nagyapa /2, szulo /2). szulo(tamas, zoltan ). szulo(tamas, eva ). szulo(zoltan, adam ). szulo(adam, gergo ). szulo(eva, jozsef ). szulo(eva, andrea ). szulo(andrea, gabor ). ferfi(tamas ). ferfi(zoltan ). ferfi(adam ). ferfi(jozsef ). ferfi(gabor ). ferfi(gergo ). no(eva ). no( andrea ). %%%%%%%%%%%%%%%%%%%% A poitív példák (nagyapa.f) tartalma: nagyapa(tamas, adam ). nagyapa( tamas, jozsef ). nagyapa( tamas, andrea ). nagyapa( zoltan, gergo ). %%%%%%%%%%%%%%%%%%%% A negatív példák (nagyapa.n) tartalma: nagyapa( tamas, tamas ). nagyapa( tamas, zoltan ). nagyapa( tamas, gergo ). nagyapa(eva, gabor ). 103

105 B. Függelék Esettanulmány gráftranszformációs szabályai B.1. ábra. cref relációt létrehozó GT szabályok B.2. ábra. fkeys relációt létrehozó GT szabályok 104

106 B.3. ábra. kcols relációt létrehozó GT szabályok B.4. ábra. pkey relációt létrehozó GT szabályok B.5. ábra. tcols relációt létrehozó GT szabályok 105

107 B.6. ábra. Elemeket létrehozó GT szabályok 106