5 Zdarzenia i bramki
Efekty uczenia się: W2, W4, U1, U3 · Treści programowe: 5 · Czas: Nauka 40 min, Wyzwanie 50 min
5.1 Nauka
Co dzieje się w trakcie procesu
Do tej pory nasze procesy miały zdarzenie na początku i na końcu, a pomiędzy nimi same zadania i bramki. W prawdziwym procesie wiele ważnych rzeczy dzieje się jednak w trakcie: przychodzi odpowiedź od innej biblioteki, mija termin na zwrot książki, dyrekcja ogłasza zamknięcie czytelni. Do pokazania takich sytuacji służą zdarzenia pośrednie (intermediate events). Rysuje się je jako kółko z podwójną cienką linią.
Zdarzenie pośrednie niczego nie trwa. Zadanie zajmuje czas i ma wykonawcę, a zdarzenie po prostu zachodzi. Gdy w opisie procesu czytasz „przychodzi”, „mija”, „zostaje ogłoszone”, „staje się prawdą”, szukaj zdarzenia, a nie zadania.
Zdarzenia przechwytujące i rzucające
Zdarzenia pośrednie występują w dwóch odmianach. Odróżnia się je po ikonie w środku kółka:
| Odmiana | Ikona | Co robi proces | Przykład |
|---|---|---|---|
| przechwytujące (catching) |  pusta, biała |
czeka, aż zdarzenie zajdzie, i dopiero wtedy idzie dalej | biblioteka czeka na przesyłkę z egzemplarzem |
| rzucające (throwing) |  wypełniona, czarna |
wywołuje zdarzenie i od razu idzie dalej | archiwum wysyła potwierdzenie przyjęcia wniosku |
Prosta reguła: biała ikona to „odbieram”, czarna to „wysyłam”. Zdarzenia czasowe i warunkowe są zawsze przechwytujące, bo nie da się „wysłać” upływu czasu. Proces może tylko na niego czekać.
Wyzwalacze zdarzeń pośrednich
Ikona w środku kółka to wyzwalacz (trigger). Mówi, co wywołuje zdarzenie. W modelach procesów informacyjnych najczęściej spotkasz pięć wyzwalaczy:
| Wyzwalacz | Ikona | Przechwytujące | Rzucające | Przykład |
|---|---|---|---|---|
| wiadomość (message) | koperta |
czekam na wiadomość od konkretnego nadawcy | wysyłam wiadomość do konkretnego adresata | przychodzi odmowa z innej biblioteki |
| czas (timer) |  zegar |
czekam, aż minie termin albo nadejdzie data | — | minęło 14 dni bez odpowiedzi |
| sygnał (signal) |  trójkąt |
nasłuchuję ogłoszenia | ogłaszam coś wszystkim zainteresowanym | dyrekcja ogłasza zamknięcie czytelni na czas remontu |
| warunek (conditional) |  kartka z liniami |
czekam, aż coś stanie się prawdą | — | stan magazynu materiałów konserwatorskich spadł poniżej minimum |
| łącznik (link) |  strzałka |
„wejście z innej części rysunku” | „przejdź do innej części rysunku” | duży diagram rozdzielony na dwie części |
Łącznik nie zmienia przebiegu procesu. Działa jak odsyłacz „ciąg dalszy na stronie 2”: para łączników o tej samej nazwie zastępuje długą strzałkę przez cały diagram. Używaj go oszczędnie, bo utrudnia śledzenie przebiegu.
Wiadomość czy sygnał?
Te dwa wyzwalacze łatwo pomylić, bo oba „przenoszą informację”. Różnica dotyczy adresata:
- wiadomość ma konkretnego adresata: biblioteka wysyła zamówienie do jednej, wskazanej biblioteki; archiwum odpowiada jednemu wnioskodawcy;
- sygnał jest ogłoszeniem dla wszystkich, którzy nasłuchują: dyrekcja ogłasza zamknięcie czytelni, a każdy otwarty proces udostępniania zbiorów, niezależnie od etapu, reaguje na to ogłoszenie.
Wiadomości między basenami rysuje się przepływem komunikatów (spotkanie 4). Sygnału nie łączy się żadną strzałką. Nadawca nie wie, kto go odbierze. Jeśli w opisie procesu pojawia się sformułowanie „jednocześnie wszystkim”, „ogłasza”, „wszystkie otwarte sprawy”, to prawie na pewno jest to sygnał.
Jak zapisuje się czas
Zdarzenie czasowe musi mieć określony czas. Zdarzenie z zegarem, któremu nie podano terminu, walidator zgłasza jako ostrzeżenie (W010). W pliku BPMN czas zapisuje się w formacie normy ISO 8601. Ten sam format wpisujesz w Camunda Modeler w panelu właściwości zdarzenia.
| Rodzaj | Zapis | Znaczenie |
|---|---|---|
| czas trwania (duration) | P14D |
14 dni od chwili, gdy proces dotarł do zdarzenia |
PT2H |
2 godziny (litera T oddziela część godzinową) |
|
P1M |
1 miesiąc | |
| data (date) | 2026-12-31T12:00:00 |
konkretna chwila w kalendarzu |
| cykl (cycle) | R3/P7D |
trzy razy, co 7 dni |
R/P1M |
bez końca, co miesiąc |
Na jedną rzecz trzeba uważać. Format ISO 8601 liczy dni kalendarzowe, a nie robocze. Termin „5 dni roboczych” w opisie procesu na diagramie analitycznym możesz nazwać słowami, np. zdarzenie „Minęło 5 dni roboczych”. W modelu wykonywalnym (spotkanie 12) trzeba go przeliczyć albo skorzystać z kalendarza w silniku procesów.
Bramka inkluzywna: jedna, kilka albo żadna
Na spotkaniu 3 poznaliśmy dwie bramki. Bramka wykluczająca (XOR) wybiera dokładnie jedną ścieżkę, a równoległa (AND) uruchamia wszystkie. Często potrzebujemy czegoś pośredniego. Biblioteka ma powiadomić czytelnika, że książka czeka na odbiór. Jeśli czytelnik podał adres e-mail, wysyła e-mail. Jeśli zgodził się na SMS, wysyła SMS. Może to zrobić oboma kanałami naraz. A jeśli czytelnik nie podał ani adresu, ani zgody, bibliotekarz przygotowuje list.
Do tego służy bramka inkluzywna (inclusive gateway, OR). Rysuje się ją jako romb z kółkiem w środku.
Rysunek 5.1: Powiadomienie czytelnika: bramka inkluzywna z przepływem domyślnym i złączenie tą samą bramką.
Zasady bramki inkluzywnej:
- Przy rozgałęzieniu każda wychodząca ścieżka ma własny warunek. Uruchamiane są wszystkie ścieżki, których warunek jest spełniony: jedna, kilka albo wszystkie.
- Przepływ domyślny (default flow), oznaczony ukośną kreską przy początku strzałki, zostaje wybrany wtedy, gdy żaden warunek nie jest spełniony. Bez niego proces mógłby utknąć w miejscu
(W050). Przepływ domyślny nie ma warunku(E015). - Przy złączeniu bramka inkluzywna czeka tylko na te ścieżki, które faktycznie zostały uruchomione. Jeśli wysłano tylko e-mail, złączenie nie czeka na SMS.
- Rozgałęzienie inkluzywne łączy się bramką inkluzywną
(W051). Złączenie bramką wykluczającą sprawiłoby, że dalsza część procesu wykonałaby się kilka razy. Złączenie bramką równoległą zablokowałoby proces na zawsze, bo czekałoby na ścieżki, które nigdy nie ruszyły.
Jak rozpoznać bramkę inkluzywną w opisie? Szukaj sformułowań „może zajść jedna sytuacja, kilka albo żadna”, „w zależności od tego, co dotyczy sprawy”, „tylko te czynności, które faktycznie uruchomiono”.
Bramka oparta na zdarzeniach: co nastąpi pierwsze
Wróćmy do wypożyczenia międzybibliotecznego. Biblioteka wysłała zamówienie i czeka. Mogą się zdarzyć trzy rzeczy: przyjdzie przesyłka z egzemplarzem, przyjdzie odmowa albo minie 14 dni bez żadnej odpowiedzi. Nikt w bibliotece nie podejmuje tu decyzji. To, którą drogą pójdzie proces, zależy od tego, co nastąpi pierwsze.
Takiej sytuacji nie zamodelujesz bramką wykluczającą. Bramka XOR wybiera ścieżkę na podstawie informacji, która już jest w procesie, np. wyniku sprawdzenia katalogów. Tu informacji jeszcze nie ma. Proces musi na nią poczekać. Do tego służy bramka oparta na zdarzeniach (event-based gateway): romb z pięciokątem w podwójnym kółku.
Rysunek 5.2: Oczekiwanie na odpowiedź innej biblioteki: bramka oparta na zdarzeniach z dwiema wiadomościami i terminem.
Jak działa bramka oparta na zdarzeniach:
- proces zatrzymuje się na bramce i jednocześnie nasłuchuje wszystkich zdarzeń, które stoją za nią;
- pierwsze zdarzenie, które zajdzie, wygrywa; proces idzie jego ścieżką, a pozostałe zdarzenia przestają być ważne;
- jeśli przesyłka przyjdzie po 15 dniach, gdy proces już poszedł ścieżką terminu, nie zostanie odebrana w tym miejscu.
Zasady, które sprawdza walidator:
- za bramką stoją wyłącznie pośrednie zdarzenia przechwytujące (wiadomość, czas, sygnał, warunek) albo zadania odbioru, a bramka ma co najmniej dwa wyjścia
(E016); - na wyjściach bramki nie ma warunków, bo o wyborze decydują zdarzenia, a nie dane
(E016); - zdarzenia stojące za bramką nie mają innych wejść
(W016).
Zwróć uwagę na pętlę w modelu. Po pierwszym upływie 14 dni biblioteka wysyła ponaglenie i znowu czeka na tej samej bramce. Przed bramką stoi bramka wykluczająca, która scala dwie drogi: pierwsze wysłanie i powrót po ponagleniu. Dzięki temu bramka oparta na zdarzeniach ma jedno wejście i nie jest jednocześnie bramką scalającą i rozgałęziającą. Po drugim terminie biblioteka już nie czeka, tylko szuka innej biblioteki.
Typowa pułapka: „czy przyszła odpowiedź?”
Początkujący często modelują oczekiwanie tak: zadanie „Sprawdzenie, czy przyszła odpowiedź”, a za nim bramka wykluczająca „Czy przyszła odpowiedź?” z gałęziami „tak” i „nie”. To błąd z dwóch powodów. Po pierwsze, proces nie czeka. Jeśli w chwili sprawdzenia odpowiedzi nie ma, idzie od razu ścieżką „nie”. Po drugie, model ukrywa to, co najważniejsze: termin i to, że o wyniku decyduje partner zewnętrzny. Jeśli w opisie pada słowo „czeka”, szukaj zdarzenia przechwytującego. Jeśli pada „co nastąpi pierwsze”, szukaj bramki opartej na zdarzeniach.
Cztery bramki w jednym zestawieniu
| Bramka | Znak | Kto lub co decyduje | Rozgałęzienie | Złączenie |
|---|---|---|---|---|
| wykluczająca (XOR) |  X |
dane już znane w procesie | dokładnie jedna ścieżka | przepuszcza każdą ścieżkę, która przyjdzie |
| równoległa (AND) |  + |
nikt, zawsze wszystkie | wszystkie ścieżki naraz | czeka na wszystkie |
| inkluzywna (OR) |  O |
dane już znane w procesie | jedna, kilka albo domyślna | czeka na faktycznie uruchomione |
| oparta na zdarzeniach |  pięciokąt |
zdarzenie, które nastąpi pierwsze | dokładnie jedna ścieżka, po zdarzeniu | — |
Bramka nigdy sama niczego nie robi. Decyzję podejmuje zadanie przed bramką albo zdarzenie za nią. Dlatego rozgałęziającą bramkę XOR i OR nazywamy pytaniem, na które odpowiedź jest już znana: „Czy inna biblioteka ma egzemplarz?”. Bramkę opartą na zdarzeniach możesz nazwać pytaniem „Co nastąpi pierwsze?” albo zostawić bez nazwy, bo zdarzenia za nią mówią same za siebie.
Typowe błędy
| Błąd | Kod | Poprawka |
|---|---|---|
| zegar bez określonego czasu | W010 | wpisz czas trwania, datę albo cykl |
| bramka OR bez przepływu domyślnego | W050 | oznacz jedną ścieżkę jako domyślną, bez warunku |
| przepływ domyślny, a druga gałąź bez warunku | W022 | dopisz warunek do każdej gałęzi oprócz domyślnej |
| kilka przepływów bez warunków wychodzi wprost z zadania albo zdarzenia | W044 | rozgałęzienie zapisz bramką równoległą albo daj przepływom warunki |
| rozgałęzienie OR złączone bramką XOR albo AND | W051 | złącz bramką tego samego typu |
| zadanie bezpośrednio za bramką opartą na zdarzeniach | E016 | zastąp je zdarzeniem przechwytującym albo zadaniem odbioru |
| warunki na wyjściach bramki opartej na zdarzeniach | E016 | usuń warunki, o wyborze decydują zdarzenia |
| sygnał narysowany jako przepływ komunikatów | — | sygnał nie ma strzałki; przepływ komunikatów zostaw dla wiadomości |
5.2 Wyzwanie
Polecenie: zbuduj w Camunda Modeler model procesu „Deponowanie pracy dyplomowej w repozytorium” na podstawie tabeli kroków. Proces prowadzi biblioteka uczelniana, która opiekuje się repozytorium. Student i promotor są dla biblioteki partnerami zewnętrznymi: komunikują się z nią przez system repozytorium.
Dane wejściowe:
| Nr kroku | Nr kolejnego kroku | Nazwa kroku | Wariant | Opis kroku | Kto wykonuje? | Dokumenty |
|---|---|---|---|---|---|---|
| 1 | 2 | Wpływ pracy | Proces biblioteki zaczyna się w chwili, gdy student przesyła do repozytorium plik pracy wraz z metadanymi. | System repozytorium | Praca [złożona] | |
| 2 | 3 | Kontrola antyplagiatowa | System sam, bez udziału człowieka, przekazuje pracę do systemu antyplagiatowego i zapisuje raport podobieństwa. | System repozytorium | Raport podobieństwa | |
| 3 | 4 | Prośba o akceptację | System wysyła promotorowi prośbę o akceptację pracy wraz z raportem. | System repozytorium | Raport podobieństwa | |
| 4 | 5 | Oczekiwanie na promotora | a | Nikt w bibliotece nie podejmuje tu decyzji. Dalszy przebieg zależy od tego, co nastąpi pierwsze: a) promotor akceptuje pracę, | Redaktor repozytorium | |
| 15 | b | b) promotor zwraca pracę do poprawy, | ||||
| 6 | c | c) mija 7 dni bez odpowiedzi promotora. | ||||
| 5 | 8 | Akceptacja otrzymana | Promotor zaakceptował pracę. | Redaktor repozytorium | Praca [zaakceptowana] | |
| 6 | 7 | Upływ terminu | Minęło 7 dni bez odpowiedzi promotora. | Redaktor repozytorium | ||
| 7 | 4 | Ponaglenie promotora | Redaktor wysyła promotorowi przypomnienie, a potem biblioteka znowu czeka na odpowiedź. | Redaktor repozytorium | ||
| 8 | 9 | Opracowanie metadanych | Redaktor sprawdza i uzupełnia metadane: słowa kluczowe, dziedzinę, język pracy. | Redaktor repozytorium | Rekord metadanych; Katalog repozytorium | |
| 9 | 10 | Czynności dodatkowe | licencja otwarta | Może zajść jedna sytuacja, obie albo żadna: student udzielił licencji na otwarte udostępnienie pracy, | ||
| 11 | egzamin wyznaczony | wyznaczono już termin egzaminu dyplomowego, | ||||
| 12 | żadna (domyślnie) | żadna z tych sytuacji nie zachodzi. | ||||
| 10 | 12 | Publikacja w otwartym dostępie | System sam udostępnia pracę i jej metadane w otwartej części repozytorium. | System repozytorium | Praca [udostępniona] | |
| 11 | 12 | Powiadomienie dziekanatu | System wysyła do dziekanatu informację, że praca jest zdeponowana. | System repozytorium | ||
| 12 | 13 | Synchronizacja | Proces czeka na zakończenie czynności uruchomionych w kroku 9, ale tylko tych, które faktycznie zostały uruchomione. | |||
| 13 | Koniec — praca zdeponowana | System wysyła studentowi potwierdzenie zdeponowania pracy. | System repozytorium | |||
| 15 | Koniec — praca zwrócona do poprawy | System przekazuje studentowi uwagi promotora. | System repozytorium |
Wymagania:
- basen biblioteki z liniami „Redaktor repozytorium” i „System repozytorium”; student i promotor jako baseny zamknięte;
- bramka oparta na zdarzeniach w kroku 4 z trzema zdarzeniami przechwytującymi i pętlą ponaglenia;
- bramka inkluzywna w kroku 9 z przepływem domyślnym i złączeniem w kroku 12;
- przepływy komunikatów do studenta i promotora wszędzie tam, gdzie biblioteka wymienia z nimi informację;
- zdarzenie czasowe z czasem zapisanym w formacie ISO 8601.
Praca: w parach, przy jednym komputerze. Co 15 minut zamieniacie się rolami: jedna osoba modeluje, druga czyta tabelę i pilnuje zasad z części Nauka.
Rezultat: plik s05-deponowanie.bpmn. Model nie jest oddawany, ale przyda się jako materiał do powtórki przed kolokwium.
Czas: 45 minut modelowania i 5 minut na porównanie modeli z inną parą.
Na co zwrócić uwagę
- Za bramką w kroku 4 stoją wyłącznie zdarzenia. Akceptacja i zwrot przychodzą od promotora, więc są to zdarzenia wiadomości z przepływem komunikatów z basenu promotora.
- Ponaglenie w kroku 7 wraca do oczekiwania. Zadbaj, żeby bramka oparta na zdarzeniach miała jedno wejście. Scal ścieżki bramką wykluczającą przed nią.
- Krok 13 kończy proces wysłaniem wiadomości do studenta. Zastanów się, czy wystarczy zwykłe zdarzenie końcowe.
- Numer 14 w tabeli nie występuje. Tabele kroków w instytucjach często mają takie luki po usuniętych krokach. Nie dodawaj elementu, którego tabela nie opisuje.
5.3 Pytania sprawdzające
- Czym różni się zdarzenie pośrednie przechwytujące od rzucającego? Jak odróżnisz je na diagramie?
- Dlaczego zdarzenie czasowe nie może być rzucające?
- Archiwum ogłasza wszystkim otwartym sprawom udostępniania, że czytelnia jest nieczynna. Jakim wyzwalaczem to zamodelujesz i dlaczego nie wiadomością?
- Co oznacza zapis
P14D, a coR3/P7D? Jak potraktujesz w modelu termin „5 dni roboczych”? - Na które ścieżki czeka złączenie inkluzywne? Co by się stało, gdyby rozgałęzienie OR złączyć bramką AND?
- Po co bramce inkluzywnej przepływ domyślny?
- Dlaczego oczekiwanie na odpowiedź partnera modeluje się bramką opartą na zdarzeniach, a nie bramką wykluczającą „Czy przyszła odpowiedź?”?
- Jakie elementy mogą stać bezpośrednio za bramką opartą na zdarzeniach?