3 Bramki i gałęzie

Po spotkaniu: zapiszesz w tok rozgałęzienia i złączenia czterech rodzajów bramek · opiszesz gałęzie etykietami, warunkami FEEL i przepływem domyślnym · rozpoznasz i poprawisz typowe błędy bramek na podstawie komunikatów tok check · Czas: Nauka 40 min, Wyzwanie 50 min

3.1 Nauka

Bramki w tok

Bramkę deklaruje się tak samo jak zadanie: słowo kluczowe, identyfikator i etykieta.

Słowo kluczowe	Bramka	Rozdziela	Łączy
`xor`	wykluczająca	dokładnie jedna ścieżka	przepuszcza każdą ścieżkę, która nadejdzie
`and`	równoległa	wszystkie ścieżki naraz	czeka na wszystkie
`or`	inkluzywna	jedna, kilka albo żadna (wtedy domyślna)	czeka na ścieżki, które faktycznie uruchomiono
`eventgw`	oparta na zdarzeniach	wygrywa to, co nastąpi pierwsze	—

Znaczenie bramek jest takie samo jak w Camunda Modeler. Jeśli potrzebujesz przypomnienia, zajrzyj do rozdziału o bramkach w kursie BPMN albo do zasad BPMN.

Dwie zasady nazewnictwa z kursu BPMN obowiązują także w tok:

bramka rozdzielająca ma etykietę w formie pytania: xor kompletny "Czy wniosek kompletny?";
bramka złączająca zwykle nie ma etykiety: and wyniki. Na diagramie wystarczy sam romb.

Gałęzie: etykiety i przepływ domyślny

Każde wyjście z bramki rozdzielającej zapisujesz w osobnym wierszu flow, z odpowiedzią w cudzysłowie:

flow kompletny -> poszukiwania "tak"
flow kompletny -> wezwanie "nie"

Jedno wyjście bramki xor albo or może być przepływem domyślnym. Oznacza się je flagą default. Silnik wybiera je wtedy, gdy żaden warunek na pozostałych wyjściach nie jest spełniony. Na diagramie ma ukośną kreskę przy początku strzałki.

flow kompletny -> wezwanie "nie" default

Pamiętaj o ograniczeniu z poprzedniego spotkania. Wiersz z etykietą albo atrybutem musi zawierać dokładnie jedną strzałkę. Zapis flow g -> a -> e "tak" jest niejednoznaczny, bo nie wiadomo, której strzałki dotyczy etykieta. Narzędzie zgłasza wtedy:

r20.tok:7: błąd R020: wiersz flow z etykietą lub atrybutami musi mieć dokładnie jedną strzałkę

Poprawny zapis to dwa wiersze: flow g -> a "tak" i flow a -> e.

Warunki w języku FEEL

Etykieta „tak” wystarcza człowiekowi. Silnik procesów potrzebuje jednak warunku, który obliczy na danych sprawy. Warunek zapisujesz atrybutem when w języku FEEL (Friendly Enough Expression Language). To ten sam język, którego używa Camunda 8 i tabele decyzyjne DMN.

flow g -> a "student" when="typ = \"student\" and wiek >= 18"
flow g -> b "pilne" when="not(pilne) or dni > 14"
flow g -> c "inne" default

Najważniejsze elementy FEEL na tym etapie:

Zapis	Znaczenie
`wiek >= 18`, `cena < 150`, `dni != 0`	porównania: `=`, `!=`, `<`, `<=`, `>`, `>=` (pojedynczy `=` to porównanie, nie przypisanie)
`kompletny = true`, `pilne`	wartość logiczna; samo `pilne` znaczy „pilne jest prawdą”
`typ = "student"`	tekst w cudzysłowie
`a and b`, `a or b`, `not(a)`	łączenie warunków
`email != null`	sprawdzenie, czy wartość istnieje
`wiek between 18 and 26`	przedział

Uwaga na cudzysłowy. Cały warunek jest już w cudzysłowie, bo jest wartością atrybutu when. Tekst wewnątrz warunku poprzedzasz więc ukośnikiem: \"student\". Narzędzie odczyta to jako typ = "student".

W tok warunki piszesz bez znaku = na początku. Camunda Modeler wymaga go w modelach wykonywalnych (=zgoda = true), ale tok doda go sam podczas eksportu takiego modelu (spotkanie 7).

tok check sprawdza składnię warunków. Pomyłka w zapisie daje błąd F002:

f2.tok:7: błąd F002: błąd składni FEEL: nieoczekiwany element „>”

Szczegóły obsługiwanego podzbioru FEEL znajdziesz w dokumentacji języka (feel.md, po angielsku).

Przykład: kwerenda w archiwum

Model łączy trzy rodzaje bramek. Bramka xor sprawdza kompletność wniosku. Gałąź „nie” wraca przez wezwanie do ponownej oceny, więc tworzy pętlę. Bramka and uruchamia dwa przeszukania naraz. Bramka or wybiera formy przekazania odpowiedzi: e-mail, list albo oba naraz, a gdy żaden warunek nie jest spełniony, wydanie osobiste.

tok 0.1 "Kwerenda w archiwum"

start wplynela "Wniosek o kwerendę wpłynął"
user ocena "Ocena wniosku"
xor kompletny "Czy wniosek kompletny?"
user wezwanie "Wezwanie do uzupełnienia"
and poszukiwania
user inwentarz "Przeszukanie inwentarzy"
user ewidencja "Przeszukanie ewidencji kwerend"
and wyniki
user odpowiedz "Opracowanie odpowiedzi"
or forma "Jak przekazać odpowiedź?"
send email "Wysłanie odpowiedzi e-mailem" message="Odpowiedź"
send list "Wysłanie odpowiedzi listem" message="Odpowiedź"
manual osobiscie "Wydanie odpowiedzi w kancelarii"
or przekazano
end zakonczona "Kwerenda zakończona"

flow wplynela -> ocena -> kompletny
flow kompletny -> poszukiwania "tak" when="kompletny = true"
flow kompletny -> wezwanie "nie" default
flow wezwanie -> ocena
flow poszukiwania -> inwentarz -> wyniki
flow poszukiwania -> ewidencja -> wyniki -> odpowiedz -> forma
flow forma -> email "e-mail" when="email != null"
flow forma -> list "list" when="adres != null and kopie = true"
flow forma -> osobiscie "osobiście" default
flow email -> przekazano
flow list -> przekazano
flow osobiscie -> przekazano -> zakonczona

Rysunek 3.1: Kwerenda w archiwum: bramki XOR (z pętlą), AND i OR z przepływem domyślnym.

Pobierz model (.tok) Pobierz eksport BPMN (.bpmn)

Zwróć uwagę na trzy szczegóły:

Pętla nie potrzebuje osobnej bramki. Przepływ flow wezwanie -> ocena wraca do zadania, które ma już przepływ wchodzący. Zadanie z dwoma wejściami działa jak złączenie XOR. Jeśli chcesz pokazać to złączenie wprost, dodaj bramkę xor przed oceną i skieruj do niej oba przepływy. To kwestia stylu, a nie poprawności.
Złączenia mają ten sam typ co rozwidlenia. Gałęzie z and poszukiwania spotykają się w and wyniki, a gałęzie z or forma w or przekazano.
tok fmt połączył część przepływów w łańcuch poszukiwania -> ewidencja -> wyniki -> odpowiedz -> forma. Łańcuch nie oznacza, że ewidencję przeszukuje się dopiero po inwentarzach. Linie flow opisują tylko połączenia, a o kolejności decyduje bramka and.

Bramka oparta na zdarzeniach

Bramka eventgw nie sprawdza warunków. Proces zatrzymuje się na niej i czeka, aż zajdzie jedno z kilku zdarzeń. Wygrywa to, które nastąpi pierwsze. Za bramką stoją więc zdarzenia przechwytujące catch (wiadomość, czas, sygnał, warunek) albo zadania odbioru receive.

tok 0.1 "Oczekiwanie na uzupełnienie wniosku"

start wezwano "Wezwanie wysłane"
eventgw czekanie "Co nastąpi pierwsze?"
catch uzupelnienie "Uzupełnienie otrzymane" message="Uzupełnienie wniosku"
catch termin "Minęło 14 dni" timer=P14D
user ocena "Ponowna ocena wniosku"
user pozostawienie "Pozostawienie wniosku bez rozpatrzenia"
end oceniony "Wniosek oceniony ponownie"
end bez-rozpatrzenia "Wniosek bez rozpatrzenia"

flow wezwano -> czekanie
flow czekanie -> uzupelnienie
flow czekanie -> termin
flow uzupelnienie -> ocena -> oceniony
flow termin -> pozostawienie -> bez-rozpatrzenia

Rysunek 3.2: Oczekiwanie na uzupełnienie wniosku: wiadomość albo upływ 14 dni, co nastąpi pierwsze.

Pobierz model (.tok) Pobierz eksport BPMN (.bpmn)

Wyjścia z eventgw nie mają etykiet ani warunków. Odpowiedź niosą etykiety zdarzeń („Uzupełnienie otrzymane”, „Minęło 14 dni”). Jeśli za bramką postawisz zwykłe zadanie, narzędzie zgłosi błąd:

e16.tok:3: błąd E016: „Co pierwsze?” (g): po bramce opartej na zdarzeniach musi wystąpić
pośrednie zdarzenie przechwytujące (wiadomość, czas, sygnał, warunek) lub zadanie odbioru,
a jest „Ponaglenie” (a).

Typowe błędy bramek

Poniższy model przygotowania wystawy w bibliotece ma cztery błędy. Najpierw spróbuj znaleźć je sam, czytając tekst.

tok 0.1 "Przygotowanie wystawy (z błędami)"

start decyzja "Decyzja o wystawie"
and przygotowania
user wybor "Wybór obiektów"
user opisy "Przygotowanie opisów"
xor gotowe
xor zgoda "Czy dyrektor zatwierdził?"
user montaz "Montaż wystawy"
user poprawki "Poprawki scenariusza"
end otwarta "Wystawa otwarta"

flow decyzja -> przygotowania
flow przygotowania -> wybor "obiekty" when="obiekty = true"
flow przygotowania -> opisy
flow wybor -> gotowe
flow opisy -> gotowe
flow gotowe -> zgoda
flow zgoda -> montaz "tak"
flow zgoda -> poprawki
flow montaz -> otwarta

Wynik tok check --lang pl:

03-bramki-z-bledem.tok:7: ostrzeżenie W051: gotowe (bramka wykluczająca (XOR)) łączy gałęzie
rozwidlone przez przygotowania (bramka równoległa (AND)): wszystkie gałęzie dotrą do złączenia,
więc dalsza część procesu wykona się kilka razy.
03-bramki-z-bledem.tok:10: ostrzeżenie W042: „Poprawki scenariusza” (poprawki) nie ma przepływu
wychodzącego — ścieżka powinna kończyć się zdarzeniem końcowym.
03-bramki-z-bledem.tok:14: błąd E017: Przepływ f-przygotowania-wybor z bramki równoległej
przygotowania nie może mieć warunku.
03-bramki-z-bledem.tok:20: ostrzeżenie W021: Gałąź f-zgoda-poprawki bramki „Czy dyrektor
zatwierdził?” (zgoda) nie ma ani etykiety, ani warunku, ani statusu przepływu domyślnego.

Kod	Błąd	Poprawka
`E017`	warunek na wyjściu bramki równoległej	usuń `when`; bramka `and` zawsze uruchamia wszystkie wyjścia
`W051`	rozwidlenie `and` złączone bramką `xor`	zmień `xor gotowe` na `and gotowe`
`W021`	gałąź bez etykiety i bez statusu domyślnego	dopisz `"nie"` i, jeśli trzeba, `default`
`W042`	ścieżka urywa się na zadaniu	dodaj przepływ z „Poprawek scenariusza”, np. z powrotem do decyzji, albo zdarzenie końcowe

Dochodzi jeszcze jedno ostrzeżenie, którego tu nie ma. Bramka or bez przepływu domyślnego daje W050. Proces nie wie wtedy, co zrobić, gdy żaden warunek nie jest spełniony.

Ostrzeżenia nie blokują eksportu, ale niemal zawsze oznaczają błąd merytoryczny. W zadaniach na Pegazie model musi być wolny od błędów, a każde pozostawione ostrzeżenie trzeba uzasadnić.

3.2 Wyzwanie

Polecenie: zapisz w tok proces zgłoszenia publikacji do repozytorium uczelnianego na podstawie tabeli kroków z opisu zadania Z1.

Dane wejściowe: tabela kroków w opisie zadania Z1 (dodatek C). Opisy kroków nie nazywają elementów BPMN. Wskazówki są w sformułowaniach, jak w laboratorium kursu BPMN.

Kroki:

Przeczytaj całą tabelę. Zaznacz kroki, które rozdzielają albo łączą ścieżki, i ustal rodzaj każdej bramki.
Zapisz elementy, a pod nimi przepływy. Etykiety elementów zacznij numerem kroku, np. "2. Kontrola formalna".
Dopisz warunki FEEL do wyjść bramek xor i or oraz przepływy domyślne.
tok check --lang pl, aż nie będzie błędów. Ostrzeżenia popraw albo uzasadnij.
tok fmt -w, tok bpmn, tok svg. Obejrzyj diagram w Camunda Modeler.

Rezultat: pliki z1-repozytorium.tok, z1-repozytorium.bpmn, z1-repozytorium.svg.

Praca: indywidualnie, bez narzędzi sztucznej inteligencji.

Czas: 50 minut na zajęciach. Zadanie dokończ do terminu na Pegazie.

Zadanie Z1 (15%). Oddajesz model procesu zgłoszenia publikacji do repozytorium w tok wraz z eksportem BPMN i rysunkiem SVG. Ocenie podlega dobór bramek i zdarzeń, poprawność warunków FEEL i przepływów domyślnych oraz model bez błędów tok check. Pełne polecenie i kryteria oceny są w dodatku C.

Na co zwrócić uwagę

Słowa „obie czynności zawsze, niezależnie” wskazują bramkę and. Słowa „może zajść jedna, kilka albo żadna” wskazują or. Słowa „co nastąpi pierwsze” wskazują eventgw.
Każdą bramkę rozdzielającą and i or złącz bramką tego samego rodzaju.
Warunki odwołują się do danych sprawy. Wymyśl czytelne nazwy zmiennych (kompletne, grant, rodzaj) i używaj ich konsekwentnie.
Pętla powrotna („wraca do kroku 2”) to zwykły przepływ do wcześniejszego elementu.

3.3 Pytania sprawdzające

Dlaczego wiersz flow g -> a -> e "tak" jest błędny? Jak go poprawić?
Zapisz warunek FEEL: „czytelnik jest pracownikiem albo ma więcej niż 60 lat”. Zmienne nazwij sam.
Kiedy silnik wybiera przepływ domyślny? Która bramka bez przepływu domyślnego daje ostrzeżenie W050?
Jakie elementy mogą stać bezpośrednio za bramką eventgw? Dlaczego jej wyjścia nie mają warunków?
Co się stanie w procesie, jeśli rozwidlenie and złączysz bramką xor?