Tag: MOF

Emocjonujące bramki czyli dogmaty vs. logika

Dodaj komentarz

W toku szko­leń, a tak­że audy­tów, powsta­ją nie raz spo­ry o inter­pre­ta­cje zna­cze­nia sym­bo­li nota­cji: ich seman­ty­ki i syn­tak­ty­ki (co ozna­cza­ją i jak je moż­na łączyć z inny­mi). Dzisiaj o dość czę­stym spo­rze czy­li bram­ki OR (inc­lu­si­ve) i XOR (exc­lu­si­ve) w nota­cji BPMN oraz o tym, że z 380 stron spe­cy­fi­ka­cji BPMN, w mode­lach ana­li­tycz­nych sto­su­je­my tyl­ko nie­ca­łe 40 stron roz­dzia­łu 7., pozo­sta­łe roz­dzia­ły słu­żą wyłącz­nie lep­sze­mu zro­zu­mie­niu teo­rii i mode­lom wyko­ny­wal­nym. Czyli dla­cze­go w ana­li­zach sto­su­je­my kil­ka, a nie kil­ka­dzie­siąt sym­bo­li nota­cji BPMN. 

Czytaj dalej… ​„Emocjonujące bram­ki czy­li dogma­ty vs. logi­ka” →

Model i dokumentowanie wdrożenia

Dodaj komentarz

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):

Instancje (nazwy apli­ka­cji praw­dzi­we ale przy­pad­ko­we, nie jest to reko­men­da­cja żad­ne­go z tych programów)

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

Instancje wraz ze śro­do­wi­ska­mi w jakich zosta­ły uruchomione

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:

Instancje wraz przy­po­rząd­ko­wa­ny­mi kla­sy­fi­ka­to­ra­mi (np. Salesforce to egzem­plarz apli­ka­cji kla­sy System CRM)

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

OMG​.org. (2016, October). MetaObject Facility (MOF). https://​www​.omg​.org/​s​p​e​c​/​MOF
D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
Suleiman, B. (2007). Specification of Business Value with and in Software Patterns. … on Software Patterns …. https://​www​.aca​de​mia​.edu/​9​8​7​5​2​3​/​S​p​e​c​i​f​i​c​a​t​i​o​n​_​o​f​_​B​u​s​i​n​e​s​s​_​V​a​l​u​e​_​w​i​t​h​_​a​n​d​_​i​n​_​S​o​f​t​w​a​r​e​_​P​a​t​t​e​rns
Larman, C. (2005). Applying UML and pat­terns: an intro­duc­tion to object-orien­ted ana­ly­sis and design and ite­ra­ti­ve deve­lop­ment (3rd ed). Prentice Hall PTR, c2005.
Wei, B., Sun, J., & Wang, Y. (2018). A Knowledge Engineering Approach to UML Modeling (S). SEKE, 60 – 63.
Evans, E. (2014). Domain-dri­ven design: tac­kling com­ple­xi­ty in the heart of softwa­re. Addison-Wesley.

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns

1 komentarz

Miło mi poin­for­mo­wać, że moja publi­ka­cja nauko­wa (tu była zapo­wiedź) na temat syn­te­zy wzor­ców archi­tek­to­nicz­nych i wzor­ców pro­jek­to­wych, sys­te­mów obiek­to­wo-zorien­to­wa­nych zatytułowana:

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns

po dłu­gim pro­ce­sie selek­cji i recen­zo­wa­nia, zosta­ła zakwa­li­fi­ko­wa­na do publi­ka­cji i wła­śnie się uka­za­ła jako jeden z roz­dzia­łów książki:

Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities.

Jeszcze milej mi poin­for­mo­wać, że – jako współ­au­tor – mogę Wam zaofe­ro­wać kod pro­mo­cyj­ny dają­cy 40% zniż­ki na zakup: IGI40.

Poniżej infor­ma­cje o książ­ce i o wydawcy. 

O książce

Ch. 3: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities:
Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns (050719 – 041004) (J.Żeliński)

DescriptionIn today?s moder­ni­zed envi­ron­ment, a gro­wing num­ber of softwa­re com­pa­nies are chan­ging the­ir tra­di­tio­nal engi­ne­ering appro­aches in respon­se to the rapid deve­lop­ment of com­pu­ting tech­no­lo­gies. As the­se busi­nesses adopt modern softwa­re engi­ne­ering prac­ti­ces, they face vario­us chal­len­ges inc­lu­ding the inte­gra­tion of cur­rent metho­do­lo­gies and con­tem­po­ra­ry design models and the refac­to­ring of exi­sting sys­tems using advan­ced approaches.Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities is a pivo­tal refe­ren­ce sour­ce that pro­vi­des vital rese­arch on the deve­lop­ment of modern softwa­re prac­ti­ces that impact main­te­nan­ce, design, and deve­lo­per pro­duc­ti­vi­ty. While high­li­gh­ting topics such as augmen­ted reali­ty, distri­bu­ted com­pu­ting, and big data pro­ces­sing, this publi­ca­tion explo­res the cur­rent infra­struc­tu­re of softwa­re sys­tems as well as futu­re advan­ce­ments. This book is ide­al­ly desi­gned for softwa­re engi­ne­ers, IT spe­cia­li­sts, data scien­ti­sts, busi­ness pro­fes­sio­nals, deve­lo­pers, rese­ar­chers, stu­dents, and aca­de­mi­cians seeking cur­rent rese­arch on con­tem­po­ra­ry softwa­re engi­ne­ering methods. Source: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities: 9781799821427: Computer Science & IT Books | IGI Global

O wydawcy

IGI Global is a leading inter­na­tio­nal aca­de­mic publi­sher com­mit­ted to faci­li­ta­ting the disco­ve­ry of pio­ne­ering rese­arch that enhan­ces and expands the body of know­led­ge ava­ila­ble to the rese­arch com­mu­ni­ty. Working in clo­se col­la­bo­ra­tion with expert rese­ar­chers and pro­fes­sio­nals from leading insti­tu­tions, inc­lu­ding Massachusetts Institute of Technology (MIT), Harvard University, Stanford University, University of Cambridge, University of Oxford, Tsinghua University, and Australian National University, IGI Global dis­se­mi­na­tes quali­ty con­tent across 350+ topics in 11 core sub­ject are­as. Source: About IGI Global | IGI Global

Synteza pojęć i wzorców MOF, MDA, PIM, MVC i BCE. Zintegrowany model struktury procesu projektowania aplikacji.

5 komentarzy

Streszczenie: Wiele publi­ka­cji, w tym pod­ręcz­ni­ki aka­de­mic­kie, zawie­ra nie­spój­no­ści w opi­sach zasto­so­wań metod i wzor­ców archi­tek­to­nicz­nych, kry­ją­cych się pod skró­ta­mi MOF, MDA, PIM, MVC, BCE. Skuteczna ana­li­za oraz nastę­pu­ją­ce po niej pro­jek­to­wa­nie opro­gra­mo­wa­nia, szcze­gól­nie gdy są to pro­jek­ty reali­zo­wa­ne w dużych zespo­łach, wyma­ga stan­da­ry­za­cji pro­ce­su wytwór­cze­go i sto­so­wa­nych wzor­ców i fra­me­wor­ków. W pra­cy tej pod­ję­to pró­bę upo­rząd­ko­wa­nia sys­te­mu pojęć opi­su­ją­cych ten pro­ces , sto­so­wa­nych do opi­su wzor­ców archi­tek­to­nicz­nych. Przeprowadzono ana­li­zę klu­czo­wych pojęć MOF i MDA, wzor­ców MVC i BCE, stwo­rzo­no spój­ny opis łączą­cy je w jeden system.

1. Wprowadzenie

Celem badań było zwe­ry­fi­ko­wa­nie obec­ne­go sta­nu metod pro­jek­to­wa­nia i opra­co­wa­nie spój­ne­go sys­te­mu pojęć i wzor­ców pro­jek­to­wych w obsza­rze pro­jek­to­wa­nia logi­ki opro­gra­mo­wa­nia, jako jej abs­trak­cyj­ne­go mode­lu. Wiele publi­ka­cji na temat ana­liz i pro­jek­to­wa­nia, w obsza­rze inży­nie­rii opro­gra­mo­wa­nia, przy­wo­łu­je nazwy wzor­ców pro­jek­to­wych MVC i BCE oraz model PIM (patrz OMG MDA, OMG MOF 2016). Z uwa­gi na, nie raz, nie małe roz­bież­no­ści w inter­pre­ta­cji tych metod i wzor­ców, autor pod­jął pró­bę upo­rząd­ko­wa­nia ich wza­jem­nych zależności.

2. Metody

Wykorzystano sys­te­my nota­cyj­ne Object Management Group (OMG​.org). Specyfikacja MOF opi­su­je trzy pozio­my abs­trak­cji: M1, M2, M3 oraz poziom M0 czy­li real­ne rze­czy (patrz struk­tu­ra pozio­mów abs­trak­cji, OMG MOF 2016). M0 to real­ny sys­tem, poziom M1 to abs­trak­cja obiek­tów tego sys­te­mu (jego model) . Poziom M2 to związ­ki pomię­dzy kla­sa­mi tych obiek­tów (nazwy ich zbio­rów) czy­li meta­mo­del sys­te­mu. Poziom M3 to meta-meta­mo­del poziom opi­su­ją­cy meto­dę mode­lo­wa­nia z uży­ciem nazwa­nych ele­men­tów o okre­ślo­nej seman­ty­ce i syntaktyce.

Proces ana­li­zy i pro­jek­to­wa­nia został opar­ty na spe­cy­fi­ka­cji MDA (OMG MDA). Proces ten ma trzy fazy rozu­mia­ne jako two­rze­nie kolej­nych mode­li: CIM, PIM, PSM oraz fazę two­rze­nie kodu. Model CIM jest doku­men­to­wa­ny z uży­ciem nota­cji BPMN (OMG BPMN 2013) i SBVR (OMG SBVR 2017). Są to odpo­wied­nio: mode­le pro­ce­sów biz­ne­so­wych oraz mode­le poję­cio­we i regu­ły biz­ne­so­we. Modele PIM i PSM doku­men­to­wa­ne są z uży­ciem nota­cji UML (OMG UML 2017). Pomiędzy mode­lem CIM a PIM ma miej­sce usta­le­nie listy usług apli­ka­cyj­nych (reak­cje sys­te­mu), któ­rych mecha­nizm reali­za­cji opi­su­je model PIM. Standardowym wzor­cem uży­wa­nym do mode­lo­wa­nia archi­tek­tu­ry apli­ka­cji jest wzo­rzec MVC. Komponent Model tego wzor­ca jest mode­lo­wa­ny z uży­ciem wzor­cza archi­tek­to­nicz­ne­go BCE.

[…]

Spis tre­ści
1. Wprowadzenie 1
2. Metody 2
2.1. Semiotyka a UML 2
2.2. Specyfikacja MOF Poziomy abs­trak­cji 3
2.3. Specyfikacja MDA i model PIM 4
2.4. Wzorzec archi­tek­to­nicz­ny MVC 5
2.5. Wzorzec archi­tek­to­nicz­ny BCE 5
3. Rezultaty 6
3.1. Założenie uprosz­cza­ją­ce 6
3.2. Zintegrowany model struk­tu­ry pro­ce­su pro­jek­to­wa­nia apli­ka­cji 7
4. Dyskusja 8
5. Dalsze pra­ce 8
6. Bibliografia 9
7. Kluczowe poję­cia meto­dycz­ne 11

Cała publi­ka­cja …

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns
Jaroslaw Zelinski (Independent Researcher, Poland)

Source Title: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities
Copyright: ? 2020 |Pages: 12
DOI: 10.4018/978 – 1‑7998 – 2142‑7.ch003

OMG’s MetaObject Facility

Dodaj komentarz

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”… 

Czytaj dalej… ​„OMG’s MetaObject Facility” →

Analiza a modelowanie czyli ile abstrakcji a ile rzeczywistości

Dodaj komentarz

Regularnie obser­wu­ję pew­ną trud­ność jaką spra­wia wie­lu ludziom, z jed­nej stro­ny sto­so­wa­nie sys­te­mów nota­cyj­nych a z dru­giej samo mode­lo­wa­nie. Wspólną czę­ścią obu tych obsza­rów jest abs­tra­ho­wa­nie od szcze­gó­łów. Praktycznie każ­dy mój klient i bar­dzo czę­sto, ana­li­ty­cy i pro­jek­tan­ci deve­lo­pe­rów reali­zu­ją­cych pro­jek­ty któ­re nad­zo­ru­ję, zada­ją mi pyta­nia: a gdzie zoba­czę to, że zamó­wie­nie może być dla inne­go pro­duk­tu i inne­go seg­men­tu.…. itp. Innymi sło­wy: na dowol­nym eta­pie pra­cy pada­ją pyta­nia o bar­dzo deta­licz­ne szcze­gó­ły kon­kret­nych ope­ra­cji. Co praw­da, jak to mawia­ją ​„dia­beł tkwi w szcze­gó­łach”, z czym wypa­da się zgo­dzić, ale to dokład­nie ten wła­śnie dia­beł nisz­czy pro­jek­ty pro­wa­dząc nie raz do ​„utra­ty pano­wa­nia nad szcze­gó­ło­wo­ścią pro­jek­tu”. Dokładnie dwa lata temu opi­sy­wa­łem mode­lo­wa­nie pro­blem deta­li w arty­ku­le Gdzie są te cho­ler­ne szcze­gó­ły, a kwe­stie zasad (reguł) dzia­ła­nia apli­ka­cji w nie­daw­nym arty­ku­le Mechanizm dzia­ła­nia. Dzisiaj będzie o mode­lach i abstrakcjach.

Modele a abstrakcje

Modelowanie ma dwa aspek­ty: pro­jek­to­wa­nie jako two­rze­nie mode­lu przy­szłej (pro­jek­to­wa­nej) rze­czy­wi­sto­ści oraz ana­li­za jako two­rze­nie mode­lu bada­nej, ist­nie­ją­cej rze­czy­wi­sto­ści. Model jako taki nie jest abs­trak­cją cze­goś, jest uprosz­czo­nym obra­zem lub opi­sem z okre­ślo­nej per­spek­ty­wy, ale zacho­wu­ją­cym okre­ślo­ne cechy rze­czy­wi­sto­ści. Model z defi­ni­cji jest zawsze uprosz­cze­niem, inny­mi sło­wy, jest pozba­wio­ny okre­ślo­nych szcze­gó­łów, tych któ­re w danym zasto­so­wa­niu mode­lu (kon­tekst) są nie­istot­ne. Pojęcia model i abs­trak­cja są czę­sto mylo­ne, bywa że sto­so­wa­ne zamien­nie, co jest bar­dzo dużym błędem.

Podstawowym narzę­dziem ana­li­zy jest pro­ces redu­ko­wa­nia szcze­gó­łów, w prze­ciw­nym wypad­ku pra­co­chłon­ność opra­co­wa­nia mode­lu i póź­niej­sza jego ana­li­za, może wręcz unie­moż­li­wić rze­tel­ne ich prze­pro­wa­dze­nie, może być to nawet nie­wy­ko­nal­ne z uwa­gi na ich nad­mier­ną zło­żo­ność. Słownik j. pol­skie­go PWN poda­je nastę­pu­ją­ce definicje:

abs­trak­cja: poję­cie ogól­ne, nie­ma­ją­ce odpo­wied­ni­ka w żad­nym kon­kret­nym przedmiocie;

model: kon­struk­cja, sche­mat lub opis uka­zu­ją­cy dzia­ła­nie, budo­wę, cechy, zależ­no­ści jakie­goś zja­wi­ska lub obiektu;

Pomiędzy poję­cia­mi abs­trak­cja i model jest pew­na klu­czo­wa róż­ni­ca: abs­trak­cja to poję­cie zaś model to opis mecha­ni­zmu, jego kon­struk­cja, dzia­ła­nie, budo­wa. Prosty przy­kład: nazwa­ne pro­sto­ką­ty na typo­wym dia­gra­mie struk­tu­ry orga­ni­za­cyj­nej to abs­trak­cje komó­rek orga­ni­za­cyj­nych i osób w nich zatrud­nio­nych, pro­sto­ką­ty te wraz z linia­mi je łączą­cy­mi sta­no­wią, jako całość, model pod­le­gło­ści zaso­bów w orga­ni­za­cji. Nieco ponad pół roku temu opi­sa­łem to w arty­ku­le Diagram obiek­tów czy­li bot­tom-up:

Generalnie rzecz w tym, by poka­zać to co wie­my czy­li kon­kret­ne nazwa­ne egzem­pla­rze ?tych rze­czy?, o któ­rych ktoś mówi lub któ­re obser­wu­je­my. To egzem­pla­rze i ich spe­cy­fi­ka­cja (nazwy, cechy itp.). Innymi sło­wy
dia­gram obiek­tów słu­ży do poka­za­nia kon­kret­ne­go, obser­wo­wal­ne­go sta­nu rze­czy.
Jeżeli więc z jakie­goś powo­du nie może­my ope­ro­wać uogól­nie­nia­mi (kla­sy) bo nie posia­da­my odpo­wied­niej wie­dzy lub jest ona zbyt ubo­ga, ana­li­zę moż­na pro­wa­dzić ?od dołu? czy­li mając szcze­gó­ły uogól­niać je. Poważną zale­tą tej meto­dy jest łatwość wery­fi­ka­cji mode­lu przez ?klien­ta?. Większość ludzi nie radzi sobie z abs­trak­cja­mi (np. meta­mo­de­le): mode­le budo­wa­ne z uży­ciem dia­gra­mów klas to uogól­nie­nia: opi­su­ją kla­sy a nie kon­kret­ną rze­czy­wi­stość. Diagramy obiek­tów (instan­cje klas) to nic inne­go jak mode­le ?kon­kret­nych sytu­acji? z życia. (Źródło: Diagram Obiektów | Jarosław Żeliński IT-Consulting)

Poziomy abstrakcji w UML

Notacja UML pozwa­la na mode­lo­wa­nie na obu wyżej wymie­nio­nych pozio­mach. W ramach [[MOF]]/[[UML]] wyróż­nia­my łącz­nie czte­ry pozio­my uogól­nie­nia ozna­czo­ne od M0 do M3. M0 to świat rze­czy­wi­stych bytów. M1 to model w któ­rym kon­kret­ne rze­czy­wi­ste byty zastę­pu­je się ich abs­trak­cja­mi (np. nazwa­ne pro­sto­ką­ty), któ­rych jest tyle ile rze­czy­wi­stych obiek­tów. Poziom M2 to meta­mo­del, czy­li wszyst­kie nazwa­ne ele­men­ty kla­sy­fi­ku­je­my i zastę­pu­je­my kla­sy­fi­ka­to­ra­mi. Obiekty mają­ce pew­ne usta­lo­ne wspól­ne cechy (całą ich gru­pę) zastę­pu­je­my jed­nym kla­sy­fi­ka­to­rem. Np. na pozio­mie M1 model dru­ży­ny pił­kar­skiej będzie zawie­rał 11 nazwa­nych obiek­tów (tu pro­sto­kąt to abs­trak­cja zawod­ni­ka). Na pozio­mie M2 model tej dru­ży­ny to była by już tyl­ko kla­sa Zawodnik, zapew­ne jed­nym z jej atry­bu­tów było­by imię i nazwi­sko oraz numer zawod­ni­ka a dru­gim jego rola (bram­karz lub zawod­nik w polu, to decy­du­je o jego zacho­wa­niu). Na naj­wyż­szym pozio­mie M3 mamy tyl­ko zde­fi­nio­wa­ne poję­cie klasyfikatora.

Notacja UML pozwa­la na mode­lo­wa­nie (two­rze­nie mode­li i meta­mo­de­li) na pozio­mach M1 i M2 (poziom M3 to defi­ni­cja kla­sy­fi­ka­to­ra w UML, pole­cam tu książ­kę Model-Driven Software Engineering…). Poniżej dia­gram obra­zu­ją­cy te czte­ry pozio­my oraz tak­so­no­mie dia­gra­mów w UML 2.5 gdzie dia­gra­my zosta­ły sko­ja­rzo­ne z odpo­wia­da­ją­cy­mi im pozio­ma­mi abstrakcji.

Poziomy modelowania (opracowanie własne Jarosław Żeliński na podstawie OMG UML 2.5 oraz OMG Meta-Object Facility (MOF))
Poziomy mode­lo­wa­nia (opra­co­wa­nie wła­sne Jarosław Żeliński na pod­sta­wie OMG UML 2.5 oraz OMG Meta-Object Facility (MOF))

Warto o tym pamię­tać, głów­nie z tego powo­du, że dia­gram klas nota­cji UML jest powszech­nie nad­uży­wa­ny, wie­le mode­li, szcze­gól­nie doku­men­tu­ją­cych stan fak­tycz­ny kon­kret­nej apli­ka­cji i wdro­że­nia, powin­no być dia­gra­ma­mi obiek­tów i wdro­że­nia a nie dia­gra­ma­mi klas czy kom­po­nen­tów, bo te osta­nie to jedy­nie meta­mo­de­le. Warto też wie­dzieć, że kod pro­gra­mu to meta­mo­del tego co zosta­nie wytwo­rzo­ne w pamię­ci kom­pu­te­ra (bo to jest model rze­czy­wo­sto­ści), po uru­cho­mie­niu tego pro­gra­mu. W kodzie np. gry będzie kla­sa zawod­nik, ale po uru­cho­mie­niu gry kom­pu­te­ro­wej, w pamię­ci będzie 11 wyge­ne­ro­wa­nych z tych klas obiek­tów, repre­zen­tu­ją­cych zawod­ni­ków drużyny.

Na powyż­szym dia­gra­mie, po jego lewej stro­nie, poka­za­łem tak­że, że pro­jek­to­wa­nie cze­goś jest roz­po­czy­na­niem pra­cy od two­rze­nia okre­ślo­nej abs­trak­cji pomy­słu (z regu­ły obiek­ty a nie kla­sy). Analiza sta­nu rze­czy­wi­ste­go to two­rze­nie tej abs­trak­cji na bazie obser­wa­cji ana­li­zo­wa­nej rzeczywistości.

model-dependent-realism
(źr. https://​thin​kin​mo​dels​.word​press​.com/​2​0​1​1​/​1​1​/​2​4​/​m​o​d​e​l​-​d​e​p​e​n​d​e​n​t​-​r​e​a​l​i​s​m​-​i​s​-​t​h​i​s​-​t​h​e​-​w​o​r​l​d​v​i​e​w​-​o​f​-​s​o​f​t​w​a​r​e​-​e​n​g​i​n​e​e​r​i​ng/)

Projekty w obsza­rze inży­nie­rii opro­gra­mo­wa­nia, two­rzo­ne w duchu para­dyg­ma­tu obiek­to­we­go to:

  1. ana­li­za rze­czy­wi­sto­ści i zbu­do­wa­nie jej obiek­to­wej abs­trak­cji (dia­gram obiektów),
  2. okre­śle­nie, któ­ry obszar rze­czy­wi­sto­ści zosta­nie zastą­pio­ny opro­gra­mo­wa­niem (np. papie­ro­we kar­to­te­ki w bibliotece),
  3. zbu­do­wa­nie meta­mo­de­lu wybra­ne­go obsza­ru : to model dzie­dzi­ny (dia­gram klas)

Pierwszy punkt to ele­ment ana­li­zy sys­te­mo­wej: two­rze­nie obiek­to­we­go mode­lu tego co jest ana­li­zo­wa­ne. Podejście obiek­to­we do ana­li­zy i pro­jek­to­wa­nia więc:

…pozwa­la wyjść od kon­kret­ne­go rze­czy­wi­ste­go ?sta­nu świa­ta? i opra­co­wać na jego pod­sta­wie model poję­cio­wy i meta­mo­del. To bar­dzo pomoc­na tech­ni­ka. Warto pamię­tać, że to co nie raz nazy­wa­ne jest ?mode­lem dzie­dzi­ny? jed­nak nim nie jest. (Źródło: Diagram Obiektów | Jarosław Żeliński IT-Consulting)