Wstęp

Swego cza­su napi­sa­łem tekst o nie­jed­no­znacz­no­ści tre­ści w doku­men­ta­cji jako źró­dle kło­po­tów w pro­jek­tach: Analityk biz­ne­so­wy czy­li wyple­nić dwu­znacz­ność… Warto pamię­tać, że:

Bałagan poję­cio­wy w rapor­cie z ana­li­zy, powo­du­je, że raport nie pozwa­la na jego jed­no­znacz­ną inter­pre­ta­cję, co prak­tycz­nie dys­kwa­li­fi­ku­je go jako przy­dat­ne źró­dło infor­ma­cji w projekcie.

Dzisiaj kon­ty­nu­acja tej tezy w kon­tek­ście powsta­ją­cych mode­li, ich tre­ści i szczegółowości.

Proces, sekwencja, scenariusz 

Weźmy np. dość czę­sto poja­wia­ją­ce się poję­cia: ​„pro­ces sys­te­mo­wy” czy też ​„sys­tem” w mode­lu pro­ce­su biz­ne­so­we­go, sekwen­cje i dia­gra­my sekwen­cji itp. Spotykam się nie­ste­ty z masą beł­ko­tu i here­zji w doku­men­tach, na blo­gach czy nawet w książ­kach… Na listach dys­ku­syj­nych LinkedIn widać, że pro­blem nie doty­czy tyl­ko nasze­go kra­ju :). Przyczyną tych pro­ble­mów jest prak­tycz­nie zawsze igno­ro­wa­nie defi­ni­cji pojęć tak języ­ko­wych (język w jakim pisa­na jest doku­men­ta­cja) jak i nota­cyj­nych (igno­ro­wa­nie lub po pro­stu nie­zna­jo­mość lub nawet nie zro­zu­mie­nie stan­dar­du). Czy nazy­wa­nie cze­goś here­zją to moje subiek­tyw­ne uzna­nie? Myślę, że nie, to porów­na­nie (audyt?) ze stan­dar­da­mi i ogól­nie uzna­ny­mi sys­te­ma­mi poję­cio­wy­mi, jed­nym z nich język ojczy­sty auto­ra dokumentu.

Najpierw kil­ka klu­czo­wych defi­ni­cji (słow­nik języ­ka pol­skie­go PWN):

pro­ces: prze­bieg nastę­pu­ją­cych po sobie i powią­za­nych przy­czy­no­wo okre­ślo­nych zmian

pro­ce­du­ra: okre­ślo­ne regu­ły postępowania

sekwen­cja: układ jakichś ele­men­tów, w któ­rym nastę­pu­ją one w okre­ślo­nej kolejności

sce­na­riusz: zapla­no­wa­ny lub prze­wi­dy­wa­ny roz­wój wydarzeń

Proces, defi­ni­cja ​„biz­ne­so­wa” mówi o pro­duk­cie pro­ce­su biz­ne­so­we­go, jest nim wła­śnie ta wpro­wa­dzo­na ​„zmia­na”. Procedura w prak­ty­ce jest regu­łą (biz­ne­so­wą). Sekwencja w UML to nic inne­go jak usta­lo­na (dla sen­su lub powo­dze­nia ope­ra­cji) kolej­ność zda­rzeń (wywo­łań). Scenariusz to poję­cie wyko­rzy­sta­ne w opi­sie przy­pad­ków uży­cia: ​„sce­na­riusz przy­pad­ku uży­cia”. W związ­ku z tym, że przy­pad­ki uży­cia są wyma­ga­niem (opi­sem uży­cia pro­duk­tu), inte­rak­cja aktor – sys­tem, ma sta­tus ​„pla­no­wa­ny”. Uznanie w pro­jek­cie, że wyma­ga­nie jest ​„OK”, daje w kon­se­kwen­cji ​„pro­jekt”, czy­li sekwen­cję opi­su­ją­cą reali­za­cję przy­pad­ku uży­cia. Jak widać, słow­nik nie jest taki zły, nota­cje i ich sys­tem poję­cio­wy w szczególności.

Porządkujemy wie­dze dalej. Zajrzyjmy do MDA Guide Version 1.0.1:

Model CIM to model opi­su­ją­cy logi­kę dzia­ła­nia (sens ist­nie­nia) mode­lo­wa­nej orga­ni­za­cji, to model tego ​„co i po co się dzie­je” a nie ​„jak i czym”. Tu nie poka­zu­je­my narzę­dzi (jakim jest np. opro­gra­mo­wa­nie). Standardem na tym pozio­mie mode­lo­wa­nia są nota­cje BMM i BPMN. Rzecz w tym, że model pro­ce­sów biz­ne­so­wych nie powi­nien zawie­rać żad­nych pojęć typu ​„sys­tem” czy ​„opro­gra­mo­wa­nie”. Dlaczego? Bo dla zro­zu­mie­nia i udo­ku­men­to­wa­nia tego jak dzia­ła orga­ni­za­cja, potrzeb­na jest wie­dza o tym jakie infor­ma­cje i jak są prze­twa­rza­ne, a nie ​„czym”.

Często widu­ję pró­by poka­za­nia na jed­nym dia­gra­mie: pra­cy ludzi, inte­gra­cji sys­te­mów, szcze­gó­łów pro­ce­dur i wszyst­ko inne, co tyl­ko autor doku­men­tu wie. To total­ne nie­po­ro­zu­mie­nie, to pokaz nie­zro­zu­mie­nia tego czym są mode­le, a są uprosz­cze­nia­mi (abs­trak­cja­mi), okre­ślo­ny­mi per­spek­ty­wa­mi ana­li­zo­wa­ne­go zjawiska.

Model PIM to obraz logi­ki dzia­ła­nia (część biz­ne­so­wa, dome­na) narzę­dzia jakim jest apli­ka­cja. Tu poja­wia się to, jakie infor­ma­cje i jak są (mają być) prze­twa­rza­ne. Model ten jed­nak nie opi­su­je szcze­gó­łów (śro­do­wi­sko apli­ka­cji, fra­me­work, roz­wią­za­nia tech­no­lo­gicz­ne np. logo­wa­nie, kodo­wa­nie, itp.), opi­su­je wyłącz­nie biz­ne­so­wą logi­kę dzia­ła­nia apli­ka­cji. Gdzie i jak to pro­jek­to­wać, poka­zać, testować?

Przytoczę po raz kolej­ny dia­gram ze stro­ny Business Process Trends:

Mamy tu trzy pozio­my mode­lo­wa­nia orga­ni­za­cji: archi­tek­tu­ra pro­ce­sów, mode­le pro­ce­sów oraz ich imple­men­ta­cja. Architekturę pro­ce­sów z regu­ły przed­sta­wia się jako wyso­ko­po­zio­mo­we uogól­nie­nie np. z pomo­cą pro­stej nota­cji zna­nej jako ​„pago­ni­ki” :):

Modele pro­ce­sów two­rzy­my z uży­ciem, nie raz tu już oma­wia­nej, nota­cji BPMN. Tu jest mowa o pro­ce­sach biz­ne­so­wych i ewen­tu­al­nych ich pod­pro­ce­sach ale nadal poziom szcze­gó­ło­wo­ści nie scho­dzi poni­żej pary ​„aktyw­ność i jej pro­dukt” (pro­ces biz­ne­so­wy). Implementacja to regu­ły wg. któ­rych reali­zo­wa­ne są poszcze­gól­ne aktyw­no­ści. Dana aktyw­ność jest reali­zo­wa­na albo na bazie umie­jęt­no­ści jej wyko­naw­cy (rola) i nie two­rzy­my jej dia­gra­mu a powo­łu­je­my się na opis sta­no­wi­ska, albo na bazie pro­ce­du­ry czy­li wyko­naw­ca danej pra­cy musi prze­strze­gać reguł narzu­co­nych pro­ce­du­rą. Procedurę spi­su­je­my w punk­tach z ewen­tu­al­ny­mi warian­ta­mi (a nie mode­lu­je­my obraz­ka­mi). Ale imple­men­ta­cja to albo wdro­że­nie pro­ce­du­ry albo wdro­że­nie oprogramowania. 

A gdzie te ​„systemowe procesy”?

Otóż nie ma cze­goś takie­go, nie w archi­tek­tu­rze opi­sy­wa­nej stan­dar­do­wo ani w BPMN ani w UML, nie ma (nie znam) w archi­tek­tu­rze kor­po­ra­cyj­nej. Mając wie­dzę o kom­po­nen­tach sys­te­mu (róż­nych apli­ka­cjach) mamy wie­dzę do cze­go zosta­ły one stwo­rzo­ne i jakie reali­zu­ją zada­nia (zna­my ich inter­fej­sy). Zaś ele­men­tem, któ­ry ini­cju­je w sys­te­mie jaką­kol­wiek sekwen­cję wyda­rzeń (inte­rak­cji mię­dzy apli­ka­cja­mi, kom­po­nen­ta­mi, obiek­ta­mi) jest zaini­cjo­wa­ny przy­pa­dek uży­cia sys­te­mu, a kon­kret­nie zda­rze­nie ini­cju­ją­ce wyge­ne­ro­wa­ne przez kon­kret­ne­go akto­ra. Jeżeli teraz przy­po­mni­my sobie, że akto­rem sys­te­mu może być tak­że inny sys­tem (kła­nia się dia­gram przy­pad­ków uży­cia), ini­cju­ją­cy inte­rak­cje (żąda obsłu­gi, np. przez API) to mamy peł­ny obraz sytu­acji: aktor ini­cju­je sekwen­cje wyda­rzeń jaką są kolej­no nastę­pu­ją­ce po sobie wza­jem­ne wywo­ła­nia kom­po­nen­tów lub obiek­tów. Znowu klu­czo­wym poję­ciem sta­je się tu SYSTEM (na dia­gra­mie przy­pad­ków uży­cia jest to ele­ment System czy­li oryg. ​„sub­ject” danej per­spek­ty­wy) i jego gra­ni­ce. To aku­rat bar­dzo ład­nie poka­zu­je ten turorial:

Tak więc mamy:

1. pro­ce­sy biz­ne­so­we jako pary aktyw­ność i jej pro­dukt (za pro­dukt odpo­wia­da wyko­naw­ca pro­ce­su, są to np. mode­le w nota­cji BPMN),
2. pro­ce­du­ry (lub wyma­ga­ne umie­jęt­no­ści), opi­su­ją­ce ato­mo­we (nie­po­dziel­ne) aktyw­no­ści (opi­sa­ne np. w posta­ci wypunk­to­wa­nych list), two­rze­nie pro­ce­dur to imple­men­ta­cja okre­ślo­nych aktyw­no­ści meto­da­mi orga­ni­za­cyj­ny­mi (np. wdro­że­nie sys­te­mu zarzą­dza­nia jako­ścią ISO),
3. sce­na­riu­sze przy­pad­ków uży­cia opi­su­ją inte­rak­cje aktor-apli­ka­cja (opi­sa­ne jako punk­to­wa­ne listy, mode­lo­wa­ne jako inte­rak­cje aktor-sys­tem w nota­cji UML), jest to imple­men­ta­cja okre­ślo­nych aktyw­no­ści w aplikacji,
4. sekwen­cje opi­su­ją inte­rak­cje pomię­dzy kom­po­nen­ta­mi (obiek­ta­mi, mode­lo­wa­ne dia­gra­mem sekwen­cji UML), czy­li ele­men­ta­mi archi­tek­tu­ry apli­ka­cji (sys­te­mu).

Bardzo dobrze poka­zu­je to model SOA opi­sa­ny w poprzed­nim arty­ku­le Wzorzec CRUD. Warstwa pro­ce­sów, usług aplikacyjnych/przypadków uży­cia i kom­po­nen­tów to odręb­ne war­stwy i per­spek­ty­wy. Nie mie­sza­my więc ani pozio­mów abs­trak­cji ani per­spek­tyw mode­li. W prze­ciw­nym razie, ule­ga­jąc suge­stiom w rodza­ju ​„ale ja chcę zoba­czyć to wszyst­ko na jed­nym dia­gra­mie” pcha­my pro­jekt w kie­run­ku ​„utra­ty pano­wa­nia nad zło­żo­no­ścią”… To pro­sta dro­ga do klę­ski projektu.

[2023] Polecam tu cie­ka­wą pre­zen­ta­cję na temat budo­wa­nia archi­tek­tu­ry sys­te­mów, autor zwra­ca uwa­gę, że isto­tą dzia­ła­nia sys­te­mów są sekwen­cje inte­rak­cji modu­łów a nie sta­tycz­ne mode­le danych.