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

Udziałowcy projektu czyli który diagram UML …

W bar­dzo cie­ka­wym arty­ku­le o iden­ty­fi­ko­wa­niu udzia­łow­ców” pro­jek­tu (pole­cam: How to Effectively Engage Requirement Contributors to Achieve Project Success) autor opi­sał isto­tę ana­li­zy wpły­wu oto­cze­nia (pod­mio­ty zewnętrz­ne) i udzia­łow­ców na pro­jekt two­rze­nia (dostar­cze­nia) opro­gra­mo­wa­nia, bar­dzo waż­ne­go eta­pu ana­li­zy biznesowej.

Osobiście jestem gorą­cym zwo­len­ni­kiem trak­to­wa­nia opro­gra­mo­wa­nia jako zesta­wu narzę­dzi pra­cy i środ­ków do jej wyko­ny­wa­nia (ang. meta­fo­ra tools&materials czy­li opro­gra­mo­wa­nie to narzę­dzia i mate­ria­ły). Wtedy łatwiej umie­ścić” sobie wyobra­że­nie powsta­ją­ce­go opro­gra­mo­wa­nia w naszym oto­cze­niu. To pocią­ga za sobą potrze­bę zro­zu­mie­nia tego oto­cze­nia” i jego wpły­wu na nasz pro­jekt. Tu poja­wia się drob­ny niu­ans”. Analiza sys­te­mo­wa wyma­ga jed­no­znacz­ne­go okre­śla­ne gra­ni­cy Systemu i okre­śle­nia czym on jest. W swo­ich pro­jek­tach defi­niu­ję to tak:

System to opro­gra­mo­wa­nie, któ­re powsta­nie oraz pro­jekt, któ­re­go jest on pro­duk­tem. Dzięki takiej defi­ni­cji wiem, że jeże­li coś ma wpływ na pro­jekt two­rze­nia opro­gra­mo­wa­nia to ma tak­że wpływ na samo opro­gra­mo­wa­nie, jeże­li coś ma wpływ na powsta­ją­ce opro­gra­mo­wa­nie to ma tak­że wpływ na zarzą­dza­nie pro­jek­tem jego wytworzenia.

Dlatego na eta­pie ana­li­zy wpły­wów oto­cze­nia, utoż­sa­miam pro­jekt z jego pro­duk­tem. Analiza wpły­wu oto­cze­nia na pro­jekt ma na celu (źr. wspo­mnia­ny artykuł):

  1. Identyfikację insty­tu­cji regu­lu­ją­cych (ogra­ni­cza­ją­cych) dzia­ła­nie pod­mio­tu dla któ­re­go powsta­je narzę­dzie, to ogra­ni­cze­nie prze­no­si się na System bo musi on być zgod­ny z tymi ograniczeniami,
  2. Identyfikację tego, kto w oto­cze­niu dostar­cza a kto kon­su­mu­je dane (wyma­ga­ne i prze­twa­rza­ne przez System oraz wytworzone),
  3. Identyfikację wszyst­kich interfejsów

Moim zda­niem pod­mio­ty iden­ty­fi­ko­wa­ne w punk­tach punk­tach 2 i 3 moż­na potrak­to­wać łącz­nie, gdyż inter­fejs jest narzę­dziem wymia­ny danych, więc iden­ty­fi­ka­cja daw­cy lub bior­cy danych impli­ku­je posta­wie­nia wyma­ga­nia na inter­fejs. Warto jedy­nie zazna­czyć czy w danym wypad­ku cho­dzi o czło­wie­ka czy o inny sys­tem, jed­nak z per­spek­ty­wy ana­liz sys­te­mo­wej obaj są Aktorami Systemu. Rozróżnienie to jed­nak ma kon­se­kwen­cje w posta­ci budo­wy typu inter­fej­su: gra­ficz­ny użyt­kow­ni­ka czy komu­ni­ka­cyj­ny (sys­tem – system).

Modelowanie zależ­no­ści pomię­dzy udziałowcami

Autor arty­ku­łu słusz­nie zauwa­ża, że etap ana­li­zy udzia­łow­ców pro­jek­tu jest bar­dzo waż­ny, wska­zu­je na klu­czo­we korzy­ści pły­ną­ce z tej fazy ana­li­zy, są to:

  1. zro­zu­mie­nie skut­ków wpro­wa­dza­nych zmian oraz wpły­wu na zakres pro­jek­tu i jego miary,
  2. mini­ma­li­zo­wa­nie ryzy­ka powsta­nia złej spe­cy­fi­ka­cji wyma­gań (roz­mi­ja­nie się z praw­dzi­wy­mi potrzebami),
  3. jasne i zro­zu­mia­łe prze­ka­za­nie ocze­ki­wań oraz ról w pro­jek­cie, każ­de­go zain­te­re­so­wa­ne­go” a nale­żą do nich spon­so­rzy pro­jek­tu i przy­szli użyt­kow­ni­cy powsta­ją­ce­go systemu.

W począt­ko­wej fazie pro­jek­tu bar­dzo waż­ne jest to ostat­nie, gdyż pomył­ka tu potra­fi zni­we­czyć wszyst­kie pozo­sta­łe wysiłki.

Tu jed­nak poja­wia się pro­blem w tre­ści arty­ku­łu. Użyto w nim pew­nych mode­li (dia­gra­mów) nie­co” nagię­tych seman­tycz­nie. Pojęcia (uży­te dia­gra­my i ich ele­men­ty) są nie­co prze­mie­sza­ne i nie zacho­wu­ją spój­no­ści zna­czeń uży­tych sym­bo­li. Czy to aż takie złe? Niestety tak. Dlaczego? Notacja UML (jak każ­da) to pewien sys­tem poję­cio­wy: zestaw pojęć i ich defi­ni­cji. Łamanie ich, ten sam sym­bol uży­wa­ny do wyra­że­nia róż­nych pojęć, pro­wa­dzi do utra­ty jed­no­znacz­no­ści mode­li i nieporozumień.

Diagramy auto­ra artykułu:

business-contexst-diagram

udzia­łow­cy:

stakeholder-relationship-model

Autor powyż­szych dia­gra­mów (i wymie­nio­ne­go we wstę­pie arty­ku­łu) nazwał pierw­szy Diagram prze­pły­wu danych (ang. DFD, Data Flow Diagram) pozio­mu zero” a dru­gi, dia­gra­mem zależ­no­ści udzia­łow­ców pro­jek­tu. Formalnie DFD nie zawie­ra poję­cia aktor, powyż­sze to dia­gram aktyw­no­ści UML (popraw­ny). W UML akto­rem jest każ­dy zewnętrz­ny byt, będą­cy bene­fi­cjen­tem usłu­gi świad­czo­nej przez System. Pojęcia «External Entity» w nota­cji DFD ozna­cza zewnętrz­ne obiek­ty” (źró­dła danych lub ich cel), w UML nie ma ono odpo­wied­ni­ka jako odręb­ne poję­cie (UML i para­dyg­mat obiek­to­wy nie ope­ru­ję poję­ciem danych).

Ogólnie w UML strzał­ki prze­ry­wa­ne mają zna­cze­nie Zależy od” (jest bior­cą usłu­gi) i jako takie mają tu zły kie­ru­nek, gdyż sym­bol zależ­no­ści w UML to wska­za­nie na obiekt, od któ­re­go coś jest uza­leż­nio­ne, lub z usług cze­go korzy­sta. Tu strzał­ki obra­zu­ją coś, co autor nazwał kie­ru­nek prze­pły­wu”, co jest nie­po­praw­ne bo ta strzał­ka” w UML nie ozna­cza prze­pły­wu. Tak więc powy­żej Pilot nie zale­ży od Lotu a jest raczej odwrot­nie. Umieszczenie takie­go dia­gra­mu w doku­men­ta­cji zawie­ra­ją­cej inne dia­gra­my UML pra­wie na pew­no dopro­wa­dzi do nie­po­ro­zu­mień (dia­gram zosta­nie źle zin­ter­pre­to­wa­ny). Jeżeli Załoga (CabinCrew) świad­czy usłu­gi Pasażerowi, to strzał­ka powin­na mieć kie­ru­nek prze­ciw­ny (Pasażer korzy­sta, jest zależ­ny, z usług Załogi). Jeżeli inten­cją było zobra­zo­wa­nie prze­pły­wu nale­ża­ło utwo­rzyć inny dia­gram, tym bar­dziej, że powyż­szy dia­gram nie poka­zu­je, co tak na praw­dę prze­pły­wa od Załogi do Pasażera (?). Jednak zacho­wu­jąc seman­ty­kę UML, dia­gram taki moż­na utworzyć. 

Jak to powin­no wyglą­dać poprawnie?

UML i diagramy przypadków użycia jako model udziałowców

Pomijając samą nazwę (przy­pad­ki uży­cia), dia­gra­my te pozwa­la­ją na mode­lo­wa­nie pojęć takich jak:

  1. System, czy­li byt (jakieś np. opro­gra­mo­wa­nie) świad­czą­cy jakieś usłu­gi (cechu­ją­cy się jaki­miś funkcjonalnościami),
  2. Aktor czy­li zewnętrz­ny wzglę­dem sys­te­mu byt, mają­cy bez­po­śred­nią lub pośred­nią inte­rak­cję z systemem,
  3. Zależność, czy­li wska­za­nie pary obiek­tów będą­cych w rela­cji klient-usłu­go­daw­ca”, klient jest uza­leż­nio­ny od usługodawcy,
  4. Realizacja czy­li wska­za­nie pary obiek­tów, gdzie jeden (imple­men­ta­cja) jest fizycz­ną reali­za­cją dru­gie­go (ide­ali­za­cja, model).

Dla roz­róż­nie­nia akto­rów na oso­by (fizycz­ne) i inne sys­te­my moż­na użyć ste­reo­ty­pów. Na dia­gra­mie wyglą­da to tak (zmie­ni­łem kon­tekst na wła­sny przykład):

model-kontekstowy-dla-projektu-dostarczenia-systemu

System kon­kret­ny to jakieś ist­nie­ją­ce opro­gra­mo­wa­nie wyma­ga­ją­ce inte­gra­cji. Inny sys­tem to zgod­na z UML abs­trak­cja Aktora Projektowanego Systemu (System kon­kret­ny jest jego Realizacją). Aktorzy mogą zale­żeć od sie­bie a tak­że od Projektowanego Systemu. Projektowany System może zale­żeć od Aktora. Jak to wyglą­da real­nie” czy­li na kon­kret­nym przykładzie?

model-kontekstowy-dla-projektu-dostarczenia-systemu-2

Powyższy dia­gram, w peł­ni zgod­ny z UML, ma nastę­pu­ją­ce zalety:

  1. Użyte poję­cia są god­ne ze stan­dar­dem a więc nie pro­wa­dzą do nie­jed­no­znacz­no­ści w inter­pre­ta­cji modeli,
  2. Narzędzia typu CASE bez pro­ble­mu pozwo­lą nary­so­wać powyż­sze, a ele­men­ty tego dia­gra­mu mogą posłu­żyć zgod­nie z UML, jako kla­sy­fi­ka­to­ry dal­szych, pod­le­głych (zależ­nych), ele­men­tów mode­lu (obiek­tów i innych diagramów),
  3. Model popraw­nie odwzo­ro­wu­je mode­lo­wa­ne ele­men­ty bez zapo­ży­cza­nia zna­czeń z innych, nie­obiek­to­wych, nota­cji i bez łama­nia zasad UML a więc model jest jed­no­znacz­ny i weryfikowalny.

Wydaje mi się, że powyż­szy dia­gram nie wyma­ga komen­ta­rza. Diagramy takie sto­su­ję jako ele­ment doku­men­ta­cji biz­ne­so­wej, przed­sta­wia­nej spon­so­ro­wi pro­jek­tu do zatwier­dze­nia. Są one czy­tel­ne, nazy­wa się je tak­że ana­li­zą inte­re­sa­riu­szy” (ja sta­ram się uni­kać tego dziw­ne­go tłu­ma­cze­nia sło­wa sta­ke­hol­ders).

Stosowanie reguł (seman­ty­ki i syn­tak­ty­ki) UML pozwa­la utrzy­mać spój­ność mode­li zależ­nych (pod­le­głe temu dia­gra­mo­wi uszcze­gó­ło­wie­nia Projektu Systemu, reali­za­cja Aktorów, przy­pad­ki uży­cia itp.) oraz zacho­wać spój­ność logicz­ną i poję­cio­wą całej doku­men­ta­cji. To zaś jest warun­kiem wery­fi­ka­cji popraw­no­ści całe­go projektu.

UML to nota­cja, któ­rej klu­czo­wym poję­ciem jest kla­sy­fi­ka­tor (opar­ta jest na defi­nio­wa­nych poję­ciach i rela­cjach mię­dzy nimi) dla­te­go war­to prze­strze­gać (zawsze war­to) zasad nota­cji i np. nie utoż­sa­miać Aktora System CRM (jest to jakaś abs­trak­cja sys­te­mu inte­gro­wa­ne­go) z kon­kret­nym Jakimś Systemem CRM. Aktor ma kon­kret­ne zna­cze­nie na dia­gra­mie UML (zde­fi­nio­wa­ne wyżej) i kon­kret­ny sys­tem tak­że. Zachowanie tego podzia­łu (abs­trak­cja i jej reali­za­cja) pozwa­la zde­fi­nio­wać oddziel­nie wyma­ga­nia i oddziel­nie kon­kret­ne roz­wią­za­nia je speł­nia­ją­ce, co jest isto­tą roz­dzia­łu wyma­gań od speł­nia­ją­cych je roz­wią­zań (a tak­że meto­dy­ki MDA roz­dzie­la­ją­cej pro­jekt od jego implementacji).

Diagramy przy­pad­ków uży­cia są bar­dzo waż­ny­mi dia­gra­ma­mi, gdyż sta­no­wią korzeń” mode­lu reali­za­cji sys­te­mu zaś łama­nie zasad nota­cji już na począt­ku pro­jek­tu pro­wa­dzi prak­tycz­nie zawsze do utra­ty moż­li­wo­ści ich, mode­li, weryfikacji.

[czer­wiec 2020] Po pew­nej dys­ku­sji doda­łem tu powyż­szy dia­gram, pyta­nie brzmia­ło jak poka­zać na dia­gra­mie sytu­acje opi­sa­ną tu tek­stem (diagramDescription).

Udziałowcy projektu

Uzupełnieniem mode­lu wpły­wu udzia­łow­ców pro­jek­tu jest ich spe­cy­fi­ka­cja. Tu wypa­da tyl­ko przy­tak­nąć auto­ro­wi arty­ku­łu, zale­ca on by każ­de­go akto­ra opi­sać atrybutami:

  1. opis,
  2. dane kon­tak­to­we,
  3. ocze­ki­wa­nia (akto­ra wzglę­dem systemu),
  4. w jakiej dzie­dzi­nie jest spe­cja­li­stą (eks­pert dziedzinowy),
  5. wpły­wy w orga­ni­za­cji (for­mal­ne i nieformalne),
  6. cele.

Osobiście jestem zwo­len­ni­kiem cał­ko­wi­tej jaw­no­ści komu­ni­ka­cji w pro­jek­tach dla­te­go nie sto­su­ję poję­cia nie­for­mal­ne­go wpły­wu” w pro­jek­tach. To pozwa­la mi z jed­nej stro­ny upro­ścić zarzą­dza­nie doku­men­ta­cja pro­jek­to­wą (mam jed­ną wer­sję dostęp­ną dla Zamawiającego i Wykonawcy) a dru­giej nie nara­żam innych na ryzy­ko przy­pad­ko­we­go odkry­cia” infor­ma­cji nie­for­mal­nych, mogą­cych być dla jed­nej ze stron pro­jek­tu powo­dem emo­cji”.

Analiza RACI

W przy­pad­ku udzia­łow­ców pro­jek­tu dobrą prak­ty­ką jest budo­wa pro­stej macie­rzy RACI (klik­nij po opis tego narzę­dzia). Co do zasa­dy przyj­mu­je się, że każ­dy obszar pro­jek­tu ma:

  1. jed­ną oso­bę (lub gro­no osób, komi­tet) odpo­wie­dzial­ną za reali­za­cję (Responsible),
  2. jed­na oso­bą (lub gro­no osób, komi­tet) akcep­tu­ją­cą zakres (Accauntable/Approver),
  3. oso­by, któ­rych opi­nie mogą lub muszą być uwzględ­nia­ne, eks­per­ci dzie­dzi­no­wi (Consulted),
  4. oso­by, któ­re muszą być na bie­żą­co infor­mo­wa­ne o postę­pach pro­jek­tu (Informed).

Określenie roli każ­de­go udzia­łow­ca w sto­sun­ku do każ­de­go z wyma­gań pozwa­la usta­lić w pro­jek­cie jed­no­oso­bo­wą odpo­wie­dzial­ność po stro­nie Zamawiającego. Ja oso­bi­ście sto­su­ję tę meto­dę jed­nak w sto­sun­ku do obsza­rów dzie­dzi­no­wych lub grup wyma­gań. Użycie macie­rzy RACI w sto­sun­ku do poje­dyn­czych wyma­gań jest chy­ba zbyt dro­bia­zgo­wym podej­ściem. Takie uogól­nie­nie daje jako efekt rela­tyw­nie mniej zło­żo­ne doku­men­ty, a wiec łatwiej­sze w percepcji.

Uwaga na zakończenie

Model kon­tek­sto­wy sys­te­mu („udzia­łow­ców”) nie jest dia­gra­mem mode­lu­ją­cym wyma­ga­nia, więc nie nale­ży na nim umiesz­czać przy­pad­ków uży­cia sys­te­mu (mimo, że uży­wa­my zesta­wu pojęć UML z gru­py Przypadki użycia). 

Dobrą prak­ty­ką two­rze­nia mode­li (tak­że w w UML) jest two­rze­nie dia­gra­mów w jed­nym kon­tek­ście. Umieszczanie na jed­nym dia­gra­mie wszyst­kie­go co wie­my i co moż­na poka­zać” pro­wa­dzi to utrud­nie­nia per­cep­cji tych dia­gra­mów, a nie raz wręcz do utra­ty kon­tek­stu i co za tym idzie, ich zro­zu­mia­ło­ści w ogóle.

Zwracam tu tak­że uwa­gę, że dia­gram ten to nie rela­cje zna­ne z mode­li danych. Po pierw­sze nie są to (Aktor czy System) dane, po dru­gie zwią­zek logicz­ny pomię­dzy dany­mi to zupeł­nie inne poję­cie niż zależ­ność klient-usłu­go­daw­ca”. Jeżeli wia­do­mo co ozna­cza fakt, że opro­gra­mo­wa­nie świad­czy pew­ną usłu­gę akto­ro­wi to inter­pre­ta­cja rela­cji encja sys­tem i encja aktor” mogła by tu być trud­na do inter­pre­ta­cji. Po dru­gie encje w mode­lach ERD to byty pasyw­ne, cze­go nie moż­na powie­dzieć o Udziałowcach i Systemach, dla­te­go mode­lo­wa­ne są tu w para­dyg­ma­cie obiek­to­wym nota­cją UML.