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…

Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Opisywałem ostat­nio wzo­rzec DDD jako narzę­dzie doku­men­to­wa­nia ana­li­zy i two­rze­nia mode­li ana­li­tycz­nych. Faktycznie, czy­tel­ni­cy mają wie­le racji twier­dząc, że czę­sto jest on zbyt bli­ski imple­men­ta­cji (zbyt szcze­gó­ło­wy a więc trud­ny dla nie­pro­gra­mi­stów). Niejednokrotnie lep­szym pomy­słem” jest opis logi­ki sys­te­mu na nie­co wyż­szym pozio­mie abs­trak­cji, pozo­sta­wia­jąc tym samym wię­cej swo­bo­dy developerowi.

Od cza­su do cza­su uży­wam wzor­ca BCE (Boundary, Control Entity) do mode­lo­wa­nia logi­ki biz­ne­so­wej. Jego rodo­wód się­ga chy­ba jesz­cze cza­sów począt­ków [[meto­dy­ki RUP]]. Pierwotnie był trak­to­wa­ny jako wzo­rzec ana­li­tycz­ny do mode­lo­wa­nia archi­tek­tu­ry kom­pa­ty­bil­nej z MVC, w swej ory­gi­nal­nej posta­ci nawią­zu­je do EJB/DAO ([[Enterprise JavaBeans/Data Access Object]]). Przykładowe stan­dar­do­we uży­cia (źr. wiki):

Wzorzec BCE koja­rzo­ny jest głów­nie z archi­tek­tu­rą EJB ([[Enterprise Java Beans]]). Od tam­tej pory EJB jed­nak nie­co ode­szło w nie­pa­mięć”, nie mamy już J2EE a JEE. Wzorzec MVC docze­kał się sen­sow­nej moim muta­cji do wer­sji [[MVVMC]], [[Model-View-ViewModel Contoler]], [[MVP]] (i kil­ku innych odmian). Diagram w tej kon­wen­cji jest tak­że nazy­wa­ny „[[robust­ness dia­gram]]” i koja­rzo­ny jest z meto­dy­ką ICONIX, jed­nak oso­bi­ście pole­cam sto­so­wa­nie zasad UML i uży­wa­nie dia­gra­mu klas zgod­nie z jego zasa­da­mi” czy­li uży­wa­nie związ­ków uży­cia (linia prze­ry­wa­na z gro­tem a nie cią­gła) i uzna­nie, że robust­ness dia­gram to po pro­stu dia­gram klas.

Podstawowa pier­wot­na wer­sja inter­pre­ta­cji wzor­ca BCE opi­sa­na jest zwięź­le tutaj:

This pat­tern is simi­lar to the Model View Controller pat­tern (descri­bed here [BUS96] and here [WIKP-MVC] among other pla­ces), but the Entity Control Boundary pat­tern is not sole­ly appro­pria­te for dealing with user inter­fa­ces and it gives the con­trol­ler a sli­gh­tly dif­fe­rent role to play. (za Entity-Control-Boundary Pattern).

Stosuję go jed­nak w nie­co zmie­nio­nej” formie.

Boundary, Control, Entity

Jak widać na powyż­szym, BCE nawią­zu­je bez­po­śred­nio do wzor­ca MVC, kla­sy boun­da­ry są w tej wer­sji już ele­men­ta­mi kom­po­nen­tu View. Starając się oddzie­lić (her­me­ty­zo­wać) logi­kę biz­ne­so­wą od czę­ści nie­biz­ne­so­wej” kodu, będą­cej w więk­szo­ści przy­pad­ków ele­men­ta­mi śro­do­wi­ska ([[fra­me­work]]) aplikacji.

Nieco inne podej­ście, to któ­re sto­su­ję obec­nie, opi­su­ję poni­żej. Zachowując pod­sta­wo­we zna­cze­nia tych trzech klas (BCE), nawią­za­łem do wzor­ca MVVM. Powstaje więc kon­struk­cja, w któ­rej Model ma struk­tu­rę M‑VM, pozo­sta­łe ele­men­ty View i Controler mają kon­kret­ne zadania:

  • M‑VM to struk­tu­ra czę­ści dzie­dzi­no­wej (Model-ViewModel),
  • View – tra­dy­cyj­nie odpo­wia­da za prezentację,
  • Controler – tra­dy­cyj­nie odpo­wia­da za zarzą­dza­nie cało­ścią, w tym poza-funk­cjo­nal­ne wyma­ga­nia (np. kodo­wa­nie trans­fe­ru danych nie jest ele­men­tem dzie­dzi­ny sys­te­mu, itp.)

Pewna cie­ka­wost­ką jest w tym wzor­cu wła­śnie ele­ment VM (ViewModel). Jego idea pole­ga na umiesz­cze­niu w obsza­rze dzie­dzi­ny dodat­ko­wej wie­dzy (logi­ki), ste­ru­ją­cej tym jakie (cho­dzi o ich bogac­two”) infor­ma­cje są poda­wa­ne na urzą­dze­nia pre­zen­tu­ją­ce o róż­nych moż­li­wo­ściach np. mały lub duży ekran, roz­dziel­czość czy wręcz komu­ni­ka­cja z pomo­cą SMS.

Powyższy dia­gram poka­zu­je sche­mat budo­wa­nia mode­lu na bazie tego wzor­ca. Jak widać ele­ment dzie­dzi­ny Model zacho­wu­je się zawsze tak samo, repre­zen­tu­je wie­dzę i logi­kę dzie­dzi­no­wą (np. kom­plet infor­ma­cji o oso­bie), Dziedzina (Model) jest dodat­ko­wo wypo­sa­żo­na w wie­dzę o moż­li­wo­ściach pre­zen­to­wa­nia peł­nej lub okro­jo­nej wer­sji wie­dzy publi­ko­wa­nej przez obiekt dzie­dzi­no­wy (kla­sy ViewModel). Dzięki temu View nie zawie­ra żad­nej logi­ki np. fil­tro­wa­nia peł­nej infor­ma­cji, dosta­je tyl­ko pro­sty przy­go­to­wa­ny zestaw danych do pre­zen­ta­cji poza samą pre­zen­ta­cją (dla uprosz­cze­nia pomię­to kom­po­nent Controller).

Jest to o tyle wygod­ne i waż­ne, że sto­so­wa­nie wzor­ca BCE wyłącz­nie do mode­lo­wa­nia logi­ki biz­ne­so­wej wyma­ga zacho­wa­nia her­me­ty­za­cji kom­po­nen­tu Model. Spotkać się moż­na z dia­gra­ma­mi, w któ­rych boun­da­ry będzie ele­men­tem kom­po­nen­tu Model (jako ViewModel). Jego rola to stwo­rze­nie dedy­ko­wa­ne­go inter­fej­su np. pomię­dzy kom­po­nen­tem View (lub Controller) a Model. Dzięki temu moż­li­we jest np. stwo­rze­nie odręb­ne­go inter­fej­su dla View na duży ekran i odręb­ne­go dla View na np. małych ekra­nach smart­fo­nów. Takie podej­ście wyglą­da tak:

Znaczenie (seman­ty­ka) stereotypów:

Boundary to kla­sa ozna­czo­na ste­reo­ty­pem «boun­da­ry», na dia­gra­mach repre­zen­to­wa­na może być iko­ną jak po lewej. Odpowiedzialność klas boun­da­ry to sepa­ra­cja mode­lu dzie­dzi­ny od innych kom­po­nen­tów (to czę­sto adap­ter, fasa­da, inter­fejs). Dzięki temu ewen­tu­al­ne zmia­ny Modelu nie prze­nio­są się na kom­po­nen­ty View i Controller oraz może­my zbu­do­wać np. róż­ne dedy­ko­wa­ne i bez­piecz­ne dzie­dzi­no­we adap­te­ry dostę­po­we do Modelu (np. w sys­te­mie nawi­ga­cyj­nym boun­da­ry dostar­czy Modelowi koor­dy­na­ty geo­gra­ficz­ne, View pozwo­li wpro­wa­dzić je z kla­wia­tu­ry a Controller z odbior­ni­ka – inter­fejs – GPS, Model sta­je nie­czu­ły na źró­dło tych koordynatów).

Control. Klasy ozna­czo­ne ste­reo­ty­pem «con­trol» lub iko­ną jak po lewej. Są to kla­sy odpo­wie­dzial­ne za wewnętrz­ne usłu­gi spe­cy­ficz­ne dla dzie­dzi­ny, umie­jęt­no­ści”. Nie są to kla­sy utrwa­la­ne. Ta kla­sa będzie obli­cza­ła np. czas prze­jaz­du na bazie wyty­czo­nej w sys­te­mie nawi­ga­cji strasy.

Entity. Najbardziej kon­tro­wer­syj­na kla­sa, w pier­wot­nej wer­sji inter­pre­ta­cji wzor­ca BCE (EJB) ozna­cza­ła tyl­ko dane utrwa­la­ne, nawią­zu­jąc do EJB sta­no­wi­ła mate­riał” na tak zwa­ny [[antyw­zo­rzec obiek­to­wy o nazwie ane­micz­ny model dzie­dzi­ny]]. Klas ozna­czo­nych ste­reo­ty­pem «enti­ty» uży­wa­my do mode­lo­wa­nia wie­dzy, czy­li zgro­ma­dzo­nych danych, nie są to jed­nak ane­micz­ne kla­sy bez ope­ra­cji. Będą to np. punk­ty na mapie cyfrowej.

Trzy powyż­sze typy klas są tu ele­men­ta­mi kom­po­nen­tu Model. Syntaktyka odwo­łań ele­men­tów wzor­ca BCE:

Obrazowo wyglą­da to tak:

Przejście na poziom DDD, dro­gę w kie­run­ku imple­men­ta­cji tego mode­lu przy powyż­szych zało­że­niach, moż­na reali­zo­wać np. tak:

Interpretacja ta pozwa­la zacho­wać głów­ny cel czy­li roz­ło­że­nie logi­ki Modelu na pro­stą” mapę trzech ele­men­tów: kon­tak­tu z oto­cze­niem (boun­da­ry), reali­za­cji logi­ki i reguł (con­trol) oraz zacho­wy­wa­nia bier­nych” obiek­tów biz­ne­so­wych (enti­ty). Mała adap­ta­cja kon­wen­cji do wzor­ca MVVM-V‑C pozwa­la uzy­skać kom­fort cał­ko­wi­tej sepa­ra­cji tak mode­lo­wa­ne­go Modelu od jego otoczenia.

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­nia funk­cjo­nal­ne i poza-funk­cjo­nal­ne. 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 autor­skie pra­wo oso­bi­ste do pro­jek­tu tej reali­za­cji (mająt­ko­we­go nie musi wydać).

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 ryzykami. 

Literatura

Polecam cie­ka­wy arty­kuł na podob­ny temat:

As we have seen, the fun­da­men­tal idea of MVC is a sepa­ra­tion of the doma­in logic and the GUI objects into the Model and the View. These two are lin­ked indi­rec­tly by using the Publish-Subscribe mecha­nism known as the Observer pat­tern. Another ele­ment of this design is a Controller that imple­ments a par­ti­cu­lar stra­te­gy for the View. (Model View Controller, Model View Presenter, and Model View ViewModel Design Patterns – CodeProject).

Oraz (apro­po MVVM iMVC):

Warto pisać apli­ka­cje w taki spo­sób, żeby moż­na było je w cało­ści obsłu­gi­wać za pomo­cą testów jed­nost­ko­wych. Jak nale­ży to rozu­mieć? Budując apli­ka­cję w taki spo­sób, że cała jej funk­cjo­nal­ność dostęp­na jest bez inter­fej­su użyt­kow­ni­ka, możesz każ­dy jej aspekt opi­sać za pomo­cą testów jed­nost­ko­wych. To pozwa­la na wstęp­ne testo­wa­nie zgod­no­ści apli­ka­cji z wyma­ga­nia­mi wstęp­ne, bo cały czas nale­ży pamię­tać, że testy jed­nost­ko­we to narzę­dzie, wspie­ra­ją­ce pro­gra­mi­stów, a nie teste­rów i jako takie nie może zastą­pić testów apli­ka­cji. (Wykorzystanie TDD wraz ze wzor­cem MVVM).

Kiedy i po co robimy te modele?

Tu nawią­żę do MDA (tu co nie­co o Model Driven Architecture). W łań­cu­chu mode­li MDA mamy trzy mode­le: CIM->PIM->PSM. Analiza biz­ne­so­wa na pierw­szym eta­pie to two­rze­nie mode­lu orga­ni­za­cji pomi­ja­ją­ce­go ist­nie­nie jakie­go­kol­wiek opro­gra­mo­wa­na (CIM – [[Computation Independent Model]]), celem jest peł­ne zro­zu­mie­nie i opi­sa­nie funk­cjo­no­wa­nia organizacji.

Kolejny etap to opra­co­wa­nie mode­lu dzie­dzi­ny pro­jek­to­wa­ne­go (wyma­ga­ne­go) opro­gra­mo­wa­nia. To model PIM ([[Platform Independent Model]]). Jego celem jest udo­ku­men­to­wa­nie logi­ki opro­gra­mo­wa­nia, wyma­ga­nia poza funk­cjo­nal­ne są reali­zo­wa­ne nie­za­leż­nie od tej logi­ki. Tak więc model PIM do coś co nazy­wa­ne bywa: wyma­ga­nia dzie­dzi­no­we”. Wymagania funk­cjo­nal­ne nie opi­su­ją w ogó­le logi­ki biz­ne­so­wej, same przy­pad­ki uży­cia nie są wystar­cza­ją­ce do napi­sa­nia opro­gra­mo­wa­nia, potrzeb­na jest wie­dza o logi­ce biz­ne­so­wej. Funkcjonalność sys­tem sprze­da­ży auto­ma­tycz­nie uwzględ­nia upu­sty dla klien­tów” nic nie mówi. Ale gdzie defi­ni­cja logi­ki udzie­la­nia tych upu­stów? Gdzie jest wie­dza o upu­stach a gdzie o towa­rach? Przy klien­cie czy przy towa­rze? Nie wia­do­mo, trze­ba to jakoś zro­zu­mieć i udo­ku­men­to­wać, w spo­sób pozwa­la­ją­cy na imple­men­ta­cją czy­li jed­no­znacz­nie. I po to się two­rzy mode­le PIM.

Tu jed­nak nale­ży się mała uwa­ga (bo nigdy nie mów nigdy): bywa, że ogra­ni­cze­nie o tre­ści mak­sy­mal­ny czas ocze­ki­wa­nia na ofer­tę nie może prze­kro­czyć pro­gu cier­pli­wo­ści 80% klien­tów”. Pozostaje zba­da­nie pro­gu cier­pli­wo­ści”, ten para­metr nie jest ele­men­tem regu­ły biz­ne­so­wej gdyż jest wła­śnie para­me­trem” a nie zasa­dą” (regu­ły biz­ne­so­we to zasa­dy postę­po­wa­nia a nie regu­ły podej­mo­wa­nia decy­zji czy mier­ni­ki). Ta regu­ła może stać się ele­men­tem dzie­dzi­ny pro­jek­to­wa­ne­go sys­te­mu jeże­li np. jej speł­nie­nie jest ele­men­tem budo­wy prze­wa­gi ryn­ko­wej. Co to zna­czy? Że nie nale­ży opty­ma­li­zo­wać obec­ne­go mode­lu dzie­dzi­ny (np. pod­no­sze­nie wydaj­no­ści poprzez uprosz­cze­nie struk­tu­ry opi­su pro­duk­tów) a dodać do dzie­dzi­ny struk­tu­rę pozwa­la­ją­cą na wyko­ny­wa­nie pew­nych wybra­nych czyn­no­ści pro­ściej i szyb­ciej. To jed­nak temat o wzor­cu pro­jek­to­wym CQRS ale to temat na inny arty­kuł.

(inne źró­dła:

basic rules apply: Actors can only talk to boun­da­ry objects.Figure 3. Robustness Analysis RulesBoth boun­da­ry objects and enti­ty objects are nouns, and con­trol­lers are verbs. Nouns can’t talk to other nouns, but verbs can talk to either nouns or verbs. Boundary objects can only talk to con­trol­lers and actors. Entity objects can only talk to con­trol­lers. Controllers can talk to boun­da­ry objects and enti­ty objects, and to other con­trol­lers, but not to actors

źr. Memorandum).