Pojęcia, reguły i fakty czyli o czym oni mówią…

Niedawno napi­sa­łem:

opro­gra­mo­wa­nie repre­zen­tu­je narzę­dzie pra­cy, więc pro­jekt tego opro­gra­mo­wa­nia raczej powi­nien zawie­rać poję­cie (kla­sę) Kartoteka Pracowników a nie Pracownicy. (Dlaczego nie podo­ba mi się kla­sa Pracownik?).

To sta­ły temat wie­lu dys­ku­sji z pro­gra­mi­sta­mi. Ostatnio, po pew­nym szko­le­niu, w ramach wspar­cia po szko­le­niu jakie zawsze świad­czę, zno­wu padło pytanie:

Czy zda­rza Ci się robić analizy/projekty, gdzie byty wystę­pu­ją pod nazwa­mi inny­mi niż uży­wa­ny­mi potocz­nie przez Biznes.

Z tym – uży­wa­ne poję­cia – jest regu­lar­nie duży pro­blem, dla­te­go od pew­ne­go cza­su orto­dok­syj­nie sto­su­ję budo­wa­nie prze­strze­ni poję­cio­wej” dla pro­jek­tu ([[Semantics of Business Vocabulary and Business Rules]]). Buduję słow­nik pojęć, listę reguł biz­ne­so­wych (to nie to samo co regu­ły decy­zyj­ne) oraz tak zwa­ny dia­gram fak­tów, któ­ry słu­ży do testo­wa­nia (i doku­men­to­wa­nia słow­ni­ka) – upew­nie­nia się, że poję­cia nie koli­du­ją ze sobą a ich defi­ni­cje nie nakła­da­ją się na sie­bie oraz, że lista jest dzie­dzi­no­wo kom­plet­na. Po co to? Właśnie po to,

by żad­ne zde­fi­nio­wa­ne sło­wo nie mia­ło w pro­jek­cie (w wyma­ga­niach, w kodzie) wię­cej niż jed­ne­go zna­cze­nia i by zna­cze­nie każ­de­go zefi­nio­wa­ne­go poję­cia nie budzi­ło żad­nych wątpliwości

(co nie­co o słow­ni­kach ter­mi­nów: Reguły biz­ne­so­we jako motor ste­ru­ją­cy orga­ni­za­cji: fak­ty + defi­ni­cje pojęć).

Jedna uwa­ga na począ­tek: jeże­li byty” (kla­sy) w kodzie (pro­jek­cie) opro­gra­mo­wa­nia wystę­pu­ją pod inny­mi nazwa­mi niż w rze­czy­wi­sto­ści, to jest to abso­lut­na poraż­ka, bo pro­gra­mi­sta zupeł­nie tra­ci kon­takt z klien­tem i (lub) doku­men­ta­cją opi­su­ją­ca wyma­ga­nia. Jeżeli już koniecz­nie pro­gra­mi­sta musi ulżyć sobie w ambi­cji uży­wa­nia wyłącz­nie j.angielskiego w kodzie, powi­nien ten kod być boga­to komen­to­wa­ny, by nie było wąt­pli­wo­ści jakie znacz­nie nie­sie np. nazwa kla­sy czy atry­bu­tu (tym bar­dziej, że np. sło­wo name to nie tyl­ko nazwisko.….)

http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​B​u​s​i​n​e​s​s​A​n​a​l​y​s​t​H​u​m​o​r​/​t​a​b​i​d​/​2​1​8​/​D​e​f​a​u​l​t​.​a​s​p​x​?​A​r​t​i​c​l​e​T​y​p​e​=​A​r​t​i​c​l​e​V​i​e​w​&​A​r​t​i​c​l​e​I​D​=​2​471

Słownik pojęć (czę­sto wystę­pu­je w doku­men­tach jako czy­sto pol­skie sło­wo glos­sa­riusz ;)) bywa czę­sto przed­mio­tem burz­li­wych nego­cja­cji, bo nie raz (a w zasa­dzie zawsze ;)) biz­nes sto­su­je slang, w któ­rym to samo sło­wo ma róż­ne zna­cze­nie, zależ­nie od kon­tek­stu uży­cia. Może to mieć sens w języ­ku mówio­nym gdy peł­na treść wypo­wie­dzi daje ten kon­tekst, ale na pozio­mie ana­li­zy i pro­jek­tu każ­de poję­cie musi mieć jed­no uni­kal­ne znacz­nie mimo bra­ku kon­tek­stu (tym bar­dziej, że np. nazwy klas nie są ele­men­ta­mi peł­nych zdań ani opowieści :)).

Pamiętam pro­jekt, w któ­rym wice­pre­zes pew­nej fir­my na każ­de dzia­ła­nie takie jak nowa umo­wa, nowy pro­jekt, nowy klient, uży­wał sło­wa temat”, nikt nie miał odwa­gi powie­dzieć mu, że nie raz nie rozu­mie o czym on mówi … Ja – obcy – się odwa­ży­łem 🙂 i upo­rząd­ko­wa­li­śmy to, był opór ;). Pamiętam, że dyplo­ma­tycz­nie popro­si­łem go by zbu­do­wał hie­rar­chię tema­tów” nazy­wa­jąc każ­dy ele­ment tej hie­rar­chii jed­nym lub dwo­ma sło­wa­mi sło­wa­mi i pomo­gło :), Słownik pojęć to negocjacje 🙂

Evans (DDD ) zapo­cząt­ko­wał bar­dzo cie­ka­we podej­ście, ono się roz­wi­ja. Co cie­ka­we Evans nie wymy­ślił idei a sys­tem wzor­ców DDD. Wspólny język to dwa ele­men­ty: uży­wa­nie biz­ne­so­wych nazw (bez skró­tów) na ele­men­ty rze­czy­wi­ste i kla­sy w sys­te­mie, ale tak­że uży­wa­nie np. poję­cia fabry­ka” przez biz­nes i przez deve­lo­pe­ra jako kon­te­ner” na pewien rodzaj kom­pe­ten­cji (wie­dza o tym jak powsta­ją pew­ne obiek­ty biznesowe).

Elementy wzor­ca DDD to nie tyl­ko blo­ki kodu, to tak­że ele­men­ty (kla­sy­fi­ka­to­ry) wie­dzy o biz­ne­sie. Faktura VAT to agre­gat – struk­tu­ra infor­ma­cji, to tyl­ko wie­dza o tym co ten doku­ment zawie­ra, ale FabrykaFaktur to odręb­na wie­dza o tym jak ten doku­ment jest two­rzo­ny. Należy świa­do­mie udo­ku­men­to­wać oba byty: doku­ment i recep­ta jego two­rze­nia. Dlaczego osob­no? Bo po pierw­sze wysta­wio­ne fak­tu­ry żyją wła­snym, życiem i obcią­ża­nie każ­dej z nich (np. tysiąc fak­tur mie­sięcz­nie) całą wie­dza jak powsta­ła nie ma więk­sze­go sen­su. Po dru­gie zmia­na prze­pi­sów nie powin­na się odbić na doku­men­tach już wysta­wio­nych ani docią­żyć nowo powstających.

Biznes tak­że musi zro­zu­mieć, że ma dwa róż­ne ele­men­ty opi­su swo­ich dzia­łań: pra­ca z doku­men­ta­mi i two­rze­nie doku­men­tów. Jednak uzna­nie tego fak­tu to jed­no, nie wie­rzę w to, że biz­nes się tego nauczy, bo nie nauczył się for­mal­ne­go opi­su lub mode­lo­wa­nia pro­ce­sów pod­czas wdro­żeń ISO, jed­nak uwa­żam, że biz­nes nie ma takiej potrze­by. Moim zda­niem od dobre­go ana­li­ty­ka nie ma uciecz­ki, to inna kom­pe­ten­cja. Nie ma uciecz­ki od pro­jek­tan­tów mody mimo ist­nie­nia kobiet chcą­cych mieć ład­ne sukien­ki i bar­dzo dobrych kraw­ców. Nikt tu niko­go nie zastąpi.

Czy Model dziedziny ma stan?

(to część bar­dziej techniczna)

W kwe­stii cze­goś takie­go jak Stan Modelu w MVC (czy model biz­ne­so­wy ma stan?) jestem ostroż­ny z uży­wa­niem poję­cia stan”, popa­trz­my na gry kom­pu­te­ro­we… Czym jest stan? Stan na pewien moment w cza­sie (snap­shot) czy stan biz­ne­so­wy” trwa­ją­cy minu­ty, godzi­ny a nie raz dłu­żej? Model to sys­tem: zespół ele­men­tów współ­dzia­ła­ją­cych. Z per­spek­ty­wy biz­ne­su, reagu­je on na akcje (sta­bil­ny ekran ocze­ki­wa­nia na OK, to per­ma­nent­ny maszy­no­wy prze­bieg spraw­dza­nia sta­nu przy­ci­sków). Osobiście trak­tu­ję kla­sy Modelu jako samo­dziel­ne żyją­ce byty, kon­struk­cja metod musi zagwa­ran­to­wać brak błę­dów i radzić sobie z tym co sta­łe” dla użyt­kow­ni­ka i zmien­ne” dla sys­te­mu (zegar bez sekund­ni­ka jest z per­spek­ty­wy minut mar­twym przed­mio­tem a mimo to cho­dzi”).

Podejście do MVC, któ­re prak­ty­ku­ję: Model powi­nien reali­zo­wać 100% funk­cjo­nal­no­ści i dać się testo­wać bez war­stwy V i C. Konkretnym sta­nem raczej cha­rak­te­ry­zu­je się kon­kret­ny obiekt a nie cały sys­tem. Cały sys­tem moż­na zapew­ne opi­sać maszy­ną sta­no­wą ale po co, sko­ro są ich nie­zli­czo­ne ilo­ści? Model żyje jak mro­wi­sko, wystar­czy zro­zu­mieć mrów­ki, mro­wi­sko to sku­tek na któ­ry za bar­dzo nie mamy wpływu.

Model DDD ana­li­tycz­ny” to meta­mo­del imple­men­ta­cji, Evans trak­tu­je go jako blo­ki kodu” zro­zu­mia­łe przez biz­nes, idąc dalej: ana­li­tyk trak­tu­je DDD jako wie­dzę o biz­ne­sie w posta­ci zro­zu­mia­łej przez deve­lo­pe­ra. Obie stro­ny uzna­ją, że ta struk­tu­ra jest wza­jem­ną umo­wą”. Jestem zwo­len­ni­kiem takie­go podej­ścia do DDD :), Evans się z tym w moich oczach nie kło­ci, on w zasa­dzie nie pisał o ana­li­zie biz­ne­so­wej :). Wielu pro­gra­mi­stów, auto­rów dosko­na­łych ksią­żek, zakła­da, że ana­li­zę wyma­gań ma popraw­nie wyko­na­ną”, co by to nie mia­ło zna­czyć :), ale to ogrom­ne uprosz­cze­nie bo tu – błę­dy – tkwi więk­szość ryzyk projektu.

Więcej o słow­ni­kach i regu­łach biznesowych:

(OMG, Glossary, Business Rules, http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​S​e​m​a​n​t​i​c​s​_​o​f​_​B​u​s​i​n​e​s​s​_​V​o​c​a​b​u​l​a​r​y​_​a​n​d​_​B​u​s​i​n​e​s​s​_​R​u​les oraz http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​B​u​s​i​n​e​s​s​_​r​ule, http://​www​.visu​al​-para​digm​.com/​s​u​p​p​o​r​t​/​d​o​c​u​m​e​n​t​s​/​b​p​v​a​u​s​e​r​g​u​i​d​e​/​2​0​1​7​/​2​1​8​1​/​5​7​0​4​3​_​c​r​e​a​t​i​n​g​f​a​c​t​.​h​tml).

Diagram klas ? czyli ?reinżynieria? analizy biznesowej

Tym razem mała pole­mi­ka czy­li kontr­pro­po­zy­cja. Celem arty­ku­łu nie jest kry­ty­ka cudze­go pro­jek­tu, dale­ki jestem od tego. Celem jest poka­za­nie, że są roż­ne meto­dy ana­li­zy i pro­jek­to­wa­nia. Czytelnik sam doko­na porów­na­nia i ewen­tu­al­nej oce­ny. Drugim celem jest wska­za­nie pew­nych metod mode­lo­wa­nia, speł­nia­ją­cych obiek­to­wy para­dyg­mat i obiek­to­we meto­dy ana­li­zy i pro­jek­to­wa­nia, w odróż­nie­niu od metod mają­cych nadal pod­sta­wy w ana­li­zie struk­tu­ral­nej. Najpierw cytat z pew­ne­go por­ta­lu (źró­dło pod cytatem):

Kilka słów o tym, co chciał­bym przed­sta­wić: mamy klien­ta (klien­tów), któ­ry skła­da zamó­wie­nia on-line u dostaw­cy pew­nych produktów,u dostaw­cy dostęp­ne jest wie­le pro­duk­tów, o róż­nych cenach, para­me­trach, wadze itp.,zamówienie może się skła­dać z od jed­ne­go do wie­lu produktów,za zamó­wie­nie klient może doko­nać płat­no­ści na 3 róż­ne spo­so­by: kar­tą kre­dy­to­wą, prze­le­wem lub gotów­ką. Mamy więc: Klienta, Zamówienie, Produkt oraz Płatność, co na dia­gra­mie moż­na przed­sta­wić następująco:

źr. Diagram klas ? ?rein­ży­nie­ria? (etap 1) ? Modelowanie pro­ce­sów biz­ne­so­wych.

Tam więc mamy opis, cza­sem nazy­wa­ny magicz­nie: user sto­ry”. Na bazie opi­su powstał dia­gram klas. Tak wła­śnie wyglą­da wie­le ana­liz wyma­gań. Ta jest cał­kiem przy­zwo­ita, więk­szość koń­czy na zare­je­stro­wa­niu tego user sto­ry” i prze­re­da­go­wa­niu go do jakiejś okre­ślo­nej struk­tu­ral­nej posta­ci nazwa­nej następ­nie Wymagania Użytkownika. Kłopot w tym, że – jak wie­lu pew­nie z czy­tel­ni­ków już się prze­ko­na­ło – tak okre­ślo­ne wyma­ga­nia i pro­jekt są w trak­cie imple­men­ta­cji per­ma­nent­nie zmie­nia­ne w takt odkry­wa­nia rze­czy, oczy­wi­stych dla użyt­kow­ni­ka, o któ­rych nam w swo­im user sto­ry” nie powiedział.

Jak już chy­ba każ­dy mój czy­tel­nik wie, pre­fe­ru­je meto­dy for­mal­ne. Tak wiec zamiast mode­lo­wać od razu sys­tem” i brać się za jego imple­men­ta­cję (pierw­szy pro­to­typ? zwin­ne two­rze­nie opro­gra­mo­wa­nia itp.…) bio­rę na tape­tę to user sto­ry” i spraw­dzam jego spój­ność. Jak? Ano two­rze model pro­ce­su, któ­ry to user sto­ry” opi­su­je. I co powstaje?

Jak widać, user sto­ry” jest dziu­ra­we jak ser szwaj­car­ski. Pojawiły się nowe zda­rze­nia i doku­men­ty wraz ze sta­tu­sa­mi. Uzupełnieniem tego dia­gra­mu powin­ny być wzo­ry doku­men­tów oraz ogra­ni­cze­nia np. pro­dukt umiesz­czo­ny na Zamówieniu musi być blo­ko­wa­ny na czas jego prze­twa­rza­nia. Etap obsłu­gi płat­no­ści powo­du­je zdję­cie blo­ka­dy lub zdję­cie z maga­zy­nu, zależ­nie od fina­łu transakcji.

Teraz dopie­ro przy­cho­dzi pora na ana­li­zę o two­rze­nie dia­gra­mu klas a kon­kret­nie mode­lu dzie­dzi­ny. Kandydatami na kla­sy są doku­men­ty, zda­rze­nia i ewen­tu­al­nie role (akto­rzy, a raczej dane o nich). Kandydatem na kla­sę są tak­że regu­ły biz­ne­so­we i ich wyko­naw­cy”. Teraz jest moment na zde­kla­ro­wa­nie się co do sty­lu ana­li­zy i pro­jek­to­wa­nia. Po pierw­sze jako bazy uży­wam wzor­ca MVC i meto­dy­ki opi­su­ją­cej jak two­rzyć ele­ment o nazwie Model w MVC czy­li Domain-Driven Design, któ­rej twór­cą jest Eric Evans.

Po co to robię? Dlaczego pod­no­szę pra­co­chłon­ność ana­li­zy wyma­gań i pro­jek­tu­ję model kon­cep­cyj­ny do testów? Ano po to by błę­dy i nie­spój­no­ści odkryć teraz, bo na eta­pie imple­men­ta­cji ich usu­wa­nie będzie nawet 100 razy droż­sze. Czy takie błę­dy są w pro­jek­tach o uprosz­czo­nych ana­li­zach biz­ne­so­wych (lub wręcz pomi­nię­tych?) Ci co mają takie pro­jek­ty za sobą wie­dzą dosko­na­le, że są i to pra­wie zawsze…

W następ­nej czę­ści przy­pad­ki uży­cia, dia­gram klas czy­li model dzie­dzi­ny oraz ich testowanie.