2013 m. rugsėjo 18 d., trečiadienis

Modelių elementų sąryšių specifikavimas



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);
b.    Interpretuojamų kalbų panaudojimas pačių transformavimo taisyklių aprašymui
(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
EMOF (Essential MOF) 2.0[1]
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ą