Ten arty­kuł to pró­ba przy­bli­że­nia czy­tel­ni­ko­wi poję­cia meta­mo­del i model. To tak­że mała prób­ka tego co jest pro­duk­tem nad­zo­ru autorskiego.

Nieco ponad pięć lat temu w arty­ku­le Diagram obiek­tów czy­li bot­tom-up pisa­łem o poję­ciu instan­cji obiek­tu i dia­gra­mie obiek­tów. Wtedy sku­pi­łem się na jed­nym tyl­ko wąt­ku, jakim jest ana­li­za zmie­rza­ją­ca do opra­co­wa­nia … no wła­śnie, cze­go? Z regu­ły auto­rzy doku­men­tów zawie­ra­ją­cych ​„dia­gra­my klas” mówią, że two­rzą mode­le. Czy zawsze są to modele?

Wprowadzenie

Jednym z bar­dzo nie­do­ce­nia­nych typów dia­gra­mów UML są dia­gram obiek­tów i dia­gram wdro­że­nia (któ­ry jest rodza­jem dia­gra­mu obiek­tów). Oba te dia­gra­my słu­żą do mode­lo­wa­nia okre­ślo­nych sytu­acji. Nie raz pisa­łem, że pro­jekt (doku­men­ta­cja pro­jek­to­wa) tez ma cykl życia. To nie jest tak, że powsta­je doku­ment Wymagania, zawie­ra­ją­cy jakieś mode­le, a następ­nie ktoś za nie­go pła­ci i ten doku­ment lądu­je za szy­bą tyl­ko do odczytu.

Patrząc na cykl życia pro­jek­tu, doku­men­ta­cja sta­no­wią­ca począt­ko­wo Wymagania, żyje i roz­wi­ja się razem z nim. Ona tak­że ma swój cykl życia. Na koniec doku­men­ta­cja ta jest opi­sem tego co powsta­ło. Jest to model kon­kret­ne­go ukoń­czo­ne­go wdrożenia.

Meta Object Facility

(oso­by nie inte­re­su­ją­ce się teo­rią mogą pomi­nąć ten rozdział) 

MOF (Meta Object Facility) to spe­cy­fi­ka­cja okre­śla­ją­ca bazo­we poję­cia dla nota­cji zarzą­dza­nych przez Object Management Group . Specyfikacja ta okre­śla trzy pod­sta­wo­we pozio­my abs­trak­cji oraz poziom pod­sta­wo­wy jakim jest świat (przed­mio­ty) mode­lo­wa­ny. Realny świat to poziom M0. Zobrazowanie real­ne­go świa­ta za pomo­cą nazw przed­mio­tów i ich wybra­nych klu­czo­wych cech (bo nie wszyst­kich) to abs­trak­cja tego świa­ta. Jeżeli jakieś gru­py przed­mio­tów mają te same klu­czo­we cechy, ale róż­nią sie jedy­nie war­to­ścia­mi tych cech, np. wie­le przed­mio­tów róż­ni się wyłącz­nie kolo­rem i dłu­go­ścią ale opi­su­je­my je z pomo­cą kolo­ru i dłu­go­ści, to mówi­my, że mamy kla­sę przed­mio­tów o atry­bu­tach kolor i dłu­gość, i nada­je­my jej (temu zbio­ro­wi) nazwę, nazwa ta czę­sto jaw­nie wystę­pu­je w języ­ku natu­ral­nym, np. ​„kolo­ro­we słom­ki” mają atry­bu­ty: kolor i dłu­gość. Zakładamy, że przed­mio­ty reagu­ją na bodź­ce czy­li mają zacho­wa­nia: słom­ka pod wpły­wem siły prze­miesz­cza się lub wygi­na (to operacja). 

Powyższy dia­gram obra­zu­je ww. pozio­my abs­trak­cji MOF. Złóżmy, że wśród drob­nych przed­mio­tów real­nych (poziom M0) są tak­że nasze słom­ki. Dwie z tych sło­mek obra­zu­je­my jak pro­sto­ką­ty mają­ce nazwy: Egzemplarz 1 i Egzemplarz 2 (mają uni­kal­ne nazwy bo musi­my je roz­róż­niać). To – poziom M1 – jest abs­trak­cja nasze­go świa­ta: jego model. Skoro słom­ki mają te same cechy: nazwa, kolor i dłu­goś, to two­rzy­my nazwę (tu Class) dla zbio­ru wszyst­kich takich sło­mek. Nazwa tego zbio­ru repre­zen­tu­je wszyst­kie takie słom­ki (zbiór sło­mek). Na pozio­mie M2 uży­wa­my już tyl­ko nazwy zbio­ru. Poziom M2 to meta­mo­del. Aby upo­rząd­ko­wać nasze mode­le i meta­mo­de­le, stan­da­ry­zu­je­my tę meto­dę opi­su, uma­wia­jąc sie, że ele­men­ty naszych mode­li to poję­cia (nazwy) i związ­ki mię­dzy nimi (zwa­ne tak­że aso­cja­cje). Pojęcia mają zawsze defi­ni­cje i repre­zen­tu­ją nazwy, czy­li zbio­ry ele­men­tów zgod­nych z daną defi­ni­cją (ele­men­ty dia­gra­mów), a defi­ni­cja ta to kla­sy­fi­ka­tor. Ta umo­wa to poziom M3, nazy­wa­ny meta-meta­mo­del (zbiór zbio­rów). Mówimy, że w UML wszyst­ko jest klasą.

Najnowsza spe­cy­fi­ka­cja MOF wska­zu­je, że co praw­da pod­sta­wo­we pozio­my abs­trak­cji to te czte­ry wymie­nio­ne, jed­nak nie ma żad­ne­go zaka­zu orga­ni­zo­wa­nia zbio­rów w zbio­ry. Robimy to na pozio­mie M2 a słu­żą do tego tak zwa­ne ste­reo­ty­py: są to kla­sy klas. Np. gdy­by było praw­dą, że słom­ki mają prze­kro­je kwa­dra­to­we i okrą­głe to albo doda­je­my im nową cechę: prze­krój o war­to­ści koło lub kwa­drat, albo two­rzy­my pod­zbio­ry «kwa­dra­to­we» i «okrą­głe». Możemy tak­że dopre­cy­zo­wać, że cechą sło­mek «kwa­dra­to­we» zawsze jest tak­że zapach a sło­mek «okrą­głe» ich cię­żar. Taka dodat­ko­wa defi­ni­cja typów klas i ich spe­cy­fi­ki to profil. 

Projektowanie i realizacja projektu

Cykl życia pro­jek­tu zaczy­na się od budo­wy archi­tek­tu­ry sys­te­mu, budu­je­my struk­tu­rę zło­żo­na z blo­ków o okre­ślo­nym zasto­so­wa­niu: mówi­my ​„sys­tem kla­sy CRM”, ​„sys­tem kla­sy ERP” czy ​„sys­tem kla­sy WorkFlow”. Nie wie­my jakie kon­kret­ne apli­ka­cje wdro­ży­my, ale wie­my (powin­ni­śmy to zde­fi­nio­wać) jakie wyma­ga­nia sta­wia­my przed każ­dą z tych klas aplikacji.

Idea podej­ścia zgod­ne­go z MOF to ana­li­za i jej efekt: nazwa­ne blo­ki funk­cjo­nal­ne sys­te­mu (dia­gram komponentów):

Ich defi­ni­cje to wyma­ga­nia na te kom­po­nen­ty. Każdy z powyż­szych kom­po­nen­tów moż­na opi­sać przy­pad­ka­mi uży­cia. Całość może zostać zre­ali­zo­wa­na jako odręb­ne apli­ka­cje, każ­dy impo­nent jest zde­fi­nio­wa­ny poprzez wyma­ga­nia wobec nie­go. Nazwy kom­po­nen­tów są zwy­cza­jo­we, tak na praw­de są one defi­nio­wa­ne poprzez przy­pad­ki uży­cia i wewnętrz­ną archi­tek­tu­rę infor­ma­cji: są to dzie­dzi­no­we komponenty. 

Wybierając i wdra­ża­jąc kolej­ne apli­ka­cje zna­my ich nazwy i to jak współ­pra­cu­ją (dia­gram wdrożenia):

Powyższy dia­gram mozna uzu­peł­nić o infor­ma­cje o doce­lo­wym śro­do­wi­sku ich pracy:

Należy tak­że wska­zać jakiej kla­sy są to apli­ka­cje (któ­re wyma­ga­nia reali­zu­ją), dla­te­go każ­dą kon­kret­ną apli­ka­cje przy­po­rząd­ko­wu­je­my do okre­ślo­nej wcze­śniej kla­sy komponentów:

Detali opi­su­ją­cych wdro­że­nie krok po kro­ku może być wię­cej (np. inter­fej­sy i ich spe­cy­fi­ka­cje). W każ­dym razie w dniu zakoń­cze­nia wdro­że­nia dostaw­ca zosta­wi po sobie deta­licz­ną doku­men­ta­cję wyko­na­nej imple­men­ta­cji, dla admi­ni­stra­to­ra całe­go sys­te­mu, będzie to kil­ka­set, a bywa że kil­ka tysię­cy, stron. Analityk-pro­jek­tant, po eta­pie nad­zo­ru autor­skie­go, zosta­wi po sobie doku­men­ta­cję zawie­ra­ją­ca abs­trak­cję: model sys­te­mu na potrze­by podej­mo­wa­nia decy­zji tak­tycz­nych i stra­te­gicz­nych, raczej kil­ka­dzie­siąt stron (patrz tak­że: Analiza, mode­lo­wa­nie i uspraw­nia­nie orga­ni­za­cji).

Następne wdro­że­nie nowe­go ele­men­tu sys­te­mu lub wpro­wa­dze­nie w nim zmian, nie będzie już wyma­ga­ło żad­nej owej ana­li­zy, a jed­nie pro­jek­tu poka­zu­ją­ce­go nowy kom­po­nent lub miej­sce gdzie będą wdra­ża­ne zmiany. 

Diagram kom­po­nen­tów to poziom M2. Diagram wdro­że­nia to poziom M1 wg. MOF. W ramach UML korzy­sta­my tu z dia­gra­mu kom­po­nen­tów i dia­gra­mu wdro­że­nia, są stan­dar­do­we pro­fi­le dla UML (MOF tak­że war­stwa M2: dodat­ko­we ste­reo­ty­py). Gdybyśmy chcie­li two­rzyć dedy­ko­wa­ne kom­po­nen­ty, zapew­ne deve­lo­per wyko­rzy­sta wzor­ce fra­me­wor­ki (goto­we zesta­wy biblio­tek) i wzor­ce pro­jek­to­we. To tak­że defi­niu­je się jako pro­fi­le w war­stwie M2 .

Źródła