Aspektus és objektum modell leírása XML-lel

1. Bevezetés

2. Objektum hierarchia leírása

3. UML leírás transzformációja XML-re

4. Elosztottság

5. Perzisztencia

6. Applikációs homlokzat

7. Összesített Aspektus és objektum hierarchia leírás

8. Konklúzió

A teljes szöveg egy file-ban

1. Bevezetés

Ennek a tanulmánynak a célja, hogy definiáljon egy módszert, amivel leírható egy objektum-orientált technológiával készült objektum hierarchia. Maga a hierarchia az ún. domain-modellt implementálja, a megoldandó feladatot modellező objektumokból áll, és nem tartalmaz egyéb, a feladathoz nem tartozó részeket.

Az aspektus-orientált programozás jelentősége az, hogy a Domain-modell, és némi egyéb információ alapján generáljuk a programnak azon részeit, amik a programozás terén ismétlődő implementációs problémák, a lényegi feladathoz nem tartoznak, és általában meglehetősen gépies munkát igényel az implementálásuk. Ezeket a részeket ezentúl "aspektusoknak" nevezzük. Az aspektus-orientáltság előnyei között az áttekinthetőbb, könnyebben karbantartható, és tömörebb forráskódot emelném ki.

A továbbiakban a következő aspektusokkal foglalkozunk:

• Elosztottság. (Távoli objektumok használata.)
• Perzisztencia. (Objektumok transzparens kiírása és visszatöltése.)
• Applikációs homlokzat. (Az objektum hierarchia egy transzformációja egy felhasználói felület számára.)

Ezeknek a részeknek (aspektusoknak) megírásához szükséges többletinformációt a modell leírásába beszúrva egy alkalmas eszközzel ezek automatikusan generálhatóak lesznek. Az automatikus generáláshoz használt technológia (a "transzformáció") ennek a leírásnak nem része.

2. Objektum hierarchia leírása

A továbbiak az XML (Extensible Markup Language) 1.0-as és az UML (Universal Modeling Language) 1.3-as verziójú szabványok alapján íródnak. Az UML szabványnak csak az objektum-típusok leírására vonatkozó részét használom, mivel a modellen belül lezajló folyamatok (pl. üzenetterjedés) az aspektusok számára nem lényegesek.

Az alábbiakban a hierarchiát leíró nyelv aspektusok nélküli változata következik, a további fejezetekben ezt fogjuk kiegészíteni a szükséges többletinformációkkal. Ez a módszer azért szerencsés, mert mindegyik implementálandó aspektus követi az objektum-hierarchiát (elképzelhető lenne olyan aspektus is, ami nem követ semmilyen a domain modellre jellemző hierarchiát, példának a kivételkezelést lehetne említeni.)

Feltételezem az XML (vagy SGML) alapfokú ismeretét a továbbiakban. Álljon itt egy rövid összefoglalás az általunk használt XML struktúrákról:

Tag-ek:

'<' Név Attribútum* '>' Tartalom '</' Név '>'

Üres tag:

'<' Név Attribútum* '/>'

Attribútum:

Név '=' AttÉrték

CLASS

A CLASS elem definiál egy osztályt. A kötelező NAME mező tartalmazza az osztály nevét. Ha az osztálynak van őse, akkor azt az ANCESTOR attribútummal adható meg. Az ős megadása nem kötelező, ha az ősnek nincsenek számunkra lényeges változói vagy metódusai. Ha vannak, akkor az őst is definiálni kell egy CLASS elemmel. Ha a CLASS-nak vannak leszármazott típusai, azokat kötelező egy-egy CLASS tag-gel definiálni.

A COMMENT mező tartalmát az aspektusokat implementáló program nem használja, ezt csak a hierarchiát emberek számára megjelenítő program számára kellhet.

METHOD

A METHOD elem definiálja egy osztály egy metódusát. Nem szükséges az osztály összes metódusát definiálni, de ha egy metódus valamelyik aspektusunk szempontjából lényeges (pl. távolról elérhetővé akarjuk tenni), akkor kell hozzá egy METHOD tag.

A metódus paramétereit és visszatérési értékét megfelelő tagekkel definiálni kell. A paramétereket a megfelelő sorrendben kell megadni. A RETURN tag bárhol lehet, de célszerű a legvégére tenni. Ha nincs RETURN tag, az azt jelenti, hogy a metódus visszatérési értéke void.

Amennyiben az osztálynak több metódusa van azonos névvel, mindet külön definiálni kell, azonos NAME tag-gel.

PARAM

A PARAM tag-ek egy metódus paramétereit határozzák meg. Minden paraméterhez kell egy ilyen tag. A tag-ek sorrendje lényeges!

RETURN

A metódus visszatérési értéke. Ha ez a tag hiányzik, az azt jelenti, hogy a metódus visszatérési értéke void.

ATTRIBUTE

3. UML leírás transzformációja XML-re

Tekintsük az alábbi objektum hierarchiát:

Bank name : String lookUpAccount() transfer() createAccount()
accounts
Account accountNumber : int balance : int balance() numberOfEntries() getEntryByIndex() setEntry()	entries account	Entry amount : int date : String amount() date()	transaction 2 from,to	Transaction typeOfTransaction : String notice : String from() to() notice() typeOfTransaction()

Ennek a hierarchiának az Account osztályának a transzformált változata a következőképpen néz ki:

   <CLASS NAME="Account" COMMENT="Egy számla, bejegyzésekkel">
      <ATTRIBUTE NAME="accountNumber" TYPE="int"/>
      <ATTRIBUTE NAME="balance" TYPE="int"/>
      <ATTRIBUTE NAME="entries" TYPE="Entry[]"/>
      
      <METHOD NAME="balance">
         <RETURN TYPE="int"/>
      </METHOD>
      <METHOD NAME="numberOfEntries">
         <RETURN TYPE="int"/>
      </METHOD>
      <METHOD NAME="getEntryByIndex">
         <PARAM TYPE="int"/>
         <RETURN TYPE="Entry"/>
      </METHOD>
   </CLASS>
   

Mint látható, az átalakítás meglehetősen egyszerű, az osztályt leíró doboz tartalmának minden eleme megfeleltethető egy tag-nek.

4. Elosztottság

Az elosztottság lehetővé teszi távoli objektumok használatát, eljárásainak hívását, paraméterek átadását. Ehhez szükség lehet az objektumok teljes vagy részleges másolására, vagy referencia szerinti átadására.

Az aspektus leírásához szükséges információk a következők:

• A távolról elérhető attribútumok, ezek láthatósága (írható, vagy csak olvasható).
• A távolról elérhető metódusok. Ezekhez meg kell adni azt is, hogy az adott metódus paraméterei és visszatérési értéke másolásra vagy referencia szerinti átadásra kerülnek-e.
• A kliens és a szerver egymásra találásának módja.

A nyelvünk ezen igények kielégítésére a következő tagekkel bővül:

CLASS	<REMOTENAME> ... </REMOTENAME> (A tag belsejében levő java kódrészletnek kell visszatérnie a szerver nevével. A kódrészlet globális változókat és objektumokat használhat, és kontextusfüggetlennek kell lennie.) <REMOTEPORT> .. </REMOTEPORT> (Mint fent, de a szerver portját adja vissza. Az implementáció nem feltétlenül használja ezeket az értékeket; pl. CORBA alapú elosztottság esetén port számra nincs szükség.)
METHOD	REMOTE (Ez az attribútum akkor szerepel, ha az adott eljárást távolról elérhetővé kivánjuk tenni. Ha szerepel, akkor a PARAM és RETURN tageket is ki kell egészíteni a megfelelő információkkal.)
PARAM	REMOTE=MasolasTipus (A MasolasTipus csak osztály vagy osztálytömb esetén szerepel. Értéke "COPY" vagy "GREF" lehet. COPY esetén másolat készül az objektumról, vagy annak részéről, GREF esetén csak egy globális objektum referencia adódik át.) BYPASS=AttrLista (COPY típusú másolás esetén meg lehet adni, hogy mely attribútumok NE adódjanak át a paraméterként szereplő objektumból.) ONLY=AttrLista (COPY típusú másolásnál csak ezek az attibútumok adódnak át. Az ONLY és a BYPASS közül legfeljebb egy szerepelhet.)
RETURN	REMOTE=MasolasTipus BYPASS=AttrLista ONLY=AttrLista

Ezen többletinformációk elegendőek az Aspektus Weavernek az szerver és kliensoldali domain modell forrásán eszközölendő változtatások automatikus generálására. Különböző elosztottsági technológiát használó weaverek (pl. RMI alapú weaver, CORBA alapú weaver) eltérő lépéseket tesznek, és az általuk generált applikáció más lesz, azonban a forrás (a domain modell forrása, és az objektum modell leírása) azonos minden esetben. Ez lehetővé teszi az elosztott technológia lecserélését egyéb költséges változtatások nélkül.

5. Perzisztencia

A perzisztencia lényege az objektum hierarchia egy részének adatbázisba kimentése, illetve onnan visszatöltése az objektumok számára transzparens módon, vagyis az objektumok ne "vegyék észre", hogy őket kimentették, kiléptek a programból, kikapcsolták a gépet, és csak másnapi visszatöltés után folytatták a futtatásukat.

A flexibilitás megköveteli, hogy többféle modellhez kapcsolható legyen az aspektusunk. Az kétféle modell, amit megkülönböztetünk:

• Az összes perzisztens objektum egy "projekt" része, központi projekt objektum nem feltétlenül létezik. Szerencsés, ha a kiírás (comit) lehetőleg csak a változott objektumokat érinti. Erre az esetre példa egy kórház betegnyilvántartó információs rendszere.
• Az objektumok egy, vagy több központi objektum köré szerveződnek. A központi objektumot dokumentumnak nevezzük. A többi perzisztens objektumnak van egy "birtokosa", és mind egy dokumentumhoz tartozik közvetlenül vagy közvetve. Perzisztens objektum csak akkor mentődik ki, amikor az dokumentum mentődik ki, amelyiknek része. Erre a modellre példa egy többdokumentumos szövegszerkesztő.

A két módszer kombinálható is. A mentés típusa is többféle lehet, az adatok tárolására szolgálhat adatbázis, vagy flat file, ez a használt weavertől függ.

A perzisztencia leírásához a következő tagekkel egészítjük ki a domain modell leírását:

CLASS	PERSISTENCE=PersTipus (A PersTipus lehet "TOPLEVEL", "DOCUMENT", vagy "PART", attól függően, hogy az objektum a globális objektumhalmaz része, egy dokumentum, vagy a dokumentum egy eleme.) OWNER=AttrNev (Meghatározza, hogy melyik attribútum tartalmazza az objektum birtokosát PART típusú osztály esetén.) AUTOADD (Megadhatjuk, hogy az adott osztályba tartozó objektumok mikor válnak a projekt részéve, vagyis perzisztenssé. Azok az objektumok, amik nem részei a projektnek, tranziens objektumok, és nem kerülnek mentésre. Ha az AUTOADD attribútum szerepel a CLASS tagben, akkor az objektumok mindig (a konstruktor futása előtt) a projekt részévé válnak, egyébként a METHOD tagoknál lehet a bekerülésüket meghatározni.) REMOVE=RmTipus (Az határozza meg, hogy mikor kerül ki az objektum a projektből. Az RmTipus lehetséges értékei: "ALWAYS", "AUTO", "MANUAL" (default). ALWAYS esetén az objektum destruktora kiszedi a projektből, AUTO esetén akkor kerül ki, ha nincs egyik TOPLEVEL objektumban sem benne. A MANUAL érték esetén szintén a METHOD tagoknál definiált a viselkedés.) <DBNAME> .. </DBNAME> (DOCUMENT típusú objektumhoz kell. Egy Java nyelvű kódrészletet tartalmaz. A kód értéke meghatározza, hogy az objektum hova mentődjön ki. Flat weaver esetén ez egy filenév, adatbázisos weavernél a tábla neve.)
ATTRIBUTE	PERSISTENT (Az objektumnak csak azon változói kerülnek kimentésre, amiknek ez szerepel az tagjükben).
METHOD	SAVE=MethodPart (Ezzel az attribútummal kell jelezni, hogy az objektumot/objektumokat menteni kell ezen metódusuk előtt, ill. után. A MethodPart értékei lehetnek "BEFORE" vagy "AFTER".) LOAD=MethodPart (Az objektumot vissza kell tölteni a metódus előtt/után) ADD=MethodPart (Ha az objektumosztálynál nincs AUTOADD, akkor ez a tag deklarálja, hogy az objektum a projekt része lesz a metódus előtt/után) REMOVE=MethodPart (REMOVE="MANUAL" esetén kell)

A perzisztencia leírása meglehetősen egyszerű, kivitelezése viszont munkaigényes. Az összes objektum referenciát le kell cserélni egy objektum azonosítóra, ami perzisztenssé tehető. A perzisztens attribútumok megváltozását követni kell, hogy tudjuk, melyik objektum változott meg. Az objektum azonosítók feloldására szükséges egy objektum manager implementálása is.

6. Applikációs homlokzat

A domain modell nem tartalmaz felhasználói felületet. A modell logikája nem feltétlenül egyeztethető össze egy jól tervezett felhasználói felület logikájával. Szükség van tehát egy transzformációra, ami a domain modell objektum hierarchiájából egy másikat csinál.

A transzformációra azért is szükség lehet, mert a teljes információs rendszert egy domain modell mellett több applikációs program szolgálja ki. Az applikációs programok tipikusan valamilyen grafikus felülettel rendelkező "thin clientek", hálózaton keresztül csatlakozva a szerverre, ahol a kiszolgáló program fut.

Ezt figyelembe véve kijelenthetjük, hogy a modern vállalati információs rendszer architektúrája a következőképpen néz ki;

FACADE

A FACADE az objektum hierarchia egy részének transzformált képe. Az alapját mindig a hierarchia egy objektuma képezi, bár a működése kiterjedhet a többi objektumra is, amik ezzel valamilyen kapcsolatban állnak. A FACADE attribútumait (amik nem valódi változók) PROPERTY-nek nevezzük.

PROPERTY

A FACADE a felhasználói felület felé egy sor PROPERTY-t szolgáltat. A PROPERTY-k úgy viselkednek, mint a valódi változók, amennyiben a manipulációs funkcióik (kiolvasás, írás, stb,) megegyeznek a változóknál megszokottallak. A különbség az, hogy a FACADE-nek nincsenek valódi attribútumai, és minden PROPERTY olvasása, írása, stb. a domain modell manipulációjára képeződik le.

A PROPERTY belsejében egy kötelező RETRIEVAL tag van, ami az értékét kiolvassa. A többi íráshoz szükséges, és mind opcionális.

RETRIEVAL

A tag belsejében szereplő java kódrészlet felelős a property kiolvasásáért.

UPDATE

A tag belsejében szereplő java kódrészlet felelős a property írásáért. Ellenőrzésre definiálható a VALIDATION tag.

LEGALVALUES

A tag belsejében levő java kódrészlet visszatér a property értékkészletét tartalmazó halmazzal.

VALIDATION

Ellenőrzi, hogy egy adott érték elfogadható a property értékének.

DEFAULT

Új objektum definiálásakor a property kezdeti értékét beállító kód.

Elképzelésem szerint a domain oldali applikációs homlokzat ilyen definiálása után egy thin client felhasználói interface implementálása a képernyők ergonómiai megtervezésében merül ki, mert a facade osztályok az információt pontosan olyan formában szolgáltatják, ahogy az a UI elemeinek kell.

7. Összesített Aspektus és objektum hierarchia leírás

CLASS

METHOD

PARAM

RETURN

ATTRIBUTE

REMOTENAME

REMOTEPORT

DBNAME

FACADE

PROPERTY

RETRIEVAL

UPDATE

LEGALVALUES

VALIDATION

DEFAULT

8. Konklúzió

Az aspektus-orientált programozás a szoftverfejlesztés új paradigmája. Mint elmélet és technológia ott tart, ahol az objektum-orientáltság húsz évvel ezelőtt: Lehet látni, hogy van értelme, vannak alkalmazási példák, de az ipar még nem vette át az elvet, és még nincsenek kereskedelemi aspektus-orientált keretrendszerek.

A jövőben valószínűleg a jelenleg kapható objektum-orientált class librarykhoz hasonló aspektus-orientált keretrendszerek lesznek, amelyek a programfejlesztést segítik úgy, hogy a "favágást" leveszik a programfejlesztők válláról. Így a programfejlesztőknek a teljes szoftverből elegendő a domainre (conceptal schema) koncentrálni, és egy viszonylag egyszerűen használható eszközzel ehhez hozzáillesztik a teljes, háromszintű, aspektusokkal kiegészített szoftvert az aspektus-orientált keretrendszer állítja elő.

Eme önálló labor célja egy ilyen keretrendszer prototípusának a megtervezése. A 6. fejezetben látható ábrán látható architektúrát generáljuk a domain modell, és a 2-6. fejezetekben definiált leíró nyelv alapján. A következő félév feladata lesz a weaver elkészítése. A weaver részei lesznek:

• Java parser: A domain forrás feldolgozására
• XML parser: Az aspektus leírás feldolgozására
• Aspektus könyvtár: Ezeket a kódrészleteket illeszti a programba