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.