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:
[…] oparta o zdarzenia (event-based gateway) do rozdzielenia ścieżki. Bramka ta (typu exclusive) działa w ten sposób, że pierwsze […]