Ten arty­kuł to odpo­wiedź na pew­ną dys­ku­sję roz­po­czę­tą od tezy, że na wie­lu stro­nach WWW (w nie­któ­rych książ­kach tak­że) mamy nie­ste­ty do czy­nie­nia z pseudowiedzą…

W arty­ku­le Cholerny dia­gram klas pisa­łem o mode­lu dzie­dzi­ny. Modelowana jest dia­gra­mem klas (nota­cja to narzę­dzie), zawie­ra logi­kę biz­ne­so­wą. W kon­wen­cji DDD ([[Domain Driven Design]]), model ten jest szkie­le­tem kom­po­nen­tu Model we wzor­cu MVC.

Tym razem napi­sze kil­ka słów o poje­dyn­czych kla­sach w mode­lu dzie­dzi­ny. Błąd numer jeden: kla­sy w mode­lu dzie­dzi­ny odwzo­ro­wu­ją poję­cia mode­lu poję­cio­we­go! Nie, model poję­cio­wy (słow­nik pojęć ich wza­jem­nych związ­ków) to nie model dzie­dzi­ny sys­te­mu. Tak się pro­jek­to­wa­ło encje w mode­lach rela­cyj­nych baz danych, prze­no­sze­nie tych doświad­czeń na grunt obiek­to­wy to powszech­na, cięż­ka cho­ro­ba, to rak toczą­cy te pro­jek­ty. Owszem, jeże­li ktoś zade­kla­ru­je, że two­rzy sys­tem meto­da­mi struk­tu­ral­ny­mi już może prze­stać czy­tać, ale niech uży­wa nota­cji i dia­gra­my ERD a nie UML i nie nazy­wa tego meto­da­mi obiek­to­wy­mi ana­li­zy i projektowania.

Niestety przy­kła­dy dia­gra­mów klas” na stro­nach wie­lu firm dorad­czych, szko­le­nio­wych i stro­nach wie­lu kon­sul­tan­tów”, «tre­ne­rów” itp. poka­zu­ją, że duch ana­li­zy struk­tu­ral­nej nadal żyje oraz, że myle­nie nota­cji UML z meto­da­mi obiek­to­wy­mi ana­li­zy i pro­jek­to­wa­nia jest powszech­ne. Przypomnę tu tyl­ko, że dia­gram klas to nota­cja, któ­rej moż­na użyć do wie­lu rze­czy, w tym do mode­lo­wa­nia pojęć, struk­tu­ry kodu opro­gra­mo­wa­nia obiek­to­we­go (zgod­ne­go z obiek­to­wym para­dyg­ma­tem, a nie tyl­ko korzy­sta­ją­ce­go z pole­ce­nia class w uży­tym języ­ku pro­gra­mo­wa­nia), sta­tycz­nych mode­li orga­ni­za­cji i wie­lu innych. Tak więc zda­nie pro­szę zro­bić dia­gram klas” nie zna­czy nic, to coś jak weź samo­chód o pojeź­dzij trosz­kę”, z trans­por­tem nie ma to nic wspólnego.

Jeżeli jed­nak uzna­my, że pro­wa­dzi­my ana­li­zę obiek­to­wą to zna­czy, że model rze­czy­wi­sto­ści (mode­lo­wa­nej) budu­je­my jako zespół współ­pra­cu­ją­cych obiek­tów reali­zu­ją­cych okre­ślo­ny cel”. Wtedy dia­gram klas to nie żad­ne dane, encje i inne nie­obiek­to­we pomy­sły (znam takich co mode­lu­ją klu­cze rela­cyj­ne w dia­gra­mach klas a to już jest tra­ge­dia nie­ste­ty, jest nawet wyda­na w Polsce książ­ka z taki­mi przy­kła­da­mi!). Projekt zaczy­na­my od klas i ich ope­ra­cji a nie od atrybutów!

Uwaga dodat­ko­wa. Sprawdzoną meto­dą ana­liz (w ogó­le) jest ana­li­za sys­te­mo­wa, jest to:

meto­da roz­wią­zy­wa­nia zło­żo­nych pro­ble­mów wyko­rzy­stu­ją­ca podej­ście sys­te­mo­we (holi­stycz­ne). Polega na trak­to­wa­niu ana­li­zo­wa­nej orga­ni­za­cji (zja­wi­ska) jako zło­żo­ne­go sys­te­mu, któ­re­go poszcze­gól­ne czę­ści pra­cu­ją” na powo­dze­nie cało­ści”. Obejmuje ona czte­ry zasad­ni­cze eta­py roz­wią­zy­wa­nia pro­ble­mu: (1) iden­ty­fi­ka­cja i sfor­mu­ło­wa­nie pro­ble­mu, (2) bada­nie (ana­li­zo­wa­nie) sytu­acji pro­ble­mo­wej (gro­ma­dze­nie infor­ma­cji, wyja­śnia­nie kwe­stii, ana­li­zo­wa­nie fak­tów itp., (3) ana­li­za pro­ble­mu (dekom­po­zy­cja zło­żo­ne­go pro­ble­mu na mniej­sze), (4) pro­jek­to­wa­nie roz­wią­za­nia (budo­wa mode­li, spe­cy­fi­ka­cje, symu­la­cja, warian­ty itp.).

Jak widać podo­bień­stwo para­dyg­ma­tu obiek­to­we­go i ana­li­zy sys­te­mo­wej jest bar­dzo duże, żeby nie powie­dzieć uderzające.

Tak więc ana­li­za i mode­lo­wa­nie (na eta­pie ana­li­zy) to roz­ło­że­nie ana­li­zo­wa­nej orga­ni­za­cji (ana­li­zo­wa­ne­go śro­do­wi­ska) na pro­ste obiek­ty, każ­dy o pro­stej odpo­wie­dzial­no­ści”. Wyłania się obraz mode­li skła­da­ją­cych się z tych czę­ści, któ­re pra­cu­ją na powo­dze­nie cało­ści”. Jakie powin­ny być owe czę­ści? Teraz pora na dwa cyta­ty z blo­gów pew­nych pro­gra­mi­stów (lubię dobrych pro­gra­mi­stów, bo przy­ta­ku­ją mi lub negu­ją a nie raz moc­no uczą poko­ry to co myślę czy­li nie błą­dzę w chmurach):

Single Responsibility Principle mówi, że kla­sa powin­na robić jed­ną rzecz, mieć jed­ną odpo­wie­dzial­ność. Jeśli ma jed­ną odpo­wie­dzial­ność to nie powin­na raczej grze­bać we wszyst­kich war­stwach. Wątpliwe jest aby kla­sa, któ­ra ma jed­ną odpo­wie­dzial­ność musia­ła się­gać do bazy danych i inter­fej­su użyt­kow­ni­ka i pli­ków i logi­ki biz­ne­so­wej i Bóg raczy wie­dzieć gdzie jesz­cze. (za using – papie­rek lak­mu­so­wy Twojej archi­tek­tu­ry | arek onli­ne | Arkadiusz Benedykt).

…naj­bar­dziej traf­ną meta­fo­rą obiek­tów pro­gra­mi­stycz­nych jest orga­nizm bio­lo­gicz­ny. Podobnie jak komór­ki, obiek­ty nie wie­dzą”, co dzie­je się wewnątrz innych obiek­tów, ale komu­ni­ku­ją się z nimi reali­zu­jąc bar­dziej zło­żo­ne cele. W prze­ci­wień­stwie do takie­go orga­ni­zmu pro­gram mono­li­tycz­ny przy­po­mi­na mecha­nizm zegar­ka, zawie­ra­ją­cy nie­prze­li­czal­ną (sic!) licz­bę try­bi­ków. Trybiki nie mają żad­nej inte­li­gen­cji i są bez­u­ży­tecz­ne poza mecha­ni­zmem, w któ­rym pra­cu­ją. Taki pro­jekt nie ma szans powo­dze­nia. Budując mecha­ni­zmy zega­ro­we, docho­dzisz w koń­cu do takiej zło­żo­no­ści, że całość prze­sta­je funk­cjo­no­wać. (Holistycznie o inży­nie­rii opro­gra­mo­wa­nia: Bo naj­waż­niej­sza jest odpo­wie­dzial­ność Synu…).

i nie­ste­ty to co widu­ję na wie­lu stro­nach WWW, w pro­jek­tach itp. (dru­ga wada czę­sto spo­ty­ka­nych mode­li dziedzinowych):

Dopisujemy kolej­ne meto­dy a tym­cza­sem kla­sa puch­nie. Przy osią­gnię­ciu masy kry­tycz­nej, wpro­wa­dze­nie jakiej­kol­wiek zmia­ny, nawet tej naj­mniej­szej powo­du­je, że spę­dza­my godzi­ny na debu­go­wa­niu kodu i spraw­dza­niu dla­cze­go nie zawsze dzia­ła tak jak byśmy tego chcie­li. (Single Responsibility Principle | arek online).

Swego cza­su na jed­nej z kon­fe­ren­cji o ana­li­zie wyma­gań, mówi­łem o potrze­bie zro­zu­mie­nia funk­cjo­no­wa­nia ana­li­zo­wa­nej orga­ni­za­cji (fir­my) o i tym jak to udokumentować:

…wszyst­ko to co nas ota­cza, samo w sobie jest natu­ral­nie pro­ste. Złożone są, nie poszcze­gól­ne rze­czy, a to, że jest ich wie­le i mają na sie­bie wza­jem­ny wpływ. Pamiętajmy, że jed­na z naj­trud­niej­szych gier na świe­cie ? sza­chy ? to tyl­ko kil­ka­na­ście figur i pro­ste regu­ły ich prze­miesz­cza­nia, sno­oker – naj­trud­niej­sza gra w bilar­da – to to tyl­ko pro­ste kule i kij. Nawet naj­więk­szą orga­ni­za­cję moż­na, w toku ana­li­zy, roz­ło­żyć na skoń­czo­ną licz­bę ról i reguł ich postę­po­wa­nia by zro­zu­mieć jej funk­cjo­no­wa­nie. (żr. Jarosław Żeliński, refe­rat na kon­fe­ren­cji o sys­te­mach ERP).

Analiza biz­ne­so­wa to etap opi­su (zro­zu­mie­nia) mode­lo­wa­nej orga­ni­za­cji (mode­le pro­ce­sów itp.). Potem, powsta­je model roz­wią­za­nia, któ­rym jest nie raz wła­śnie opro­gra­mo­wa­nie, jego logi­ka (patrz powyż­szy cytat) to obiek­to­wy model dzie­dzi­ny sys­te­mu”, a nie jakiś dia­gram klas nafa­sze­ro­wa­ny atry­bu­ta­mi i pozba­wio­ny ope­ra­cji bo jest dokład­nie odwrotnie:

zly modelAnemic Domain Model: This is one of tho­se anti-pat­terns tha­t’s been aro­und for quite a long time, yet seems to be having a par­ti­cu­lar spurt at the moment. I was chat­ting with Eric Evans on this, and we’ve both noti­ced they seem to be get­ting more popu­lar. As gre­at boosters of a pro­per Domain Model, this is not a good thing. (AnemicDomainModel).

Dla kon­tra­stu cytat z jed­nej ze stron WWW pew­nej fir­my szkoleniowej:

Zwróćmy uwa­gę, że na mode­lu dzie­dzi­ny nie umiesz­cza­my klas imple­men­tu­ją­cych logi­kę apli­ka­cji, jej inter­fejs użyt­kow­ni­ka czy war­stwę dostę­pu do danych. Nie war­to też na mode­lu dzie­dzi­ny umiesz­czać metod. (Diagramy klas – model dzie­dzi­ny i pro­jekt apli­ka­cji).

I tyle mam dzi­siaj do powie­dze­nia o nie­któ­rych kon­sul­tan­tach i wykła­dow­cach … (a tu trosz­kę praw­dy)

P.S.

Bardzo czę­sto spo­ty­kam się z tezą, że model dzie­dzi­ny powi­nien opra­co­wy­wać archi­tekt by doko­nać ewen­tu­al­nych opty­ma­li­za­cji jesz­cze przed imple­men­ta­cją. Stawianie takich tez ma w moich oczach dwa głów­ne źró­dła: dostaw­ca usłu­gi (deve­lopr) szu­ka oka­zji by pro­jekt nagiąć do swo­ich potrzeb, do posia­da­nych goto­wych kom­po­nen­tów nie speł­nia­ją­cych jed­nak wyma­gań. Innym powo­dem jest zwy­kła nie­wie­dza. O opty­ma­li­za­cji kil­ka pro­stych tez usta­mi pro­gra­mi­sty: 3 zasa­dy opty­ma­li­za­cji. Więc powtó­rzę: na eta­pie ana­li­zy i pro­jek­to­wa­nia nicze­go nie uprasz­cza­my ani nie opty­ma­li­zu­je­my bo nie wie­my czy w ogó­le zaist­nie­je taka potrze­ba, a opty­ma­li­za­cja ZAWSZE psu­je model.

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.