Regularnie na moich szko­le­niach oraz w toku pro­jek­tów, dosta­je pyta­nia o ​„wali­da­cje”. Z regu­ły spo­ty­kam spe­cy­fi­ka­cje wyma­gań (albo ocze­ki­wa­nia na takie), zawie­ra­ją­ce zesta­wie­nia doku­men­tów (i for­ma­tek ekra­no­wych), dla każ­de­go zesta­wie­nie pól, dla każ­de­go pola ​„wali­da­cje”. Problem w tym, że:

• mie­sza­ją się tu tak zwa­ne typy pro­ste danych (zna­ko­we, licz­bo­we, itp.), tak zwa­ne ​„maski” (data, ema­il, itp.), oraz regu­ły biz­ne­so­we (np. wła­ści­wy rabat),
• z uwa­gi na to, że doku­men­tów jest wie­le, a pola mogą się na nich powta­rzać, powsta­je duża licz­ba powtó­rzo­nych zapi­sów ​„wali­da­cji”, nie­jed­no­krot­nie nie­spój­nych a bywa, że sprzecznych.
• typy pro­ste oraz regu­ły biz­ne­so­we (logi­ka biz­ne­so­wa) to dwa zupeł­nie inne obsza­ry systemu.

Jak definiować wymagania na ​„walidacje”

Tu war­to na począ­tek wró­cić do kla­sy­fi­ka­cji wyma­gań. W arty­ku­le Inżynieria wyma­gań opi­sa­łem trzy ich rodzaje:

1. funk­cjo­nal­ne czy­li usłu­gi apli­ka­cji (przy­pad­ki uży­cia tej aplikacji),
2. poza-funk­cjo­nal­ne czy­li cechy jakościowe,
3. dzie­dzi­no­we czy­li logi­ka biznesowa.

I teraz bar­dzo waż­na rzecz: któ­re ele­men­ty archi­tek­tu­ry opro­gra­mo­wa­nia, za reali­za­cję któ­rych wyma­gań odpo­wia­da­ją? W arty­ku­le Gdzie się reali­zu­ją wyma­ga­nia opi­sa­łem ogól­nie wzo­rzec pro­jek­to­wy MVC. Pomijając sam wzo­rzec, istot­ne jest to, że tak zwa­ne ​„wali­da­cje” są doko­ny­wa­ne w dwóch róż­nych ele­men­tach archi­tek­tu­ry. Tak zwa­ne typy pro­ste danych (np. pole zna­ko­we Nazwisko) są (mogą być) spraw­dzo­ne w momen­cie ich wpro­wa­dza­nia (np. for­mat­ka ekra­no­wa nie przyj­mu­je cyfr w polu nazwi­sko). Cała logi­ka biz­ne­so­wa jest wyko­ny­wa­na wewnątrz apli­ka­cji (infor­ma­cje o ewen­tu­al­nych błę­dach poja­wią się po zatwier­dze­niu for­mu­la­rza), np. upust może być spraw­dzo­ny (albo nali­czo­ny) dopie­ro po skom­ple­to­wa­niu danych wyma­ga­nych do jego wyli­cze­nia, czy­li będzie to kil­ka róż­nych pól (naj­mniej dwa :)). Bywa, że do wyli­cze­nia cze­goś potrzeb­ne będą dane nie wpro­wa­dza­ne do danej for­mat­ki fak­tu­ry, np. sal­do klienta.

Jedną z naj­gor­szych prak­tyk pro­gra­mi­stów jakie spo­ty­kam, jest umiesz­cza­nie logi­ki biz­ne­so­wej (a są nią np. meto­dy nali­cza­nia upu­stów) w for­mu­la­rzach ekra­no­wych. Po pierw­sze pro­wa­dzi to duże­go obcią­ża­nia kodu tych for­ma­tek, po dru­gie przy dużej ilo­ści doku­men­tów (for­ma­tek ekra­no­wych) logi­ka biz­ne­so­wa jest powie­la­na, co pro­wa­dzi do dużych pro­ble­mów z utrzy­ma­niem spój­no­ści spraw­dza­nych reguł biz­ne­so­wych w apli­ka­cji. Po trze­cie pró­by pisa­nia inter­fej­sów (API) do tych apli­ka­cji (np. przyj­mo­wa­nie doku­men­tów wysta­wio­nych poza apli­ka­cją) jest nie­moż­li­we bez kolej­ne­go powie­le­nia logi­ki biz­ne­so­wej w API (jeże­li chce­my ​„wali­do­wać” przyj­mo­wa­ne tą dro­gą dane a z raczej chce­my). Jednym sło­wem masakra.

Sprawdzoną meto­dą sku­tecz­ne­go (spój­ność, kom­plet­ność, nie­sprzecz­ność) zapi­sy­wa­nia wyma­gań dzie­dzi­no­wych (w tym ​„wali­da­cje”) jest wydzie­le­nie w dokumentacji:

1. słow­ni­ka pojęć
2. słow­ni­ka reguł biznesowych 
   1. spe­cy­fi­ka­cji tablic decy­zyj­nych jako uzu­peł­nie­nia reguł biznesowych.

Słownik pojęć powi­nien obej­mo­wać wszyst­ko to co stwa­rza ryzy­ko nie­jed­no­znacz­no­ści. Reguły biz­ne­so­we, wraz z tabli­ca­mi decy­zyj­ny­mi (jeże­li są wyma­ga­ne) zebra­ne w jed­nym miej­scu (spe­cy­fi­ka­cja reguł), są niczym innym jak wyma­ga­nia­mi dzie­dzi­no­wy­mi. Tak opra­co­wa­na doku­men­ta­cja ana­li­tycz­na pozwa­la deve­lo­pe­ro­wi na łatwe poru­sza­nie się po doku­men­cie, mamy moż­li­wość wery­fi­ka­cji wyma­gań, ich spój­no­ści i kom­plet­no­ści. Załączając spe­cy­fi­ka­cje wzo­rów doku­men­tów (mock-up’y ekra­nów czy­li for­mat­ki ekra­no­we) każ­dy obszar takie­go wzo­ru albo jest oczy­wi­sty, albo jest zde­fi­nio­wa­ny (jako nazwa) w słow­ni­ku pojęć. Cała nie­try­wial­na logi­ka dzia­ła­nia jest opi­sa­na regu­ła­mi biz­ne­so­wy­mi. Ogólne zasa­dy two­rze­nia takiej dokumentacji:

1. W toku ana­li­zy opra­co­wu­je­my mode­le pro­ce­sów biz­ne­so­wych zawie­ra­ją­ce wyłącz­nie aktyw­no­ści i ich pro­duk­ty (czy­li pro­ce­sy biz­ne­so­we) i nic ponad to (dodat­ko­we szcze­gó­ły to albo pro­ce­du­ry albo sce­na­riu­sze przy­pad­ków uży­cia, to inne dokumenty).
2. Na mode­lach pro­ce­sów zazna­cza­my wszyst­kie aktyw­no­ści zwią­za­ne ze sto­so­wa­niem reguł biz­ne­so­wych (kon­wen­cja doku­men­to­wa­nia reguł na mode­lach zale­ży od uży­te­go narzę­dzia CASE). Reguły biz­ne­so­we uzu­peł­nia­my o ewen­tu­al­ne kry­te­ria decy­zyj­ne (np. w posta­ci tablic decyzyjnych).
3. Równolegle pro­wa­dzi­my słow­nik pojęć dla dokumentacji.
4. Nie defi­niu­je­my (jako biz­nes, a nawet ana­li­tyk biz­ne­so­wy, zgła­sza­ją­cy wyma­ga­nia) typów pro­stych, one są albo oczy­wi­ste, albo wyni­ka­ją z defi­ni­cji pojęć (w razie wąt­pli­wo­ści pisze­my czym jest nazwi­sko w słowniku).

Ważna rzecz. Decyzje o tym jaki­mi typa­mi danych ope­ru­je apli­ka­cja, to decy­zje deve­lo­pe­ra (pro­gra­mi­sty). Moim zda­niem pro­gra­mi­sta żąda­ją­cy w wyma­ga­niach poda­nia mu typów danych, jest nie­ukiem albo leni­wym sabo­ta­ży­stą (uży­cie – wybór typów danych, w tym typów zło­żo­nych, to decy­zje i kom­pe­ten­cje developera!).

Poniżej opi­sa­ne ele­men­ty umiesz­czo­ne na jed­nym sche­ma­cie blokowym:

Tak więc, war­to roz­wa­żyć sto­so­wa­nie reguł biz­ne­so­wych i słow­ni­ków pojęć (Semantics Of Business Vocabulary And Rules), gdyż jest to spraw­dzo­na i bar­dzo przy­dat­na tech­ni­ka ana­li­zy i doku­men­to­wa­nia logi­ki biz­ne­so­wej. Polecam tak­że stro­nę The Business Rules Group i zamiesz­czo­ny tam Manifest Reguł Biznesowych. Tworzenie mon­stru­al­nych doku­men­tów wyma­gań, zawie­ra­ją­cych dzie­siąt­ki razy powie­la­ne ​„wali­da­cje” pro­wa­dzi do wie­lu kło­po­tów z utrzy­ma­niem spój­no­ści i kom­plet­no­ści takich spe­cy­fi­ka­cji. Pomijam już ich uciąż­li­wą obję­tość. Jako mate­riał dla pro­gra­mi­sty są one wte­dy trud­ne w uży­ciu, do tego skła­nia­ją do naj­gor­szych prak­tyk, jaki­mi jest mię­dzy inny­mi umiesz­cza­nie logi­ki biz­ne­so­wej w kodzie for­ma­tek ekranowych.

Na koniec pole­cam książ­kę Building Business Solutions poświę­co­na temu zagadnieniu.