Biznesowy model danych – nie chcemy

Nadal obser­wu­ję to, że model rela­cyj­ny i two­rze­nie mode­li danych na eta­pie ana­li­zy wyma­gań” trzy­ma­ją się twar­do mimo tego, że nie wie­le wno­szą do pro­jek­tu a narzu­ca­ją (suge­ru­ją) kiep­ską archi­tek­tu­rę apli­ka­cji z jed­ną rela­cyj­na bazą danych. Co cie­ka­we zaczy­na­nie od bazy danych jest wręcz zaprze­cze­niem zwin­no­ści (koniecz­ność ukoń­cze­nia pro­jek­tu doce­lo­wej bazy danych przed roz­po­czę­ciem kodo­wa­nia czy­li kla­sy­ka water­fall, w efek­cie beto­no­wa­nie sta­nu z dnia roz­po­czę­cia) mimo, że autor­ki arty­ku­łu piszą o sobie że są agile…

Popatrzmy na to co pro­po­nu­ją w tym 2017 roku.:

If the­re are spe­ci­fic busi­ness rules in the sys­tem that set maxi­mums on the 0..n or 1..n rela­tion­ships, the­se can be inc­lu­ded in the bounds for con­text. For exam­ple, the PO for SeiSounds might want to spe­ci­fy that each acco­unt can only be asso­cia­ted with a maxi­mum of five users or liste­ners to avo­id friends buy­ing one paid sub­scrip­tion and sha­ring with eve­ry­one else. See the exam­ple below:

[…] CONCLUSION Business Data Diagrams are one of tho­se MUST HAVE models for any pro­duct that is dealing with data. The exer­ci­se of cre­ating the model itself cre­ates a power­ful, sha­red under­stan­ding of the under­ly­ing data con­structs as users under­stand it. Instrumental in hel­ping to iden­ti­fy addi­tio­nal, more deta­iled models that might be needed, the BDD can also help you get to a com­ple­te set of user sto­ries aro­und users inte­rac­ting with the data fol­lo­wing the cre­ate, use, edit, dele­te, move and copy actions. (Źródło: Deep Dive Models in Agile Series: Business Data Diagram

Powyższy model:

  1. dekla­ru­je kon­kret­ną zna­ną na teraz”, war­tość limi­tu licz­by użyt­kow­ni­ków Konta,
  2. pomię­dzy auto­rem, utwo­rem i sta­cją jest nic nie­mó­wią­ca (każ­de z każ­dym bez żad­nych ogra­ni­czeń) zależność,
  3. pozo­sta­łe ele­men­ty nie wno­szą war­to­ści doda­nej (utwór jest cechą arty­sty czy może arty­sta jest cechą utworu…).

Zaryzykuję tezę, że powyż­sze w zasa­dzie nie poma­ga deve­lo­pe­ro­wi w niczym. Czy wno­si coś do pro­jek­tu? W moich oczach sta­no­wi pro­ste zapi­sa­nie” tego co zezna­li inda­go­wa­ni zama­wia­ją­cy (arty­kuł zawie­ra opis histo­ry­jek użyt­kow­ni­ka i ich koja­rze­nia z tym mode­lem danych). Stwierdzenie zaś, że …spe­ci­fic busi­ness rules in the sys­tem that set maxi­mums on the 0..n or 1..n rela­tion­ships…, (np. mak­si­mum pię­cio­ro użyt­kow­ni­ków może jed­no­cze­śnie słu­chać), to nie regu­ła biz­ne­so­wa a kry­te­rium decy­zyj­ne (wię­cej o regu­łach biz­ne­so­wych w lite­ra­tu­rze). 

Trzeba sobie tu jasno powie­dzieć, że induk­cyj­ne podej­ście do ana­li­zy (zbie­ra­nie i zapi­sy­wa­nie obser­wa­cji w celu iden­ty­fi­ka­cji tren­du lub powtó­rzeń) przy­po­mi­na pró­by zro­zu­mie­nia gry w sza­chy meto­dą wie­lo­krot­nej obser­wa­cji roz­gry­wek. Im wier­niej­szy opis gry ma powstać, tym wię­cej obser­wa­cji nale­ży udo­ku­men­to­wać, co nie zmie­nia fak­tu, że taki doku­ment nie mówi abso­lut­nie nic o przy­szłych roz­gryw­kach. Alternatywą jest deduk­cyj­ne podej­ście, pole­ga­ją­ce na zro­zu­mie­niu i opra­co­wa­niu, moż­li­wie naj­mniej­szym nakła­dem pra­cy, reguł gry w sza­chy, cze­go udo­ku­men­to­wa­nie wyma­ga naj­wy­żej dwóch stron papie­ru A4, taki doku­ment opi­su­je tak­że w 100% wszyst­kie przy­szłe roz­gryw­ki… 

Jak inaczej podejść do tego? 

Na począ­tek nale­ży zro­zu­mieć dzie­dzi­nę pro­ble­mu i opi­sać ją słownikiem:

Powyższy model poję­cio­wy (dia­gram nota­cji SBVR, dia­gram klas nota­cji UML) to słow­nik pojęć a nie model danych. To dia­gram obra­zu­ją­cy poję­cia i kon­tek­sto­we związ­ki mię­dzy nimi (tym kon­tek­stem są fak­ty z dzie­dzi­ny ana­li­zo­wa­ne­go pro­ble­mu). Nie są to ani dane ani regu­ły biz­ne­so­we. Są to nazwy, a nie byty sys­te­mo­we”. Poza takim dia­gra­mem, nale­ży tak­że stwo­rzyć słow­nik pojęć biz­ne­so­wych w posta­ci tabe­li zawie­ra­ją­cej pre­cy­zyj­ne, dzie­dzi­no­we defi­ni­cje tych pojęć. Dla wygo­dy i pre­zen­ta­cji ich tre­ści nanio­słem dwie regu­ły na dia­gram, są sko­ja­rzo­ne z Kontem gdyż jego doty­czą. Co do zasa­dy regu­ły biz­ne­so­we są koja­rzo­ne z ele­men­ta­mi na innych dia­gra­mach poprzez sło­wa zdefiniowane.

Cała ana­li­za powin­na się zaczy­nać od udo­ku­men­to­wa­nia mode­li pro­ce­sów. Tu pomi­ną­łem te mode­le bo ich opi­sów jest na moim blo­gu wie­le, a chcę się sku­pić na dzie­dzi­nie dla jakiej powsta­je apli­ka­cja. Analiza i zro­zu­mie­nie pro­ble­mu pro­wa­dzi do stwo­rze­nia mode­lu dzie­dzi­ny apli­ka­cji. Taki model powsta­je na pod­sta­wie tre­ści doku­men­tów wewnętrz­nych i zewnętrz­nych (tu np. Ustawa o pra­wach autor­skich), poma­ga­ją co naj­wy­żej bie­żą­ce wyja­śnie­nia. Do jego powsta­nia nie są potrzeb­ne żad­ne warsz­ta­ty ani cało­dzien­ne spotkania.

Celem mode­lo­wa­nia dzie­dzi­ny sys­te­mu (tu apli­ka­cji) jest udo­ku­men­to­wa­nie wewnętrz­nej logi­ki apli­ka­cji, czy­li mecha­ni­zmu jej dzia­ła­nia. Absolutnie nie jest to model danych. Powyższy model nie jest mode­lem ukoń­czo­nym”, wyma­ga na pew­no dopra­co­wa­nia, jed­nak moim celem jest jedy­nie poka­za­nie idei jego two­rze­nia. Nazwy klas, atry­bu­tów, ope­ra­cji zawie­ra­ją poję­cia zawar­te w słow­ni­ku pojęć. Zapewnia to jed­no­znacz­ność i zro­zu­mie­nie. Dodam, że dopie­ro ten model poka­zu­je bar­dzo waż­ną rzecz, to że autor jest cechą utwo­ru a nie odwrotnie. 

Tak więc:

  1. uru­cho­mie­nie i korzy­sta­nie z emi­sji kon­tro­lo­wa­ne jest przez Zarządzanie emi­sją, tu spraw­dza­ne są i egze­kwo­wa­ne, regu­ły biznesowe, 
  2. kom­po­nent Zarządzanie emi­sją korzy­sta tak­że z infor­ma­cji zawar­tych w Koncie użyt­kow­ni­ka i Playlisty, deta­le utwo­rów pobie­ra z Repozytorium utworów. 

Tu waż­ne jest pod­kre­śle­nie, że regu­ła doty­czą­ca ogra­ni­cze­nia licz­by jed­no­cze­śnie słu­cha­ją­cych, jest oddzie­lo­na od Kont użyt­kow­ni­ków i (nie poka­za­nych tu) Subskrypcji. Dzięki temu para­metr ten jest łatwo mody­fi­ko­wal­ny z pozio­mu apli­ka­cji (para­me­try­zo­wa­ne kry­te­rium decy­zyj­ne) bez potrze­by jakich­kol­wiek inge­ren­cji w model danych”. Umieszczanie jakich­kol­wiek reguł w bazie danych (czy­li na pozio­mie imple­men­ta­cji utrwa­la­nia) jest nie­ste­ty ich beto­no­wa­niem”.

Zmienność, nie tyl­ko ryn­ku ale i samych reguł w orga­ni­za­cjach, to sta­ły ele­ment śro­do­wi­ska apli­ka­cji. Dlatego dobrą prak­ty­ką jest, by utrwa­la­nie danych (wszel­kie bazy danych, pli­ki itp..) nie słu­ży­ło do nicze­go poza utrwa­la­niem. Logika biz­ne­so­wa powin­na być w w 100% w apli­ka­cji a nie podzie­lo­na pomię­dzy apli­ka­cję i dane (żad­na baza danych nie jest w sta­nie prze­cho­wy­wać innych reguł biz­ne­so­wych niż bez­po­śred­nie związ­ki ilo­ścio­we). Na eta­pie imple­men­ta­cji, sto­su­je­my zasa­dę her­me­ty­za­cji, czy­li nie współ­dzie­li­my, na żad­nym pozio­mie, danych pomię­dzy repo­zy­to­ria­mi i nie usu­wa­my redun­dan­cji. Dzięki temu nie odci­na­my sobie dro­gi do zmian sys­te­mu takich jak np. zastą­pie­nie kla­sy Dane oso­bo­we inter­fej­sem do zewnętrz­ne­go sys­te­mu, dys­po­nu­ją­ce­go taki­mi infor­ma­cja­mi (kla­sa ta zosta­nie zmie­nio­na, sta­nie się wte­dy mostem do API zewnętrz­ne­go sys­te­mu co nie pocią­gnie za sobą jakich­kol­wiek zmian, bo inter­fejs tej kla­sy i jej nazwa pozo­sta­ną nie­zmie­nio­ne, patrz zasa­da open-clo­se prin­ci­pia oraz polimorfizm).

Poniżej klu­czo­we związ­ki w UML i ilu­stra­cja związ­ku pomię­dzy mode­lem poję­cio­wym a mode­lem struk­tu­ry (archi­tek­tu­ry, to model dziedziny):

Na zakoń­cze­nie war­to zauwa­żyć, że zmien­ność śro­do­wi­ska biz­ne­so­we­go powo­du­je, że żad­ne decy­zje o logi­ce biz­ne­so­wej nie są osta­tecz­ne, jed­nak są ele­men­ty nie­zmien­ne takie jak np. nasze dane oso­bo­we. Tak więc to, co powszech­nie nazy­wa­ne jest mode­lem danych” (busi­ness data dia­gram) w rozu­mie­niu opi­sa­nym przez autor­ki arty­ku­łu, nie ma dzi­siaj racji bytu. Ma sens zacho­wa­nie zamó­wie­nia i osob­no fak­tu­ry, ale to czy regu­łą jest jed­no zamó­wie­nie do jed­nej fak­tu­ry, pod­le­ga zmia­nom wyni­ka­ją­cym i ze zmien­no­ści pra­wa i ze zmien­no­ści mode­li biz­ne­so­wych. Nie widzę żad­ne­go powo­du dekla­ro­wa­nia już na począt­ku pro­jek­tu, tego by nie wię­cej niż 5 osób mogło korzy­stać z jed­ne­go kon­ta i sub­skryp­cji. W szcze­gól­no­ści nie widzę powo­du by taka zasa­da była zawar­ta w samym kodzie aplikacji.

Warto tak­że mieć na uwa­dze to, że opro­gra­mo­wa­nie może być two­rzo­ne z uży­ciem zewnętrz­nych kom­po­nen­tów dostęp­nych na ryn­ku. Założenie więc na samym począt­ku pro­jek­tu, że dane są w jed­no­li­ty spo­sób prze­cho­wy­wa­ne i współ­dzie­lo­ne w jed­nej cen­tral­nej i współ­dzie­lo­nej bazie danych, wraz z logi­ką ich uży­cia, jest tu nie tyl­ko nie­uza­sad­nio­ne ale wręcz szkodliwe. 

I na koniec grat­ka: dokład­nie ta powsta­ła, i nadal tak wyglą­da, znacz­na więk­szość obec­nych na ryn­ku sys­te­mów ERP, CRM itp.… 

oraz cytat z literatury

z 1994 roku:

(źr. Designing Objects Systems, Steve Cook, John Daniels, 1994 rok.)

Inne artykuły na podobny temat

image_print(wydruk PL)

Komentarze

  1. Sławek S. 3 lutego 2017 at 19:14

    Jako eks-deve­lo­per potwier­dzam: polu­cje typu dia­gram rze­czow­ni­ków w niczym nie pomagają.
    Ciekawe ujął to zna­ko­mi­ty G. Weinberg w https://​www​.ama​zon​.com/​R​e​t​h​i​n​k​i​n​g​-​S​y​s​t​e​m​s​-​A​n​a​l​y​s​i​s​-​D​e​s​i​g​n​-​W​e​i​n​b​e​r​g​/​d​p​/​0​9​3​2​6​3​3​080

    Można mode­lo­wać:
    – being – struk­tu­ry danych
    – beha­ving – zacho­wa­nia i reguły
    – beco­ming – zmiany

    To pierw­sze pozwa­la zadać mało sen­sow­nych pytań: co to ma, jakie­go typu to jest, ile tego jest.
    Dwa kolej­ne pozwa­la­ją zadać masę sen­sow­nych pytań: kie­dy się, dla­cze­go, kto to zmie­nia, czy moż­na to powtó­rzyć lub odwró­cić, jak czę­sto się zmienia,.…

    • Jaroslaw Zelinski 3 lutego 2017 at 19:40

      No i jestem zno­wu lżej­szy o kil­ka­na­ście dolców 😉 … dziękuję 😀

    • Marek Bisztyga 5 lutego 2017 at 11:22

      Cześć.
      Od razu przy­zna­ję się – nie czy­ta­łem Weinberga, ale zapo­zna­jąc się (przy­zna­ję pobież­nie) z dige­sta­mi jego książ­ki, odno­szę wra­że­nie, że cho­dzi o jakieś archi­tek­to­nicz­ne podej­ście w SE. Rzeczywiście, roz­wią­zu­je wie­le pro­ble­mów , w szcze­gó­no­ści brak osa­dza­nia mode­li obiek­tów biz­ne­so­wych (danych) w kon­tek­ście dyna­micz­nym oraz brak sepa­ra­cji reguł biz­ne­so­wych i zaszy­wa­nie ich w mode­lu danych, cze­go dziś już od daw­na, o ile wiem, nie ptrak­ty­ku­je się. Biorąc pod uwa­gę rok publi­ka­cji książ­ki (1988), zary­zy­ku­ję stwier­dze­nie, że w świa­do­mo­śći wie­lu ana­li­ty­ków pro­blem został już daw­no uświa­do­mio­ny i roz­wią­za­ny . Nie wyklu­czam jed­nak, że nawet po tylu latach książ­ka wciąż zacho­wu­je świe­żość spojrzenia.
      Pozdrawiam,
      Marek

    • Jaroslaw Zelinski 5 lutego 2017 at 11:49

      Ta książ­ka ma swo­je kolej­ne wyda­nia, zaś podej­ście bazu­ją­ce na osa­dza­niu całych sys­te­mów na jed­nym rela­cyj­nym sys­te­mie bazo­da­no­wym jest od lat kry­ty­ko­wa­ne jako nie­sku­tecz­ne i wręcz szko­dli­we (pierw­sze publi­ka­cje D’Souzy na temat sku­tecz­no­ści her­me­ty­zo­wa­nych archi­tek­tur kom­po­nen­to­wych uka­za­ły się ponad 20 lat temu). Parcie na sto­so­wa­nie sys­te­mów rela­cyj­nych baz danych ma dwa źró­dła: kor­po­ra­cje zara­bia­ją­ce na tym miliar­dy oraz nadal popu­lar­ne kon­cep­cje dają­ce wia­rę w ist­nie­nie jed­nej onto­lo­gii. Ontologia (jako jeden uni­wer­sal­ny sys­tem zna­czeń i pojęć) to meta­fi­zy­ka, od któ­rej pozy­tyw­na filo­zo­fia ode­szła już chy­ba w latach 30-tych. Umberto Eco, chy­ba naj­słyn­niej­szy semio­tyk (poza tym, ze pisarz i filo­zof), daw­no wyka­zał, że nie da się ode­rwać zna­cze­nia sło­wa od kon­tek­stu jego uży­cia co potwier­dza teo­ria komu­ni­ka­cji (ludz­kie języ­ki mają mniej znaków/słów niż zna­czeń, co tłu­ma­czy ist­nie­nie i potrze­bę słów wie­lo­znacz­nych). Innymi sło­wy: poza wąsko kon­tek­sto­wym sys­te­mem, nie ma jest moż­li­we opi­sa­nia świa­ta” jed­nym spój­nym sys­te­mem nazw. Walczą z tym, nadal bez żad­nych suk­ce­sów, wyznaw­cy uni­wer­sal­nej inte­ro­pe­ra­cyj­no­ści sys­te­mów IT. 

    • Marek Bisztyga 5 lutego 2017 at 12:45

      Jako że od lat jestem moc­no prze­su­nię­ty w poglą­dach w kie­run­ku podej­ścia archi­tek­to­nicz­ne­go w ana­li­zie, myśle­nie rela­cyj­ne pozo­sta­wi­łem deve­lo­pe­rom. Dziś czę­ściej skła­niam się ku mode­lom i narzę­dziom gra­fo­wym (np. ostat­nio ćwi­czę Neo4J). Co do tezy na temat onto­lo­gii intu­icyj­nie zga­dzam się (intu­icyj­nie bo brak mi„papierów” z tej dzie­dzi­ny). Natomiast potwie­dzam, że zna­ne mi pró­by pro­jek­to­wa­nia dużych sys­te­mów w opar­ciu o tzw. kano­nicz­ne mode­le danych nie koń­czą się naj­le­piej. Przynajmniej ja nie mam pozy­tyw­nych doświadczeń.

    • Jaroslaw Zelinski 5 lutego 2017 at 14:45

      No to mamy podob­ne doświadczenia 🙂 …
      W kwe­stii Neo4 – może się mylę – to powtór­ne odkry­wa­nie koła, pole­cam spe­cy­fi­ka­cję nota­cji i sys­te­mu poję­cio­we­go SBVR (omg​.org).

    • Marek Bisztyga 5 lutego 2017 at 15:23

      A pro­pos Neo4J, rze­czy­wi­ście idea jest sta­ra, ale za to w nowym opakowaniu.

      Czy zna­cie , Koledzy, jakieś narząd­ko, na któ­rym moż­na­by wpra­wiać się w SBVR?

    • Jaroslaw Zelinski 5 lutego 2017 at 15:25

      Np. Visual-Paradigm 😉
      Narzędzie ma zaim­ple­men­to­wa­ny cały SBVR czy­li: słow­nik biz­ne­so­wy, dia­gram fak­tów i regu­ły biznesowe.…

    • Marek Bisztyga 5 lutego 2017 at 16:04

      Dzięki. Zainstalowałem demo i bio­rę się za SBVR.

  2. Jaroslaw Zelinski 5 lutego 2017 at 15:16

    O tym, że budo­wa­nie kon­tek­sto­wych kom­po­nen­tów roz­wią­zu­je pro­ble­my onto­lo­gii i kano­icz­nych ogól­nych” modeli:
    https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​B​o​u​n​d​e​d​C​o​n​t​e​x​t​.​h​tml

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.