Wzorce projektowe Książki

Wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Analiza biz­ne­so­wa i projektowanie

Wstęp

W arty­ku­le o apli­ka­cjach webo­wych, ponad rok temu, pisałem:

Generalnie klu­czo­wą cechą micro-ser­wi­­sów, czy­nią­cą z nich tak zwa­ną zwin­ną archi­tek­tu­rę, jest cał­ko­wi­ta wza­jem­na nie­za­leż­ność imple­men­ta­cji poszcze­gól­nych usług apli­ka­cyj­nych. (źr.: Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych).

Przy innej oka­zji pisa­łem o wzorcach:

Wzorce pro­jek­to­we to bar­dzo waż­na część ??zawo­du? ana­li­ty­ka i archi­tek­ta opro­gra­mo­wa­nia. […] Generalnie wzor­ce są to ska­ta­lo­go­wa­ne stan­dar­dy i dobre prak­ty­ki . (Obiektowe wzor­ce projektowe ) 

Szkolenia dla ana­li­ty­ków poprze­dzam ankie­ta­mi przed szko­le­nio­wy­mi, jak do tej pory żad­na nie zawie­ra­ła pytań o wzor­ce pro­jek­to­we: ani tego że są uży­wa­ne ani tego, że są celem szko­le­nia, nie­mal­że każ­dy dekla­ru­je albo, że uży­wa UML lub, że chce zacząć uży­wać UML, nawet gdy są to pro­gra­mi­ści. Zauważyłem, że wzor­ce pro­jek­to­we w świa­do­mo­ści ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia (OOAD) nie ist­nie­ją”. Wśród pro­gra­mi­stów, jeże­li jest spo­ty­ka­na, to wie­dza o wzor­cach przy­dat­nych w two­rze­niu biblio­tek i narzę­dzi, czę­sto też powie­la­ne są wyuczo­ne sta­re i złe prak­ty­ki pro­gra­mi­stycz­ne rodem z lat 60-tych (np. prak­ty­ki SmallTalk, patrz dalej). 

Z dru­giej stro­ny od wie­lu lat zna­ne są tech­ni­ki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), któ­re w róż­nych for­mach, ale jed­nak wska­zu­ją, że naj­sku­tecz­niej­sza for­ma wyra­ża­nia wyma­gań wobec roz­wią­za­nia to pro­jekt archi­tek­tu­ry i logi­ki dzie­dzi­no­wej (model) dzia­ła­nia apli­ka­cji . O pro­jek­to­wa­niu poprze­dza­ją­cym imple­men­ta­cję pisze sie od dość daw­na, meto­dy obiek­to­we i dobre prak­ty­ki zna­ne są od lat .

Autorzy BABoK prak­tycz­nie od począt­ku ist­nie­nia tego wydaw­nic­twa, zwra­ca­ją uwa­gę na tak zwa­ną bia­łą skrzyn­kę”, czy­li wyma­ga­nia wyra­żo­ne w posta­ci wewnętrz­nej struk­tu­ry pro­duk­tu, wska­zu­jąc, że to znacz­nie sku­tecz­niej­sza meto­da defi­nio­wa­nia wyma­gań wobec roz­wią­za­nia, niż tak zwa­na czar­na skrzyn­ka”, czy­li tra­dy­cyj­ne, i jed­nak mniej sku­tecz­ne, wyma­ga­nia wyra­żo­ne tyl­ko jako cechy funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Pamiętajmy, że adre­sa­tem wyma­gań jest zawsze dostaw­ca produktu!

Czytaj dalej… Wzorce pro­jek­to­we w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu”

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…

Ach ten wstrętny, wścibski analityk

Znowu o tym, tak: o ana­li­zie, pro­jek­to­wa­niu i … ryzy­ku. Czy ana­li­za jest koniecz­na? Nie! To cze­mu słu­ży? By praw­do­po­do­bień­stwo tego, że uda się stwo­rzyć i wdro­żyć wła­ści­we opro­gra­mo­wa­nie było jak naj­więk­sze. Ale o co cho­dzi? Ano nie zawsze jest tak, że to praw­do­po­do­bień­stwo jest wystar­cza­ją­co duże! Ale po kolei.

Wprowadzenie

Obecnie na ryn­ku coraz bar­dziej domi­nu­ją tak zwa­ne obiek­to­we meto­dy ana­li­zy, pro­jek­to­wa­nia i pro­gra­mo­wa­nia. W czym pro­blem? Jedyną nama­cal­ną rze­czą jest kod i od pro­gra­mo­wa­nia (kodo­wa­nia) nie ma uciecz­ki: kod musi powstać by powsta­ło opro­gra­mo­wa­nie. Pozostaje ana­li­za i pro­jek­to­wa­nie – to moż­na pomi­nąć, moż­na od razu kodo­wać nicze­go nie ana­li­zu­jąc ani nie projektując.

Myślenie zama­wia­ją­ce­go: Te dwa eta­py, ana­li­za i pro­jek­to­wa­nie, to dodat­ko­wy koszt: może da się go uniknąć.

Myślenie pro­gra­mi­sty: Istniejący pro­jekt to wią­za­nie mi rąk, mojej kre­atyw­no­ści i roz­wo­ju: może uda się od razu zacząć kodować.

Nie raz pro­gra­mi­sta, w sumie tak­że wyko­naw­ca, doda­je sobie powyż­sze myśle­nie klien­ta: unik­nę kosz­tu ana­li­zy i projektowania.

Obaj mają ten sam cel! Pominąć ana­li­zę i projektowanie! 

A teraz po kolei i od koń­ca. Posłużymy się defi­ni­cja­mi a potem je jakoś razem pokle­imy. Mimo, że pod­cho­dzę z dużą rezer­wą do WIKI, posłu­żę się tymi stro­na­mi, gdyż są w więk­szo­ści reda­go­wa­ne przez ludzi zwią­za­nych z infor­ma­ty­ką, nie raz wła­śnie przez pro­gra­mi­stów programistów.

Programowanie obiektowe

Na począ­tek definicja:

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 frag­men­tów. (źr. WIKI)

Jak widać, mamy nowe narzę­dzie dla pro­gra­mi­stów, kolej­na edy­cja struk­tu­ra­li­za­cji kodu. cza­sem spo­ty­kam się u pro­gra­mi­stów z defi­ni­cją: pro­gra­mo­wa­nie obiek­to­we to ukła­da­nie kodu w pod­pro­gra­my łączą­ce dane i ope­ra­cje na nich. Tak więc tyl­ko tech­no­lo­gia. Drugi aka­pit tyl­ko to pod­kre­śla: tu tyl­ko technologia.

Powstaje opro­gra­mo­wa­nie.

Projektowanie obiektowe

I tu problem:

Przepraszamy, ale nie ma jesz­cze arty­ku­łu ?Projektowanie obiek­to­we? w Wikipedii. (dziś jest 24 Maj 2011, zno­wu spraw­dzam i nadal nie ma a jest 07 luty 2019).

Nie ma takiej defi­ni­cji w pol­skim WIKI. Czyżby nasi” nie projektowali?

Object-orien­ted design is the pro­cess of plan­ning a sys­tem of inte­rac­ting objects for the pur­po­se of solving a softwa­re pro­blem. It is one appro­ach to softwa­re design. (źr, http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​O​b​j​e​c​t​-​o​r​i​e​n​t​e​d​_​d​e​s​ign)

Uff, jed­nak pro­jek­tu­ją. Tak więc pro­jek­to­wa­nie obiek­to­we to zorien­to­wa­ny obiek­to­wo (para­dyg­mat obiek­to­wy) pro­ces roz­wią­zy­wa­nia pro­ble­mu poprzez pro­jek­to­wa­nie opro­gra­mo­wa­nia jako sys­te­mu komu­ni­ku­ją­cych się obiek­tów. Tak wiec moż­na przed roz­po­czę­ciem kodo­wa­nia, zapla­no­wać to co sta­nie zako­do­wa­ne. Gdzie indziej tak robią.

Powstaje pro­jekt opro­gra­mo­wa­nia (prze­my­śla­ny!).

[nie­ste­ty, wbrew temu co piszą pro­gra­mi­ści, para­dyg­mat obiek­to­wy to nie łącze­nie danych i funk­cji w obiek­ty, a budo­wa­nie sys­te­mu jako zesta­wu współ­pra­cu­ją­cych obiek­tów reagu­ją­cych w okre­ślo­ny spo­sób na okre­ślo­ne bodź­ce, obiek­ty są defi­nio­wa­ne wła­ści­wo­ścia­mi jaki­mi są ich atry­bu­ty i ope­ra­cje, cechu­ją się cał­ko­wi­tą her­me­ty­za­cją, czy­ni nie ujaw­nia­ją swo­ich wła­ści­wo­ści na zewnątrz.]

Analiza obiektowa

Kolejne podej­ście do Wikipedii:

Przepraszamy, ale nie ma jesz­cze arty­ku­łu ?Analiza obiek­to­wa? w Wikipedii. (dziś jest 24 Maj 2011, spraw­dzam 07 luty 2019, nadal nie ma)

Mam pecha, nasi nie ana­li­zu­ją. Znowu spo­glą­da­my na stro­ny anglo­sa­skich WIKI:

Object-orien­ted ana­ly­sis (OOA) looks at the pro­blem doma­in, with the aim of pro­du­cing a con­cep­tu­al model of the infor­ma­tion that exi­sts in the area being ana­ly­zed. Analysis models do not con­si­der any imple­men­ta­tion con­stra­ints that might exist, such as con­cur­ren­cy, distri­bu­tion, per­si­sten­ce, or how the sys­tem is to be built. Implementation con­stra­ints are dealt during object-orien­ted design (OOD). Analysis is done befo­re the Design. (źr. http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​O​b​j​e​c​t​-​o​r​i​e​n​t​e​d​_​a​n​a​l​y​s​i​s​_​a​n​d​_​d​e​s​ign)

W dużym skró­cie: ana­li­za obiek­to­wa (ana­li­za zorien­to­wa­na obiek­to­wo) to opra­co­wa­nie mode­lu poję­cio­we­go infor­ma­cji, opi­su­ją­ce­go bada­ną dome­nę (czy­li ana­li­zo­wa­ny obszar dzie­dzi­no­wy, np. kon­kret­na orga­ni­za­cja, fir­ma nasze­go klien­ta). Kolejny etap to pro­jek­to­wa­nie obiek­to­we. Model ana­li­tycz­ny nie powi­nien zawie­rać ogra­ni­czeń tech­no­lo­gicz­nych (imple­men­ta­cyj­nych), te ogra­ni­cze­nia powin­ny być bra­ne pod uwa­gę dopie­ro na eta­pie pro­jek­to­wa­nia (to pra­ca pro­gra­mi­stów). I na koniec tra­ge­dia: ana­li­za powin­na być wyko­na­na przed roz­po­czę­ciem projektowania!

Powstaje obiek­to­wy model ele­men­tów orga­ni­za­cji zama­wia­ją­ce­go (pole­cam arty­kuł o Domain Driven Design).

Druga strona barykady: Analiza procesowa

Tradycyjnie idzie­my do WIKI:

Przepraszamy, ale nie ma jesz­cze arty­ku­łu ?Analiza pro­ce­so­wa? w Wikipedii. (24 Maj 2011)

No cóż, szu­ka­my dalej:

Process ana­ly­sis pre­sents a chro­no­lo­gi­cal sequ­en­ce of steps that expla­in how some­thing is done, how some­thing hap­pens, or how readers can do some­thing. (źr. http://​www​.tcc​.edu/​s​t​u​d​e​n​t​s​/​r​e​s​o​u​r​c​e​s​/​w​r​i​t​c​e​n​t​/​h​a​n​d​o​u​t​s​/​w​r​i​t​i​n​g​/​p​r​o​c​e​s​s​.​htm).

Coś mamy: ana­li­za pro­ce­so­wa pre­zen­tu­je w posta­ci chro­no­lo­gicz­nej sekwen­cji kro­ków, to jak coś powsta­je, co się wyda­rza lub jak moż­na coś zro­bić. Piękna defi­ni­cja. Ta pre­zen­ta­cja to, w kon­tek­ście biz­ne­so­wym, model (mapa) pro­ce­sów biznesowych.

Mamy wiec upo­rząd­ko­wa­ną wie­dzę o fir­mie (orga­ni­za­cji) zama­wia­ją­ce­go opro­gra­mo­wa­nie. Tu tak­że powsta­je opis tego po co i gdzie tego opro­gra­mo­wa­nia chce­my uży­wać: model procesowy.

Tak zwane niedopasowanie oporu

Tak jest nazy­wa­na w lite­ra­tu­rze róż­ni­ca pomię­dzy para­dyg­ma­tem pro­ce­so­wym a obiek­to­wym. Paradygmat pro­ce­so­wy ope­ru­je taki­mi poję­cia­mi jak: pro­ces, wej­ście pro­ce­su, wyj­ście pro­ce­su, zda­rze­nie, wyko­naw­ca pro­ce­su (zaso­by), czyn­ność (lub ich sekwen­cja). Paradygmat obiek­to­wy to wspo­mnia­ne obiek­ty czy­li struk­tu­ry łączą­ce dane i meto­dy ich prze­twa­rza­nia. W czym pro­blem? W przej­ściu z mode­lu pro­ce­so­we­go na obiek­to­wy. Czy to łatwe? Nie. Jak to zro­bić? Hm… usiąść i popra­co­wać nad tym.

Należy prze­pro­wa­dzić ana­li­zę obiek­to­wą i wyko­nać model obiek­to­wy. Czego? Kodu? Nie! Organizacji zamawiającego!

W latach 60-tych (tak!) powsta­ły meto­dy obiek­to­we ana­li­zy i pro­jek­to­wa­nia jako pomysł na mode­lo­wa­nie świa­ta” tak jak jest postrze­ga­ny: w posta­ci obiek­tów mają­cych jakąś wie­dzę i jakieś umie­jęt­no­ści. To ana­li­za obiek­to­wa (sama w sobie nie ma ona nic wspól­ne­go z programowaniem!).

Skoro wie­le pro­ble­mów pro­gra­mi­stycz­nych doty­czy świa­ta rze­czy­wi­ste­go, powstał pomysł stwo­rze­nia języ­ka (ów) pro­gra­mo­wa­nia pasu­ją­ce­go” do pro­duk­tu ana­li­zy obiek­to­wej: mode­lu obiek­to­we­go: powstał obiek­to­wy język pro­gra­mo­wa­nia Small Talk.

Dzisiaj mamy sytu­ację, w któ­rej pro­gra­mi­ści uży­wa­ją obiek­to­wych narzę­dzi pro­gra­mi­stycz­nych i nie­ste­ty postrze­ga­ją je tyl­ko jako nowe meto­dy łącze­nia funk­cji i danych.

A teraz to wszystko narysuję

Zebrałem wszyst­ko powyż­szej i mamy:

Paradygmat obiektowy i procesowy, proces analizy
Paradygmat obiek­to­wy i pro­ce­so­wy, pro­ces analizy

U góry fir­ma (orga­ni­za­cja klien­ta), by zro­zu­mieć ją, pro­wa­dzi­my ana­li­zę pro­ce­so­wą. To ana­li­za ukie­run­ko­wa­na na zarzą­dza­nie czy­li kto, co i po robi. Jak odkry­je­my, że coś war­to uspraw­nić, robi­my to.

Wiedząc, że meto­dy obiek­to­we są sku­tecz­niej­sze w pro­jek­tach biz­ne­so­wych inży­nie­rii opro­gra­mo­wa­nia (no coś nale­ży uznać), opra­co­wu­je­my (prze­cho­dzi­my na) model obiek­to­wy tej organizacji.

Innymi sło­wy, model pro­ce­sów słu­ży nam do zro­zu­mie­nia tego jak dzia­ła orga­ni­za­cja, bo war­tość doda­na powsta­je jako pro­dukt pro­ce­su (biz­ne­so­we­go). Opracowanie narzę­dzia, jakim jest opro­gra­mo­wa­nie, wyma­ga opra­co­wa­nia okre­ślo­nej kon­struk­cji sys­te­mu, a ten jako taki jest obiektowy.

Jeżeli model pro­ce­so­wy orga­ni­za­cji poka­zu­je jak się ona zacho­wu­je, to model obiek­to­wy poka­zu­je czym ona jest.

W pro­ce­sie ana­li­zy obiek­to­wej powsta­je model obiek­to­wy bada­nej orga­ni­za­cji. Tu ma miej­sce trans­for­ma­cja para­dyg­ma­tu pro­ce­so­we­go na obiek­to­wy. To naj­trud­niej­sza część całe­go pro­jek­tu, tu powsta­je naj­więk­sze ryzy­ko, zła ana­li­za obiek­to­wa skut­ku­je jesz­cze gor­szym opro­gra­mo­wa­niem. Z regu­ły model obiek­to­wy jest two­rzo­ny nie dla całej orga­ni­za­cji a dla jej czę­ści (opro­gra­mo­wa­nie to jedy­nie narzę­dzie wspie­ra­ją­ce ludzi a nie cała firma).

Mając obiek­to­wy model wybra­ne­go obsza­ru orga­ni­za­cji i cel pro­jek­tu (koniecz­nie) two­rzy­my pro­jekt przy­szłe­go opro­gra­mo­wa­nia. Tu mała uwa­ga: opro­gra­mo­wa­nie to dwa aspek­ty: jego funk­cjo­nal­ność oraz tech­nicz­ne para­me­try takie jak bez­pie­czeń­stwo, wydaj­ność i dostęp­ność. Funkcjonalność wyni­ka wprost z pro­duk­tu ana­li­zy obiek­to­wej, para­me­try tech­nicz­ne to poza biz­ne­so­we ele­men­ty, któ­rych pro­jek­tan­ta­mi są inży­nie­ro­wie i programiści.

Mając pro­jekt, sia­da­my w koń­cu i kodu­je­my. Powstało opro­gra­mo­wa­nie, któ­re wspie­ra w usta­lo­nym obsza­rze orga­ni­za­cję zama­wia­ją­ce­go: opro­gra­mo­wa­nie to narzę­dzie. Na każ­dym eta­pie powyż­sze­go pro­ce­su powin­no się doko­nać oce­ny jako­ści pro­duk­tu. Należy spraw­dzić (upew­nić się), że mode­le są praw­dzi­we, i że ich imple­men­ta­cja dopro­wa­dzi do powsta­nia ocze­ki­wa­ne­go opro­gra­mo­wa­nia. Jak? Testując je. Jak? Opisałem to już 🙂 w poprzed­nich artykułach.

Diagram powyż­szy wyróż­nia dwa obsza­ry: żół­ty, któ­ry wska­zu­je na kom­pe­ten­cje Analityka Biznesowego oraz fio­le­to­wy, wska­zu­ją­cy na obszar kom­pe­ten­cyj­ny Dewelopera (wyko­naw­cy, dostaw­cy oprogramowania). 

Opracowanie mode­lu biz­ne­so­we­go (pro­ce­so­wy i obiek­to­wy) wyma­ga bar­dzo dużej wie­dzy z zakre­su zarzą­dza­nia i mar­ke­tin­gu. Wykonanie imple­men­ta­cji wyma­ga oczy­wi­ście dużej wie­dzy i doświad­cze­nia w zakre­sie inży­nie­rii opro­gra­mo­wa­nia. Są to nie­ste­ty dwa zupeł­nie odręb­ne obsza­ry wie­dzy i połą­cze­nie ich w jed­nej oso­bie jest nie­zwy­kle rzad­kie. Ale nawet jeśli znaj­dzie­my taka oso­bę, eta­py te powin­ny zostać roz­dzie­lo­ne z inne­go powo­du: wyko­naw­ca w biz­ne­sie nie powi­nien sam sobie sta­wiać wyma­gań! Rodzi to ogrom­ne ryzy­ko nad­użyć. (wię­cej o podzia­le na role w pro­jek­cie)

Komunikacja: powszech­nie uzna­ną meto­dą komu­ni­ka­cji w takich pro­jek­tach jest wła­śnie two­rze­nie mode­li, sfor­ma­li­zo­wa­nych dia­gra­mów obra­zu­ją­cych pro­duk­ty poszcze­gól­nych eta­pów ana­liz i pro­jek­to­wa­nia. O nota­cjach (stan­dar­dach two­rze­nia dia­gra­mów) w innych postach (są to głow­nie BPMN i UML). Warto tu tyl­ko przy­to­czyć sta­re porze­ka­dło: rysu­nek wart tysią­ca słów. Kod jest zaś na samym koń­cu osta­tecz­nym produktem.

Agile

Najpierw przy­to­czę tak zwa­ny Manifest Agile:

Manifest Zwinnego Tworzenia Oprogramowania

Wytwarzając opro­gra­mo­wa­nie i poma­ga­jąc innym w tym zakre­sie, odkry­wa­my lep­sze spo­so­by wyko­ny­wa­nia tej pra­cy. W wyni­ku tych doświad­czeń przedkładamy:

Ludzie i inte­rak­cje ponad pro­ce­sy i narzędzia.

Działające opro­gra­mo­wa­nie ponad obszer­ną dokumentację.

Współpraca z klien­tem ponad for­mal­ne ustalenia.

Reagowanie na zmia­ny ponad podą­ża­nie za planem.

Doceniamy to, co wymie­nio­no po pra­wej stronie,

jed­nak bar­dziej ceni­my to, co po lewej.

Cóż, zastą­pie­nie pro­ce­su ana­li­zy i pro­jek­to­wa­nia wer­bal­ną komu­ni­ka­cją to dro­ga na skró­ty: czer­wo­na strzał­ka. Czy to zła dro­ga? Droga na skró­ty to wspo­mnia­ne na począt­ku ryzy­ko, ogrom­ne bo sta­ty­sty­ki wska­zu­ją sta­le, że ok. 70 – 80% pro­jek­tów pro­gra­mi­stycz­nych ma poważ­ne kło­po­ty. Statystyki te są takie same od lat. Dlaczego? Skoro od razu kodu­je­my to pomi­nę­li­śmy pośred­nie spraw­dze­nia i weryfikacje.

Od lat zna­ny jest powyż­szy pro­ces i mimo to zawsze jest te 80% klien­tów i ich dostaw­ców, któ­rzy doga­du­ją się, że ana­li­za i pro­jek­to­wa­nia żad­ne­mu z nich nie słu­ży… tak jak to napi­sa­no na początku.

Po co to napi­sa­łem? By każ­dy z Państwa sam, świa­do­mie, oce­niał ryzy­ko swo­ich pro­jek­tów. Rezygnacja z ana­li­zy i pro­jek­to­wa­nia to pod­ję­cie pew­ne­go ryzy­ka. Niestety rezy­gna­cja z ana­li­zy i pro­jek­to­wa­nia ze stro­ny dewe­lo­pe­ra to cza­sem dodat­ko­wo sku­tek przy­zna­nia, że ana­li­za i pro­jek­to­wa­nie leży poza kom­pe­ten­cja­mi pro­gra­mi­stów (Ci obiek­to­wo kodu­ją) wiec wybie­ra­na jest dro­ga na skróty.

A Agile? Mam dziw­ne wra­że­nie, że to z jed­nej stro­ny łapa­nie brzy­twy przez toną­ce­go, ratu­nek, głos pro­gra­mi­stów pozba­wio­nych ana­li­ty­ka i pro­jek­tan­ta, a z dru­giej meto­dy­ka pozby­cia się roli nie pasu­ją­cej od para­dyg­ma­tu” pro­gra­mi­sty, któ­ry bada i roz­wi­ja się poprzez sta­łe ćwi­cze­nie się w swo­im fachu”, szko­da, że nie raz na cudzej skórze.

Pominięcie jed­nak ana­li­zy i pro­jek­to­wa­nia pro­wa­dzi do pro­gra­mów gdzie para­dyg­mat obiek­to­wy, koń­czy się na tym, że owe struk­tu­ry łączą­ce dane i ope­ra­cje na nich” powsta­ją jako sztucz­ne byty, nie mają­ce nic wspól­ne­go z rze­czy­wi­sto­ścią, a co naj­wy­żej z wygo­dą kodu­ją­ce­go pro­gra­mi­sty. Tak wła­śnie powsta­ją bar­dzo czę­sto bar­dzo złe pro­gra­my: nie­roz­wo­jo­we, nie­ży­cio­we, nie­na­tu­ral­ne w pracy.

I nie cho­dzi o to by koniecz­nie zatrud­niać ana­li­ty­ka, cho­dzi o to by rze­tel­nie wyko­nać ana­li­zę i pro­jekt zanim roz­pocz­nie­my kodowanie.