Nowości w BPMN 2.

mgr inż. Małgorzata Bukowska

e-mail:mbukowska@wat.edu.pl
1. Historia BPMN (organizacja OMG)
2.1. Zadanie reguły biznesowej

Zadanie reguły biznesowej (Business rule task) stosujemy w

przypadku zadań realizowanych przez:
• silnik procesów biznesowych (zebranie danych i przekazanie ich do
silnika reguł),
• silnik reguł biznesowych (obliczenie wartości reguły biznesowej i
przekazanie je do silnika procesów).
Korzyść: separacja logiki procesu biznesowego (np. proces
przyznawania kredytu hipotetycznego) od logiki biznesowej (np.
algorytm podejmowania decyzji kredytowej).
Wada: konieczność wdrożenia i utrzymywania silnika reguł
2.2. Znaczniki zadań

W standardzie BPMN 2.0, w odniesieniu do czynności atomowych

możemy stosować znaczniki, które umożliwiają dokładniejsze graficzne
wyspecyfikowanie sposobu realizacji czynności.
Zadanie abstrakcyjne (Abstract task) stosujemy w przypadku braku
specyfikacji typu zadania.

Zadanie użytkownika (User task) stosujemy w przypadku zadań

wykonywanych przez człowieka z wykorzystaniem aplikacji
komputerowej.

Zadanie manualne (Manual task) stosujemy w przypadku zadań

wykonywanych przez człowieka całkowicie poza systemami
komputerowymi np. stemplowanie kopert.

Zadanie usługowe (Service task) stosujemy w przypadku zadań

wykonywanych całkowicie automatycznie np. Web Service
2.2. Znaczniki zadań
Zadanie odebrania (Receive task) stosujemy w przypadku zadań
związanych z odebraniem komunikatu od innego uczestnika.

Zadanie wysłania (Send task) stosujemy w przypadku zadań związanych

z wysłaniem komunikatu do innego uczestnika.

Zadanie inicjalizujące odebranie komunikatu (Initiating receive task)

stosujemy w przypadku procesów zaczynających się czynnością
odebrania wiadomości.

Zadanie skryptowe (Script task) stosujemy w przypadku zadań

wykonywanych przez silnik procesów biznesowych w oparciu o skrypt
przygotowany przez analityka lub programistę procesów biznesowych.

Zadanie reguły biznesowej (Business rule task) stosujemy w przypadku

zadań realizowanych przez silnik procesów biznesowych oraz silnik reguł
biznesowych.
2.3. Czynność wieloinstancyjne

Wieloinstancyjna czynność sekwencyjna (Sequential

Multi-Instace Task) jest to czynność powtarzana
sekwencyjnie np. akceptacja kosztów zamówienia.

Wieloinstancyjna czynność równoległa (ParallelMulti-

Instace Task) jest to czynność wykonywana równolegle np.
wysłanie towarów do sklepów.
2.3. Czynność wieloinstancyjne
2.4. Czynność wywołania

Czynność wywołania (Call Activity) stosujemy w przypadku

wystąpienie potrzeby odwołania się do:
• innego procesu / podprocesu globalnego (Global Process),
Uwaga: podproces można wywoływać w formie zwiniętej oraz rozwiniętej (obu
przypadkach używamy pogrubionej linii)

• innego zadania globalnego (Global Task).

2.4. Czynność wywołania
2.5. Podproces zdarzeniowy

Podproces zdarzeniowy (Event Subprocess) stosujemy w przypadku

konieczności zamodelowania sytuacji realizowanej poza normalnym
przepływem, gdyż nie wynika ona z sekwencji czynności w procesie
nadrzędnym, a z wystąpienia konkretnego zdarzenia. Postacie
podprocesu:
• podproces zwinięty:

• podproces rozwinięty:
2.5. Podproces zdarzeniowy

Założenia:
1. Każdy podproces zdarzeniowy musi zaczynać się jednym zdarzeniem.
Dopuszczalne zdarzenia:
• Wiadomość,
• Stoper,
• Eskalacja,
• Warunek,
• Błąd,
• Sygnał,
• Wielokrotne
• Wielokrotne równoległe.
Uwaga: jeżeli mamy do czynienie ze zwiniętym podprocesem, to w lewym
górnym rogu umieszczamy symbol zdarzenia wywołującego podproces.
2.5. Podproces zdarzeniowy

Założenia cd.:
2. Podproces zdarzeniowy nie ma wchodzących i wychodzących
przepływów (Sequence Flows).
3. Podprocesu zdarzeniowego można używać w ramach procesu oraz
podprocesu i może wykonywać się wielokrotnie lub wcale. Przy
czym proces nadrzędny może:
• działać nieprzerwanie (zdarzenie początkowe nieprzerywające ),
• zostać zatrzymany i oczekiwać na zakończenie podprocesu
zdarzeniowego (zdarzenie początkowe przerywające ).
Uwaga: zdarzenie błędu nie posiada formy nieprzerywającej proces
2.5. Podproces zdarzeniowy
3. Zdarzenia (Events)
3.1. Zdarzenie nieprzerywające (Non-Interrupting Events)
3.2. Eskalacja (Escalation Events)
3.3. Wielokrotne równoległe (Multiple Parallel Events)
3.1. Zdarzenie nieprzerywające

Ogólne informacje:
• symbol: okrąg narysowany przerywaną linią,
• znaczenie biznesowe typu zdarzenia przerywającego jest analogiczne
do znaczenia typu zdarzenia nieprzerywającego np. znak koperty w
obu przypadkach oznacza wiadomości.
Założenia:
• stosujemy na starcie podprocesów, które nie przerywają działania
procesu nadrzędnego (całość dzieje się niezależnie „w tle”) np. w
procesie zarządzenia sprzedażą może odbywać się cykliczna
weryfikacja miejsca zamieszkania klientów,
• stosujemy w przypadku zdarzeń krawędziowych przechwytujących
wyzwalacze, gdy odstępstwo od zwykłego procesu i obsługa
przepływu wyjątkowego nie powinna zakończyć procesu /
podprocesu np. w procesie monitorowania poczty pojawił się
komunikat sugerujący naruszenie bezpieczeństwa narodowego.
3.1. Zdarzenie nieprzerywające
3.1. Zdarzenie nieprzerywające
3.1. Zdarzenia przerywające a zdarzenia
nieprzerywające
3.1. Zdarzenia początkowe podprocesów zdarzeniowych
3.1. Zdarzenia pośrednie krawędziowe
3.2. Zdarzenie „Eskalacja”

Zdarzenie eskalacji (Escalation Events) jest stosowane, gdy chcemy

zwrócić uwagę na fakt wystąpienia problemu i wyeskalować go, ale nie
chcemy używać zdarzenia błędu (Error Events). Eskalacja zazwyczaj
przedstawia sytuację wymagającą interwencji człowieka np. realizacja
czynności przedłuża się i wymagane jest zaraportowanie problemu do
osoby nadzorującej proces.
Uwaga: każde zdarzenie eskalacji może mieć określony parametr
escalationCode, dzięki czemu możliwe jest eskalowania w jednym
podprocesie wielu różnych sytuacji.
3.2. Zdarzenie „Eskalacja”
3.3. Zdarzenie „Wielokrotne równoległe”

Uruchomienie procesu / podprocesu zależy od wszystkich możliwych

wyzwalaczy zdefiniowanych w ramach wielozdarzenia równoległego.
Zdarzenie wielokrotne równoległe (Multiple Parallel Events) w
przeciwieństwie do zdarzenia wielokrotnego (Multiple Events) wymaga
spełniania wszystkich warunków, a nie tylko przynajmniej jednego z
wielu różnych wyzwalaczy.
4. Bramki oparte na zdarzeniach
początkowych (Gateways)
4.1. Równoległa bramka rozpoczynająca proces

Bramka równoległa rozpoczynająca proces (Parallel Event-Based

Gateway to start a Process) jest stosowana, gdy chcemy podkreślić fakt
rozpoczęcia procesu pod wpływem kliku różnych zdarzeń np. proces
rekrutacji na zajęcia w BPMN rozpoczyna się, gdy nadeszła
zdefiniowana data i wpłynął wniosek. W praktyce oznacza to, że
dopiero pojawienie się wszystkich kolejnych zdarzeń tworzy nową
instancję procesu.
4.1. Równoległa bramka rozpoczynająca proces
4.2. Wykluczająca bramka rozpoczynająca proces

Wykluczająca bramka rozpoczynająca proces (Exclusive Event-

Based Gateway to start a Process) jest stosowana, gdy chcemy
podkreślić fakt rozpoczęcia procesu pod wpływem zajścia jednego z
wielu zdarzeń np. proces rekrutacji na zajęcia w BPMN rozpoczyna się,
gdy zgłoszenie wysłano pocztą lub zgłoszenie wysłano pocztą
elektroniczną lub zgłoszenie wysłano komunikatem SMS. W praktyce
oznacza to, że każde pojawienie się kolejnego dowolnego zdarzenia
początkowego tworzy nową instancję procesu.
4.2. Wykluczająca bramka rozpoczynająca proces
5. Obiekty danych (Data Objects)
5.1. Asocjacja a obiekty danych

Asocjacja (Data Associations) używana w kontekście prezentacji

danych służy do łączenia obiektów danych z:
• innymi obiektami danych (Data Objects),
• zdarzeniami (Events),
• zadaniami (Activities).
Uwaga: w przypadku obiektów danych powinniśmy stosować asocjację
skierowaną, czyli asocjację zakończoną grotem oznaczającym kierunek
asocjacji.
5.1. Asocjacja a obiekty danych
5.2. Dane wejścia i wyjścia

Typ obiektu Nazwa obiektu Symbol Przykład

Elektroniczny
Obiekt danych
indeks
Wewnętrzny

Magazyn danych Baza ocen

Niesprawdzony
Obiekty wejścia
indeks

Zewnętrzny

Sprawdzony
Obiekt wyjścia
indeks
5.2. Dane wejścia i wyjścia
5.3. Magazyn danych

Magazyn danych (Data Stores) (np. repozytorium, baza danych)

stosujemy, gdy dane przetwarzane w procesie biznesowym są
przechowywane w określonym miejscu niezależnie od tego czy proces
aktualnie działa czy jest nieaktywny. Magazyn może pełnić
jednocześnie funkcje źródła danych (source) oraz miejsca zapisu danych
(target).

Proces Nazwa obiektu Przykład

Obiekt danych Elektroniczny bilet lotniczy

Transport
pasażera
Magazyn danych Rejestr biletów

Obiekt danych FV
Akceptacja FV i
płatności
Magazyn danych Baza FV i płatności
5.4. Kolekcja danych

Kolekcję danych (Collection of Data) stosujemy w odniesieniu do grup

posiadających identyczną strukturę danych:
• obiekty danych wewnętrznych,
• obiekty danych wejściowych,
• obiekty danych wyjściowych.
 5.5. Magazyn danych i kolekcja danych

Uwaga: realizacja procesu obejmuje całą kolekcję faktur, a nie pojedynczą fakturę
6. Kolaboracje i konwersacja
6.1. Kolaboracja

Kolaborację (Collaboration) stosujemy w przypadku konieczności

zamodelowania procesu biznesowego wraz z jego szerszym kontekstem.
Diagram kolaboracji umożliwia ukrycie nieistotnych w danej chwili
fragmentów procesu.
Postacie:
• pełna z pulami w poziomie,

• pełna z pulami w pionie,

• uproszona z pustymi pulami
6.1. Kolaboracja

Założenia:
1. Kolaboracja, to zbiór co najmniej dwóch pul reprezentujących
uczestników danego procesu.
2. Wybrane pule mogą zawierać tylko nazwy roli bez modelu czynności, ale
nie muszą.
3. Komunikacja między uczestnikami opisywana jest jako za pomocą
przepływów komunikatu.
4. Przepływy komunikatów nie muszą być opisane.
5. Możliwe jest pominięcie obramowania pul.
6. Możliwe jest wprowadzenie różnej rozpiętości i ułożenia pul.
6.2. Konwersacja

Konwersację (Conversation) stosujemy w przypadku konieczności

przygotowania poglądowych modeli obserwowanych „z lotu ptaka”.
Diagram konwersacji umożliwia szybkie uchwycenie przestrzeni
biznesowej (business context diagram) poprzez:
• pominięcie szczegółów realizacji procesu,
• wyeksponowanie powiązań między uczestnikami.
6.2. Konwersacja
Założenia:
1. Uczestnicy procesu prezentowani są za pomocą pul.
2. Komunikaty między pulami prezentowane są za pomocą węzłów
konwersacji (Conversation).

Uwaga: węzeł odpowiedzialny jest za agregację konwersacji.

3. Węzły konwersacji łączone są z pulami za pomocą łączy konwersacji.

4. Jeżeli wymiana komunikatów jest złożona i zawiera konwersacje

podrzędne, to stosujemy konwersację złożoną (Sub-Conversation).
6.3. Choreografia

Choreografię (Choreography) stosujemy w przypadku konieczności

przygotowania wzorców wymiany komunikatów (Message Exchange
Patterns), czyli prezentacji interakcji zachodzących między
uczestnikami procesu. Choreografie wymuszają tworzenie
jednoznacznych modeli bez rozpisywania ich szczegółów, a w
przypadku kolaboracji i konwersacji mamy do czynienie z naumyślnym
pomijaniem szczegółów.
6.3. Choreografia
Założenia:
1. Uczestnicy:
• W choreografii musi występować co najmniej dwóch uczestników.
• Uczestnik nadający komunikat jest zawsze jeden i znajduje się na
jasnym tle.
• Uczestnicy odbierający komunikaty znajdują się na ciemnym tle i
może być ich dowolna ilość.
6.3. Choreografia
Założenia cd:
3. Jednokierunkowe zadanie choreografii odpowiada fragmentowi procesu
w którym jeden z uczestników wysyła komunikat.

4. Dwukierunkowe zadanie choreografii odpowiada fragmentowi procesu w

którym poza wysyłaniem komunikatu następuje odpowiedz zwrotna.
6.3. Choreografia
Założenia cd:
5. Rodzaje choreografii:
• choreografia prosta oznacza
wysłania komunikatu
i opcjonalnie odebranie
odpowiedzi

• choreografia złożona składa się z innych zdań choreografii lub jest

wielokrotną wymianą komunikatów między uczestnikami
6.3. Choreografia
Założenia cd:
6. Charakter choreografii:

niepowtarzalna

pętla

wieloinstancyjność równoległa

wieloinstancyjność sekwencyjna
7. Posters
7.1. BPMN 2.0
7.2. BPMN 1.2
7.1. Poster BPMN 2.0
7.2. Poster BPMN 1.2
Dziękuję za uwagę