OMG’s MetaObject Facility

Końcówka roku, wręcz ostat­ni jego dzień 😉 …

Mając przed ocza­mi kolej­ny pro­jekt badaw­czy, kolej­ny raz gapię się na stro­ny OMG i mała reflek­sja: porząd­ki dobie­ga­ją koń­ca. W arty­ku­le o UML v.2.5. wspo­mi­na­łem, że zre­zy­gno­wa­no w koń­cu z poję­cia agre­ga­cji” (zwa­nej cza­sa­mi sła­bą kom­po­zy­cją”), odcho­dzi się od cał­ko­wi­cie zbęd­nych związ­ków extend” i inc­lu­de” w przy­pad­kach uży­cia (kon­struk­cje te nadal pozo­sta­ją w spe­cy­fi­ka­cji z uwa­gi na kom­pa­ty­bil­ność wstecz narzę­dzi CASE i doku­men­tów jakie w nich są nadal two­rzo­ne lub archi­wi­zo­wa­ne). Paradoksalnie spe­cy­fi­ka­cja UML jest uprasz­cza­na (sta­le tkwi w niej echo pier­wot­ne­go zlep­ku kil­ku nota­cji z lat 99-tych). Oczyma wyobraź­ni widzę jak ktoś, w toku prac nad UML, sta­le wyma­chu­je brzy­twą Ockhama”… 

To oczy­wi­ście nie wszyst­kie porząd­ki. Porządkowana jest tak­że kwe­stia meta­mo­de­lo­wa­nia oraz MDA (Model Driven Architecture). Specyfikacja MOF (Meta Object Facility) to doku­ment (i idea) opi­su­ją­cy podej­ście (meto­dy­kę) OMG, z któ­rą kom­pa­ty­bil­ne są nota­cje z tej staj­ni”. 

The MetaObject Facility Specification is the foun­da­tion of OMG’s indu­stry-stan­dard envi­ron­ment whe­re models can be expor­ted from one appli­ca­tion, impor­ted into ano­ther, trans­por­ted across a network, sto­red in a repo­si­to­ry and then retrie­ved, ren­de­red into dif­fe­rent for­mats (inc­lu­ding XMI, OMG’s XML-based stan­dard for­mat for model trans­mis­sion and sto­ra­ge), trans­for­med, and used to gene­ra­te appli­ca­tion code. (Źródło: OMG’s MetaObject Facility (MOF) Home Page)

Klarują się defi­ni­cje mode­li PIMPSM, porząd­ko­wa­ne są kwe­stie prze­no­szal­no­ści mode­li (stan­dard XMI), dopra­co­wy­wa­na jest auto­ma­ty­za­cja trans­for­ma­cji mode­li. Ta ostat­nia, moim zda­niem, nadal dłu­go jesz­cze pozo­sta­nie w sfe­rze prac aka­de­mic­kich raczej. Nie dla­te­go, że to nie dzia­ła”, a dla­te­go, że nakład pra­cy (licz­ba wyma­ga­nych deta­li) na stwo­rze­nie mode­lu umoż­li­wia­ją­ce­go taką trans­for­ma­cję jest nie­współ­mier­nie duży do korzy­ści z tej auto­ma­ty­za­cji (podob­nie ma to miej­sce w symu­lo­wa­niu pro­ce­sów biznesowych).

Niewątpliwie jed­nak upo­rząd­ko­wa­no kwe­stie eta­pów prac: PIM to model dome­no­wy (dzie­dzi­ny, kon­tek­sto­wy), opi­su­je struk­tu­rę i zacho­wa­nie się okre­ślo­ne­go sys­te­mu, jego usłu­gi. Model PIM to meta­mo­del kom­po­nen­tu Model wzor­ca MVC. PSM to model sta­no­wią­cy tak na praw­dę model kodu pro­gra­mu (w rozu­mie­niu tego co pisze pro­gra­mi­sta w Java czy .NET itp.). Warto wie­dzieć, że tak rozu­mia­ny kod to meta­mo­del tego co powsta­nie w pamię­ci po uru­cho­mie­niu kodu (pro­gra­mi­sta pro­gra­mu­jąc dekla­ru­je kla­sy a nie obiek­ty). Jak widać licz­ba pozio­mów abs­trak­cji (meta­mo­de­li) ma znaczenie. 

Poniżej przy­kład uży­cia pod­sta­wo­wych pozio­mów abs­trak­cji w toku ana­li­zy i projektowania:

MOF: od dołu war­stwy M0 (okre­ślo­na rze­czy­wi­stość), M1 (abs­trak­cja wyra­żo­na nazwa­mi obiek­tów) i M2 (jej meta­mo­del czy­li kla­sy obiek­tów). W war­stwie M2 umiesz­cza­my tak­że typy struk­tu­ral­ne jako kla­sy repre­zen­tu­ją­ce zde­fi­nio­wa­ne i nazwa­ne struk­tu­ry danych

Z per­spek­ty­wy oso­by popu­lar­nie zwa­nej ana­li­ty­kiem biz­ne­so­wym” (coraz bar­dziej nie zno­szę tej nazwy), two­rzy ona model sys­te­mu, testu­je go (przy­dat­ność sys­te­mu, czy­li jak i czy w ogó­le, speł­nia wyma­ga­nia) i prze­ka­zu­je do reali­za­cji (imple­men­ta­cji). Wcześniej powsta­je model orga­ni­za­cji aby prze­te­sto­wać tezę: zro­zu­mie­li­śmy to jak dzia­ła ta orga­ni­za­cja, to jest jej model, nikt go nie sfal­sy­fi­ko­wał więc to popraw­ny model”, i mowa tu o moty­wa­cji biz­ne­so­wej (nota­cja BMM), mode­lu pro­ce­sów biz­ne­so­wych i nośni­kach infor­ma­cji (nota­cja BPMN), mode­lu poję­cio­wym opi­su­ją­cym nazew­nic­two i regu­ły biz­ne­so­we (nota­cja SBVR). To model CIM. Tu ma teraz miej­sce płyn­ne przej­ście z CIM do PIM (poja­wia się kon­trakt doku­men­to­wa­ny dia­gra­mem przy­pad­ków uży­cia, logi­ka biz­ne­so­wa i nośni­ki danych z pro­ce­sów są mode­lo­wa­ne jako struk­tu­ry UML). Miejsce (rysu­nek powy­żej) ozna­czo­ne Automated Transformation to nadal dome­na ludzi: ana­li­ty­ków, pro­jek­tan­tów i inży­nie­rów programistów.

Słowo sys­tem” poja­wia się regu­lar­nie nie tyl­ko na tym blo­gu, war­to wie­dzieć (pamię­tać), że:

  • orga­ni­za­cja (fir­ma, urząd, itp.) to sys­tem któ­re­go ele­men­ta­mi są ludzie i narzę­dzia jakich uży­wa­ją, w szcze­gól­no­ści oprogramowanie
  • opro­gra­mo­wa­nie (narzę­dzia w rękach ludzi pra­cu­ją­cych w tych orga­ni­za­cjach) to pod­sys­tem tego powyż­sze­go sys­te­mu (czy­li for­mal­nie podsystem).

W toku prac na pro­jek­to­wa­niem opro­gra­mo­wa­nia nie moż­na o tym zapo­mi­nać. Słownictwo (model poję­cio­wy) zawsze zawie­ra kon­tekst orga­ni­za­cji a nie opro­gra­mo­wa­nia, jest to koniecz­ne dla zacho­wa­nia spój­no­ści nie tyl­ko nazew­nic­twa ale i samej doku­men­ta­cji a tak­że kodu (mówiąc sło­wa­mi kode­rów naming). Poniższy dia­gram poka­zu­je te zależności. 

Na tym zakoń­czę dzi­siej­sze, w sumie syl­we­stro­we, dywa­ga­cje, i zachę­cam i ana­li­ty­ków, i pro­jek­tan­tów, i archi­tek­tów, i kode­rów, do pozna­wa­nia mode­lo­wa­nia i sto­sow­nych nota­cji. To tak samo koniecz­ne jak rysu­nek tech­nicz­ny w pozo­sta­łych dzia­łach inży­nie­rii. Dobra infor­ma­cja: do celów ana­li­tycz­nych wystar­czy lek­tu­ra ok. 20% tych spe­cy­fi­ka­cji, roz­dzia­ły poświę­co­ne trans­for­ma­cjom i prze­no­szal­no­ści to lek­tu­ra dla aka­de­mi­ków i pro­du­cen­tów opro­gra­mo­wa­nia CASE.

Do Siego Roku 🙂 

Inne artykuły na podobny temat

image_print(wydruk PL)

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.