Analysis Patterns: Reusable Object Models

Jedna z cie­kaw­szych i popu­lar­niej­szych ksią­żek (ja mam dodruk z 2010 roku). Bardzo czę­sto spo­ty­kam się w sie­ci z powo­ły­wa­niem się na tę książ­kę w kwe­stii wzor­ców ana­li­tycz­nych”. Jednak po pierw­sze nie nale­ży zapo­mi­nać, że napi­sa­na zosta­ła w 1996 roku (od tam­tej pory mamy jed­nak pewien postęp, do tego książ­ka jest ilu­stro­wa­na sym­bo­la­mi opar­ty­mi na nota­cji ERD a nie UML), a po dru­gie, o czym wie­lu zapo­mi­na, Fowler pre­zen­tu­je w niej mode­le kon­cep­cyj­ne a nie struk­tu­ral­ne (wytłusz­cze­nie moje):

Analysis Patterns pro­vi­des a cata­lo­gue of pat­terns that have emer­ged in a wide ran­ge of doma­ins inc­lu­ding tra­ding, measu­re­ment, acco­un­ting and orga­ni­za­tio­nal rela­tion­ships. Recognizing that con­cep­tu­al pat­terns can­not exist in iso­la­tion, the author also pre­sents a series of sup­port pat­terns” that discuss how to turn con­cep­tu­al models into softwa­re that in turn fits into an archi­tec­tu­re for a lar­ge infor­ma­tion sys­tem. Included in each pat­tern is the reaso­ning behind the­ir design, rules for when they sho­uld and sho­uld not be used, and tips for imple­men­ta­tion. (Źródło: Analysis Patterns: Reusable Object Models: Martin Fowler: 9780201895421: Amazon.[1]com: Books)

Generalnie książ­kę pole­cam oso­bom doświad­czo­nym, czy­ta­jąc ją, nie wol­no zapo­mi­nać o tym, że Fowler bazu­je w nich na mode­lach poję­cio­wych. Książka nie zawie­ra mode­li dzie­dzi­ny (struk­tu­ra, mecha­nizm dzia­ła­nia apli­ka­cji). Modele poję­cio­we (słow­nik pojęć i związ­ków pomię­dzy nimi) słu­żą do zro­zu­mie­nia ana­li­zo­wa­ne­go obsza­ru wie­dzy, nie są (jak to ma miej­sce w dia­gra­mach ERD) ani mode­lem dzie­dzi­ny a nie struk­tu­rą kodu. Nie będę w tej recen­zji tego opi­sy­wał, opi­sa­łem to tu (cytat to pyta­nie pew­ne­go forumowicza):

Czy może­cie mi wytłu­ma­czyć co ozna­cza­ją poję­cia ?model dzie­dzi­ny? oraz ?model kon­cep­tu­al­ny?? Czy model dzie­dzi­ny zawie­ra tak­że dia­gram kon­cep­tu­al­ny klas? (Źródło: Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu | Jarosław Żeliński IT-Consulting)

Książkę pole­cam, duża daw­ka obiek­to­wej wie­dzy i przy­kła­dów, ale bierz­cie popraw­kę na powyż­sze. Fragmenty na Google books: czy­taj.[2]

Analysis Patterns: Reusable Object Models Hardcover
October 19, 1996, Martin Fowler

Footnotes
[1]M. Fowler, Analysis Patterns. Reusable Object Models, Addisson_Wesley 2010.
[2]J. Zelinski, Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu [na:] ?Jarosław Żeliński IT-Consulting?, https://it-consulting.pl//2013/02/17/czym-jest-a-czym-nie-jest-tak-zwany-model-dziedziny-systemu/, udo­stęp­nio­no 16 lipiec 2017.

Bibliografia

Fowler, M., Analysis Patterns. Reusable Object Models, Addisson_Wesley 2010.
Zelinski, J., Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu [na:] ?Jarosław Żeliński IT-Consulting?, https://it-consulting.pl//2013/02/17/czym-jest-a-czym-nie-jest-tak-zwany-model-dziedziny-systemu/, udo­stęp­nio­no 16 lipiec 2017.

Bo banki od wszystkiego są do niczego czyli złe modele dziedziny

Ten arty­kuł to odpo­wiedź na pew­ną dys­ku­sję roz­po­czę­tą od tezy, że na wie­lu stro­nach WWW (w nie­któ­rych książ­kach tak­że) mamy nie­ste­ty do czy­nie­nia z pseudowiedzą…

W arty­ku­le Cholerny dia­gram klas pisa­łem o mode­lu dzie­dzi­ny. Modelowana jest dia­gra­mem klas (nota­cja to narzę­dzie), zawie­ra logi­kę biz­ne­so­wą. W kon­wen­cji DDD ([[Domain Driven Design]]), model ten jest szkie­le­tem kom­po­nen­tu Model we wzor­cu MVC.

Tym razem napi­sze kil­ka słów o poje­dyn­czych kla­sach w mode­lu dzie­dzi­ny. Błąd numer jeden: kla­sy w mode­lu dzie­dzi­ny odwzo­ro­wu­ją poję­cia mode­lu poję­cio­we­go! Nie, model poję­cio­wy (słow­nik pojęć ich wza­jem­nych związ­ków) to nie model dzie­dzi­ny sys­te­mu. Tak się pro­jek­to­wa­ło encje w mode­lach rela­cyj­nych baz danych, prze­no­sze­nie tych doświad­czeń na grunt obiek­to­wy to powszech­na, cięż­ka cho­ro­ba, to rak toczą­cy te pro­jek­ty. Owszem, jeże­li ktoś zade­kla­ru­je, że two­rzy sys­tem meto­da­mi struk­tu­ral­ny­mi już może prze­stać czy­tać, ale niech uży­wa nota­cji i dia­gra­my ERD a nie UML i nie nazy­wa tego meto­da­mi obiek­to­wy­mi ana­li­zy i projektowania.

Niestety przy­kła­dy dia­gra­mów klas” na stro­nach wie­lu firm dorad­czych, szko­le­nio­wych i stro­nach wie­lu kon­sul­tan­tów”, «tre­ne­rów” itp. poka­zu­ją, że duch ana­li­zy struk­tu­ral­nej nadal żyje oraz, że myle­nie nota­cji UML z meto­da­mi obiek­to­wy­mi ana­li­zy i pro­jek­to­wa­nia jest powszech­ne. Przypomnę tu tyl­ko, że dia­gram klas to nota­cja, któ­rej moż­na użyć do wie­lu rze­czy, w tym do mode­lo­wa­nia pojęć, struk­tu­ry kodu opro­gra­mo­wa­nia obiek­to­we­go (zgod­ne­go z obiek­to­wym para­dyg­ma­tem, a nie tyl­ko korzy­sta­ją­ce­go z pole­ce­nia class w uży­tym języ­ku pro­gra­mo­wa­nia), sta­tycz­nych mode­li orga­ni­za­cji i wie­lu innych. Tak więc zda­nie pro­szę zro­bić dia­gram klas” nie zna­czy nic, to coś jak weź samo­chód o pojeź­dzij trosz­kę”, z trans­por­tem nie ma to nic wspólnego.

Jeżeli jed­nak uzna­my, że pro­wa­dzi­my ana­li­zę obiek­to­wą to zna­czy, że model rze­czy­wi­sto­ści (mode­lo­wa­nej) budu­je­my jako zespół współ­pra­cu­ją­cych obiek­tów reali­zu­ją­cych okre­ślo­ny cel”. Wtedy dia­gram klas to nie żad­ne dane, encje i inne nie­obiek­to­we pomy­sły (znam takich co mode­lu­ją klu­cze rela­cyj­ne w dia­gra­mach klas a to już jest tra­ge­dia nie­ste­ty, jest nawet wyda­na w Polsce książ­ka z taki­mi przy­kła­da­mi!). Projekt zaczy­na­my od klas i ich ope­ra­cji a nie od atrybutów!

Uwaga dodat­ko­wa. Sprawdzoną meto­dą ana­liz (w ogó­le) jest ana­li­za sys­te­mo­wa, jest to:

meto­da roz­wią­zy­wa­nia zło­żo­nych pro­ble­mów wyko­rzy­stu­ją­ca podej­ście sys­te­mo­we (holi­stycz­ne). Polega na trak­to­wa­niu ana­li­zo­wa­nej orga­ni­za­cji (zja­wi­ska) jako zło­żo­ne­go sys­te­mu, któ­re­go poszcze­gól­ne czę­ści pra­cu­ją” na powo­dze­nie cało­ści”. Obejmuje ona czte­ry zasad­ni­cze eta­py roz­wią­zy­wa­nia pro­ble­mu: (1) iden­ty­fi­ka­cja i sfor­mu­ło­wa­nie pro­ble­mu, (2) bada­nie (ana­li­zo­wa­nie) sytu­acji pro­ble­mo­wej (gro­ma­dze­nie infor­ma­cji, wyja­śnia­nie kwe­stii, ana­li­zo­wa­nie fak­tów itp., (3) ana­li­za pro­ble­mu (dekom­po­zy­cja zło­żo­ne­go pro­ble­mu na mniej­sze), (4) pro­jek­to­wa­nie roz­wią­za­nia (budo­wa mode­li, spe­cy­fi­ka­cje, symu­la­cja, warian­ty itp.).

Jak widać podo­bień­stwo para­dyg­ma­tu obiek­to­we­go i ana­li­zy sys­te­mo­wej jest bar­dzo duże, żeby nie powie­dzieć uderzające.

Tak więc ana­li­za i mode­lo­wa­nie (na eta­pie ana­li­zy) to roz­ło­że­nie ana­li­zo­wa­nej orga­ni­za­cji (ana­li­zo­wa­ne­go śro­do­wi­ska) na pro­ste obiek­ty, każ­dy o pro­stej odpo­wie­dzial­no­ści”. Wyłania się obraz mode­li skła­da­ją­cych się z tych czę­ści, któ­re pra­cu­ją na powo­dze­nie cało­ści”. Jakie powin­ny być owe czę­ści? Teraz pora na dwa cyta­ty z blo­gów pew­nych pro­gra­mi­stów (lubię dobrych pro­gra­mi­stów, bo przy­ta­ku­ją mi lub negu­ją a nie raz moc­no uczą poko­ry to co myślę czy­li nie błą­dzę w chmurach):

Single Responsibility Principle mówi, że kla­sa powin­na robić jed­ną rzecz, mieć jed­ną odpo­wie­dzial­ność. Jeśli ma jed­ną odpo­wie­dzial­ność to nie powin­na raczej grze­bać we wszyst­kich war­stwach. Wątpliwe jest aby kla­sa, któ­ra ma jed­ną odpo­wie­dzial­ność musia­ła się­gać do bazy danych i inter­fej­su użyt­kow­ni­ka i pli­ków i logi­ki biz­ne­so­wej i Bóg raczy wie­dzieć gdzie jesz­cze. (za using – papie­rek lak­mu­so­wy Twojej archi­tek­tu­ry | arek onli­ne | Arkadiusz Benedykt).

…naj­bar­dziej traf­ną meta­fo­rą obiek­tów pro­gra­mi­stycz­nych jest orga­nizm bio­lo­gicz­ny. Podobnie jak komór­ki, obiek­ty nie wie­dzą”, co dzie­je się wewnątrz innych obiek­tów, ale komu­ni­ku­ją się z nimi reali­zu­jąc bar­dziej zło­żo­ne cele. W prze­ci­wień­stwie do takie­go orga­ni­zmu pro­gram mono­li­tycz­ny przy­po­mi­na mecha­nizm zegar­ka, zawie­ra­ją­cy nie­prze­li­czal­ną (sic!) licz­bę try­bi­ków. Trybiki nie mają żad­nej inte­li­gen­cji i są bez­u­ży­tecz­ne poza mecha­ni­zmem, w któ­rym pra­cu­ją. Taki pro­jekt nie ma szans powo­dze­nia. Budując mecha­ni­zmy zega­ro­we, docho­dzisz w koń­cu do takiej zło­żo­no­ści, że całość prze­sta­je funk­cjo­no­wać. (Holistycznie o inży­nie­rii opro­gra­mo­wa­nia: Bo naj­waż­niej­sza jest odpo­wie­dzial­ność Synu…).

i nie­ste­ty to co widu­ję na wie­lu stro­nach WWW, w pro­jek­tach itp. (dru­ga wada czę­sto spo­ty­ka­nych mode­li dziedzinowych):

Dopisujemy kolej­ne meto­dy a tym­cza­sem kla­sa puch­nie. Przy osią­gnię­ciu masy kry­tycz­nej, wpro­wa­dze­nie jakiej­kol­wiek zmia­ny, nawet tej naj­mniej­szej powo­du­je, że spę­dza­my godzi­ny na debu­go­wa­niu kodu i spraw­dza­niu dla­cze­go nie zawsze dzia­ła tak jak byśmy tego chcie­li. (Single Responsibility Principle | arek onli­ne).

Swego cza­su na jed­nej z kon­fe­ren­cji o ana­li­zie wyma­gań, mówi­łem o potrze­bie zro­zu­mie­nia funk­cjo­no­wa­nia ana­li­zo­wa­nej orga­ni­za­cji (fir­my) o i tym jak to udokumentować:

…wszyst­ko to co nas ota­cza, samo w sobie jest natu­ral­nie pro­ste. Złożone są, nie poszcze­gól­ne rze­czy, a to, że jest ich wie­le i mają na sie­bie wza­jem­ny wpływ. Pamiętajmy, że jed­na z naj­trud­niej­szych gier na świe­cie ? sza­chy ? to tyl­ko kil­ka­na­ście figur i pro­ste regu­ły ich prze­miesz­cza­nia, sno­oker – naj­trud­niej­sza gra w bilar­da – to to tyl­ko pro­ste kule i kij. Nawet naj­więk­szą orga­ni­za­cję moż­na, w toku ana­li­zy, roz­ło­żyć na skoń­czo­ną licz­bę ról i reguł ich postę­po­wa­nia by zro­zu­mieć jej funk­cjo­no­wa­nie. (żr. Jarosław Żeliński, refe­rat na kon­fe­ren­cji o sys­te­mach ERP).

Analiza biz­ne­so­wa to etap opi­su (zro­zu­mie­nia) mode­lo­wa­nej orga­ni­za­cji (mode­le pro­ce­sów itp.). Potem, powsta­je model roz­wią­za­nia, któ­rym jest nie raz wła­śnie opro­gra­mo­wa­nie, jego logi­ka (patrz powyż­szy cytat) to obiek­to­wy model dzie­dzi­ny sys­te­mu”, a nie jakiś dia­gram klas nafa­sze­ro­wa­ny atry­bu­ta­mi i pozba­wio­ny ope­ra­cji bo jest dokład­nie odwrotnie:

zly modelAnemic Domain Model: This is one of tho­se anti-pat­terns tha­t’s been aro­und for quite a long time, yet seems to be having a par­ti­cu­lar spurt at the moment. I was chat­ting with Eric Evans on this, and we’ve both noti­ced they seem to be get­ting more popu­lar. As gre­at boosters of a pro­per Domain Model, this is not a good thing. (AnemicDomainModel).

Dla kon­tra­stu cytat z jed­nej ze stron WWW pew­nej fir­my szkoleniowej:

Zwróćmy uwa­gę, że na mode­lu dzie­dzi­ny nie umiesz­cza­my klas imple­men­tu­ją­cych logi­kę apli­ka­cji, jej inter­fejs użyt­kow­ni­ka czy war­stwę dostę­pu do danych. Nie war­to też na mode­lu dzie­dzi­ny umiesz­czać metod. (Diagramy klas – model dzie­dzi­ny i pro­jekt apli­ka­cji).

I tyle mam dzi­siaj do powie­dze­nia o nie­któ­rych kon­sul­tan­tach i wykła­dow­cach … (a tu trosz­kę praw­dy)

P.S.

Bardzo czę­sto spo­ty­kam się z tezą, że model dzie­dzi­ny powi­nien opra­co­wy­wać archi­tekt by doko­nać ewen­tu­al­nych opty­ma­li­za­cji jesz­cze przed imple­men­ta­cją. Stawianie takich tez ma w moich oczach dwa głów­ne źró­dła: dostaw­ca usłu­gi (deve­lopr) szu­ka oka­zji by pro­jekt nagiąć do swo­ich potrzeb, do posia­da­nych goto­wych kom­po­nen­tów nie speł­nia­ją­cych jed­nak wyma­gań. Innym powo­dem jest zwy­kła nie­wie­dza. O opty­ma­li­za­cji kil­ka pro­stych tez usta­mi pro­gra­mi­sty: 3 zasa­dy opty­ma­li­za­cji. Więc powtó­rzę: na eta­pie ana­li­zy i pro­jek­to­wa­nia nicze­go nie uprasz­cza­my ani nie opty­ma­li­zu­je­my bo nie wie­my czy w ogó­le zaist­nie­je taka potrze­ba, a opty­ma­li­za­cja ZAWSZE psu­je model.

Analiza wymagań – zrozumienie

Dzisiaj krót­ki arty­kuł o wyma­ga­niach dzie­dzi­no­wych. W jed­nym z poprzed­nich arty­ku­łów pisa­łem o wyma­ga­niach, że pro­blem tkwi w ich zro­zu­mie­niu i o tym, że przy­szły użyt­kow­nik nie powi­nien pisać jaki ma być ten pro­gram”, bo popy­cha pro­jekt w stro­nę cha­otycz­nych oczekiwań.

I tu jest sed­no: ana­li­za nie powin­na być tyl­ko pasmem wywia­dów, któ­re­go pro­duk­tem będę set­ki stron zapi­sów z ankiet i prze­pro­wa­dzo­nych roz­mów. Analiza, to duża pra­ca, któ­rej celem powin­no być zro­zu­mie­nie a nie tyl­ko opi­sa­nie. (Analiza wyma­gań na opro­gra­mo­wa­nie czy­li opi­sa­nie czy zro­zu­mie­nie).

Wymagania naj­czę­ściej dzie­li­my na funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Warto jed­nak upo­rząd­ko­wać pro­jekt i ukie­run­ko­wać ana­li­zę naj­pierw na wyma­ga­nia biz­ne­so­we a potem do już wymie­nio­nych dodać wyma­ga­nia dzie­dzi­no­we. Te ostat­nie są tak na praw­dę wydzie­le­niem z cha­osu ocze­ki­wań cze­goś co nazwę jak to jest robio­ne” ale nie w kon­tek­ście opro­gra­mo­wa­nia (pro­gra­mi­ści wie­dzą jak pro­gra­mo­wać), a w kon­tek­ście reguł biz­ne­so­wych i decy­zyj­nych (wie­dzy o tym jak się rze­czy dzieją).

Oprogramowania bez­po­śred­nio doty­czą tyl­ko wyma­ga­nia funk­cjo­nal­ne, poza-funk­cjo­nal­ne i dzie­dzi­no­we. Wymagania biz­ne­so­we to cele jakie ma przed sobą orga­ni­za­cja, dla któ­rej ma powstać (ma zostać jej dostar­czo­ne) opro­gra­mo­wa­nie. Zresztą, nie nale­ży o tym zapo­mi­nać, że może ist­nieć inne roz­wią­za­nie pro­ble­mu orga­ni­za­cji, niż oprogramowanie.

Oprogramowanie pro­jek­to­wa­ne meto­da­mi obiek­to­wy­mi wg. naj­lep­szych prak­tyk i wzor­ców ma nastę­pu­ją­ca strukturę:

Model systemu wymagania

Aktor to oczy­wi­ście jego użyt­kow­nik. Oprogramowanie, jako narzę­dzie pra­cy, świad­czy usłu­gi jego użyt­kow­ni­kom – akto­rom, jest ich narzę­dziem pra­cy. Oprogramowanie zawiera:

  1. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za jakość świad­czo­nych usług, to kla­sy reali­zu­ją­ce przy­pad­ki uży­cia tego oprogramowania,
  2. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za logi­kę biznesową,
  3. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za utrwa­la­nie infor­ma­cji (obiek­ty biznesowe).

Wymagania to warun­ki jakie ma speł­niać opro­gra­mo­wa­nie by było przy­dat­ne. Tak więc Analityk biz­ne­so­wy powi­nien zro­zu­mieć jak dzia­ła orga­ni­za­cja, zde­fi­nio­wać narzę­dzie jakie jej pomo­że, opi­sać wyma­ga­nia na to narzę­dzie. Jak? Powiem ina­czej, nie jest rolą pro­gra­mi­stów odkry­wa­nie” logi­ki biz­ne­so­wej, pro­gra­mi­sta odpo­wia­da za jej imple­men­ta­cję. Dlatego war­to pamię­tać o wyma­ga­niach dzie­dzi­no­wych… nie jest to nie­ste­ty miej­sce na szcze­gó­ło­wy ich opis, tu zapra­szam na szko­le­nie o wyma­ga­niach, któ­re pro­wa­dzę.

Praktyka nie­ste­ty poka­zu­je, że zapis ocze­ki­wań użyt­kow­ni­ka i prze­ka­za­nie ich pro­gra­mi­stom to dro­ga na manow­ce… Oczekiwania w rodza­ju roz­wi­ja­ne listy, mysz­ko­lo­gia”, łatwe w uży­ciu ekra­ny” i cała masa innych szcze­gó­łów nijak się ma do tego jak to opro­gra­mo­wa­nie ma dzia­łać. To tyl­ko cechy użyt­ko­we inter­fej­su użyt­kow­ni­ka, te jed­nak bez wewnętrz­nej logi­ki po pierw­sze o niczym nie mówią, a po dru­gie i tak są efek­tem goto­wych ele­men­tów z jakich budu­je się inter­fejs użyt­kow­ni­ka. Warto o ich wspo­mnieć by zama­wia­ją­cy miał ich świa­do­mość ale nie oszu­kuj­my się, opi­su­je­my tak tyl­ko to co zna­my już z innych apli­ka­cji a to w pew­nym sen­sie stan­dard (np. doty­ko­wy ekran smart­fo­na czy tabletu).

Zapisanie zaś, że sys­tem ma pozwa­lać na dobór pro­mo­cji dla klien­tów o róż­nych pozio­mach zaku­pów, po pierw­sze nic nie mówi, po dru­gie wyma­ga ana­li­zy o co cho­dzi” i są to wła­śnie wyma­ga­nia dzie­dzi­no­we­go. Wymaganiem funk­cjo­nal­nym będzie tu to: System pozwa­la na zarzą­dza­nie listą upu­stów. W języ­ku pol­skim i nie tyl­ko funk­cja to zada­nie, któ­re speł­nia lub ma speł­nić jakaś oso­ba lub rzecz. Innymi sło­wy wyma­ga­nie funk­cjo­nal­ne to to do cze­go ma słu­żyć opro­gra­mo­wa­nie a nie to jak ma to robić.

Przypomnę na zakoń­cze­nie: powyż­sze to tyl­ko pew­ne dobre prak­ty­ki 🙂 bazu­ją­ce na meto­dach obiek­to­wych (a w zasa­dzie takie głów­nie są teraz a w uży­ciu) i wzor­cach projektowych.

Bo najważniejsi Panie są Aktorzy…

Bardzo czę­sto spo­ty­kam się z pro­jek­ta­mi, w któ­rych użyt­kow­ni­cy narze­ka­ją na dostaw­cę opro­gra­mo­wa­nia, uwa­ża­ją że pro­gram nie cał­kiem speł­nia ich ocze­ki­wa­nia (wyma­ga­nia pod­pi­sa­li… ale to nie roz­wią­zu­je tego pro­ble­mu). Problem pole­ga na czę­sto spo­ty­ka­nym podej­ściu: ana­li­za wyma­gań tyl­ko w posta­ci wywia­dów i w kon­se­kwen­cji nie­peł­ne zro­zu­mie­nie spe­cy­fi­ki biz­ne­so­wej oraz fakt, że deve­lo­per ma skłon­no­ści do uprosz­czeń i nor­ma­li­za­cji”. Innym, moim zda­niem jesz­cze gor­szym podej­ściem, jest roz­po­czę­cie kodo­wa­nia jesz­cze w trak­cie trwa­nia wywia­dów i two­rze­nie opro­gra­mo­wa­nia meto­dą codzien­nych, lub co tygo­dnio­wych spo­tkań z użyt­kow­ni­kiem opi­su­ją­cym kolej­ne aspek­ty sys­te­mu. Zbyt póź­ne odkry­wa­nie (a nie raz nawet nie­do­strze­ga­nie tego), tego że pew­ne rze­czy są «tymi samy­mi rze­cza­mi” ale w innych kon­tek­stach, pro­wa­dzi do bar­dzo wie­lu pro­ble­mów z imple­men­ta­cją. Ale po kolei.

Wymaganie: system ma pozwalać na wystawianie faktur VAT

Wyobraźmy sobie pozor­nie pro­sty pro­blem: opro­gra­mo­wa­nie CRM zawie­ra­ją­ce mię­dzy inny­mi funk­cjo­nal­ność fak­tu­ro­wa­nia. Z regu­ły z wywia­dów (ana­li­za) dowie­my się, że w kil­ku miej­scach róż­ne oso­by wysta­wia­ją fak­tu­ry. Wzór fak­tu­ry będzie załącz­ni­kiem, z kil­ku tak zwa­nych user sto­ry” zosta­nie opra­co­wa­ny jeden (nor­ma­li­za­cja user sto­ry) przy­pa­dek uży­cia Wystawienie fak­tu­ry VAT”, jego imple­men­ta­cja z regu­ły jest kom­pi­la­cją tre­ści kil­ku wywia­dów (user sto­ry). Kilka róż­nych osób (role) dosta­nie pro­to­typ do oce­ny, każ­dy zgło­si inne zmia­ny i ocze­ki­wa­nia, powo­li powsta­je bar­dzo zło­żo­ny sce­na­riusz przy­pad­ku uży­cia obło­żo­ny warun­ko­wy­mi ścież­ka­mi sce­na­riu­sza reali­za­cji tego przy­pad­ku uży­cia. Nie raz moż­na spo­tkać bar­dzo skom­pli­ko­wa­ny model pro­ce­su” wysta­wia­nia fak­tu­ry z wie­lo­ma warun­ka­mi… Diagram przy­pad­ków uży­cia jed­nak, po czymś w rodza­ju nor­ma­li­za­cji, naj­czę­ściej przed­sta­wiał by jed­no wyma­ga­nie – wysta­wia­nie fak­tur VAT – i wyglą­dał by tak:

Analiza biznesowa krok po kroku

Model procesów biznesowych

Pierwszym kro­kiem powin­na być jed­nak ana­li­za pole­ga­ją­ca na opra­co­wa­niu mode­li pro­ce­sów biz­ne­so­wych. Celem tego mode­lo­wa­nia jest wykry­cie, udo­ku­men­to­wa­nie i zro­zu­mie­nie każ­de­go kon­tek­stu wysta­wie­nia fak­tu­ry, wery­fi­ka­cja tre­ści wywia­dów (ludzie mają natu­ral­ne ten­den­cje do pomi­ja­nia rze­czy oczy­wi­stych i uwy­pu­kla­nia swo­jej roli w pro­ce­sie) oraz upew­nie­nia się, że zna­my wszyst­kie sytu­acje, w któ­rych wysta­wia­na jest fak­tu­ra VAT. Dlatego nie­za­leż­nie od zakre­su pro­jek­tu war­to zawsze opra­co­wać model pro­ce­sów biz­ne­so­wych całej organizacji.

Tu mała uwa­ga, model pro­ce­su to nie algo­rytm pra­cy a model obra­zu­ją­cy czyn­no­ści i ich cele.Samo wysta­wia­nie fak­tur może mieć róż­ne kon­tek­sty, może to robić wię­cej niż jed­na oso­ba, a spo­sób w jaki to robi zale­ży od kom­pe­ten­cji tej oso­by. W opi­sy­wa­nym przy­pad­ku mamy dwa takie kon­tek­sty. Faktura VAT za usłu­gę wysta­wia­na przez oso­bę o wyso­kich kwalifikacjach:

oraz fak­tu­ra VAT za towar z maga­zy­nu wysta­wia­na przez oso­bę nie mają­cą wie­dzy lub upraw­nień pozwa­la­ją­cych na samo­dziel­ne wysta­wie­nie Faktury VAT – dla takiej oso­by powsta­ła dokład­na procedura:

Jak widać dia­gra­my nie są jest zbyt skom­pli­ko­wa­ne i takie powin­ny być. Model pro­ce­sów biz­ne­so­wych nie powi­nien zawie­rać w sobie wie­dzy z innych obsza­rów takich jak : pro­ce­du­ry, upraw­nie­nia, umie­jęt­no­ści. Proces biz­ne­so­wy ma ści­słą defi­ni­cję (czyn­ność lub czyn­no­ści prze­kształ­ca­ją­ce stan wej­ścia w pro­dukt pro­ce­su). Jak widać powy­żej, czyn­no­ści pro­ce­su są koja­rzo­ne z pro­ce­du­ra­mi (tu komen­tarz) i rola­mi (tor ma mode­lu pro­ce­sów). W powyż­szych przy­kła­dach pro­ce­du­ry jaw­nie umiesz­czo­no na dia­gra­mie (to jed­na z moż­li­wych kon­wen­cji). W pierw­szym przy­pad­ku pro­ce­du­ra jest try­wial­na, wpi­sa­łem ją tyl­ko dla zobra­zo­wa­nia jej pro­sto­ty co wyni­ka z fak­tu, że kie­row­nik pro­jek­tu (PM) to oso­ba o wyso­kich kom­pe­ten­cjach, od któ­rej wyma­ga­my (CV, rekru­ta­cja) wie­dzy o tym jak wysta­wiać fak­tu­ry VAT. Informacja taka powin­na być w doku­men­ta­cji sko­ja­rzo­na z rolą PM.

Na dia­gra­mach ozna­czo­no czyn­no­ści zwią­za­ne z fak­tu­ro­wa­niem jako «przy­pa­dek uży­cia» (przy­ję­ta tu kon­wen­cja, nie jest to ele­ment nota­cji BPMN, w któ­rej wyko­na­no te diagramy).

Jak widać mamy więc dwa zupeł­nie róż­ne kon­tek­sty wysta­wia­nia fak­tur w tej fir­mie. Oba są istot­ne i było by dużym błę­dem two­rze­nie dla nich jed­ne­go uni­wer­sal­ne­go scenariusza.

Model przypadków użycia

Jak pora­dzić sobie z fak­tu­ro­wa­niem na dwa spo­so­by? Błędem było by pro­ste uzna­nie, że mamy dwa przy­pad­ki użycia:

Powyższe suge­ru­je wyko­na­nie dwóch imple­men­ta­cji, zapew­ne z powie­le­niem czę­ści kodu. Pojawienie się kolej­ne­go nowe­go kon­tek­stu, to tu kolej­ny przy­pa­dek uży­cia, będzie to wyma­ga­ło dopi­sa­nia kolej­ne­go kodu. Powyższy dia­gram to nie naj­lep­szy pomysł. Więc jak?

Tu poja­wia się rola mode­lu dzie­dzi­ny jako ele­men­tu doku­men­ta­cji wyma­gań. Nazywa się to cza­sem wyma­ga­nia dzie­dzi­no­we” w ana­li­zie biz­ne­so­wej czy­li zro­zu­mie­nia i udo­ku­men­to­wa­nie biz­ne­so­wych aspek­tów narzę­dzia (a nim jest zama­wia­ne opro­gra­mo­wa­nie), na któ­re wyma­ga­nia mają zostać wyspecyfikowanie.

Moim zda­niem model przy­pad­ków uży­cia, jako tak zwa­na czar­na skrzyn­ka, nie roz­wią­zu­je żad­ne­go pro­ble­mu poza oczy­wi­ście wyspe­cy­fi­ko­wa­niem wyma­gań funk­cjo­nal­nych (co jest bar­dzo ważne!).

Dobry pro­jekt będzie zawie­rał jed­nak, moim zda­niem, jeden przy­pa­dek uży­cia ale tak­że kon­tek­sty ról. Nieco nad­mia­ro­wy dia­gram przy­pad­ków uży­cia z kontekstami:

Powyższy dia­gram mode­lu­je pomysł” z kon­tek­sta­mi. Oprogramowanie ma jeden przy­pa­dek uży­cia (sys­tem ma być pro­sty i łatwy w uży­ciu!). Diagram przed­sta­wia dwóch akto­rów (dwie role), jeden przy­pa­dek uży­cia (w pro­jek­tach wole oso­bi­ście poję­cie usłu­ga sys­te­mu”, któ­re jest łatwiej­sze w komu­ni­ka­cji z użyt­kow­ni­kiem), oraz jego dwie spe­cja­li­za­cje po jed­nej dla każ­de­go akto­ra (aktor jest połą­czo­ny z wła­ści­wym przy­pad­kiem uży­cia związ­kiem uży­cia). Powyższy dia­gram był­by trud­ny do zro­zu­mie­nia przez Zamawiającego nie zna­ją­ce­go dobrze nota­cji UML, różo­we ele­men­ty umie­ści­łem nad­mia­ro­wo dla zilu­stro­wa­nia tego arty­ku­łu). W doku­men­ta­cji dla klien­ta ele­men­tów ozna­czo­nych na różo­wo nie umieszczam.

Nadal jest to jed­nak czar­na skrzyn­ka, któ­ra nie deter­mi­nu­je logi­ki biz­ne­so­wej sys­te­mu. Czy powin­na? Myślę, że tak, gdyż wyzna­ję zasa­dę, że rolą deve­lo­pe­ra jest imple­men­ta­cja a nie mode­lo­wa­nie logi­ki orga­ni­za­cji , któ­rej nie zna. Zostawiając deve­lo­pe­ra tyl­ko z powyż­szym dia­gra­mem, bar­dzo ryzy­ku­je­my, że wyko­na co praw­da opro­gra­mo­wa­nie w sta­nie na dzi­siaj”, ale jego roz­wój, wyni­ka­ją­cy z logi­ki biz­ne­so­wej orga­ni­za­cji (np. pla­no­wa­ne­go jej roz­wo­ju) może być trud­ny, kosz­tow­ny a nawet cza­sem niemożliwy.

Model dziedziny systemu

Dlatego jed­nak two­rzy­my model dzie­dzi­ny sys­te­mu, nie narzu­ca­jąc (tu zga­dzam się z pro­gra­mi­sta­mi) metod roz­wią­zy­wa­nia pro­ble­mów imple­men­ta­cji (czy­li na tym eta­pie nie prak­ty­ki DDD a raczej model ana­li­tycz­ny BCE).

Nie umiesz­cza­my więc na dia­gra­mie przy­pad­ków uży­cia kon­tek­stów (powy­żej przy­pad­ki uży­cia ozna­czo­ne kolo­rem różo­wym) a two­rzy­my model wewnętrz­nej logi­ki zawie­ra­ją­cej infor­ma­cję o tych kon­tek­stach. Model ten powi­nien być tak opra­co­wa­ny, by moż­li­we było łatwe doda­wa­nie nowych kon­tek­stów, bo to wyni­ka ze spe­cy­fi­ki biz­ne­su. Dodatkowo ele­men­tem biz­ne­so­wym jest tak­że to, że Zamawiający na dziś ocze­ku­je moż­li­wo­ści pra­cy z pomo­cą kom­pu­te­ra i table­tu, nie wyklu­cza w przy­szło­ści innych urzą­dzeń koń­co­wych. Wymaganie to nie powin­no pro­wa­dzić do powie­le­nia przy­pad­ków uży­cia, nie powin­no tak­że kom­pli­ko­wać ele­men­tów typo­wo dzie­dzi­no­wych np. zarzą­dza­nia kon­tek­sta­mi przy­pad­ku użycia.

Proponowany tu model dzie­dzi­ny to kom­plet­na logi­ka dzie­dzi­no­wa (kom­po­nent Model wzor­ca MVC, dia­gram klas w kon­wen­cji BCE/ICONIX)):

Powyższy model zawie­ra dwa dedy­ko­wa­ne ele­men­ty, każ­dy dla kon­kret­ne­go urzą­dze­nia koń­co­we­go, bez inge­ren­cji w sam mecha­nizm fak­tu­ro­wa­nia (kla­sa WystawienieFakturyVAT). To wzo­rzec archi­tek­to­nicz­ny MVVM. Klasa ta (jed­na dla przy­pad­ku uży­cia!) zawie­ra odpo­wied­nie sce­na­riu­sze dla każ­de­go kon­tek­stu (kla­sy skom­po­no­wa­ne o nazwach takich jak akto­rzy, tu np. wzo­rzec pro­jek­to­wy stra­te­gia). Faktury VAT są zarzą­dza­ne przez repo­zy­to­rium faktur.

Model sterowania interakcją

Uzupełnieniem powyż­sze­go, dia­gram przy­pad­ków uży­cia i model dzie­dzi­ny, powi­nien być model sce­na­riu­sza reali­za­cji przy­pad­ku uży­cia – dia­gram sekwen­cji (któ­re­go już tu nie pre­zen­tu­ję, był nie raz opi­sy­wa­ny) oraz dia­gram ste­ro­wa­nia inte­rak­cją (nie jest to dia­gram aktywności!):

Powyższy dia­gram poka­zu­je, kolej­ne ekra­ny (ich makie­ty powin­na zawie­rać doku­men­ta­cja wyma­gań). Mam nadzie­ję, że nie powyż­sze­go szcze­gó­ło­wo wyjaśniać.

Na zakończenie

Powyższe to kom­plet­ne wyma­ga­nia dla deve­lo­pe­ra, któ­re nie narzu­ca­ją imple­men­ta­cji a jedy­nie ocze­ki­wa­ną logi­kę two­rzo­ne­go opro­gra­mo­wa­nia. Jeżeli w wyma­ga­niach doda­my, że ele­men­ty Entities (tu kape­lu­sik” FakturyVAT) mają być roz­dziel­ne, a w wypad­ku wąt­pli­wo­ści (nie­ste­ty) narzu­ca­my [[wzo­rzec acti­ve records]] (cza­sem [[wzo­rzec acti­ve table]]), to zabez­pie­cza­my się przed bar­dzo czę­stą i szko­dli­wą prak­ty­ką wie­lu deve­lo­pe­rów, pole­ga­ją­cą na pro­jek­to­wa­niu repo­zy­to­rium w posta­ci jed­nej dużej rela­cyj­nej bazy danych dla całe­go sys­te­mu i sto­so­wa­niu bar­dzo zło­żo­ne­go mapo­wa­nia ORM (mapo­wa­nie obiek­to­wo-rela­cyj­ne), któ­re w zasa­dzie zabi­je wszyst­kie korzy­ści z obiek­to­wej ([[para­dyg­mat OOAD]]) her­me­ty­za­cji (utrzy­ma­nie peł­nej nie­za­leż­no­ści wszyst­kich ele­men­tów archi­tek­tu­ry). Drugim tego efek­tem jest z regu­ły dra­stycz­ny spa­dek wydaj­no­ści z powo­du bar­dzo wie­lu skom­pli­ko­wa­nych zapy­tań do bazy danych.

Tak więc, war­to pro­wa­dzić ana­li­zę rze­tel­nie, bez nad­mia­ru zwin­no­ści” i z peł­nym zro­zu­mie­niem pro­ble­mu. Pochopne decy­zje, roz­po­czy­na­nie imple­men­ta­cji bez posia­da­nia pro­jek­tu cało­ści, to naj­częst­sze przy­czy­ny nie­uda­nych pro­jek­tów, pro­jek­tów trwa­ją­cych i kosz­tu­ją­cych znacz­nie wię­cej niż planowano…

Bo naj­waż­niej­si w ana­li­zie, Panie, są Aktorzy…

Wymagania biznesowe a wymagania wobec produktu – rola analityka

Na począ­tek histo­ryj­ka. Stolarz ma zwy­kły mło­tek, któ­re­go uży­wa do wbi­ja­nia gwoź­dzi. Prosty mło­tek to trzo­nek i pro­sty pobi­jak. W mia­rę roz­wo­ju fir­my poja­wia się pro­blem: sto­la­rze mają pro­blem z otwar­ciem piwa pod­czas pra­cy, zaczy­na­ją szu­kać spo­so­bu, czę­sto odbi­ja­ją kap­sle młot­kiem, nie raz uszka­dza­jąc butel­kę. Z uszko­dzo­nej butel­ki picie jest nie­bez­piecz­ne więc odpo­wie­dzial­ni pra­cow­ni­cy, w takich przy­pad­kach, muszą iść do skle­pu po dru­gie piwo. Powoduje to stra­tę cza­su i spa­dek wydaj­no­ści. Pojawia się wyma­ga­nie biz­ne­so­we: popra­wić wydaj­ność sto­la­rzy w pro­ce­sie prac budow­la­nych. Strategia: uspraw­nić narzę­dzia. Taktyka: zapro­jek­to­wać mło­tek, któ­ry nie uszka­dza kap­slo­wa­nych bute­lek pod­czas otwierania.

Analityk musi zro­zu­mieć pro­blem i zapro­po­no­wać rozwiązanie

No to do robo­ty: czyn­no­ści wyko­ny­wa­ne przez sto­la­rzy w pro­ce­sie kon­stru­owa­nia drew­nia­nych kon­struk­cji to wbi­ja­nie gwoź­dzi (czy­li ogól­nie pobi­ja­nie”) oraz otwie­ra­nie kap­slo­wa­nych bute­lek z piwem. Obie czyn­no­ści ma reali­zo­wać mło­tek” (przy­ję­ta tak­ty­ka roz­wią­za­nia pro­ble­mu). Czynności te więc sta­ją jego, młot­ka, przy­pad­ka­mi użycia.

Młotek świad­czy jed­ną usłu­gę: wspar­cie sto­la­rza w czyn­no­ściach, któ­rych nie moż­na wyko­nać dłoń­mi. Decydujemy (decy­zja pro­jek­to­wa), że oba przy­pad­ki uży­cia (usłu­gę tę) będzie reali­zo­wa­ła głów­ka młot­ka (kla­sa usłu­go­wa), a nie np. trzo­nek zakoń­czo­ny otwie­ra­czem. Tak więc na bazie wyko­ny­wa­nych czyn­no­ści i wie­dzy, że ma to być to samo narzę­dzie pra­cy, uzna­je­my, że mło­tek ma mieć dwa przy­pad­ki uży­cia: pobi­ja­nie oraz odkap­slo­wa­nie. Projektujemy mło­tek, model dzie­dzi­ny ma dwie kla­sy: trzo­nek i głów­ka. Główka to usłu­go­wa kla­sa i będzie mia­ła dwie ope­ra­cje: pobi­ja­nie i otwie­ra­nie kap­slo­wa­nych bute­lek.
Implementacja (obraz po lewej) to dzie­ło pro­du­cen­ta narzę­dzi: mło­tek typu dru­gie­go. Jak widać głów­ka świad­czy usłu­gę (trwa­ły meta­lo­wy ele­ment robo­czy) uży­tecz­ną do pobi­ja­nia i otwie­ra­nia bute­lek (ma dwie operacje).

Co więc mamy? Wymaganie biz­ne­so­we, pro­dukt wraz z tym jakie usłu­gi potra­fi świad­czyć, przy­pad­ki uży­cia czy­li to, do cze­go fak­tycz­nie moż­na (chce­my) użyć tego młot­ka oraz pro­jekt realizacji.

Czynności w pro­ce­sie biz­ne­so­wym (model biz­ne­so­wy) mapu­ją się na przy­pad­ki uży­cia pro­duk­tu (model – [[pro­jekt jako czar­na skrzyn­ka]] – tego produktu).

Jednak nicze­go nie wie­my o tym, co nale­ży zro­bić do cza­su, gdy ktoś nie opra­cu­je pro­jek­tu pro­duk­tu. Autor pomy­słu zawarł w pro­jek­cie dwa ele­men­ty: trzo­nek i dwu-funk­cyj­ną głów­kę czy­li dwie kla­sy dzie­dzi­no­we i ich ope­ra­cje (głów­ka: Uderz oraz Zerwij kap­sel i trzo­nek: połącz dłoń z głów­ką młot­ka). Implementacja (design, dobór mate­ria­łów itp. to inży­nier­ska robo­ta” czy­li reali­za­cja pro­jek­tu. Tu są reali­zo­wa­ne wyma­ga­nia poza-funk­cjo­nal­ne np. mło­tek ma wytrzy­my­wać 1 mln. ude­rzeń, nie może ważyć wię­cej niż 1,5 kg.

Można było sto­la­rza zaopa­trzyć w stan­dar­do­wy otwie­racz do bute­lek, jed­nak mamy tu ogra­ni­cze­nie stra­te­gicz­ne: nie chce­my powięk­szać licz­by przed­mio­tów w wypo­sa­że­niu sto­la­rza. Tak więc tak­ty­ka musia­ła być taka jaką tu wybrano.

Mam nadzie­ję, że ten pro­sty przy­kład obra­zu­je tak­so­no­mię” (kla­sy­fi­ka­cję) wyma­gań. Sam kie­dyś mie­wa­łem z tym pro­blem, szcze­gól­nie gdy pro­jekt się rozrastał.

Problemem więk­szo­ści pro­jek­tów pro­gra­mi­stycz­nych jest nie tyle lista wyma­gań (choć może być nie­kom­plet­na lub nie­spój­na, jeże­li powsta­nie jako dekla­ra­tyw­na lista ręka­mi pra­cow­ni­ków), pro­ble­mem pro­jek­to­wym jest zamia­na wyma­gań na usłu­gi sys­te­mu i pro­jekt ich realizacji.

Co więc mamy w pro­jek­tach, któ­rych celem jest dostar­cze­nie oprogramowania:

  1. wyma­ga­nia biz­ne­so­we – wyma­ga­nia wzglę­dem nowe­go lub zmie­nia­ne­go mode­lu biz­ne­so­we­go lub stra­te­gii czy­li co chce­my osią­gnąć w orga­ni­za­cji,
  2. wyma­ga­nia pro­duk­to­we – to cze­go ocze­ku­je­my od nowe­go pro­duk­tu (narzę­dzia pra­cy) czy­li jak to chce­my osią­gnąć (zapa­dła ewen­tu­al­na decy­zja o potrze­bie posia­da­nia sto­sow­ne­go produktu),
  3. usłu­gi pro­duk­tu – to co pro­dukt potra­fi zro­bić dla jego użyt­kow­ni­ka czy­li co pro­dukt powi­nien umieć”,
  4. pro­ces biz­ne­so­wy – lista czyn­no­ści jakie wyko­nu­ją przy­szli użyt­kow­ni­cy pro­duk­tu czy­li kie­dy będzie­my uży­wać pro­duk­tu,
  5. przy­pad­ki uży­cia wywo­dzo­ne z pro­ce­sów – to do cze­go użyt­kow­nik chce użyć pro­duk­tu,
  6. model pro­duk­tu – struk­tu­ra opi­su­ją­ca wewnętrz­ne ele­men­ty pro­duk­tu (modu­ły) i ich moż­li­wo­ści (ope­ra­cje jakie potra­fią wyko­nać) oraz ich wza­jem­ną współ­pra­cę (sce­na­riu­sze współ­dzia­ła­nia), pozwa­la­ją­cą na wyko­na­nie usłu­gi (zre­ali­zo­wa­nie kolej­nych przy­pad­ków uży­cia) czy­li jak powi­nien być skon­stru­owa­ny pro­dukt (jego obiek­to­wy model – dzie­dzi­na sys­te­mu); model pro­duk­tu to wyma­ga­nia dzie­dzi­no­we.
Tu pora na kon­klu­zję: wyma­ga­nia wyma­ga­niom nie­rów­ne, nie impli­ku­ją tak­że roz­wią­za­nia i jego jako­ści, więc jedy­nym spo­so­bem jed­no­znacz­ne­go zamó­wie­nia” opro­gra­mo­wa­nia jest opi­sa­nie tego jak powi­nien być skon­stru­owa­ny pro­dukt.

Odpowiedzialność za wyma­ga­nia w pro­jek­tach programistycznych

Projekty pro­gra­mi­stycz­ne i ana­li­za poprze­dza­ją­ca ich reali­za­cję, powin­ny być dosto­so­wa­ne (poczy­nio­ne pew­ne zało­że­nia) do dostęp­nej na ryn­ku tech­no­lo­gii i metod wytwa­rza­nia opro­gra­mo­wa­nia. Wśród nich są meto­dy obiek­to­we ana­li­zy i pro­jek­to­wa­nia oraz obiek­to­we języ­ki pro­gra­mo­wa­nia i szkie­le­ty opro­gra­mo­wa­nia (fra­me­wor­ki), pozwa­la­ją­ce na imple­men­ta­cję pro­jek­tów wyko­na­nych w obiek­to­wym paradygmacie.

Wydaje się, że obiek­to­we meto­dy są naj­sku­tecz­niej­sze w przy­pad­ku opro­gra­mo­wa­nia dla biz­ne­su. Bardzo popu­lar­ny i chy­ba naj­star­szy obiek­to­wy wzo­rzec pro­jek­to­wy to wzo­rzec [[Model, View, Controller (MVC)]]. W dużym uproszczeniu:

  • Model opi­su­je dzie­dzi­nę systemu,
  • View opi­su­je to co widzi użytkownik,
  • Control­ler ste­ru­je tym wszystkim.

Stosuję ten wzo­rzec do podzia­łu zadań (odpo­wie­dzial­no­ści) w pro­jek­tach z nastę­pu­ją­cy­mi konsekwencjami:

  1. View (widok): klient zama­wia” for­mu­larz (papier/ekran), bo klient wie co chce mieć”,
  2. Analityk two­rzy Model Dziedziny: 100% obiek­tów dzie­dzi­no­wych z regu­ła­mi (atry­bu­ty i ope­ra­cje biznesowe),
  3. Analityk dostar­cza listę wyma­gań poza-funk­cjo­nal­nych (ocze­ki­wa­ne wydaj­ność, bez­pie­czeń­stwo, dostęp­ność itp.),
  4. Developer imple­men­tu­je Model Dziedziny two­rząc opro­gra­mo­wa­nie, z pomo­cą uży­wa­ne­go szkie­le­tu opro­gra­mo­wa­nia roz­wią­zu­je pro­ble­my poza-funk­cjo­nal­ne lub zgła­sza ogra­ni­cze­nia ich realizacji.

I tak mamy: 100% inter­fej­su użyt­kow­ni­ka zama­wia użyt­kow­nik (sam lub z pomo­cą spe­cja­li­stów), 100% wyma­gań funk­cjo­nal­nych reali­zu­je Model Dziedziny (pro­jekt ana­li­ty­ka-pro­jek­tan­ta), 100% wyma­gań poza-funk­cjo­nal­nych reali­zu­je deve­lo­per (pro­jekt i imple­men­ta­cja). Developer tak­że imple­men­tu­je model dzie­dzi­ny z pomo­cą tech­no­lo­gii jakiej używa.

A jeże­li klient powie: nie mamy tych wzo­rów doku­men­tów i ekra­nów! To pierw­szy sygnał, że nie ma pod­staw do zama­wia­nia jakie­go­kol­wiek opro­gra­mo­wa­nia, bo naj­pierw trze­ba wie­dzieć co się chce”.

Jak to zro­bić? Tu kła­nia się ana­li­za biz­ne­so­wa: mode­lu­je­my pro­ce­sy biz­ne­so­we, dla każ­de­go z nich usta­la­my wej­ście oraz efekt (pro­dukt) czy­li wła­śnie owe wzo­ry doku­men­tów”. Po upo­rząd­ko­wa­niu tego i upew­nie­niu się, że nie ma w tym bała­ga­nu (powtór­ki, bra­ki, nie­kon­se­kwen­cje, sprzecz­no­ści itp.) może­my pytać o goto­we opro­gra­mo­wa­nie lub zama­wiać” jego wytwo­rze­nie. Produktem pra­cy ana­li­ty­ka powin­ny być, poza mode­la­mi pro­ce­sów bo one są narzę­dziem a nie celem, obiek­to­wy model dzie­dzi­ny czy­li model tego jaki­mi infor­ma­cja­mi i jak zor­ga­ni­zo­wa­ny­mi ope­ru­je orga­ni­za­cja, oraz to jak pra­cow­ni­cy tej orga­ni­za­cji chcą się komu­ni­ko­wać z opro­gra­mo­wa­niem (źro­dłem infor­ma­cji jest jed­nak klient).

Mamy czy­sty podział odpo­wie­dzial­no­ści i łatwość roz­li­cze­nia pro­jek­tu. Na czym pole­ga haczyk? Klient nie może uni­kać odpo­wie­dzial­no­ści za skut­ki swo­ich decy­zji i udzie­la­nych infor­ma­cji. Ale też, co jest klu­czo­we: Analityk musi zro­zu­mieć pro­blem i zapro­po­no­wać rozwiązanie. 

Jednak nie jest rolą ana­li­ty­ka wyko­na­nie opro­gra­mo­wa­nia! To jak – tech­no­lo­gia – ma to zostać zre­ali­zo­wa­ne” jest decy­zją deve­lo­pe­ra. Ma dużo pra­cy. Nie zapo­mi­naj­my, że kod reali­zu­ją­cy tak zwa­ną logi­kę biz­ne­so­wą to led­wie kil­ka pro­cent cało­ści kodu apli­ka­cji, jed­nak nie zapo­mi­naj­my tak­że (pro­gra­mi­ści), że zła logi­ka biz­ne­so­wa dys­kwa­li­fi­ku­je całe to opro­gra­mo­wa­nie z pro­ste­go powo­du: sta­je się nieprzydatne.

___

Po wie­lu dys­ku­sjach na szko­le­niach pre­zen­tu­ję zgod­ny z UML dia­gram przy­pad­ków uży­cia dla młotka:

Business Model vs. System Model

Swego cza­su pisa­łem o tym, że np. kla­sa prze­cho­wu­ją­ca infor­ma­cje o pra­cow­ni­ku raczej powin­na nazy­wać się DaneOPracowniku a nie Pracownik. Dlaczego? Bo pro­jekt sys­te­mu zawie­ra­ją­cy infor­ma­cje o pra­cow­ni­kach i klien­tach, a tak­że treść wie­lu doku­men­tów, powi­nien pozwa­lać zro­zu­mieć co jest w sys­te­mie” a co w rze­czy­wi­sto­ści” (pra­cow­nik jest żywym orga­ni­zmem, opro­gra­mo­wa­nie co naj­wy­żej zarzą­dza dany­mi opi­su­ją­cy­mi tego pracownika).

Ku moje­mu zasko­cze­niu ale tak­że rado­ści, nie­mal­że ten sam pro­blem poru­szył Ron Ross (blo­ger i autor książ­ki BUILDING BUSINESS SOLUTIONS: Business Analysis with Business Rules):

To make a long sto­ry short, busi­ness models talk direc­tly abo­ut real-world things (as busi­ness people do); sys­tems models talk abo­ut sur­ro­ga­tes for real-world things (as sys­tem desi­gners do). Not the same thing! (za Business Model vs. System Model: eCommerce ? Ron Ross on Business Rules).

W uprosz­cze­niu: model biz­ne­so­wy opi­su­je real­ny świat, model sys­te­mu (opro­gra­mo­wa­nia) opi­su­je jego [[suro­gat]]. Warto o tym nie zapo­mi­nać. Podobne podej­ście pre­zen­to­wa­ne jest przez auto­rów książ­ki: Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approach). Tu poja­wia się meta­fo­ra opi­su­ją­ca opro­gra­mo­wa­nie (sys­tem) jako narzę­dzia i mate­ria­ły”. Tu tak­że wewnątrz sys­te­mu nie ma Pracownika a jedy­nie jego Kartoteka.

Warto jed­nak pamię­tać, ze w sys­te­mach biz­ne­so­wych np. doku­ment ma (może mieć) wer­sje papie­ro­wą i elek­tro­nicz­ną. W przy­pad­ku owe­go pra­cow­ni­ka już nie, pra­cow­nik (jak każ­dy czło­wiek) ma tyl­ko wer­sję żywą” (pomi­ja­my tu kwe­stie gier kom­pu­te­ro­wych, któ­re tak­że są opro­gra­mo­wa­niem). Tak więc sys­tem zapew­ne ma w sobie” np. fak­tu­rę czy umo­wę ale na pew­no nie pra­cow­ni­ka czy klienta.

Szybkie pod­su­mo­wa­nie

Każdy model opro­gra­mo­wa­nia, a spe­cy­fi­ka­cja wyma­gań jest tak­że takim mode­lem, powi­nien być opa­trzo­ny jego kon­tek­stem i prag­ma­ty­ką. Przede wszyst­kim sys­te­my biz­ne­so­we to nie gry kom­pu­te­ro­we, tu mamy (sys­tem prze­twa­rza) doku­men­ty, dano o czymś lub kimś, ale nie ludzi, nie pojazdy.

Zaniedbanie tej pozor­nie bła­hej róż­ni­cy (kła­nia się [[semio­ty­ka i teo­ria komu­ni­ka­cji]]) pro­wa­dzi to dużych nie­po­ro­zu­mień, a nie raz do wręcz beł­ko­tli­wej tre­ści w rodza­ju: sys­tem ma pozwa­lać na usu­wa­nie pra­cow­ni­ków z poszcze­gól­nych wydzia­łów fir­my. Nie! Co naj­wy­żej sys­tem powi­nien pozwa­lać na two­rze­nie nowych zakre­sów obo­wiąz­ków lub umów o pra­cę na pod­sta­wie wzo­rów umów lub tre­ści umów poprzed­nio zawar­tych (plus wzo­ry lub mode­le tych dokumentów).