Projektowanie systemu workflow przy

użyciu narzędzia BizAgi Studio

część 1

Definiowanie procesu w notacji BPMN

Instytut Systemów Informatycznych, Wydział Cybernetyki, Wojskowa Akademia Techniczna

Paweł Mieteo, Jarosław Koszela

Spis treści

Wprowadzenie ........................................................................................................................................ 2

Definiowanie procesu przy użyciu notacji BPMN .................................................................................... 3

Wprowadzenie

BizAgi Studio jest środowiskiem, które przekształca procesy zamodelowane w notacji BPMN do
aplikacji bez konieczności programowania. BizAgi oferuje zestaw nazrzędzi do graficznego
projektowania procesu, tworzenia modelu danych oraz definiowania reguł biznesowych.

Poniższy diagram przedstawia kolejne kroki składające się na cykl tworzenia aplikacji:

Rysunek 1. Cykl tworzenia aplikacji

Definiowanie procesu przy użyciu notacji BPMN

Aby rozpocząd projektowanie procesu należy uruchomid narzędzie BizAgi Studio i następnie utworzyd
nowy projekt.

Rysunek 2. Tworzenie nowego projektu (krok 1)

Na pierwszym ekranie należy wybrad opcję New.

Rysunek 3. Tworzenie nowego projektu (krok 2)

Kolejnym krokiem jest nadanie nazwy projektu, w naszym przypadku będzie to TutorialBizAgi.

Rysunek 4. Tworzenie nowego projektu (krok 3)

Ostatnim etapem tworzenia projektu jest automatyczne skonfigurowanie projektu przez narzędzie,
oraz utworzenie bazy danych, w której będzie zapisywany stan naszego projektu. BizAgi Studio
utworzy bazę danych o nazwie TutorialBizAgi.

Po utworzeniu projektu, zostanie otwarte główne okno narzędzia:

Rysunek 5. Główne okno narzędzia BiaAgi Studio

Tworząc aplikacje przy użyciu BizAgi Studio, rozpoczynamy pracę od zdefiniowania procesu. W tym
celu wybieramy opcję New Process.

Rysunek 6. Tworzenie nowego procesu

W pole „Proces Name” wpisujemy nazwę procesu. W naszym przypadku będzie to „Składanie
wniosku o poprawę egzaminu”.

Rysunek 7. BizAgi Process Modeler

Tworzenie procesu odbywa się w zintegrowanym narzędziu o nazwie „BizAgi Process Modeler”.

Po lewej stronie okna mamy paletę, w której znajdują się elementy, z których budujemy Proces.



Flow (Przepływ)

o

Task (zadanie) – Element ten symbolizuje pracę wykonywaną w procesie.

o

Start Event (zdarzenie początkowe) – Inicjuje/określa początek przepływu

procesu.

o

Intermediate Event (zdarzenie pośrednie) – Jest to element znajdujący się

wewnątrz procesu, który określa punkt oczekiwanie na jakieś zdarzenie. Element ten
nie rozpoczyna i nie kooczy procesu.

o

End Event (zdarzenie koocowe) – Element ten wskazuje miejsce zakooczenia

procesu.

o

Gateway (brama logiczna) – Jest to element decyzyjny, który steruje

przepływem, uaktywniając odpowiednie ścieżki w zależności od reguł biznesowych.
Bramy mogą rozdzielad lub łączyd przepływy.



Artifacts (Artefakty) - elementy graficzne nie będące elementem przepływu.

o

Group (grupa) – element grupujący inne elementy diagramu. Stosowany w celu

zwiększenia przejrzystości procesu.

o

Annotation (adnotacja) – Jest to element tekstowy pozwalający opisad diagram.

o

Data Object (dane) – Element pozwalający opisad dokumenty i inne obiektu

wykorzystywane podczas procesu.



Swimlines (Miejsca realizacji procesu/tory pływackie)

o

Line (tor) – Tory służą do podziału procesu w sposób horyzontalny. Zazwyczaj

reprezentują osobę, rolę lub system, do którego należy wykonanie zadao
znajdujących się wewnątrz.

o

Milestone (kamienie milowe) – Elementy te służą do podziału procesu na

logiczne części, reprezentujące etapy systemu.



Connectors (Połączenia)

o

Sequence Flow (Sekwencja przepływu) – Element ten określa kolejnośd

wykonywania się odpowiednich aktywności wewnątrz procesu.

o

Association (Asocjacja) – Połączenie to łączy ze sobą artefakty i obiekty

przepływu.

W modelowanym procesie wyodrębnimy cztery role: student, dziekanat, dziekan i księgowośd. W
związku z tym z wcześniej opisanej palety na nasz diagram przenosimy czterokrotnie ikonkę „Line” i ją
upuszczamy. Każdy tor nazywamy zgodnie z rolami. Czynimy to przez dwuklik na nazwie lub na
kliknięciu na nazwę i wpisaniu nowej nazwy w okienku „Element Properties” na dole głównego okna.
Druga metod umożliwia wpisanie polskich znaków. W analogiczny sposób zmieniamy nazwę każdemu
innemu elementowi na diagramie.

Rysunek 8. Zdefiniowanie torów

Kolejnym krokiem jest wyodrębnienie etapów procesu, tak zwanych kamieni milowych. Do tego celu
użyjemy elementu „Milestone”. Trzy krotnie przeciągamy go na diagram procesu i odpowiednio
ustawiamy nazwy: przyjmowanie wniosku, dokonanie wpłaty, odbiór dokumentów.

Rysunek 9. Zdefiniowanie torów i kamieni milowych

Proces będzie inicjowany przez studenta, a więc element „Start event” umieszczamy w torze
studenta w pierwszym etapie. Jego pierwszym zadaniem będzie złożenie wniosku, w związku z tym
obok elementu startowego umieszczamy „Task” i nazywamy go odpowiednio. Oba elementy łączymy
elementem „Sequence Flow”, również przeciągniętym z lewego panelu.

Rysunek 10. Rozpoczęcie procesu

System daje inny sposób dodawania nowych elementów do procesu. A mianowicie chcąc dodad
kolejny element do przepływu, połączony elementem „Sequence Flow” należy kliknąd na obiekt, z
którego ma wychodzid strzałka. W tym momencie pojawią się elementy, które mogą byd następnymi
w procesie. Należy chwycid odpowiedni i umieścid go w dowolnym miejscu.

Rysunek 11. Element "Start event" w trybie tworzenia następnego elementu

Rysunek 12. Element "Task" w trybie tworzenia następnego elementu

Jak widad drugi sposób jest znacznie szybszy i wygodniejszy.

Pierwszy etap procesu wygląda następująco:

Rysunek 13. Przyjmowanie wniosku - pierwszy etap procesu

Powyższy proces możemy opisad słownie w następujący sposób:

1. Student składa wniosek o poprawę egzaminu
2. Dziekanat poobiera dane o studencie z serwisu zewnętrznego
3. Dziekanat decyduje czy wniosek jest prawidłowo złożony i czy student spełni warunki

formalne

a. Jeśli student definitywnie nie spełnia warunków formalnych to wniosek zostaje

odrzucony oraz wygenerowany zostaje sygnał(powstaje inicjatywa) o skreślenie go z
listy studentów. Koniec procesu.

b. Jeśli wniosek wymaga dodatkowych czynności ze strony studenta to należy go o tym

poinformowad (przejście do punktu 4.)

c. Wniosek poprawny formalnie, więc zostaje przyjęty i przekazany do

dziekana(przejście do punktu 5.)

4. Student dokonuje wymaganych czynności (przejście do punktu 3.)
5. Dziekan ostatecznie rozpatruje wniosek.

a. Dziekan odrzuca wniosek, co kooczy proces oraz wygeneruje sygnał(powstaje

inicjatywa) o skreślenie danej osoby z listy studentów.

b. Dziekan przyjmuje wniosek(Przejście do punktu 6.)

6. Dziekanat wysyła informacje do studenta, że jego wniosek został przyjęty.

Porównując oba opisy tego samego procesu łatwo dostrzec, że reprezentacja graficzna jest łatwiejsza
w zrozumieniu. A sama notacja jest na tyle intuicyjna, że osoba niemająca doświadczenia jest w
stanie zrozumied sens procesu.

Rysunek 14. Nadawanie typu zadaniu

Rysunek 15. Service Task

Zadaniu „Pobieranie informacji o studencie” nadaliśmy typ „Service Task”, co oznacza, że zadanie to
będzie korzystało z serwisu zewnętrznego. Narzędzie umożliwia nam transformacje zadania do
jednego z powyżej zaprezentowanych typów. Robi się to przez menu kontekstowe, a więc należy
kliknąd na dany element, wcisnąd prawy przycisk myszy a następnie wybrad odpowiednią opcję.

Rysunek 16. Pętla wykorzystująca bramę logiczną

Zgodnie z zastosowaniem element w kształcie rombu użyliśmy do stworzenia pętli. Brama logiczna
służy do sterowania przepływem. W powyższym przypadku, w zależności od akcji podjętej na zadaniu
„Przyjmowanie wniosku do rozpatrzenia”, proces może obrad jeden z trzech przewidzianych
wariantów. W przypadku „Odrzucenia warunkowego” przechodzimy do kroku „Dokonanie
wymaganych czynności” i ponownie wracamy do przyjmowania wniosku.

Rysunek 17. Send Task

Kolejnym przykładem użycia zadania określonego typu jest task „Wysłanie wiadomości o przyjęciu
wniosku”, któremu nadaliśmy typ „Send Task”. Opcja ta została ustawiona po przez menu
kontekstowe, w analogiczny sposób jak w przypadku „Service Task”.

Rysunek 18. Nadawanie typu dla zdarzenia koocowego

Rysunek 19. End Event - Signal

W pierwszym etapie naszego przykładu możliwe jest zakooczenie całego procesu. Koniec procesu
oznaczony jest po przez czerwoną obręcz. „End Event” również może przyjmowad jeden z kilku
typów. Nasze zdarzenie koocowe otagowaliśmy typem „Signal”. Oznacza to, że w trakcie zakooczenie
zostanie wygenerowany sygnał, który np. może zostad wykorzystany do automatycznego
uruchomienia innego procesu.

Rysunek 20. Dokonanie wpłaty - Drugi etap procesu

Kolejnym etapem w naszym procesie jest „Dokonanie wpłaty”. System oczekuje na wpłatę 5 dni, jeśli
w tym czasie nie zostanie odnotowane wpłynięcie pieniędzy to proces zostanie zakooczony. W
przypadku, jeśli księgowa odnotuje wpłynięcie pieniędzy na konto rozpocznie się podproces
księgowania wpłaty.

Rysunek 21. Wykorzystanie Event Based Gateway oraz zdarzeo Intermediate Event

Rysunek 22. Nadawanie typu bramce logicznej

Rysunek 23. Bramka logiczna typu "Event Base Gateway"

Jeśli chcemy, aby proces obrał różny przebieg w zależności od zdarzenia, które zajdzie najwcześniej,
należy użyd bramki logicznej i ustawid jej typ „Event Based Gateway”. Następnie trzeba dodad
zdarzenia pośrednie. System wybierze jedną ze ścieżek, a mianowicie tę, na której pierwszej zajdzie
zdarzenie.

Rysunek 24. Nadawanie typu zdarzeniu pośredniemu

Rysunek 25. Zdarzenie pośrednie typu "Timer"

Rysunek 26. Właściwości zdarzenia pośredniego typu "Timer"

Aby zdarzenie odpaliło się po pięciu dniach należy wejśd we właściwości obiektu i w parametrze
„Duration” ustawid odpowiednią wartośd.

Kolejnym korkiem w naszym procesie jest podproces „Zaksięgowanie wpłaty”. Aby go utworzyd
należy najpierw zapisad aktualny proces oraz przejśd do głównego okna w narzędziu BizAgi Studio,
gdzie będziemy mogli dodad nowy proces, który następnie podepniemy jako podproces.

Rysunek 27. Dodanie nowego procesu - Zaksięgowanie wpłaty

Analogicznie jak to robiliśmy w na początku należy dodad nowy proces. Nazwijmy go „Zaksięgowanie
wpłaty”. Po utworzeniu procesu opuśdmy go i powródmy do głównego procesu. Proces księgowania
wpłaty zamodelujemy na koocu.

Rysunek 28. Główne okno BizAgi Studio - zmienianie kontekstu procesu

W celu powrócenia do głównego procesu należy zmienid kontekst pracy narzędzia. W tym celu w
prawnym górnym rogu okna należy z listy rozwijanej wybrad odpowiedni proces. Następnie trzeba
kliknąd opcję „Edit Process”.

Rysunek 29. Stworzenie podprocesu

Rysunek 30. Podproces

W celu wykorzystanie uprzednio stworzonego procesu w głównym procesie należy dodad Task’a,
nadad mu odpowiednią nazwę oraz z menu kontekstowego wybrad opcję „Transfer to subprocess”.
Operacja ta uruchomi kreator za pomocą, którego będziemy mogli skonfigurowad odpowiednio
podproces.

Rysunek 31. Podproces - wybieranie typu

Do wyboru mamy cztery rodzaje procesów:



Embedded –Podproces wbudowany jest aktywnością, która zwiera inne aktywności. Pracuje
on na danych głównego procesu. Nie istnieje możliwośd wykorzystanie tego podprocesu w
innym miejscu w tym procesie ani żadnym innym.



Resuable – Podproces wielokrotnego użytku jest aktywnością, która wywołuje inny proces.
Istnieje możliwośd przekazania danych z głównego procesu do podprocesu oraz w drugą
stronę.



Multiple – Wielokrotny podproces umożliwia wywołanie go wielokrotnie. Ilośd wywołao
zdefiniowana jest przez określona liczbę lub przez licznośd kolekcji danych. Kolejne
wywołania mogą działad w trybie równoległym lub sekwencyjny.



Transactional – Transakcyjny podproces daje nam mechanizm potwierdzający, że dana partia
aktywności wykonała się w całości poprawnie lub cała została wycofana.

W naszym przypadku użyjemy opcji „Resuable”.

Rysunek 32. Podproces - procesu

Kolejnym krokiem jest wybranie procesu, który będzie uruchamiany w ramach tej aktywności.
Wybieramy uprzednio stworzony proces „Zaksięgowanie wpłaty”.

Rysunek 33. Wybranie trybu pracy podprocesu

Do dyspozycji mamy dwa tryby:



Integrated – tryb ten oznacza, że dany podproces musi się zakooczyd zanim główny proces
przejdzie do następnego kroku.



StandAlone –opcja ta pozwala w procesie głównym kontynuowad przebieg, bez znaczenia na
jakim etapie jest pod proces.

W naszym przypadku wybieramy tryb StandAlone, co oznacza, że dziekanat może wydad karty
poprawkowe studentowi nie czekając na zakooczenie procesu księgowania wpłaty.

Rysunek 34. Odbiór dokumentów - Trzeci etap procesu

Ostatnim etapem całego procesu jest „Odbiór dokumentów”. Dziekanat równolegle przygotowuje
karty poprawkowe oraz wprowadza odpowiednie dane do systemu E-dziekanat. Po zakooczeniu obu
tych kroków, może wydad dokumenty studentowi.

Rysunek 35. Przebieg równoległy

W celu uruchomienia wielu równoległych wątków w przebiegu procesu należy użyd bramki logicznej
typu „Parallell Gateway”. Aby sprowadzid rozdzielone wątki ponownie do jednego przebiegu, również
trzeba użyd tej samej bramki. Bramka ta będzie oczekiwad, do póki nie spłyną do niej wszystkie
doprowadzone wątki.

Rysunek 36. Widok całego procesu

W celu manipulowania wielkością diagramu należy wcisnąd przycisk Ctrl oraz użyd scrolla w myszce.