Co to ten token?

W poprzednim wpisie użyłem sformułowania, że po „otrzymaniu tzw. tokenów” ze wszystkich ścieżek wchodzących do bramki proces będzie kontynuowany. Tzw. token można sobie wyobrazić jako znacznik przebiegu procesu przekazywany od zdarzenia początkowego, od czynności do czynności, rozdzielanego i łączonego na ścieżkach równoczesnych, traconego w pewnych sytuacjach. W szczególności za pomocą tokenów łatwo wyjaśnić działanie bramek. Spróbuję przedstawić to wizualnie.

Załóżmy, że przygotowujemy obiad, rysujemy proces czynności wykonywanych po kolei, a potem dajemy komuś zadanie powtórzenia procesu. Można sobie wyobrazić, że ta osoba (lub robot po przepisaniu procesu na język maszynowy), wodzi palcem po procesie i wykonuje czynności zgodnie z ich opisem. Wstawia wodę na ziemniaki, soli ją, w trakcie gotowania wody, obiera ziemniaki, a potem je wrzuca do garnka, następnie wykonuje kolejne czynności. Może też to zrobić za pomocą parowaru. Wstawia wodę, obiera ziemniaki i umieszcza je w parowarze. Powyższy diagram w BPMN prezentuje taki przykładowy proces.

Przyglądając się dokładnie animacji można zauważyć, że:

• za bramką AND są 2 tokeny i przejście do następnych czynności, jest możliwe, gdy obydwa one trafią do bramki łączącej. Zadania mogą zakończyć się w różnym czasie.
• za bramką typu exclusive jest jeden token, ponieważ proces przebiega jedną ścieżką.

Reklama

Obydwa czy pierwszy lepszy?

Wyobraźmy sobie, że, czysto hipotetycznie, chcemy przesunąć po gąbce stalową kulkę. Nie trudno sobie wyobrazić taką sytuację, nawet mając świadomość, że jest absurdalny problem. Można to zrobić na dwa sposoby: popychając kulkę lub uciskając gąbkę, a kulka będzie się przesuwać tocząc po nierówności. Chciałbym skupić na tym drugim przypadku. Mamy dwie czynności: Utwórz wgłębienie i Przesuń kulkę (działanie automatyczne) wykonywane w tym samym momencie i Zwolnij nacisk wykonywane potem.

Załóżmy, że powyższe zadanie zostało przedstawione za pomocą diagramu procesu, używając BPMN, a w szczególności przez pomyłkę umieszczono jako element łączący tzw. bramkę OR (ang. inclusive OR merge). Sytuację tę przedstawia wariant A na poniższym diagramie. Specyfika tego elementu oznacza, że proces jest kontynuowany, jeżeli do bramki dotrze tzw. token z dowolnej ze ścieżek przychodzących. Gdyby automat wykonywał zadanie Utwórz wgłębienie, to kulka w pewnym momencie mogłaby zostać w innym miejscu gąbki niż początek wgłębienia, ponieważ operacja Zwolnij nacisk wykonana byłaby za szybko.

Diagram można łatwo poprawić, poprzez umieszczenie elementu tzw. bramkę AND (ang. paraller (AND) joining). Element ten wskazuje, że przejście dalej w procesie jest możliwe dopiero po zakończeniu – otrzymaniu tzw. tokenów – wszystkich ścieżek przychodzących do bramki. Po wykonaniu wgłębienia należałoby poczekać na przesunięcie kulki, a następnie Zwolnić nacisk i utworzyć nowe wgłębienie. Poprawka zaprezentowana jest w ramach wariantu B.

Powyższy przykład pokazuje różnicę między dwoma elementami BPMN. Przepisując taki diagram na język maszynowy proces działałby niezgodnie z oczekiwaniem, jeżeli założeniem jest zakończenie dwóch równoczesnych czynności przed wykonaniem kolejnej.

Decyzje pod kontrolą lub poza

Dzisiaj ponownie przybliżę temat tzw. bramek wyłączających (ang. exclusive gates), czyli takich, z których możliwe jest tylko jedno wyjście do dalszego procesu. Około rok temu, wskazywałem we wpisie o podejmowaniu decyzji w procesie, że mamy dwa rodzaje tych bramek: oparte o dane (ang. data-based) oraz oparte o zdarzenia (ang. event-based). Podany wtedy przykład nie podawał wyraźnie rozróżnienia między tymi bramkami. Dzisiaj postaram się podać lepszy przykład.

Załóżmy, że nadal mówimy o procesie przygotowania raportu. Otrzymaliśmy wniosek i analizujemy, czy mamy komplet danych i są one spójne. Posługujemy się danymi dostępnymi tu i teraz, lokalnie, bez angażowania innych osób, chcemy zrealizować zlecone zadanie. I to jest jest właśnie specyfika bramek opartych o dane (ang. exclusive data-based). Na powyższym diagramie w BPMN jest to pierwsza z bramek, występująca po czynności Określ parametry wniosku. Wszystkie elementy są pod kontrolą wykonującego czynność. Wiemy dokładnie jakie czynności zostaną wykonane dalej.

W sytuacji jednak, gdy dane okażą się niespójne lub zabraknie danej do parametryzacji oczekiwanego raportu, pojawia się konieczność kontaktu z odbiorcą raportu. W tym momencie, dalszy przebieg procesu jest poza naszą kontrolą. To, co się dalej wydarzy jest uzależnione od odbiorcy raportu. To jest charakterystyczne dla bramek opartych o zdarzenia (ang. exclusive event-based). Na powyższym diagramie w BPMN jest to druga bramka. W sumie wiemy co dalej możemy wykonać w przypadku różnych działań odbiorcy, ale sama jego decyzja jest niezależna od samego procesu.

Myślę, że powyższy przykład lepiej oddaje charakter tych dwóch bramek. Innym przykładem może być ten z wysyłką listu/wykonywaniem telefonu, a odbiorem przesyłki/odebraniem telefonu.