Permanentne dys­ku­sje z wie­lo­ma pro­gra­mi­sta­mi utrwa­la­ją we mnie pewien ste­reo­typ: inży­nier to dobry wyko­naw­ca ale żaden ana­li­tyk. Czy to coś złe­go? Absolutnie nie, dobry inży­nier jest na wagę zło­ta ale dobry inży­nier powi­nien mieć jed­ną klu­czo­wą cechę: nie dys­ku­tu­je z pro­jek­tan­tem (jeże­li tyl­ko pro­jek­tant potra­fi uza­sad­nić cze­go chce). Ale po kolei.

Popatrzmy do Wikipedii bo w znacz­nej mie­rze jest two­rzo­na przez pro­gra­mi­stów i entu­zja­stów infor­ma­ty­ki, choć chy­ba nale­ży raczej powie­dzieć: pro­gra­mo­wa­nia (dodam, że w pra­wie każ­dej fir­mie obser­wu­ję dwa syn­dro­my: każ­dy kto nie jest infor­ma­ty­kiem zna się na mar­ke­tin­gu, pozo­sta­li zna­ją się i na pro­gra­mo­wa­niu i na marketingu).

Programowanie obiek­to­we (ang. object-orien­ted pro­gram­ming) ? para­dyg­mat pro­gra­mo­wa­nia, w któ­rym pro­gra­my defi­niu­je się za pomo­cą obiek­tów ? ele­men­tów łączą­cych stan (czy­li dane, nazy­wa­ne naj­czę­ściej pola­mi) i zacho­wa­nie (czy­li pro­ce­du­ry, tu: meto­dy). Obiektowy pro­gram kom­pu­te­ro­wy wyra­żo­ny jest jako zbiór takich obiek­tów, komu­ni­ku­ją­cych się pomię­dzy sobą w celu wyko­ny­wa­nia zadań. Podejście to róż­ni się od tra­dy­cyj­ne­go pro­gra­mo­wa­nia pro­ce­du­ral­ne­go, gdzie dane i pro­ce­du­ry nie są ze sobą bez­po­śred­nio zwią­za­ne. Programowanie obiek­to­we ma uła­twić pisa­nie, kon­ser­wa­cję i wie­lo­krot­ne uży­cie pro­gra­mów lub ich fragmentów.

Największym atu­tem pro­gra­mo­wa­nia, pro­jek­to­wa­nia oraz ana­li­zy obiek­to­wej jest zgod­ność takie­go podej­ścia z rze­czy­wi­sto­ścią – mózg ludz­ki jest w natu­ral­ny spo­sób naj­le­piej przy­sto­so­wa­ny do takie­go podej­ścia przy prze­twa­rza­niu infor­ma­cji. Już Platon postu­lo­wał dwo­istość: ​„byt” – ​„idea (wzo­rzec) bytu”, np. książ­ka jako idea ogól­na – w ter­mi­no­lo­gii pla­toń­skiej: dosko­na­ła (choć nie­do­okre­ślo­na), i książ­ka kon­kret­na np. zbiór baśni leżą­cy na pią­tej pół­ce. Podobnie, choć póź­niej Arystoteles ana­li­zu­jąc rze­czy­wi­stość wpro­wa­dził poję­cia for­my i mate­rii. (źr. WIKI)

Mamy tu więc dwa wąt­ki: tech­nicz­ny czy­li imple­men­ta­cja [[para­dyg­ma­tu]] obiek­to­we­go w języ­kach pro­gra­mo­wa­nia oraz huma­ni­stycz­ny czy­li opis (model) rze­czy­wi­sto­ści: byty i ich postrze­ga­nie przez czło­wie­ka (w zasa­dzie filo­zo­fia, a kon­kret­nie [[feno­me­no­lo­gia]]: wśród waż­nych pojęć feno­me­no­lo­gii znaj­du­je się [[ana­li­za eide­tycz­na]], czy­li dąże­nie do uchwy­ce­nia isto­ty tego, co dane, ide­acja, docie­ra­nie do isto­ty zja­wisk, widze­nie istot­no­ścio­we. W naocz­no­ści istot­no­ścio­wej dana jest czy­sta isto­ta zja­wi­ska. Uchwycenie tej isto­ty nie musi być prze­pro­wa­dzo­ne na wie­lu przy­kła­dach, wystar­czy nawet jeden lub tyl­ko naocz­ność wyobra­że­nio­wa (przy­kład wyobra­żo­ny)).

Modelowanie rze­czy­wi­stych bytów nie ma nic wspól­ne­go z pro­gra­mo­wa­niem czy infor­ma­ty­ką (przy­po­mi­nam tak­że, że [[teo­ria infor­ma­cji]] i [[infor­ma­ty­ka]] to nie toż­sa­me dzie­dzi­ny wie­dzy) . Raczej potrzeb­na jest do tego [[teo­ria pozna­nia czy­li epi­ste­mo­lo­gia]], [[onto­lo­gia]] czy seman­ty­ka a tak­że [[teo­ria komu­ni­ka­cji społecznej]].

Model dzie­dzi­ny więc, to nic inne­go jak zespół pojęć, związ­ków mię­dzy tymi poję­cia­mi, tego jak czło­wiek postrze­ga te byty rze­czy­wi­ste na bazie nazw, któ­rych uży­wa do ich ozna­cza­nia. Powszechnie pod­no­szo­ny ​„brak wie­dzy klien­ta o tym co chce”, to tak na praw­dę brak kom­pe­ten­cji pro­gra­mi­stów do odczy­ta­nia tego co swo­imi poję­cia­mi prze­ka­zu­je im klient. 

Nie piszę o tym dla­te­go, co mi się cza­sa­mi zarzu­ca, by zamu­lić ana­li­zę teo­rią i udo­wad­niać coś pro­gra­mi­stom. Piszę o tym dla­te­go, że ana­li­za jako drą­że­nie tego co chcą ludzie powie­dzieć i co mówią, taka wła­śnie jest: nieinformatyczna.

Naturalnym więc bie­giem wyda­rzeń w two­rze­niu opro­gra­mo­wa­nia powin­no być więc mode­lo­wa­nie ​„świa­ta opi­sy­wa­ne­go” a potem ​„odtwo­rze­nie” go w kodzie opro­gra­mo­wa­nia. Wcześniej nale­ży okre­ślić co i po co ma zna­leźć odzwier­cie­dle­nie w pro­gra­mie. Być może ktoś dostrze­że tu ele­men­ty DDD ([[Domain Driven Design]], ang. pro­jek­to­wa­nie ste­ro­wa­ne mode­lem dzie­dzi­ny) i słusz­nie bo tak wła­snie jest.

Komponent opro­gra­mo­wa­nia odpo­wie­dzial­ny za reali­za­cję wyma­gań funk­cjo­nal­nych, omó­wio­ny dalej Model, to nic inne­go jak pro­gra­mo­wa ​„symu­la­cja” kawał­ka rze­czy­wi­ste­go świa­ta. Nie moż­na jej abso­lut­nie uprasz­czać, w prze­ciw­nym wypad­ku ​„psu­je­my pro­gram” odda­la­jąc go od rze­czy­wi­sto­ści. Paradoksalnie przy­kła­dem takie­go psu­cia jest nor­ma­li­za­cja rela­cyj­nej bazy danych (redun­dan­cje są typo­wym ele­men­tem rze­czy­wi­sto­ści, usu­wa­nie ich to nisz­cze­nie związ­ku pomię­dzy pro­gra­mem a świa­tem jaki pro­gram modeluje).

Jak zwró­co­no uwa­gę w przy­to­czo­nej defi­ni­cji: ​„Największym atu­tem pro­gra­mo­wa­nia, pro­jek­to­wa­nia oraz ana­li­zy obiek­to­wej jest zgod­ność takie­go podej­ścia z rze­czy­wi­sto­ścią”. Tak więc nale­ży ​„posiąść” tę zgod­ność i rze­czy­wi­stość i nie psuć jej.

Kto powi­nien mode­lo­wać ​„nasz świat”? Dla pro­gra­mi­sty, jak sami to nie raz pod­kre­śla­ją, obiekt to struk­tu­ra łączą­ca w kodzie dane prze­twa­rza­ne z meto­da­mi ich prze­twa­rza­nia. Ale wokół nas są obiek­ty rze­czy­wi­ste: świat i jego zawi­ło­ści. To suge­ru­je raczej, że ana­li­za obiek­to­wa i two­rze­nie mode­lu ​„rze­czy­wi­sto­ści” nie ma nic wspól­ne­go z pro­gra­mo­wa­niem. To raczej jest tak, że pro­gra­mi­sta powi­nien ​„odtwo­rzyć” w kodzie otrzy­ma­ny od ana­li­ty­ka i pro­jek­tan­ta, model. Po to powsta­ły obiek­to­we narzę­dzia by wła­śnie uła­twić pro­gra­mi­stom imple­men­ta­cje obiek­to­wych mode­li a ana­li­ty­kom ich two­rze­nie, dać im wspól­ny (powszech­ny, [[Ubiquitous Language]]) język.

A tu pro­szę: inży­nier ze swo­im ​„obiek­to­wym języ­kiem pro­gra­mo­wa­nia, struk­tu­ra­mi kodu i danych” zabie­ra się do tego, do cze­go nie ma żad­ne­go przy­go­to­wa­nia: mode­lo­wa­nie fir­my (świa­ta) i tego jak jest zarzą­dza­na. Rozumiem obu­rze­nie: to my jeste­śmy pro­gra­mi­sta­mi i my wie­my jak pro­gra­mo­wać. Owszem, JAK ale nie CO. Nie wystar­czy że popy­ta­cie use­ra jak pra­cu­je, trze­ba zro­zu­mieć: co i po co robi a potem stwo­rzyć tego model. Dobry model musi ​„odzwier­cie­dlać rzeczywistość”.

Z obiek­to­wo­ści pro­gra­mi­ści rozu­mie­ją tyl­ko tyle, że to ​„coś co łączy dane i funk­cje”. Ja nicze­go wię­cej nie ocze­ku­ję od pro­gra­mi­stów. Ilu pro­gra­mi­stów czy­ta­ło ze zro­zu­mie­niem Druckera, Portera, Kottlera?

Wielu z nich jest (będzie jak to prze­czy­ta ;)) jak obra­żo­ne dzie­ci bawią­ce się sza­cha­mi: roz­po­zna­ją koni­ka, wie­że czy kró­la, tra­fia­ją figu­ra­mi w pola sza­chow­ni­cy i nie dadzą sobie powie­dzieć, że Goniec to tyl­ko po sko­sie. Szachy to nie ​„jakieś drew­nia­ne pio­ny i 64 pola do ich usta­wia­nia”. Można zagrać tymi pio­na­mi na tej plan­szy w war­ca­by a nawet w zbi­ja­ka, ale to nadal są sza­chy i ta gra ma nie­co inne zasa­dy mimo, że to fak­tycz­nie tyl­ko plan­sza i drew­nia­ne pio­ny i fak­tycz­nie da się z powo­dze­niem zagrać ​„tym sprzę­tem” w war­ca­by, a nawet w chiń­czy­ka (w koń­cu to tyl­ko drew­nia­ne figurki).

Tak więc obiek­to­we pro­gra­mo­wa­nie to narzę­dzie, moż­na nim wie­le zro­bić na wie­le spo­so­bów, ale jeże­li powie­my sobie, że pro­jek­tu­je­my jakąś rze­czy­wi­stość biz­ne­so­wą meto­da­mi obiek­to­wy­mi, to z całym sza­cun­kiem: ocze­ku­ję od pro­gra­mi­sty, że uzna fakt, że figur­ki i plan­sza to jed­nak sza­chy. Od sto­la­rza nie ocze­ku­ję, że będzie mistrzem sza­cho­wym, ocze­ku­ję, że pod dyk­tan­do sza­chi­sty (wyma­ga­nia) wyko­na naj­lep­szą plan­szę i pio­ny i nie będzie się wda­wał w dys­ku­sje na temat tego, dla­cze­go koń na sza­chow­ni­cy wyci­na takie śmiesz­ne hołub­ce i for­so­wał tezy by uznać, że ma ​„cho­dzić pro­sto” i będzie pro­ściej. Szachista tak chce i już, ma pra­wo bo to on zama­wia, to on tu jest sza­chi­stą a sto­larz stolarzem.

Proces powstawania oprogramowania

Tu powo­łam się (po raz kolej­ny) na wzo­rzec pro­jek­to­wy MVC. Obrazuje on podział opro­gra­mo­wa­nia na trzy klu­czo­we podsystemy:

Stosowanie tego wzor­ca ma pewien głę­bo­ki sens: podział odpo­wie­dzial­no­ści zgod­nie z regu­łą obiek­to­wą mówią­cą, że obiekt (tak­że kom­po­nent i jego inter­fejs) ma wszyst­kie i tyl­ko te kom­pe­ten­cje, któ­re są wyma­ga­ne do wywią­za­nia się z kon­trak­tu ([[pro­jek­to­wa­nie zorien­to­wa­ne na kon­trakt]]). Tym kon­trak­tem jest ​„to za co odpo­wia­da obiekt i tyl­ko to”. Powyższy dia­gram (nie jest to [[dia­gram klas]], to sche­mat blo­ko­wy obra­zu­ją­cy wza­jem­ne oddzia­ły­wa­nie na sie­bie kom­po­nen­tów: blo­czek ozna­cza kom­po­nent, strzał­ka poka­zu­je kie­ru­nek oddzia­ły­wa­nia) obra­zu­je zobo­wią­za­nia tych trzech komponentów.

Nie wgłę­bia­jąc się w szcze­gó­ły tego wzor­ca (opi­sy dostęp­ne w sie­ci) istot­ne jest odręb­ne ist­nie­nie kom­po­nen­tów. Model zawie­ra w sobie (mode­lu­je w pro­jek­cie i imple­men­tu­je w kodzie) ​„świat rze­czy­wi­sty wyra­żo­ny w obiek­to­wym para­dyg­ma­cie” (kon­trakt brzmi: wiem wszyt­ko o tym czym jest i jak dzia­ła świat w oto­cze­niu użyt­kow­ni­ka), zarów­no dane jak i logi­kę ich zacho­wań. View ma kon­trakt inny: bio­rę na sie­bie całą inte­rak­cję pro­gra­mu z użyt­kow­ni­kiem. Controller zaś mówi: bio­rę na sie­bie zapa­mię­ty­wa­nie, całą komu­ni­ka­cję, jej spraw­ność i nie­za­wod­ność, w tym tak­że pomię­dzy View i Modelem.

Mamy pro­sty podział odpo­wie­dzial­no­ści: Grafik odpo­wia­da za pro­jekt View, Analityk Biznesowy za Model (przy­po­mnę: co i jak jest prze­twa­rza­ne) a pro­gra­mi­sta za tech­no­lo­gię i ubra­nie tego wszyst­kie­go w dzia­ła­ją­cy kod czy­li za imple­men­ta­cję. Jeżeli uzna­my, że ana­li­tyk opra­cu­je Model meto­da­mi obiek­to­wy­mi to mamy wła­śnie atut pro­gra­mo­wa­nia, pro­jek­to­wa­nia oraz ana­li­zy obiek­to­wej czy­li zgod­ność takie­go podej­ścia z rzeczywistością.

No i teraz sko­ro tak, to samo się nasuwa:

1. wyko­naj ana­li­zę i opra­cuj obiek­to­wy model rze­czy­wi­sto­ści, upew­nij się, że jest praw­dzi­wy (zgod­ny z tą rzeczywistością),
2. opra­cuj pro­jekt tego co zoba­czy użyt­kow­nik pro­gra­mu: ekrany,
3. zapisz ogra­ni­cze­nia sto­so­wa­nia przy­szłe­go programu,
4. daj to pro­gra­mi­stom by stwo­rzy­li zgod­ny z tymi wyma­ga­nia­mi, dzia­ła­ją­cy program.

Czy inna kolej­ność jest moż­li­wa? Czy widać, że bez pro­jek­tów Modelu i ekra­nów nie ma się co brać za kodo­wa­nie? Co kodo­wać? Jak na tym tle wyglą­da­ją meto­dy pole­ga­ją­ce, na tym, że od razu po roz­mo­wie z nie­ro­zu­mie­ją­cym obiek­to­we­go para­dyg­ma­tu użyt­kow­ni­kiem, przy­stę­pu­je się do kodo­wa­nia? Jak będzie prze­bie­ga­ło two­rze­nie kodu, jeśli wie­my na razie tyl­ko to, że ma powstać fak­tu­ra zaś o tym, że doty­czy zamó­wień z inne­go sys­te­mu i wła­sne­go maga­zy­nu dowie­my się jutro mając już ​„coś napi­sa­ne”? Bo ja mam wra­że­nie, że to po pro­tu sta­re funk­cyj­ne podej­ście tyle, że z uży­ciem ​„klas obiek­tów, metod i atry­bu­tów” bo nie raz, patrząc na pra­ce nie­któ­rych pro­gra­mi­stów, nie prze­cho­dzi mi przez gar­dło ​„para­dyg­mat obiektowy”.

Czym to gro­zi? Długim cza­sem kodo­wa­nia, kolej­ny­mi pro­to­ty­pa­mi i dzie­siąt­ka­mi mody­fi­ka­cji kodu, bra­kiem zro­zu­mie­nia, uprosz­cze­nia­mi wyma­gań czy­li jed­nym sło­wem: duży­mi pie­niędz­mi za kiep­ski pro­gram (skąd to znamy??).

Dlatego pro­szę pro­gra­mi­stów: rób­cie to co rozu­mie­cie i nie wma­wiaj­cie niko­mu, że wie­cie lepiej jak zarzą­dzać fir­mą Waszych klien­tów. Róbcie to co każ­dy dobry sto­larz: popro­ście klien­ta o rysu­nek tego co ma powstać i zrób­cie. Nie zapo­mi­naj­cie, że dobry sto­larz to nie to samo do dobry pro­jek­tant, jak klient nie potra­fi ryso­wać (a naj­czę­ściej nie, bo nie to jest jego kom­pe­ten­cją), dobry sto­larz zawsze ode­śle do pro­jek­tan­ta po rysu­nek. Między inny­mi dla­te­go, by póź­niej nie być posą­dzo­nym o stron­ni­czość czy­li ryso­wa­nie tyl­ko tego co jest łatwe w wyko­na­niu. Rzecz w tym, że nie ma być łatwe dla sto­la­rza a dobre dla klienta.

Pod tym wszyst­kim pod­pi­su­ję się ja, Jarek Rysownik

P.S.

Ten arty­kuł powi­nien mieć chy­ba tytuł: Manifest analityka-projektanta ;).