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)

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

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