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 „podejmowane” są decyzje w procesie w BPMN?

Niektóre sklepy komputerowe stosują praktykę, że podczas rozliczania transakcji weryfikują cenę produktu z wewnętrzną bazą/stroną internetową. Klient wybierając produkt na półce prosi o jego udostępnienie, a następnie decyduje się bądź nie na jego zakup. W takim sklepie mówiąc, że jest zainteresowany, może usłyszeć, że cena jest wyższa, niższa lub taka sama. Poniższy przykładowy diagram w BPMN prezentuje właśnie taki proces – jest to proces, którego rzeczywiście doświadczyłem. Pozostawiłem pewne elementy bez ostatecznego rozwiązania, ponieważ każdy mógłby zachować się inaczej, sklep mógłby postąpić inaczej. Nie będę wskazywał jak postąpiłem, nie jest to istotne z punktu widzenia tematu, który chcę poruszyć.

W trakcie takiego procesu mamy różne momenty decyzyjne, oznaczone przez znaki w kształcie rombów na diagramie. W tym wypadku zostały zastosowane elementy charakterystyczne na diagramów w BPMN. Takie sytuacje zakupowe są idealnym przykładem do prezentacji elementów decyzyjnych na procesie. W powyższym przykładzie obydwa zastosowane elementy – „z pięciokątem w środku” oraz „z krzyżykiem” – oznaczają przypadki, gdy tylko z jedna z dalszych ścieżek diagramu może zostać zastosowana. Są one wyłacząjące się (ang. exclusive).

Pierwszy z nich – „z krzyżykiem” – opiera się na weryfikacji warunku, sprawdzeniu wartości dla określonych danych (ang. exclusive data-based). W przykładzie następuje sprawdzenie warunku dotyczącego ceny (na diagramie specjalnie go nie umieściłem aby to omówić w treści). Klient sprawdza, czy zawiera się w kwocie, którą przeznaczył na zakup. Sprzedawca porównuje dwie ceny – cenę z spółki i cenę z systemu. W zależności od wyniku następują różne komunikaty.

Drugi z nich – „z pięciokątem w środku” dotyczy oczekiwania na zdarzenie innej osoby, klienta, jako wynik jego zachowania, zrealizowanych działań (ang. exclusive event-based). W niniejszym przykładzie jest to wynik analizy produktu przez Klienta. Tak naprawdę sprzedawca może jedynie czekać, ponieważ nie wie co sprawdza Klient i jaka będzie jego ostateczna decyzja. Oczekuje określone zdarzenia – chcę kupić lub rozmyśliłem się. Można by jeszcze dodać opcję – chciałbym zobaczyć podobne produkty albo wróci do początku procesu.