Download as pdf or txt
Download as pdf or txt
You are on page 1of 78

Modelowanie procesów biznesowych

– BPMN cz. I

1
Plan wykładu

• Literatura
• Wprowadzenie
• Bramki
• Zdarzenia
• Czynności
• Przepływy
• Pule i tory
• Obiekty
• Przykład

2
Literatura*

• http://www.omg.org/spec/BPMN/2.0/ – witryna organizacji


odpowiedzialnej m.in. za aktualną wersję BPMN

• Bruce Silver: BPMN Method and Style

• Thomas Allwayer: BPMN 2.0

• Marek Piotrowski: Notacja modelowania procesów biznesowych

• Szymon Drejewicz: Zrozumieć BPMN

• http://www.mgx.com.pl/pdf/BPMN2_0_Poster_PL.pdf

*w prezentacji wykorzystano przykłady z wyżej wymienionych pozycji


3
• Literatura
• Wprowadzenie
• Bramki
• Zdarzenia
• Czynności
• Przepływy
• Pule i tory
• Obiekty
• Przykład

4
Pojęcie procesu

• Proces w językach programowania

• Procesy w naukach inżynierskich (procesy


chemiczne, procesy sterowania w automatyce)

• Produkcja oprogramowania

• Procesy biznesowe (zarządzanie, informatyka)

5
Definicje procesu
biznesowego (1)
• Proces biznesowy jest to logiczna organizacja ludzi, materiałów,
energii, wyposażenia i procedur w działalności zawodowej
przeznaczony do uzyskania określonego efektu końcowego (Pall,
1987, Zarządzanie)

• Proces biznesowy jest zdefiniowany jako łańcuch działań, których


ostatecznym celem jest produkcja konkretnej wartości wyjściowej
dla konkretnego klienta lub rynku (Davenport, 1993, Ekonomia)

• Proces biznesowy jest zbiorem czynności, ma jeden lub więcej


rodzajów wejść i tworzy wartość wyjściową dla klienta. Proces
biznesowy posiada swój cel, a oddziałują na niego zdarzenia
zachodzące w świecie zewnętrznym lub w innych procesach
(Hammer and Champy, 1993, Nauki inżynierskie)

6
Procesy biznesowe

• Określony zbiór czynności biznesowych, które stanowią


niezbędne kroki w celu osiągnięcia celu biznesowego.
Obejmuje on przepływ i użycie informacji oraz zasobów
(OMG, 2011)

• Proces biznesowy jest to zbiór powiązanych procedur lub


działań, które wspólnie zapewniają osiągnięcie celu
biznesowego lub celu polityki, zwykle w ramach struktury
organizacyjnej definiującej funkcjonalność ról i zależności
pomiędzy nimi (WfMC, 1999)

• Proces biznesowy to seria powiązanych ze sobą działań lub


zadań, które rozwiązują określony problem lub prowadzą do
osiągnięcia określonego efektu (Wikipedia, 2012)

7
Dlaczego warto modelować
procesy biznesowe?
 Odpowiedzialność za zadania (co kto robi)

 Alokacja zasobów (jak przypisać zadania)

 Związki (kto/co z kim/czym się komunikuje)

 Przepływy informacji (skąd biorą się dokumenty i gdzie trafiają)

 Ścieżki krytyczne (gdzie mogą pojawić się problemy)

 Optymalizacja procesów (jak zwiększyć produktywność, obniżyć, koszty


przyśpieszyć proces?)

 Automatyzacja (które czynności można zautomatyzować)

8
Reguły wyrazem strategii
1/4
Reguły wyrazem strategii
2/4
Reguły wyrazem strategii
3/4
Reguły wyrazem strategii
4/4
Standardy i organizacje
standaryzujące
• Workflow Management Coalision (WfMC)
– model referencyjny
– standardy składowania, wymiany definicji procesów
oparte o XML (XPDL, WAPI, Wf-XML),
– interoperacyjność

• Business Process Management Initiative (BPMI)


– Business Process Modeling Language (BPML)

• Object Management Group (OMG)


– Business Process Model and Notation (BPMN)

13
Troszeczkę historii…

• 2001 – opracowanie BPML przez organizację BPMI

• 2004 – przedłożenie BPMN do akceptacji przez OMG

• 2006 – akceptacja BPMN przez OMG

• 2011 – wersja 2.0

14
BPMN vs. diagramy
czynności

BPMN Diagramy czynności

– projektowany dla – projektowane dla


„ludzi biznesu” informatyków
– czytelny i zrozumiały – uniwersalność
dla czytelnika konstrukcji
– duża liczba – minimalna liczba
elementów elementów
– łatwość modelowania – trudniejszy w
modelowaniu
15
Poziomy modelowania w
BPMN
Model poglądowy
 ogólny zarys procesu biznesowego, bez szczegółów takich jak typy zadań, parametry
bramek, obiektów danych, rozwiniętych podprocesów; służy po to, by szybko
zorientować się z czym mamy do czynienia?

Model analityczny
 Dodane szczegóły zadań, parametry bramek, wyspecyfikowane obiekty,
uszczegółowiona komunikacja miedzy uczestnikami; służy m.in. do oceny rozmiaru
prac koniecznych do wdrożenia

Model wykonywalny
 precyzyjnie opisuje proces, zadania, wszystkie używane dane i konstrukcje oraz
metody komunikacji; służy do wdrożenia na silniku procesów

16
• Literatura
• Wprowadzenie
• Bramki
• Zdarzenia
• Czynności
• Przepływy
• Pule i tory
• Obiekty
• Przykład

17
Bramki

Służą do sterowania przebiegiem procesu

Sterownie przepływem polega rozgałęzieniu procesu na


ścieżki alternatywne, równoległe lub funkcjonujące według
praktycznie dowolnej reguły oraz na łączeniu tych ścieżek

Z każdej bramki może dochodzić wychodzić wiele


przepływów sekwencji

BPMN dopuszcza tzw. bramki zdarzeniowe (sterowane


zdarzeniami)

18
Bramka XOR (decyzyjna,
wykluczająca)
 Bramka XOR (decyzyjna) służy do wybrania tylko jednej z wielu ścieżek

 Wybór dokonywany jest na podstawie warunku

 Wybierana jest ścieżka dla której warunek jest prawdziwy

 Na projektancie leży obowiązek zadbania, żeby warunki nie zachodziły na


siebie i pokrywały całą przestrzeń wartości

 Jest to najczęściej stosowana bramka

 Jej działanie odpowiada konstrukcji programistycznej if-then-else

 Bramka może posiadać ścieżki warunkowe i ścieżkę domyślną


(wykonywaną wtedy, gdy żadna z alternatyw nie jest prawdziwa)

19
Bramka XOR - przykład
Przepływ
domyślny

Bramka XOR

• Jeśli zlecenie jest poprawne i kwota > 1000 zlecenie zostanie przekazane od
BOK

• Jeśli zlecenie zawiera błędy, zostanie odrzucone

• W pozostałych przypadkach zlecenie będzie przetwarzane (przepływ


domyślny)

20
Bramka równoległa

• Bramka równoległa rozdziela proces na dwie lub więcej ścieżek


wykonywanych równolegle

• Każde z zadań na ścieżkach równoległych zostanie uruchomione

• Równoległość w BPMN oznacza, że zadania mogą być wykonywane w


tym samym czasie, głównie jednak chodzi o to, że zadania są
wykonywane niezależnie od siebie

• Bramka równoległa służy również do synchronizacji niezależnych


przebiegów

21
Bramka Równoległa –
przykład
 Podróż jest możliwa tylko wtedy, kiedy dokonamy rezerwacji
samolotu i rezerwacji hotelu
 Obydwie czynności musza być wykonane, ich kolejność nie
ma jednak znaczenia

• Obydwa zadania będą wykonane (niezależnie)


• Proces zakończy się tylko wtedy, gdy skończą się obydwa
zadania

22
Bramka OR

• Jako bramka rozdzielająca sprawdza warunki na każdej z


wychodzących ścieżek i uruchamia te z nich na których warunek jest
prawdziwy

• Jeśli występuje ścieżka domyślna, wówczas jest ona uruchamiana tylko


wtedy, gdy żadna z pozostałych nie została uruchomiona

• Może funkcjonować jako bramka XOR lub równoległa (zależy od


wyrażenia na ścieżkach wyjściowych)

• Jako bramka scalająca działa „inteligentnie” i synchronizuje tylko te


przebiegi, które zostały odpalone na odpowiadającej jej bramce
rozdzielającej

23
Bramka Or – przykład

 Klient podjeżdża na stację benzynową celem zatankowania


samochodu (obowiązkowe)
 W trakcie tankowanie może uzupełnić płyn do spryskiwacza, może
też umyć szyby

• Możliwe jest realizacja następujących zbiorów zadań:


– Samochód jest tankowany
– Samochód jest tankowany, szyby są myte
– Samochód jest tankowany, płyn jest uzupełniany
– Samochód jest tankowany, szyby są
24 myte, płyn jest uzupełniany
Bramka złożona

• Bramka złożona jako jedyna posiada własne wyrażenie


określające zachowanie

• Pozostałe bramki wykorzystują wyrażenia zdefiniowane na


przebiegach

• Bramka złożona przy rozwidleniu przepływu zachowuje się


podobnie jak bramka OR

• Bramka złożona przy scalaniu przebiegów posiada


możliwość weryfikacji warunku na bramce
25
Bramka złożona – przykład
 Pracownicy dostali polecenie wyszukania pewnych informacji
 Informacje mogą być wyszukiwane w Internecie lub bibliotece
 Należy rozpocząć poszukiwania w obydwu źródłach i zakończyć,
kiedy zostanie znaleziona potrzebna informacja

• Rozpoczęte zostaną dwa zadania: wyszukiwanie w Internecie i


wyszukiwanie w bibliotece
• Proces zakończy się jeśli przynajmniej jedno z równoległych zadań
zostanie zakończone

26
• Literatura
• Wprowadzenie
• Bramki
• Zdarzenia
• Czynności
• Przepływy
• Pule i tory
• Obiekty
• Przykład

27
Zdarzenia

• Zdarzenie oznacza wystąpienie pewnej sytuacji w przebiegu


procesu biznesowego, istotnej z punktu widzenia tego
procesu

• Zdarzenie może oznaczać odebranie lub wysłanie


komunikatu, sygnału, nadejście pewnego czasu

• Zdarzenia mogą rozpoczynać, kończyć, przerywać proces

• Zdarzenia umożliwiają modelowanie takich elementów jak:


– Komunikacja
– Transakcje
– Wyjątki
– Kompensacje

28
Rodzaje zdarzeń

• Początkowe – oznacza rozpoczęcie


procesu lub podprocesu

• Pośrednie – może pojawić się jako krok


w procesie

• Końcowe – oznacza zakończenie ścieżki


procesu

29
Zdarzenia początkowe

• Istnieje 7 rodzajów zdarzeń początkowych

• Każde z tych zdarzeń reprezentuje inny sposób i


okoliczności w jakich uruchamiany jest proces

• Zdarzenia początkowe mogą posiadać tylko


przepływy wychodzące

• Zdarzenia początkowe są opcjonalne

• Proces może posiadać wiele zdarzeń


początkowych

30
Nieokreślone zdarzenie
początkowe
• Nieokreślonego zdarzenia początkowego używa się w sytuacji, gdy proces ma rozpocząć
wewnętrzny uczestnik

• Każdy proces który w pewnych warunkach będzie funkcjonował jako podproces powinien
mieć jedno nieokreślone zdarzenie początkowe

• Jeśli proces nie posiada nieokreślonego zdarzenia początkowego, to nie może


funkcjonować jako podproces

• Procesy rozpoczynające się od niekreślonego zdarzenia mogą być uruchamiane przez


tzw. czynność wywołania, czyli mogą być uruchamiane przez inne procesy

31
Zdarzenie początkowe
czasowe (Timer)
• Proces rozpocznie się, kiedy określony warunek
związany z czasem zostanie spełniony

• Warunek może oznaczać konkretną datę i czas,


np. 1 styczeń 2013 lub też powtarzającą się datę
i/lub czas, np. każdy wtorek o 16.30

32
Zdarzenie początkowe
warunkowe (Conditional)
• Pozwala na uruchomienie procesu w sytuacji, gdy pewien warunek
stanie się prawdziwy

• Implementacja zdarzenia wymaga ciągłego monitorowania warunku

• Zasada działania zdarzenia warunkowego podobna jest do zasady


działania wyzwalacza w bazach danych

33
Zdarzenie początkowe
Komunikat (Message)
• Proces jest uruchamiany, gdy dotrze odpowiedni komunikat
• Komunikaty są formą porozumiewania się pomiędzy uczestnikami biznesowymi
(pulami)
• BPMN nie dopuszcza przesyłania komunikatów w obrębie tej samej puli
• Komunikaty są kierowane do określonego adresata
• Na diagramie zaznacza się przepływ komunikatu

34
Zdarzenie początkowe
Sygnał (Signal)
• Proces jest uruchamiany, gdy dotrze odpowiedni sygnał

• Sygnały są rozgłaszane (broadcasting) i nie mają określonego adresata

• Nadawca sygnału nie ma świadomości istnienia odbiorcy (nie ma potrzeby


rejestracji odbiorców)

• Na diagramie nie zaznacza się powiązania pomiędzy nadawcą sygnału a


odbiorcą, bo sygnał nie ma adresata

35
Komunikat vs. Sygnał

Komunikat Sygnał

Komunikat jest kierowany do Sygnał jest nie jest kierowany do


określonego uczestnika określonego odbiorcy tylko rozgłaszany
Nadawca musi wiedzieć do kogo chce (publikowany)
wysłać komunikat Każdy może zasubskrybować się by
odbierać sygnał

Komunikat może uruchomić co najwyżej Sygnał może uruchomić wiele procesów


jeden proces

Komunikaty mogą być wysyłane tylko Sygnały mogą być przesyłane pomiędzy
pomiędzy pulami (uczestnikami) pulami i ramach tej samej puli

36
Wielozdarzenie początkowe
zwykłe i równoległe (Multiple
i Parallel)
• Wielozdarzenie zwykłe jest zbiorem zdarzeń
początkowych funkcjonujących według
następującej reguły
– Wystąpienie jednego z tych zdarzeń powoduje
uruchomienie procesu

• Wielozdarzenie równoległe jest zbiorem


zdarzeń początkowych funkcjonujących według
następującej reguły:
– Proces jest uruchamiany tylko wtedy, gdy
wystąpią wszystkie zdarzenia

37
Zdarzenia końcowe

• Zdarzenie końcowe reprezentuje koniec przepływu w


procesie lub w jednej z jego ścieżek
• Proces może zawierać dowolną skończona liczbę
zdarzeń końcowych (również zero)
• Zakończenie procesu może oznaczać wytworzenie
jakiegoś rezultatu (komunikat, sygnał, itp.)
• Jeśli nie ma zdarzenia początkowego, wówczas
można pominąć zdarzenie końcowe, gdy proces nie
wytwarza żadnego rezultatu
• Jeśli model zawiera zdarzenie początkowe to
wymagane jest również zdarzenie końcowe

38
Zalecenia projektowe

• O ile nie zaleca się dużej liczby zdarzeń początkowych, o


tyle w przypadku zdarzeń końcowych jest dokładnie
odwrotnie

• Powinno się tworzyć zdarzenia końcowe dla każdej innej


wartości zwracanej przez proces

• Jeśli proces posiada rozgałęzienie równoległe i po złączeniu


przebiegów występuje tylko zdarzenie końcowe, wówczas
zaleca się nie łączyć przebiegów, tylko zakończyć dwoma
lub większą liczbą zdarzeń końcowych

39
Zdarzenie końcowe
Przerwanie (Terminate)
• Zdarzenie oznacza zakończenie procesu niezależnie
od liczby aktywnych ścieżek

• Zdarzenie powoduje zakończenie procesu na


bieżącym poziomie i wszystkich jego podprocesów

• Zdarzenie nie przerywa procesów nadrzędnych

• Po wystąpieniu zdarzenia w podprocesie proces


nadrzędny jest kontynuowany tak jakby ukończył się
w normalnym trybie

40
Zdarzenie końcowe
nieokreślone
• Zdarzenie końcowe Nieokreślone oznacza zakończenie
bieżącej ścieżki procesu bez wytwarzania określonego
rezultatu lub też zakończenie bieżącej ścieżki procesu z
wytworzeniem rezultatu innego niż w pozostałych
zdarzeniach końcowych

• Zdarzenie końcowe Komunikat oznacza zakończenie


bieżącej ścieżki procesu i przekazanie określonego
komunikatu do innego uczestnika procesu

• Zdarzenie końcowe Sygnał oznacza zakończenie


bieżącej procesu i rozgłoszenie określonego sygnału,
który może być odebrany przez dowolnego (w tym tego
samego) uczestnika procesu

41
Throwing vs. Catching

• Zdarzenia dzielą się na dwie główne kategorie:


– Zdarzenia typu catch – oczekuje na nadejście określonego komunikatu
sygnału, itp., po jego nadejściu proces przechodzi dalej
– Zdarzenia typu throw – wytwarza (generuje, wyrzuca) pewien komunikat
sygnał, itp., po „wyrzuceniu” proces przechodzi dalej

• Zdarzenia początkowe występują w wersji catch

• Zdarzenia końcowe występują w wersji throw

• Zdarzenia pośrednie mogą występować w wersji throw lub


catch

42
Zdarzenia pośrednie

Throw Catch • Zdarzenie pośrednie


oznacza sytuację w trakcie
Nieokreślone wykonywania procesu
Komunikat biznesowego, która jest
Czas istotna z punktu widzenia
tego procesu
Eskalacja
Sygnał • Zdarzenia pośrednie służą
Wielozdarzenie do modelowania wysyłania i
odbierania komunikatów,
Warunkowe sygnałów, opóźnień,
Kompensacja sytuacji wyjątkowych oraz
Link kompensacji

43
Bramka zdarzeniowa (1)

• Bramka zdarzeniowa reprezentuje rozgałęzienie typu alternatywa, przy


czym wybór konkretnej ścieżki zależy od wystąpienia określonego
zdarzenia

• Zdarzenia występujące w bramce muszą być typu catch

• Bramka zdarzeniowa po aktywacji oczekuje na zajście jednego ze


zdefiniowanych zdarzeń

• Wystąpienie takiego zdarzenia powoduje, że przebieg przechodzi dalej,


a pozostałe ścieżki są dezaktywowane

44
Bramka zdarzeniowa (2)

• Autoryzacja przy pomocy kodu np. SMS przebiega zwykle według


następującego schematu:
– System wysyła SMS z kodem autoryzującym i prosi o wprowadzenie kodu do
formularza
– Użytkownik wprowadza kod do formularza wówczas podejmowana jest próba
autoryzacji
– Jeśli w ciągu np. 60 sekund kod nie zostanie wprowadzony proces autoryzacji
kończy się
45
Bramka zdarzeniowa (3)

• Działanie bramki przypomina tzw. race condition


(wygrywa ta ścieżka, która pierwsza odbierze komunikat

• Wykorzystuje się często do obsługi przekroczeń czasowych


(timeout) oraz do obsługi wyjątków

• W odróżnieniu od pozostałych bramek nie opiera się na


danych tylko na zdarzeniach

46
• Literatura
• Wprowadzenie
• Bramki
• Zdarzenia
• Czynności
• Przepływy
• Pule i tory
• Obiekty
• Przykład

47
Czynność

• Czynność to praca wykonana w ramach procesu


biznesowego

• Wykonanie czynności zajmuje określony czas oraz wymaga


zaangażowania określonych zasobów

• Zwykle konieczne jest wprowadzenie pewnych danych


wejściowych

• W efekcie realizacji powstaje też często pewien wynik


(produkt, usługa, dokument)

48
Rodzaje czynności

• Zadanie
Czynność atomowa

• Podproces
Czynności nie atomowe

• Czynność wywołania
Reprezentuje wywołanie innej
czynności

49
Zadanie

Zadanie jest przykładem czynności, która nie jest


dekomponowana na prostsze czynności (czynność atomowa)

W modelowanej rzeczywistości dekompozycja zadania na


prostsze czynności zwykle istnieje

Przyjmuje się jednak, że taka dekompozycja nie jest istotna z


punktu widzenia modelowanego procesu

Zadanie nie jest funkcją systemu ani nie jest stanem systemu –
zadanie to praca wykonana w ramach procesu

Przykład:
Wprowadzenie danych do formularza rejestracyjnego serwisu pocztowego

50
Rodzaje zadań

• Niezdefiniowane (none)
• Użytkownika (user)
wykonuje użytkownik pod kontrolą systemu informatycznego
• Manualne (manual)
wykonuje użytkownik bez kontroli systemu informatycznego
• Usługowe (service)
wywołuje usługę sieciową lub określoną aplikację
• Wysłania (send)
wysyła wiadomość do zewnętrznego uczestnika
• Odebrania (receive)
Oczekuje i odbiera wiadomość od zewnętrznego uczestnika

• Skryptowe (script)
wykonuje dostarczony skrypt

• Reguły biznesowej (business rules)


wykonuje reguły biznesowe na silniku reguł
51
Zadanie niezdefiniowane
(None lub Abstract)
Nie posiada wyspecyfikowanego
rodzaju pracy do wykonania

Na diagramie może oznaczać każdy


rodzaj zadań

Jest używane w początkowej fazie


odkrywania procesu, kiedy nie znamy
jeszcze szczegółów realizacji
poszczególnych zadań

Jeśli nie jest planowana implementacja


procesu zadanie niezdefiniowane może
istnieć również w końcowej wersji
modelu procesu

52
Zadania wykonywane przez
człowieka
Zadanie użytkownika reprezentuje
dowolną pracę w procesie biznesowym,
która jest wykonywana przez człowieka z
wykorzystaniem systemów
komputerowych
(np. wysłanie e-maila, opracowanie danych w
arkuszu, wprowadzenie danych do CRM)

Zadanie manualne reprezentuje dowolną


pracę w procesie biznesowym, która jest
wykonywana przez człowieka bez
używania systemów komputerowych
(np. sortowanie listów, dostarczenie przesyłki)

53
Zadanie użytkownika

• Zadanie wykonywane przez użytkownika wiąże się z


następującymi operacjami

• Utworzenie tzw. workitem i dodanie do listy zadań do


wykonania przez użytkownika

• Powiadomienie użytkownika, że pojawiło się nowe zadanie


do wykonania

• Dostarczenie danych procesowych i dokumentów


niezbędnych do realizacji zadania
54
Zadanie usługowe (Service)

 Zadanie wykonywane automatycznie przez zewnętrzny


system na żądanie silnika procesów
 Domyślne zachowanie polega na wywołaniu usługi
sieciowej (web service)
 Możliwe są inne implementacje niż usługa sieciowa
(zależy od dostawcy systemu)
 Usługi sieciowe mogą być wywoływane synchronicznie
lub asynchronicznie
 Wywołanie synchronicznie wstrzymuje proces do momentu
powrotu z usługi
 Wywołanie asynchronicznie nie wstrzymuje procesu
 Zadanie usługowe służy do modelowania usług
wywoływanych w sposób synchroniczny
 Wywołania asynchroniczne modelowane są przy
pomocy zdarzeń wysyłania i odbierania komunikatów
55
Zadanie wysłania (Send)

Zadanie wysłania polega na wysłaniu


komunikatu do innego uczestnika (puli)

Zadanie jest realizowane automatycznie


przez silnik procesów biznesowych
wspierany przez inny system /komponent

Człowiek nie uczestniczy w realizacji tego


zadania

Wysłanie komunikatu może być


alternatywnie modelowane przez zdarzenie
typu komunikat (throw)
56
Zadanie odebrania
(Receive)
Zadanie polega na odebraniu komunikatu
od innego uczestnika

Zadanie jest realizowane automatycznie


przez silnik procesów biznesowych
wspierany przez inny system /komponent

Człowiek nie uczestniczy w realizacji tego


zadania

Odebranie komunikatu może być


alternatywnie modelowane przez
zdarzenie Komunikat (catch)
57
Zadania wysyłania i
odbierania

• Jeśli w przepływ komunikatów zaangażowany jest człowiek


(np. wysłanie maila, faksu, rozmowa telefoniczna), wówczas
należy używać zadania użytkownika

• Jeśli przepływ komunikatów odbywa się na linii maszyna-


do-maszyna (np. SOAP, JMS), wówczas należy stosować
zadanie wysyłania i odbierania lub zdarzenia typu
komunikat (catch + throw)

58
Zadanie skryptowe (script)

 Polega na wykonaniu pewnego skryptu

 Zadanie jest realizowane automatycznie przez


silnik procesów biznesowych

 Silniki procesów potrafią uruchomić skrypty w


JavaScript, Xpath i wiele innych

 BPMN nie definiuje języka skryptowego

 Silniki procesów potrafią przekazać dane z


procesu do skryptu i odebrać wyniki działania
skryptu

 Skrypty reprezentują zazwyczaj proste


zadania przetwarzania danych; stosuje się je
tam, gdzie nie opłaca się używać usług
59
Reguły biznesowe
 Przez regułę biznesową należy rozumieć zbiór powiązanych konstrukcji warunkowych typu „jeżeli
A i B to C”

 Reguły biznesowe są niezależne od procesu: proces reprezentuje przepływ zadań, reguły


biznesowe służą wyznaczenia wartości pewnych danych/obiektów

 Reguły biznesowe mogą reprezentować polityki biznesowe możliwe do wykorzystania w różnych


procesach (np. sprawdzanie czy klient może być zaliczony do grupy „Premium” lub czy klient jest
wypłacalny?)

 Procesy biznesowe się uruchamia; na regułach biznesowych prowadzi się wnioskowanie

 Reguły biznesowe zwykle są składowane w oddzielnym repozytorium i zarządzane przez System


Zarządzania Regułami Biznesowymi

 Systemy Zarządzania Regułami Biznesowymi są często zintegrowane z Systemami Zarządzania


Procesami Biznesowymi

 Systemy Zarządzania Regułami Biznesowymi oprócz zbiorów reguł udostępniają takie elementy
jak siatki, czy tabele decyzyjne

60
Zadanie reguły biznesowej
(business Rule)
Zadanie polega na
przeprowadzeniu wnioskowania na
bazie reguł biznesowych

W zadaniu bierze udział silnik


procesu i silnik reguł biznesowych

Silnik procesu odpowiada za


przygotowanie danych do
wnioskowania i odebranie wyniku

Silnik reguł odpowiada za


przeprowadzenie wnioskowania
61
• Literatura
• Wprowadzenie
• Bramki
• Zdarzenia
• Czynności
• Przepływy
• Pule i tory
• Obiekty
• Przykład

62
Rodzaje przepływów w
procesie

• Przepływ sekwencji

• Przepływ komunikatów

• Przepływ danych

63
Przepływ sekwencji

• Przepływ sekwencji pomiędzy dwoma elementami A i B (od A do B)


oznacza, że jeśli element A zakończył działanie, wówczas element B
staje się aktywny

• Przepływ sekwencji może zachodzić pomiędzy czynnościami,


zdarzeniami, bramkami,

• Przepływ sekwencji nie może jednak zachodzić miedzy pulami

64
Przepływ komunikatów

• Przepływ komunikatów reprezentuje wiadomość wysyłaną pomiędzy


dwoma pulami (uczestnikami)

• Komunikaty są wysyłane i odbierane przez dedykowane zadania lub


zdarzenia, ale nie jest możliwe by wysyłający i odbiorca znajdowali się w
tej samej puli.

65
• Literatura
• Wprowadzenie
• Bramki
• Zdarzenia
• Czynności
• Przepływy
• Pule i tory
• Obiekty
• Przykład

66
Pule (Baseny) i tory

Pula reprezentuje uczestnika, który


bierze udział w procesie

Pula białej skrzynki zawiera model


procesu

Pula czarnej skrzynki nie zawiera


modelu procesu

Pule białej skrzynki zaleca nazywać


się nazwą procesu

Pule czarnej skrzynki zaleca nazywać


się nazwą uczestnika

Tory mogą reprezentować rolę


uczestnika w organizacji lub dowolny
inny aspekt (np. odpowiedzialność)

Tory mogą być zagnieżdżane

67
Pule i tory

• Ograniczenia nałożone na pule

– Pula może zawierać tylko jeden proces

– Przepływ sekwencji jest ograniczony do jednej puli, nie może


przekraczać granic puli

– Przepływ komunikatów może odbywać się tylko pomiędzy pulami

• BPMN nie określa dodatkowych ograniczeń na tory niż te


wynikające z faktu, że tory znajdują się w puli

68
• Literatura
• Wprowadzenie
• Bramki
• Zdarzenia
• Czynności
• Przepływy
• Pule i tory
• Obiekty
• Przykład

69
Modelowanie danych w
procesie
• BPMN umożliwia modelowanie obiektów
przetwarzanych w procesie biznesowym

• Pojęcie obiektu w BPMN odnosi się do


informacji, danych, dokumentów, obiektów
materialnych

• Do modelowanie obiektów służą następujące


konstrukcje:
– Obiekt danych
– Magazyn danych
– Dane wejściowe i wyjściowe

70
Obiekt danych

• Obiekty danych posiadają stan, który służy do


oznaczenia jak obiekt zmienia się trakcie procesu, np.
obiekt zamówienie może posiadać następujące stany:
złożone, zaakceptowane, opłacone, zrealizowane

• Ten sam obiekt danych może pojawić się w wielu


miejscach w procesie, w każdym z tych miejsc może
znajdować się w innym stanie

• Obiekt danych może być powiązany z


– przepływem sekwencji, komunikatów (zwykła asocjacja),
– czynnościami i zdarzeniami (asocjacja kierunkowa)

• Przepływ obiektów w procesie nie ma wpływu na


przepływ sekwencji

71
Magazyn danych

• Magazyn danych służy do


przechowywania danych procesu
niezależnie od tego czy proces trwa, czy
też został zakończony

• Proces może czytać i zapisywać dane do


magazynu

• Magazyn danych może również być


przydatny w interakcji procesu z
zewnętrznymi systemami

72
dane wejściowe i wyjściowe

• Wejściowe i wyjściowe obiekty są obiektami


zewnętrznymi, istniejącymi przed i/lub po
zakończeniu procesu

• Obiekt wejściowy to obiekt wymagany do


uruchomienia / działania procesu

• Obiekt wyjściowy to obiekt powstały lub


przetworzony w procesie przekazany do otoczenia

• Obiekt może jednocześnie występować w roli


wejściowego i wyjściowego, np. legitymacja
studencka w trakcie procesu prolongaty legitymacji

73
Czas życia obiektów

• Czas życia obiektu danych zależy od jego rodzaju obiektu

• Obiekty wejściowe i wyjściowe żyją niezależnie od procesu

• Obiekty wewnętrzne żyją tylko tyle, ile instancja procesu

• Jeśli obiekt wewnętrzny ma żyć dłużej musi być składowany


w magazynie danych

74
Obiekt danych – przykład

75
• Literatura
• Wprowadzenie
• Bramki
• Zdarzenia
• Czynności
• Przepływy
• Pule i tory
• Obiekty
• Przykład

76
77
KONIEC

78

You might also like