4 Baseny, linie, komunikaty i dane

Po spotkaniu: zapiszesz w tok model współpracy dwóch uczestników z basenami, liniami i przepływem komunikatów · dołączysz do modelu dokumenty i rejestry (data, store, reads, writes) · odczytasz i poprawisz błędy struktury R030, R031, R021 i R022 · Czas: Nauka 40 min, Wyzwanie 50 min

4.1 Nauka

Od jednego procesu do współpracy

Modele z poprzednich spotkań opisywały jeden proces. Wszystkie elementy leżały na najwyższym poziomie dokumentu, bez wcięcia, a tok umieszczał je w jednym procesie. W instytucjach informacyjnych proces rzadko kończy się jednak na progu własnej organizacji. Biblioteka zamawia książkę w innej bibliotece, archiwum odpowiada na wniosek obywatela, wydawnictwo czeka na recenzję od zewnętrznego recenzenta.

Na kursie BPMN taki model nazywaliśmy współpracą (collaboration), zob. rozdział 4 kursu BPMN. Ma kilku uczestników. Każdy uczestnik to basen (pool), a w basenie linie (lanes) pokazują role. Między basenami przepływają wyłącznie komunikaty. W innych podręcznikach i programach spotkasz też nazwy „pula” (pool) oraz „tor” albo „pas” (lane). W obu naszych kursach używamy nazw „basen” i „linia”. W tok wszystkie te elementy zapisuje się tak samo jak zadania i zdarzenia: jednym wierszem ze słowem kluczowym na początku.

Basen z blokiem i basen zamknięty

Basen deklaruje słowo pool:

pool biblioteka "Biblioteka uczelniana"
  lane czytelnik "Czytelnik"
    start potrzeba "Potrzeba książki"
pool udostepniajaca "Biblioteka udostępniająca"

O tym, czym jest basen, decyduje wcięty blok pod nim:

Zapis	Znaczenie	Element BPMN
`pool` z blokiem (wcięte wiersze pod spodem)	uczestnik, którego proces modelujemy	`participant` z własnym `process`
`pool` bez bloku	uczestnik, którego wnętrza nie znamy albo nie modelujemy	`participant` bez procesu, czyli basen zamknięty (black box)

Basen z blokiem tworzy w eksporcie BPMN dwa elementy: uczestnika i jego proces. Proces dostaje identyfikator ID-basenu-process, np. biblioteka-process. Jeśli proces ma mieć inną nazwę techniczną, podajesz ją atrybutem process=:

pool uczelnia "Uczelnia" process=obieg-pisma

To ma znaczenie przy modelach wykonywalnych. Identyfikator procesu widać wtedy w silniku, np. w Operate. Zajmiemy się tym na spotkaniu 7.

Linie i linie zagnieżdżone

Linię deklaruje słowo lane. Wszystko, co jest wcięte pod linią, należy do niej. Linie mogą się zagnieżdżać: linia „Wydział” może mieć w środku linie „Dziekanat” i „Dziekan”.

tok 0.1 "Obieg pisma na wydziale"

pool uczelnia "Uczelnia" process=obieg-pisma
  lane kancelaria "Kancelaria ogólna"
    start wplyw "Pismo wpłynęło"
    user rejestracja "Rejestracja pisma w EZD"
  lane wydzial "Wydział"
    lane dziekanat "Dziekanat"
      user dekretacja "Dekretacja pisma"
      user odpowiedz "Przygotowanie odpowiedzi"
    lane dziekan "Dziekan"
      user podpis "Podpisanie odpowiedzi"
      end wyslana "Odpowiedź wysłana"
  store ezd "System EZD"

flow wplyw -> rejestracja -> dekretacja -> odpowiedz -> podpis -> wyslana

writes rejestracja ezd
reads dekretacja ezd

group obsluga "Obsługa merytoryczna" members="dekretacja odpowiedz podpis"

Rysunek 4.1: Obieg pisma na wydziale: linie zagnieżdżone i grupa.

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

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

wcięcie wyznacza linię. Zadanie „Dekretacja pisma” ma sześć spacji wcięcia, bo leży w linii „Dziekanat”, która leży w linii „Wydział”, która leży w basenie;
przepływy piszemy na końcu dokumentu, bez wcięcia. Wiersz flow wplyw -> rejestracja -> dekretacja … łączy elementy z różnych linii. W jednym basenie linie łączy zawsze przepływ sekwencji, tak jak na diagramie;
grupa (group) obejmuje elementy z różnych linii. Wymieniasz je w atrybucie members, oddzielając spacjami. Grupa nie zmienia przebiegu procesu. Jest tylko podpowiedzią dla czytelnika diagramu.

Gdzie mogą stać elementy

Kiedy dokument ma baseny, tok pilnuje dwóch zasad, które wynikają z BPMN:

Kod	Zasada
`R031`	jeśli dokument ma choć jeden basen, zdarzenia, zadania i bramki muszą leżeć w basenach, nie na najwyższym poziomie
`R030`	jeśli basen ma linie, każdy element procesu musi leżeć w którejś linii

Do tego dochodzą dwie zasady o przepływach:

Kod	Zasada
`R021`	przepływ sekwencji (`flow`) nie wychodzi poza swój proces ani podproces
`R022`	przepływ komunikatów (`message`) łączy dwa różne baseny

Oto model, który łamie wszystkie cztery zasady:

tok 0.1 "Obieg pisma z błędami"

start wplyw "Pismo wpłynęło"

pool uczelnia "Uczelnia"
  user rejestracja "Rejestracja pisma w EZD"
  lane dziekanat "Dziekanat"
    user dekretacja "Dekretacja pisma"
    end koniec "Pismo zadekretowane"

flow wplyw -> rejestracja -> dekretacja -> koniec
message rejestracja -> dekretacja "Pismo"

Wynik polecenia tok check 04-linie-z-bledem.tok --lang pl:

04-linie-z-bledem.tok:3: błąd R031: „wplyw” zadeklarowano poza basenem, a dokument ma baseny; przenieś go do basenu
04-linie-z-bledem.tok:6: błąd R030: „rejestracja” leży w basenie z liniami, ale poza liniami
04-linie-z-bledem.tok:11: błąd R021: przepływ sekwencji wplyw -> rejestracja przekracza granicę procesu lub podprocesu
04-linie-z-bledem.tok:12: błąd R022: przepływ komunikatów rejestracja -> dekretacja musi łączyć dwa różne baseny
04-linie-z-bledem.tok: błędy 4, ostrzeżenia 0, uwagi 0

Każdy komunikat wskazuje numer wiersza. Błąd R021 jest skutkiem błędu R031: zdarzenie wplyw leży poza basenem, więc należy do innego procesu niż zadanie rejestracja. Po przeniesieniu zdarzenia do linii znikną oba błędy. Tak często bywa: pierwszy błąd w strukturze pociąga za sobą kolejne. Dlatego poprawiaj komunikaty od góry.

Błąd R022 pokazuje najczęstsze nieporozumienie z kursu BPMN. Między liniami jednego basenu nie ma komunikatów. Rejestracja i dekretacja to kroki tej samej uczelni, więc łączy je flow. W walidatorze z kursu BPMN ten sam błąd miał kod E008. tok wykrywa go wcześniej, na poziomie tekstu.

Przepływ komunikatów

Przepływ komunikatów zapisuje słowo message:

message wyslanie -> udostepniajaca "Zamówienie"
message udostepniajaca -> przesylka "Przesyłka z egzemplarzem"

Po lewej stronie strzałki jest nadawca, po prawej odbiorca. Może to być element procesu (zadanie albo zdarzenie) albo cały basen. Do basenu zamkniętego zawsze łączysz się całym basenem, bo nie ma on wnętrza. Etykieta w cudzysłowie to nazwa wiadomości. tok tworzy z niej deklarację wiadomości (message) w pliku BPMN. Ta sama nazwa użyta w kilku miejscach oznacza tę samą wiadomość. Dlatego zadanie wysyłania send wyslanie … message="Zamówienie" i przepływ message wyslanie -> udostepniajaca "Zamówienie" odnoszą się do jednej wiadomości.

W przepływach komunikatów nie stosuje się łańcuchów. Każda wiadomość to osobny wiersz, bo każda ma własnego nadawcę, odbiorcę i nazwę.

Dokumenty i rejestry

Kolumna „Dokumenty” w tabeli kroków opisuje informacje, na których pracuje proces. W BPMN odpowiadają im dwa elementy, które znasz z kursu BPMN: obiekt danych (dokument istniejący tylko w trakcie sprawy) i magazyn danych (rejestr, który istnieje dłużej niż sprawa). W tok:

Zapis	Znaczenie
`data zam-zlozone "Zamówienie" state="złożone"`	obiekt danych „Zamówienie” w stanie „złożone”
`data zam-wyslane "Zamówienie" state="wysłane"`	ten sam dokument w innym stanie: osobny identyfikator, ta sama etykieta
`store katalog "Katalog NUKAT"`	magazyn danych
`reads katalogi katalog`	zadanie `katalogi` korzysta z magazynu `katalog` (asocjacja danych wejściowych)
`writes rejestracja rejestr`	zadanie `rejestracja` zapisuje dane w magazynie `rejestr` (asocjacja danych wyjściowych)

Wiersze reads i writes mają zawsze tę samą kolejność: najpierw czynność, potem dane. Kierunek strzałki na diagramie wynika ze słowa kluczowego: reads rysuje strzałkę od danych do czynności, writes od czynności do danych. Odczytywać i zapisywać dane mogą tylko czynności. Zdarzenie w miejscu czynności daje błąd R003.

Przykład: wypożyczenie jako współpraca

Połączmy wszystko w jednym modelu. Biblioteka uczelniana zamawia książkę w bibliotece udostępniającej, której wnętrza nie modelujemy.

tok 0.1 "Wypożyczenie międzybiblioteczne: współpraca"

pool biblioteka "Biblioteka uczelniana"
  lane czytelnik "Czytelnik"
    start potrzeba "Potrzeba książki"
    user zamowienie "Złożenie zamówienia"
    user odbior "Odbiór książki"
    end wypozyczona "Książka wypożyczona"
  lane bibliotekarz "Bibliotekarz wypożyczalni międzybibliotecznej"
    user katalogi "Sprawdzenie katalogów"
    send wyslanie "Wysłanie zamówienia" message="Zamówienie"
    receive przesylka "Odbiór przesyłki" message="Przesyłka z egzemplarzem"
  lane system "System biblioteczny"
    service rejestracja "Rejestracja wypożyczenia"
  data zam-zlozone "Zamówienie" state="złożone"
  data zam-wyslane "Zamówienie" state="wysłane"
  store katalog "Katalog NUKAT"
  store rejestr "Rejestr wypożyczeń"

pool udostepniajaca "Biblioteka udostępniająca"

flow potrzeba -> zamowienie -> katalogi -> wyslanie -> przesylka -> rejestracja -> odbior -> wypozyczona

message wyslanie -> udostepniajaca "Zamówienie"
message udostepniajaca -> przesylka "Przesyłka z egzemplarzem"

writes zamowienie zam-zlozone
reads katalogi zam-zlozone
reads katalogi katalog
writes wyslanie zam-wyslane
writes rejestracja rejestr

note podstawa "Regulamin wypożyczeń międzybibliotecznych, § 4" on=wyslanie

Rysunek 4.2: Wypożyczenie międzybiblioteczne jako współpraca dwóch bibliotek.

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

Ten model przechodzi tok check bez żadnych komunikatów. Przeczytaj go tak, jak czytałbyś diagram:

biblioteka uczelniana ma trzy linie: czytelnika, bibliotekarza i system biblioteczny;
zadanie wysyłania „Wysłanie zamówienia” wysyła wiadomość do zamkniętego basenu, a zadanie odbioru „Odbiór przesyłki” czeka na wiadomość z niego;
dokument „Zamówienie” występuje w dwóch stanach: złożone i wysłane;
dwa rejestry: katalog NUKAT (odczyt) i rejestr wypożyczeń (zapis);
adnotacja (note) z podstawą prawną jest przypięta do zadania wysyłania atrybutem on=.

Kolejność w formie kanonicznej

Deklaracje data i store możesz napisać w dowolnym miejscu bloku basenu, także wewnątrz linii. Obiekty danych nie należą jednak w BPMN do linii, tylko do procesu. Dlatego tok fmt przenosi je na koniec bloku basenu, pod wszystkie linie. Wiersze message, reads, writes, note i group drukuje na najwyższym poziomie, w tej kolejności, po przepływach sekwencji. Kolejność odpowiada porządkowi czytania modelu: najpierw kto i co robi, potem jak płynie praca, a na końcu jakie informacje towarzyszą procesowi.

4.2 Wyzwanie

Polecenie: zapisz w tok model współpracy archiwum z wnioskodawcą na podstawie tabeli kroków.

Dane wejściowe: proces „Kwerenda w archiwum z udziałem wnioskodawcy”. Wnioskodawca jest osobą prywatną. Jego czynności nie modelujemy, tylko wiadomości, które wymienia z archiwum (basen zamknięty).

Nr kroku	Nr kolejnego kroku	Nazwa kroku	Wariant	Opis kroku	Kto wykonuje?	Dokumenty
1	2	Wpływ wniosku		Proces zaczyna się, gdy od wnioskodawcy wpływa wniosek o kwerendę.	Kancelaria	Wniosek [złożony]
2	3	Rejestracja wniosku		Kancelaria rejestruje wniosek w systemie kancelaryjnym.	Kancelaria	Wniosek [zarejestrowany]; Ewidencja kwerend
3	4	Przegląd inwentarzy		Archiwista przegląda inwentarze zespołów, których może dotyczyć kwerenda.	Archiwista	Inwentarze archiwalne
4	5	Czy wniosek wymaga uzupełnienia?	T	Tak, we wniosku brakuje danych potrzebnych do poszukiwań.
	7		N	Nie, dane są wystarczające.
5	6	Wysłanie prośby o uzupełnienie		Archiwista wysyła wnioskodawcy prośbę o uzupełnienie danych.	Archiwista	Prośba o uzupełnienie
6	7	Odbiór uzupełnienia		Archiwista otrzymuje od wnioskodawcy uzupełnione dane.	Archiwista	Wniosek [uzupełniony]
7	8	Poszukiwania w zasobie		Archiwista przegląda akta i sporządza notatki z kwerendy.	Archiwista	Notatki z kwerendy
8	9	Zatwierdzenie odpowiedzi		Kierownik oddziału sprawdza i podpisuje odpowiedź.	Kierownik oddziału	Odpowiedź [podpisana]
9	10	Wysłanie odpowiedzi		Kancelaria wysyła wnioskodawcy odpowiedź i odnotowuje to w ewidencji.	Kancelaria	Odpowiedź [wysłana]; Ewidencja kwerend
10		Koniec — odpowiedź wysłana

Wymagania: basen „Archiwum Państwowe” z trzema liniami i zamknięty basen „Wnioskodawca”; przepływy komunikatów w krokach 1, 5, 6 i 9; co najmniej dwa obiekty danych ze stanem i jeden magazyn danych połączony z czynnościami przez reads albo writes; tok check --lang pl bez błędów; plik w formie kanonicznej.

Kroki:

Ustal z tabeli uczestników, role i typy elementów. Kroki 5 i 6 zamodeluj jako zadania wysyłania i odbioru.
Napisz kwerenda.tok: najpierw baseny i linie z elementami, potem przepływy, wiadomości i dane.
Uruchom tok check --lang pl, popraw błędy, potem tok fmt -w.
Wygeneruj tok bpmn i otwórz diagram w Camunda Modeler. Sprawdź, czy przepływy komunikatów biegną między basenami, a nie między liniami.

Rezultat: kwerenda.tok i kwerenda.bpmn. Nie oddajesz ich na Pegazie, ale przydadzą się na spotkaniu 5.

Praca: indywidualnie.

Czas: 50 minut.

Na co zwrócić uwagę

Basen zamknięty nie ma bloku. Jeśli pod pool wnioskodawca "Wnioskodawca" przypadkiem wetniesz jakiś wiersz, basen przestanie być zamknięty i dostanie własny proces.
Wiadomości do basenu zamkniętego kierujesz na cały basen: message wyslanie -> wnioskodawca "Odpowiedź".
Dwa stany jednego dokumentu to dwa identyfikatory z tą samą etykietą: data wniosek-zlozony "Wniosek" state="złożony" i data wniosek-uzup "Wniosek" state="uzupełniony".
Jeśli tok check zgłasza kilka błędów naraz, popraw najpierw pierwszy. Kolejne często są jego skutkiem.

4.3 Pytania sprawdzające

Czym w tok różni się basen z blokiem od basenu bez bloku? Jakie elementy BPMN powstają z każdej z nich?
Co oznacza atrybut process= w deklaracji basenu i kiedy warto go użyć?
Dlaczego zapis message rejestracja -> dekretacja jest błędny, jeśli oba zadania leżą w liniach tego samego basenu? Jak go poprawić?
Jak zapisać w tok dokument „Wniosek” w dwóch stanach i połączyć go z czynnościami, które go tworzą i czytają?
Gdzie tok fmt umieszcza deklaracje data i store i dlaczego nie zostawia ich w liniach?