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”

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.

Dane są nieważne bo liczy się przede wszystkim mechanizm działania

Tym prze­wrot­nym tytu­łem chcę dziś zwró­cić uwa­gę na dwa waż­ne i bar­dzo pomoc­ne wzor­ce ana­li­tycz­ne (sło­wo ana­li­tycz­ne ode mnie, w książ­kach na temat wzor­ców bar­dzo rzad­ko uży­wa­na jest nazwa wzor­ce ana­li­tycz­ne”) opi­sa­ne w książ­ce M.Fowlera. Wzorcami ana­li­tycz­ny­mi nazy­wam te wzor­ce pro­jek­to­we, któ­re poma­ga­ją w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu (biz­ne­so­wy model obiektowy).

MFowlerWzorceProjektowePolecam oczy­wi­ście lek­tu­rę całej książ­ki Martina Fowlera Architektura Systemów Zarządzania Przedsiębiorstwem Wzorce Projektowe.[1] Opisuje on w niej wła­snie wzor­ce pro­jek­to­we bar­dzo przy­dat­ne już na eta­pie pro­jek­to­wa­nia. Fowler nie uży­wa poję­cia wzor­ca ana­li­tycz­ne­go” ale książ­ka jest podzie­lo­na na obsza­ry zasto­so­wa­nia wzor­ców, wśród nich znaj­dzie­cie więc wzor­ce logi­ki dzie­dzi­ny, wzor­ce pre­zen­ta­cji inter­ne­to­wych czy omó­wio­ne tu wzor­ce dys­try­bu­cji a tak­że bar­dzo przy­dat­ne wzor­ce okre­ślo­ne jako pod­sta­wo­we”.

Poza wzor­ca­mi typo­wy­mi dla sys­te­mów obiek­to­wych w ogó­le, war­to zwró­cić uwa­gę na dwa. Opiszę krót­ko dwa bar­dzo przy­dat­ne na eta­pie ana­li­zy wzor­ce pro­jek­to­we (odno­śni­ki do stro­ny M.Fowlera): Transfer Object oraz Value Object.

Przykład użycia Value Object i Transfer Object

Na eta­pie ana­li­zy pro­ble­mu (ana­li­zy i mode­lo­wa­niu dzie­dzi­ny sys­te­mu) powin­no nas inte­re­so­wać przede wszyst­kim co i po co się dzie­je. Wielu ana­li­ty­ków o rodo­wo­dzie pro­gra­mi­stycz­nym zaczy­na pra­cę od pytań w rodza­ju ile nazwi­sko ma zna­ków, czy mogą to być tyl­ko lite­ry czy coś jesz­cze”, itd. Jest to moim zda­niem kom­plet­ne nie­po­ro­zu­mie­nie. Zabieranie się za opra­co­wa­nie mode­lu od tej stro­ny (mode­lo­wa­nie danych) cał­ko­wi­cie przy­ćmi roz­wią­zy­wa­ny pro­blem. Np. sta­ra­jąc się zro­zu­mieć sys­tem sprze­da­ży bile­tów na samo­lot istot­ne jest na począt­ku nie to, ile zna­ków może mieć nazwi­sko a to, że bar­dzo istot­na jest iden­ty­fi­ka­cja pasa­że­rów i miejsc jakie mają zająć w samo­lo­cie. To nie jest to samo, bo iden­ty­fi­ka­cja pasa­że­rów ma za cel kon­tro­lę, kogo wpusz­cza­my na pokład samo­lo­tu, a nazwi­sko to jed­na z cech pasa­że­ra i na eta­pie ana­li­zy nie nale­ży zakła­dać, że to jedy­ny i naj­lep­szy spo­sób na to roz­róż­nie­nie. Brzmi jak here­zja? Zapewne, bo więk­szość” ana­li­ty­ków zaczy­na wła­śnie od bada­nia np. nazwiska.

A kie­dy zając się nazwi­skiem? Dopiero wte­dy gdy zro­zu­mie­my pro­blem i opra­cu­je­my sys­te­mo­we jego roz­wią­za­nie. Po pierw­sze dla­te­go, że na począt­ku nie mamy wie­dzy (za wcze­śnie na taką decy­zję) by usta­lić na jakich kon­kret­nie danych będzie opie­ra­ła się iden­ty­fi­ka­cja pasa­że­rów (a nuż poja­wi się [[bio­me­tria]]), po dru­gie nie­po­trzeb­nie skom­pli­ku­je­my doku­men­ta­cję zamu­la­jąc ją od same­go począt­ku dużą ilo­ścią zbęd­nych atry­bu­tów”.

Druga istot­na rzecz, to komu­ni­ka­cja. Wiemy, że fir­ma sprze­da­ją­ca bile­ty lot­ni­cze ope­ru­je róż­ny­mi dany­mi (lokal­ny model biz­ne­so­wy tej fir­my) na temat rezer­wo­wa­nych bile­tów. Wiemy, że te dane – o sprze­da­nych bile­tach – muszą być prze­ka­za­ne linii lot­ni­czej, ta zaś wcze­śniej musi jakoś prze­ka­zać infor­ma­cje o tym, na jakie loty i jakie bile­ty oferuje.

Co cie­ka­we, dosko­na­le to pasu­je to opi­sów wyko­ny­wa­nych przez zama­wia­ją­ce­go (albo jak kto woli user sto­ry). Normalny czło­wiek raczej powie nam, że zapi­su­je dane pasa­że­ra”, ale raczej nie powie nam, że reje­stru­je 25 zna­ków nazwi­ska, 20 zna­ków imie­nia i cza­sem 20 zna­ków dru­gie­go imie­nia.….”. Ten sam czło­wiek powie następ­nie, że prze­ka­zu­je dane o sprze­da­nych bile­tach do odpo­wied­nich linii lot­ni­czych a nie, że doko­nu­je trans­fe­ru kolek­cji danych zawierających.….”.

Analiza i projektowanie

Na bazie wywia­dów, doku­men­tów itp. sta­ra­my się zro­zu­mieć co jest gra­ne”, jak ten sys­tem funk­cjo­nu­je. Powstaje np. taki dia­gram. Tu zakła­dam już, że mode­lu­je­my sys­tem sprze­da­ży bile­tów, ale sys­tem ozna­cza wszyst­ko to, co bie­rze w tym udział” a nie kon­kret­ne oprogramowanie”:

Transfer biletów do linii lotniczej

Mamy model cze­goś co ma się wyda­rzyć. Na tym eta­pie kom­plet­nie nie ma sen­su zaj­mo­wa­nie się tym ile zna­ków ma nazwi­sko. To może się zmie­nić w toku ana­li­zy a nawet imple­men­ta­cji, ale nie powin­na ulec zmia­nie logi­ka tej operacji.

Jak już opa­nu­je­my logi­kę (zro­zu­mie­my co i jak ma dzia­łać i zapro­jek­tu­je­my jak to zre­ali­zo­wać) zabie­ra­my się za szcze­gó­ły. Model dzie­dzi­ny (frag­ment):

Model dziedziny

Jak widać, np. danePasażera jako zawar­tość to daneOsoby a nie pola i typy danych”. Czym są DaneOsoby znaj­dzie­my tu:

ValueObject

Zamiast pro­stych typów danych (np. zna­ko­we) sto­su­je­my obiekt jako typ danych. To zna­ko­mi­cie uła­twia póź­niej­sze roz­sze­rze­nia i zmia­ny (nie musi­my nic zmie­niać w mode­lu dzie­dzi­ny by np. dodać dru­gie imię do danych oso­by, mody­fi­ku­je­my w jed­nym miej­scu jedy­nie dekla­ra­cję kla­sy DaneOsoby).

Wywołanie ope­ra­cji podajDaneBiletu zwra­ca obiekt DaneBiletuLitniczego (lub agre­gat zawie­ra­ją­cy wszyst­kie bilety):

Transfer ObjectNie jest to ten sam obiekt co wcze­śniej, ValueObject to typ danych, Transfer Object to seria­li­za­cja, któ­rej celem jest jedy­nie prze­nie­sie­nie w moż­li­wie naj­prost­szy do odczy­ta­nia spo­sób okre­ślo­nych infor­ma­cji (oba te obiek­ty nie mają jed­nak toż­sa­mo­ści). Nie nale­ży tych wzor­ców mylić ani utoż­sa­miać, gdyż Value Object to typ danych” zaś Transfer Object to jedy­nie para­metr wywo­łań, Value Object powi­nien mieć ope­ra­cje sparw­dza­ja­ce jego popraw­ność (wali­da­cja), Transfer Object słu­ży wyłącz­nie do prze­ka­zy­wa­nia infor­ma­cji jako para­metr wywo­łań i odpo­wie­dzi (w pew­nym sen­sie defi­niu­je pro­to­kół wymia­ny danych).

Korzyści ze sto­so­wa­nia tych wzor­ców to mię­dzy innymi:

  1. szcze­gó­ły danych odkła­da­my na koniec pro­jek­tu co jest bez­piecz­ne (nie musi­my mody­fi­ko­wać pro­jek­tu w mia­rę postę­pu pozy­ski­wa­nia wie­dzy o szczegółach),
  2. zmia­na tych szcze­gó­łów nie spo­wo­du­je potrze­by zmia­ny szkie­le­tu mode­lu dziedziny,
  3. może­my pro­wa­dzić spo­koj­ną upo­rząd­ko­wa­ną ana­li­zę top-down” (od ogó­łu do szczegółu),
  4. może­my się umó­wić z deve­lo­pe­rem, że jako ana­li­ty­cy nie będzie­my wni­ka­li w szcze­gó­ły danych, nadal może­my ope­ro­wać kla­sa­mi ValueObject i TransferObject (kla­sy te będą w począt­ko­wej fazie pro­jek­tu bez atrybutów),
  5. mimo to może­my umie­ścić w kla­sach ValueObject warun­ki wali­da­cji (ope­ra­cje klas, któ­rych tu nie poka­zy­wa­łem) i do tego one mię­dzy inny­mi słu­żą (to się nazy­wa okre­śla­nie wyma­gań poprzez testy czy­li TDD),
  6. już na samym począt­ku może­my uzgod­nić postać danych wymie­nia­nych na inter­fej­sach (np. zdal­na komu­ni­ka­cja) i korzy­stać z tej umowy.

Tak zapro­jek­to­wa­ny sys­tem speł­nia tak­że jed­ną z klu­czo­wych zasad pro­jek­to­wa­nia obiek­to­we­go: sys­tem jest zamknię­ty na zmia­ny i otwar­ty na rozszerzenia”.

Na zakończenie

Często sły­szę, że to trud­ne i pra­co­chłon­ne (dodat­ko­we kla­sy w mode­lu), nie­ste­ty zbyt pro­sty pro­jekt potra­fi być kosz­tow­niej­szy w roz­bu­do­wie w porów­na­niu z pier­wot­nym wytwo­rze­niem, dla­te­go jak klient w ramach wyma­gań wpi­su­je (a wpi­su­je coraz czę­ściej): sys­tem ma umoż­li­wiać łatwe roz­sze­rze­nia funk­cjo­nal­no­ści, to nale­ży go tak pro­jek­to­wać, w prze­ciw­nym wypad­ku wyma­ga­nie to nie jest spełnione…

Druga uwa­ga: czę­sto sami klien­ci zabi­ja­ją swo­je pro­jek­ty żąda­jąc na samym począt­ku udo­ku­men­to­wa­nia wszyst­kich szcze­gó­łów jakie im do gło­wy przyj­dą nie potra­fiąc jed­no­cze­śnie opi­sać mecha­ni­zmu dzia­ła­nia ich orga­ni­za­cji (lub nowe­go pomy­słu). To nie­ste­ty czę­sto spo­ty­ka­ne zja­wi­sko, z któ­rym moim zda­niem nale­ży wal­czyć. Paradoksalnie zło­żo­ność sys­te­mów biz­ne­so­wych tkwi w mecha­ni­zmie ich funk­cjo­no­wa­nia a nie w danych, któ­re zbie­ra­ją (któ­rych nie raz jest po pro­stu za dużo…).

Dane to fak­ty jakie chce­my znać, te fak­ty są kon­se­kwen­cją dzia­ła­nia a nie odwrotnie. 

Na ryn­ku w Polsce są jesz­cze mię­dzy inny­mi książ­ki o wzorcach:

Moim zda­niem jed­nak nie przy­dat­ne ana­li­ty­kom. Pierwsza to wzor­ce tech­nicz­ne”, sto­so­wa­ne głów­nie z kom­po­nen­tach Controller i View (archi­tek­tu­ra MVC). Druga to w zasa­dzie doku­men­ta­cja [[J2EE]]. Tak więc obie raczej dla pro­gra­mi­stów i archi­tek­tów. Książkę Fowlera pole­cam ana­li­ty­kom i archi­tek­tom tak­że. Wszystkim pole­cam tak­że UML i Wzorce pro­jek­to­we Larmana.

(UWAGA! Pokazano pro­jekt poglą­do­wy, wyssa­ny z pal­ca, nie ujaw­ni­łem tre­ści żad­ne­go z moich real­nych projektów).

Footnotes
[1]M. Fowler, Architektura sys­te­mów zarzą­dza­nia przed­się­bior­stwem. Wzorce pro­jek­to­we [na:] ?helion​.pl?, http://​helion​.pl/​k​s​i​a​z​k​i​/​a​r​c​h​i​t​e​k​t​u​r​a​-​s​y​s​t​e​m​o​w​-​z​a​r​z​a​d​z​a​n​i​a​-​p​r​z​e​d​s​i​e​b​i​o​r​s​t​w​e​m​-​w​z​o​r​c​e​-​p​r​o​j​e​k​t​o​w​e​-​m​a​r​t​i​n​-​f​o​w​l​e​r​,​s​z​a​b​k​o​.​htm, udo­stęp­nio­no 16 lipiec 2017.
[2]H. SA, J2EE. Wzorce pro­jek­to­we. Wydanie 2 [na:] ?helion​.pl?, http://​helion​.pl/​k​s​i​a​z​k​i​/​j​2​e​e​-​w​z​o​r​c​e​-​p​r​o​j​e​k​t​o​w​e​-​w​y​d​a​n​i​e​-​2​-​d​e​e​p​a​k​-​a​l​u​r​-​j​o​h​n​-​c​r​u​p​i​-​d​a​n​-​m​a​l​k​s​,​j​2​e​e​w​2​.​htm, udo­stęp­nio­no 16 lipiec 2017.
Dom bez planów

CQRS czyli kto, co i jak zamawia i dostarcza

Poprzedni arty­kuł koń­czy­ły słowa:

Tak więc jest to moim zda­niem dro­ga do mode­lo­wa­nia wyma­gań meto­dą ?tak to ma dzia­łać? a nie tyl­ko ?tak to ma wyglą­dać?, bo to dru­gie jest przy­czy­ną wie­lu problemów?

Wielu deve­lo­pe­rów zacie­kle bro­ni się przed tezą, że wyma­ga­nia to tak­że ?żąda­na reali­za­cja logi­ki biz­ne­so­wej?, ocze­ku­ją wyłącz­nie zesta­wu wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych. Jest to moim zda­niem źró­dło dwóch ryzyk:

  • jeże­li zamó­wie­nie jest opi­sem czar­nej skrzyn­ki tak na praw­dę nie wie­my do dosta­nie­my jako jej realizację,
  • jeże­li auto­rem reali­za­cji jest dostaw­ca, pozo­sta­je mu nie­zby­wal­ne pra­wo do pro­jek­tu tej realizacji.

Dlatego war­to, jako wyma­ga­nie prze­ka­zać pro­jekt tak zwa­nej ?bia­łej skrzyn­ki?, bo zabez­pie­cza to nas przed powyż­szy­mi ryzy­ka­mi. (Wzorzec ana­li­tycz­ny Boundary Control Entity).

Czemu tak bro­nię tej tezy? Zarzuty deve­lo­pe­rów wobec mnie to: wymu­szasz imple­men­ta­cję a to rola pro­jek­tan­ta”. Jest to nie praw­da, bo pro­jek­ty wyma­gań zawie­ra­ją­ce wewnętrz­ną logi­kę to jesz­cze nie imple­men­ta­cja, ale na pew­no jest to ocze­ki­wa­nie kupu­ją­ce­go opro­gra­mo­wa­nie. Gdybym kupo­wał samo­chód nie chciał bym, by mi ktoś powie­dział, że wol­no mi powie­dzieć tyl­ko jak będę do nie­go wsia­dał, wysia­dał i po co, że będę zgod­nie z ogól­ny­mi zasa­da­mi naci­skał peda­ły i mani­pu­lo­wał drąż­kiem zmia­ny bie­gów. Nie! Mam pra­wo i ocho­tą okre­ślić typ sil­ni­ka, żądać ABS i wie­le innych rze­czy. Jeżeli ja nie znam się aż tak na samo­cho­dach popro­szę o pomoc kogoś kto się zna. Jest ryzy­ko? Jest, ale to ja o nim decy­du­ję a nie sprze­daw­ca samochodów!

Jeden z wielu powodów takiego podejścia

Przytłaczająca więk­szość deve­lo­pe­rów, z któ­ry­mi się spo­tka­łem, roz­wią­zu­je pro­blem wydaj­no­ści np. pra­cy z listą pro­duk­tów, podej­mu­jąc kom­pro­mis pomię­dzy szcze­gó­ło­wo­ścią i wier­no­ścią opi­su pro­duk­tu” a wydaj­no­ścią (czas odpo­wie­dzi sys­te­mu) np. pod­czas pre­zen­ta­cji (gene­ro­wa­nia) uprosz­czo­ne­go cen­ni­ka. Większość zna­nych mi deve­lo­pe­rów nie­ste­ty pre­zen­tu­je coś co nazy­wam struk­tu­ral­ny model pro­jek­to­wa­nia opro­gra­mo­wa­nia opar­ty na ane­micz­nym mode­lu dzie­dzi­ny”. Z regu­ły roz­wią­zu­ją oni opi­sa­ny wyżej pro­blem cen­ni­ka, uprasz­cza­jąc opis pro­duk­tu (psu­ją model!), umiesz­cza­ją uprosz­czo­ne dane o pro­duk­cie w mode­lu rela­cyj­nym wraz z resz­tą danych i wal­czą z opty­ma­li­za­cją zapy­tań do tej rela­cyj­nej bazy (uprasz­cza­nie i denormalizacja).

Nie raz pro­wa­dzi to do sytu­acji, w któ­rej opro­gra­mo­wa­nie jest szyb­kie i nieprzydatne”. 

< – jeże­li nie jesteś ana­li­ty­kiem przejdź na koniec artykułu – >

Wygląda to wte­dy np. tak (źr. Fowler CQRS):

Od pra­wej: inter­fejs użyt­kow­ni­ka, model dzie­dzi­ny, baza danych (pod­sys­tem utrwalania).

CQRS

Nie od dzi­siaj zna­ny jest wzo­rzec pro­jek­to­wy, któ­ry radzi sobie z tym pro­ble­mem. Nazywa się CQRS, i tak jest opi­sy­wa­ny przez guru” ana­li­zy i pro­jek­to­wa­nia :), Martina Fowlera:

CQRS stands for Command Query Responsibility Segregation. It’s a pat­tern that I first heard descri­bed by Greg Young. At its heart is a sim­ple notion that you can use a dif­fe­rent model to upda­te infor­ma­tion than the model you use to read infor­ma­tion. This sim­ple notion leads to some pro­fo­und con­se­qu­en­ces for the design of infor­ma­tion sys­tems. (źr. CQRS).

Idea tego pomy­słu na tym, by nie opty­ma­li­zo­wać wydaj­no­ści sys­te­mu meto­dą, nie raz zgni­łe­go, kom­pro­mi­su, a podejść do pro­ble­mu dzie­ląc go na dwa pro­ble­my: zgod­ność mode­lu z rze­czy­wi­sto­ścią i wydaj­ność całe­go sys­te­mu. Pierwszy pro­blem roz­wią­zu­je­my two­rząc wier­ny model struk­tu­ry opi­su­ją­cej pro­duk­ty, dru­gi pro­blem – wydaj­no­ści – roz­wią­zu­je­my two­rząc dru­gi uprosz­czo­ny model pro­duk­tów, do celów szyb­kiej reali­za­cji kil­ku waż­nych zapy­tań” (np. publi­ka­cja on line uprosz­czo­nej posta­ci cennika).

Powyższy dia­gram poka­zu­je: UI (inter­fejs użyt­kow­ni­ka), poka­zu­je menu zgod­ne z opi­sem z przy­pad­ków uży­cia (wyma­ga­nia funk­cjo­nal­ne). Model dzie­dzi­ny (część środ­ko­wa) poka­zu­je ocze­ki­wa­ne roz­wią­za­nie (takie­go żądam w wyma­ga­niach). Polega ono wła­śnie na zapro­jek­to­wa­niu w czę­ści dzie­dzi­no­wej odręb­ne­go mode­lu do zarzą­dza­nia poje­dyn­czy­mi pro­duk­ta­mi i odręb­ne­go do wydaj­ne­go zarzą­dza­nia ich kolek­cją. Owszem, model się nie­co skom­pli­ko­wał (jest nie­co kosz­tow­niej­szy w imple­men­ta­cji), ale jako zama­wia­ją­cy mam to cze­go potrze­bu­ję: wydaj­ny i uży­tecz­ny system.

< – jeże­li nie jesteś ana­li­ty­kiem tu zacznij czy­tać dalej – >

Opisując wyma­ga­nia wyłącz­nie jako czar­ną skrzyn­kę” nie wiem co dosta­nę. Większość deve­lo­pe­rów będzie dąży­ło do uprosz­cze­nia imple­men­ta­cji (ich koszt, nie raz brak wie­dzy) by zaspo­ko­ić na mini­mal­nym pozio­mie wyma­ga­nia opi­sa­ne przy­pad­ka­mi uży­cia. Nie raz klient sły­szy tu musi­my to upro­ścić bo tak się nie da”, a zama­wia­ją­cy, nie mając kom­pe­ten­cji by pole­mi­zo­wać z taką opi­nią, zga­dza się i dostar­czo­ny w efek­cie sys­tem sta­je się zgni­łym kom­pro­mi­sem opar­tym wła­śnie na czar­nej skrzyn­ce” jako spe­cy­fi­ka­cji zamó­wień: dosta­li­śmy dokład­nie to co zamó­wi­li­śmy ale zupeł­nie nie to cze­go napraw­dę potrzebujemy”. 

Tak więc,

nie ma zna­cze­nia fakt, że na pew­no są na ryn­ku deve­lo­pe­rzy zna­ją­cy pro­blem, któ­ry opi­sa­łem i sto­su­ją­cy opi­sa­ne tu roz­wią­za­nie takich pro­ble­mów. Jednak nawet cień ryzy­ka (a jest ono na praw­dę duże), że dosta­nie­my bubla, daje zama­wia­ją­ce­mu pra­wo do szcze­gó­ło­we­go defi­nio­wa­nia wyma­gań jako bia­łej skrzyn­ki”, bo dzię­ki temu zama­wia­ją­cy dosta­nie to cze­go potrze­bu­je a nie tyl­ko to co zamó­wił”.

Dla zain­te­re­so­wa­nych tak­że do pobra­nia książ­ka z MSDN:

The CQRS pat­tern and event sour­cing are not mere sim­pli­stic solu­tions to the pro­blems asso­cia­ted with lar­ge-sca­le, distri­bu­ted sys­tems. By pro­vi­ding you with both a wor­king appli­ca­tion and writ­ten guidan­ce, we expect you’ll be well pre­pa­red to embark on your own CQRS jour­ney. (za CQRS Journey).

Poziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa

[[Analiza wyma­gań]] to temat rze­ka, meto­dy są róż­ne ale nie będę pisał o zna­nych mi, tyl­ko o pew­nym podej­ściu sys­te­mo­wym” zorien­to­wa­nym na mode­le i wzor­ce pro­jek­to­we. Ale po kolei.

Ile mamy poziomów szczegółowości wymagań

Poziom szcze­gó­ło­wo­ści wyma­gań jest tema­tem wie­lu dys­ku­sji, pisa­łem tu już nie raz na ten temat. Tym razem nie o tym, że zarzą­dza­nie tysią­ca­mi deta­li dużych pakie­tów opro­gra­mo­wa­nia jest nie­moż­li­we (i nie­ra­cjo­nal­ne). Tym razem o tym, że sto­so­wa­ne wzor­ców, tu ana­li­tycz­nych i pro­jek­to­wych, poma­ga. Najpierw kil­ka słów o pozio­mach szcze­gó­ło­wo­ści, któ­re stosuję:

  • Najwyższy poziom abs­trak­cji to nazwa­nie celu biz­ne­so­we­go np. chce­my spraw­nie wysta­wiać fak­tu­ry VAT. Jedno zda­nie, bez szcze­gó­łów. To naj­czę­ściej jest cel spon­so­ra pro­jek­tu, któ­rym jest nie­jed­no­krot­nie ktoś z zarządu.
  • Kolejny etap to dopre­cy­zo­wa­nie tego wyma­ga­nia, w tym momen­cie powo­łu­je­my się albo na prze­pi­sy, któ­re opi­su­ją to wyma­ga­nie wystar­cza­ją­co szcze­gó­ło­wo (np. Ustawa o podat­ku VAT i Ustawa o rachun­ko­wo­ści). Jeżeli nie mamy na co się powo­łać posze­rza­my ten opis sami. Tu mamy do czy­nie­nia z usłu­gą sys­te­mu z per­spek­ty­wy zama­wia­ją­ce­go a z [[przy­pad­kiem uży­cia]] z per­spek­ty­wy oprogramowania.
  • Jeżeli opro­gra­mo­wa­nie mia­ło by być wyko­na­ne na zamó­wie­nie, powsta­je dodat­ko­wo uszcze­gó­ła­wia­ją­cy opis każ­dej usłu­gi zawie­ra­ją­cy: dane wej­ścio­we i ocze­ki­wa­ne dane wyj­ścio­we, wzo­ry for­mu­la­rzy do wpro­wa­dza­nia danych i wzór pro­duk­tu (tu wzór fak­tu­ry) oraz sce­na­riusz uży­cia czy­li ocze­ki­wa­nia zama­wia­ją­ce­go co do spo­so­bu pra­cy z przy­szłym pro­gra­mem. Opis taki robi ana­li­tyk-pro­jek­tant a jako źró­dło infor­ma­cji wystę­pu­je eks­pert dzie­dzi­no­wy (czę­sto przy­szły użytkownik).

I tu zaczy­na się cie­kaw­szy ciąg dal­szy. [[Przypadki uży­cia]] to tak zwa­ny [[opis czar­nej skrzyn­ki]], nic nie mówi o logi­ce jaką chce­my odtwo­rzyć, wbu­do­wać do nowe­go opro­gra­mo­wa­nia. Pojawia się waż­ne pyta­nie: jaką wie­dzę” ma mieć to opro­gra­mo­wa­nie? Przypadki uży­cia koja­rzy się z tak zwa­ny­mi Aktorami sys­te­mu. Są to okre­ślo­ne role, któ­re będą wyko­ny­wa­ne przez użyt­kow­ni­ków (np. Specjalista ds. Handlowych może peł­nić rolę fak­tu­rzy­sty – akto­rem jest Fakturzysta). Dopiero po zde­fi­nio­wa­niu wie­dzy jaką ma (ma mieć) Aktor, mamy pod­sta­wy defi­nio­wać wie­dzę” jakiej ocze­ku­je­my do opro­gra­mo­wa­nia (to cze­go nie potra­fi Aktor).

Czarna skrzyn­ka (wyłącz­nie przy­pad­ki uży­cia) jako wyma­ga­nie jest bar­dzo ryzy­kow­nym narzę­dziem, bo nie defi­niu­je tego jaką wie­dzę” ma mieć (odtwa­rzać) to opro­gra­mo­wa­nie. Tu potrzeb­ne jest okre­śle­nie z cze­go będą powsta­wa­ły ocze­ki­wa­ne pro­duk­ty (co jest potrzeb­ne do wysta­wia­nia fak­tu­ry VAT, np. pro­duk­ty i usłu­gi zna fak­tu­rzy­sta czy ma je pod­po­wia­dać oprogramowanie).

Potrzebny jest więc opis logi­ki biz­ne­so­wej, któ­rą chce­my zaim­ple­men­to­wać. Ten opis to sed­no pro­ble­mu pra­cy analityka.

I przy­szła pora na ana­li­zę”. Powszechnie nad­uży­wa­ne sło­wo ana­li­za oznacza:

ana­li­za [gr. anály­sis ?roz­ło­że­nie?, ?roz­biór?], roz­ło­że­nie pew­ne­go obiek­tu na ele­men­ty skła­do­we (czę­ści, cechy, rela­cje); może być zabie­giem fizycz­nym lub czyn­no­ścią myślo­wą; (za Encyklopedia PWN).

Słowo klucz: ele­men­ty skła­do­we”. W meto­dach pra­cy, któ­re sto­su­ję, powyż­sze jest pod­sta­wo­wym narzę­dziem” pra­cy. Ale tu małe wyja­śnie­nie: nie­ste­ty więk­szość spo­ty­ka­nych doku­men­tów ana­li­tycz­nych, nie wie­le ma wspol­ne­go z ana­li­zą. Dlaczego? Skoro ana­li­za to roz­ło­że­nie na ele­men­ty skła­do­we”, to czym jest zapis życzeń i ocze­ki­wań wyar­ty­ku­ło­wa­ny usta­mi pra­cow­ni­ków jakiejś fir­my czy orga­ni­za­cji na spo­tka­niach, w posta­ci tek­stu, tabel lub nie­for­mal­nych obraz­ków ? Jest po pro­stu jakimś spi­sem ale na pew­no nie analizą.

Żeby doko­nać jakiej­kol­wiek ana­li­zy musi­my sobie naj­pierw zde­fi­nio­wać jakieś ele­men­ty skła­do­we”. Analiza zda­nia pole­ga na wyod­ręb­nie­niu słów, koja­rze­niu ich w związ­ki itp. ale począt­kiem jest ist­nie­ją­cy słow­nik i regu­ły gra­ma­tycz­ne. Analiza che­micz­na to roz­ło­że­nie sub­stan­cji na z góry zna­ne pier­wiast­ki (pomi­jam ich odkry­wa­nie). Czym jest ana­li­za biz­ne­so­wa czy ana­li­za wymagań?

Analiza pro­ce­sów biz­ne­so­wych wyma­ga zro­zu­mie­nia tego co dzie­je się w ana­li­zo­wa­nej fir­mie i roz­ło­że­nie tego na pre­de­fi­nio­wa­ne ele­men­ty skła­do­we. W zasa­dzie mamy jeden: pro­ces biz­ne­so­wy. Jego defi­ni­cja okre­śla ato­mo­wy ele­ment takiej ana­li­zy. Jeżeli patrzy­my więc dia­gram zawie­ra­ją­cy pro­sto­ką­ty i linie będą­ce gra­ficz­nym zapi­sem tego co powie­dzia­no”, nie jest to żaden wynik ana­li­zy ani model a jedy­nie obraz­ko­wy zapis opowieści.

Dalej: pro­jek­to­wa­nie opro­gra­mo­wa­nia. Na czym pole­ga ana­li­za obiek­to­wa i pro­jek­to­wa­nie? Po pierw­sze zno­wu potrzeb­ne są ele­men­ty skła­do­we” (przy­po­mi­nam, że ma być ich skoń­czo­na licz­ba, mają zde­fi­nio­wa­ne zna­cze­nia, któ­re się na sie­bie nie nakła­da­ją (nic nie może paso­wać do dwóch defi­ni­cji jed­no­cze­śnie) i pozwa­la­ją, z usta­lo­na dokład­no­ścią, na zbu­do­wa­nie ana­li­zo­wa­nej całości.

Przykład

Opiszę jak moż­na pro­wa­dzić ana­li­zę i budo­wać część wyma­gań o nazwie model dzie­dzi­ny (model logi­ki biznesowej).

Zgodnie z powyż­szym nale­ży zacząć od zde­fi­nio­wa­na sobie skoń­czo­nej licz­by kloc­ków (ich typów). Np. LEGO, moż­na z nich zbu­do­wać wszyst­ko” akcep­tu­jąc pew­ną gra­ni­ce w odtwa­rza­niu uszcze­gó­łów. Typów pod­sta­wo­wych kloc­ków jest kil­ka a jed­nak moż­na z nich zbu­do­wać dom, samo­lot czy kaczkę:

Analiza pole­ga na tym, by real­ny dom lub kacz­kę roz­ło­żyć na skoń­czo­na licz­bę (z regu­ły nie wiel­ką) pro­stych ele­men­tów skła­do­wych, któ­rych słow­ni­kiem” jest posia­da­ny zestaw LEGO. Wynikiem ana­li­zy jest doku­ment” w posta­ci instruk­cji jak zło­żyć domek z LEGO”. Innymi sło­wy, mamy skoń­czo­ną licz­bę ele­men­tów budul­co­wych” ana­li­za pole­ga na zro­zu­mie­niu pro­ble­mu, roz­ło­że­niu go na takie wła­śnie elementy.

Osobiście jestem zwo­len­ni­kiem sto­so­wa­nia [[wzor­ca pro­jek­to­we­go MVC]] oraz sty­lu ana­li­zy i pro­jek­to­wa­nia zwa­ne­go DDD (ang. [[Domain Driven Design]], pro­jek­to­wa­nie ste­ro­wa­ne dzie­dzi­ną sys­te­mu, arty­kuł o DDD). DDD to wzor­ce zarów­no ana­li­tycz­ne jak i pro­jek­to­we. Te wzor­ce to wła­śnie takie ato­mo­we kloc­ki”.

Na eta­pie ana­li­zy, roz­kła­da­my” ana­li­zo­wa­ną fir­mę (jej część) na ele­men­tar­ne skład­ni­ki. W DDD są to poje­dyn­cze encje i ich agre­ga­ty, typy (value-object), usłu­gi, fabry­ki, repo­zy­to­ria. Analiza pole­ga na opi­sa­niu (roz­ło­że­niu jej ) całej logi­ki opro­gra­mo­wa­nia z pomo­cą tych kil­ku stan­dar­do­wych kloc­ków”. Model taki dla deve­lo­pe­ra sta­je się pro­jek­tem, a te kloc­ki wzor­ca­mi projektowymi.

Poniżej zaba­wo­wy” przy­kład takiej analizy.

Aktorem jest użyt­kow­nik. Potrzebny mu jest sys­tem” któ­ry da mu przed­miot wyko­na­ny z kloc­ków LEGO (domek). System cał­ko­wi­cie izo­lu­je Aktora od swo­je­go wnę­trza z pomo­cą Recepcji (View w mode­lu MVC). Wewnątrz mamy zestaw kloc­ków (encje, agre­ga­ty), deli­kwen­ta wie­dzą­ce­go jak wyko­nać domek (usłu­ga) oraz fabry­kę kloc­ków (na bazie wzor­ców two­rzy­my ich tyle ile potrze­bu­je­my, ile zażą­da usługodawca).

Aby zacho­wać wytwo­rzo­ne kloc­ki a tak­że wyni­ki prac czy pół­pro­duk­ty, musi­my mieć pudeł­ko na kloc­ki: repo­zy­to­rium. Nad cało­ścią czu­wa Kontroler, eki­pa ludzi zaj­mu­ją­ca się wszyst­ki­mi poza spe­cja­li­stycz­ny­mi” (poza-dzie­dzi­no­wy­mi) zada­nia­mi. Z racji tego, że takie poję­cia jak wydaj­ność, zaso­by, bez­pie­czeń­stwo itp. są uni­wer­sal­ne, taka eki­pa back offi­ce (skrzyn­ka na zabaw­ki, recep­cja, kon­tro­ler) może zostać wyna­ję­ta nie­mal­że dla każ­dej fir­my bez wzglę­du na bran­że (to się nazy­wa fra­me­work). Specyficzna jest tyl­ko dzie­dzi­na, tu typ klocków.

Tak więc ana­li­za wyma­gań na opro­gra­mo­wa­nie to lista wyma­ga­nych usług. Wymagania na dedy­ko­wa­ne opro­gra­mo­wa­nie zaś to nie jest spi­sa­nie i sor­to­wa­nie ocze­ki­wań. Analiza to roz­ło­że­nie pro­ble­mu (fir­ma klien­ta) na kloc­ki zgod­ne z uzna­ną (uży­wa­ną) meto­dy­ką i wzor­ca­mi. DDD (opis wzor­ców pro­jek­to­wych DDD) to wła­śnie jeden z takich zesta­wów klocków.

Wynikiem ana­li­zy jest model (a nie tyl­ko obra­zek) opi­su­ją­cy jak dzia­ła ana­li­zo­wa­na fir­ma, zbu­do­wa­ny z kloc­ków, tu opi­sa­nych w DDD.

Dla deve­lo­pe­ra taki model jest pro­jek­tem logicz­nym ([[Platform Independent Model w nomen­kla­tu­rze OMG/MDA]]). W efek­cie ana­li­tyk nie tyl­ko zro­zu­miał i udo­ku­men­to­wał pro­blem, ana­li­tyk zapro­jek­to­wał logi­kę biz­ne­so­wą opro­gra­mo­wa­nia, moż­li­wą do bez­po­śred­niej imple­men­ta­cji przez deve­lo­pe­ra (przy zało­że­niu, że sto­su­je meto­dy obiek­to­we i zna uży­te wzor­ce). Taki efekt dają meto­dy obiek­to­we i prag­ma­ty­ki np. DDD. Za to wła­śnie bar­dzo lubię obiek­to­wy para­dyg­mat i DDD: obiek­to­wość” zrów­nu­je wynik ana­li­zy z pro­jek­tem, DDD daje nam zestaw kloc­ków: słow­nik pojęć, zro­zu­mia­ły dla biz­ne­su” i dla deve­lo­pe­ra. DDD to zestaw wzor­ców pozwa­la­ją­cy na dogłęb­ne zro­zu­mie­nie ana­li­zo­wa­ne­go pro­ble­mu i będą­ce zara­zem pro­jek­tem jego implementacji.

Kim więc jest dobry analityk?

Jest to ktoś, kto potra­fi ana­li­zo­wa­ną orga­ni­za­cję roz­ło­żyć na ele­men­ty skła­do­we”. Tymi ele­men­ta­mi są wzor­ce pro­jek­to­we, ele­men­ty sto­so­wa­nej nota­cji. Wynik ana­li­zy to nie rysu­nek”, to model w posta­ci sche­ma­tu blo­ko­we­go (dia­gra­mu), na któ­rym każ­dy ele­ment ma ści­śle okre­ślo­ne znacz­nie, kon­struk­cję i zasa­dy wza­jem­ne­go łącze­nia i oddziaływania.

Analiza Biznesowa to roz­ło­że­nie ana­li­zo­wa­ne­go przed­mio­tu” na skoń­czo­ny zestaw ele­men­tów, któ­ry z okre­ślo­ną dokład­no­ścią zacho­wu­je się tak, jak ana­li­zo­wa­na orga­ni­za­cja. Jeżeli te ele­men­ty skła­do­we mają tak­że swo­je odwzo­ro­wa­nie w kodzie pro­gra­mu, to wynik ana­li­zy sta­je się pro­jek­tem tego oprogramowania.

Więc pozio­my szcze­gó­ło­wo­ści wyma­gań to:

  • cele biz­ne­so­we (pro­duk­ty pro­ce­sów biznesowych)
  • opis usług żąda­nych od opro­gra­mo­wa­nia (tu tak­że for­mat­ki papierowe/ekranowe, przy­pad­ki uży­cia oprogramowania)
  • opis (pro­jekt) wewnętrz­nej logi­ki biz­ne­so­wej (wewnętrz­ne ele­men­ty skła­do­we i sce­na­riu­sze ich współdziałania)

P.S.

Artykuł ma cha­rak­ter badaw­czy”, wszel­kie uwa­gi mile widziane.

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: