Wprowadzenie

Niedawno napisał do mnie czytelnik pod jednym 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ść kursy) 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 systemu. 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 czytelne? (źr.: : Model pojęciowy, model danych, model dziedziny systemu)

Prawdę mówiąc, mniej więcej w takiej formie dostaje materiały od moich klientów.. ;). Co możemy zrobić? Pomyślałem, że dobry reprezentatywny przykład pomoże. Popatrzmy…

Metody

Organizacje na początku modelujemy z perspektywy biznesowej abstrahując od tego co nazywamy „systemem informatycznym”. Celem jest zrozumienie tego jak ona funkcjonuje i opisanie (model) jej mechanizmu działania. Na tym etapie musimy oderwać się od używanego od wielu lat oprogramowania i udokumentować procesy biznesowe, mimo tego, że bardzo często używane oprogramowanie coś automatyzuje i pracownicy tego od lat nie widzą. Taki model w metodyce MDA nazywamy Computation Independent Model. Mając opisany i rozumiejąc mechanizm działania organizacji, pozyskujemy wiedzę o tym jakimi narzędziami się ona (jej pracownicy) posługuje i kiedy, sprawdzamy co i kiedy (jeżeli w ogóle) zostało z pomocą tych rozwiązań IT zautomatyzowane. Powstaje model PIM systemu IT (Platform Independent Model). Całość wykorzystuje notacje BPMN oraz UML.

Model biznesowy (CIM)

Na tym etapie modelujemy „co i po” co a nie „jak i czym” a task BPMN (model analityczny, opisowy) to nazwa procedury:

Bardzo częstym błędem, są próby łączenia powyższego w (traktowania jako) jeden proces biznesowy. Drugi częsty błąd to umieszczanie na modelach biznesowych systemów IT. Powyżej „Zewnętrzna platforma” to nie „system IT” a dostawca usługi, alternatywą jest wpisanie tam nazwy podmiotu zarządzającego tą platformą. Detale, zależnie od tego czego dotyczą, umieszczamy na szablonach dokumentów (czyli poza diagramami BPMN) lub w treści procedur uwidocznionych jako ich nazwy (task) na diagramie BPMN.

Dokument (szablon, struktura) Lista własnych kursów walut można przedstawić np. tak (tu jako Wewnętrzna tabela kursów walut) :

Model, opis techniczny (PIM)

Może mało podobny do realnego wydruku, ale pozwala zarządzać treścią a taki jest cel na tym etapie. Taki model wykonany w narzędziu CASE, to klasa i jej atrybuty. Może posłużyć jako struktura pliku XML.

Modelowanie to przede wszystkim poziomy abstrakcji. najwyższy to Model kontekstowy:

Powyższe to konsekwencja modelu procesów (patrz Transformacja modelu…): przypadek użycia aplikacji (systemu) to usługa jaką 'system’ świadczy aktorowi. Usługa w UML (przypadek użycia systemu) realizuje oczekiwany przez aktora efekt (tu dokument) a nie „kliknięcie w ekran”.

A co robi nasz „system”?

Tu pokazujemy komponenty składowe systemu rozumianego jako „system IT organizacji”. Granice tego co nazywamy „system” ustalamy my, bo to kontekst projektu. Pod pojęciem „system” może sie kryć konkretna aplikacja lub „całość IT” organizacji, to także kwestia umowy (przyjętej w danym projekcie konwencji).

Jak to działa?

Diagram aktywności. Cały basen to aktywny system, partycje reprezentują jego komponenty. Wewnątrz partycji pokazano zadania realizowane przez poszczególne komponenty i (ewentualnie) dane jakie sobie przekazują. Docelowo zadania można przyporządkować do operacji komponentów reprezentowanych przez partycje. Ten diagram pokazuje w jakiej kolejności są wykonywane zadania a nie jak wywołują się między sobą komponenty. Tutaj celem jest pokazanie samej współpracy komponentów i przepływu danych (obiekty reprezentują dokumenty: nazwane struktury danych). Na rym etapie (z reguły wcześniejszy etap koncepcyjny) pokazujmy tylko przepływ danych.

Jeżeli chcemy pokazać scenariusz integracji robimy to tak:

Tak wygląda scenariusz (realizowany raz dziennie) komunikowania się komponentów. Każdorazowo zaś, gdy pracownik tworzy dokument wykorzystujący aktualny wewnętrzny kurs waluty, realizowany jest scenariusz:

Na diagramach pokazujemy operacje interfejsów wywoływane przez poszczególne komponenty.

Podsumowanie

Jak widać mamy tu kilka prostych diagramów, każdy ma określony jeden kontekst. Czy to jest tytułowe „czytelne pokazanie”? Moim zdaniem, każdy z tych diagramów jest bardzo prosty mimo, że pierwotny opis wygląda na skomplikowany.

Próba pokazanie wszystkiego na „jakimś” jednym diagramie skończy się typowym „spaghetti modelingiem”. Jednak jeżeli podejdziemy do tego tak, że osobno opiszemy to co robią ludzie i osobno to co robią komponenty tego systemu, to będzie właśnie kilka prostych diagramów. Jak dodamy do tego fakt, że robiąc to w narzędziu CASE, automatycznie zyskamy śledzenie spójności i kompletności logiki tego modelu (projektu), uzyskamy efekt w postaci spójnej i kompletnej dokumentacji (jeżeli jest to opis wykonany na bazie audytu) lub projektu (jeżeli jest to opis opracowany przed wdrożeniem).

Podręcznikowa wersja powyższego wygląda jak poniżej:

Więcej o powyższym w artykule o wymaganiach.

Uwagi końcowe

Takie modele pomagają wychwytywać miejsca optymalizacji zarówno procesów jak i samej architektury integracji.

Mając takie schematy i zrozumienie architektury pojawia sie pytanie: skoro mamy szynę integracyjną ESB to dlaczego mamy integracje bezpośrednią pomiędzy komponentami Z i Y?

Komponent Y wielokrotnie odpowiada na żądania podawania określonych kursów. Być może API było by prostsze i natężenie komunikacji mniejsze gdyby Komponent Z żądał i dostawał całą tabelę kursów i „wydłubywał z niej” potrzebny mu w danym momencie kurs waluty.

Na modelu procesów biznesowych, można (w razie takiej potrzeby) pokazać, które komponenty wspierają poszczególne aktywności w procesach, lub je automatyzują.