Na ten wpis pew­nie wie­lu z Was cze­ka, tak przy­naj­mniej suge­ru­ją listy do mnie i gło­sy na forach, a tak­że poten­cjal­ni klien­ci. Ci, któ­rych nie­ste­ty cza­sem kry­ty­ku­ję, tak­że pew­nie cze­ka­ją. Pokażę na pro­stym przy­kła­dzie, pro­ces od ana­li­zy przez wyma­ga­nia aż do pro­jek­tu dedy­ko­wa­ne­go opro­gra­mo­wa­nia. Całość będzie zgod­na z faza­mi CIM/PIM (www​.omg​.org/​mda). Projekt dzie­dzi­ny, któ­ry powsta­nie będzie speł­niał zasa­dy SOLID pro­jek­to­wa­nia obiek­to­we­go, pro­jek­to­wa­nia przez kom­po­zy­cje (zamiast dzie­dzi­cze­nia) (pole­cam arty­kuł Łukasza Barana) i DDD. Opis doty­czy każ­de­go pro­jek­tu zwią­za­ne­go z opro­gra­mo­wa­niem, tak­że goto­wym np. ERP, CRM, EOD itp.

Korzystałem z opi­su zasad gry w sza­chy zamiesz­czo­ne­go na WIKI:

Zasady gry w sza­chy ? pra­wi­dła regu­lu­ją­ce spo­sób roz­gry­wa­nia par­tii sza­chów. Choć pocho­dze­nie gry nie zosta­ło dokład­nie wyja­śnio­ne, to współ­cze­sne zasa­dy ukształ­to­wa­ły się w śre­dnio­wie­czu. Ewoluowały one do począt­ków XIX wie­ku, kie­dy to osią­gnę­ły wła­ści­wie swą bie­żą­cą postać. W zależ­no­ści od miej­sca zasa­dy gry róż­ni­ły się od sie­bie, współ­cze­śnie za prze­pi­sy gry odpo­wia­da Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się róż­nić w przy­pad­ku róż­nych warian­tów gry, np. dla sza­chów szyb­kich, bły­ska­wicz­nych czy kore­spon­den­cyj­nych. (Zasady gry w sza­chy ? Wikipedia, wol­na ency­klo­pe­dia).

To na co chcę zwró­cić tu uwa­gę w szcze­gól­no­ści, to metafora:

pro­jek­tu­jąc (mode­lu­jąc) opro­gra­mo­wa­nie dla czło­wie­ka, mode­lu­je­my narzę­dzie dla tego czło­wie­ka a nie jego samego.

Swego cza­su pisa­łem, w arty­ku­le o nazy­wa­niu klas, że opro­gra­mo­wa­nie z regu­ły zastę­pu­je dotych­cza­so­we narzę­dzie czło­wie­ka a nie czło­wie­ka jako takie­go. Druga waż­na rzecz: aktor jest rów­no­praw­nym ele­men­tem sys­te­mu (tu sys­te­mem jest orga­ni­za­cja z jej ludź­mi i uży­wa­ny­mi przez nich narzę­dzia­mi). No to zaczynamy.

Cel zamawiającego

Często pro­jekt zaczy­na się od pustej kart­ki, ale nie raz Zamawiający (spon­sor pro­jek­tu) ma już swo­je wyma­ga­nia, z regu­ły jest to jakaś lista w rodzaju:

Z regu­ły z listy wyma­gań (a potra­fi mieć set­ki pozy­cji) nie wyni­ka wprost cel spon­so­ra, a jedy­nie to jak sobie on wyobra­ża roz­wią­za­nie swo­je­go pro­ble­mu (wyobraź­cie sobie powyż­szą listę bez skraj­nej lewej i pra­wej kolum­ny). Wstępne upo­rząd­ko­wa­nie tej listy pozwa­la uznać, że wyma­ga­niem jest wytwo­rze­nie pro­gra­mu do gry w sza­chy na tablet i smart­fon. Pozostałe to pew­ne cechy tego ​„głów­ne­go” wyma­ga­nia biznesowego.

Od dłuż­sze­go cza­su prze­sta­łem na tym eta­pie uży­wać poję­cia wyma­gań funk­cjo­nal­nych i nie­funk­cjo­nal­nych. Na pra­wie każ­dym szko­le­niu i więk­szo­ści pro­jek­tów usły­szy­cie, że to kanon ana­li­zy wyma­gań, a ja – i nie tyl­ko jak poka­zu­je lite­ra­tu­ra- uwa­żam, że sko­ro spon­sor pro­jek­tu (tak zwa­ny biz­nes) z regu­ły nie rozu­mie tych pojęć, to nie nale­ży ich uży­wać w dia­lo­gu z biz­ne­sem na tym eta­pie pro­jek­tu, a tym bar­dziej żądać takie­go podzia­łu. No to kie­dy? Zobaczycie pod koniec :). Nie znam przy­pad­ku, by zama­wia­ją­cy ​„biz­nes” popraw­nie roz­róż­nił te dwie gru­py wyma­gań albo potra­fił same­mu spi­sać ​„przy­pad­ki uży­cia”. A jeże­li jesz­cze zażą­da­my podzia­łu na FURPS to będzie ​„masa­kra”. Czy ma to robić od razu ana­li­tyk? A po co sko­ro Zamawiający i tak tego nie zwe­ry­fi­ku­je a jest adre­sa­tem tego doku­men­tu? Na tym eta­pie, powyż­sza lista, moż­na poprze­stać na uzna­niu powyż­szej listy za ​„wyma­ga­nia biz­ne­so­we” (czy­li te, któ­re wprost for­mu­łu­je ​„biz­nes”).

Tak więc na tym eta­pie war­to raczej poświę­cić czas, by zro­zu­mieć cel Zamawiającego, wywia­dy pozwa­la­ją na stwo­rze­nie obra­zu celu biz­ne­so­we­go i tak zwa­nej moty­wa­cji biznesowej:

Powyższe bar­dzo poma­ga w pro­jek­cie gdyż po pierw­sze, sta­no­wi przy­sło­wio­we świa­teł­ko w tune­lu, po dru­gie każ­de szcze­gó­ło­we wyma­ga­nie, jeże­li ma sta­no­wić ele­ment zakre­su pro­jek­tu, musi wspie­rać cele biz­ne­so­we. To pod­sta­wo­we narzę­dzie pano­wa­nia nad zakre­sem projektu.

W naszym przy­pad­ku, w sfe­rze two­rze­nia opro­gra­mo­wa­nia, pozo­sta­je Opracowanie pro­gra­mu do gry w sza­chy (tak nazy­wa to spon­sor pro­jek­tu! cie­ka­we co powsta­nie). Nadal jed­nak kry­je się tu pew­na nie­wie­dza: co to zna­czy ​„do gry w szachy”?

Model pojęciowy – zrozumieć problem i cel projektu

Warto na samym począt­ku opra­co­wać słow­nik pojęć i reguł biz­ne­so­wych, któ­re tak­że sta­ną się wyma­ga­niem biz­ne­so­wym. Tak, słow­nik i regu­ły są wyma­ga­niem i to bar­dzo waż­nym. Najpierw model pojęciowy:

Nie jest to abso­lut­nie żaden model dzie­dzi­ny. To dia­gram klas UML (albo SBVR) poka­zu­ją­cy zde­fi­nio­wa­ne poję­cia biz­ne­so­we oraz fak­ty jakie łączą je w jeden kon­tekst. Nie jest to obiek­to­wy model, a ter­mi­ny słow­ni­ko­we. Budowanie biz­ne­so­we­go słow­ni­ka pojęć dla wie­lu ana­li­ty­ków jest gehen­ną budo­wa­nia listy dzie­sią­tek i setek defi­ni­cji. Otóż błę­dem jest zali­cza­nie do tego słow­ni­ka wszyst­kich pojęć zwią­za­nych z dzie­dzi­ną (bran­ża itp.) orga­ni­za­cji Zamawiającego, to pro­sta dro­ga do prze­pi­sa­nia słow­ni­ka np. j.polskiego. Interesują nas wyłącz­nie te poję­cie, któ­re sta­no­wią spe­cy­fi­kę pro­ble­mu a nie wszyst­kie z nim zwią­za­ne. Narzędziem do budo­wy takie­go słow­ni­ka (mode­lu poję­cio­we­go, prze­strze­ni nazw) są fak­ty, do słow­ni­ka biz­ne­so­we­go doda­je­my wyłącz­nie te poję­cia, któ­re są zwią­za­ne ze sobą fak­ta­mi (zda­rze­nia) z ana­li­zo­wa­nej dzie­dzi­ny i celu pro­jek­tu. Wtedy pojęć na liście będzie mniej pojęć i będą to tyl­ko te, któ­re słu­żą zacho­wa­niu jed­no­znacz­no­ści doku­men­ta­cji pro­jek­tu, a więc i całej komu­ni­ka­cji w projekcie.

Model procesu biznesowego – zrozumieć co i po co jest robione

Kolejne roz­mo­wy i opis pro­ce­su, jaki reali­zu­je (będzie reali­zo­wał) użyt­kow­nik przy­szłe­go pro­gra­mu. Nie jest to pro­ste wbrew pozo­rom, bo oka­zu­je się, że nie cho­dzi o grę jaką zna­my z kom­pu­te­rów, a o wir­tu­al­ną plan­szę, co widać z procesu:

Powyższy pro­ces (jego model, nota­cja BPMN) może budzić począt­ko­wo zdzi­wie­nie. Ale przy­po­mi­nam, że pro­ces ma (powi­nien mieć) swój kon­tekst, jest nim tu korzy­sta­nie z plan­szy do gry w sza­chy. Dlaczego nie ma np. dwóch gra­czy na prze­mian prze­sta­wia­ją­cych pion­ki? To ​„osta­tecz­ny model”, doj­ście do nie­go to efekt testów (tak, mode­le testu­je­my żeby wyka­zać ich popraw­ność!). Jakie to testy? Ano w sza­chy może grać jeden czło­wiek sam ze sobą, może grać dwóch prze­ciw­ko sobie, może grać jeden prze­ciw­ko wie­lu na wie­lu sza­chow­ni­cach (gra symul­ta­nicz­na), ten model musi ​„być dobry” w każ­dym z tych kon­tek­stów – testów (przy­pad­ków) i taki jest (jak ktoś ma wąt­pli­wo­ści niech nary­su­je model pro­ce­su gry przez dwóch gra­czy a potem spraw­dzi czy model ten będzie popraw­ny dla ​„sam z sobą” i symultany).

Z ana­li­zy widać, że gra­ją­cy sami prze­miesz­cza­ją bier­ki. W tym miej­scu war­to zazna­czyć, że ​„odkry­wa­my” zna­cze­nie wyma­ga­nia Kontrola reguł gry: nie jest to pla­no­wa­ne w pierw­szej fazie pro­jek­tu a pro­gram ma jed­nak do cze­goś słu­żyć. Jak widać, w pierw­szej fazie sta­no­wi sobą tyl­ko wir­tu­al­ną plan­szę, ma zastą­pić chy­bo­tli­wą na kola­nach plan­szę i roz­sy­pu­ją­ce się po pod­ło­dze bier­ki. Użyte regu­ły biz­ne­so­we (lista osob­no) ogra­ni­cza­ją jedy­nie poło­że­nie bie­rek, narzu­ca­ją (symu­lu­ją) fizycz­ne ogra­ni­cze­nia plan­szy. Proces nale­ży dopro­wa­dzić do posta­ci opi­su­ją­cej fak­tycz­ne zacho­wa­nie (czyn­no­ści i ich cele) użyt­kow­ni­ków. Użytkownik (każ­dy) ma jeden i ten sam cel: prze­sta­wie­nie bier­ki (to czy taki ruch ma sens oce­nia on a nie plansza).

Zaznaczamy na mode­lu pro­ce­su czyn­no­ści wcho­dzą­ce w zakres pro­jek­tu (tu są to wszyst­kie), budu­je­my dia­gram przy­pad­ków użycia:

Na dia­gra­mie doda­łem regu­ły biz­ne­so­we (ele­men­ty z poza nota­cji UML/przypadki uży­cia) by poka­zać, że są one wyma­ga­niem, będą wbu­do­wa­ne w pro­gram (zde­cy­du­ją o jego zacho­wa­niu). W real­nych pro­jek­tach, regu­ły biz­ne­so­we nie są tak umiesz­cza­ne, sta­no­wią osob­ną specyfikację.

Druga uwa­ga, na tym etapie:

dopre­cy­zo­wu­je­my i sepa­ru­je­my odpo­wie­dzial­ność pro­gra­mu i akto­ra (coś cze­go pra­wie nikt nie robi w projektach!).

Tu widać, że regu­ły regu­lu­ją­ce fizycz­ne moż­li­wo­ści sza­chow­ni­cy (pro­gram nie powi­nien pozwa­lać na to, na co nie pozwa­la praw­dzi­wa sza­chow­ni­ca) to odpo­wie­dzial­ność two­rzo­ne­go pro­gra­mu, zasa­dy gry w sza­chy (ich zna­jo­mość i prze­strze­ga­nie) to odpo­wie­dzial­ność Gracza (pro­gram w pierw­szym eta­pie two­rze­nia nie będzie tego więc kon­tro­lo­wał). Zwracam tu uwa­gę, że sza­chow­ni­ca nie zna zasad gry w szachy! 🙂

Na tym eta­pie moż­na utwo­rzyć zapy­ta­nie do firm, poszu­ku­jąc goto­we­go opro­gra­mo­wa­nia na ryn­ku. Dysponujemy przy­pad­ka­mi uży­cia (wyma­ga­nia funk­cjo­nal­ne to usłu­gi apli­ka­cji), regu­ła­mi biz­ne­so­wy­mi (wyma­ga­nia dzie­dzi­no­we) oraz upo­rząd­ko­wa­ną (ewen­tu­al­nie prze­fil­tro­wa­ną na oko­licz­ność zgod­no­ści z cela­mi biz­ne­so­wy­mi) listą wyma­gań biz­ne­so­wych, któ­re tu mogą peł­nić rolę wyma­gań poza-funkcjonalnych.

Jeżeli na goto­we, speł­nia­ją­ce nasze wyma­ga­nia opro­gra­mo­wa­nie (modu­ły) nie ma szans, pro­jek­tu­je­my je czy­li spe­cy­fi­ku­je­my to, co chce­my dostać od developera.

Jak to się ma do systemów biznesowych ERP i nie tylko ERP?

Kluczowym ele­men­tem każ­dej takiej ana­li­zy jest okre­śle­nie celu spon­so­ra pro­jek­tu, nazwa­nie pro­ble­mu. W tym przy­pad­ku (opi­sa­na sza­chow­ni­ca) istot­ne jest wykry­cie, że celem spon­so­ra jest opra­co­wa­nie wir­tu­al­nej sza­chow­ni­cy a nie ​„kom­pu­te­ro­wej gry w sza­chy” (co na począt­ku, z tre­ści wyma­gań, nie było oczy­wi­ste). Dodanie do sza­chow­ni­cy kon­tro­li reguł gdy to gadżet (ele­ment auto­ma­ty­za­cji, moż­li­wy do póź­niej­sze­go wdro­że­nia). Cel ana­li­zy poprze­dza­ją­cej zakup, to narzę­dzie do nazwa­nia roz­wią­za­nia, a kon­kret­nie wyspe­cy­fi­ko­wa­nia wyma­gań jakie sta­wia­my przed tym roz­wią­za­niem. Takie wyma­ga­nia okre­ślo­no tu na eta­pie przy­pad­ków uży­cia i reguł biz­ne­so­wych. Duże pro­jek­ty, to pew­na licz­ba takich ele­men­tar­nych (jak ten tu opi­sa­ny) pro­ble­mów. Otrzymamy więk­szą spe­cy­fi­ka­cję takich wyma­gań, prak­ty­ka poka­zu­je, że część z nich (typo­wo ok. 80% – zno­wu zasa­da Pareto) uda się zre­ali­zo­wać z pomo­cą dostęp­ne­go na ryn­ku opro­gra­mo­wa­nia, pozo­sta­łe 20% albo zosta­nie zapro­jek­to­wa­ne i zbu­do­wa­ne jako dedy­ko­wa­ne modu­ły (kasto­mi­za­cja goto­we­go jest odra­dza­na) meto­dą tu opi­sa­ną, albo zosta­ną zanie­cha­ne (nie budu­ją war­to­ści uza­sad­nia­ją­cej taką inwestycję).

<Od tego momen­tu powsta­je doku­men­ta­cja tech­nicz­na, jest to wyma­ga­nie w sto­sun­ku do deve­lo­pe­ra. Zamawiający usłu­gę otrzy­mu­je ten doku­ment, ale nie jest jego adre­sa­tem (nie musi go rozu­mieć). Wartość doda­na tego doku­men­tu: prze­te­sto­wa­ny pro­jekt pozwa­la napi­sać opro­gra­mo­wa­nie ​„za pierw­szym razem”, pro­jekt jako dzie­ło ana­li­ty­ka pro­jek­tan­ta dzia­ła­ją­ce­go na zle­ce­nie Zamawiającego przej­mu­je Zamawiający, deve­lo­per nie jest auto­rem pro­jek­tu więc nie ma żad­nych praw do opro­gra­mo­wa­nia jakie wytwo­rzy na bazie zle­ce­nia (two­rzy tak zwa­ny utwór zależ­ny), w związ­ku z tym nie może tak napi­sa­ne­go opro­gra­mo­wa­nia sprze­da­wać na ryn­ku np. kon­ku­ren­tom Zamawiającego, prze­czy­taj wię­cej o pra­wach autor­skich i nad­uży­ciach firm pro­gra­mi­stycz­nych>.

Pora na model dziedziny – dedykowane rozwiązanie

Teraz wiel­ka kość nie­zgo­dy :). Ale po kolei.

Do tej pory nadal nie wia­do­mo ​„jak to ma dzia­łać”. Wiemy tyl­ko do cze­go posłuży.

To jest ten moment, w któ­rym deve­lo­per nadal nie­ma cze­go wyce­niać, nadal nie wie­my co dosta­nie­my, zło­że­nie zamó­wie­nia na dedy­ko­wa­ne opro­gra­mo­wa­nie z powyż­szą doku­men­ta­cją jest wiel­kim ryzy­kiem, moż­li­we jest, że mimo powyż­szej doku­men­ta­cji, dostaw­ca po wie­lu pró­bach (po ter­mi­nie i więk­szym kosz­tem) dostar­czy pro­dukt, może przy­dat­ny ale kosz­tow­ny w roz­bu­do­wie a nie raz wyma­ga­ją­cy grun­tow­nej prze­rób­ki przy każ­dej nowej funk­cjo­nal­no­ści (prak­ty­ka: 100% dotych­czas pyta­nych deve­lo­pe­rów i stu­den­tów, umie­ści­ło by regu­ły prze­miesz­cza­nia bie­rek w ope­ra­cjach klas repre­zen­tu­ją­cych te bier­ki, a to naj­gor­szy pomysł). 

Poniższy model wyja­wia ​„zbyt dużo” jak na ten etap pro­jek­tu ale jakoś musia­łem to pokazać:

Modele jak powyż­szy spo­tka­cie na szczę­ście, np. w książ­kach o obiek­to­wych wzor­cach pro­jek­to­wych. Jak widać nie jest to ​„model dzie­dzi­ny”, jaki moż­na zoba­czyć na stro­nach wie­lu blo­gów ana­li­ty­ków czy mate­ria­łów szko­le­nio­wych (nawet uczel­nia­nych 🙁 ). Tam spo­tka­cie raczej mode­le poję­cio­we lub UML’owe atra­py mode­li danych. Co naj­gor­sze, nie raz te mode­le są nor­ma­li­zo­wa­ne (współ­dzie­lo­ne połą­cze­nia klas w celu uni­ka­nia redun­dan­cji co z meto­da­mi obiek­to­wy­mi nie ma nic wspól­ne­go, żeby nie powie­dzieć kłó­ci się z nimi).

[tu kolej­ny przy­kład na stro­nie Uniwersytetu Warszawskiego, autor tuto­ria­la poka­zu­je kla­sy poję­cio­we gry w mono­pol, na tym eta­pie nie jest źle, nie wiem po co te liczeb­no­ści (kto ma je kon­tro­lo­wać), ale nagle poja­wia się poję­cie ​„czę­ścio­wy model dzie­dzi­ny” i widzi­my ten sam model poję­cio­wy (!) napa­ko­wa­ny atry­bu­ta­mi, co cie­ka­we nadal model nie zawie­ra żad­nych ope­ra­cji czy­li prak­tycz­nie ten ​„sys­tem” nie dzia­ła! To kla­sycz­ny błąd pole­ga­ją­cy na pro­jek­to­wa­niu struk­tu­ral­nej bazy danych z masą atry­bu­tów bez żad­nej wie­dzy o tym «co się dzie­je i dla­cze­go”. Klasyczny [[ane­micz­ny model dzie­dzi­ny]]. Zaryzykuje tezę, że żaden sen­sow­nie dzia­ła­ją­cy pro­gram symu­lu­ją­cy grę w mono­pol nie będzie miał takie­go mode­lu dzie­dzi­ny. Można mnie teraz zlin­czo­wać, ale odra­dzam ten materiał].

Model na powyż­szym, moim, dia­gra­mie to model dzie­dzi­ny sys­te­mu, czy­li kom­po­nent M wzor­ca MVC. Jak powsta­wał? Najpierw ziden­ty­fi­ko­wa­no kla­sy, któ­re za ​„coś” odpo­wia­da­ją. Powstały kla­sy Plansza i Bierka, dru­ga odpo­wia­da za wie­dzę o ist­nie­niu każ­dej bier­ki, czym ona jest i jej poło­że­niu. Plansza odpo­wia­da za utrzy­ma­nie kolek­cji Bierek jed­nej gry (par­tii) i zobra­zo­wa­nie zmian ich poło­że­nia. Następnie powsta­ła kla­sa FabrykaPlansz, odpo­wia­da za two­rze­nie nowych ​„dzie­wi­czych” plansz z bier­ka­mi usta­wio­ny­mi w poło­że­niach ini­cju­ją­cych grę. Mamy już plan­sze i mecha­nizm two­rze­nia nowych. Przychodzi pora na ​„obsłu­gę” przy­pad­ków uży­cia. Dobrą prak­ty­ką jest sepa­ro­wa­nie klas repre­zen­tu­ją­cych byty dzie­dzi­no­we od tego w jaki spo­sób są wyko­rzy­sty­wa­ne (peł­nią bier­ną rolę, bier­ki same się nie prze­su­wa­ją!). Ma to dwie pod­sta­wo­we zale­ty: nie prze­cią­ża­my klas odpo­wie­dzial­no­ścią oraz zacho­wu­je­my klu­czo­wą potrze­bę: moż­li­wość łatwe­go roz­wi­ja­nia apli­ka­cji bez prze­bu­do­wy (tak zwa­ne [[open clo­sed prin­ci­ple]]). Jak to dzia­ła? Wyobraźmy sobie, że nie ma jesz­cze żół­tej kla­sy KontrolerRegułGryWSzachy. Wydawało by się, że kla­sa PrzemieszczanieBierki jest zbęd­na (kla­sa Plansza ma wszyst­kie jej ope­ra­cje). Po co to?

Zasada ​„nigdy nie mów nigdy” ozna­cza, że żaden pro­gram nie jest skoń­czo­ny. Innymi sło­wy powin­no być moż­li­we roz­sze­rza­nie jego funk­cjo­nal­no­ści bez prze­bu­do­wy. W wyma­ga­niach poja­wi­ło się ​„Kontrola reguł gry”. Wyobraźmy sobie, że wyma­ga­nie to ​„wyska­ku­je” jak kró­lik z kape­lu­sza, dopie­ro po odda­niu pro­gra­mu do użyt­ku (czy­li nor­ma :)). Gdyby nie było kla­sy PrzemieszczanieBierki, zapew­ne ​„odpo­wie­dzial­ność” ta (regu­ły gry) wylą­do­wa­ła by w Klasie Plansza lub Bierki zosta­ły by obcią­żo­ne wie­dzą o tym jak wol­no je prze­sta­wiać (to naj­gor­szy pomysł). Klasy zaczy­na­ją puch­nąć i ule­ga roz­my­ciu ich pier­wot­na logika. 

Zaprojektowanie od razu, pozor­nie nie­po­trzeb­nej kla­sy PrzemieszczanieBierki, izo­lu­je logi­kę gry w sza­chy (pier­wot­nie odpo­wia­da za nią aktor) od plan­szy, któ­ra tej logi­ki nie powin­na znać (bier­ki ​„są prze­su­wa­ne” a nie ​„się prze­su­wa­ją”). Nowe wyma­ga­nie Obsługa logi­ki gdy w sza­chy, to nowa kla­sa KontrolerRegułGryWSzachy ​„pod­pi­na­my” do kla­sy Przemieszczanie bier­ki, bo to natu­ral­ne: do tej pory te ruchy kon­tro­lo­wał gracz, teraz gracz jest kon­tro­lo­wa­ny (a raczej ogra­ni­cza­ny) regu­ła­mi, któ­re zna ​„ktoś” a nie plan­sza (ta nie powin­na nigdy być tym obcią­żo­na). Po dru­gie zmia­na reguł gry to inge­ren­cja w kla­sę KontrolerReguł, gdy­by­śmy obcią­ży­li tą wie­dzą plan­sze i bier­ki, prze­rób­ki wyma­ga­ła­by znacz­na część pro­gra­mu (nie­mal­że cały).

Kolejna korzyść: kom­po­nent View ma pro­sty pro­blem: dla jed­ne­go przy­pad­ku wywo­łu­je jed­ną kla­sę i ta kon­tro­lu­je cały sce­na­riusz. Nie obcią­ża­my kom­po­nen­tu View wie­dzą o szcze­gó­łach dzie­dzi­ny, ukry­wa­my ją przed nim (her­me­ty­za­cja). Jakakolwiek zmia­na zacho­wa­nia wymu­szo­na np. zmia­ną table­tu na smart­fon itp. nie prze­nie­sie się poza kla­sę PrzemieszczanieBierki.

Mity. Model dzie­dzi­ny nie powi­nien zawie­rać logi­ki biz­ne­so­wej, ta jest ele­men­tem kon­tro­le­ra. Jak widać jest to bzdu­ra. Komponent Model Dziedziny powi­nien pozwa­lać na wyko­na­nie wszyst­kich testów funk­cjo­nal­no­ści bo taka jest jego rola! Zaczynamy mode­lo­wać kla­sy od ich atry­bu­tów. Bzdura. Klasy mają odpo­wie­dzial­ność czy­li ope­ra­cje, któ­re ​„coś potra­fią” i od tego zaczy­na­my. Atrybuty powsta­ją na samym koń­cu jako te ele­men­ty, któ­re ​„coś zapa­mię­tu­ją” w związ­ku z reali­zo­wa­ny­mi zada­nia­mi (a zada­nia pro­jek­tu­je­my naj­pierw). Na eta­pie ana­li­zy nale­ży zapro­jek­to­wać model bazy danych. Bzdura. To imple­men­ta­cja, któ­ra jest zada­niem wyko­naw­cy, to on podej­mie decy­zje jak obsłu­ży utrwa­la­nie danych, a to nie ma nic wspól­ne­go z mode­lem i mode­lo­wa­niem obiektowym.

Skąd te operacje w klasach

Mając model przy­pad­ków uży­cia budu­je­my dla każ­de­go z nich sce­na­riusz. Opisuje on dia­log akto­ra z opro­gra­mo­wa­niem. Kolejny krok to test pro­jek­tu mode­lu dzie­dzi­ny: opra­co­wa­ny wstęp­ny model (same kla­sy bez ope­ra­cji i atry­bu­tów) zosta­je uży­ty do reali­za­cji sce­na­riu­szy przy­pad­ków uży­cia. Nie ma więk­sze­go sen­su ​„wymy­śla­nie” ope­ra­cji klas ​„na zapas” bo nie mamy żad­nych prze­sła­nek do ich two­rze­nia. Wiemy, że bier­ka ma reago­wać na żąda­nie prze­miesz­cze­nia ale treść tego żąda­nia to sku­tek dia­lo­gu jaki zaist­nie­je. Wymyślanie ​„na zapas” (burza mózgów nad atry­bu­ta­mi i ope­ra­cja­mi klas to naj­gor­szy spo­sób) koń­czy się z regu­ły masą nad­mia­ro­wych i masą nie­prze­wi­dzia­nych atry­bu­tów i ope­ra­cji. Znacznie lep­sza jest symu­la­cja dia­lo­gu. Robimy to z pomo­cą opra­co­wa­nych sce­na­riu­szy przy­pad­ków uży­cia i roz­pi­sa­nia ich na model dziedziny:

Inicjacja gry:

Przemieszczenie bier­ki:

Odkryjemy przy oka­zji, że Inicjacja gry dosko­na­le nada­je się na przy­wo­ły­wa­nie z Repozytorium par­tii prze­rwa­nych (jest takie wyma­ga­nie!). Teraz dopie­ro ​„obda­rzy­my” nasze kla­sy ope­ra­cja­mi, są one natu­ral­ną kon­se­kwen­cją tego dia­lo­gu, a pamię­ta­my, że para­dyg­mat obiek­to­wy to ​„współ­pra­cu­ją­ce obiek­ty” a nie jakieś encje i funkcje.

Atrybuty. Teraz dopie­ro, na samym koń­cu, poja­wia się potrze­ba ich ist­nie­nia, są para­me­tra­mi wywo­łań. Teraz wie­my jakie powin­ny one być. Kolejną dobrą prak­ty­ką jest sto­so­wa­nie typów zło­żo­nych (albo w DDD valueObjects). Np. poło­że­nie bier­ki to w tym pro­jek­cie nie dwa pro­ste (pri­mi­ti­ve) atry­bu­ty wiersz i kolum­na, a jeden atry­but PoleSzachownicy. Co osią­ga­my? Po pierw­sze kon­tro­lu­je­my w jed­nym miej­scu jego popraw­ność (poda­na para opi­su­ją­ca poło­że­nie, musi wska­zy­wać popraw­ne pole miesz­czą­ce się w obsza­rze sza­chow­ni­cy). Po dru­gie ewen­tu­al­na zmia­na np. wymia­rów sza­chow­ni­cy będzie wyma­ga­ła wyłącz­nie zmia­ny dekla­ra­cji tej kla­sy, a nie wszyst­kich innych ope­ru­ją­cych współ­rzęd­ny­mi pola sza­chow­ni­cy wywo­łań. Wyobraźmy sobie jaką pra­cę nale­ża­ło by wyko­nać by dosto­so­wać pro­gram do gry w sza­chy hek­sa­go­nal­ne, w moim przy­kła­dzie były by to wręcz kosme­tycz­ne popraw­ki a nie refak­to­ring całej aplikacji. 

Stany. Może nam się przy­tra­fić kla­sa mają­ca tak­że sta­ny. Stan to pewien szcze­gól­ny atry­but kla­sy, jego zmia­na rzą­dzi się wła­sny­mi pra­wa­mi, (regu­ła­mi), doku­men­tu­je­my to mode­lem maszy­ny sta­no­wej. Tu jest to nasza Bierka:

Potrzeba ist­nie­nia tego sta­tu­su wyni­ka ze sce­na­riu­sza ich prze­miesz­cza­nia: naj­pierw infor­mu­je­my Plansze, któ­ra bier­ka będzie prze­miesz­cza­na (a kon­kret­nie jej poło­że­nie), dru­gi krok to pole­ce­nie o nowym poło­że­niu. Plansza wie, że doty­czy ono tyl­ko tej jed­nej bier­ki o sta­tu­sie ​„prze­miesz­cza­na”. Dzięki temu, w celu wyda­nia pole­ce­nia prze­miesz­cze­nia bier­ki, nie musi­my ope­ro­wać ​„robo­czą” parą danych ​„pole począt­ko­we i pole koń­co­we” i któ­ra to bier­ka, co skom­pli­ko­wa­ło by pro­gram. Po pro­tu naj­pierw poka­zu­je­my kon­kret­ną bier­kę (ona jest na jakimś polu) a potem pole na któ­re ma się prze­mie­ścić. To dwa pro­ste pole­ce­nia z mini­mal­ną ilo­ścią para­me­trów. Po dru­gie dokład­nie odwzo­ro­wu­je to co robi gracz. (gdy­by w przy­szło­ści ktoś zażą­dał funk­cjo­nal­no­ści doku­men­to­wa­nia par­tii, wystar­czy te pole­ce­nia rejestrować).

Dobrze zapro­jek­to­wa­nie opro­gra­mo­wa­nie cechu­je się tym, że koszt kolej­nych nowych funk­cjo­nal­no­ści jest porów­ny­wal­ny i względ­nie sta­ły. Widać to na przy­kła­dzie ​„doda­nia” funk­cjo­nal­no­ści ​„Kontrola reguł gry”.

Zarządzanie wymaganiami

Mamy tu do czy­nie­nia z wie­lo­ma mode­la­mi, każ­dy ma swo­ją role do ode­gra­nia, do tego nad nami ​„wiszą” wyma­ga­nia. Warto zarzą­dzać nimi, postę­pem ich reali­za­cji oraz kon­tro­lo­wać wyma­ga­nia ​„sie­ro­ty” (nie uży­wa­ne po wdro­że­niu a wyma­ga­ne funk­cje pro­gra­mu) i wyma­ga­nia ​„uta­jo­ne” (odkry­wa­my je na eta­pie imple­men­ta­cji i wdro­że­nia jako bra­ku­ją­ce a wyma­ga­ne jed­nak przez użyt­kow­ni­ków zacho­wa­nia i cechy). Do tego celu słu­ży model wyma­gań wyko­na­ny w nota­cji SysML:

Wymagania otrzy­ma­ne od Zamawiającego naj­pierw porząd­ku­je­my w ich hie­rar­chię, potem wska­zu­je­my jak są reali­zo­wa­ne. Takie ​„śla­do­wa­nie” uła­twia pano­wa­nie nad zakre­sem pro­jek­tu, pozwa­la tak­że na zarzą­dza­nie ich realizacją.

Teraz widać tak­że, że podział na wyma­ga­nia funk­cjo­nal­ne i pozo­sta­łe ​„sam się doko­nał”, znacz­nie lepiej niż domy­sły Zamawiającego na począt­ku pro­jek­tu (dla któ­re­go są to zresz­tą słusz­nie rów­no­praw­ne wymagania).

Ten pro­jekt zapew­ne moż­na jesz­cze ulep­szyć, ale myślę (mam nadzie­ję), że już na tym eta­pie poka­zu­je zale­ty OOAD i róż­ni­ce w sto­sun­ku do metod struk­tu­ral­nych. Pokazuje tak­że w prak­ty­ce dość boga­ty model kom­pe­ten­cji Analityka Biznesowego wg. IIBA.

Analiza wpływu – narzędzia CASE

Nie raz w więk­szym pro­jek­cie nie­oce­nio­ne są moż­li­wo­ści kon­tro­li całe­go pro­jek­tu w posta­ci ana­li­zy wpły­wu jed­nych ele­men­tów pro­jek­tu na pozo­sta­łe, oraz kon­tro­la tak zwa­nych sie­rot, czy­li nie­uży­wa­nych a zapro­jek­to­wa­nych ele­men­tów. Efekt takiej ana­li­zy może wyglą­dać tak (tu nie ma sierot ;)):

Wykonanie takiej ana­li­zy ręcz­nie to ogrom­na pra­co­chłon­ność, podob­nie zresz­tą jak śla­do­wa­nie (wywo­dze­nie jed­nych mode­li z dru­gich meto­dą top-down, od ogó­łu do szcze­gó­łu) całe­go pro­jek­tu. Dlatego nie­daw­no pisa­łem, że pro­wa­dze­nie takich pro­jek­tów z pomo­cą zwy­kłe­go opro­gra­mo­wa­nia np. biu­ro­we­go, zdjęć tablic zapi­sa­nych notat­ka­mi i żół­ty­mi kar­tecz­ka­mi, itp. to meto­dy rodem ze śre­dnio­wiecz­nych manu­fak­tur. Bez narzę­dzi CASE takie pro­jek­ty są bar­dzo pra­co­chłon­ne i nara­żo­ne na ogrom błę­dów.

Na zakoń­cze­nie

Analiza i pro­jek­to­wa­nie obiek­to­we (ang. OOAD) to nie­ja­ko ​„imple­men­ta­cja” kla­sycz­nej ana­li­zy sys­te­mo­wej. Nie ma ona nic wspól­ne­go ze struk­tu­ral­ny­mi meto­da­mi ana­li­zy i pro­jek­to­wa­nia opro­gra­mo­wa­nia (cze­go wie­lu zda­je się nadal nie dostrze­gać). Wygląda na to, że jest znacz­nie trud­niej­sza ale prak­ty­ka poka­zu­je, że daje znacz­nie lep­sze rezul­ta­ty. Języki obiek­to­we to nie jakieś tam nowa nazwa kla­sy na pod­pro­gra­my, a zupeł­nie nowy para­dyg­mat pro­gra­mo­wa­nia: musi być poprze­dza­ny ana­li­zą i pro­jek­tem. Jego zale­tą jest to, że pozwa­la na odwzo­ro­wy­wa­nie, nie­mal­że jak w grze, ana­li­zo­wa­ne­go i roz­wią­zy­wa­ne­go pro­ble­mu, pozwa­la na prze­te­sto­wa­nie pomy­słu na pro­gram zanim powsta­nie choć jed­na linia pro­gra­mu. Problemem i wyzwa­niem na eta­pie ana­li­zy jest zro­zu­mie­nie pro­ble­mu, co mam nadzie­ję pokazałem.

Niestety wie­le ana­liz doku­men­to­wa­nych z uży­ciem nota­cji UML nie ma wie­le wspól­ne­go z OOAD, sta­no­wią echa struk­tu­ral­nych metod ana­li­zy i pro­jek­to­wa­nia, sto­so­wa­nia baz rela­cyj­nych już na eta­pie ana­li­zy (obiek­to­we narzę­dzia nie czy­nią pro­jek­tów obiek­to­wy­mi). Niestety błę­dy te popeł­nia­ją nawet wykła­dow­cy wie­lu uczel­ni i kursów.

Bardziej roz­bu­do­wa­ny pro­jekt, wraz z fil­mem o jego powsta­wa­niu tu: Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE ? przy­kła­do­wy projekt

Koszty

Są zależ­nie od skła­du zespo­łu deve­lo­pe­ra i meto­dy pra­cy. Ale zespół pro­gra­mi­sta i tester, powyż­sze, robio­ne meto­dą ​„agi­le”: czy­li user sto­ry i od razu burza mózgów, ​„wsa­dze­nie” do fra­me­wor­ka, kodo­wa­nie, testy, pro­to­typ, testy u zama­wia­ją­ce­go i kil­ka takich ite­ra­cji ver­sus powyż­sze (to pra­ca ana­li­ty­ka tu moja, na jeden dzień). Porównanie kosz­tu musi każ­dy zro­bić sam, ale z moje­go doświad­cze­nia wyni­ka, że doj­ście do tego eta­pu (prze­my­śla­na i spraw­dzo­na logi­ka sys­te­mu) meto­da­mi burz mózgów i pro­to­ty­po­wa­nia – kolej­ne wer­sje kodu dla Klienta – to kil­ku­krot­nie więk­szy koszt i czas w porów­na­niu z opra­co­wa­niem powyż­szej ana­li­zy i pro­jek­tu i wyko­na­nia popraw­ne­go opro­gra­mo­wa­nia za nie­mal­że pierw­szym podej­ściem na bazie prze­my­śla­ne­go pro­jek­tu (pisze na bazie wyko­na­nych pro­jek­tów, ale pro­por­cje mogą być inne z innym zespo­łem). Na koniec sta­ty­sty­ka pew­ne­go deve­lo­pe­ra (pole­cam cały wątek):

I star­ted a com­pa­ny cal­led Nascent Blue that spe­cia­li­zes in MDD for appli­ca­tion deve­lop­ment. We have actu­al­ly had the oppor­tu­ni­ty to com­pa­re MDD to tra­di­tio­nal deve­lop­ment side-by-side on lar­ge pro­jects. Our client set up ​„the expe­ri­ment” to col­lect the PM data for ana­ly­sis. It was a lar­ge pro­ject with 5 teams. The results:

1. Our team was less than half the size of the other teams.

2. Our team pro­du­ced more than twi­ce the code of the other teams.

3. Our team achie­ved a 75% reduc­tion in cost.

4. Our team achie­ved a 66% reduc­tion in defect rate.

5. Our team was twi­ce as fast (with half the size).

We have sin­ce got­ten more effi­cient and more advan­ced, so I don’t know what the num­bers are now.

We deve­lop our own mode­ling tools (UML, ERD, and DSLs for UI and other things). We also have tools for ADM, so we can achie­ve simi­lar pro­duc­ti­vi­ty gains for re-plat­for­ming and re-archi­tec­tu­re projects.

(źr. Model dri­ven pro­duc­ti­vi­ty | LinkedIn).

Literatura

Wyjątkowo podam zale­ca­ną lite­ra­tu­rę z nadzie­ją, że choć cześć tego uda się Wam ana­li­ty­kom, prze­czy­tać. Sponsorom pro­jek­tów pole­cam roz­waż­ny dobór ana­li­ty­ków i projektantów :).

Kolejność trosz­kę przy­pad­ko­wa (czy­li z mojej pół­ki i tyl­ko część ;)):

1. Tytuł: Metody obiek­to­we w teo­rii i prak­ty­ce, Autor: Ian Graham, Wydanie: WTN, Warszawa 2004

2. Tytuł: Inżynieria Projektowania Strategii Przedsiębiorstwa, Autor: Lechosław Berliński, Ilona Penc-Pietrzak, Wydanie: Difin, Warszawa 2004

3. Tytuł: Inżynieria sys­te­mów infor­ma­cyj­nych, Autor: Paul Beynon-Davis, Wydanie: Warszawa, WNT 2004

4. Tytuł: UML. Inżynieria opro­gra­mo­wa­nia. Wydanie II, Autor: Perdita Stevens, Wydanie: Helion 2007

5. Tytuł: Strategie Konkurencji, Autor: David Faulkner, Cliff Bowman, Wydanie: Gebethner i ska, Warszawa 1996

6. Tytuł: Cybernetyka w zarzą­dza­niu. Modelowanie cyber­ne­tycz­ne. Sterowanie sys­te­ma­mi, Autor: Zdzisław Gomółka, Wydanie: Warszawa, Placet 2000

7. Tytuł: Modele refe­ren­cyj­ne w zarzą­dza­niu pro­ce­sa­mi biz­ne­su, Autor: Tadeusz Kasprzak, Wydanie: Difin, Warszawa 2005

8. Tytuł: Teoria i Inżynieria Systemów, Autor: Czesław Cempel, Wydanie: Czesław CEMPEL, Poznań 2008

9. Tytuł: Business Inteligence, Autor: Jerzy Surma, Wydanie: PWN, Warszawa 2009

10. Tytuł: Architektura sys­te­mów zarzą­dza­nia przed­się­bior­stwem. Wzorce pro­jek­to­we, Autor: Martin Fowler, Wydanie: Helion Gliwice

11. Tytuł: Head First Object-Oriented Analysis and Design, Autor: Brett D. McLaughlin, Gary Pollice, David West, Wydanie: Helion, Gliwice 2008

12. Tytuł: Projektowanie hur­tow­ni danych. Zarządzanie kon­tak­ta­mi z klien­ta­mi (CRM), Autor: Todman Chris, Wydanie: WNT, Warszawa 2003

13. Tytuł: Komponenty w UML, Autor: John Cheesman, John Daniels, Wydanie: WNT, Warszawa 2000

14. Tytuł: UML prze­wod­nik użyt­kow­ni­ka, Autor: Grady Booch, James Rumbaugh, Ivar Jacobson, Wydanie: WNT, Warszawa 2002

15. Tytuł: Inżynieria opro­gra­mo­wa­nia, Autor: Ian Sommerville, Wydanie: WNT, Warszawa

16. Tytuł: Projektowanie zorien­to­wa­ne obiek­to­wo. Wzorce pro­jek­to­we, Autor: Alan Shalloway, James R. Trott, Wydanie: Gliwice, Helion 2005

17. Tytuł: Wdrażanie stra­te­gii dla prze­wa­gi kon­ku­ren­cyj­nej, Autor: Robert S. Kaplan, David P. Norton, Wydanie: PWN, Warszawa 2010

18. Tytuł: Wzorce pro­jek­to­we, Autor: E.Gamma, R.Helm, R.Jonson, J.Vlissides, Wydanie: Helion, Gliwice 2010

19. Tytuł: UML w kro­pel­ce wer­sja 2.0, Autor: Fowler Martin, Wydanie: LTP

20. Tytuł: Analysis Patterns. Reusable Object Models, Autor: Martin Fowler, Wydanie: Addison-Wesley, 1997

21. Tytuł: Podstawy metod obiek­to­wych, Autor: James Martin, James J.Odell, Wydanie: WNT, Warszawa 1997

22. Tytuł: Tworzenie archi­tek­tu­ry opro­gra­mo­wa­nia, Autor: Christine Hofmeister, Robert Nord, Dilip Soni, Wydanie: WNT, Warszawa 2006

23. Tytuł: Business Process Management, Autor: John Jeston, Johan Nelis, Wydanie: Butterworth-Heinemann, 2008 (Reprint 2009)

24. Tytuł: Requirements Analysis and System Design, Autor: Leszek A. Maciaszek, Wydanie: Addison Wesley 2001

25. Tytuł: Object-Oriented Construction Handbook, Autor: Heinz Zullighoven, Wydanie: Elsevier Inc. 2005

26. Tytuł: Stosowanie przy­pad­ków uży­cia, Autor: Geri Schneider, Jason P. Winters, Wydanie: WNT, Warszawa 2004

27. Tytuł: Porter o kon­ku­ren­cji, Autor: Michael E. Porter, Wydanie: PWE, Warszawa 2001

28. Tytuł: Strategie Konkurencji, Autor: Michael E. Porter, Wydanie: MT Biznes, Warszawa 2006

29. Tytuł: Michael E. Porter, Autor: Przewaga kon­ku­ren­cyj­na, Wydanie: Helion, Gliwice 2006

30. Tytuł: Systems Analysis and Design with UML Version 2.0, Autor: Alan Dennis, Barbara Halley Wixom, David Tegarden, Wydanie: Second edi­tion, John Wiley and Sons, Inc. 2005, USA

31. Tytuł: UML i wzor­ce pro­jek­to­we. Analiza i pro­jek­to­wa­nie obiek­to­we oraz ite­ra­cyj­ny model wytwa­rza­nia apli­ka­cji, Autor: Craig Larman, Wydanie: Helion, Gliwice 2011

32. Tytuł: Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approach, Autor: Heinz Züllighoven, Wydanie: Morgan Kaufmann; 1 edi­tion, October 13, 2004

33. Tytuł: Domain-Driven Design: Tackling Complexity in the Heart of Software, Autor: Eric Evans, Wydanie: Addison-Wesley

(zain­te­re­so­wa­nych pozna­niem opi­sa­nych metod ana­li­zy i pro­jek­to­wa­nia zapra­szam na moje szko­le­nia)

A na zakoń­cze­nie cytat:

Moja rada dla osób zaczy­na­ją­cych pra­cę w IT… zanim usią­dziesz do kom­pu­te­ra i zaczniesz pro­gra­mo­wać czy kon­fi­gu­ro­wać weź kart­kę, pomyśl, napisz i nary­suj co chcesz zro­bić, pomyśl jesz­cze raz, popraw, pokaż innym, spy­taj ich o opi­nie, po raz kolej­ny pomyśl, jesz­cze raz popraw i dopie­ro wte­dy sia­daj do kom­pu­te­ra. (Zanim zaczniesz pro­gra­mo­wać weź kart­kę, pomyśl, napisz i nary­suj co chcesz zro­bić – Computerworld).

W sie­ci moż­na zna­leźć wie­le takich i podob­nych przy­kła­dów, tu jeden z nich któ­ry pole­cam. Powyżej opi­sy­wa­łem pro­ces ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nie z uży­ciem trzech nota­cji (narzę­dzi), bo każ­de z nich powsta­ło dla dane­go obsza­ru poję­cio­we­go (osob­no BMM, BPMN i UML). Poniżej przy­kład ana­li­zy (a raczej spe­cy­fi­ka­cji, autor­ka opi­sa­ła treść doku­men­tu a nie jak powsta­wał) jed­nak co do zasa­dy jest to ​„kla­sycz­ny” pro­ces od opi­su biz­ne­su do spe­cy­fi­ka­cji apli­ka­cji, dodam – bo tu to waż­ne – autor­ka korzy­sta­ła wyłącz­nie z moż­li­wo­ści MS Office/Visio (Visio, poza pew­ny­mi nie­for­mal­ny­mi biblio­te­ka­mi sym­bo­li do two­rze­nia sche­ma­tów blo­ko­wych, nie zawie­ra innych nota­cji niż UML):

Complete Business-Systems Analysis Model (UML Example) […] NOTE: The fol­lo­wing exam­ple is the result of an ana­ly­sis effort that was con­struc­ted with MS Visio and Word. (Complete Business-Systems Analysis Model (UML Example).