Wstęp
Swego czasu napisałem tekst o niejednoznaczności treści w dokumentacji jako źródle kłopotów w projektach: Analityk biznesowy czyli wyplenić dwuznaczność… Warto pamiętać, że:
Bałagan pojęciowy w raporcie z analizy, powoduje, że raport nie pozwala na jego jednoznaczną interpretację, co praktycznie dyskwalifikuje go jako przydatne źródło informacji w projekcie.
Dzisiaj kontynuacja tej tezy w kontekście powstających modeli, ich treści i szczegółowości.
Proces, sekwencja, scenariusz
Weźmy np. dość często pojawiające się pojęcia: “proces systemowy” czy też “system” w modelu procesu biznesowego, sekwencje i diagramy sekwencji itp. Spotykam się niestety z masą bełkotu i herezji w dokumentach, na blogach czy nawet w książkach… Na listach dyskusyjnych LinkedIn widać, że problem nie dotyczy tylko naszego kraju :). Przyczyną tych problemów jest praktycznie zawsze ignorowanie definicji pojęć tak językowych (język w jakim pisana jest dokumentacja) jak i notacyjnych (ignorowanie lub po prostu nieznajomość lub nawet nie zrozumienie standardu). Czy nazywanie czegoś herezją to moje subiektywne uznanie? Myślę, że nie, to porównanie (audyt?) ze standardami i ogólnie uznanymi systemami pojęciowymi, jednym z nich język ojczysty autora dokumentu.
Najpierw kilka kluczowych definicji (słownik języka polskiego PWN):
proces: przebieg następujących po sobie i powiązanych przyczynowo określonych zmian
procedura: określone reguły postępowania
sekwencja: układ jakichś elementów, w którym następują one w określonej kolejności
scenariusz: zaplanowany lub przewidywany rozwój wydarzeń
Proces, definicja “biznesowa” mówi o produkcie procesu biznesowego, jest nim właśnie ta wprowadzona “zmiana”. Procedura w praktyce jest regułą (biznesową). Sekwencja w UML to nic innego jak ustalona (dla sensu lub powodzenia operacji) kolejność zdarzeń (wywołań). Scenariusz to pojęcie wykorzystane w opisie przypadków użycia: “scenariusz przypadku użycia”. W związku z tym, że przypadki użycia są wymaganiem (opisem użycia produktu), interakcja aktor – system, ma status “planowany”. Uznanie w projekcie, że wymaganie jest “OK”, daje w konsekwencji “projekt”, czyli sekwencję opisującą realizację przypadku użycia. Jak widać, słownik nie jest taki zły, notacje i ich system pojęciowy w szczególności.
Porządkujemy wiedze dalej. Zajrzyjmy do MDA Guide Version 1.0.1:
Model CIM to model opisujący logikę działania (sens istnienia) modelowanej organizacji, to model tego “co i po co się dzieje” a nie “jak i czym”. Tu nie pokazujemy narzędzi (jakim jest np. oprogramowanie). Standardem na tym poziomie modelowania są notacje BMM i BPMN. Rzecz w tym, że model procesów biznesowych nie powinien zawierać żadnych pojęć typu “system” czy “oprogramowanie”. Dlaczego? Bo dla zrozumienia i udokumentowania tego jak działa organizacja, potrzebna jest wiedza o tym jakie informacje i jak są przetwarzane, a nie “czym”.
Często widuję próby pokazania na jednym diagramie: pracy ludzi, integracji systemów, szczegółów procedur i wszystko inne, co tylko autor dokumentu wie. To totalne nieporozumienie, to pokaz niezrozumienia tego czym są modele, a są uproszczeniami (abstrakcjami), określonymi perspektywami analizowanego zjawiska.
Model PIM to obraz logiki działania (część biznesowa, domena) narzędzia jakim jest aplikacja. Tu pojawia się to, jakie informacje i jak są (mają być) przetwarzane. Model ten jednak nie opisuje szczegółów (środowisko aplikacji, framework, rozwiązania technologiczne np. logowanie, kodowanie, itp.), opisuje wyłącznie biznesową logikę działania aplikacji. Gdzie i jak to projektować, pokazać, testować?
Przytoczę po raz kolejny diagram ze strony Business Process Trends:
Mamy tu trzy poziomy modelowania organizacji: architektura procesów, modele procesów oraz ich implementacja. Architekturę procesów z reguły przedstawia się jako wysokopoziomowe uogólnienie np. z pomocą prostej notacji znanej jako “pagoniki” :):
Modele procesów tworzymy z użyciem, nie raz tu już omawianej, notacji BPMN. Tu jest mowa o procesach biznesowych i ewentualnych ich podprocesach ale nadal poziom szczegółowości nie schodzi poniżej pary “aktywność i jej produkt” (proces biznesowy). Implementacja to reguły wg. których realizowane są poszczególne aktywności. Dana aktywność jest realizowana albo na bazie umiejętności jej wykonawcy (rola) i nie tworzymy jej diagramu a powołujemy się na opis stanowiska, albo na bazie procedury czyli wykonawca danej pracy musi przestrzegać reguł narzuconych procedurą. Procedurę spisujemy w punktach z ewentualnymi wariantami (a nie modelujemy obrazkami). Ale implementacja to albo wdrożenie procedury albo wdrożenie oprogramowania.
A gdzie te “systemowe procesy”?
Otóż nie ma czegoś takiego, nie w architekturze opisywanej standardowo ani w BPMN ani w UML, nie ma (nie znam) w architekturze korporacyjnej. Mając wiedzę o komponentach systemu (różnych aplikacjach) mamy wiedzę do czego zostały one stworzone i jakie realizują zadania (znamy ich interfejsy). Zaś elementem, który inicjuje w systemie jakąkolwiek sekwencję wydarzeń (interakcji między aplikacjami, komponentami, obiektami) jest zainicjowany przypadek użycia systemu, a konkretnie zdarzenie inicjujące wygenerowane przez konkretnego aktora. Jeżeli teraz przypomnimy sobie, że aktorem systemu może być także inny system (kłania się diagram przypadków użycia), inicjujący interakcje (żąda obsługi, np. przez API) to mamy pełny obraz sytuacji: aktor inicjuje sekwencje wydarzeń jaką są kolejno następujące po sobie wzajemne wywołania komponentów lub obiektów. Znowu kluczowym pojęciem staje się tu SYSTEM (na diagramie przypadków użycia jest to element System czyli oryg. “subject” danej perspektywy) i jego granice. To akurat bardzo ładnie pokazuje ten turorial:
Tak więc mamy:
- procesy biznesowe jako pary aktywność i jej produkt (za produkt odpowiada wykonawca procesu, są to np. modele w notacji BPMN),
- procedury (lub wymagane umiejętności), opisujące atomowe (niepodzielne) aktywności (opisane np. w postaci wypunktowanych list), tworzenie procedur to implementacja określonych aktywności metodami organizacyjnymi (np. wdrożenie systemu zarządzania jakością ISO),
- scenariusze przypadków użycia opisują interakcje aktor-aplikacja (opisane jako punktowane listy, modelowane jako interakcje aktor-system w notacji UML), jest to implementacja określonych aktywności w aplikacji,
- sekwencje opisują interakcje pomiędzy komponentami (obiektami, modelowane diagramem sekwencji UML), czyli elementami architektury aplikacji (systemu).
Bardzo dobrze pokazuje to model SOA opisany w poprzednim artykule Wzorzec CRUD. Warstwa procesów, usług aplikacyjnych/przypadków użycia i komponentów to odrębne warstwy i perspektywy. Nie mieszamy więc ani poziomów abstrakcji ani perspektyw modeli. W przeciwnym razie, ulegając sugestiom w rodzaju “ale ja chcę zobaczyć to wszystko na jednym diagramie” pchamy projekt w kierunku “utraty panowania nad złożonością”… To prosta droga do klęski projektu.
[2023] Polecam tu ciekawą prezentację na temat budowania architektury systemów, autor zwraca uwagę, że istotą działania systemów są sekwencje interakcji modułów a nie statyczne modele danych.
