Gdy brak zdarzenia…

Ostatnio idąc do pracy, zauważyłem jak zmienia się cykl na skrzyżowaniu, które muszę pokonać. Samochody zaczęły zwalniać i w momencie jak dotarłem na skrzyżowanie zapaliło się im czerwone a ja nacisnąłem przycisk dla pieszych, aby wywołać zielone. Niestety zgodnie z cyklem zapaliło się światło zielone najpierw na jednej podporządkowanej, potem na drugiej. W tym momencie powinno zapalić się światło zielone dla pieszych, ale to nie nastąpiło. Przypuszczam, że za późno nacisnąłem przycisk, aby algorytm zmiany świateł to wyłapał. Może przycisk nie działał, choć to raczej nie możliwe, bo często z tego przejścia korzystam. Mogę przypuszczać, że cykl jest ustawiony jak na poniższym diagramie.

Na powyższym diagramie w BPMN wykorzystane zostały elementy:

• Zdarzenie oparte o czas (nadejście określonego momentu czy minięcie określonego czasu), co jest oznaczone przez obiekt timer event. Na diagramie są 2 takie zdarzenia: początkowe dla procesu (start timer event), oznaczone jako (A) na diagramie oraz pośrednie, występujące wewnątrz procesu (intermediate timer event), oznaczone kolejnymi literami (B, C, D, E).
• Zdarzenie informujące o otrzymaniu sygnału/komunikatu od zewnętrznego aktora (message event), tym razem zastosowane wewnątrz procesu (intermediate message event). Takim komunikatem/sygnałem jest żądanie od pieszego, który oczekuje zmiany światła z czerwonego na zielone dla przejścia dla pieszych. Ostatnio wskazywałem, że to zdarzenie może rozpocząć proces. W tym wypadku to zdarzenie wpływa na przebieg procesu, który wykonałby się i tak bez tego zdarzenia – nastąpiłaby zmiana świateł, tak, aby samochody z dróg podporządkowanych mogły przejechać przez skrzyżowanie. Różnica między obiektami jest widoczna na diagramach – jedno z nich ma pojedynczą linię (początkowe), a drugie podwójną (wewnątrz procesu).
• Bramka oparta o zdarzenia (event-based gateway) do rozdzielenia ścieżki. Bramka ta (typu exclusive) działa w ten sposób, że pierwsze napotkane zdarzenie inicjuje uruchomienie ścieżki/przebiegu procesu, występującego po tym zdarzeniu. Na końcu rozdzielenia też jest bramka i w zależności od jej rodzaju – wszystkie ścieżki muszą dojść do tego miejsca lub wystarczy jedna, aby proces przeszedł dalej. W powyższym przykładzie zastosowano również bramkę, która oznacza, że wystarczy tylko jedno z „wejść”, aby przejść dalej w procesie (tzw. exclusive gateway). Taka bramka znajduje się także poniżej, w celu wyboru jednej ze ścieżek, w zależności od tego, czy światło dla pieszych jest zielone czy nie. Decyzja oparta jest o zebrane dane/statusy (exclusive data-based event) a nie zdarzenia. Wcześniejsze zdarzenie (żądanie pieszego) spowodowało zmianę światła lub nie – jest to w sumie zero-jedynkowe. Takie oznaczenie można zaliczyć do danych sterujących procesem. Gdy brak takiego zdarzenia, zadania dotyczące światła dla pieszych w przebiegu procesu zostaną pominięte.
• Zadania (ang. tasks) wykonywane w procesie – zmiany świateł na czerwone, a potem na zielone dla odpowiednich sygnalizatorów oznaczonych numerami (1)-(4).
• tzw. artefakty, czyli dodatkowe elementy rozszerzające interpretację diagramu. Dodałem komentarze dotyczące przebiegu procesu, aby lepiej oznaczyć miejsca, które opisuje w punkcie dotyczącym bramek. Są to informacje dodatkowe, które nie sterują przebiegiem procesu, a pozwalają lepiej zrozumieć przedstawiony diagram.

Za pomocą wskazanych obiektów można sterować przebiegiem procesu oraz sekwencją wykonywanych zadań. W zależności od obsłużonych zdarzeń lub ich kolejności wystąpienia, proces pójdzie ścieżką „domyślną”, obsłuży wyjątek lub zastosuje zadania wynikają z alternatywnego przebiegu procesu. Powyższy proces mógłby przebiegać tak, że zawsze następuje przełączenie światła dla pieszego – z czerwonego na zielone, niezależnie od jego żądania.

Może być też tak, że w zależności od liczby żądań, czy jedno czy z dwóch stron jezdni, zmiana świateł dla samochodów następuje szybciej lub czas oznaczający, że konieczne jest przestawienie świateł się wydłuża. Pewnie istnieje też system, który dostosowuje długość cykli do ruchu lub natężenia ruchu pieszych. W niektórych miastach były testowane (a nawet chyba są wdrożone) takie mechanizmy, które badają natężenie ruchu lub mają zmienny system sygnalizacji w zależności od pory dnia.
—
Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Dzięki niej będę mógł tworzyć treści bardziej dostosowane do Waszych oczekiwań. Jeżeli pojawią się jakieś uwagi do samej ankiety lub problemy z jej wypełnieniem prośba o sygnał w komentarzu lub na adres e-mail podany po prawej stronie.

Reklama

Jak korzystać z bramek opartych o zdarzenia?

Wielokrotnie byłem świadkiem w kolejce w sklepie, gdy pracownik sklepu w pewnym momencie przerywał kasowanie produktów, tzn. automatyczne odczytywanie kodów (czynność Odczytaj kod na diagramie) produktów i ich dodawanie do listy produktów. W tym momencie brał produkt i ręcznie przepisywał kolejne cyfry kodu kreskowego do odpowiedniego miejsca na ekranie kasy (czynność Przyjmij kod na diagramie). Pozwalało to na dodanie tak odszukanego kodu, a następnie produktu do listy produktów.

Produkt musi się znaleźć w określonym obszarze kasy (czynność Namierz produkt na diagramie), aby czujniki czytnika mogły zeskanować kod (czynność Odszukaj kod w zasięgu czytnika na diagramie). Czasami kod musi być dokładnie w pozycji równoległej do poziomu kasy, a czasami może być pod innym kątem.

Na powyższym diagramie (w BPMN) najpierw następuje rozgałęzienie za pomocą bramki (ang. gateway) a potem połączenie dwóch ścieżek w jedną przed akcją, która jest wspólna dla obydwu ścieżek. W tym miejscu także jest zastosowana bramka. Jest to jedna ze znanych dobrych praktyk w stosowaniu “bramek”, czyli rozgałęzienie i połączenie ścieżek jest zakończone bramką. Element zaznaczony na niebiesko.

Każde wyjście z bramki, opartej o zdarzenia (ang. event-based gateway), powinno być połączone ze zdarzeniem. Pozwala to jednoznaczenie wskazać w jakiej sytuacji następuje wyjście na daną ścieżkę, czyli jakie zdarzenie powoduje przejście tą ścieżką. Jest to druga ze znanych dobrych praktyk w stosowaniu bramek. Oznaczone na zielono na diagramie.

Istnieje więcej dobrych praktych w tym obszarze, jednakże już te dwa znacznie wpływają na poprawę czytelności diagramu. Dzięki nim wiemy, które ścieżki kiedy występują i w których momencie i na jakich warunkach następuje powrót z rozgałęzienia i przejście do dalszej części procesu.

O zdarzeniach pisałem już kilkakrotnie w różnym kontekście:

• Jak podejmowane są decyzje w procesie? – wykorzystanie różnych typów zdarzeń.
• Co to jest tokem? Czyli jak się on przemieszcza po po procesie.
• Rozróżnienia ścieżek alternatywnych i wyjątków

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.

Kiedy zaczyna się proces

Oczekiwanie na zdarzenie w poprzednim wpisie było związane ze zdarzeniami, które mają miejsce w trakcie trwania procesu i pozwalają na jego kontynuowanie. Z kolei dzielenie klasy na pary, było związane ze zdarzeniami przerywającymi proces lub wymagającymi wykonania określonych kolejnych kroków. Obydwie sytuacje były związane z tzw. intermediate events.

W przypadku BPMN można rozróżnić również zdarzenia inicjujące dane proces – tzw. start events. Proces może rozpoczynać się w wyniku wystąpienia danego zdarzenia (np. momentu czasu) lub jednego z wielu zdarzeń (np. czas lub wiadomość). Możliwa jest także sytuacja, gdy musi wystąpić równocześnie kilka zdarzeń. Dla każdej z tych sytuacji, język BPMN przewiduje różnego typu oznaczenia zdarzeń. Oznaczenia te pozwalają szybko zorientować się, podczas czytania diagramu, jaki rodzaj zdarzenia inicjuje proces.

Załóżmy, że mamy następującą sytuację. Pewna jednostka po zakończeniu każdego miesiąca kalendarzowego przygotowuje raport. Na przygotowanie raportu składa się określenie parametrów raportu, wykonanie raportu w systemie oraz przygotowanie komentarza do raportu. Taki proces jest inicjowany przez zdarzenie o typie określenia czasu (ang. timer), co widoczne jest na poniższym diagramie.

Załóżmy, że w pewnym momencie podjęto decyzję, że raport może być także przygotowywany na żądanie, zgodnie z wytycznymi podanymi we wniosku. Poniższy diagram w BPMN prezentuje dodanie takiego zdarzenia o typie wiadomości (ang. message). Jako element uzupełniający kroku „Określ parametry raportu” dodano informację o danych wejściowych (opcjonalnych).

Obok wskazanych typów zdarzeń inicjujących BPMN przewiduje jeszcze kilka ich rodzajów: niezdefiniowany (ang. none), warunkowy (ang. conditional), sygnał (używany przy łączeniu procesów, ang. signal), różne zdarzenia (ang. multiple), równoczesne zdarzenia (ang. parallel).

Zadanie: Reguła biznesowa

W artykule „A New Information Systems Paradigm: What does a Business Analyst Needs to Know?” na ModernAnalyst.com autorzy przybliżają czytelnikom serwisu ewolucję systemów informacyjnych i sposobu ich tworzenia. Przechodzą od prostych rozwiązań, wymagających więdzy po stronie szeroko pojętego biznesu nt. choćby tworzenia zapytań SQL, aż do rozwiązań nowoczesnych, rozbudowanych z implementacją systemów klasy workflow, wspartych silnikami baz danych i nie tylko.

Jednym z elementów, które poruszają, jest zarządzanie regułami biznesowymi i tworzenie systemów wspierających ich definiowanie, przechowywanie oraz wykonywanie. Tzw. BRMS (Business Rules Management System, czyli System Zarządzania Regułami Biznesowymi) są nieodłącznym elementem tworzonych systemów. Powstają one trochę przez analogię do wspomnianych jakiś czas temu przeze mnie BPMS (Business Process Management System, czyli System Zarządzania Procesami Biznesowymi) czy DBMS (Data Base Management System, czyli System Zarządzania Bazą Danych).
Załóżmy, że mamy następującą regułę biznesową, wykorzystywaną w korespondencji wysyłanej z systemu:

• Płeć: mężczyzna → powitanie: Pan;
• Płeć: kobieta oraz Stan: mężatka → powitanie: Pani;
• Płeć: kobieta oraz Stan: wolny → powitanie: Panna;

Reguła jest bardzo prosta i to co się rzuca w oczy, w przypadku pierwszej reguły, stan cywilny nie ma znczenia. Powyższą regułę można byłoby w łatwy sposób zapis w bazie danych – jako 3 wiersze, z 3 atrybutami.

Powyższy artykuł przypomina, że w celi opisu takich reguł powstawała Decision Model Notation (DMN) – notarcja modeli decyzyjnych. Artykuł nie rozwija tego tematu, ale w Internecie można znaleźć informacje. W szczególności na stronach brcommunity.com wskazują, że definiowanie reguł jest związane z ich wielokrotnym użytkowaniem. Jest to silne wsparcie dla osób projektujących proces, za pomocą notacji BPMN 2.0, gdzie została przygotowana opcja „BusinessRuleTask”. Służy ona do wołania o wynik poszczególnych reguł. Od notacji BPMN można przejść do postaci wykonawczej poprzez zastosowanie BPML. Przykład zastosowanie tego typu zadania – BusinessRuleTask- został wskazany na powyższym diagramie BPMN. Zadania tego typu oznaczane są przez symbol pogrubionej „tabelki”.

W biznesie można spotkać się z dwoma typami reguł biznesowych – reguły ogólne, mające zastosowanie do wielu procesów, mających miejsce w różnych miejscach orgranizacji oraz reguły szczególne, wykorzystywane w danym procesie biznesowym. Opis reguł biznesowych jest ważnym elementem, który pozwala na zrozumienie działania procesu oraz okoliczności jego wykonania. Często są to tabele lub diagramy drzewiaste ze względu na różnorodnosć powiązań. Samo wykonanie reguł biznesowych może zostać zaimplementowane w różnych sposób – może to być np. tabela bazy danych, na której wykonywane są zapytania SQL a wynikiem jest wynik reguły. Na konferencjach często można usłyszeć w jaki sposób implementować reguły i w jakich sytuacjach. Równocześnie zwracana jest uwaga, aby sposób ich definiowania i przechowywania pozwalał na ich późniejsze aktualizowanie bez konieczności zmiany systemu odwołującego się.

Perspektywa Klienta

W poprzednich wpisać (w szczególności w ramach Etapów benchmarkingu) wskazane zostały następujące kroki procesu wykonywane po stronie klienta:

• zgłoszenie zapotrzebowania / wyszukanie produktu(-ów),
• akceptacja oferty dostawcy / złożenie zamówienia,
• realizacja zamówienia (płatność, odbiór produktu, podanie szczegółów realizacji).

Między powyższymi krokami procesu wykonywane są kroki dostawcy, wpływające na zachowanie klienta i jego decyzje. Wskazane kroki nie są jedynymi wykonywanymi przez klienta. Patrząc z perspektywy klienta można również wyróżnić elementy tzw. procesu decyzyjnego przed zakupem. W literaturze można znaleźć wiele podejść do tego procesu, różnego nazewnictwa uczestników oraz występujących etapów. Do mnie najbardziej przemawia rozwiązanie zaproponowane przez M.J. Baker.

W skrócie można je przedstawić jak na powyższym diagramie (przedstawionym w BPMN), dostosowując do przedstawionej sytuacji w poprzednich wpisach. Między punktami A i B, C i D mają miejsce kroki realizowane przez dostawcę lub wspólnie z dostawcą. Krok „Realizacja decyzji” mógłby zostać potraktowany jako cały wcześniej przedstawiony proces do momentu złożenia zamówienia/potwierdzenia.

BPMN – wyjątki w procesie

Wśród pojęć w metamodelu występuje także element wyjątku: [punkt 10.] Wyjątki (ang. Exceptions).

Poniższy diagram prezentuje moment wystąpienia – w ramach realizacji kroku „Przygotowanie przesyłki” (element wcześniej prezentowanego procesu) – takich wyjątków jak:

• brak papieru w drukarce
• brak atramentu
• brak opakowania

Wszystkie zostały zaprezentowane jako zdarzenie „error” (błąd).
Obok znajduje się także zdarzenie „Materiały dostępne”, które pozwala na kontynuowanie procesu w odróżnieniu od powyższych, dla których inicjowany jest proces rozwiązania.

BPMN – dalsza analiza procesu

Wśród pojęć w metamodelu zostały wymienione między innymi następujące:

• [punkt 1.] Zadanie Wejścia/Wyjścia (ang. Task I/O)
• [punkt 3.] Cechy jakości (ang. Quality Attributes)
• [punkt 5.] Strumień kontroli (ang. Control Flow)
• [punkt 6.] Kierowanie danymi (ang. Data Handling)
• [punkt 8.] Role (ang. Roles)
• [punkt 9.] Zdarzenia (ang. Events)
• [punkt 13.] Dane statystyczne (ang. Statistical Data)

Niektóre z nich – 1, 5, 6, 8, 9 – zostały wykorzystane na zamieszczonych diagramach podczas prezentacji warstwy implementacyjnej – cały proces oraz podproces.

Przykładowo:

• „Zadanie wejścia/wyjścia” to „ProduktDostarczony”
• „Strumień kontroli” to połączenie między krokami „Potwierdzenie zamówienia” a „Analiza danych zamówienia”
• „Kierowanie danymi” to połączenie między „Złożenie zamówienia” a „Przygotowanie zamówienia”
• „Role” to obiekt „Wykonanie: Pracownik”
• „Zdarzenia” to „Produkt dostępny”

Biorąc pod uwagę drugi z diagramów – tzn. podproces – można dodać do niego kolejne informacje: „Cechy jakości” oraz „Dane statystyczne”. Są to informacje, które można zebrać analizując wykonanie całego procesu. Istotne jest jednak to, aby w odpowiednich miejscach została zachowana informacja, która pozwoli na późniejszą analizę. Mogą to być następujące informacje:

• „data/czas rozpoczęcia” i „data/czas zakończenia” poszczególnych kroków;
• „oczekiwany czas wykonania określonych kroków” – aplikacja wspierająca wykonanie procesu może przypominać o zbliżających się terminach, bądź opóźnieniu;
• „wyjątki”/”niezaplanowane zdarzenia” – np. brak papieru w drukarce, wygaśnięcie umowy z pośrednikiem. Mogą to być bardziej lub mniej trywialne zdarzenia.

Są to informacje, które mogą się znaleźć w szczegółowym opisie danego procesu, aby nie przepełniać podstawowego diagramu. W momencie zapisu daty/czasu może nastąpić porównanie z założonymi czasami realizacji procesu. Takie elementy zostały zaprezentowane na poniższym diagramie.

BPML: podejście pierwsze