XI. Erdélyi Tudományos Diákköri Konferencia Kolozsvár, 2008. május 23–24.
Objektumorientált programelemzés és tervezés MDA segítségével
Szerző: Lőrincz Beáta Babes-Bolyai Tudományegyetem, Matematika-Informatika kar, Matematika-Informatika szak, III. Év Témavezető: Dr. Darvay Zsolt, egyetemi adjunktus Babes-Bolyai Tudományegyetem, Matematika-Informatika kar, Programozási nyelvek és módszerek tanszék
Tartalomjegyzék 1 Bevezetés .......................................................................................................................................... 3 2 A szoftver-fejlesztés kihívásai ........................................................................................................ 5 2.1 Az alkalmazásfejlesztés problémái a történelem során............................................................. 5 2.2 Modellezés és formalizálás a problémák megoldása? .............................................................. 6 2.3 Következtetések ........................................................................................................................ 7 3 Az MDA előfutárai.......................................................................................................................... 9 3.1 Az UML modellező nyelv......................................................................................................... 9 3.2 Az UML 2 újdonságai............................................................................................................. 10 4 Modellvezérelt fejlesztés (Model Driven Architecture)............................................................. 13 4.1 Szükséges még újabb technológia?......................................................................................... 13 4.2 MDA szabványrendszer .......................................................................................................... 13 4.3 MDA architektúra ................................................................................................................... 18 4.4 Előnyök, sikerek...................................................................................................................... 21 5 MDA oktatóprogram .................................................................................................................... 22 6 Összefoglaló ................................................................................................................................... 23 Bibliográfia ....................................................................................................................................... 24
2
1 Bevezetés A modellezés hasznosságát talán már senki nem vitatja, hiszen összefoglaló modellek nélkül a nagy projektek nem lehetnének sikeresek. A számokat összeadó programot fölösleges lett volna modellezni, de a mai informatika kihívásai nagyot fejlődtek és a valós életben már szinte kizárólag nagy és komplex feladatokat kell megoldani. A kérdés napjainkban úgy tevődik fel, hogy mely modellek alkalmazása a legmegfelelőbb adott helyzetekben. Győződjünk meg méginkább a modellezés fontosságáról. A modell szó alapvető értelme: „egy minta, terv, ábrázolás (különösen miniatürizálva), vagy pedig egy tárgy, rendszer, fogalom szerkezetének, vagy működésének leírása”1. Vizsgáljuk meg a számunkra érdekes értelmet, vagyis informatikai rendszerek modellezését. A modellek a fizikai rendszerek absztrakcióját szolgáltatják, mely segítségével a fejlesztők átfogó képet kapnak a rendszerről, még mielőtt a részletekben elvesztődnének. A tervezés bármilyen formája modellekre támaszkodik, annak érdekében, hogy komplex, valós világbeli rendszereket megértsen. Modelleket sokféle formában alkalmazunk. A modellek lehetnek a fizikai rendszerek implementációinak előfutárai, vagy származtathatóak egy létező rendszerből, esetleg fejlődésben lévő rendszerből, mint segédeszköz viselkedésének a megértésére. Mivel a rendszer sokféle tulajdonságának ábrázolásában érdekeltek vagyunk, változatos modellezési fogalomra és jelölésrendszerre van szükség, hogy a rendszer egyéni nézeteit kiemelje, attól függően, hogy a feladat megoldásának időpontjában mi a releváns, lényeges. Továbbá egyes esetekben a modellek kiegészíthetőek útmutatásokkal, szabályokkal, melyek elősegítik egyik reprezentációból a másikba való alakítást. Gyakran szükséges a rendszer nézeteinek átalakítása egy azonos
absztrakciós
szinten
(pl.
strukturális
nézetből
a
viselkedés
nézetébe),
és
a
modelltranszformáció automatizált módon teszi ezt lehetővé. Más esetekben a modelleket különböző absztrakciós szintek között kell alakítani, általában egy kevésbé absztrakt modellé. A modellek és a modellvezérelt alkalmazásfejlesztés az MDA megközelítés magját képezik. Minél jobban megértjük a szemléletet, annál inkább profitálhatunk a modellek alkalmazásából. A szoftver tervezés világában a modellezésnek gazdag hagyománya van a programozás kezdeitéig visszanyúlva. A dolgozat során röviden visszatekintünk ebbe a múltba, a jelentősebb lépéseket megemlítve, melyek a mai elterjedt alkalmazásfejlesztés alapját képezi, az UML modellező nyelv, mint alapjelölésrendszerből kiindulva. Az UML-ből kiindulva, ennek bővítéseit is kifejtve eljutunk az MDA-ig, mely a modellező nyelv mellett bevezeti a MOF metamodellt, mely ugyan magába foglalja az UML-t, de emellett a CWM adatmodelleket is. 1
http://hu.wikipedia.org/wiki/Modell
3
Az utóbbi pár évben sok vállalat figyelt fel a modellvezérelt alkalmazásfejlesztésre, mely segítségével megközelíthető az alkalmazás tervezése és implementációja is. Az MDA olyan elveket fogalmaz meg, melyek a rendszer modellek gyakorlatias és hatékony használatára biztat a szoftver tervezési folyamatban, és az újrahasználhatóságot is lehetővé teszi a rendszercsaládok esetén. A szerzők (OMG – Object Management Group) szavaival élve, az MDA egy mód a vállalati architektúrák megszervezésére, irányítására és megszerkesztésére, olyan automatizált eszközökkel és szolgáltatásokkal alátámasztva, melyek a modellek meghatározását és az átalakítást különböző modellek között is lehetővé teszik. A következőkben vizsgáljuk meg a modellvezérelt architektúra összetevőit, ezek előnyeit és nem utolsó sorban gyakorlatban való alkalmazásukat.
4
2 A szoftver-fejlesztés kihívásai 2.1 Az alkalmazásfejlesztés problémái a történelem során Fassen wir noch einmal zusammen, was wir über das Problem wissen, Dann wird die Lösung sich von selbst aufdrängen.2 Eduard von Hartmann
Több mint 30 év óta merülnek fel problémák a szoftver-fejlesztésben, állandóan új igények jelentkeznek.
Alapvető
elvárás,
hogy
a
szoftvertermékek
folyamatosan
és
gyorsan
alkalmazkodjanak a változó igényekhez. Annak ellenére, hogy jelentős előrehaladásoknak lehetünk szemtanúi ezen a téren, még nincsen minden probléma megoldva. Tekintsünk kicsit vissza a múltba. A 70-es évek közepén - amikor a szoftver alkalmazások egyre komplexebbek lettek, illetve megjelentek az objektum orientált programozási nyelvek – felmerült az igény elemzési és tervezési módszerek használatára. A szakemberek, akik komplex fejlesztési folyamatokban dolgoztak, rájöttek, hogy a szemléltető eszközök, diagramok, ábrák nagy mértékben elősegítik a fejlesztést. Különböző vizualizációs technikákat alkalmazva egyszerűbbé és világosabbá vált a fejlesztési munka, a fejlesztők, illetve fejlesztők-felhasználók közötti kommunikáció. Hamar felmerült az egységesítés iránti igény, hiszen komoly problémát jelentett az alkalmazkodás olyan fejelsztőknek, akik egyszerre több projektben vettek részt, és esetleg több féle módszertan szerint kellett dolgozniuk. A kifejlesztett módszerek többsége azonban ebben a kezdeti fázisban még nem tudott egyértelmű fejlesztési lépéseket meghatározni, illetve nem volt képes a rendszer bonyolultságát általánosan kezelni. A többféle megjelenített módszertan csak a 90-es években vált annyira hatékonnyá, hogy fejlesztési folyamatokban eredményesen tesztelték és alkalmazták. A 90-es évek második felében már sok különböző OO-módszertan létezett, de a választás nehézsége még mindig bizonytalanná tette a fejlesztőket. Az egységesítési törekvések eredményeként, egy évtizednyi munka eredményeként megjelentek a RUP (Rational Unified Process), illetve az UML (Unified Modelling Language) első verziói. Az Ericsson cég módszertani kutatásai jelentették a kezdetet, majd erre épült az Objectory módszertan.
2
Foglaljuk össze azt, amit a problémáról tudunk, majd a megoldása magától adódik.
5
1996-ban jelent meg az egységesített modellező nyelv alapverziója, majd 1998-ban véglegesítették a RUP módszertanát, számos más szerző tapasztalatait és módszertanát figyelembe véve. 3 Hogy mit hozott az ez utáni időszak a következő fejezetekben részletesen kibontjuk.
2.2 Modellezés és formalizálás a problémák megoldása? Das Symbol, das Modell, die Hypothese geht dem Darzustellenden parallel. Aber der Paralellismus kann weiter reichen, oder weiter geführt warden, als es bei der Wahl dieser Mittel ursprünglich beabsichtigt war. Indem das Dargestellte und das Darstellungsmittel doch verschieden sind, fällt an dem einen auf, was an dem anderen verbogen bleiben würde.4 Ernst Mach
Tehát a probléma középpontjában a szoftver-rendszer modellezése, illetve a felhasználó nemformális, konkrét követelményekkel rendelkező világából az informatikus formalizált világába való átlépés áll. A követelményekből kiindulva a szoftver termékig és annak érvényesítéséig számos kihívással kell szembenézni, melyek inkább gyakorlati jellegűek, mint elméletiek. Vizsgáljuk először a modell, illetve modellezés fogalmát. A modellezés témakörében különbség van a módszertan és a modellező nyelv fogalma között. A módszertan meghatározza, hogy mit és hogyan kell végrehajtani, illetve hogy miért van szükség a feladat elvégzésére. A módszertan fontos építőelemei a módszerek, olyan eljárások, amelyek előre megadott szabályok szerint működnek. A módszertan az absztrakció alapelveire épül, eredményeit különböző formákban lehet ábrázolni, reprezentálni. Kifejezhetjük akár szóban, leírhatjuk szövegesen, vagy különböző szabályokat alkalmazva le lehet rajzolni. Ennek a kifejezésnek a formáját nevezzük modellező nyelvnek. Ez a nyelv egy szimbólumrendszerből épül fel, melyben az elemek formája és az elemek egymáshoz kapcsolódása jól definiált (szintaktikai szabályok). Ezeket a szabályokat a felhasználóknak azonos kontextusban és azonos módon kell alkalmazni, azaz a szemantikai szabályoknak megfelelően. A modellező nyelv csak akkor éri el célját, ha a szimbólumok segítségével érthetővé teszi az ábrázolandót. Ez a pragmatikai szabály a legfontosabb. Annak ellenére, hogy sok modellező nyelv 3
M. Raffai, UML 2 modellező nyelv, Palatia, 2005, 19. oldal
4
A szimbólum, a modell, a feltevés, az ábrázolandóval párhuzamban áll. Ez a párhuzam azonban tovább érhet, vagy tovább vezethető, mint ahogy ennek az eszköznek a kiválasztásánál eredetileg elképzeltük. Mivelhogy az ábrázolt és az ábrázolási eszköz különbözőek, feltűnik az egyikben, ami a másikban elrejtve maradt.
6
eleget tesz a szintaktikai és szemantikai szabályoknak, kevés az olyan, mely a pragmatikai szabályokat is kielégíti. A fejlesztők feladata a nyelv szemléletének elsajátítása és szabályainak pontos használata. A nyelv használatának eredményessége a fejlesztőkön múlik. A modellező nyelv és a programnyelv bizonyos vonásokban nagyon hasonlít egymásra, rendelkeznek meghatározott és absztrakt szintaktikával, szemantikai szabályokkal, de az absztrakció szintjében és elérni kívánt céljukban azonban lényeges az eltérés. A modellező nyelv a valós rendszer követelményeire, a valós elemekre, folyamatokra és viszonyokra épül, míg a programnyelvnél a tényleges megvalósításon van a hangsúly, azokon a műveleteken, amelyek a számítógépen való működést valósítják meg. A konkrét szintaxis is különböző, a modellező nyelv valamilyen szimbólumok használatával elkészített diagram, míg a programok meghatározott formában készített utasítások sorozatából állnak. Természetesen a programnyelvekben is találkozunk szöveges leírásokkal, de formája eleget kell tegyen formai szabályoknak, mely szerint alkalmas gépi fordításra a program. A modellező nyelv fontos szerephez jut az alkalmazás fejlesztési folyamatában, mert különböző szakemberek által érthető és kezelhető módon reprezentálják a rendszer funkcióit. Ha rendelkezésünkre állnak, a modellező nyelvből programnyelvbe átalakító szoftverek, és ezeket alkalmazzuk az alkalmazásfejlesztésben, akkor modellvezérelt fejlesztésről beszélünk.
2.3 Következtetések A természetes nyelvben megfogalmazott követelmények, melyek nem formális modellek formájában állnak a fejlesztők rendelkezésére, nem olvasható, illetve nem értelmezhető formálisan, és így nem alakítható automatikusan. Először a design, illetve implementálás során használhatóak a formális nyelvek.
7
Állandóan növekvő ráfordítás kevésbé formalizált kezdeti modellekkel, leírásokkal
Ha az a fenti ábrával ellentétben a formalizálás szintje magasabb lett volna kezdetben, vagyis az elemzési fázisban, nemcsak számos hibát lehetett volna kiküszöbölni, hanem a munka egy részét automatizálni lehetett volna, úgyhogy a ráfordítás összességében csökkent volna.
Magasszintű formalizálás magas fokú automatizálást tesz lehetővé Csökken a ráfordítás a formalizálás és automatizálás segítségével
Egy központi kérdés a formalizálásban még mindig nyitott marad: hogyan készítjük el a szoftver-architektúrát, és mi a célfelület? Ezeket először formálisan definiálni kell ahhoz, hogy automatikus továbbfejleszthessük transzformációk segítségével, melyek végeredménye futtatható 8
kód. Pontosan ezt a szemléletmódot ülteti gyakorlatba az MDA a felületfüggetlen, illetve felületfüggő modellek használatával. Mielőtt az MDA használatát bővebben fejtegetnénk, vizsgáljuk meg a diagramokat, eszközöket, melyekből kiindul a modellvezérelt fejlesztés.
9
3 Az MDA előfutárai 3.1 Az UML modellező nyelv Egy tulajdonság elveszítésével, a tárgy mégis megőriz valamit abból, amit elveszít, de már valamit felmutat abból is, amivé válik. Egyáltalán, amikor valami elmúlik, megőriz valamit a létéből, és amikor valami keletkezik, muszáj valaminek lennie, amiből létrejön, de ez nem folytatódhat a végtelenségig. Tegyünk még egy megjegyzést, hogy nem egy és ugyanazt jelenti: változtatás a mennyiségre nézve, és változtatás a minőségre nézve. Aristoteles – Metafizika
A tudomány különböző területeinek megvan a maga sajátos nyelvezete, melyet az illető tudományág szakértői bizonyára értenek és értelmezni is tudnak. Ha a világ bármely pszichológusa az SR képlettel találkozik, akkor tudni fogja, hogy ez a behavioristák egy elméletéból származik, akik arra törekedtek, hogy a jelenségeket inger-válasz (stimulus-reaction) kategóriák segítségével írják le. Annak ellenére, hogy ez egyszerűnek tűnik, egy bonyolult elmélet áll mögötte. Tehát a pszichológusoknak van egy közös nyelvezete, de így van a zenészeknek, kémikusoknak és bármely más foglalkozásnak. Erre volt szüksége a szoftver-engineeringnek is. Tehát a Unified Modelling Language, vagy az UML, egy grafikus modellező nyelv, mely a szoftver-rendszereket modellez különböző nézetekben, vagyis egy olyan jelölésrendszer, melyben modellek és diagramok adhatóak meg különböző nézetekben, úgy hogy függetlenek maradjanak a felülettől, melyben alkalmazni fogják. Az OMG (Object Modeling Group), definíciója szerint: "Az egységesített modellező nyelv (UML) egy grafikus nyelv egy szoftver-intenzív rendszer termékeinek megjelenítésére, specifikálására, felépítésére és dokumentálására. Az UML szabványos lehetőségeket kínál a rendszer felvázolásához, beleértve a fogalmi dolgokat, mint üzleti modellezés és rendszerfunkciók, valamint a konkrét dolgokat, mint programnyelvi utasítások, adatbázis sémák és újrafelhasználható szoftverkomponensek." 5
5
M. Raffai, UML 2 modellező nyelv, op. cit., 71. oldal
10
3.2 Az UML 2 újdonságai At last ... the OMG’s long-awaited release of UML 2.0! Why has this version lurked on the horizon for so long? Three simple words: Model Driven Architecture (MDA).6 Scott Ambler – Software Development
A 2003/2004-es évek folyamán fejlesztették ki a UML nyelv második szabványverzióját, alapos felülvizsgálat után 2004 októberében hagyták jóvá.
Mivel az első szabványverziónak olyan
hiányosságai voltak, melyek az egyre inkább elterjedt webalkalmazásoknak és osztott rendszereknek a megváltozott igényeihez nehezen tudtak alkalmazkodni, komplex megoldásokra volt szükség. Az UML 2.0-t a fejlesztők és felhasználok véleményének figyelembe vételével bővítették, és az új kihívásokhoz igazították. A legfontosabb módosításokat az MDA szabványhoz igazítva a szemantikai szabályokra, a szimbólumok használatára, és a kiterjesztési mechanizmusban használt lehetőségekre hajották végre. A változtatásokat a következőképpen foglalhatnánk össze röviden: o Fejlődtek az architektúra-orientált diagramok: a komponens, fejlődés és csomag diagramok. A komponens diagramok, mint részletes design diagramok támogatják az adat, illetve interface modellezést, tükrözve a „minden egy komponens”
általános
nézetet. Ezeket a szerkezeteket alkalmazás és vállalati architektúráknak javasolják. o Az
aktivitásdiagram
(tevékenységdiagram)
egyértelműen
külön
vált
az
állapotdiagramtól. Ezután nem az állapotmenetekre, hanem a folyamatokra, az elágazási pontokra, a feltételekre és a párhuzamosságokat figyelembe vevő ábrázolási megoldásokra
összpontosít.
Objektum
modellezés
helyett
üzleti
folyamatok
modellezésére javasolják. o A szekvenciadiagramban lehetőség van egyes események/üzenetek leválasztására. Ez komplexebb struktúrák ábrázolását teszi lehetővé, illetve a diagram egyes részei más típusú ábrázolásban is felhasználhatóak. o A régi együttműködési diagramban a hangsúly valóban az együttműködésre kerül, a kommunikáció pontos leírását ezután a kommunikációs diagram valósítja meg.
6
Végre ... az OMG régen várt UML 2.0 kiadása! Miért rejtőzködött ez a láthatáron olyan sokáig? Három egyszerű szó: Modell Vezérelt Architektúra (MDA).
11
o Az új időzítésdiagrammal leírhatóak a időbeli folyamatok, és követketőek az időbeli állapotváltozások. Az időzítésdiagramon kívül két új diagramot vezettek be, az interakciós, illetve kommunikációs diagramot. o UML 2-ben lehetőség van a diagramrészletek egybefoglalására, és más diagramokban történő hivatkozott felhasználására. Az MDA koncepcióját figyelembe véve az UML 2 nem csak egy ábrázolási technika, hanem egy absztraktabb nyelv, mely „az OCL nyelvvel a MOF és XMI szabványokhoz illeszkedve lehetővé teszi a különböző platformokon működő, egymástól eltérő rendszerek információinak azonos módon történő értelmezését, az elemek együttműködését, a modellek automatikus transzformációját”7.
7
M. Raffai, UML 2 modellező nyelv, op. cit., 122. oldal
12
4 Modellvezérelt fejlesztés (Model Driven Architecture) 4.1 Szükséges még újabb technológia? A fejlesztési hatékonyság egyik akadályozója a hagyományos alkalmazásfejlesztési szemlélet követése és az új technológiák összeférhetetlensége. Komoly gond az alkalmazások különböző platformok közötti hordozhatósága, illetve a dokumentációk karbantartásának a hiánya. Újrafelhasználhatóság és automatizálás segítségével, formális és standardizált nyelvek következetes használatával sok kérdést meg lehet oldani. Ezen a ponton lép színre az MDA és OMG (Object Managment Group). Elsősorban az MDA és MDA-eszközök biztosítják, hogy a modellek átalakítása kóddá automatikusan történjen, ahelyett, hogy azt manuálisan szerkesztenénk meg. Egy rendszer formalizált lényegét a technológiai felülettől függetlenül, modellek formájában fejleszteni és jobbítani lehet, majd a szükséges változtatások elvégzése után kerül sor a megfelelő kód generálására. Ha változnak a felületek, akkor a felületfüggetlen modellt csupán az új felülettel kell kombinálni, és létrejön az új szoftver a régi modellre alapozva. Az MDA-val kapcsolatban feltevődik a kérdés, hogy a modellezés és formalizálás a szoftver engineering problémáinak megoldására elegendő-e. A továbbiakban sor kerül az MDA módszereinek bemutatására és elemzésére.
4.2 MDA szabványrendszer „A programozók régi álma, amikor majd program fog programot írni. Soha nem értettem ezt a dolgot, ez olyan, mintha egy buszvezető álma az lenne, hogy robot vezesse a buszt, szerencsére messze vagyunk még ettől az álomtól... Vannak azonban olyan helyzetek, amikor a favágó munkát célszerű ráhagyni a gépre. Mind ismerünk különféle fejlesztőkörnyezeteket, amelyek kisebb-nagyobb mértékben képesek kódot generálni, beírt kódot ellenőrizni, illetve kódot kiegészíteni. Egyszerűen arról van szó, hogy a nem kreatív munkát megcsinálja a gép.” Java Forum, Gábor
13
Az MDA az Object Managment Group (OMG) egy újabb standardja, mely megalkotását 1989ben kezdték el. Közben az OMG nemzetközi szervezetté vált, melynek világszerte több mint 800 tagja van. Célja az objektumorientált technológiák elméleti megközelítése és alkalmazása. E cél elérése érdekében számos irányelvet és specifikációt fogalmazott meg, melyek objektumalapú alkalmazások heterogén és osztott környezetekben való futtatását teszi lehetővé úgy, hogy ezek újrafelhasználhatóak, hordozhatóak, illetve kommunikációra képesek legyenek. 2000-ben tették nyilvánossá a kezdetleges változatát, és jelölték az MDA fogalommal. A grafikus szimbóluma megmagyarázza a stratégiáját.
Az MDA hivatalos szimbóluma A modell magja az OMG specifikáció 3 fontos alkotóelemét tartalmazza, a MOF-t (Meta Object Facility), az UML-t (Unified Modelling Language) és a CWM-t (Common Warehouse Metamodel), melyre a köztesrétegmodellek alapoznak. Ezeket a szoftver-architektúra különböző szempontjait biztosítják, mint például a biztonságot. A kifele mutató nyilak az alkalmazási területekre utalnak, melyekért a modellt szerkesztjük. A vezérelv egyszerű és hatásos: modelleket precízen és géppel leolvasható formában tervezni, hogy az absztrakciós szintek architektúráit automatizálni lehessen. Semmilyen mesterséges akadály, mint pl. összeférhetetlen operációs rendszerek, nem szabad a szoftver rendszer fejlődését akadályoznia. Ezt csak a különböző koncepciók és technológiák együttműködésével lehet elérni. Milyen újdonságot hoz az MDA az UML-lel szemben? A modell vezérelt architektúra egy új megközelítése az alkalmazásfejlesztésnek. Kiindulópontja platformfüggetlen UML modell, 14
melyhez kapcsolódik egy vagy több platform specifikus modell. Először a rendszer funkcionalitására és viselkedésére kell koncentrálni, a technológiai környezettől eltekintve. Ily módon a rendszer teljes modelljét csak egyszer kell megalkotni. Az MDA szemlélet egy alapvető eleme az alkalmazás-architektúra elkülönítése a rendszer architektúrától. Az alkalmazásarchitektúra az alkalmazás funkcionális céljait meghatározó összetevőket és kapcsolatokat specifikálja. A rendszer-architektúra pedig az alacsonyabb szintű komponensekből és kapcsolatokból áll, melyek az alkalmazás-architektúra végrehajtását teszik lehetővé. Vizsgáljuk meg a hivatalos szimbólum összetevőit. A közös magot három tényező alkotja az UML, MOF és CWM. Ahhoz hogy a fejlesztők azonos módon értelmezzék a modellezéshez használt elemeket, szükség van a modellező nyelv építőelemeinek általános leírására. Hogy azt a metamodellkoncepciót megvalósítsuk a modellelemeket, -struktúrát és -jellemzőket definiáló MOF-szabvány tölti be kulcsszerepet. A MOF
„egy technikai megoldás metaadatok definiálására olyan
fejlesztésekben,
doménmodellt
amelyek
a
objektumosztályokká
és
különböző
viselkedésmodellekké képezik le.” A modellekre vonatkozó információkat egy repositoryban tárolja. Alapvető célja, hogy a metamodellek együttműködésével lehetővé tegye a különböző platformokon a kommunikációt. Tulajdonképpen egy leegyszerűsített osztálydiagram, mely képes a különböző modellszintek információinak integrálására.
15
A MOF metaadat architektúrája
A meta-metaModell réteg absztrakt nyelvi formában kifejezett információkat tartalmaz a metametamodellekre vonatkozóan. M3: a metaModell réteg a modellek tulajdonságait leíró információkat tartalmazza. Egy absztrakt nyelv a különböző modellek és modellnézetek leírására, amely modellkomponenseket, szerkezeteket és szemantikát definiál. M2: a Modell réteg információkat tartalmaz a valós folyamatokról és elemeiről. Ezeket a jellemzőket informális módon alkalmazzuk a metamodellekben. M1: az információs réteg a modellezett valós világ tulajdonságait írja le, annak elemeit és viselkedését tükrözi. Az M0 réteg az információs rétegben meghatározott modellelemeket valós objektumokkal, kapcsolatokkal valósítja meg. Következtetésképpen megfogalmazhatjuk, hogy a MOF a metamodelljét alkotja az UML metamodellszinteknek és más specifikációknak, mint a CWM. Az MDA-ban felhasznált 16
modellrészeket (PIM, PSM, PM) és nézeteket (szintek), mint az UML, de más modellnyelveket is alkalmazhatunk, melyek metamodellje a MOF metamodellre alapoz. A MOF lehetővé teszi a navigálást egy eset és a metaobjektuma között, egy absztrakt szintaxist definiál egy nyelv számára a metamodell alkalmazásának segítségével, egy megvalósítási példa az UML, de ez csak egy lehetséges megoldás, OCL-kifejezéseket is használhatnánk. Eredményképp egy magasabb szintű kommunikációt kapunk, mely az MDA számára különösen fontos, mert nemcsak egyetlen eszköz áll rendelkezésünkre, anélkül, hogy az információcserére lehetőség lenne. Az eszközlánc felépítéséhez, és a hozzá kapcsolódó transzformációknál fontos szerepet tölt be a MOF. A különböző formátumban tárolt adatok átalakítására és egységes kezelésére van szükség. Olyan karbantartható adattárra van szükségünk, mely lehetővé teszi a különböző szintű döntési folyamatok támogatását. A CWM (Common Warehouse Model) valójában olyan keretrendszer, mely különböző adatforrásokat és céladatokat kezel, adatműveleteket, valamint az átalakítás és az elemzés módjára vonatkozó metaadatokat tartalmazza. Ez a szabvány specifikálja a vállalatok különböző adatbázisainak az együttműködését, és garantálja az adatbázisok közötti átjárhatóságot, leírja az adatmodellezés és –implementáció szabályait, az adatbázissémák leképezésének formáit és módját. A CWM metamodell a következő almetamodellekből tevődik össze: o A Data Resources a relációs és az objektumorientált rekordok, valamint a multidimenzionális és az XML-adatforrások metainformációi. o A Data Analysis metamodell az adattranszformációs eljárásokat, az OLAP (On Line Analitycal
Processing),
az
adatbányászati,
az
információmegjelenítési
és
az
üzleti/szakterületi adatok. o A Warehouse Managment metamodell az adattárház-műveleteket és azok eredményeit képviseli. A CWM megoldást kínál a vállalatoknál felhalmozódott adatok rendszerezésére. Fontos megemlíteni a CWM Web Services kiterjesztést, mely a webimplementációk metaadatok továbbítására vonatkozó szintaktikát és szemantikáját írja elő és a metaadat forgalmat szabványosítja.
17
A CWM modell struktúrája táblázatba foglalva: Folyamatelemek Adattárház
Transzformáció
Műveletek OLAP Adat-
kezelő
bányászat
Információ-
Domén-
megjelenítés
megvalósítás
rendszer Modell-
Objektum-
Relációs
Rekor
Többdimenziós
elemek
modell
modell
dok
megvalósítás
Adattípus
Kifeje
Kulcsok,
Típus
Szoftverek
zések
indexek
leképezés
futtatása
Szakterületi Üzleti komponens
információk ok
XML
Objektumok architektúra- és viselkedésmodell nézetei
4.3 MDA architektúra Vizsgáljuk meg az architektúra összetevőit, abban a sorrendben, melyben alkalmazzuk őket.
Frankel D., 2003. The Zachman Framework and the OMG's Model Driven Architecture
A CIM modell Egy Computation Independent Model (CIM), melyet a Domain Model vagy Business Model kifejezésekkel is szoktak jelölni, a rendszert minden hard- és szoftverelemtől függetlenül írja le, vagyis a a rendszer használata és működése áll a figyelem középpontjában. Hasznos a fejlesztendő 18
rendszer megértése szempontjából, és egy közös terminológia megteremtése szempontjából. Ideális esetben a CIM-ből az út a PIM és PSM irányába is követhető. Például egy CIM modell egy UML osztálydiagram formájában áll rendelkezésre, mely a rendszer követelményeit írja le. A CIM modell létrehozásánál segítő eszközök az elemzési minták, olyan modellei a rendszerelemzésnek, melyek magas általánossági- és absztrakciós szintekkel rendelkeznek. Sok elemzési minta (Analysis Patterns) áll rendelkezésre, mint például Party, Organization Structure, Transactions, Contract, Product. Egy érdekes kiegészítése a CIM modellnek az Archetype Patterns. Az archetípusok olyan tényállasok, melyek állandóan előfordulnak, olyan előredefiniált modell komponensek, melyek az átmenetet képezik a PIM modellhez. Következetetés: a CIM modell nem részletezi a rendszer szerkezetét, nem igényel mély modellelméleti ismereteket, sem elképzeléseket a megvalósításról. Fontos szerepet játszik azok között, akik a rendszer doméniumának és követelményeinek szakértői, illetve a design és megvalósítás szakértői.
Példa CIM modellre, mint UML osztálydiagram
A PIM modell A modellvezérelt szoftver-fejlesztés esetében fontos egy olyan platformfüggetlen modellt (Platform Independent Model) megalkotni. A modell alkotásánál csupán szakmai szempontokat veszünk figyelembe, és ezeket modellezzük. Az így létrejött modell akkor is érvényes, ha semmilyen szoftvert nem fejlesztünk segítségével, ezeket a félig formalizált modelleket valóban használják a például az üzleti folyamatok elemzésénél és optimalizálásánál (Business Process Re-Engineering). De leggyakrabban ezek a modellek szolgálnak alapul a fejlesztendő szoftver rendszernek.
19
A CIM modellből kiindulva ezt finomítva, részletezve megkapjuk a PIM modellt, de mégis nagy a kettő közötti különbség, egy PIM modell – a CIM modellel ellentétben – megfelel az MDA formális elvárásainak, melyek segítségével a koddá átalakítás végrehajtható, vagyis a formalizálási szint minősége lényegesen magasabb. Míg a CIM modell esetében a leírások a természetes nyelvhez nagyon közel állnak, ez elfogadhatatlan a PIM modell esetében.
Példa PIM modellre, mint UML osztálydiagram
A PSM modell és implementáció (PSI) Egy platform-modell (PM) vagy platformleíró (Platform Descriptor) a PIM vagy PSM-tól függetlenül egy alapot specifikál a létrehozandó szoftver rendszerekhez. Középpontjában a platform struktúrái
és
szolgáltatásai
állnak.
A
platform-modellek
lehetnek
generikusak,
technológiaspecifikusak. Ha már kidolgoztuk a CIM, illetve PIM modellt, még egy lépés választ el a használható kódtól. A PIM modellból kiindulva automatikus transzformációval megkapjuk a célfelületet a PSM (Platform Specific Model) modellt, a PM segítségével. Ezt a modellt a PSI névvel is szokták jelölni, ami még kifejezőbb: Platform Specific Implementation, vagyis a Source-Code az eredmény. PIM modelleket automatizáltan alakítunk PSM modelleké, a fordított műveletre még nem alkottak programot, de erre igény sincs, mivel először tervezünk és utána implementálunk.
20
4.4 Előnyök, sikerek MDA – A Life Cycle, Not Just a Model „In the same way, models are just not a few fancy diagrams designed to temporarily visualize a problem or to impress project sponsors or developers. Models can be the lifeblood of the enterprise. They can flow smoothly through different layers. That is why MDA is so important to the current enterprise systems. A model has its own identity, behavior, and value, as objects do.”8 Jax Magazine, 2007 April, MDA T.R.E.N.D.
Ahhoz, hogy a szoftverfejlesztéssel szemben támasztott elvárásokat a fejlesztők teljesíteni tudják gyors megoldásokra van szükség. Feltevődik a kérdés, hogy hogyan őrizhetjük meg az eddigi szoftver befektetésünket. A már létező szoftver alapot fel kellene használni, a minőségi munkát meg kellene őrizni, a létező kódalapot karbantartani, és integrálni azt amit már megépítettünk, azzal amit építeni fogunk. Az MDA szabvány erre is irányul, az alkalmazott megoldásoktól függetlenül lehetővé válik különböző korábbi modellelemek felhasználása, illetve a fejlesztési raktárakban (repository) tárolt információk projekten belüli vagy projektek közötti megosztása. Ahhoz, hogy a munkafolyamatok eredményesek legyenek a fejlesztőknek alkalmazkodni kell a formai követelményekhez. Ahhoz, hogy a megoldások kompatibilisek legyenek, az MDA keretrendszer leírja a technológiától független funkcionalitását és viselkedését a rendszernek, lehetővé teszi a különböző szinteken definiált modellek automatikus transzformációját, valamint biztosítja a különböző felületeken futó alkalmazások együttműködését.
8
Hasonlóképp, a modellek nem csak egy pár különlegesen szerkesztett diagram, melyeket azért szerkesztünk, hogy időszakosan ábrázoljunk egy problémát vagy meghassuk a projekt szponzorait és fejlesztőit. A modellek lehetnek a vállalkozás nélkülözhetetlen elemei. Simán áramolhatnak különböző szintek között. Ez az amiért olyan fontos az MDA a mostani vállalati rendszereknek. A modellnek megvan a a saját identitása, viselkedése, és értéke, mint az objektumoknak.
21
5 MDA oktatóprogram Egy saját alkalmazáson keresztül lehetőség van a modellvezérelt architektúra egy rövid elméleti áttekintéséhez, illetve gyakorlatok, tesztek végzéséhez interaktív felületen. A program főmenüjében megjelennek az architektúra alapvető elemei, mint a MOF, CWM és UML, a MOF-ról és CWM-ről rövid leírást olvashatunk, míg az UML gombra kattintva megjelenik egy újabb menü, mely az UML 2.0 összes diagramtípusáról tartalmaz leírásokat. A diagramnevek megjelennek a menüben,
ezek leírása tartalmazza a diagram létrehozásának célját, ennek
értelmezését, azaz a diagramok rendszerbeli funkcionalitását, és a modellelemeket. Minden diagramtípust példa tesz világossá, melynek modellelemeit lépésekben tekinthetőek meg, az elméletben megjelenő sorszámozásnak megfelelően. Az elméleti részben megjelenik még egy leírás a modellvezérelt alkalmazásfejlesztésről általánosan. A gyakorlati rész két részre osztott, lehet egyszerűen tesztkérdésekre válaszolni, a kiértékelésre az összes kérdés megválaszolása után kerül sor. A gyakorlat másik része interaktívabb, diagramrészeket kell felismerni, ezek közötti különbségeket megállapítani, illetve ábrákat összerakni. Az alkalmazás használatávál rövid betekintőt nyerünk a témába.
22
6 Összefoglaló Az MDA eredményeinek sikerei azt suggalják, hogy szükség van a modellezés elméletével foglalkozni, illetve ezt alaposabban oktatni, hogy növekedjen a fejlesztők száma, akiknek ismert az UML és MDA fogalom, hogy az ezek által felkínált lehetőségeket jobban ki tudják használni. Több figyelmet kellene fordítani arra, hogy a kliensek/felhasználók miként vegyenek részt a fejlesztési folyamatban. Ez azt javasolja, hogy az UML nem kizárólagosan csak szakértők számára érthető nyelvnek kell lennie, hanem a diagramok és ezek szerepének megértése a rendszerek megépítési folyamataiban szükséges a szervezetek számára is, akik a rendszereket igénylik. A diagramok egységesítése nagyban hozzájárult e cél eléréséhez. A használati utasítások standardizálása szintén szükséges. Az MDA megközelítésnek több előnye is van, befejezésképp vizsgáljuk meg a legfontosabbakat: o Az MDA fejlesztési folyamatban, a figyelem elsősorban az alkalmazás funkcionalitására és viselkedésére irányul, lehetővé téve a résztvevők számára, hogy azokra a tulajdonságokra összpontosítsanak, melyek jelentősen, kritikusan meghatározzák a rendszer magjának folyamatait. A technikai jellemzők megvalósítása végrehajtható az automatizált, illetve szemi-automatizált fejlesztési eszközök segítségével. o Egy architektúra, mely az MDA-ra alapoz, alkalmazkodik a változó igényekhez, és könnyebbé teszi az alkalmazások integrációját a köztesrétegek között.
23
Bibliográfia 1. Ariadne Training, UML applied, Object Oriented Analysis and Design Using the UML, http://ariadnetraining.co.uk/ 2. Raffai Mária, UML 2 modellező nyelv, Palatia, 2005 3. Roland Petrasch, Oliver Meimberg, Model Driven Architecture, Eine praxisorientierte Einführung in die MDA, Koninklijke Wöhrmann B.V., 2006, (Modell vezérelt architektúra, Egy gyakorlatias bevezetés az MDA-ba) Internetes források: 4. Az OMG hivatalos oldala: http://www.omg.org/docs/formal/07-11-04.pdf, http://www.omg.org/mda/faq_mda.htm 5. Az IBM információi: http://www.ibm.com/developerworks/rational/library/3100.html 6. https://nws.niif.hu/ncd2005/docs/ehu/088.pdf 7. http://www.ddj.com/architect/184415097
24
