Analiza a modelowanie czyli ile abstrakcji a ile rzeczywistości

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)

Diagram prawdę Ci powie

Dzisiaj będzie bar­dzo krót­ki wpis, któ­rym nie­mal­że w cało­ści będzie cytat z arty­ku­łu pew­ne­go pro­gra­mi­sty. Każdy ana­li­tyk i pro­jek­tant powi­nien prze­czy­tać cały arty­kuł (nie jest dłu­gi) i koniecz­nie komen­ta­rze pod nim. Jeden komen­tarz zacy­tu­je bo jest zna­mien­ny, choć­by dla­te­go, że moje doświad­cze­nia są dokład­nie takie same:

Co Ty czło­wie­ku, życia nie znasz? Przecież w realu jak­byś poszedł do takie­go i podzie­lił się taki­mi uwa­ga­mi to foch na pare tygo­dni co naj­mniej gwa­ran­to­wa­ny. Kiedyś mia­łem podob­ną sytu­ację (a raczej serię sytu­acji, ale doty­czą­cych rze­czy o mniej­szej ska­li) to efekt był taki, że wola­łem zmie­nić robotę 😉

A teraz zapra­szam do lek­tu­ry tek­stu, któ­ry napi­sał nie ana­li­tyk a pro­gra­mi­sta (a kim jest to pole­cam jego CV na stronie):

Jak to z każ­dym języ­kiem bywa, nie­kie­dy jeste­śmy w sta­nie wydo­być bar­dzo wie­le nawet bez zbyt­nie­go wgłę­bia­nia się w szcze­gó­ły, po pro­stu wie­my, że nie­któ­re rze­czy są waż­niej­sze niż inne. Tak jak w zda­niach, któ­rych spój­ni­kiem jest ?ale?. Każdy wie, że wszyst­ko to, co przed owym ?ale? się znaj­du­je jest nie­war­te słu­cha­nia 😛 I wła­śnie kil­ka takich przy­pad­ków chciał­bym dzi­siaj opi­sać. Sytuacji, w któ­rych rozu­mie­nie całe­go kon­tek­stu jest zbęd­ne, wystar­czy szyb­ki rzut okiem na dia­gram, aby wie­dzieć co jest najważniejsze.

W oma­wia­nych prze­ze mnie przy­pad­kach cho­dzi o szyb­kie wyła­pa­nie błę­dów pro­jek­to­wych, bez koniecz­no­ści zagłę­bia­nia się w logi­kę, któ­ra kry­je się za dia­gra­ma­mi. (Programistyka: Diagram praw­dę Ci powie)

Process for System Architecture and Requirements Engineering

Czy da się wyspe­cy­fi­ko­wać wyma­ga­nia na duże mia­sto? Poproście kil­ka­na­ście osób o wypi­sa­nie tego jakich funk­cji ocze­ku­ją od swo­je­go mia­sta. Dostaniecie dłu­gą listę wyobra­żeń zawie­ra­ją­cych prze­mie­sza­ne moż­li­wo­ści, ich jakość i wydaj­ność. Otóż zło­żo­ne­go sys­te­mu nie da sen­sow­nie” opi­sać z pomo­cą zwy­kłej listy ocze­ki­wań. Będzie bar­dzo duża i zdez­ak­tu­ali­zu­je się toku trwa­nia pro­jek­tu, któ­ry pla­nu­je się raczej na lata niż niż tygodnie.

Książka zawie­ra opis szkie­le­tu (fra­me­work) mode­lo­wa­nia sys­te­mu infor­ma­cyj­ne­go opar­te­go na czte­rech pod­sta­wo­wych obsza­rach: inter­fejs użyt­kow­ni­ka, wej­ście i wyj­ście, klu­czo­wej oraz wspo­ma­ga­ją­cej logi­ki. Główny trzon szkie­le­tu to wej­ście, prze­twa­rza­nie i wyj­ście, czy­li pro­ces”. Autorzy budu­ją sys­tem poję­cio­wy opar­ty na ana­li­zie od ogó­łu do szcze­gó­łu, abs­trak­cji, tak­że obiek­to­wym para­dyg­ma­cie (auto­rzy ope­ru­ją związ­ka­mi całość cześć, dzie­dzi­cze­niem, związ­kiem usłu­go­bior­ca – usłu­go­daw­ca). Złożony sys­tem dzie­lo­ny jest na kom­po­nen­ty, całość jed­nak utrzy­ma­na w duchu biz­ne­so­wych sche­ma­tów blokowych.

W czę­ści opi­su­ją­cej wyma­ga­nia, poja­wia się bar­dzo waż­ne i przy­dat­ne zało­że­nie: wyma­ga­nia są defi­nio­wa­ne nie­za­leż­nie od tech­no­lo­gii. Druga waż­na rzecz: wyma­ga­nia to słow­nik (zesta­wie­nie) cech: moż­li­wo­ści sys­te­mu oraz – tych moż­li­wo­ści (funk­cje) – cechy jako­ścio­we i wydaj­no­ścio­we. Szkielet (abs­trak­cja) sys­te­mu to trzy typy ele­men­tów (w książ­ce trzy per­spek­ty­wy): pamięć (enti­ty model) czy­li miej­sca prze­cho­wy­wa­nia infor­ma­cji (repo­zy­to­ria). Dalej pro­ce­sy – tu, funk­cje prze­twa­rza­ją­ce dane prze­cho­wy­wa­ne w pamię­ci oraz ste­row­nie (spra­wo­wa­nie kon­tro­li) nad całością.

Całość sta­no­wi pew­ne prze­mie­sza­nie ana­li­zy obiek­to­wej (model abs­trak­cji od ogó­łu do szcze­gó­łu z dzie­dzi­cze­niem, kom­po­nen­ty) i struk­tu­ral­nej (mode­le danych i prze­pły­wu danych). Całość jest opa­ko­wa­na” wyma­ga­nia­mi w rozu­mie­niu słow­ni­ka cech systemu.

Z opi­su moż­na wysnuć wnio­sek, że auto­rzy nie wprost (nie powo­łu­ją się na ten model) nawią­zu­ją do obiek­to­we­go mode­lu BCE (opi­sa­łem go w arty­ku­le Wzorzec ana­li­tycz­ny BCE). Korzystają z dia­gra­mu klas UML (jaw­nie o nim pisze) jako mode­lu poję­cio­we­go. Jednak model pro­ce­sów to już model DFD zna­ny z ana­li­zy struk­tu­ral­nej (De Marco). W obsza­rze defi­nio­wa­nia pro­ce­sów (w tej książ­ce funk­cje prze­twa­rza­ją­ce) przy­wo­łu­ją tak­że tabli­ce decy­zyj­ne (tabli­ce decy­zyj­ne).

Warto tę książ­kę prze­czy­tać, by poznać dobrze opi­sa­ną, spój­ną, zorien­to­wa­ną na mode­le, kon­cep­cję ana­li­zy i mode­lo­wa­nia sys­te­mów biz­ne­so­wych. Dla kogoś mają­ce­go przy­wią­za­nie do ana­li­zy struk­tu­ral­nej, opi­sa­ny szkie­let będzie zapew­ne dobrym narzę­dziem pra­cy. Przyznam jed­nak, że nadal koja­rzy mi się to z lata­mi 90-tymi i pierw­szy­mi narzę­dzia­mi typu EJB ([[Enterprise Java Bean]]) i ane­micz­nym mode­lem dzie­dzi­ny. Autorzy przy­wo­łu­ją meto­dy obiek­to­we jako sze­ro­ko obec­nie rekla­mo­wa­ne”, jed­nak mam wra­że­nie, że nie mają prze­ko­na­nia do tego mode­lu, uzna­ją­ce­go ści­sły zwią­zek danych i pro­ce­sów prze­twa­rza­nia w posta­ci obiek­tów. Co cie­ka­we jed­nak widzą zale­ty tego na wyż­szych pozio­mach abs­trak­cji”, a tak się skła­da, że obiek­to­wy para­dyg­mat zakła­da imple­men­ta­cję wła­śnie tej abs­trak­cji – obiek­to­we­go mode­lu – w takiej posta­ci jaka powsta­je na eta­pie ana­li­zy i pro­jek­to­wa­nia (mode­lo­wa­nia) sys­te­mu (prze­czy­taj arty­kuł o DDD).

Dalsza część książ­ki to opis pro­ce­su wytwa­rza­nia apli­ka­cji co tu pomi­nę, tak­że dla­te­go, że nie jest moim celem stresz­cza­nie tu tej książ­ki. Opisałem ją bo (pomi­ja­jąc struk­tu­ral­nie zorien­to­wa­ną meto­dę ana­li­zy i pro­jek­to­wa­nia) bar­dzo dobrze opi­su­je war­tość doda­ną same­go pro­ce­su ana­li­zy opar­tej na mode­lo­wa­niu. Porządkuje to wie­dzą o sys­te­mie, mode­le sta­no­wią też doku­men­ta­cję sys­te­mu, są mapo­wa­ne” na wymagania.

Na koniec war­to pod­kre­ślić jed­ną rzecz: ana­li­za i spe­cy­fi­ko­wa­nie wyma­gań, zakła­da­jąc abs­tra­ho­wa­nie wyma­gań od tech­no­lo­gii, dosko­na­le nada­je się do pro­jek­tów zakła­da­ją­cych zakup goto­we­go opro­gra­mo­wa­nia. Autor nad­mie­nia na począt­ku, iż zakła­da­nie że będzie to od razu jeden mono­li­tycz­ny sys­tem, że taki jest lep­szy, jest moc­no nacią­ga­ne. Nawiązując do meta­fo­ry z budo­wa­niem mia­sta: powsta­je ono w cza­sie, będzie ono raczej zło­że­niem kom­po­nen­tów ([[COTS]]) niż monolitem.

Trzeba tę mieć jed­nak świa­do­mość tego, że książ­kę pierw­szy raz wyda­no w 2000 roku, jej napi­sa­nie mogło trwać ok. roku, może dwóch, a to zna­czy, że opi­su­je ona doświad­cze­nia auto­rów z lat 80 i 90 tych (cze­go auto­rzy nie ukry­wa­ją). To były cza­sy, gdy meto­dy obiek­to­we racz­ko­wa­ły a struk­tu­ral­ne prze­ży­wa­ły jesz­cze szczy­ty popularności.

Co cie­ka­we auto­rzy, w dodat­ku na koń­cu książ­ki, przy­zna­ją, że model zorien­to­wa­ny obiek­to­wo jest bar­dzo dobrą abs­trak­cją sys­te­mu, jed­nak uzna­ją, że na potrze­by imple­men­ta­cji waż­ny jest model struk­tu­ral­ny. Myślę, że to efekt przy­zwy­cza­je­nia auto­rów do trak­to­wa­nia wyma­gań jako prze­pi­su na pisa­nie kodu pro­gra­mu, pisa­nie meto­da­mi i narzę­dzia­mi strukturalnymi…

Tak więc czy­ta­jąc takie książ­ki, nadal popu­lar­ne, nie zapo­mi­naj­my o tym z jakiej epo­ki się wywo­dzą. Nie zapo­mi­naj­my, że meto­dy struk­tu­ral­ne to dro­ga do mono­li­tycz­nych sys­te­mów, któ­rych zwin­ność” jest porów­ny­wal­na raczej do wiel­kie­go traw­le­ra prze­twór­ni na Bałtyku, a dzi­siaj są potrzeb­ne małe, szyb­kie, dedy­ko­wa­ne kutry rybac­kie, któ­re w moż­na bar­dzo w ilo­ści i spe­cja­li­za­cji, łatwo dobrać do panu­ją­cych warun­ków na ryn­ku i zmie­niać w razie potrzeby.

Tytuł: Process for System Architecture and Requirements Engineering
Autor: Derek Hatley, Peter Hruschka, Imtiaz Pirbhai0
Wyd.: Published August 2nd 2013 by Addison-Wesley Professional (Goodreads | Process for System Architecture and Requirements Engineering Dorset House eBooks by Derek Hatley ? Reviews, Discussion, Bookclubs, Lists).

Myślenie obiektowe w programowaniu

Książka adre­so­wa­na do pro­gra­mi­stów, sam tytuł to suge­ru­je. Warto ją kupić (pro­gra­mi­ści) bo bar­dzo wyczer­pu­ją­co opi­su­je to, co nazy­wam imple­men­ta­cją obiek­to­wo­ści”. Samo naucze­nie się (seman­ty­ka i syn­tak­ty­ka) obiek­to­wo zorien­to­wa­ne­go języ­ka pro­gra­mo­wa­nia to mało, war­to poznać na czym ta imple­men­ta­cja pole­ga: czym jest obiekt, dzie­dzi­cze­nie czy kom­po­zy­cja. Autor sku­pia się jed­nak na imple­men­ta­cji samej obiek­to­wo­ści”.

Moim zda­niem książ­ka jak naj­bar­dziej przy­dat­na pro­gra­mi­stom, bo przy­kła­dy są ilu­stro­wa­ne kodem i dia­gra­ma­mi UML. Jednak nie znaj­dzie­cie tam zbyt wie­le o obiek­to­wo zorien­to­wa­nym opi­sie mode­lo­wa­nej rze­czy­wi­sto­ści, czy­li o biz­ne­so­wym aspek­cie pro­gra­mo­wa­nia i pro­jek­to­wa­nia. Z tre­ści książ­ki domy­ślam się, że autor zosta­wia obiek­to­wą ana­li­zę i pro­jek­to­wa­nie ana­li­ty­kom i pro­jek­tan­tom, pro­gra­mi­stów uczy korzy­sta­nia z obiek­to­wo zorien­to­wa­ne­go kom­pi­la­to­ra i rozu­mie­nia go.

Książkę gorą­co pole­cam każ­de­mu pro­gra­mi­ście korzy­sta­ją­ce­mu z obiek­to­wo zorien­to­wa­nych narzę­dzi. Jeżeli jakiś ana­li­tyk lub pro­jek­tant chce zro­zu­mieć ogra­ni­cze­nia imple­men­ta­cji, to jemu tak­że tę książ­kę polecam.

Tytuł: Myślenie obiek­to­we w programowaniu
Autor: Matt Wesfeld
Wydanie: Helion 2014

złożoność złożony system skomplikowany http://hikingartist.files.wordpress.com/

Kolejna wpadka IT: obiektowość

CW 4-1019 Bereza Blad Arystotelesa w IT
CW 4 – 1019 Bereza Blad Arystotelesa w IT

Tym razem wpadł mi w oko dosko­na­ły arty­kuł Pana Bogdana Berezy w COMPUTEROWRLD nr. 4 – 1019 z tego roku. Polecam cały arty­kuł do prze­czy­ta­nia, a po pra­wej cytat, któ­ry obu­dził we mnie potrze­bę uzupełnienia.

Cały arty­kuł doty­czy igno­ro­wa­nia nauki w inży­nie­rii opro­gra­mo­wa­nia na rzecz pro­stych pseu­do­ro­zwią­zań. Tu się z auto­rem w peł­ni zga­dzam: nauka jako szu­ka­nie zro­zu­mie­nia i roz­wią­zań pro­ble­mów poprzez ana­li­zę i uogól­nia­nie ma głę­bo­ki sens, histo­ria poka­zu­je, że tak zwa­ne meto­dy nauko­we są sku­tecz­ne (o czym nie raz tu już pisa­łem) ale też nie­lu­bia­ne bo trudne.

Autor napi­sał tak­że (cytat po pra­wej, moim zda­niem praw­dę), że nastą­pi­ło pew­ne sza­leń­stwo, któ­re w moich oczach dopro­wa­dzi­ło w bran­ży IT to total­ne­go pomie­sza­nia pojęć (ostat­ni aka­pit cyta­tu obok). Nie zgo­dzę się jed­nak z tym, że dane i funk­cje, zade­kla­ro­wa­ne wewnątrz jed­nej funk­cji prze­sta­ją ist­nieć, gdy się te funk­cję opu­ści” (pierw­szy aka­pit cyta­tu po pra­wej). Otóż w meto­dach obiek­to­wych nie ist­nie­je poję­cie funk­cji”, są ope­ra­cje i meto­dy oraz atry­bu­ty a nie dane, a znik­nąć mogą co naj­wy­żej atry­bu­ty obiek­tu (tu trak­to­wa­ne jako jakieś dane) pod warun­kiem, że go – ten obiekt – znisz­czy­my. Tu chy­ba jed­nak mamy pomie­sza­nie pojęć (dodam, że nie rozu­miem stwier­dze­nia funk­cja zawie­ra funk­cje i dane”).

W czym pro­blem? Otóż nale­ży bar­dzo rygo­ry­stycz­nie odróżnić:

  • ana­li­zę obiek­to­wą (OOA – Object Oriented Analysis)
  • pro­jek­to­wa­nie obiek­to­we (OOD – Object Oriented Design)
  • pro­gra­mo­wa­nie obiek­to­we (OOP – Object Oriented Programming)

Autor arty­ku­łu, pisząc jedy­nie o pro­gra­mo­wa­nie obiek­to­wym, w moich oczach ma rację. Co do zgod­no­ści OO z psy­chi­ką to i ja mam wąt­pli­wo­ści, i tu chy­ba fak­tycz­nie pomy­sło­daw­cy popłynęli.

Tu przy­po­mnę kolej­ne waż­ne pojęcia:

  • ogól­na teo­ria sys­te­mów to teo­ria ope­ru­ją­ca poję­ciem sys­tem, defi­nio­wa­nym jako zbiór ele­men­tów współ­pra­cu­ją­cych w okre­ślo­nym celu”, teo­ria ta w zasa­dzie sta­no­wi obec­nie pod­sta­wę tak zwa­nych metod naukowych,
  • para­dyg­mat obiek­to­wy to trak­to­wa­nie okre­ślo­nej rze­czy­wi­sto­ści jako zbio­ru współ­pra­cu­ją­cych obiek­tów reali­zu­ją­cych okre­ślo­ne funk­cje wobec swo­je­go otoczenia”.

Jak widać są to bar­dzo do sie­bie podob­ne (nie­mal­że toż­sa­me) poję­cia. Studiując lite­ra­tu­rę przed­mio­tu zary­zy­ku­ję tezę, że ta zbież­ność nie jest przy­pad­ko­wa :), pierw­sze obiek­to­we języ­ki pro­gra­mo­wa­nia powsta­ły w ośrod­kach aka­de­mic­kich na potrze­by pro­wa­dze­nia badań opar­tych o symulacje.

W świe­cie ludzi IT” poję­cie obiek­to­wo­ści” zosta­ło cał­ko­wi­cie zawłasz­czo­ne na uży­tek języ­ków pro­gra­mo­wa­nia. Jest to w moich oczach wiel­ka szko­da wyrzą­dzo­na obiek­to­we­mu podej­ściu, teo­rii a tak­że samej inży­nie­rii opro­gra­mo­wa­nia. Autor ma rację pisząc, że obiek­to­wość” jako taka (powyż­sze defi­ni­cje) nie ma nic wspól­ne­go (nie tyl­ko) z prze­no­sze­niem danych ze sto­su na ster­tę czy z dzie­dzi­cze­niem. Ale to wła­śnie efekt tego zawłasz­cze­nia (i opis imple­men­ta­cji obiek­to­wo­ści” w języ­kach programowania).

Gdzie zalety i sukces obiektowości?

Jednym z klu­czo­wych czyn­ni­ków ryzy­ka pro­jek­tów z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, two­rzo­ne­go dla firm i orga­ni­za­cji, jest zła jakość spe­cy­fi­ka­cji wyma­gań. Zajmuję się o tym od lat, wszel­kie (słusz­nie skry­ty­ko­wa­ne przez Pana Berezę) pro­ste meto­dy zbie­ra­nia wyma­gań” dają w efek­cie to, co nazy­wa­ne jest nie­kom­plet­no­ścią i nie­spój­no­ścią. Przyczyną pora­żek pro­jek­tów pro­gra­mi­stycz­nych, poda­wa­ną w 100% przy­pad­ków tych pora­żek, jest nie­kom­plet­ność i nad­mia­ro­wość spe­cy­fi­ka­cji wyma­gań. Niekompletność to wyma­ga­nia odkry­wa­ne dopie­ro na eta­pie wdro­że­nia, nad­mia­ro­wość to tak zwa­ne wyma­ga­nia osie­ro­co­ne, czy­li funk­cjo­nal­no­ści zgło­szo­ne jako wyma­ga­ne na eta­pie ana­li­zy wyma­gań i nie wyko­rzy­sty­wa­ne po dostar­cze­niu opro­gra­mo­wa­nia. Pierwsze gene­ru­ją dodat­ko­we kosz­ty, dru­gie to czy­ste mar­no­traw­stwo środ­ków. Nieodkryte wyma­ga­nia dodat­ko­wo nisz­czą” pier­wot­ny harmonogram.

Jak poma­ga tu obiek­to­wość”? Pomaga jako meto­da ana­li­zy, poma­ga jako meto­da pro­jek­to­wa­nia, poprze­dza­ją­ce­go spe­cy­fi­ko­wa­nie wyma­gań. W czym rzecz?

Popularna i fał­szy­wa teza, mówią­ca, że wyma­ga­nia się zbie­ra”, pro­wa­dzi do dekla­ra­tyw­nej i nie­we­ry­fi­ko­wal­nej spe­cy­fi­ka­cji wyma­gań funk­cjo­nal­nych i poza-funk­cjon­la­nych (przy­po­mi­nam wyma­ga­nia odkry­te i osie­ro­co­ne). Popularna i mitycz­na jakość wyma­gań nazy­wa­na SMART i FURPS nie daje żad­ne­go narzę­dzia do testo­wa­nia kom­plet­no­ści i nie­sprzecz­no­ści wyma­gań, więc nie da się stwier­dzić, że kon­kret­na spe­cy­fi­ka­cja wyma­gań jest SMART i FURPS, wcze­śniej niż po zakoń­cze­niu pro­jek­tu. Tak więc FURPS i SMART spo­koj­nie, moim zda­niem, moż­na zali­czyć do tego co Pan Bereza nazy­wa bzdur­ną misty­fi­ka­cją”, i co nie­ja­ko wyja­śnia pew­na filo­zo­ficz­na praw­da” mówią­ca: nie ist­nie­ją pro­ste meto­dy roz­wią­zy­wa­nia zło­żo­nych problemów.

Sprawdzoną w inży­nie­rii jako takiej, meto­dą, jest pro­ces wytwór­czy mają­cy trzy eta­py: ana­li­za potrzeb, pro­jek­to­wa­nie i testy, wyko­na­nie (wytwo­rze­nie) na bazie pro­jek­tu. Wprowadzenie zmian w każ­dym następ­nym eta­pie jest prze­cięt­nie o rząd wiel­ko­ści kosz­tow­niej­sze. Wynika z tego, że inwe­sty­cja w ana­li­zę i pro­jek­to­wa­nie poprze­dza­ją­ce budo­wę, jest jak naj­bar­dziej uza­sad­nio­na. Jednak kolek­cjo­no­wa­nie wyma­gań” to nie jest żad­na ana­li­za, to dopie­ro zbie­ra­nie danych do analizy.

A gdzie tu OOA, OOD, OOP?

Jak podejść do pro­ble­mu spe­cy­fi­ko­wa­nia wyma­gań” z dużo mniej­szym ryzy­kiem? Zamówić opro­gra­mo­wa­nie na bazie pro­jek­tu, a nie na bazie opi­su czar­nej skrzyn­ki”. Co pro­jek­to­wać? Na pew­nie nie wszyst­ko. Wg. róż­nych sza­cun­ków, tak zwa­na logi­ka biz­ne­so­wa to ok. 3 – 5% cało­ści kodu (któ­ry zawie­ra mię­dzy inny­mi roz­bu­do­wa­ne kom­po­nen­ty komu­ni­ka­cyj­ne, inte­gra­cyj­ne, wydaj­no­ścio­we, bez­pie­czeń­stwa, set­ki biblio­tek, itp.) pro­blem w tym, że te 3 – 5% kodu decy­du­je w 100% o przy­dat­no­ści aplikacji.

Analiza obiek­to­wa (OOA) to meto­da ana­li­zy i opi­su przed­mio­tu ana­li­zo­wa­ne­go (np. orga­ni­za­cji). Projektowanie obiek­to­we (OOD) to meto­da opi­su logi­ki dzia­ła­nia tego co chce­my stwo­rzyć (narzę­dzie pra­cy). Programowanie obiek­to­we to jest to co przy­wo­łał Pan Bereza, jed­nak cechą OOP jest to, że pro­jekt obiek­to­wy, pro­dukt OOD jest moż­li­wy do imple­men­ta­cji wprost” w języ­ku obiek­to­wym na eta­pie OOP. Innymi sło­wy wyma­ga­niem nie jest lista wyma­gań” a pro­jekt, ana­lo­gicz­nie jak w każ­dej innej inży­nie­rii: wyma­ga­niem wobec wyko­naw­cy jest pro­jekt tego co nale­ży wyko­nać a nie tyl­ko słow­ny opis tego cze­go ocze­ku­je zamawiający.

OOA i OOD jest łączo­ne w OOAD z tego powo­du, że obiek­to­wy opis (model) cze­goś” jest 9w meto­dach obiek­to­wych) zara­zem pro­jek­tem tego cze­goś”. Mając obiek­to­wy model opro­gra­mo­wa­nia (czę­ści opi­su­ją­cej jego biz­ne­so­wą logi­kę dzia­ła­nia, nazy­wa­nej Modelem Dziedziny) może­my spraw­dzić (prze­te­sto­wać) jak speł­nia on wyma­ga­nia funk­cjo­nal­ne zanim jesz­cze, powsta­nie znacz­nie droż­sza od pro­jek­tu, imple­men­ta­cja. Mamy szan­se, rela­tyw­nie niskim kosz­tem, zmie­nić pro­jekt zanim uru­cho­mi­my kosz­tow­ny zespół pro­gra­mi­stów. Na bazie takie­go mode­lu moż­li­we jest w ogó­le wyko­na­nie ana­li­zy wyko­nal­no­ści.

Metoda ta jest spraw­dzo­na, dzia­ła, jest sku­tecz­na. Pierwszy, gło­śno, napi­sał o tym Eric Evans w dzie­le Domain-Driven Design: Tackling Complexity in the Heart of Software (pisa­łem o tym tu: Poziomy szcze­gó­ło­wo­ści wyma­gań ? wzor­ce DDD ? czy­li czym jest ana­li­za obiek­to­wa). Problem pole­ga na tym, że biz­ne­so­wa ana­li­za obiek­to­wa (OOAD), dają­ca jako efekt model dzie­dzi­ny (czy­li sed­no biz­ne­so­wych apli­ka­cji), wyma­ga zupeł­nie innych kom­pe­ten­cji (nie licząc rozu­mie­nia samej obiek­to­wo­ści) niż kom­pe­ten­cje pro­gra­mi­stów i archi­tek­tów opro­gra­mo­wa­nia. Nie praw­dą jest, że tyl­ko deve­lo­per” ma tu kom­pe­ten­cje do pro­jek­to­wa­nia opro­gra­mo­wa­nia. W obsza­rze ana­li­zy i mode­lo­wa­nia biz­ne­su” z regu­ły nie ma żad­nych kom­pe­ten­cji. Potwierdza to tak­że obec­ny model kom­pe­ten­cji Analityka Biznesowego pre­zen­to­wa­ny przez orga­ni­za­cję IIBA.

Tak więc obiek­to­wość jako pana­ceum na pro­ble­my pro­gra­mi­stów i pro­gra­mo­wa­nia to w moich oczach jak naj­bar­dziej wpad­ka. Obiektowość jako sku­tecz­ne meto­da ana­li­zy świa­ta” i jego mode­lo­wa­nia to suk­ces, ale to tyl­ko kon­ty­nu­acja roz­wo­ju ogól­nej teo­rii sys­te­mów. Obiektowość dała tej teo­rii bar­dzo dobre narzę­dzie – obiek­to­we meto­dy mode­lo­wa­nia. Specyfikowanie wyma­gań w posta­ci czar­nej skrzyn­ki się nie spraw­dza, sta­ty­sty­ki pora­żek pro­jek­tów są nie­zmien­ne od lat. Specyfikacja wyma­gań w posta­ci pro­jek­tu jest nie­mal­że dosko­na­ła (ale tyl­ko na tyle na ile dosko­na­ły jest projekt). 

Arystoteles (jak słusz­nie zauwa­żył Pan Bereza), uwa­żał, że przed­mio­ty cięż­sze spa­da­ją szyb­ciej i miał on pra­wo posłu­żyć się heu­ry­sty­ką, w jego cza­sach fizy­ka nawet nie racz­ko­wa­ła. Nie zapo­mi­naj­my jed­nak, że Arystoteles dał pod­wa­li­ny dzi­siej­szych metod nauko­wych, tezą: praw­dzi­wa wie­dza to zna­jo­mość przyczyn.

Mamy jed­nak inny para­doks: Znamy sta­ty­sty­ki mówią­ce, że ok. 75% pro­jek­tów IT to poraż­ki, a mimo to nadal naj­czę­ściej sto­so­wa­ne są meto­dy wyko­rzy­sty­wa­ne przez więk­szość”. To się nazy­wa kon­for­mizm Project Managera, któ­ry jak widać, jest sil­niej­szy od umie­jęt­no­ści wycią­ga­nia wnio­sków: histo­ria uczy ludzi, że histo­ria nicze­go ludzi nie nauczyła…

Demo System Szachownica

Z uwa­gi na zain­te­re­so­wa­nie moim pro­jek­tem demo” stwo­rzy­łem tę stro­nę. Tu będą się poja­wia­ły infor­ma­cje o kolej­nych eta­pach two­rze­nia tego doku­men­tu. Powiadomienia o postę­pach będą wysy­ła­ne mailem do subskrybentów.

Projekt Szachy ma na celu poka­za­nie na pro­stym przy­kła­dzie, toku ana­li­zy i pro­duk­tów jakie two­rzę w roli ana­li­ty­ka i pro­jek­tan­ta. Dokument ten może zawie­rać pew­ne bra­ki (brak pew­nych szcze­gó­łów) gdyż celem tego doku­men­tu jest zade­mon­stro­wa­nie zawar­to­ści tego rodza­ju doku­men­ta­cji a nie szcze­gó­ło­we opra­co­wa­nie real­ne­go pro­jek­tu, będzie to jed­nak zazna­czo­ne w treści.

Kliknij i pobierz aktu­al­ny plik projektu

Wszelkie pyta­nia i suge­stie na temat tre­ści pro­jek­tu pro­szę zgła­szać poni­żej, będę na nie sys­te­ma­tycz­nie odpowiadał.