Norint įvykdyti išeities modelio transformaciją į
tikslo modelį - turime aprašyti tų modelių elementų loginius sąryšius. Toks
modelių elementų sąryšių specifikavimas vadinamas modelių susiejimu (model mapping). OMG mini tris [4, 3-2p.] išeities ir tikslo modelių susiejimo
strategijas:
1. Modelių tipų
(metamodelių) susiejimas - tai toks modelių susiejimas, kai susiejami PIM
modeliavimo kalbos aprašomi tipai su PSM modeliavimo kalbos aprašomais tipais.
Būtent šitam modelių susiejimui svarbus metamodeliavimas, kurio svarba buvo
nagrinėta praeitame skyriuje, nes susiejami vienos modeliavimo kalbos
metamodelio elementai su kitos modeliavimo kalbos metamodelio elementais. 5
pav. pateiktas pavyzdys kaip susiję skirtingo tipo modelio elementai su
metamodelio klasėmis.
6 pav. -- Skirtingų tipų
modelio elementų atvaizdavimas naudojant kaip žymes stereotipus
Modelių tipų (metamodelių) susiejimas yra griežtai formalus, nes
susiejami elementai nurodomi metamodelio lygyje ir tokių būdu apibrėžia
modeliavimo kalbos formalizmą. Toks griežtai formalus susiejimas leidžia
apriboti modeliavimo kalbos vartotoją nuo nekorektiškų modelių sukūrimo.
Modelių
egzempliorių susiejimas - nėra formalus ir griežtas naudojamos modeliavimo
kalbos požiūriu, nes susiejami ne metamodelio elementai, kurie yra modeliavimo
kalbos formalizmo dalis, o jų egzemplioriai. Tokio susiejimo metu - labai
sudėtinga automatizuotai patikrinti sudaryto modelio korektiškumą, pvz. UML
kalba leidžia klasėm uždėti stereotipus, tačiau šitos kalbos formalizmas
nenustato, kokios, mūsų sudaryto modelio, klasės gali tūrėti stereotipą <<entity>>,
o kokios negali.
Tokiu pagrindu eksperimentinėms transformacijoms
pasirinkau metamodeliavimo strategiją ir metamodelių susiejimą, nes jis leidžia
sukurti griežtai apibrėžtus, formalius modelius ir modelių transformacijas.
2.3 Modelių transformacijų specifikavimo strategijos
Transformacijos realizacijoje galime išskirti dvi pagrindines dalis:
transformavimo įrankį ir transformacijos specifikaciją (transformation definition) (žr. 4 pav.). Šios dalys priklausomai nuo pasirinktos realizacijos
architektūros gali būti atskiros arba apjungtos kaip vienas įrankis su
įprogramuotu transformacijos šablonu (transformation pattern). Realizacijos architektūros pasirinkimas priklauso nuo transformacijų
specifikavimo strategijos. Galima tris transformacijų specifikavimo strategijas:
1. Algoritminis transformacijų
realizavimas - tai tokios
modelių susiejimo ir jų
transformacijų realizacijos, kurios
panaudoja jau egzistuojančias algoritmines
programavimo ar
transformavimo kalbas. Galima būtų išskiri:
a. Algoritminių kalbų
panaudojimą (pvz. Java) - čia transformacijos realizacija
fiksuotai įprogramuojam į transformavimo įrankį arba transformuojanti dalis
užkraunama dinamiškai (plug-in);
fiksuotai įprogramuojam į transformavimo įrankį arba transformuojanti dalis
užkraunama dinamiškai (plug-in);
b. Interpretuojamų kalbų
panaudojimas pačių transformavimo taisyklių aprašymui
(pvz. Java );
(pvz. Java );
c. Šablonų kalbų panaudojimas (pvz. XSL, Velocity).
2. Metamodeliavimo - tai
modelių susiejimo ir transformacijų specifikavimo būdas, kuris pagrįstas metamodelių
ir jų programavimo sąsajų
(API) panaudojimu. OMG konsorciumas
paskelbė užklausą pasiūlymams RFP (Request for Proposal) dėl MOF 2.0 užklausų, atvaizdų ir transformacijų (MOF-QVT - MOF Model / Views /Transformations) [7] ir tikisi
sukurti naują standartizuotą transformacijų modeliavimo
kalbą. Transformacijų modeliavimo kalba leistų metamodelių lygyje ir
naudojant modeliavimo priemones susieti modelius ir specifikuoti transformaciją
iš vieno modelio į kitą. OMG jau gavo atsakymų į MOF-QVT RFP, tačiau šita MOF metakalbos dalis dar nestandartizuota iki šio
momento. Vienas šio darbo tikslų - realizuoti eksperimentinę modelių
transformaciją. 2.2 skyriuje pasirinkome metamodelių susiejimo strategiją mūsų
eksperimentinės transformacijos realizacijai. Šiai realizacijai laikantis
labiausiai tinkantis transformacijų specifikavimo metodas būtų transformacijų
modeliavimo kalba, nes jos priemonėmis galima būtų formaliai susieti modelius
ir tuo pagrindu realizuoti vaizdinio modeliavimo įrankius. Kadangi
metamodeliavimo principu besiremiančio
transformacijų modeliavimo
standarto nėra, tai pasirenkame algoritminį transformacijų realizavimo būdą.
Programinių realizavimo priemonių pasirinkimas bus analizuojamas 2.4 šio darbo
skyriuje.
2.4 Transformacijų realizavimo priemonės
Transformacijoms realizuoti pasirinkau Java programavimo kalbą. Ši
kalba gana populiari, jai tiekiama daug programavimo aplinkų ir bibliotekų.
Taip pat šios programavimo kalbos pagrindu sukurta J2EE (Java2 Enterprise Edition) platforma vis dar pati populiariausia įmonės lygmens (enterprise) interneto programų kūrimo platforma, o būtent įmonės lygmens
programinei įrangai yra svarbūs tikslai kurių siekiama MDA.
Atlikdamas tyrimą
užsibrėžiau sukurti išeities ir tikslo modelius ir realizuoti jų
transformaciją. Tokiu būdu mums reikia: 1) Specifikuoti išeities metamodelį;
2)
Specifikuoti
tikslo metamodelį;
3)
Sukonstruoti
išeities modelį;
4)
Realizuoti
transformaciją:
a. Išeities modelio nuskaitymą;
b. Išeities modelio elementų manipuliavimą ir jų susiejimą su tikslo
modeliu;
c. Gauto tikslo modelio išsaugojimą.
OMG apibrėžė XMI, kaip standartinį
modelių ir metamodelių saugojimo būdą [9]. Pasirinkus realizacijos kalbą Java,
šiuo metu galima aptikti dvi programavimo aplinkas (frameworks), kurių pagalbą galima būtų realizuoti modelių nuskaitymą ir išsaugojimą
į XMI formato bylas - tai NSUML
(http://nsuml.sourceforge.net/) ir EMF (http://www.eclipse.org/emf).
Šių programavimo aplinkų analizės rezultatai pateikti 3 lent..
3 lent. -- NSUML ir EMF programavimo aplinkų palyginimas
Funkcionalumas
|
NSUML
|
EMF
|
Palaikoma XMI versija
|
UNISYS XMI 1.1
|
XMI 2.0
|
Suteikiamos metamodelių
kūrimo priemonės
|
Nėra
|
• Java interfeisai;
• Ecore editorius;
• XML schemos (XSD);
|
Palaikomos išorinės
metamodelių kūrimo priemonės.
|
MagicDraw
|
Rational Rose
|
Integracija su darbo aplinkom
|
Nėra
|
Eclipse platforma
|
Kurią MOF standarto versiją atitinka galimybės
|
MOF 1.4
|
|
Gauto modelio
manipuliavimo programavimo aplinka (API)
|
Generatorius, kuris sugeneruoja MOF programavimo sąsają.
|
Tiekiamas generatorius, kuris sugeneruoja reikiamas EMF.Edit aplinkos klases.
|
Galimybė išsaugoti
rankomis pakoreguotas kodo dalis vykdant
kitas modelių
|
Nėra
|
Automatiškai apjungia naujai generuojamus ar pergeneruojamus senus
|
programavimo sąsajų
generacijas.
|
|
elementus ir
rankomis realizuotas dalis.
|
Galimybė sukurti gauto
metamodelio egzempliorius.
|
Programiniu būdu.
|
• Programiniu būdu;
• Galima
sukurti grafinį redaktorių.
|
Matome, kad EMF
programavimo aplinka palaiko modernesnius standartus ir suteikia daugiau
galimybių kuriant metamodelius ir manipuliuojant jais. Taip pat EMF
integruojasi su patogia ir šiuo metu greitai besivystančia programavimo
platforma Eclipse (http://www.eclipse.org). Todėl EMF programavimo aplinką pasirinkau eksperimentiniams
metamodeliams sukurti ir jų transformacijoms realizuoti.
[1] Paminėtina, kad EMF aplinka teikia Ecore modeliavimo kalbą. Ecore
pagal funkcionalumą atitinka EMOF 2.0 ir galima ją laikyti EMOF realizacija,
tačiau vengiant painiavos šita kalba vadinama Ecore [10, 37p.].
Komentarų nėra:
Rašyti komentarą