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…

Jarosław Żeliński

BIO: Od roku 1991 roku, nie­prze­rwa­nie, reali­zu­ję pro­jek­ty z zakre­su ana­liz i pro­jek­to­wa­nia sys­te­mów, dla urzę­dów, firm i orga­ni­za­cji. Od 1998 roku pro­wa­dzę tak­że samo­dziel­ne stu­dia i pra­ce badaw­cze z obsza­ru ana­li­zy sys­te­mo­wej i mode­lo­wa­nia (mode­le jako przed­miot badań: ORCID). Od 2005 roku, jako nie­eta­to­wy wykła­dow­ca aka­de­mic­ki, pro­wa­dzę wykła­dy i labo­ra­to­ria (onto­lo­gie i mode­lo­wa­nie sys­te­mów infor­ma­cyj­nych, aktu­al­nie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspi­cja­mi Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje bada­nia i publi­ka­cje nie mają finan­so­wa­nia z zewnątrz, jako ich autor dekla­ru­ję brak kon­flik­tu interesów.

it​-con​sul​ting​.pl/​f​i​r​m​a​-​i​t​-​c​o​n​s​u​l​t​i​n​g​-​j​a​r​o​s​l​a​w​-​z​e​l​i​n​s​k​i​/​j​a​r​o​s​l​a​w​-​z​e​l​i​n​s​ki/