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.