dostępny przez przeglądarkę internetową system modelowania … · 2011. 7. 1. ·...
TRANSCRIPT
-
Akademia Górniczo-Hutnicza
im. Stanisława Staszica
w Krakowie
Praca magisterska
Dostępny przez przeglądarkę
internetową system modelowania
procesów biznesowych zgodnych z
językiem jPDL.
Janusz Bożek, Tomasz [email protected],[email protected]
Kierunek: Informatyka
Specjalność: Systemy rozproszone i sieci komputerowe
Nr albumu:
Janusz Bożek 127091
Tomasz Juszczyk 104477
Promotor
dr inż. Dominik Radziszowski
Wydział Elektroniki Automatyki Informatyki i Elektrotechniki
Kraków 2009
-
Oświadczenie autorów
Oświadczamy, świadomi odpowiedzialności karnej za poświadczenie nieprawdy, że niniej-
szą pracę dyplomową wykonaliśmy osobiście i samodzielnie (w zakresie wyszczególnionym
we wstępie) i że nie korzystaliśmy ze źródeł innych niż wymienione w pracy.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(Podpis autorów)
-
Spis treści
Wstęp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
I. Wprowadzenie
Rozdział 1. Wprowadzenie do tematyki modelowania procesów biznesowych . 11
1.1. Ważniejsze pojęcia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2. Składniki procesu biznesowego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.1. Obiekty sterujące przepływem . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.2. Połączenia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.3. Elementy grupujące . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.4. Artefakty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3. Wzorce przepływu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.1. Sekwencja (ang. sequence) . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.2. Podział równoległy (ang. parallel split) . . . . . . . . . . . . . . . . . . . . 21
1.3.3. Synchronizacja (ang. synchronisation) . . . . . . . . . . . . . . . . . . . . 22
1.3.4. Decyzja (ang. exclusive choice) . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.5. Proste złączenie (ang. simple merge) . . . . . . . . . . . . . . . . . . . . . 23
Rozdział 2. Modelowanie przepływu w informatyce . . . . . . . . . . . . . . . . . 25
2.1. Znaczenie przepływu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2. Aktualne kierunki rozwoju . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2
-
Spis treści
II. Tło technologiczne
Rozdział 3. Obowiązujące standardy . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1. UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2. BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3. XPDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4. BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5. Inne standardy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Rozdział 4. Platforma JBPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1. Standard JBPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2. Format jPDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Rozdział 5. Charakterystyka wybranych technologii . . . . . . . . . . . . . . . . . 50
5.1. Narzędzia modelowania procesów biznesowych . . . . . . . . . . . . . . . . . . . . 50
5.1.1. JBoss jBPM Graphical Process Designer . . . . . . . . . . . . . . . . . . . 50
5.1.2. JBoss jBPM Modeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.3. NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.4. Visual Paradigm Smart Development Environment . . . . . . . . . . . . . 54
5.1.5. Sparx Systems Enterprise Architect . . . . . . . . . . . . . . . . . . . . . . 55
5.1.6. IBM WebSphere Business Modeler . . . . . . . . . . . . . . . . . . . . . . 56
5.1.7. Oracle Business Process Management Suite . . . . . . . . . . . . . . . . . 57
5.2. Baza technologiczna projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.1. OPEN-jACOB Draw2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.2. The Dojo Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.3. Apache Tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.4. Apache Struts 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.5. JSON-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
III. Projekt i implementacja
Rozdział 6. Projekt systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1. Definicja zadania projektowego. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.1.1. Wymagania funkcjonalne . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3
-
Spis treści
6.1.2. Wymagania niefunkcjonalne . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2. Kontekst systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.2.1. Aktorzy systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.2.2. Przypadki użycia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3. Decyzje projektowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.4. Architektura systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.4.1. Moduły aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.4.2. Model wdrożeniowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.5. Model danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.5.1. Model persystencji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.5.2. Dynamiczna reprezentacja projektu biznesowego . . . . . . . . . . . . . . 98
6.5.3. Model procesu biznesowego . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.5.4. Model aplikacji klienckiej . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.6. Specyfikacje interfejsów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.6.1. Komunikacja warstwy prezentacji z warstwą przetwarzania . . . . . . . . . 100
6.6.2. Adaptacja biblioteki JBoss Graphical Process Designer . . . . . . . . . . . 101
6.6.3. Interfejs zewnętrzny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Rozdział 7. Aspekty implementacyjne . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.1. Sposóby organizacji graficznego interfejsu użytkownika . . . . . . . . . . . . . . . 104
7.2. Równoległa obsługa wielu procesów biznesowych . . . . . . . . . . . . . . . . . . . 107
7.3. Komunikacji warstwy prezentacji z warstwą serwera . . . . . . . . . . . . . . . . . 108
7.4. Implementacja obsługi usług sieciowych . . . . . . . . . . . . . . . . . . . . . . . . 110
7.5. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
IV. Podsumowanie
Rozdział 8. Realizacja wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.1. Realizacja wymagań funkcjonalnych . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.1.1. Dodawanie i usuwanie węzłów procesu . . . . . . . . . . . . . . . . . . . . 114
8.1.2. Tworzenie połączeń między węzłami . . . . . . . . . . . . . . . . . . . . . 115
8.1.3. Definiowanie akcji wykonywanej podczas przejścia . . . . . . . . . . . . . 116
8.1.4. Definiowanie zadania wykonywanego w węźle . . . . . . . . . . . . . . . . 117
8.1.5. Modyfikacja graficznej reprezentacji procesu . . . . . . . . . . . . . . . . . 117
4
-
8.1.6. Menadżer historii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.1.7. Utrwalanie pracy użytkownika . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.1.8. Wczytanie danych do systemu . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.1.9. Wdrażanie na maszyny wykonawcze . . . . . . . . . . . . . . . . . . . . . 119
8.1.10. Integracja procesu z usługami sieciowymi . . . . . . . . . . . . . . . . . . 120
8.1.11. Wczytywanie opisu usługi sieciowej . . . . . . . . . . . . . . . . . . . . . . 120
8.1.12. Obsługa repozytorium importowanych binariów . . . . . . . . . . . . . . . 121
8.2. Realizacja wymagań niefunkcjonalnych . . . . . . . . . . . . . . . . . . . . . . . . 121
8.2.1. Intuicyjność interfejsu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
8.2.2. Swoboda dostępu, Łatwość wdrożenia, Wieloplatformowość . . . . . . . . 122
8.2.3. Elastyczność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
8.2.4. Rozszerzalność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
8.2.5. Modułowa konstrukcja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.2.6. Bezpieczeństwo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Rozdział 9. Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
9.1. Podsumowanie realizacji projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
9.2. Kierunki dalszego rozwoju . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
9.2.1. Import i eksport procesu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.2.2. Rozszerzanie możliwości funkcjonalnych edytora . . . . . . . . . . . . . . . 126
9.2.3. Rozszerzenie koncepcji repozytorium . . . . . . . . . . . . . . . . . . . . . 126
9.2.4. System Workflow jako platforma integracyjna . . . . . . . . . . . . . . . . 126
9.2.5. Integracja z BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
9.2.6. Adaptacja nowszej wersji edytora JBoss GPD . . . . . . . . . . . . . . . . 127
9.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
V. Dodatki
Słownik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Kompilacja i instalacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
-
Wstęp
Modelowanie procesów biznesowych jest jednym z najważniejszych mechanizmów za-
rządzania przedsięwzięciami korporacyjnymi. Pozwala organizować procesy w myśl zasady
ich ciągłego usprawniania (ang. continous improvment). W dobie informatyzacji wszyst-
kich dziedzin życia, a zwłaszcza w zakresie organizacji pracy, najskuteczniejszym sposo-
bem modelowania jest tworzenie procesów poddających się automatyzacji. Taką metodą
opisu procesu biznesowego jest modelowanie za pomocą przepływów1. Istotą przepływu
prac jest automatyzacja procesu, który znajduje się pod kontrolą systemu informatycz-
nego, a nie człowieka. Działania człowieka ograniczają się do niezbędnego minimum, nie
jest on już nadzorcą procesu, a jedynie wykonawcą niektórych zadań (ang. task).
Z perspektywy informatycznej modelowanie procesów poprzez implementację przepły-
wów jest jednym z najciekawszych i najdynamiczniej rozwijających się podejść do two-
rzenia oprogramowania biznesowego. Współistnieje i uzupełnia się z takimi koncepcjami
jak: środowiska kontenerów aplikacji biznesowych, np. architektura JEE (Java Enterprise
Edition)2, architektura skierowana na usługi3, czy usługi sieciowe (ang. webservice). Pod-
stawową zaletą korzystania z procesów typu workflow jest programowanie na wyższym
poziomie abstrakcji (programowanie wysokopoziomowe), tworzenie modelu zrozumiałego
1 Przepływ prac (ang. workflow) to grafowy model procesu biznesowego przeznaczony do automa-tycznego wykonania. Dokładny opis w rozdziale 1.1.
2 W pracy przyjęto konwencję, że rozwinięcie skrótu lub angielskie tłumaczenie terminu znajduje sięw nawiasie bezpośrednio w tekście, przypisy zaś służą do zamieszczenia szerszego komentarza, objaśnienia.Dodatkowo zestawienie wszystkich skrótów znajduje się w dodatkach (część V).
3 Architektura skierowana na usługi (ang. Service Oriented Architecture - SOA) to sposób tworzeniasystemów luźno powiązanych bazujących na kompozycji usług.
6
-
Wstęp
nie tylko przez programistę i projektanta, ale i analityka biznesowego. Pozwala zachować
spójność modelu procesu z jego faktyczną implementacją oraz ustaleniami biznesowymi,
dostarczając większej kontroli nad zarządzaniem i ewolucją procesu.
Temat pracy magisterskiej wiąże się bezpośrednio z zagadnieniem modelowania pro-
cesów poprzez przepływy prac. Wymieniony w tytule język jPDL jest opartym na XML
językiem służącym do opisu procesów typu workflow, będącym składnikiem platformy
jBPM. JBPM jest jednym z kompleksowych środowisk do modelowania biznesowego dla
języka Java4. Wyboru platformy dokonano głównie ze względu na jej spójność, dużą spo-
łeczność osób zaangażowanych w projekt i dynamikę rozwoju. Dodatkowymi atutami jest
darmowa dystrybucja oprogramowania (ang. freeware) i otwartość kodu (oprogramowanie
typu open source). Tytułowy system dostępny przez przeglądarkę internetową (ang. web
application) to wielowarstwowa aplikacja udostępniająca swój interfejs użytkownika za
pomocą przeglądarki, realizująca komunikację warstwy klienckiej z serwerową za pomocą
protokołu HTTP. Jest to bardzo popularny w ostatnim czasie sposób realizacji rozproszo-
nych aplikacji typu klient - serwer. Zyskał popularność wśród twórców oprogramowania
ze względu na łatwość wdrożenia na komputerach klienta oraz wśród użytkowników ze
względu na prostotę interfejsu i powszechną znajomość środowiska przeglądarki interne-
towej.
Celem pracy jest stworzenie prototypu narzędzia do modelowania procesów bizneso-
wych zgodnych ze standardem jBPM, dostępnego poprzez interfejs uruchamiany w ramach
przeglądarki internetowej. Platforma jBPM udostępnia narzędzie wspierające tworzenie
procesów jBPM w środowisku Eclipse5. Zadaniem projektu magisterskiego jest przenie-
sienie interfejsu użytkownika, tak by nie był on ściśle związany z oprogramowaniem de-
dykowanym jedynie dla programisty oraz stworzenie modelu systemu rozproszonego i
wieloużytkownikowego. Zaletą takiej aplikacji jest umożliwienie wspólnej (niekonicznie
równoczesnej) pracy nad modelem procesu. Brak łatwego w dostępie (także dla anality-
ka i projektanta) interfejsu do modelowania był zdaniem autorów istotnym mankamen-
4 Platforma jBPM - platforma modelowania biznesowego autorstwa firmy JBoss. Składa się na niąbiblioteka umożliwiająca programowe definiowanie i wykonywania procesów, język modelowania bizne-sowego oraz narzędzia wspierające modelowanie - edytor procesu oraz środowisko wykonawcze (ang.execution environment). Więcej na temat jBPM w rozdziale 4.
5 Eclipse - popularne środowisko pracy programisty - IDE (ang. Integrated Development Environ-ment).
7
-
Wstęp
tem platformy jBPM. Potwierdzeniem tych spostrzeżeń jest stworzenie sieciowej aplikacji
JBoss jBPM Modeller (patrz 5.1.2) w najnowszych wersjach projektu jBPM, wydanych
już w trakcie realizacji projektu magisterskiego.
Dodatkowymi celami projektowymi jest pokazanie szerokich możliwości proponowa-
nego systemu, na przykładzie realizacji zadań: eksportu procesów do innych systemów,
integracji z usługami sieciowymi oraz kompozycji akcji procesu z gotowych komponentów
programowych.
Praca magisterska składa się z dwóch elementów - projektowego i opisowego. Element
projektowy to implementacja przedmiotowego systemu. Niniejsze opracowanie stanowi
składnik opisowy, podzielony na kilka części.
Część pierwsza to wstęp teoretyczny do tematyki modelowania biznesowego przy uży-
ciu metodologii grafowych, za pomocą przepływów prac. Zostały wprowadzone koniecz-
ne definicje i oznaczenia, przedstawiono koncepcję modelowania biznesowego, wskazano
podstawowe składniki procesu, omówiono podstawowe wzorce przepływu (ang. workflow
patterns). Na koniec pokrótce omówiono znaczenie modelowania biznesowego jako sposobu
tworzenia oprogramowania oraz wskazano główne kierunki rozwoju w tej dziedzinie.
W części drugiej przedstawiono tło technologiczne projektu magisterskiego. Omówiono
w niej obowiązujące standardy w dziedzinie modelowania biznesowego za pomocą przepły-
wów. Następnie opisano dokładnie platformę jBPM, język modelowania jPDL i omówiono
najważniejsze technologie i biblioteki programowe wykorzystane na etapie implementacji
projektu magisterskiego.
Kolejna sekcja opracowania merytorycznego składa się z projektu systemu i opisu
aspektów implementacji. Zdefiniowano zadanie projektowe wraz z wymaganiami, omó-
wiono otoczenie systemu w postaci przypadków użycia. Następnie przedstawiono projekt
architektury, model danych oraz specyfikację interfejsów. W fragmencie implementacyj-
nym przedstawiono najciekawsze aspekty realizacji wymagań funkcjonalnych w postaci
diagramów obiektowych i ich omówień.
W podsumowaniu (część czwarta) omówiona została realizacja przypadków użycia.
Wskazano mocne i słabsze punkty zaproponowanego rozwiązania, z naciskiem na stopień
realizacji celów funkcjonalnych i niefunkcjonalnych. Następnie przedstawiono ewolucję
systemu, czyli kierunki dalszego rozwoju.
8
-
Wstęp
Ostatnia część, prócz bibliografii zawiera słownik skrótów i samouczek pokazujący
krok po kroku podstawowe ścieżki użycia systemu (ang. HOWTO, Step by step guide).
Niniejsza praca została wykonana przez zespół dwuosobowy, w skład którego wchodzą
Janusz Bożek i Tomasz Juszczyk, pod kierunkiem dr inż. Dominika Radziszowskiego w
katedrze Informatyki Akademii Górniczo – Hutniczej w Krakowie.
W części teoretycznej większość prac została podzielona na niewielkie podzadania, któ-
re następnie zostały rozdzielone pomiędzy członków zespołu. Rozdziały miały opiekunów
merytorycznych, jednakże poszczególni członkowie zespołu pracowali nad fragmentami
każdego z rozdziałów.
Janusz Bożek opracował rozdziały: 4.2, 5, 7, 8, 9.
Tomasz Juszczyk jest autorem Wstępu oraz rozdziałów: 1, 2, 3, 4.1, 6.
W części praktycznej jeszcze trudniej przypisać realizację konkretnych modułów syste-
mu poszczególnym autorom. Praca miała charakter zadaniowy. W celu lepszego podziału
obowiązków, dla zapewnienia odpowiedniego poziomu granulacji, implementacja projektu
została podzielona na mniejsze zadania przypisywane konkretnemu programiście. Także
w przypadku implementacji obaj członkowie zespołu brali czynny udział w pracach nad
różnymi fragmentami systemu. Poszczególne moduły systemu miały jedynie swoich opie-
kunów, zajmujących się kontrolą realizacji zadań i ich jakości.
Janusz Bożek monitorował postępy prac nad aplikacją kliencką oraz modułami:
workflow-deployer, workflow-jpdl, workflow-wsdl, workflow-repository.
Tomasz Juszczyk kontrolował pracę nad modułami: workflow-web w warstwie logiki
prezentacji, workflow-core, workflow-model, workflow-model-designer, workflow-persistence
i workflow-domain.
Słowa kluczowe
proces biznesowy, przepływ, workflow, jBPM, jPDL, BPMN, JBoss
-
Część I
Wprowadzenie
-
Rozdział 1
Wprowadzenie do tematyki
modelowania procesów biznesowych
1.1 Ważniejsze pojęcia
W rozdziale zostaną omówione podstawowe pojęcia języka modelowania procesów biz-
nesowych wspólne dla różnych metodologii, począwszy od standardów grupy BPMI (ang.
Business Process Management Initiative), poprzez język BPEL (ang. Business Process
Execution Language, patrz rozdział 3), aż po dokładniej omawiane w pracy standardy
stworzone przez grupę JBoss Community - jBPM i jPDL.
Omówienie należy rozpocząć od dwóch podstawowych pojęć analizy biznesowej, które
będą się przewijać przez całą pracę, czyli pojęcia procesu biznesowego oraz przepły-
wu (ang. workflow). Dyskusja przeprowadzona w artykule [10] pokazuje, że znalezienie
właściwej definicji nie jest sprawą trywialną i w świecie specjalistów odbywa się wiele debat
11
-
1.1. WAŻNIEJSZE POJĘCIA
na ten temat. We wspomnianym artykule przytaczane są różne definicje procesu bizneso-
wego, kładące różny nacisk na pewne jego aspekty, jak produkt końcowy i dane wejściowe,
strukturę aktywności lub aktorów biorących w nim udział. Perspektywa programistyczna,
z jakiej pisana jest praca, sprawia, że punktem wyjścia będzie definicja przytaczana przez
Davenport’a, kładąca nacisk na strukturę poszczególnych aktywności i zadań tworzących
proces (1993, [16]):
Proces biznesowy jest zbiorem działań i zadań, mierzalnym i posiadającym określoną
strukturę, zaprojektowanym, by wytworzyć pewien produkt końcowy, spełniający wyma-
gania określonego użytkownika (beneficjenta) lub rynku (środowiska). Proces biznesowy
kładzie nacisk na to jak zadania są wykonywane wewnątrz organizacji, w przeciwień-
stwie do podejścia co, skupiającego się na produkcie finalnym. Proces biznesowy jest więc
specyficznym uporządkowaniem zadań w czasie i przestrzeni, z wyszczególnionym począt-
kiem i końcem i dobrze zdefiniowanym wejściem (dane początkowe, składniki początowe)
i wyjściem (produkt). Jest więc strukturą, zgodnie z którą organizacja wykonuje zadania,
niezbędne by wytworzyć produkt, będący wartością dla klienta.
Inne definicje procesu, można znaleźć w [28] (1993r.), [44] (1995r.), [33] (1993r.). Ham-
mer i Champy [28] przytaczają definicję bardziej minimalistyczną, nie kładącą nacisku na
strukturę procesu, Rummler i Brache klasyfikują procesy ze względu na ich rezultat, Jo-
hansson podaje podobną definicję do Davenporta, wskazując jednocześnie, że prawidłowy
proces powinien dostarczać pewną wartość dodaną.
Przepływ prac (przepływ, ang. workflow) wg definicji przytaczanej przez organizację
WorkFlow Management Coalition (WFMC, [31]) to:
Przepływem nazywamy skomputeryzowane, zautomatyzowane usprawnienie procesu biz-
nesowego lub jego części.
Także i w tym przypadku w źródłach można znaleźć wiele różnych prób definiowania
przepływu, jednak przytoczona definicja ze swoją prostotą i nastawieniem na automatyzm
procesu najlepiej oddaje istotę pojęcia. W dalszej części pracy w obszarze zainteresowań
12
-
1.1. WAŻNIEJSZE POJĘCIA
będą jedynie zautomatyzowane przez oprogramowanie informatyczne procesy biznesowe,
więc pisząc o procesie biznesowym faktycznie będzie mowa o przepływie prac.
W praktycznych rozwiązaniach spotyka się najczęściej dwa typy języków modelowania:
• o strukturze grafowej;
• o strukturze blokowej.
Praca jest zorientowana na na grafowe modele przepływu prac, gdyż właśnie taka
reprezentacja procesu jest najbardziej powszechna w procesie analizy i projektowania
procesów i dodatkowo umożliwia automatyczne przetwarzanie przy pomocy oprogramo-
wania komputerowego (matematyczne podstawy obliczeń daje rachunek π). Mówiąc o
automatyzacji procesów nie sposób nie odnieść się do modelów blokowych jako, że wiele
współczesnych języków wykonywania procesów należy właśnie do tej rodziny (np. BPEL).
Grafem przepływu nazywamy model przepływu posiadający strukturę grafu tj. z węzła-
mi reprezentującymi pewne zadania składające się na proces lub też zdarzenia w trakcie
jego trwania oraz krawędziami oznaczającymi przejścia stanowe od jednej aktywności do
drugiej.
Struktura blokowa języków modelowania stwarza pewne ograniczenia w stosunku do
modeli grafowych.
Język modelowania o blokowej strukturze opisuje przepływ sterowania za pomocą serii
zagnieżdżeń podstawowych elementów konstrukcyjnych, wśród nich elementów sterujących
jak pętle, alternatywy, elementy reprezentujące przetwarzanie współbieżne.
Składnie blokowe mają więc strukturę drzewa. Podstawowym ograniczeniem stąd wy-
nikającym w porównaniu do modeli grafowych jest brak reprezentacji dla dowolnych pętli
w przepływie (ang. arbitrary loops).
Wprowadzone zostanie także pojęcie instancji procesu, aby odróżnić strukturę procesu,
z licznymi rozgałęzieniami, reprezentującymi możliwe alternatywne wybory i schematy
postępowania od pojedynczego wykonania tego procesu, podążającego określoną ścieżką.
13
-
1.1. WAŻNIEJSZE POJĘCIA
Instancją procesu biznesowego lub instancją przepływu nazywamy pojedyncze wykona-
nie procesu zgodnie z grafem przepływu.
Z pojęciem instancji przepływu wiąże się także techniczny termin tokena przepływu
oraz ścieżki wykonania.
Ścieżką wykonania instancji procesu nazywamy ścieżkę w grafie przepływu (procesu)
wskazującą sekwencję zadań, zdarzeń, decyzji wykonanych w czasie trwania instancji pro-
cesu.
Zauważmy, że model procesu może zawierać liczne rozgałęzienia, wówczas możliwe są
różne ścieżki wykonania. Dodatkowo zakłada się, że w czasie trwania instancji procesu,
jednocześnie (równolegle) mogą być przetwarzane różne ścieżki.
Tokenem będziemy nazywali wskaźnik wyznaczający aktualny stan wykonania instacji
procesu, tzn. pozycje w grafie przepływu dla danej ścieżki wykonania.
Ponieważ dopuszcza się równoległe przetwarzanie różnych ścieżek, podczas pojedyn-
czej instancji przepływu może istnieć więcej niż jeden token przyporządkowany do danej
instancji. Każdy z tokenów jest związany z pewną ścieżką wykonania procesu. Pojedyn-
cza instancja może posiadać kilka równoległych ścieżek powstałych na skutek rozgałęzień
(ang. fork). Stan procesu oczywiście nie jest równoznaczny z tokenem. Token wskazuje
jedynie, który węzeł grafu przepływu jest aktualnie przetwarzany w obrębie danej ścieżki
przetwarzania.
Umieszczone w tytule pracy pojęcie modelowanie procesów biznesowych (ang.
business process modelling) oznacza proces tworzenia modelu procesu biznesowego,
najczęściej w postaci grafu przejść, łączącego poszczególne aktywności i zadania. W infor-
matyce dąży się do wykorzystywania bardziej formalnych modeli, które mogą następnie
być wykorzystane przez oprogramowanie do realizacji zarządzania danym procesem. Wią-
że się to z wprowadzeniem pewnego formalnego języka modelowania, najczęściej mającego
także graficzną reprezentację w postaci diagramów, ułatwiającego reprezentację struktury
procesu. Pewne przykłady języków modelowania biznesowego zostaną pokrótce opisane w
14
-
1.2. SKŁADNIKI PROCESU BIZNESOWEGO
rozdziałach 3 oraz 4.2. Jednym z ważniejszych celów modelowania biznesowego jest jasne
określenie interakcji między człowiekiem, a maszyną, wyznaczenie granic automatyzacji.
Zarządzanie procesami biznesowymi (BPM - Business Process Manage-
ment) to ogół czynności, strategii podejmowanych przez organizację w celu stałej popra-
wy efektywności realizacji określonych celów biznesowych. Proces ten obejmuje zarówno
zarządzanie zasobami ludzkimi (zespołami), jak i czasem, budżetem i sprzętem. Metodo-
logia BPM zakłada pewien cykl czynności składający się z pięciu podstawowych faz:
• projekt (ang. design) - rozpoznanie obecnej postaci procesu (ang. “as is” process)
oraz docelowej jego postaci (ang. “to be” process), jego aktorów, kalkulacja zagrożeń,
kosztów, podstawowych interakcji;
• modelowanie (ang. modelling) - stworzenie modelu procesu biznesowego, w przypadku
procesów wspieranych komputerowo, na tym etapie powstaje opis w postaci przepływu
zadań;
• wykonanie (ang. execution) - proces zostaje wdrożony w środowisku produkcyjnym;
• monitorowanie (ang. monitoring) - wdrożenie nie zamyka cyklu, na tym etapie badana
jest wydajność procesu, szacowanie korzyści z jego wprowadzenia oraz identyfikacja
słabych stron i możliwych udoskonaleń;
• optymalizacja (ang. optimisation) - wprowadzanie udoskonaleń do procesu powodują-
cych wzrost wydajności.
1.2 Składniki procesu biznesowego
Definiując proces wspomniano, że stanowi on strukturalną całość złożoną z mniejszych
fragmentów - zadań i aktywności. Także w definicji grafu przepływu zostały użyte pojęcia
zadania, zdarzenia oraz krawędzi - przejścia między stanami procesu. W dalszej części
rozdziału omówimy podstawowe składniki każdego modelu procesu biznesowego, wspólne
niezależnie od przyjętego języka modelowania. Składniki te są następnie wykorzystywa-
ne jako budulec przepływu zgodnie z określonymi wzorcami architektonicznymi (ang.
workflow patterns). Wzorce te (niezależne od implementacji), stały się podstawą definicji
składni języków modelowania.
15
-
1.2. SKŁADNIKI PROCESU BIZNESOWEGO
Przy omawianiu podstawowych składników przepływu posłużono się notacją języ-
ka BPMN (Bussiens Process Modelling Notation), stworzonego przez konsorcjum OMG
(Object Management Group) jako, że jest on najbardziej rozpowszechnionym standar-
dem. Podstawowy katalog składników przepływu powstał w oparciu o pozycje bibliotecz-
ne: [52], [54], [35].
Składniki procesu biznesowego można podzielić na cztery podstawowe grupy:
• obiekty sterujące przepływem (flow objects);
• połączenia (connectors);
• elementy grupujące (swimlanes);
• artefakty.
1.2.1 Obiekty sterujące przepływem
Obiekty te stanowią jądro modelów biznesowych, ponieważ z ich pomocą modeluje się
logikę przepływu. Można je podzielić na zdarzenia, czynności i bramki, pełniące w modelu
odrębne funkcje. W modelach grafowych stanowią węzły grafu przepływu.
Zdarzenia (Events)
Rysunek 1.1: Typyzdarzeń
Przez zdarzenia rozumiemy sytuacje, które mają miej-
sce podczas trwania procesu, mające wpływ na jego dalszy
przebieg. Zazwyczaj są wywoływane przez jakiś fakt (wyzwa-
lacz, ang. trigger) lub powodują powstanie jakiegoś rezultatu.
Wśród zdarzeń możemy wyróżnić dwa specjalne typy, wystę-
pujące w każdym modelu procesu biznesowego:
• zdarzenie początkowe - oznaczające początek przepływu,
w którym określa się warunki początkowe dla procesu;
• zdarzenie końcowe - oznacza koniec przetwarzania, określa
stan końcowy procesu;
Rysunek 1.1 przedstawia podstawowe typy zdarzeń w notacji BPMN.
16
-
1.2. SKŁADNIKI PROCESU BIZNESOWEGO
Czynności (Activities)
Czynności są najważniejszymi elementami procesu, gdyż modelują pracę do wykona-
nia. Czynności można podzielić ze względu na atomowość operacji na zadania (ang.
tasks) i podprocesy.
Rysunek 1.2: Ty-py czynności
Zadania są atomowa czynnością tzn. nie dają się podzielić na
mniejsze składniki w modelu procesu.
Podproces jest procesem, będącym częścią składową większe-
go procesu. Użycie tego składnika poprawia przejrzystość, umoż-
liwia powtórne wykorzystanie składników procesu (ang. reusabi-
lity), wpływa na skalowalność.
Zadanie cykliczne jest typem zadania, które jest wykony-
wane iteracyjnie. W procesach biznesowych pętle zdarzeń są opi-
sywane z wykorzystaniem bramek, jednakże pojedyncze zadanie
cykliczne można oznaczyć specjalnym symbolem.
Bramki (Gates)
Rysunek 1.3: Typy bramek
Bramki są elementami sterującymi przepływem. Słu-
żą do oznaczania miejsc w systemie, w których w za-
leżności od warunków następuje podjęcie jakiejś decyzji,
służą do rozgałęziania lub łączenia ścieżek przepływu.
Bramki służą także do oznaczenia miejsc synchronizacji
rozgałęzionych ścieżek wykonania.
Język BPMN, którego składnia jest punktem odnie-
sienia w tym rozdziale, wyróżnia kilka podstawowych ty-
pów bramek (Rys. 1.3):
• rozłączna (ang. exclusive, XOR gateway) - zwana
także decyzją, służy do oznaczania rozgałęzień w
grafie przepływu, czyli alternatywnych ścieżek wyko-
nania, przy czym decyzja, która ścieżka zostaje wy-
17
-
1.2. SKŁADNIKI PROCESU BIZNESOWEGO
brana następuje na podstawie spełnienia warunku (ang. data based decision) lub zda-
rzenia (ang. event based decision). W czasie wykonywania instancji procesu, przy
opuszczaniu bramki decyzji, jedynie jedna ścieżka może zostać wybrana.
• łączna (ang. inclusive, OR gateway) - opisuje podobne zachowanie jak bramka decyzji,
z tą różnicą, że opuszczając ją instancja może podążać więcej niż jedną ścieżką wyko-
nania, gdy będzie spełniona większa liczba warunków. Najczęściej ścieżki te są łączone
także przez bramkę łączną, służącą do zbierania wyników z poszczególnych ścieżek.
• złożona (ang. complex) - w składni BPMN jest rodzajem decyzji podejmowaną na
podstawie bardziej złożonego procesu niż warunek, czy zdarzenie.
• równoległa (ang. parallel) - służy do rozdzielania ścieżki wykonania na ścieżki rów-
noległe. Każda z nich jest tak samo uprzywilejowana. Powstaje wiele tokenów które
sygnalizują wiele pozycji w grafie przepływu. Najczęściej ścieżki te są łączone bramką
synchronizacyjną, którą instancja procesu może opuścić dopiero po zebraniu tokenów
z wszystkich równoległych ścieżek.
1.2.2 Połączenia
Rysunek 1.4: Typy połą-czeń
Połączenia to krawędzie w grafie przepływu. Ich
głównym zadaniem jest wprowadzenie porządku w zbio-
rze czynności, ustalenie kolejności zdarzeń. Dodatkowo
służą do modelowania przesyłu informacji między ele-
mentami procesu oraz powiązania węzłów procesu z da-
nymi (produkty procesu, dane wejściowe) oraz innymi
artefaktami. Możemy rozróżnić następujące rodzaje po-
łączeń (Rys. 1.4) :
• przepływ sterowania - przy pomocy tego rodzaju
krawędzi oznacza się następstwo składników proce-
su (zdarzeń, czynności, bramek), nie mogą zaś łączyć
składników różnych podprocesów oraz ról procesowych. Połączenia tego typu mogą
być wzbogacane o wyrażenia warunkowe, określające, pod jakim warunkiem przejście
18
-
1.2. SKŁADNIKI PROCESU BIZNESOWEGO
wzdłuż danego połączenia może mieć miejsce. Istnieje także specjalne oznaczenie na
domyślne przejście, które zachodzi gdy żadne inne połączenie warunkowe z danego
elementu procesu nie może mieć miejsca.
• przepływ wiadomości - ma miejsce między dwoma uczestnikami procesu i tylko między
nimi, przy czym może łączyć zarówno uczestników jako takich lub elementy proce-
su w obrębie danego uczestnika. Przepływ wiadomości nie służy więc do oznaczania
komunikacji w obrębie jednego procesu, a do modelowania interakcji z kontekstem
zewnętrznym procesu.
• asocjacja - jest połączeniem między obiektami sterującymi przepływu, a obiektami
dodatkowymi - artefaktami. Ich głównym zadaniem jest dostarczanie dodatkowej in-
formacji na etapie modelowania oraz pokazywanie przepływu danych w czasie trwania
procesu.
1.2.3 Elementy grupujące
Elementy grupujące nie są składnikiem funkcjonalnym, mającym fundamentalne zna-
czenie dla opisu sterowania, są elementem porządkującym opis, poprawiającym jego czy-
telność. Służą do wyszczególnienia ról procesowych, uczestników procesu oraz do mode-
lowania interakcji z kontekstem zewnętrznym w procesach typu B2B (ang. business to
business). Zgodnie ze standardem BPMN możemy rozróżnić dwa typy elementów grupu-
jących:
Rysunek 1.5: Elementy grupujące
• pule (ang. pools) - to uczestnicy procesu, lub organizacje biorące udział w interaktyw-
nym procesie typu B2B. Służą do wyznaczania kontekstu zewnętrznego dla procesu,
19
-
1.2. SKŁADNIKI PROCESU BIZNESOWEGO
by umożliwić modelowanie wzajemnej komunikacji międzyprocesowej. Pule mogą być
typu “czarna skrzynka” - nie zawierając w sobie żadnego elementu procesu lub też
otwarte - wówczas enkapsulują pełny proces. Przepływ sterowania procesu nie może
przekraczać granicy puli.
• tory (lanes) - służą najczęściej do wydzielenia w obrębie pojedynczego procesu po-
szczególnych ról procesowych. Specyfikacja ni e precyzuje ściśle, że muszą być to role
procesowe. Podział na tory może dotyczyć dowolnego logicznego podziału elementów
procesu na grupy. Między torami nie może następować wymiana komunikatów, która
jest zarezerwowana dla interakcji międzyprocesowych.
1.2.4 Artefakty
Rysunek 1.6: Artefakty
Artefakty są dodatkowymi elementami języków mo-
delowania procesów, pełniąc funkcję uzupełniającą. Słu-
żą dwóm podstawowym celom:
— dostarczają dodatkowych informacji o procesie, nie
mających wpływu na przepływ sterowania, ale uła-
twiających czytanie i zrozumienie modelu procesu,
— pokazują przepływ danych w obrębie procesu.
Język BPMN rozróżnia trzy podstawowe rodzaje ar-
tefatów:
• adnotacja tekstowa - jest elementem opisowym, po-
łączonym z elementem procesu za pomocą asocjacji.
Dostarcza dodatkowej informacji o elemencie, tłuma-
cząc jego znaczenie, wskazując ważne cechy. Nie jest istotna z punktu widzenia automa-
tycznego przetwarzania (nie mając bezpośredniego wpływy na przebieg sterowania),
może być ważna dla osoby implementuj ącej proces, zawierając wskazówki dotyczące
zachowania danego elementu.
20
-
1.3. WZORCE PRZEPŁYWU
• obiekt danych - służy do pokazania sposobu użycia dokumentów i danych w obrę-
bie procesu, pokazuje dane wejściowe i produkty czynności procesowych, może być
opatrzony informacją o stanie, pokazującą jak proces zmienił dane.
• grupa - jest elementem porządkującym pozwalającym wydzielić pewne elementy pro-
cesu, które są ze sobą w jakimś aspekcie związane. Grupowanie nie jest ogranniczone
przez tory ani pule.
1.3 Wzorce przepływu
Rozdział został ograniczony do przedstawienia kilku podstawowych wzorców przepły-
wu. Dokładny katalog wzorców można znaleźć na stronach grupy Workflow Patterns [40],
której prace merytoryczna skupiona jest w dwóch ośrodkach: Eindhoven University of
Technology (prowadzonego przez profesora van der Aalsta) i Queensland University of
Technology (prowadzonego przez prof. der Hofstede) oraz w licznych publikacjach (np. [39]
i [53]).
1.3.1 Sekwencja (ang. sequence)
Sekwencja jest podstawową formą przepływu sterowania wewnątrz procesu. Oznacza
wykonywanie zadań jedno po drugim.
Rysunek 1.7: Sekwencja (składnia BPMN)
1.3.2 Podział równoległy (ang. parallel split)
Podział równoległy oznacza rozdzielenie gałęzi przepływu na dwie lub więcej gałęzi, z
których każda jest wykonywana równolegle. Podział niekoniecznie musi oznaczać koniecz-
21
-
1.3. WZORCE PRZEPŁYWU
ność późniejszej synchronizacji, każda z gałęzi może osiągać stan końcowy niezależnie.
Rysunek 1.8: Podział równoległy (składnia BPMN)
1.3.3 Synchronizacja (ang. synchronisation)
Synchronizacja jest wzorcem modelującym połączenie dwóch lub więcej ścieżek prze-
twarzania w jedną wspólną. Przejście z bramki synchronizacyjnej do następującej po niej
czynności odbywa się gdy każdy z tokenów poruszjących się po łączonych ścieżkach prze-
twarzania osiągnie bramkę.
Rysunek 1.9: Synchronizacja (składnia BPMN)
1.3.4 Decyzja (ang. exclusive choice)
Decyzja rozdziela ścieżkę przetwarzania na kilka alternatywnych ścieżek. Ścieżki te
są jednak rozłączne w tym sensie, że w trakcie trwania pojedynczej instancji procesu
22
-
1.3. WZORCE PRZEPŁYWU
jedynie jedna ze ścieżek może zostać wybrana. W bramce rozdzielającej sprawdzany jest
warunek, na podstawie, którego podejmowana jest decyzja o przekazaniu starowania do
jednej z gałęzi.
Rysunek 1.10: Decyzja (składnia BPMN)
1.3.5 Proste złączenie (ang. simple merge)
Proste złączenie jest inną wersją łączenia kilku ścieżek przetwarzania. W przeciwień-
stwie do omawianego wcześniej wzorca “Synchronizacja”, nie powoduje synchronizacji
kilku wykonujących się współbieżnie ścieżek przetwarzania lecz zakłada, że token prze-
mieszcza się jedynie wzdłuż jednej ze ścieżek. Oznacza to, że po osiągnięciu bramki pro-
stego złączenia token natychmiast przekazywany jest do następującej po niej aktywności.
Rysunek 1.11: Proste złączenie (składnia BPMN)
Katalog wzorców przepływu jest znacznie obszerniejszy niż przedstawione powyżej
zestawienie. Bibliografia zawiera odnośniki do źródeł opisujących go dokładnie.
Podział taksonomiczny katalogu wyróżnia podstawowe klasy wzorców przepływu:
23
-
• sterujące (ang. control patterns, patrz [39] i [55]);
• danych (ang. data patterns, patrz [36]);
• dotyczące zasobów (ang. resource workflow patterns, patrz [37]);
• obsługi błędów (ang. exception handling patterns, patrz [38]).
W rozdziale powyżej przedstawiono jedynie grupę wzorców określaną przez inicjatywę
Workflow Patterns mianem podstawowych wzorców sterujących (ang. basic control pat-
terns). Pozwalają one jednak na konstrukcję nietrywialnych przepływów i modelowanie
skomplikowanych scenariuszy biznesowych, dlatego na potrzeby pracy ich omówienie jest
wystarczające (opis wyrafinowanych wzorców przepływu nie wnosiłby żadnej dodatkowej
wiedzy z punktu widzenia celów pracy).
-
Rozdział 2
Modelowanie przepływu w
informatyce
2.1 Znaczenie przepływu
Optymalizacja procesów w przedsiębiorstwach polega współcześnie przede wszystkim
na coraz rozleglejszej automatyzacji i informatyzacji. Doprowadziła do powstania syste-
mów zarządzania procesami biznesowymi - BPMS (ang. Business Process Mana-
gement Systems), które udostępniają użytkownikom narzędzia do realizacji trzech pod-
stawowych zadań:
• modelowanie procesów (ang. process modelling);
• wykonywanie procesów (ang. process execution);
• monitorowanie procesów (ang. process monitoring).
25
-
2.1. ZNACZENIE PRZEPŁYWU
Wykorzystywanie przez firmę technologii i platform realizujących procesy zgodnie z kon-
cepcją workflow niesie z sobą wiele korzyści. Realizacja projektów biznesowych jest pod-
dana silnym ograniczeniom czasowym i finansowym. Niezwykle ważne jest, by zmieścić
się z wdrożeniem produktu w ścisłych ramach czasowych i pozostawać w zgodzie
z budżetem. Podstawą jest ukierunkowanie na klienta, co oznacza, że aby zapew-
nić sukces komercyjny produkt musi zostać dobrze przyjęty przez klienta (satysfakcja
klienta). Celem strategicznym modelowania biznesowego oraz automatyzacji procesów w
postaci przepływów jest realizacja wyżej wymienionych wymagań i wypracowanie jak naj-
większego zysku. Organizacja, aby zrealizować cel strategiczny musi działać sprawniej
i efektywniej, posiadać zautomatyzowane procedury, zespoły na różnych etapach
produkcji powinny współpracować i komunikować się ze sobą z wzajemnym zro-
zumieniem. Do tego celu idealnie nadaje się graficzny język modelowania - przejrzysty i
zrozumiały dla analityka, bliski perspektywie klienta, pozwalający nie tracić z oczu celów
biznesowych. Jedną z najważniejszych zalet jest zbliżenie perspektyw analityka i
dewelopera.
Przepływ łatwo poddaje się automatyzacji, wpływając w stopniu decydującym na
poprawę efektywności. Modelowanie procesów biznesowych z wykorzystaniem przepływów
jest współczesną propozycją rozwiązania problemu: „Jak sprawnie zarządzać przedsięwzię-
ciami biznesowymi”. Technologie oparte na przepływach zyskują na znaczeniu głównie ze
względu na ścisłość opisu, dającą się łatwo przełożyć na język programowania. Współ-
czesne języki modelowania pozwalają na podstawie opisu analityka biznesowego (model
procesu) automatycznie tworzyć zrąb programistyczny - komputerową reprezentację pro-
cesu. Programistom pozostaje implementacja dobrze wyodrębnionych fragmentów funk-
cjonalnych (zadań w nomenklaturze języków modelowania biznesowego), najczęściej w
postaci uniwersalnych serwisów. Tworzenie uniwersalnych serwisów umożliwia ich wielo-
krotne wykorzystanie (ang. reusability), co dodatkowo pozwala na oszczędność czasu.
Program komputerowy umieszczony w odpowiednim środowisku zarządzania proce-
sami sprawnie nadzoruje jego przebieg. Środowiska realizujące przepływ prac potrafią
efektywnie zarządzać i łączyć zarówno zadania realizowane przez automaty (programy
komputerowe oraz sterowane komputerowo maszyny), jak i nie dające się zautomatyzo-
26
-
2.1. ZNACZENIE PRZEPŁYWU
wać zadania dla człowieka, poprzez mechanizmy synchronizacji i blokad oraz utrwalania
stanu i danych oraz dbanie o integralność danych.
jak również monitorowanie stanu systemu i
Systemy BPMS monitorują przebiegi procesów skutecznie znajdując ich wąskie gardła
i wspomagając tworzenie kolejnych usprawnień. Umożliwiają realizację hurtowni danych
(ang. data warehouse) i ich późniejszą analizę (ang. data mining). Stały monitoring po-
zwala na szybkie reagowanie na zmieniające się warunki zewnętrzne (kontekst systemu) i
wystąpienie sytuacji awaryjnych.
Modelowanie biznesowe z wykorzystaniem technologii przepływu wnosi wiele nowego
także z perspektywy programistycznej. Modele programowania przeszły głęboką ewolucję
od czasów języków niskopoziomowych, strukturalnych, poprzez paradygmat obiektowy,
po programowanie komponentowe. Systemy korporacyjne są systemami rozproszonymi,
tworzonymi w architekturze wielowarstwowej. Nastawienie na realizację kontraktu i czas
jego realizacji kieruje uwagę ku wysokopoziomowym językom, programowaniu komponen-
towemu i serwisowemu. SOA(ang. Service Oriented Architecture, architektura serwisowa)
ułatwia tworzenie systemów skalowalnych, rozszerzalnych złożonych z luźno powiązanych
(ang. loose coupling) usług, realizujących ściśle określone kontrakty. Głównym zadaniem
programistów staje się realizacja kontraktów biznesowych poprzez kompozycję usług reali-
zujących określone, wąskie zadania w celu realizacji złożonego procesu, oraz implementacja
poszczególnych usług o jasno sprecyzowanych interfejsach.
Technologie przepływowe idealnie wpasowują się w powyższy schemat. Służą lepsze-
mu zrozumieniu celów biznesowych i orkiestracji (ang. orchestration) pełnego procesu z
mniejszych składników. Modelowanie biznesowe nie narzuca usług sieciowych (ang. web
service) jako koniecznego składnika procesu. Czynności procesu (patrz definicje składni-
ków procesu 1.2) mogą być implementowane dowolnie, jednakże BPM jest też dobrym
mechanizmem orkiestracji w ramach realizacji architektury SOA.
Programowanie wysokopoziomowe wpływa na jakość tworzonego kodu, stabilność roz-
wiązań, umożliwiając wielokrotne wykorzystanie dobrze przetestowanych komponentów.
Zapewnia generyczną obsługę standardowych usług, jak bezpieczeństwo, transakcyjność,
przesyłanie wiadomości (ang. messaging), obługę sytuacji niewłaściwych (ang. exception
handling), itp.
27
-
2.2. AKTUALNE KIERUNKI ROZWOJU
2.2 Aktualne kierunki rozwoju
Modelowanie procesów biznesowych przy pomocy przepływów jest bardzo intensywnie
rozwijającą się dziedziną projektowania systemów biznesowych. Istnieje wiele środowisk
naukowych i biznesowych zaangażowanych w tworzenie języków i platform modelowania
biznesowego. Świadczą o tym chociażby wymienione w rozdziałach 3, 4 i 5 organizacje i
firmy zaangażowane w rozwój języków opisu procesów biznesowych.
Jednym z większych problemów omawianej dziedziny programowania jest brak glo-
balnych standardów, nadmiar rozwiązań pretendujących do miana standardu lub brak
kompatybilności pomiędzy powszechnie uznanymi technologiami (np. BPMN i BPEL).
Dlatego też najważniejszym celem przed jakim stoi środowisko BPM jest pogłębianie
standaryzacji i praca na rzecz kompatybilności itniejących rozwiązań.
Świat aplikacji biznesowych pełen jest kodu zastanego (ang. legacy code), który był
tworzony z wykorzystaniem starszych technologii oraz niechęci do jego zmiany. Zmiana
funkcjonującego mechanizmu wiąże się zawsze z ryzykiem, nowy mechanizm potrzebuje
czasu i testów, by osiągnąć stabilność i niezawodność poprzedniego. Dlatego też kolejnym
ważnym celem jest tworzenie pomostów między istniejącymi językami modelowa-
nia. Platformy do modelowania powinny operować na przystępnej graficznej notacji i na
jej podstawie umożliwiać generację opisu w różnych językach. Powinny być wyposażone
w konwertery importujące model procesu zapisany w różnych notacjach. Automatyczna
konwersja między różnymi notacjami jest jednym z największych wyzwań. Problemem
jest m.in. konwersja między modelami grafowymi a blokowymi oraz obsługa niekompaty-
bilności notacji (różnic zakresów funkcjonalnych).
Najdynamiczniej rozwijającą się gałęzią modelowania biznesowego jest wykorzystanie
modeli do automatyzacji procesu. Dlatego też ważne jest, by narzędzia analityka i pro-
jektanta tworzyły opis modelu, na podstawie którego automatycznie generowane są zręby
programowe, takie jak choćby szablon procesu w języku BPEL. Pożądaną tendencją jest
dalsza integracja pracy projektanta, analityka i programisty. Konsekwencją jest
dostarczenie zrozumiałej dla nieposiadającego technicznej wiedzy analityka przystępnej,
graficznej reprezentacji modelu. Udostępnienie wieloużytkownikowej platformy umożliwia-
jącej wspólną pracę i wymianę spostrzeżeń przez przedstawicieli wszystkich wymienionych
28
-
wyżej grup jest także jednym z wyzwań na najbliższy czas. Platforma taka powinna speł-
niać kilka podstawowych wymagań, m.in. umożliwiać synchronizację pracy, interakcyj-
ność, działanie w środowisku rozproszonym, integrację z istniejącymi narzędziami pracy
programisty i projektanta.
Przy projektowaniu systemów biznesowych w ostatnich latach największą popularność
zdobywają technologie wspierające tworzenie architektury skierowanej na usługi (SOA),
chmury obliczeniowe (ang. cloud computing), ESB (ang. Enterprise Service Bus), czy kon-
tenery aplikacji biznesowych (np. platforma JEE). Korporacje coraz powszechniej wprowa-
dzają modelowanie wewnętrznych procesów, jako ważny element poprawy funkcjonowania.
W kolejnych latach następować powinna dalsza integracja modelowania biznesowego
z architekturą usługową przede wszystkim zaś usługami sieciowymi (ang. web servi-
ces). Przykładem takiego działania są próby tworzenia automatów tłumaczących procesy
BPMN na język BPEL, służący do orkiestracji usług sieciowych.
Ogólnym kierunkiem rozwoju oprogramowania dla biznesu jest łączenie i współpraca
różnych technologii. Technologie modelowania przepływów powinny współpracować z kon-
tenerami aplikacyjnymi (np. rozwiązania proponowane przez twórców platformy JBoss),
usługami sieciowymi, chmurami obliczeniowymi, magistralami usług (ESB), hurtowniami
danych, oraz systemami eksploracji danych (ang. data mining systems).
-
Część II
Tło technologiczne
-
Rozdział 3
Obowiązujące standardy
Jednym ze wskaźników dużego zainteresowania branży językami modelowania bizne-
sowego i platformami wykonawczymi dla przepływów (ang. workflow frameworks) jest
ogromna liczba konkurencyjnych rozwiązań istniejących na rynku. Ta różnorodność jest
też pewną słabością, polegającą na braku standardu, który byłby zrozumiały przez wszyst-
kie zainteresowane strony (analityków biznesowych, projektantów, deweloperów, przedsta-
wicieli klienta).
Brak standardowego interfejsu programistycznego jest jeszcze dotkliwszy w świecie
zautomatyzowanych procesów - przepływów. Utrudnia to tworzenie dużych systemów,
komunikację między procesami, zestawianie złożonych procesów z mniejszych, jak również
utrzymanie dużych systemów, także z powodu trudności w przewidzeniu, które technologie
przepływów staną się dominujące w przyszłości. Utrudniona jest także komunikacja mię-
dzy zespołami programistycznymi i wewnątrz zespołu, co jest konsekwencją posługiwania
się różnymi językami.
31
-
3.1. UML
Mimo tych utrudnień istnieje pewna liczba popularnych standardów, języków modelo-
wania, platform przepływowych znana szerokiemu gronu osób. Rozwiązania te pretendują
do miana standardów lub kompleksowością rozwiązań starają się przyciągnąć użytkowni-
ków.
Spośród wszystkich składni opisu procesów najbardziej rozpowszechnioną i będącą
de facto wyznacznikiem dla innych, jest BPMN pod patronatem grupy OMG, znanej w
świecie IT z takich standardów jak CORBA czy UML.
W rozdziale przedstawiono kilka najbardziej znanych języków modelowania biznesowe-
go, ze zwróceniem uwagi na technologie i platformy pozwalające automatyzować procesy
opisane przy pomocy danej notacji.
3.1 UML
W języku UML w wersji 2.0 do modelowania procesów biznesowych służą diagramy
aktywności. Rysunek 3.1 przedstawia pięć podstawowych wzorców przepływu sterowania
zamodelowanych przy użyciu diagramów aktywności UML. Możemy zaobserwować, że
styl modelowania jest podobny do standardowej notacji BPMN. Pozycja [53] stanowi
doskonałe kompendium porównawcze tych notacji. Diagramy aktywności UML stanowią
w pełni funkcjonalny język modelowania biznesowego, pozwalający przedstawić wszystkie
aspekty procesów omawiane w tym rozdziale, jak również tworzyć złożone modele wg
wzorców proponowanych przez grupę Workflow Patterns.
Przydatny w modelowaniu biznesowym przy użyciu UML jest mechanizm profilów,
który stał się częścią języka w wersji 2.2. Pozwala on tworzyć spójne rozszerzenia ję-
zyka UML wprowadzające szereg artefaktów i stereotypów definiujących standardowe
elementy języka modelowania biznesowego (jak akcje, zdarzenia, decyzje, dane wejścio-
we, itp.). Przykładem takiego podejścia jest omówiony w książce [29] profil biznesowy
Erikssona-Penkera (ang. Eriksson-Penker Business Modeling Profile).
Słabością UML-a jest jego nieznajomość w środowiskach analityków biznesowych. Ję-
zyk modelowania najpopularniejszy wśród programistów jest w świecie specjalistów dzie-
dzinowych niemal nieznany. A jednym z głównych założeń nowoczesnych języków mode-
lowania biznesowego jest zbliżenie tych środowisk.
32
-
3.1. UML
Rysunek 3.1: podstawowe wzorce sterowania (składnia UML)
Drugim mankamentem, był do niedawna brak narzędzi służących do automatyzacji
procesów opisanych przy pomocy UML-a. Sytuacja na rynku zmienia się w trakcie pisa-
nia pracy dynamicznie, pojawiają się narzędzia komercyjne oferujące translacje modelów
UML (najczęściej w wersji 2.3, bazujących na specyficznych profilach BPM dla UML) do
języka wykonawczego (ang. execution language) takich jak np. BPEL. Nie są to jednak
rozwiązania powszechne, brak jest bezpłatnych i otwartych narzędzi tego typu.
Powyższe niedogodności powodują, że UML przydaje się przede wszystkim jako narzę-
dzie pracy projektanta (takie jest główne przeznaczenie UML-a), a nie język komunikacji
między projektantem, analitykiem i programistą.
Zaletą UML-a przy projektowaniu systemów implementujących procesy biznesowe jest
jego kompletność, pozwalająca modelować różne perspektywy procesu, nie tylko przepływ
sterowania.
Przykładem wykorzystania UML 2.3 do modelowania biznesowego jest komercyjna
platforma Enterprise Architect (patrz 5.1.5).
33
-
3.2. BPMN
3.2 BPMN
BPMN - Business Process Modeling Notation - graficzny, grafowy, język modelowa-
nia biznesowego stworzony przez grupę OMG. Jest to najbardziej upowszechniony język
modelowania, stanowiący najczęściej punkt odniesienia dla innych notacji. Podrozdziały
1.2 i 1.3 przedstawiały podstawy modelowania biznesowego na podstawie składni języka
BPMN. Pozycja [27] to zestawienie podstawowych składników języka BPMN, pokazujące
jego złożoność i możliwości.
Z formalnego punktu widzenia BPMN jest przykładem języka realizującego formalizm
matyczny zwany rachunkiem π. Rachunek π jest przykładem rachunku procesowego (ang.
process calculi), które służą do formalnego opisu przetwarzania procesowego, z uwzględ-
nieniem formalnych definicji współbieżności, sekwencyjności zdarzeń, komunikacji mię-
dzyprocesowej, synchronizacji. Oznacza to, że każdy proces opisany formalnie za pomocą
rachunku π może być modelowany w notacji BPMN i na odwrót.
Język BPMN jest językiem graficznym ułatwiającym modelowanie. Jest zatem najlep-
szym narzędziem dla analityka biznesowego i projektanta aby stworzyć strukturalną re-
prezentację procesu. Notacja taka nie nadaje się jednak do automatycznego przetwarzania
przez oprogramowanie. Ważnym aspektem technologicznym współczesnego modelowania
biznesowego przy użyciu przepływów jest stworzenie tekstowego lub binarnego odpowied-
nika składni BPMN oraz narzędzi tłumaczących (translatorów) opisy procesu z repre-
zentacji graficznej na maszynową. Najlepszym wyborem wydają się składnie XML-owe,
gdyż ich postać jest zarówno zrozumiała przez człowieka, jak i łatwo przetwarzana przez
oprogramowanie.
Istnieje wiele technologii informatycznych próbujących realizować ten cel (w większym
lub mniejszym zakresie), mianowicie umożliwiać tworzenie definicji procesu w graficznej
notacji BPMN, która wewnętrznie jest reprezentowana w języku nadającym się do auto-
matycznego przetwarzania.
Obecnie na rynku istnieje szereg tekstowych języków modelowania biznesowego (np.
BPEL, XPDL, jPDL), które dają możliwość bezpośredniej reprezentacji coraz szerszej
grupy składników notacji BPMN. Procesy tak opisane posiadają więc graficzną reprezen-
tację zrozumiałą w gronie analityków i mogą być poddane automatyzacji w platformach
34
-
3.3. XPDL
przepływowych. Wiele narzędzi do modelowania za pomocą przepływów stosuje właśnie
taką strategię.
Grupa OMG przedstawia w [51] przykład translacji modelu procesu w notacji BPMN
na opis w języku BPEL. Projekt bpmn2bpel jest próbą implementacji takiej strategii. W
rozdziale 4 przedstawiono dokładniej wykorzystaną w projekcie magisterskim technologię
jBPM, która wykonuje translację BPMN - jpdl.
3.3 XPDL
XPDL - XML Process Definition Language jest językiem standaryzowanym przez
Workflow Management Coalition (WfMC). Jego celem jest ujednolicenie różnych forma-
tów opisu procesów biznesowych oraz stworzenie mechanizmu wymiany definicji procesów
między różnymi narzędziami do modelowania przepływów. XPDL definiuje dokumenty
XML Schema, opisując strukturę jaką powinien mieć poprawny opis procesu biznesowego
w postaci przepływu. XPDL nie wprowadza nowej graficznej notacji, stara się być w
najwyższym stopniu zgodny z notacją BPMN i służyć jako format wymiany diagramów
BPMN. Dlatego też XPDL w przeciwieństwie do wielu innych formatów opisu procesu
(np. jPDL, BPEL) zaprojektowany został, by zawierać zarówno informację dotyczącą re-
prezentacji graficznej przepływu, jak i informację o jego logice przetwarzania. Dzięki temu
może posłużyć jako opis procesu w notacji BPMN. Taki sposób reprezentacji przepływu
stoi jednak w niezgodzie ze współczesnymi wzorcami reprezentacji danych, dążącymi do
rozdzielenia informacji na temat prezentacji od danych (np. XSLT, wzorzec MVC, archi-
tektura warstwowa aplikacji).
Listing 3.1 ukazuje implementację 3 wzorców sterowania przepływem. Elementy defi-
niujące stan początkowy, podział równoległy oraz synchronizację zostały pogrubione. Na
listingu umieszczono także elementy składni: , ,
, będące miejscami wstawiania dodatkowych informacji o
procesie (np. położenie elementów procesu na diagramie i opis implementacji), by pokazać
mechanizm rozszerzeń stosowany w XPDL.
1 2 3
35
-
3.3. XPDL
4 5 . . .6 7 8 . . . 9 . . .10 11 12 . . . 13 . . .14 15
16 17 18 19 20 21 22 23 24 25 26 . . . 27 . . .28 29 30 . . . 31 . . .32 33 34 35
36 37 38 39 40 41 42 . . .43 44 45 46 47 48 49 50 51 52 53 54 55
Listing 3.1: XPDL - wzorce: Sekwencja, Podział równoległy, Synchronizacja
Na stronie głównej projektu XPDL [12] można znaleźć definicję składni języka oraz
proste przykłady, zaś pozycje biblioteczne [21] i [50] zawierają dokładne omówienie składni
wraz z opisem mapowania XPDL - BPMN oraz przykładami implementacji podstawowych
wzorców przepływu.
Strona http://www.wfmc.org/xpdl-implementations.html zawiera pokaźną listę apli-
kacji do modelowania biznesowego bazujących na reprezentacji procesu w formacie XPDL.
36
http://www.wfmc.org/xpdl-implementations.html
-
3.4. BPEL
3.4 BPEL
BPEL (właściwie WS-BPEL, ang. Web Services Business Process Execution Langu-
age) stworzony przez organizację standaryzującą OASIS [4], jako język modelowania biz-
nesowego, służący do orkiestracji usług sieciowych. Powstał z połączenia języków WSFL i
XLANG oraz ich kompilacji w postaci języka BPEL4WS (ang. Business Process Execution
Language for Web Services). Jest stworzony w oparciu o składnie: XML, WSDL i XPath.
BPEL jest językiem o strukturze blokowej, w przeciwieństwie do głównego nurtu języ-
ków modelowania, które mają strukturę grafową. Taka struktura ułatwa tworzenie maszyn
wykonawczych (ang. execution environment), jednak wprowadza ograniczenia funkcjonal-
ne w stosunku do języków grafowych. Jest to przyczyną problemów z integracją z innymi
notacjami, przede wszystkim z BPMN.
Na listingu 3.2 została przedstwiona przykładowa implementacja wzorców przepływu:
sekwencji, podziau równoległego oraz synchronizacji. Dyskusja dotycząca składni BPEL
pod kątem możliwości realizacji wyrafinowanych wzorców przepływu została przeprowa-
dzona na stronach grupy Workflow Patterns [40].
1 2 3 . . . 4 5 < l i n k s>6 < l i n k name="into parallel split"/>7 < l i n k name="after synchronisation"/>8 9 10 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26
Listing 3.2: BPEL - wzorce: Sekwencja, Podział równoległy, Synchronizacja
Do podstawowej kontroli przepływu w BPEL służą tagi sequence, link, flow wyko-
37
-
3.4. BPEL
rzystane w przykładzie, do oznaczenia aktywności invoke. BPEL wyposażony jest także
w wiele innych konstrukcji językowych. Pełna specyfikacja standardu to dokument [13].
Podsumowując, podstawową zaletą języka BPEL jest łatwość tworzenia środowiska wy-
konawczego i dostępność wielu istniejących implementacji silników BPEL. Jest to standard
powszechnie akceptowany w środowisku twórców procesów opartych o usługi sieciowe, dla
których zaletą jest ścisłe powiązanie BPEL-a z technologią WebServices oraz językiem
WSDL służącym do komunikacji z usługami.
Podstawowymi wadami są:
• ograniczenia funkcjonalne związane z blokową konstrukcją (np. brak możliwości wy-
rażenia w języku dowolnych pętli);
• brak wsparcia dla szerokiej gamy złożonych wzorców przepływu, wynikająca z powyż-
szego ograniczenia;
• niekompatybilność z wieloma składniami języków BPM, w tym z najważniejszym -
BPMN;
• brak wsparcia dla zadań wykonywanych przez człowieka (ang. human tasks);
• wymuszenie konkretnego sposobu implementacji elementów procesu (aktywności jako
usługi sieciowe, przy użyciu komunikacji WSDL);
• niezrozumienie technicznej składni BPEL przez analityków biznesowych w połącze-
niu z niekompatybilnością z BPMN powoduje, trudności w wykorzystaniu języka do
integracji pracy analityka i programisty.
Niekompatybilność z wieloma językami modelowania, w tym z BPMN jest poważnym
problemem, jednak podejmowane są próby przezwyciężenia wyżej wymienionych trudno-
ści.
Stworzono (przy udziale m.in. SAP, Oracle, IBM) specyfikacje BPEL4People [20]
oraz WS-HumanTask [19] i są prowadzone w ramach OASIS prace nad standardem
OASIS WS-BPEL Extension for People (BPEL4People) [22], który łączyłby oba powyższe.
Specyfikacje te mają na celu wprowadzenie do języka BPEL obsługi zadań wykonywanych
przez człowieka (ang. Human tasks), które są niezwykle ważnym elementem modelowania
biznesowego, a są zupełnie pominięte w standardzie BPEL.
Powstają narzędzia do modelowania posługujące się w sferze wizualizacji notacją
BPMN i tłumaczące ją do wyrażeń BPEL. W następnych latach przewiduje się dalszą
38
-
3.5. INNE STANDARDY
integrację BPEL - BPMN, gdyż takie są obecnie wymagania rynku (projektanci i anality-
cy jako naturalny widzą język BPMN, deweloperom usług SOA bliższy jest język BPEL).
Programy do modelowania są w stanie przedstawiać coraz bardziej złożone struktury
BPMN w języku BPEL, jednak problemy wynikające z rozbieżnych założeń dotyczących
struktury języka (grafowej i blokowej) pozostaną. Dyskusję na temat translacji BPMN -
BPEL można znaleźć w pozycjach [51], [42].
BPEL jest doskonałym narzędziem do orkistracji usług sieciowych, jednak jego użycie
jako języka BPM jest sztuczne, a stało się popularne na skutek istnienia na rynku wielu
rozbudowanych silników wykonawczych BPEL, rozwoju architektur SOA z udziałem usług
sieciowych i chęci łączenia perspektyw projektowej i implementacyjnej, także za cenę
ograniczeń i kompromisów.
3.5 Inne standardy
W poprzednich podrozdziałach zostały omówione najważniejsze składnie i notacje z
zakresu modelowania procesów. Powstające narzędzia najczęściej posługują się którymś
z omówionych standardów do prezentacji, składowania, wymiany danych lub wykonania
przepływu prac. Na rynku dostępna jest jednak znacznie szersza baza języków modelo-
wania biznesowego.
Następny rozdział poświęcony jest platformie jBPM i językowi jPDL, środowisku mo-
delowania i wykonywania procesów dla języka Java, dynamicznie rozwijanemu przez firmę
Red Hat.
Zostało podjętych kilka prób standaryzacji programowania biznesowego dedykowanych
dla języka Java, w formie dokumentów JSR (ang. Java Specification Request). Prace nad
JSR 207 (ang. Process Definition for Java) oraz JSR 312 (JBI 2.0) zostały zarzucone.
Zaakceptowany został dokument JSR 208 [3], czyli JBI (ang. Java Business Integration),
definiujący infrastrukturę umożliwiającą integrację procesów (ang. Enterprise Application
Integration - EAI) oraz intergrację B2B poprzez udostępnienie standardowego API wy-
miany informacji między podłączanymi (ang. pluggable) do środowiska JBI niezależnymi
komponentami.
Należy wspomnieć o standardzie BPDM (ang. Business Process Definition Metamo-
39
-
del, [1]) wydanym przez OMG, który ma na celu stworzyć abstrakcyjną definicję (meta-
model) dla języka modelowania biznesowego, wyodrębniając jego podstawowe elementy
i zależności między poszczególnymi elementami. Metamodel ułatwia translację między
różnymi składniami języków modelowania, dostarcza formatu wymiany modelów procesu
między aplikacjami, pozwala na strukturalną reprezentację notacji BPMN. OMG definiuje
także inne standardy BPM, m.in. SBVR (ang. Semantics of Business Vocabulary and
Business Rules, [6]) oraz WfMF (ang. Workflow Management Facility, [8]).
Poniżej zostało wymienionych kilka języków modelowania biznesowego, nie tak po-
pularnych jak omówione w poprzednich podrozdziałach, lecz ciągle wykorzystywanych w
wielu, także komercyjnych projektach:
• PSL (ang. Process Specification Language, [5]) autorstwa NIST (ang. National Insti-
tute of Standards and Technology);
• ebXML (ang. Electronic Business using eXtensible Markup Language, [2]) autorstwa
OASIS;
• Wf-XML [7] autorstwa WFMC;
• YAWL (ang. Yet Another Workflow Language, [9] ) autorstwa grupy Workflow Pat-
terns.
Prócz ciągle rozwijanych języków modelowania istnieje także szeroka grupa języków,
które miały znaczenie w przeszłości, lecz obecnie nie są już rozwijane. Przykładami są
języki: WSFL (IBM), XLANG (Microsoft), BPML (BPMI).
Powyższe zestawienie obrazuje różnorodność i kłopotliwy brak jednolitości wśród na-
rzędzi wspierających modelowanie biznesowe. Bogatą listę standardów i narzędzi można
znaleźć w artykule [11].
-
Rozdział 4
Platforma JBPM
W rozdziale omówiona zostanie platforma Jboss jBPM i język modelowania bizne-
sowego jPDL, na bazie których, w ramach projektu magisterskiego stworzono narzędzie
wspierające proces modelowania. Oba standardy zostały opracowane przez zespół firmy
Red Hat w ramach projektu JBoss [48]. JBPM jest elastycznym narzędziem do zarządza-
nia procesami biznesowymi (stąd nazwa jBPM - Java Business Process Management). W
założeniu twórców, ma być platformą stanowiącą pomost między grupą analityków biz-
nesowych, a zespołem programistów, przyczyniając się do pogłębienia integracji procesu
wytwarzania oprogramowania. Tradycyjne silniki zarządzania procesami biznesowymi są
przeznaczone dla analityków biznesowych i działają niejako w oderwaniu od technicznego
świata programistów. Celem jBPM jest połączenie spojrzenia technicznego i analitycznego
w jedną spójną koncepcję procesu biznesowego.
JPDL (ang. Java Process Definition Language) - jest językiem modelowania bizneso-
wego o strukturze opisanej językiem XML, wykorzystanym w platformie jBPM do opisu
procesu.
41
-
4.1. STANDARD JBPM
System Workflow Web Designer odnosi się do wersji 3.2 platformy jBPM. Modelo-
wanie procesów biznesowych jest dynamicznie rozwijającym się kierunkiem w dziedzinie
tworzenia oprogramowania biznesowego. Częste zmiany dotyczą także platformy JBPM.
W czasie prac nad projektem magisterskim pojawiła się oficjalna dystrybucja platformy
w wersji 4, a następnie w wersji 5. W rozdziale zostaną zarysowane tendencje w rozwoju
narzędzia oraz podstawowe różnice w poszczególnych wersjach oprogramowania. Główny
nacisk położony jest jednak na opis wersji współgrającej z oprogramowaniem stworzonym
w ramach projektu magisterskiego, czyli jBPM w wersji 3.
4.1 Standard JBPM
Rysunek 4.1 przedstawia zarys architektury platformy JBoss JBPM. Ze względu na
przejrzystość nie zostały przedstawione wszystkie komponenty, tylko te najbardziej istot-
ne. Najważniejszym składnikiem jest PVM (ang. Process Virual Machine) - oprogramo-
wanie, którego celem jest sprawowanie kontroli nad wykonującym się procesem. Model
Procesu (ang. Process Model) to wewnętrzna reprezentacja procesu. Składają się na nią
dwie perspektywy procesu - statyczna i dynamiczna.
Perspektywa statyczna to zapisana w języku jPDL definicja procesu i jej mapowanie
na obiektowy model statyczny. Abstrakcją procesu jest klasa ProcessDefinition, będąca
kontenerem dla różnych węzłów i przejść między węzłami. Model procesu jest w jBPM
wzbogacony o bardziej wyspecjalizowane składniki. Dodatkowo cechuje go rozszerzalność
- użytkownik może tworzyć własne typy węzłów, które również będą mogły posłużyć do
tworzenia definicji procesu.
Perspektywa dynamiczna to model instancji procesu. Bazuje na pojęciach instancji i
wykonania procesu (ang. process execution) oraz tokena, opisanych w rozdziale teoretycz-
nym. Pojedyncza instancja może posiadać wiele ścieżek przetwarzania, w każdej z nich
znajduje się token. Z instancją związany jest jeden token główny (root token) i drzewo
tokenów potomnych. Przetwarzanie kończy się gdy token główny osiągnie stan końcowy.
Dwie podstawowe perspektywy procesu biznesowego - statyczna, czyli jego definicja i
dynamiczna, czyli instancja procesu mają odzwierciedlenie na wielu poziomach platformy,
42
-
4.1. STANDARD JBPM
Rysunek 4.1: Architektura platformy JBPM (na podst. dokumentacji projektu JBPM).
począwszy od modelu danych, przez omówioną reprezentację wewnętrzną procesu, po defi-
nicje i instancję kontekstu procesu oraz modułu zarządcy zadań (ang. Task Management).
Jednym z podstawowych założeń architektonicznych platformy jest jej modułowość i
serwisowa konstrukcja. Silnik JBPM składa się z grupy modułów podstawowych koniecz-
nych do funkcjonowania oprogramowania oraz z serwisów konfigurowalnych, opcjonalnych,
odpowiadających za pewien fragment funkcjonalny.
Oprócz PVM omówionej powyżej, niezbędnym składnikiem silnika jest menadżer
kontekstu i konfiguracji (ang. Context & Configuration Management module). Za-
daniem menadżera konfiguracji jest poprawna zestawienie środowiska pracy i wczytanie
definicji procesu, czyli translacja języka JPDL do obiektowego modelu procesu. Menadżer
kontekstu ma za zadanie zarządzanie zmiennymi wykorzystywanymi w czasie wykonywa-
nia procesu. To na nim spoczywa odpowiedzialność za wymianę danych pomiędzy węzłami
grafu procesu, przekazywanie danych wejściowych i produktu końcowego (ang. process
output) na zewnątrz procesu. Dostarczanie danych wyjściowych to nie tylko zadanie me-
nadżera kontekstu, ale i poszczególnych węzłów czynności.
Kolejnym niezbędnym składnikiem silnika JBPM jest menadżer zadań (ang. Task
43
-
4.1. STANDARD JBPM
manager). Dostarcza on mechanizmów zarządzania zadaniami i bramkami sterującymi.
JBPM dostarcza implementację podstawowych bramek: bramki rozłącznej (ang. decision),
bramki rozgałęzienia i synchronizacji procesu (fork, join gateways). Podstawową zasadą
przy projektowaniu menadżera zadań jest stworzenie elastycznego środowiska pracy dla
programisty i przekazanie mu kontroli nad zachowaniem procesu w obrębie węzłów czyn-
ności. To deweloper odpowiada za wznowienie wykonania procesu i decyduje o tym, w
którym momencie proces opuszcza węzły zadań. W JBPM istnieje też możliwość definicji
zadań asynchronicznych, przy obsłudze menadżer zadań współpracuje z modułem planera
zadań (ang. scheduler) i wykonawcą zadań (ang. Job Executor).
JBPM jest wyposażony w szereg modułów dodatkowych, opcjonalnych, jednakże ma-
jących fundamentalne znaczenie dla funkcjonowania potężnego silnika zarządzania proce-
sami biznesowymi.
Oprócz wspomnianych wykonawcy zadań asynchronicznych i planera można wymienić
komponent autoryzacji aktorów procesu oraz serwisy: transakcyjny i trwałości danych.
Fundamentalne znaczenie ma zwłaszcza mechanizm utrwalania danych. On także ma
za zadanie zapisywanie dwóch perspektyw procesu biznesowego, z funkcjonalnego punktu
widzenia najważniejszą cechą jest możliwość utrwalania stanu instancji procesu wraz z
jej kontekstem. Procesy biznesowe ze swej natury są operacjami długotrwałymi. Dopusz-
czenie interakcji z użytkownikiem w węzłach (ang. human tasks), powoduje długotrwałe
wstrzymywanie wykonania procesu. Dlatego też możliwość zapisania instancji procesu,
i odtworzenie jej stanu, w sytuacji wznowienia wykonania, jest podstawą poprawności
działa nia silników wykonawczych przepływów.
Platforma JBPM wyposażona jest dodatkowo w dwie aplikacje pomocnicze. Pierwszą z
nich jest JBPM Console - dostępna przez przeglądarkę platforma wdrażania i monitorowa-
nia wykonania procesów. Ma ona szczególne znaczenie w procesie testowania implementa-
cji, wdrożenia produkcyjne odbywają się bowiem w obrębie docelowego oprogramowania.
Drugą aplikacją dodatkową jest mająca duże znaczenie dla praktycznych zastosowań:
GPD Eclipse Desgner - działająca w środowisku programistycznym Eclipse platforma do
projektowania i implementacji procesów. Należy zauważyć, że realizacja celów, dla których
rozwija się modelowanie biznesowe byłaby niemożliwa bez istnienia graficznego narzędzia
do modelowania. GPD Eclipse Designer dostarcza narzędzie do tworzenia graficznej re-
44
-
4.2. FORMAT JPDL
prezentacji procesu, komponowania węzłów i przejść między nimi, służy dodatkowo jako
środowisko programisty procesów biznesowych, umożliwiając implementację poszczegól-
nych węzłów procesu. Podstawową wadą jest ścisłe związanie aplikacji ze środowiskiem
programistycznym Eclipse, co w praktyce uniemożliwia pogłębianie integracji pracy anali-
tyka i programisty, gdyż nie stwarza dogodnych warunków pracy analitykowi. Dodatkowo
jest to platforma stworzona do pracy lokalnej, z synchronizacją w oparciu o repozytorium
kodu, co nie daje szerokich możliwości pracy grupowej (równoległej).
Analiza języków modelowania biznesowego pod względem możliwości relizacji wzor-
ców przepływu dostępna na stronach grupy Workflow Patterns ( [40]) wskazuje, że język
JPDL jest w pełni funkcjonalnym językiem modelowania biznesowego, a platforma JBPM
dostarcza poza podstawowym środowiskiem wykonawczym (PVM), projektowym(GPD
Designer) i testowym (JBPM console) także szereg serwisów funkcjonalnych gwarantują-
cych wykonywanym procesom mechanizmy utrwalania stanu wykonania, transakcyjności,
planowania, autentykacji i autoryzacji. Umożliwia zbliżenie perspektywy biznesowej, pro-
jektowej i implementacyjnej, jednakże nie dostarcza wystarczającego środowiska pracy
analityka biznesowego.
4.2 Format jPDL
Silnik jBPM jest odpowiedzialny za wykonywanie określonego procesu, musi jednak
istnieć sposób, za pomocą którego podany proces zostanie zdefiniowany. W tym celu
został opracowany format opisu procesu o nazwie jPDL. Umożliwia stworzenie definicji
grafu przepływu oraz definiuje sposób umieszczania powiązanych z przepływem plików w
jednym archiwum typu zip. Poniższy opis dotyczy wersji 3.2 języka.
Najważniejszym elementem który powinien znaleźć się w archiwum jest plik pro-
cessdefiniotion.xml. Znajduje się w nim definicja grafu i konfiguracja poszczególnych
elementów. Nie zawiera jednak informacji odnośnie rozmieszczenia wierzchołków w prze-
strzeni, dlatego opcjonalnie może znaleźć się w archiwum plik gpd.xml z umieszczonymi
współrzędnymi każdego elementu oraz plik processdefinition.jpg będący wizualizacją
grafu przepływu. Dodatkowo w zależności od konfiguracji elementów w archiwum powin-
45
-
4.2. FORMAT JPDL
ny znaleźć się skompilowane klasy języka Java oraz wykorzystywane w zadaniach pliki z
definicją formularzy dla użytkownika.
Poniżej zostały przedstawione podstawowe elementy składniowe języka jPDL. Pełna
specyfikacja języka znajduje się w oficjalnej dokumentacji [49].
Wszystkie elementy związane z definicją procesu powinny znaleźć się w sekcji process-definition
w pliku processdefiniotion.xml. Dodatkowo w atrybucie sekcji z definicją przepływu
powinna znaleźć się informacja o wykorzystanej wersji języka jPDL.
1 2 . . .3
Listing 4.1: jPDL - definicja procesu
Podstawowymi elementami przepływu są wierzchołki. Umieszczane są bezpośrednio w
definicji procesu. Do najważniejszych własności wierzchołków należą:
name - nazwa wierzchołka
transition - wychodzące połączenie z wierzchołka
event - zbiór akcji przyporządkowanych do określonych zdarzeń
exception-handler - określa jakie akcje należy wywołać w przypadku wystąpienia sy-
tuacji wyjątkowej
Wierzchołki zostały podzielone ze względu na swoje indywidualne cechy na określone
typy. Odpowiadają one typom definiowanym przez standard jBPM. Poniżej lista wybra-
nych typów elementów:
start-state - element początkowy procesu. W przepływie może występować tylko jeden
element tego typu. Poza standardową konfiguracją element tego typu może posiadać jedno
zadanie(task).
node - podstawowy element przepływu. Nie posiada żadnych dodatkowych możliwości
konfiguracji poza tymi dostępnymi dla wszystkich typów.
state - element określający dany stan procesu. Jest elementem blokującym, oczekującym
na zajście pewnego zdarzenia. W celu kontynuowania przepływu musi zostać wzbudzony
poprzez otrzymanie odpowiedniego sygnału.
46
-
4.2. FORMAT JPDL
task-node - element służący do interakcji z użytkownikiem. Posiada listę zadań(task)
przeznaczonych do wykonania przez użytkownika.
fork - element nie posiada żadnych dodatkowych parametrów konfiguracyjnych. Służy do
równoległego rozdzielania przepływu na wszystkie swoje wyjścia.
join - element nie posiada żadnych dodatkowych parametrów konfiguracyjnych. Czeka aż
zakończą się wszystkie równoległe przepływy rozdzielone elementem typu fork.
decision - element decyzyjny. Umożliwia podanie w konfiguracji klasy odpowiedzialnej
za wybór wyjścia z elementu w danym przepływie.
end-state - element końcowy przepływu. W przeciwieństwie do pozostały elementów nie
może posiadać połączeń wyjściowych(transition).
Język jPDL umożliwia stworzenie połączenia między wierzchołkami za pomocą ele-
mentu transition. Element łączący podobnie jak wierzchołek może posiadać własną kon-
figurację. Do najważniejszych własności połączeń należą:
name - nazwa stworzonego połączenia
to - nazwa elementu do którego prowadzi połączenie
action - akcja przypisana do połączenia
exception-handler - określa jakie akcje należy wywołać w przypadku wystąpienia sy-
tuacji wyjątkowej
Poniżej znajdują się opisane w rozdziale 1.3 wzorce projektowe zapisane w języku
jPDL:
• Sekwencja - wzorzec realizowany jest poprzez wykorzystanie elementu transition.
Poniżej została przedstawiona sekwencja od węzła Node1 do węzła Node2.
1
2
3
4
5
6
Listing 4.2: jPDL - sekwencja
47
-
4.2. FORMAT JPDL
• Podział równoległy - wzorzec realizowany jest poprzez wykorzystanie węzła typu fork.
Poniżej został przedstawiony podział równoległy przepływu na dwie gałęzie prowadzą-
ce do węzłów Node2 i Node3.
1
2
3
4
5
6
7
8
9
10
11
Listing 4.3: jPDL - podział równoległy
• Synchronizacja - wzorzec realizowany jest poprzez wykorzystanie węzła typu join.
Poniżej została przedstawiona synchronizacja przepływów z gałęzi pochodzących od
węzłów Node1 i Node2.
1
2
3
4
5
6
7
8 < j o i n name="Join1">
9
10
11
12
Listing 4.4: jPDL - synchronizacja
• Decyzja - wzorzec realizowany jest poprzez wykorzystanie węzła typu decision. Po-
niżej została prze