Aspektus-orientált nyelvek XML reprezentációja Kincses Róbert Debreceni Egyetem, Informatikai Intézet kincsesr@inf.unideb.hu Tartalomjegyzék 1. Bevezetés 2 2. Aspektus-orientált programozás és az AspectJ 3 2.1. AOP alapelvek.......................... 3 2.2. Aspektusok és komponensek................... 3 2.3. Aspektus-orientált rendszer................... 3 2.4. Az AspectJ alapjai........................ 4 2.4.1. Kapcsolódási pont (join point).............. 4 2.4.2. Vágási pont (pointcut).................. 5 2.4.3. Tanács (advice)..................... 5 2.4.4. Típusközi deklaráció (Inter-type declarations)..... 6 2.4.5. Aspektus (aspect)..................... 6 3. XML specikációk 6 3.1. Az XML-r l............................ 6 3.2. XSLT és XPath.......................... 8 4. Az AspectJ XML reprezentációja 10 4.1. Az XML formátum kialakítása................. 10 4.2. Az XML dokumentum felhasználása............... 12 4.2.1. AspectJ kód el állítása.................. 12 4.2.2. Más transzformációk................... 14 1
5. Összefoglalás és további fejlesztési irányok 14 Kivonat Az dolgozat témája egy olyan XML nyelv bemutatása, mely lehet vé teszi egy aspektus-orientált nyelv elemeinek reprezentálását. Egy olyan reprezentáció kerül bemutatásra, melyet egy konkrét nyelv alapján alakítunk ki, majd megvizsgáljuk ennek felhasználhatóságát is: hogyan lehetséges egy XML dokumentumból az eredeti nyelv fordítója számára értelmezhet szöveget nyerni, valamint milyen más célokra lehet azt felhasználni. Röviden áttekintjük, milyen más lehet ségeket nyújt az XML reprezentáció. Azt is megvizsgáljuk, hogy egy aspektus orientált nyelv mely részeit érdemes és lehetséges XML segítségével leírni. 1. Bevezetés Napjainkban a legtöbb szoftvert az Objektum-orientált technológiák segítségével készítik el. Az OO elvek használata a gyakorlatban hasznosnak bizonyult, a valós világ rendszerei jól modellezhet ek segítségükkel. Egy jól megtervezett és kivitelezett OO program karbantartható és könnyen továbbfejleszthet. Azonban léteznek olyan problémák, amelyeket nehéz elegánsan megvalósítani OO technikák segítségével. Olyan feladatokról van szó, amelyek a rendszer egészére vonatkoznak és a hagyományos programegységek határait átívelik. Az ilyen problémák megoldására az OO technikák nem kínálnak egyszer módot, hiszen a megoldás gyakran a forráskódban szétszórtan helyezkedik el. Az is el fordulhat, hogy a program egyes zárt egységei több feladatot látnak el egyszerre úgy, hogy a részfeladatok összefonódnak. Mindkét esetben nehéz újrafelhasználható formába önteni a kérdéses kódot. Az ilyen programot nehéz karbantarani, módosítani és továbbfejleszteni. Az ilyen típusú problémák megoldására született meg az Aspektus-orientált programozás (AOP). Az AOP egyszer és újrafelhasználható formában modellezi a hagyományos programozási módszerek egységeit szétfeszít problémákat. Az Aspektus-orientált programozás egyre népszer bb manapság, ezt bizonyítja, hogy több konkrét nyelv és keretrendszer is megjelent. Ennek a cikknek a célja, hogy egy konkrét aspektus-orientált nyelven keresztül megvizsgálja, milyen módon lehetséges azt XML dokumentumok segítségével leírni. Emellett, az XML dokumentumok felhasználásanak módjai is bemutatásra kerülnek. 2
2. Aspektus-orientált programozás és az AspectJ Ebben a fejezetben az Aspektus-orientált programozás elveinek rövid áttekintése található. Az fogalmak általános bemutatása után egy konkrét AOP nyelv, az AspectJ alapelvei kerülnek tárgyalásra. 2.1. AOP alapelvek A bevezet fejezetben tárgyalt nehézségekre kerestek és találtak egy megoldást [1] a XEROX Palo Altoi Kutatási Központjának (SPARC) munkatársai. Ezeket az objektumok határain átível, a programot független helyeken befolyásoló döntéseket, tényez ket elnevezték aspektusnak (aspect), és az aspektusokkal operáló programozási paradigmát pedig aspektus-orientált programozásnak (AOP). A megoldás életképességét mutatja, hogy azóta többféle implementáció, keretrendszer (framework) is megjelent.[2] 2.2. Aspektusok és komponensek A hagyományos (procedurális és objektum-orientált) programozási nyelvek segítségével úgy oldhatunk meg egy feladatot, hogy komponens ekre bontjuk. A komponensek (legalábbis jó tervezés esetén) jól körülhatárolható részfeladatokat oldanak meg, a teljes rendszer felépítésében elemi részekként vesznek részt. Könnyen modellezhet ek a hagyományos nyelvek eszközei (eljárások, metódusok, objektumok) segítségével. Ezzel szemben létez(het)nek olyan jellemz i a feladatnak, melyeket nehéz komponensekkel megvalósítani, mert a rendszert egészében hatják át és a komponensek teljesítményét, viselkedését, szemantikáját módosítják. Ezeket a jellemz ket nevezzük aspektusoknak. Ezt a két meghatározást alapul véve, az AOP célja a következ : Lehet vé tenni, hogy a komponensek és az aspektusok könnyen elkülöníthet ek legyenek egy rendszerben. Olyan mechanizmusok biztosítása, melyekkel a komponensek és az aspektusok absztrakt módon megfoghatóak és felépíthet bel lük a kívánt rendszer. 2.3. Aspektus-orientált rendszer Egy rendszer AOP alapú megvalósítása a következ kb l áll: Egy hagyományos programozási nyelv, amely segítségével a komponensek megvalósíthatóak. 3
Egy, vagy több aspektus nyelv, amelyekkel az aspektusok leprogramozhatóak. Egy aspektusszöv (aspect weaver), amely a nyelveket kombinálja. A komponenseket és az aspektusokat megvalósító programok, mindkett a megfelel nyelven megírva. A szövést végre lehet hajtani fordítási id ben, vagy elhalasztható a futási idejére. A kívánt rendszer létrehozásához az aspketusszöv nek fel kell dolgoznia a komponens és az aspektus nyelvet is, megfelel en összedolgozva ket. Nagyon fontos fogalom a kapcsolódási pont (join point), amely a komponens nyelv azon szemantikai elemeit jelöli, amelyekhez az aspektus nyelv kapcsolódhat. 2.4. Az AspectJ alapjai Az AspectJ egy általános célú, aspektus-orientált kiterjesztése a Java nyelvnek, egy új fogalmat és néhány új konstrukciót vezet be. Ezek segítségével lehet vé válik az objektumok határait átível szempontok leírását. Ez a fejezet ezeket a nyelvi elemeket taglalja. A teljes dokumentációt [3] tartalmazza. 2.4.1. Kapcsolódási pont (join point) A kapcsolódási pont (join point) az egyetlen új fogalom, amit az AspectJ bevezet, amely valójában egy már létez fogalom megnevezése. Egy kapcsolódási pont egy jól deniált pont a program végrehajtásában. Az AspectJ több ilyen pontot is deniál. Néhány konkrét kapcsolódási pont típus: Metódus hívás (Method Call) Amikor a metódust meghívják, a nem statikus metódusok super hívásait nem beleszámítva. Konstruktor hívás (Constructor call ) Amikor egy objektum konstruktorát meghívják. A létrejöv objektum a konstruktor hívás kapcsolódási pont visszatérési értéke, tehát a kapcsolódási pont visszatérési értékének típusa az objektum típusa. Az objektum elérhet egy visszatérés után tanács (lásd 2.4.3) segítségével. Mez hivatkozás (Field reference) Amikor egy nem statikus mez re hivatkoznak. Mez beállítása (Field set) Amikor a mez nek értéket adnak. Úgy tekintjük, hogy a mez beállítása kapcsolódási pontnak egy argumentuma van, amely az az érték, amelyre a mez t beállítják. A visszatérési értéke nincs (típusa void). 4
2.4.2. Vágási pont (pointcut) A vágási pontok megadják, hogy az AspectJ mely pontokon tudja egy program futását módosítani. A vágási pont (pointcut) segítségével ki lehet választani konkrét pontokat. Egy vágási pont tartalmazza a kapcsolódási pont típusát és a konkrét pontot. Például a call(void Point.setX(int)) vágási pont egy metódus hívás kapcsolódási pontot határoz meg, méghozzá a Point osztály setx metódusát, amelynek egy int paramétere van. Az AspectJ lehet séget biztosít a kapcsolódási pontok kombinálásara (vagy, és &&, nem!) és az összetettebb vágási pontokat el is nevezhetjük. A név segítségével kés bb egyszer bben hivatkozhatunk az adott vágási pontra. Mivel egy vágási pont a kapcsolódási pontokat nem csak egy típusból választhatja ki, hanem tetsz legesen sokból, ezért azt mondhatjuk, hogy átvágja (crosscut) a típusok határait. Amikor a kapcsolódási pontok kiválasztásánál pontos metódusok, mez k vagy más egységek nevét adjuk meg, akkor név alapú (name based) vágásról van szó. Lehet ség van azonban az úgynevezett jellemz alapú (property based) vágásra. Ebben az esetben nem pontos neveket, hanem mintát kell megadni, amely egyszerre több metódusra, mez re illeszekedhet. A minták mellett léteznek olyan vágási pontok is, amelyek deniciójukból adódóan választanak ki több kapcsolódási pontot egyszerre. 2.4.3. Tanács (advice) A vágási pontok által kiválasztott kapcsolódási pontokhoz kapcsolódó, típusokat átível viselkedés implementálását teszik lehet vé a tanács (advice). Az advice rendelkezik törzssel, mely programkódot tartalmaz. A kód akkor fut le, ha az advice-hoz kapcsolt vágási pontot elérte a program futása. Az AspectJ többféle advice-t deniál: before Akkor fut le, amikor a program futása elérte a kapcsolódási pontot, azel tt, hogy a kapcsolódási pontnál a program végrehajtása folytatódna. after Akkor fut le, amikor egy kapcsolódási pontnál a program futása éppen befejez dött. Mivel egy Java program futáskor egy kapcsolódási pontot kétféleképpen hagyhat el, ezért három fajta after tanács létezik: normál befejez dés esetén az after returning, kivétel esetén az after throwing tanács használható. Ha mindkét esetet gyelembe akarjuk venni, akkor egyszer en az after tanácsot kell alkalmaznunk. 5
around A kapcsolódási pont kódja helyett fut le. A kapcsolódási pont végrehajtása a proceed meghívásával lehetséges, amelynek paraméterezése megegyezik a tanács paraméterezésével. A vágási pontok a kapcsolódási pontok kiválasztása mellett képesek felfedni a végrehajtási környezetét az általuk kiválasztott kapcsolódási pontoknak (exposing context). A felfedett értékek használhatóak a tanácsok törzsében. A tanács deklarációjának a paraméterlistája adja meg a felfedett környezet elemeinek a nevét. 2.4.4. Típusközi deklaráció (Inter-type declarations) A típusközi deklaráció keresztül vágja az osztályokat és azok hierarchiáit. Olyan tagokat deklarálhatnak, amelyek több osztályon vágnak keresztül, vagy megváltoztathatják az osztályok között fenálló örökl dési viszonyt. A tanácsoktól eltér módon, fordítási id ben fejtik ki hatásukat. Nagyon hatékonyan használhatók abban az esetben, ha valamilyen több, egymástól az osztály-hierarchiában távol álló osztályt kell azonos funkcionalitással felruházni. Az AspectJ nélkül ezt a feladatot egy interfész bevezetésével lehetne megoldani (melyet a megfelel osztáyok implementálnának). A típusközi deklarációk segítségével azonban az eredeti osztályok forráskódjának módosítása nélkül, egy helyen lehet a megfelel funkcionalitást implementálni. 2.4.5. Aspektus (aspect) Az aspektusok vágási pontokat, tanácsokat és típusközi deklarációkat fognak egybe. Az aspektus hasonlít az osztályra, lehetnek metódusai, mez i, inicializátoria az aspektus-orientált tagok mellett. 3. XML specikációk Ez a fejezet röviden ismerteti azokat a XML specikációkat, melyeket a reprezentációhoz felhasználunk. El ször az XML kerül bemutatásra, majd az XSLT és az XPath specikációk rövid leírása következik. 3.1. Az XML-r l Az extensible Markup Language (XML) specikációját [4] a W3C XML Core Munkacsoport készítette. Az XML egy részhalmaza az SGML-nek. Az XMLt úgy tervezték meg, hogy a feldolgozásához használt eszközök könnyen imp- 6
lementálhatóak legyenek és biztosítsa az interoperábilitást mind a HTML-el, mind az SGML-el. Az XML segítségével nyelveket lehet kialakítani, amelyek dokumentum osztályokat írnak le. Ezek a dokumentumok hierarchikus szerekzet adatok tárolhatnak. A W3C ajánlása az XML dokumentumokat feldolgozó programok viselkedésével is foglalkozik. Egy XML dokumentum entitásokból áll, amelyek elemzett és nem elemzett részekre osztható. Az elemzett részek karakterekb l állnak, melyek egy része karakteres adat, egy része pedig úgynevezett markup (jelölés). A markup adja meg a dokumentum részeinek leírását és alakítja ki annak logika struktúráját. Egy egyszer XML dokumentum a következ képpen néz ki: <?xml version="1.0" standalone="yes"?> <list> <element value="5"/> <element value="1"/> <list> Az els sor az úgynevezett prolog részbe tartozik, melynek feladata, hogy speciális információkat tároljon az egász dokumentumra vonatkozóan. A fenti példa természetesen nem meríti ki a prolog összes lehet ségét. Sok más mellett itt lehet megadni a dokumentum kódolását is. Az XML dokumentum mindig tartalmaz pontosan egy markup elemet, amelyet a gyökérelemnek nevezünk. Ez lehet üres is. A további elemek egymásba ágyazva, tetsz leges számban és sorrendben helyezhet ek el a dokumentumban (a gyökérelem tartalmaként). Az XML specikáció nem határoz meg markup készletet, melyb l dokumentumainkat felépíthetjük (extensible), hanem a logikai szerekzetre határoz meg szabályokat. Az egyik nagyon fontos követelmény a jól formázottság (well-formedness), mely azt jelenti, hogy a tagek nem fedhetik át egymást: vagy azonos szinten kell lenniük a hierarciában, vagy teljes tartalmazás kell fennálljon. Egy másik tulajdonsága az XML dokumentumnak az érvényesség (validity). Ahhoz, hogy egy XML dokumentum érvényes legyen, meg kell adni, hogy milyen szabályoknak kell megfelelnie. Erre több lehet ség is van, az egyik ezek közül a Document Type Denition (DTD) megadása. Egy XML dokumentum érvényes, ha jól formázott és megfelel a DTD-nek. Az XML használalata igen elterjedt manapság, szinte minden komolyabb szoftver rendszer használja valamilyen formában. Az XML specikáció mellett sok olyan specikáció jelent meg, amely a XML-re épül, annak egyfajta alkalmazása.[5] 7
3.2. XSLT és XPath A dolgozatban közvetlenül is felhasznált XML-re épül specikációk a következ k: az XSL Transzformációk (XSL Transformations) [6] és az XML Útvonal nyelv (XML Path Language) [7], amelyek az XSL javaslat család részei. Az el bbi olyan transzformációk leírására szolgál, amellyel XML dokumentumok alakíthatóak át. Az XPath egy olyan nyelvet deniál, amellyel az XML dokumentum részeire lehet hivatkozni. Az XSLT használja az XPath-t. Egy XSLT stíluslap egy XML dokumentum osztály prezentációját adja meg úgy, hogy megadja, hogy a dokumentum osztály egy példányát hogyan kell egy másik XML dokumentumba transzformálni. Az eredmény dokumentum több fajta lehet, mint például XHTML vagy XSL-FO. Az XSLT mük dését röviden úgy lehet összefoglalni, hogy egy forrás fát átalakít egy eredmény fává. A transzformálási folyamat során az XSLT az XPath segítségével jelöli ki a forrás dokumentum azon részeit, amelyek bizonyos mintákra illeszkednek. A feldolgozás során az illeszked rész a minta alapján kerül átalakításra. A forrás dokumentum azon részei, melyekre egyetlen minta sem illeszkedik, változtatás nélkül kerülnek az eredmény dokumentumba. A transzformációt egy olyan program végzi el, amely feldolgozza a forrás dokumentumot és a hozzá kapcsolt stíluslapot, majd a stíluslapban talált transzformációs utasításoknak megfelel en el állítja az eredmény dokumentumot. A stíluslapot a követekz módon lehet az XML állományhoz csatolni: <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="simple.xsl"?> <list> <element value="5"/> <element value="1"/> </list> Így a simple.xsl állomány a fenti XML dokumentum stíluslapja lett. A stíluslap tartalma a következ lehet: <?xml version="1.0" encoding="iso-8859-1"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/xsl/transform"> <xsl:template match="/"> <html> <head><title>list</title></head> <body> 8
<xsl:apply-templates/> </body> </html> </xsl:template> <xsl:template match="list"> <ul> <xsl:apply-templates/> </ul> </xsl:template> <xsl:template match="element"> <xsl:if test="@value = 5"> <li><xsl:value-of select="@value"/></li> </xsl:if> </xsl:template> </xsl:stylesheet> Amint a példán is látszik a stíluslap maga is egy XML állomány. A második sor tartalmazza a gyökér elem nyitó tagjét és egyben a stíluslap névterületét is meghatározza (ezt rögzíti a specikáció). Ezek után minták következnek (<xsl:template>), melyek megadják, mire illeszkednek. Az sikeres illesztés mindig kiválaszt egy aktuális csomópontot és egy aktuális csomópont-listát. Egy-egy mintán belül helyezkednek el az eredmény dokumentumba kerül elemek és a további szabályok. A példa tartalmaz egyszer XPath kifejezéseket is, mint például a @name = 5 kifejezés a feltételes feldolgozó utasítás feltételeként. Ha ez a kifejezés igaz, azaz az aktuális <element> tag value attribútumának értéke 5, akkor az <xsl:if> tagben megadott formázási utasítások végrehajtódnak. A transzformáció eredménye a fenti XML állományt feltételezve az alábbi: <html> <head><title>list</title></head> <body> <ul> <li>5</li> </ul> </body> </html> 9
4. Az AspectJ XML reprezentációja Ennek a szakasznak a célja, hogy röviden bemutassa, milyen módon lehetséges az AspectJ aspektus-orientált nyelvi elemeit XML dokumentumok segítségével reprezentálni. Emellett azt is megvizsgájuk, hogyan lehet az XML dokumentumokat felhasználni. 4.1. Az XML formátum kialakítása Ahhoz, hogy az AspectJ elemeit XML dokumentumok segítségével reprezentáljuk, el ször ki kell alakítani a megfelel XML szintaktikáju nyelvet. Erre a célra szabványosított megoldás nem áll rendelkezésre, tehát saját formátumot kell létrehozni. Az XML nyelv kialakításánál érdemes olyan megoldásra törekedni, amely olyan XML dokumentumokat eredményez, amelyek az ember számára is könnyen el állíthatóak és olvasatóak. Így megkönnyíthet az XML dokumentumként reprezentált AspectJ kóddal való munka, ugyanis annak szerkesztése nem (feltétlenül) igényel speciális eszközöket (XML szerkeszt t). Az AspectJ kód átalakítását több lépésben végezhetjük el. A nyelv elemeit kív lr l befelé haladva alakítjuk át (a nagyobb szintaktikai egységeket vesszül el ször). A végcél az, hogy a lehet legtöbb részt írjuk le XML segítségével. Lássuk az átalakítás lépéseit, néhány példával illusztrálva! Els lépésként tételezzük fel, hogy egy-egy aspketus denícója egy-egy külön állományban szerepel és abban az állományban csak egy aspektus szerepel. Adott egy SimpleAspect.aj nev állomány, melyben szerepel egy aspektus: public aspect SimpleAspect { //... } A fenti feltevés mellett egyszer vé válik a gyökérelem megválasztása, amelyet rögtön felruházhatunk az aspektus jellemz ivel is: <?xml version="1.0" encoding="iso-8859-2"?> <aspect name="simpleaspect" modifier="public"> </aspect> Az itt látható aspektusnak csak a neve (SimpleAspect) és egy módosítója (public) van megadva. Az aspektus más jellemz it hasonló módon lehet leírni. 10
Az aspektus törzsét nyilván az <aspect> tagek között kell megadni. Az ott elhelyezhet elemeket a fentihez hasonlóan képezhetjük le XML elemekre. Vegyük sorra az aspektus vágási pontjainak leírását: pointcut dosomething(): call( void Foo.doSomething(int) ); Ennek a vágási pontnak egyfajta leképezése lehet a következ : <pointcut> <name>dosomething</name> <primitive type="call"> void Foo.doSomething(int) </primitive> </pointcut> Ezen a példán egy egyszer vágási pont XML reprezentációját láthatjuk. A vágási pontnak a neve (dosomething) valamint az egyetlen primitív vágási pontja (<primitive>) van megadva. Egy vágási pont ennél sokkal összetettebb is lehet, ekkor több dolgot kell leírnunk: pointcut argcheck(int score): call(void Proba.doSomething(int)) && args(score); Ebben az esetben a vágási pontnak formális paramétere is van, illetve két elemi vágási pontot is tartalmaz, melyek and kapcsolatban vannak. Így a reprezentáció is bonyolultabbá válik: <pointcut> <name>argcheck</name> <formals> <formal type="int" name="score"></formal> </formals> <and> <primitive type="call"> void Proba.doSomething(int) </primitive> <primitive type="args"> score </primitive> </and> </pointcut> 11
A teljes vágási pont deníciónak megfelel XML reprezentáció elkészíthet az AspectJ referencia alapján. A következ példában egy egyszer tanács kódja látható: before(int score): argcheck(score) { if( score < 0 score > 100 ) throw new IllegalArgumentException("illegal score: "+score); } Természetesen a példában nem szerepel a tanács minden lehetséges jellemz je. Egy lehetséges reprezentáció a következ : <advice type="before"> <formals> <formal type="int" name="score"></formal> </formals> <pointcut> <name>argcheck</name> <exposes>score</exposes> </pointcut> <body> if( score < 0 score > 100 ) throw new IllegalArgumentException("illegal score:"+score); </body> </advice> A fentiek csupán egyszer példák, melyek megmutatják, hogy lehetséges XML formában reprezentálni egy aspektust. A reprezentáció nem végleges és nem teljes, azonban az alapvet felhasználási lehet ségek kipróbálásához megfelel. 4.2. Az XML dokumentum felhasználása Ebben a fejezetben azt vizsgáljuk meg, hogy az el z ekben el állított XML dokumentumot milyen módon lehet felhaszálni. Az átalakítás technológiája egyértelm en az XSLT, így a különféle kimeneti formátumok el állításához csupán egy-egy XSL transzformációt leíró állományt kell készíteni. 4.2.1. AspectJ kód el állítása Ez a szakasz az AspectJ programkód el állítási módját vizsgálja, mely az 4.1 fejezetben leírtak megfordítása és automatikus végrehajtása. Nyilvánvaló, 12
hogy ez a m velet akkor nyer értelmet, amikor nem rendelkezünk az AspectJ kóddal, hanem csupán az XML dokumentum áll rendelekzésünkre. A következ kben egy olyan XSL transzformáció kerül részleteiben bemutatásra, amely az el z ekben tárgyalt AspectJ kód el állítására alkalmas. El ször lássuk, hogyan lehet a forrás vázát, az aspektust el állítani: <xsl:template match="aspect"> <xsl:value-of select="@modifier"/> <xsl:text> aspect </xsl:text> <xsl:value-of select="@name"/> { <xsl:apply-templates select="pointcut"/> <xsl:apply-templates select="advice"/> } </xsl:template> A fent megadott template egy <aspect> tagre alkalmazva, a példa esetén a következ kimenetet adja: public aspect SimpleAspect {... } Amint látható, a template további template-k alkalmazását írja el, a következ példa ezek közül az els t szemlélteti: <xsl:template match="pointcut"> pointcut <xsl:apply-templates select="name"/> <xsl:apply-template select="formals"/> <xsl:apply-templates select="and"/> <xsl:apply-templates select="primitive"/> <xsl:text>;</xsl:text> </xsl:template> A kimenet többféleképpen alakulhat. Ha a vágási pont tartalmaz formális paramétereket, akkor azok a <formals> tagekre illeszked minta alapján generálódnak. Ha a vágási pont több elemi vágási pontból tev dik össze, akkor azok valamilyen logikai jellel vannak összekapcsolva. A fenti részlet csak az and kapcsolatra mutat példát, azonban a not és az or hasonlóképpen implementálható. Amennyiben csak egyetlen elemi vágási pontot tartalmaz, akkor csupán annak a kódja generálódik. Utolsóként következzen egy elemi vágási pont transzformáláshoz szükséges kód és annak eredménye: 13
<xsl:template match="primitive"> <xsl:value-of select="@type"/>( <xsl:apply-templates/> ) </xsl:template> Ez a minta a következ kimenetet adja egy metódushívás elemi vágási pontjára alkalmazva: pointcut dosomething: call( void Proba.doSomething(int) ) ; A többi elem az XML dokumentumban hasonló elvek alapján könnyen feldolgozható. Az eredmény pedig egy olyan szöveg, amelyet az AspectJ fordító képes értelmezni. 4.2.2. Más transzformációk Az XML dokumentumok felhasználására más lehet ség is adódik. Ha a fent ismertetett formátumot megfelel en kiegészítjük, akkor lehetségessé válik dokumentáció mellékelésére az elemekhez. Ezeket a dokumentációs részeket egy megfelel transzformáció segítségével összegy jthetjük és el állíthatjuk az aspektushoz tartozó dokumentációt, például HTML formátumban. Lehetséges egy olyan fordító programot írni, amely közvetlenül az XML dokumentum feldolgozásával és a Java osztályok segítségével el állítja az aspektus-orientált kóddal kiegészített class állományokat. A kimeneti formátumok számának és a felhasználási lehet ségeknek csak az XSL transzformációk lehet ségei és a kiválasztott XML reprezentáció korlátai szabnak határt. 5. Összefoglalás és további fejlesztési irányok A dolgozat egy konkrét AOP nyelv, az AspectJ elemeinek XML dokumentumokkal történ reprezentációját ismerteti. Röviden vázolja a reprezentáció el állítását, majd annak fontosabb felhasználásait is tárgyalja. Lássunk néhány további fejlesztési lehet séget. A 4.1 részben az XML dokumentum el állítása kézzel történt. Az egyik lehet ség ennek a folyamatnak az automatizálása, mely egy speciális fordító program megírását jelenti. A fordítás eredménye az XML dokumentum lenne. A XML formátum automatikus ellen rzéséhez szükséges lenne egy séma el állítása. Ekkor lehet vé válna, hogy az XML állomány feldolgozás közben validáláson is átessen. 14
Amennyiben a XML reprezentáció elég általánossá válik és kevés nyelvfügg dolgot tartalmaz, akkor lehet ség nyílik arra, hogy egy XML dokumentumból más aspektus-orientált nyelveknek megfelel forráskódot is generáljunk. Ez azonban a lehetséges nyelvek megvizsgálását és az XML reprezntáció tökéletesítését kívánja meg. Hivatkozások [1] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J. Loingtier and J. Irwin: Aspect-Oriented Programming, European Conference on Object-Oriented Programming (ECOOP), June 1997. [2] AOSD Homepage Research Projects, http://aosd.net/technology/research.php [3] The AspectJ T M Programming Guide http://dev.eclipse.org/viewcvs/indextech.cgi/ checkout /aspectj-home/doc/progguide/index.html [4] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau: Extensible Markup Language (XML) 1.0 (Third Edition), http://www.w3.org/tr/2004/rec-xml-20040204/ [5] W3C Technical Reports and Publications http://www.w3.org/tr/ [6] James Clark (ed): XSL Transformations (XSLT) Version 1.0 http://www.w3.org/tr/xslt [7] James Clark, Steve DeRose: XML Path Language (XPath) Version 1.0 http://www.w3.org/tr/xpath 15