Wstęp

Niedawno napi­sał do mnie czy­tel­nik pod jed­nym z artykułów:

Załóż­my, że reali­zu­je­my pro­ces biz­ne­so­wy: zarzą­dza­nie kur­sa­mi walut. W ramach pro­ce­su pra­cow­nik musi przy­go­to­wać plik csv zawie­ra­ją­cy wyłącz­nie listę słow­ni­ko­wą par walut (np. usdpln, eurpln, eurusd). Nazwa pli­ku to np bie­żą­cą data. Następnie systemX łączy się z API zewnętrz­nej plat­for­my i pobie­ra tabe­le kur­sów tych par walut (aktu­al­ne i histo­rycz­ne mie­siąc wstecz) i wysta­wia plik xls zawie­ra­ją­cy dane: nazwa pary walut, data kur­su, war­tość kur­sy) Plik ten sys­tem X wysy­ła do szy­by ESB. Szyna prze­sy­ła ten plik do systemuY. SystemY wyko­rzy­stu­je te dane do wyzna­cze­nia wewnętrz­nych kur­sów walut wg. usta­lo­ne­go mode­lu mate­ma­tycz­ne­go. Wynik obli­czeń odkła­da­ny jest w bazie danych tego sys­te­mu. Na koń­cu pro­ce­su jest pra­cow­nik, któ­ry wyko­rzy­stu­je te infor­ma­cje za pośred­nic­twem SystemuZ. Wybiera parę walut, okre­śla datę i sys­tem zwra­ca mu wewnętrz­ny kurs wyzna­czo­ny przez SystemY. Technicznie odby­wa się poprzez odpy­ta­nie sys­te­mu Y poprzez jego API. Czyli mamy SystemX, SystemY, SystemZ, pra­cow­ni­ka, szy­nę, plik csv, plix xls, 2XAPI no i prze­pływ danych (naj­pierw pli­ków, potem poszcze­gól­nych atry­bu­tów) . I jak to wszyst­kim poka­zać żeby było czy­tel­ne? (źr.: : Model poję­cio­wy, model danych, model dzie­dzi­ny sys­te­mu)

Prawdę mówiąc, mniej wię­cej w takiej for­mie dosta­je mate­ria­ły od moich klien­tów.. ;). Co może­my zro­bić? Pomyślałem, że dobry repre­zen­ta­tyw­ny przy­kład. Popatrzmy…

Metody

Organizacje na począt­ku mode­lu­je­my z per­spek­ty­wy biz­ne­so­wej abs­tra­hu­jąc od tego co nazy­wa­my ​„sys­te­mem infor­ma­tycz­nym”. Celem jest zro­zu­mie­nie jak ona funk­cjo­nu­je, jej mecha­ni­zmu dzia­ła­nia. Na tym eta­pie musi­my ode­rwać się od uży­wa­ne­go od wie­lu lat opro­gra­mo­wa­nia i udo­ku­men­to­wać pro­ce­sy biz­ne­so­we, mimo tego, że bar­dzo czę­sto uży­wa­ne opro­gra­mo­wa­nie coś auto­ma­ty­zu­je i pra­cow­ni­cy tego od lat nie widzą. Taki model w meto­dy­ce MDA nazy­wa­my Computation Independent Model. Rozumiejąc mecha­nizm dzia­ła­nia orga­ni­za­cji, pozy­sku­je­my wie­dzę o tym jaki­mi narzę­dzia­mi się ona (jej pra­cow­ni­cy) posłu­gu­je i kie­dy, spraw­dza­my co i kie­dy (jeże­li w ogó­le) zosta­ło z pomo­cą tych roz­wią­zań IT zauto­ma­ty­zo­wa­ne. Powstaje model PIM (Platform Independent Model). Całość wyko­rzy­stu­je nota­cje BPMN oraz UML. 

Model biznesowy (CIM)

Na tym eta­pie mode­lu­je­my ​„co i po” co a nie «jak i czym”: 

Bardzo czę­stym błę­dem, są pró­by łącze­nia powyż­sze­go w (trak­to­wa­nia jako) jeden pro­ces biz­ne­so­wy. Drugi czę­sty błąd to umiesz­cza­nie na mode­lach biz­ne­so­wych sys­te­mów IT (powy­żej: ​„Zewnętrzna plat­for­ma”). Tu powi­nien być pod­miot zarzą­dza­ją­cy ta plat­for­mą. Detale, zależ­nie od tego cze­go doty­czą, umiesz­cza­my na sza­blo­nach doku­men­tów lub w tre­ści pro­ce­dur aktyw­no­ści uwi­docz­nio­nych na dia­gra­mie BPMN. Dokument (struk­tu­ra) Lista wła­snych kur­sów walut moż­na przed­sta­wić np. tak:

Model techniczny (PIM)

Może mało podob­ny do real­ne­go wydru­ku, ale pozwa­la zarzą­dzać tre­ścią a taki jest cel na tym eta­pie. Taki model wyko­na­ny w narzę­dziu CASE, to kla­sa i jej atry­bu­ty. Może posłu­żyć jako struk­tu­ra pli­ku XML. 

Modelowanie to przede wszyst­kim pozio­my abs­trak­cji. naj­wyż­szy to Model kontekstu:

Powyższe to kon­se­kwen­cja mode­lu pro­ce­sów (patrz Transformacja mode­lu…): przy­pa­dek uży­cia apli­ka­cji (sys­te­mu) to usłu­ga jaką «sys­tem» świad­czy akto­ro­wi. Usługa w UML (przy­pa­dek uży­cia sys­te­mu) reali­zu­je ocze­ki­wa­ny przez akto­ra efekt (tu doku­ment) a nie ​„klik­nię­cie w ekran”. 

A co robi nasz ​„sys­tem”?

Tu poka­zu­je­my kom­po­nen­ty skła­do­we sys­te­mu rozu­mia­ne­go jako ​„sys­tem IT orga­ni­za­cji”. Granice tego co nazy­wa­my «sys­tem» usta­la­my my, bo to kon­tekst pro­jek­tu. Pod poję­cie «sys­tem» może sie kryć kon­kret­na apli­ka­cja lub ​„całość IT” orga­ni­za­cji, to tak­że kwe­stia umo­wy (przy­ję­tej w danym pro­jek­cie konwencji). 

Jak to działa? 

Diagram aktyw­no­ści. Cały basen to aktyw­ny sys­tem, par­ty­cje repre­zen­tu­ją jego kom­po­nen­ty. Wewnątrz par­ty­cji poka­za­no zada­nia reali­zo­wa­ne przez poszcze­gól­ne kom­po­nen­ty i (ewen­tu­al­nie) dane jakie sobie prze­ka­zu­ją. Docelowo zada­nia moż­na przy­po­rząd­ko­wać do ope­ra­cji kom­po­nen­tów repre­zen­to­wa­nych przez par­ty­cje. Ten dia­gram poka­zu­je w jakiej kolej­no­ści są wyko­ny­wa­ne zada­nia a nie jak wywo­łu­ją się mię­dzy sobą kom­po­nen­ty. Tutaj celem jest poka­za­nie samej współ­pra­cy kom­po­nen­tów i prze­pły­wu danych (obiek­ty repre­zen­tu­ją doku­men­ty: nazwa­ne struk­tu­ry danych). na rym eta­pie (z regu­ły wcze­śniej­szy etap kon­cep­cyj­ny) poka­zuj­my tyl­ko prze­pływ danych. 

Jeżeli chce­my oka­zać sce­na­riusz wywo­łań (inte­gra­cji) robi­my to tak:

Tak wyglą­da sce­na­riusz (reali­zo­wa­ny raz dzien­nie) komu­ni­ko­wa­nia się kom­po­nen­tów. Każdorazowo zaś, gdy pra­cow­nik two­rzy doku­ment wyko­rzy­stu­ją­cy aktu­al­ny wewnętrz­ny kurs walu­ty, reali­zo­wa­ny jest scenariusz:

Na dia­gra­mach poka­zu­je­my ope­ra­cje wywo­ły­wa­ne przez poszcze­gól­ne komponenty.

Podsumowanie

Jak widać mamy tu kil­ka pro­stych dia­gra­mów, każ­dy ma okre­ślo­ny jeden kon­tekst. Czy to jest tytu­ło­we ​„czy­tel­ne poka­za­nie”? Moim zda­niem, każ­dy z tych dia­gra­mów jest bar­dzo pro­sty. Pierwotny opis wyglą­da na skom­pli­ko­wa­ny. Próba poka­za­nie wszyst­kie­go na ​„jakimś” jed­nym dia­gra­mie skoń­czy się typo­wym ​„spa­ghet­ti mode­lin­giem”. Jednak jeże­li podej­dzie­my do tego tak, że osob­no opi­sze­my to co robią ludzie i osob­no to co robią kom­po­nen­ty tego sys­te­mu, to będzie wła­śnie kil­ka pro­stych dia­gra­mów. Jak doda­my do tego fakt, że robiąc to w narzę­dziu CASE, auto­ma­tycz­nie zyska­my śle­dze­nie spój­no­ści i kom­plet­no­ści logi­ki tego mode­lu (pro­jek­tu), uzy­ska­my efekt w posta­ci spój­nej i kom­plet­nej doku­men­ta­cji (jeże­li jest to opis wyko­na­ny na bazie audy­tu) lub pro­jek­tu (jeże­li jest to opis opra­co­wa­ny przed wdro­że­niem). Podręcznikowa wer­sja powyż­sze­go wyglą­da jak poniżej:

Więcej o powyż­szym w arty­ku­le o wyma­ga­niach.

Uwagi końcowe

Takie mode­le poma­ga­ją wychwy­ty­wać miej­sca opty­ma­li­za­cji zarów­no pro­ce­sów jak i samej archi­tek­tu­ry integracji. 

Mając takie sche­ma­ty i zro­zu­mie­nie archi­tek­tu­ry poja­wia sie pyta­nie: sko­ro mamy szy­nę inte­gra­cyj­ną ESB to dla­cze­go mamy inte­gra­cje bez­po­śred­nią pomię­dzy kom­po­nen­ta­mi Z i Y?

Komponent Y wie­lo­krot­nie odpo­wia­da na żąda­nia poda­wa­nia okre­ślo­nych kur­sów. Być może API było by prost­sze i natę­że­nie komu­ni­ka­cji mniej­sze gdy­by Komponent Z żądał i dosta­wał całą tabe­lę kur­sów i ​„wydłu­by­wał z niej” potrzeb­ny mu w danym momen­cie kurs waluty. 

Na mode­lu pro­ce­sów biz­ne­so­wych, moż­na (w razie takiej potrze­by) poka­zać, któ­re kom­po­nen­ty wspie­ra­ją poszcze­gól­ne aktyw­no­ści w pro­ce­sach, lub je automatyzują.