dostępny przez przeglądarkę internetową system modelowania … · 2011. 7. 1. ·...

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


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


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


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


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


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


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


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


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


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

dostępny przez przeglądarkę internetową system modelowania … · 2011. 7. 1. ·...

Documents