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…

Inne artykuły na podobny temat

image_print(wydruk PL)

Komentarze

  1. Sławomir Sobótka 5 marca 2014 at 13:09

    Znamy z histo­rii wie­le przy­pad­ków, gdy prze­ło­mo­we odkry­cie nastą­pi­ło przy­pad­kiem w cza­sie eks­pe­ry­men­tów gdzie uwa­ga była sku­pio­na na czymś innym. I w niczym to nie ujmu­je tym odkryciom.

    Co do sto­su i ster­ty, to pro­gra­mi­ści w więk­szo­ści (w szcze­gól­no­ści w apli­ka­cjach biz­ne­so­wych) nie wie­dzą (i nie muszą wie­dzieć) jak to tam pod spodem” działa.

    Co do mode­lu obiek­to­we­go, to bar­dzo czę­sto wła­śnie go nie ma – zamiast tego jest model struk­tur danych – nazy­wa­nych błęd­nie obiek­ta­mi, więc nie ma duże­go sen­su oce­nia­nie czy dane podej­ście dzia­ła czy nie, jeże­li nie upew­ni­my się czy w obser­wo­wa­nej prób­ce to podej­ście było fak­tycz­nie zasto­so­wa­ne, czy jedy­nie ktoś tak twierdzi:)

    W boga­tym wachla­rzu tech­nik DDD mamy zarów­no tech­ni­ki obiek­to­we, jak i pro­ce­du­ral­ne, funk­cyj­ne, może­my doda­wać DSLe, podej­ście dekla­ra­tyw­ne. Cokolwiek, co powo­li zbu­do­wać wspól­ny model pro­ble­mu – wspól­ny dla eks­per­ta dome­no­we­go (nie użyt­kow­nik i nie klient) i mode­la­rza oraz imple­men­to­wal­ny 1:1 w jed­nej z warstw systemu.

    Z tym zbie­ra­niem wyma­gań też jest pro­blem, bo ludzie kie­dyś wyma­ga­li” szyb­szych koni a nie samochodów:)

  2. Jaroslaw Zelinski 5 marca 2014 at 13:15

    pro­blem koni” obser­wu­je sta­le, jeże­li ktoś wyma­ga konia” to zna­czy, że kom­plet­nie nie rozu­mie poję­cia ana­li­za wyma­gań”. Poprawna spe­cy­fi­ka­cja wyma­gań” będzie raczej zawie­ra­ła zapis listo­nosz powi­nien w moż­li­wie naj­krót­szym cza­sie dotrzeć do adre­sa­ta prze­sył­ki” i rolą ana­li­ty­ką jest dotar­cie do tego” zapi­su. Klient wyma­ga­ją­cy” i otrzy­mu­ją­cy konia, spo­koj­nie może powie­dzieć: dosta­łem dokład­nie to cze­go chcia­łem ale nie to cze­go potrze­bu­ję”… Dobra ana­li­za nie da konia” jako wyni­ku… konia w spe­cy­fi­ka­cji zapi­sze ana­li­tyk dyk­ta­fon” a nie kom­pe­tent­ny analityk. 

  3. Jaroslaw Zelinski 5 marca 2014 at 17:17

    Zapraszam tak­że 18 Marca na kon­fe­ren­cję Wymagania, na któ­rej mam refe­rat na ten temat.

  4. jacek2v 5 marca 2014 at 22:02

    Zgadzam się świet­nie Pan to zauwa­żył, że OOA, OOD i OOP to są cał­ko­wi­cie odręb­ne dzie­dzi­ny. Naście lat temu spę­dzi­łem spo­ro cza­su na pró­bie skon­stru­owa­nia pro­ce­su pro­gra­mo­wa­nia OOA->OOD->OOP i pole­głem. A pole­głem ponie­waż, tak jak Pan napi­sał logi­ka biz­ne­so­wa to 3 – 5% cało­ści kodu. Teraz uwa­żam, że języ­ki stric­te obiek­to­we to nie­po­trzeb­ny nad­miar kodu i cza­su – dobre uza­sad­nie­nie w języ­ku Python: http://​www​.youtu​be​.com/​w​a​t​c​h​?​v​=​o​9​p​E​z​g​H​o​rH0

    • Jaroslaw Zelinski 5 marca 2014 at 23:01

      Można powie­dzieć, że MDA (mode­le CIM, PIM i PSM) to wła­snie pro­ces OOA,OOD, OOP, ale praw­do­po­dob­nie nie ma potzre­by by cały kod był pisa­ny obiek­to­wo»…

    • Piotr 7 marca 2014 at 15:03

      Widzę, że Python poja­wił się w roz­wa­ża­niach. Zlecając (nie­wie­le) zadań na pisa­nie dedy­ko­wa­ne­go softu sta­ra­my się uni­kać «wiel­kich tech­no­lo­gi» (.net, java) na korzyść «lżej­szych» typu wła­śnie Python czy Ruby. 

      Jak w Państwa prak­ty­ce zawo­do­wej koń­czy się imple­men­ta­cja? Najczęściej w wyżej wymie­nio­nych «cięż­kich» śro­do­wi­skach czy tra­fia­ją się wyko­naw­cy w języ­kach bar­dziej przy­ja­znych dla zarów­no deve­lo­pe­rów (mniej pisa­nia) jak i klien­ta (poten­cjal­nie szyb­ciej moż­na spo­dzie­wać się efektu)?

      Przyznam, że nasza prak­ty­ka mimo, że celu­je w wyżej wymie­nio­ne nowo­cze­sne «lek­kie» języ­ki, to koń­czy na php 😉 z powo­du bra­ku wyko­naw­ców. Projektów nie było dużo i były małe.
      P.

    • Jaroslaw Zelinski 7 marca 2014 at 22:45

      Z moje­go doświad­cze­nia wyni­ka, że sto­so­wa­nie nazwa­nych tu cięż­kich” tech­no­lo­gii, zale­ży od kla­sy zada­nia i wyma­gań, ta impli­ku­je sto­so­wa­nie nie tyle dane­go języ­ka co fra­me­wor­ka, czy­li takie­go zesta­wu biblio­tek, któ­ry pozwa­la jak naj­mniej pisać od zera”.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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