Dostępny przez przeglądarkę internetową system modelowania procesów biznesowych zgodnych z językiem jpdl.

Wielkość: px
Rozpocząć pokaz od strony:

Download "Dostępny przez przeglądarkę internetową system modelowania procesów biznesowych zgodnych z językiem jpdl."

Transkrypt

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 Juszczyk janusz.bozek@gmail.com,tom.juszczyk@gmail.com Kierunek: Informatyka Specjalność: Systemy rozproszone i sieci komputerowe Nr albumu: Janusz Bożek Tomasz Juszczyk Promotor dr inż. Dominik Radziszowski

2 Oświadczenie autorów Oświadczamy, świadomi odpowiedzialności karnej za poświadczenie nieprawdy, że niniejszą 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)

3 Spis treści Wstęp I. Wprowadzenie Rozdział 1. Wprowadzenie do tematyki modelowania procesów biznesowych Ważniejsze pojęcia Składniki procesu biznesowego Obiekty sterujące przepływem Połączenia Elementy grupujące Artefakty Wzorce przepływu Sekwencja (ang. sequence) Podział równoległy (ang. parallel split) Synchronizacja (ang. synchronisation) Decyzja (ang. exclusive choice) Proste złączenie (ang. simple merge) Rozdział 2. Modelowanie przepływu w informatyce Znaczenie przepływu Aktualne kierunki rozwoju

4 Spis treści II. Tło technologiczne Rozdział 3. Obowiązujące standardy UML BPMN XPDL BPEL Inne standardy Rozdział 4. Platforma JBPM Standard JBPM Format jpdl Rozdział 5. Charakterystyka wybranych technologii Narzędzia modelowania procesów biznesowych JBoss jbpm Graphical Process Designer JBoss jbpm Modeller NetBeans Visual Paradigm Smart Development Environment Sparx Systems Enterprise Architect IBM WebSphere Business Modeler Oracle Business Process Management Suite Baza technologiczna projektu OPEN-jACOB Draw2D The Dojo Toolkit Apache Tiles Apache Struts JSON-RPC Podsumowanie III. Projekt i implementacja Rozdział 6. Projekt systemu Definicja zadania projektowego Wymagania funkcjonalne

5 Spis treści Wymagania niefunkcjonalne Kontekst systemu Aktorzy systemu Przypadki użycia Decyzje projektowe Architektura systemu Moduły aplikacji Model wdrożeniowy Model danych Model persystencji Dynamiczna reprezentacja projektu biznesowego Model procesu biznesowego Model aplikacji klienckiej Specyfikacje interfejsów Komunikacja warstwy prezentacji z warstwą przetwarzania Adaptacja biblioteki JBoss Graphical Process Designer Interfejs zewnętrzny Rozdział 7. Aspekty implementacyjne Sposóby organizacji graficznego interfejsu użytkownika Równoległa obsługa wielu procesów biznesowych Komunikacji warstwy prezentacji z warstwą serwera Implementacja obsługi usług sieciowych Podsumowanie IV. Podsumowanie Rozdział 8. Realizacja wymagań Realizacja wymagań funkcjonalnych Dodawanie i usuwanie węzłów procesu Tworzenie połączeń między węzłami Definiowanie akcji wykonywanej podczas przejścia Definiowanie zadania wykonywanego w węźle Modyfikacja graficznej reprezentacji procesu

6 Menadżer historii Utrwalanie pracy użytkownika Wczytanie danych do systemu Wdrażanie na maszyny wykonawcze Integracja procesu z usługami sieciowymi Wczytywanie opisu usługi sieciowej Obsługa repozytorium importowanych binariów Realizacja wymagań niefunkcjonalnych Intuicyjność interfejsu Swoboda dostępu, Łatwość wdrożenia, Wieloplatformowość Elastyczność Rozszerzalność Modułowa konstrukcja Bezpieczeństwo Podsumowanie Rozdział 9. Wnioski Podsumowanie realizacji projektu Kierunki dalszego rozwoju Import i eksport procesu Rozszerzanie możliwości funkcjonalnych edytora Rozszerzenie koncepcji repozytorium System Workflow jako platforma integracyjna Integracja z BPEL Adaptacja nowszej wersji edytora JBoss GPD Podsumowanie V. Dodatki Słownik Kompilacja i instalacja Bibliografia

7 Wstęp Modelowanie procesów biznesowych jest jednym z najważniejszych mechanizmów zarządzania przedsięwzięciami korporacyjnymi. Pozwala organizować procesy w myśl zasady ich ciągłego usprawniania (ang. continous improvment). W dobie informatyzacji wszystkich dziedzin życia, a zwłaszcza w zakresie organizacji pracy, najskuteczniejszym sposobem modelowania jest tworzenie procesów poddających się automatyzacji. Taką metodą opisu procesu biznesowego jest modelowanie za pomocą przepływów 1. Istotą przepływu prac jest automatyzacja procesu, który znajduje się pod kontrolą systemu informatycznego, 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ływów jest jednym z najciekawszych i najdynamiczniej rozwijających się podejść do tworzenia 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ługi 3, czy usługi sieciowe (ang. webservice). Podstawową 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 automatycznego wykonania. Dokładny opis w rozdziale 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 tworzenia systemów luźno powiązanych bazujących na kompozycji usług. 6

8 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 procesó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 Java 4. 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 rozproszonych 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 internetowej. Celem pracy jest stworzenie prototypu narzędzia do modelowania procesów biznesowych 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 Eclipse 5. Zadaniem projektu magisterskiego jest przeniesienie interfejsu użytkownika, tak by nie był on ściśle związany z oprogramowaniem dedykowanym 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 analityka 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 biznesowego 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 Environment). 7

9 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 proponowanego 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życiu metodologii grafowych, za pomocą przepływów prac. Zostały wprowadzone konieczne 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ływó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 implementacyjnym 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

10 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 systemu 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 opiekunó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

11 Część I Wprowadzenie

12 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 biznesowych 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ływu (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

13 1.1. WAŻNIEJSZE POJĘCIA na ten temat. We wspomnianym artykule przytaczane są różne definicje procesu biznesowego, 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 wymagania 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ątkiem 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.). Hammer 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, Johansson 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 biznesowego 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

14 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 oprogramowania 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łami 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 wynikają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

15 1.1. WAŻNIEJSZE POJĘCIA Instancją procesu biznesowego lub instancją przepływu nazywamy pojedyncze wykonanie 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 procesu. 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 pojedynczej 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. Pojedyncza 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 informatyce 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

16 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 Management) to ogół czynności, strategii podejmowanych przez organizację w celu stałej poprawy 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. Metodologia 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 wykorzystywane 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

17 1.2. SKŁADNIKI PROCESU BIZNESOWEGO Przy omawianiu podstawowych składników przepływu posłużono się notacją języka BPMN (Bussiens Process Modelling Notation), stworzonego przez konsorcjum OMG (Object Management Group) jako, że jest on najbardziej rozpowszechnionym standardem. Podstawowy katalog składników przepływu powstał w oparciu o pozycje biblioteczne: [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 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) Przez zdarzenia rozumiemy sytuacje, które mają miejsce podczas trwania procesu, mające wpływ na jego dalszy przebieg. Zazwyczaj są wywoływane przez jakiś fakt (wyzwalacz, 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: Typy zdarzeń Rysunek 1.1 przedstawia podstawowe typy zdarzeń w notacji BPMN. 16

18 1.2. SKŁADNIKI PROCESU BIZNESOWEGO Czynności (Activities) Czynności są najważniejszymi elementami procesu, gdyż modelują pracę do wykonania. Czynności można podzielić ze względu na atomowość operacji na zadania (ang. tasks) i podprocesy. 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ększego procesu. Użycie tego składnika poprawia przejrzystość, umożliwia powtórne wykorzystanie składników procesu (ang. reusability), wpływa na skalowalność. Zadanie cykliczne jest typem zadania, które jest wykonywane iteracyjnie. W procesach biznesowych pętle zdarzeń są opisywane z wykorzystaniem bramek, jednakże pojedyncze zadanie cykliczne można oznaczyć specjalnym symbolem. Rysunek 1.2: Typy czynności Bramki (Gates) Bramki są elementami sterującymi przepływem. Służą do oznaczania miejsc w systemie, w których w zależ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 odniesienia w tym rozdziale, wyróżnia kilka podstawowych typó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 wykonania, przy czym decyzja, która ścieżka zostaje wy- Rysunek 1.3: Typy bramek 17

19 1.2. SKŁADNIKI PROCESU BIZNESOWEGO brana następuje na podstawie spełnienia warunku (ang. data based decision) lub zdarzenia (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ą wykonania, 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ównoległ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 Połączenia Połączenia to krawędzie w grafie przepływu. Ich głównym zadaniem jest wprowadzenie porządku w zbiorze czynności, ustalenie kolejności zdarzeń. Dodatkowo służą do modelowania przesyłu informacji między elementami procesu oraz powiązania węzłów procesu z danymi (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 procesu (zdarzeń, czynności, bramek), nie mogą zaś łączyć Rysunek 1.4: Typy połączeń 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

20 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 procesu 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 informacji na etapie modelowania oraz pokazywanie przepływu danych w czasie trwania procesu Elementy grupujące Elementy grupujące nie są składnikiem funkcjonalnym, mającym fundamentalne znaczenie dla opisu sterowania, są elementem porządkującym opis, poprawiającym jego czytelność. Służą do wyszczególnienia ról procesowych, uczestników procesu oraz do modelowania 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 grupujących: Rysunek 1.5: Elementy grupujące pule (ang. pools) - to uczestnicy procesu, lub organizacje biorące udział w interaktywnym procesie typu B2B. Służą do wyznaczania kontekstu zewnętrznego dla procesu, 19

21 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 poszczegó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 Artefakty Artefakty są dodatkowymi elementami języków modelowania 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łatwiających czytanie i zrozumienie modelu procesu, pokazują przepływ danych w obrębie procesu. Język BPMN rozróżnia trzy podstawowe rodzaje artefatów: Rysunek 1.6: Artefakty adnotacja tekstowa - jest elementem opisowym, połączonym z elementem procesu za pomocą asocjacji. Dostarcza dodatkowej informacji o elemencie, tłumacząc jego znaczenie, wskazując ważne cechy. Nie jest istotna z punktu widzenia automatycznego 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

22 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 procesu, 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ływu. 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]) 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) 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

23 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) Synchronizacja (ang. synchronisation) Synchronizacja jest wzorcem modelującym połączenie dwóch lub więcej ścieżek przetwarzania 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 przetwarzania osiągnie bramkę. Rysunek 1.9: Synchronizacja (składnia BPMN) 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

24 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) 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 przemieszcza się jedynie wzdłuż jednej ze ścieżek. Oznacza to, że po osiągnięciu bramki prostego 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

25 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 patterns). 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).

26 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 systemów zarządzania procesami biznesowymi - BPMS (ang. Business Process Management Systems), które udostępniają użytkownikom narzędzia do realizacji trzech podstawowych zadań: modelowanie procesów (ang. process modelling); wykonywanie procesów (ang. process execution); monitorowanie procesów (ang. process monitoring). 25

27 2.1. ZNACZENIE PRZEPŁYWU Wykorzystywanie przez firmę technologii i platform realizujących procesy zgodnie z koncepcją workflow niesie z sobą wiele korzyści. Realizacja projektów biznesowych jest poddana 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 zapewnić 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 najwię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 zrozumieniem. 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ę procesu. Programistom pozostaje implementacja dobrze wyodrębnionych fragmentów funkcjonalnych (zadań w nomenklaturze języków modelowania biznesowego), najczęściej w postaci uniwersalnych serwisów. Tworzenie uniwersalnych serwisów umożliwia ich wielokrotne wykorzystanie (ang. reusability), co dodatkowo pozwala na oszczędność czasu. Program komputerowy umieszczony w odpowiednim środowisku zarządzania procesami 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

28 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 pozwala 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 komponentowemu 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 realizują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żą lepszemu 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ładnikó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ść rozwią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

29 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 globalnych 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 modelowania. 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 niekompatybilnoś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 projektanta 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żliwiającej wspólną pracę i wymianę spostrzeżeń przez przedstawicieli wszystkich wymienionych 28

30 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, interakcyjność, 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 kontenery aplikacji biznesowych (np. platforma JEE). Korporacje coraz powszechniej wprowadzają 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 services). 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 kontenerami 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).

31 Część II Tło technologiczne

32 Rozdział 3 Obowiązujące standardy Jednym ze wskaźników dużego zainteresowania branży językami modelowania biznesowego 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 wszystkie zainteresowane strony (analityków biznesowych, projektantów, deweloperów, przedstawicieli 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

33 3.1. UML Mimo tych utrudnień istnieje pewna liczba popularnych standardów, języków modelowania, 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żytkownikó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 biznesowego, 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ściowe, 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 dziedzinowych niemal nieznany. A jednym z głównych założeń nowoczesnych języków modelowania biznesowego jest zbliżenie tych środowisk. 32

34 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 pisania 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

35 3.2 BPMN 3.2. BPMN BPMN - Business Process Modeling Notation - graficzny, grafowy, język modelowania 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ędnieniem 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 najlepszym narzędziem dla analityka biznesowego i projektanta aby stworzyć strukturalną reprezentację 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 odpowiednika składni BPMN oraz narzędzi tłumaczących (translatorów) opisy procesu z reprezentacji 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 automatycznego 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ą reprezentację zrozumiałą w gronie analityków i mogą być poddane automatyzacji w platformach 34

36 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 formató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ą reprezentacji 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, architektura warstwowa aplikacji). Listing 3.1 ukazuje implementację 3 wzorców sterowania przepływem. Elementy definiujące stan początkowy, podział równoległy oraz synchronizację zostały pogrubione. Na listingu umieszczono także elementy składni: <NodeGraphicsInfos>, <Implementation>, <ConnectorGraphicsInfos>, 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 <WorkflowProcess Id=" Example1 "> 2 <A c t i v i t i e s > 3 <A c t i v i t y Id=" Stan Startowy "> 35

37 3.3. XPDL 4 <Route/> 5 <NodeGraphicsInfos >... </ NodeGraphicsInfos> 6 </A c t i v i t y > 7 <A c t i v i t y Id=" Zadanie 1"> 8 <Implementation>... </Implementation> 9 <NodeGraphicsInfos >... </ NodeGraphicsInfos> 10 </A c t i v i t y > 11 <A c t i v i t y Id=" Fork "> 12 <Implementation>... </Implementation> 13 <NodeGraphicsInfos >... </ NodeGraphicsInfos> 14 <T r a n s i t i o n R e s t r i c t i o n s > 15 <T r a n s i t i o n R e s t r i c t i o n > 16 <S p l i t Type=" AND "> 17 <T r a n s i t i o n R e f s > 18 <T r a n s i t i o n R e f Id="T4"/> 19 <T r a n s i t i o n R e f Id="T5"/> 20 </T r a n s i t i o n R e f s > 21 </S p l i t > 22 </ T r a n s i t i o n R e s t r i c t i o n > 23 </ T r a n s i t i o n R e s t r i c t i o n s > 24 </A c t i v i t y > 25 <A c t i v i t y Id="A"> 26 <Implementation>... </Implementation> 27 <NodeGraphicsInfos >... </ NodeGraphicsInfos> 28 </A c t i v i t y > 29 <A c t i v i t y Id="B"> 30 <Implementation>... </Implementation> 31 <NodeGraphicsInfos >... </ NodeGraphicsInfos> 32 </A c t i v i t y > 33 <A c t i v i t y Id=" Join "> 34 <T r a n s i t i o n R e s t r i c t i o n s > 35 <T r a n s i t i o n R e s t r i c t i o n > 36 <J o i n Type=" AND "/> 37 </ T r a n s i t i o n R e s t r i c t i o n> 38 </ T r a n s i t i o n R e s t r i c t i o n s> 39 </ A c t i v i t y> 40 <A c t i v i t y Id=" Stan końcowy "> 41 <Route/> 42 <NodeGraphicsInfos>... </ NodeGraphicsInfos> 43 </ A c t i v i t y> 44 </ A c t i v i t i e s> 45 <T r a n s i t i o n s> 46 <T r a n s i t i o n Id="T1" From=" Stan Startowy " To=" Zadanie 1"/> 47 <T r a n s i t i o n Id="T2" From=" Zadanie 1" To=" Fork "/> 48 <T r a n s i t i o n Id="T3" From=" Join " To=" Stan końcowy "/> 49 <T r a n s i t i o n Id="T4" From=" Fork " To="A"/> 50 <T r a n s i t i o n Id="T5" From=" Fork " To="B"/> 51 <T r a n s i t i o n Id="T6" From="A" To=" Join "/> 52 <T r a n s i t i o n Id="T7" From="B" To=" Join "/> 53 <T r a n s i t i o n Id="T8" From=" Join " To=" Stan końcowy "/> 54 </ T r a n s i t i o n s> 55 </ WorkflowProcess> 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 zawiera pokaźną listę aplikacji do modelowania biznesowego bazujących na reprezentacji procesu w formacie XPDL. 36

38 3.4 BPEL 3.4. BPEL BPEL (właściwie WS-BPEL, ang. Web Services Business Process Execution Language) stworzony przez organizację standaryzującą OASIS [4], jako język modelowania biznesowego, 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ęzyków modelowania, które mają strukturę grafową. Taka struktura ułatwa tworzenie maszyn wykonawczych (ang. execution environment), jednak wprowadza ograniczenia funkcjonalne 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 przeprowadzona na stronach grupy Workflow Patterns [40]. 1 <p r o c e s s name=" Example BPEL "> 2 <sequence> 3 <r e c e i v e... c r e a t e I n s t a n c e=" yes "... >... </ r e c e i v e> 4 <f l o w> 5 <l i n k s> 6 <l i n k name=" into parallel split "/> 7 <l i n k name=" after synchronisation "/> 8 </ l i n k s> 9 <invoke partnerlink=" Before Join "...> 10 <s o u r c e linkname=" into parallel split " 11 t r a n s i t i o n C o n d i t i o n="... "/> 12 </ invoke> 13 <f l o w> 14 <t a r g e t linkname=" into parallel split "/> 15 <s o u r c e linkname=" after synchronisation "/> <invoke partnerlink=" P1"/> 18 <invoke partnerlink=" P2"/> 19 <invoke partnerlink=" P3"/> 20 </ f l o w> 21 <invoke partnerlink=" Before Join "...> 22 <t a r g e t linkname=" after synchronisation "/> 23 </ invoke> 24 </ f l o w> 25 </ sequence> 26 </ p r o c e s s> 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

39 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 wykonawczego 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 wyraż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łączeniu 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

40 3.5. INNE STANDARDY integrację BPEL - BPMN, gdyż takie są obecnie wymagania rynku (projektanci i analitycy 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 modelowania biznesowego. Następny rozdział poświęcony jest platformie jbpm i językowi jpdl, środowisku modelowania 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 wymiany 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

41 del, [1]) wydanym przez OMG, który ma na celu stworzyć abstrakcyjną definicję (metamodel) 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 popularnych 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 Institute 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 Patterns. 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 narzędzi wspierających modelowanie biznesowe. Bogatą listę standardów i narzędzi można znaleźć w artykule [11].

42 Rozdział 4 Platforma JBPM W rozdziale omówiona zostanie platforma Jboss jbpm i język modelowania biznesowego 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ądzania 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 biznesowych, 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 biznesowego o strukturze opisanej językiem XML, wykorzystanym w platformie jbpm do opisu procesu. 41

43 4.1. STANDARD JBPM System Workflow Web Designer odnosi się do wersji 3.2 platformy jbpm. Modelowanie 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 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 istotne. Najważniejszym składnikiem jest PVM (ang. Process Virual Machine) - oprogramowanie, 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 teoretycznym. 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

44 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 definicje 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 koniecznych 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). Zadaniem 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 wykonywania 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 menadż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

45 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 czynnoś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 mających fundamentalne znaczenie dla funkcjonowania potężnego silnika zarządzania procesami 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. Dopuszczenie 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 monitorowania wykonania procesów. Ma ona szczególne znaczenie w procesie testowania implementacji, 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

46 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ólnych 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 analityka 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 wzorcó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, projektowej 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 processdefiniotion.xml. Znajduje się w nim definicja grafu i konfiguracja poszczególnych elementów. Nie zawiera jednak informacji odnośnie rozmieszczenia wierzchołków w przestrzeni, 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

47 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 <p r o c e s s d e f i n i t i o n xmlns=" urn:jbpm. org:jpdl -3.2 "> </ p r o c e s s d e f i n i t i o n> 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 sytuacji 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 wybranych 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

48 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ą elementu transition. Element łączący podobnie jak wierzchołek może posiadać własną konfigurację. 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 sytuacji 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 <p r o c e s s d e f i n i t i o n xmlns=" urn:jbpm. org:jpdl -3.2 "> 2 <node name=" Node1 "> 3 <t r a n s i t i o n to=" Node2 "> 4 </ node> 5 <node name=" Node2 "> 6 </ p r o c e s s d e f i n i t i o n> Listing 4.2: jpdl - sekwencja 47

49 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 <p r o c e s s d e f i n i t i o n xmlns=" urn:jbpm. org:jpdl -3.2 "> 2 <node name=" Node1 "> 3 <t r a n s i t i o n to=" Fork1 "> 4 </ node> 5 <f o r k name=" Fork1 "> 6 <t r a n s i t i o n to=" Node2 "> 7 <t r a n s i t i o n to=" Node3 "> 8 </ f o r k> 9 <node name=" Node2 "> 10 <node name=" Node3 "> 11 </ p r o c e s s d e f i n i t i o n> 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 <p r o c e s s d e f i n i t i o n xmlns=" urn:jbpm. org:jpdl -3.2 "> 2 <node name=" Node1 "> 3 <t r a n s i t i o n to=" Join1 "> 4 </ node> 5 <node name=" Node2 "> 6 <t r a n s i t i o n to=" Join1 "> 7 </ node> 8 <j o i n name=" Join1 "> 9 <t r a n s i t i o n to=" Node3 "> 10 </ j o i n> 11 <node name=" Node3 "> 12 </ p r o c e s s d e f i n i t i o n> Listing 4.4: jpdl - synchronizacja Decyzja - wzorzec realizowany jest poprzez wykorzystanie węzła typu decision. Poniżej została przedstawiona decyzja między przejściem do węzła Node1, a Node2. 1 <p r o c e s s d e f i n i t i o n xmlns=" urn:jbpm. org:jpdl -3.2 "> 2 <d e c i s i o n name=" Decision1 "> 3 <t r a n s i t i o n to=" Node1 "> 48

50 4 <t r a n s i t i o n to=" Node2 "> 5 </ d e c i s i o n> 6 <node name=" Node1 "> 7 <node name=" Node2 "> 8 </ p r o c e s s d e f i n i t i o n> Listing 4.5: jpdl - decyzja Proste złączenie - wzorzec realizowany jest poprzez wykorzystanie węzła typu task. Poniżej zostało przedstawione proste złączenie gałęzi pochodzących od elementów Task1 i Task2. 1 <p r o c e s s d e f i n i t i o n xmlns=" urn:jbpm. org:jpdl -3.2 "> 2 <t a s k name=" Task1 "> 3 <t r a n s i t i o n to=" Node1 "> 4 </ t a s k> 5 <t a s k name=" Task2 "> 6 <t r a n s i t i o n to=" Node1 "> 7 </ t a s k> 8 <node name=" Node1 "> 9 </ p r o c e s s d e f i n i t i o n> Listing 4.6: jpdl - proste złączenie Podsumowując, język jpdl umożliwia zdefiniowanie przepływu zgodnego ze standardem jbpm. Dodatkowo możliwe jest również zamodelowanie wszystkich podstawowych wzorców przepływu, dzięki czemu można wykorzystać gotowe rozwiązania najpopularniejszych problemów związanych z tworzeniem procesu biznesowego. Wprawdzie możliwe jest stworzenie przepływu w języku jpdl nawet w zwykłym edytorze tekstowym, jednak jest to zadanie żmudne i czasochłonne. Najlepiej w tym celu skorzystać z graficznego edytora procesów biznesowych wspierającego standard jbpm.

51 Rozdział 5 Charakterystyka wybranych technologii 5.1 Narzędzia modelowania procesów biznesowych W rozdziale zostaną zaprezentowane wybrane narzędzia ułatwiające modelowanie procesów biznesowych JBoss jbpm Graphical Process Designer JBoss jbpm Graphical Process Designer [14] jest profesjonalnym narzędziem do modelowania procesów biznesowych zgodnych ze standardem jbpm. Występuje w formie do- 50

52 5.1. NARZĘDZIA MODELOWANIA PROCESÓW BIZNESOWYCH datku do środowiska programistycznego Eclipse. Jest rozpowszechniany na licencji LGPL, dzięki czemu może być używany bez konieczności wykupienia odpowiedniej licencji. Rysunek 5.1: JBoss jbpm GPD: Widok okna umożliwiającego tworzenie nowego przepływu. Poprzez graficzny interfejs umożliwia stworzenie przepływu przy wykorzystaniu dostępnych wierzchołków i połączeń. Każdy element występujący na diagramie może zostać uzupełniony o odpowiednią konfigurację, różną w zależności od jego typu. Całość przechowywana jest w formacie XML zgodnym z językiem jpdl. Dzięki temu, że edytor jest dodatkiem do środowiska Eclipse istnieje możliwość uzupełnienia przepływu o elementy programistyczne wykorzystując tylko jedno narzędzie. Stworzony przepływ może zostać przesłany na podany serwer lub zapisany do pliku w postaci archiwum zip. W archiwum z procesem znajduje się plik z przepływem w formacie jpdl, plik zawierający informację o rozmieszczeniu wierzchołków w przestrzeni oraz wygenerowany automatycznie plik graficzny ze stworzonym przepływem. Dodatkowo w archiwum znajdują się klasy napisane w języku Java użyte w przepływie oraz pozostałe wymagane zasoby. 51

53 5.1. NARZĘDZIA MODELOWANIA PROCESÓW BIZNESOWYCH Rysunek 5.2: JBoss jbpm GPD: Widok okna umożliwiającego umieszczenie (ang. deployment) przepływu na określonym serwerze JBoss jbpm Modeller JBoss jbpm Modeller [46] jest dostępnym przez przeglądarkę internetową systemem do modelowania procesów biznesowych.został oparty na istniejącym edytorze procesów biznesowych stworzonym przez firmę Signavio. Edytor Signavio bazuje natomiast na bezpłatnym narzędziu do modelowania Oryx. Umożliwia stworzenie przepływu, który może być następnie zapisany i otworzony w JBoss jbpm Graphical Process Designer w celu uzupełnienia go o elementy programistyczne. Dopiero tak przygotowany przepływ może zostać umieszczony na serwerze i wykonany przez silnik jbpm. Notacja wykorzystywana do tworzenia przepływu jest zgodna ze standardem BPMN 1.2, jednak następna wersja ma obsługiwać standard BPMN 2.0. Stworzony przepływ jest natomiast zapisywany w formacie zgodnym z formatem jpdl. Zaletą tego systemu jest dostępność z poziomu przeglądarki internetowej, dzięki czemu nie ma potrzeby instalowania nowych narzędzi na każdym środowisku na którym ma być użyty. Głównymi odbiorcami 52

54 5.1. NARZĘDZIA MODELOWANIA PROCESÓW BIZNESOWYCH Rysunek 5.3: Signavio jbpm Modeller: Widok okna edytora. 1 opisywanego narzędzia są osoby odpowiedzialne za modelowanie procesów biznesowych, a stworzone przez nich przepływy muszą być później uzupełnione o części programistyczne NetBeans Środowisko programistyczne NetBeans [15] udostępnia edytor graficzny do modelowania procesów biznesowych zgodnych ze standardem BPEL. Rozpowszechniane jest na licencjach CDDL i GNU. W przeciwieństwie do wcześniej opisywanych narzędzi tworzących przepływ zgodny ze standardem jbpm, edytor środowiska NetBeans opiera się na standardzie BPEL. Służy przez to głównie do pracy z serwisami sieciowymi i określenia sposobu w jaki mają ze sobą współpracować. Dużą zaletą narzędzia jest rozbudowany mechanizm odwzorowania parametrów wejściowych jak i wyjściowych serwisów sieciowych. Ostatnią wersją zawierającą graficzny edytor języka BPEL była wersja 6.5, kolejne wersje NetBeans zostały już pozbawione tej funkcjonalności. 1 Źródło: archive.html 53

55 5.1. NARZĘDZIA MODELOWANIA PROCESÓW BIZNESOWYCH Rysunek 5.4: NetBeans: Widok okna umożliwiającego stworzenie nowego przepływu Visual Paradigm Smart Development Environment Smart Development Environment firmy Visual Paradigm [43] jest rozbudowanym narzędziem do projektowania i tworzenia systemów, jednak w przeciwieństwie do wcześniej wymienionych jest rozwiązaniem płatnym. Występuje jako dodatek do najpopularniejszych środowisk programistycznych. Narzędzie do projektowania procesów biznesowych jest jedynie jednym z wielu dostępnych funkcjonalności produktu. Dołączony jest jednak tylko do wersji Enterprise Edition, która jest zdecydowanie najdroższą z możliwości. Smart Development Environment w porównaniu do pozostałych wymienionych narzędzi jest najbardziej rozbudowany i posiada dużo więcej opcji od pozostałych. Umożliwia generowanie procesów zgodnych zarówno ze standardem BPEL jak i jpdl. Dodatkowo obsługiwany jest jeszcze format XPDL, który nie był wspierany przez żadne z wcześniej opisywanych narzędzi. Tworzone diagramy przepływów są zgodne ze standardem BPMN 2.0. Smart Development Environment jest najbardziej rozbudowanym narzędziem ze wszystkich opisanych, jednak największą jego wadą jest wysoka cena. W zdecydowanej większości przypadków najlepiej skorzystać z jednego z bezpłatnych rozwiązań, które zawierają 54

56 5.1. NARZĘDZIA MODELOWANIA PROCESÓW BIZNESOWYCH Rysunek 5.5: Visual Paradigm SDE: Widok okna umożliwiającego stworzenie nowego przepływu. 1 wszystkie najpotrzebniejsze funkcje. Na korzyść pozostałych rozwiązań przemawia również prostsza obsługa Sparx Systems Enterprise Architect Również płatnym narzędziem jest Enterprise Architect [47] firmy Sparx Systems. Aplikacja służy głównie do modelowania diagramów zgodnych ze standardem UML, jednak od wersji 7.5 posiada wsparcie do tworzenia procesów biznesowych, Jedną z dostępnych funkcjonalności narzędzia Enterprise Architect jest modelowanie procesów biznesowych. Tworzone diagramy są zgodne z notacją BPMN. Dodatkowo obsługiwany jest język modelowania procesów biznesowych BPEL. Wsparcie do modelowania procesów biznesowych nie jest główną funkcjonalnością aplikacji, a jedynie jedną z wielu. Powoduje to bardziej ograniczone możliwości w porównaniu z systemami skupiającymi się jedynie na procesach biznesowych. 1 Źródło: 55

57 5.1. NARZĘDZIA MODELOWANIA PROCESÓW BIZNESOWYCH Rysunek 5.6: Sparx Systems Enterprise Architect: Widok okna umożliwiającego tworzenie procesu biznesowego IBM WebSphere Business Modeler WebSphere Business Modeler [32] to komercyjne narzędzie firmy IBM ułatwiające tworzenie i zarządzanie procesami biznesowymi. To co wyróżnia produkt firmy IBM od podobnych rozwiązań to rozbudowany edytor graficzny procesów wspierający standard BPMN. Na uwagę zasługuje również bardzo rozbudowana funkcjonalność narzędzia, pod tym kontem zdecydowanie przewyższa darmowe odpowiedniki. Tak jak w większości systemów komercyjnych wspieranym standardem jest BPEL. 1 Źródło: process modeling.html 56

58 5.1. NARZĘDZIA MODELOWANIA PROCESÓW BIZNESOWYCH Rysunek 5.7: IBM WebSphere Business Modeler: Widok okna umożliwiającego tworzenie procesu biznesowego Oracle Business Process Management Suite Firma Oracle również posiada swoje narzędzie do modelowania procesów biznesowych, mowa tutaj o Oracle Business Process Management Suite [41]. Jak przystało na narzędzie komercyjne BPM Suite jest bardzo rozbudowanym systemem. Posiada edytor graficzny zgodny ze standardem BPMN 2.0. Podobnie jak pozostałe systemy komercyjne wspiera standard BPEL oraz dodatkowo XPDL. Na uwagę zasługuje bardzo rozbudowana dokumentacja dostępna na stronie producenta, co w przypadku tak skomplikowanego systemu jest bardzo istotną zaletą. 1 Źródło: 57

59 5.2. BAZA TECHNOLOGICZNA PROJEKTU Rysunek 5.8: Oracle BPM Suite: Widok okna umożliwiającego tworzenie procesu biznesowego Baza technologiczna projektu W poniższym rozdziale dokonany zostanie przegląd najważniejszych technologii wykorzystanych w fazie implementacji projektu magisterskiego. Z całą pewnością nie zostały w nim ujęte wszystkie narzędzia i biblioteki z których Workflow Web Designer korzysta, lecz tylko te najistotniejsze. Z uwagi na specyfikę projektu i duży nacisk na interfejs graficzny użytkownika najważniejszymi bibliotekami okazały się biblioteki graficzne OPEN-jACOB Draw2D OPEN-jACOB Draw2D [30] to biblioteka napisana w języku JavaScript przez Andreasa Herza, udostępniana na licencji LGPL. Jest to narzędzie wspomagające tworzenie aplikacji graficznych, działających po stronie przeglądarki internetowej. Dużą zaletą jest prosty i intuicyjny interfejs ułatwiający pracę i poznanie biblioteki. 1 Źródło: 58

60 5.2. BAZA TECHNOLOGICZNA PROJEKTU Dodatkową zaletą omawianej biblioteki jest bezpłatna dokumentacja dostępna na stronie internetowej produktu oraz liczne przykłady pokazujące użycie poszczególnych elementów. Biblioteka jest cały czas rozwijana, dochodzą nowe funkcjonalności oraz poprawiane są błędy. Rysunek 5.9: Przykład wykorzystania biblioteki Draw2D. 1 Technologia została wybrana ze względu na rozbudowaną funkcjonalność odpowiadającą potrzebą oraz swoją prostotę. Dodatkowo brak jest zbliżonego, darmowego narzędzia mogącego konkurować z Draw2D The Dojo Toolkit The Dojo Toolkit [25] jest biblioteką programistyczną napisaną w języku JavaScript, rozpowszechniana na zasadzie licencji BSD i Free Academic License. Ułatwia tworzenie graficznego interfejsu użytkownika dzięki udostępnianiu interesujących kontrolek. Jej zaletą jest atrakcyjny wygląd komponentów oraz rozbudowane i ciągle rozwijane możliwości. 1 Źródło: 59

61 5.2. BAZA TECHNOLOGICZNA PROJEKTU Dojo nie jest jednak tylko zwykłym narzędziem graficznym, oferuje jeszcze dodatkowe funkcjonalności takie jak między innymi wsparcie dla asynchronicznej komunikacji z serwerem, czy mechanizmy ułatwiające przechowywanie danych. Posiada również narzędzia do obsługi popularnych formatów przechowywania danych, takich jak format JSON. Przydatną funkcjonalnością The Dojo Toolkit może być również mechanizm ułatwiający rysowanie wykresów. Rysunek 5.10: Przykładowa strona stworzona przy pomocy The Dojo Toolkit. 1 Biblioteka The Dojo Toolkit została wybrana z uwagi na szybką i łatwą możliwość stworzenia ładnie wyglądającego graficznego interfejsu użytkownika, oraz udostępniania rozbudowanych mechanizmów zarządzania danymi. 1 Źródło: 60

62 5.2. BAZA TECHNOLOGICZNA PROJEKTU Apache Tiles Apache Tiles 2 [24] jest narzędziem stworzonym w celu uproszczenia procesu tworzenia interfejsu użytkownika aplikacji internetowych. Umożliwia modularyzację rozbudowanych stron internetowych wprowadzając ich logiczny podział oraz pozwala na wielokrotne wykorzystanie kodu (ang. code reuse) poprzez tworzenie szablonów widoku i podmianie tylko treści poszczególnych elementów szablonu w odpowiedzi na żądanie użytkownika. Biblioteka Tiles2 umożliwia prostą konfigurację dzięki zastosowaniu pliku konfiguracyjnego w formacie XML. Definiuje się w nim które fragmenty stron powinny być umieszczone w odpowiednich miejscach w trakcie wyświetlania strony w przeglądarce internetowej. Technologia została wybrana w celu uproszczenia procesu implementacji poprzez umożliwienie podziału dużych plików zawierających kod HTML Apache Struts 2 Struts 2 [23] jest otwartym oprogramowaniem grupy Apache wspierającym tworzenie warstwy kontrolera aplikacji internetowych. Początkowo nosił nazwę WebWork 2 i był rozwijany równolegle z frameworkiem Struts, jednak po kilku latach oba te projekty zostały połączone i powstał Struts 2. Framework Struts 2 powstał, aby ułatwiać tworzenie aplikacji opartych na architekturze Model-View-Controller (MVC). Dostarcza kontroler aplikacji (ActionServlet) oraz ułatwia tworzenie szablonu widoku. Twórca aplikacji może ograniczyć się jedynie do napisania modelu aplikacji oraz stworzenia pliku struts.xml zawierającego konfigurację frameworka. Cała architektura rozwiązania została została przedstawiona na rysunku Istnieją wprawdzie jeszcze inne frameworki służące do tworzenia aplikacji internetowych opartych na architekturze MVC, jednak zdecydowano się na użycie Struts 2. Zadecydowała o tym duża popularność tego rozwiązania, dzięki czemu istnieje rozbudowana dokumentacja narzędzia oraz łatwo można znaleźć przykładowe rozwiązania popularnych problemów. 61

63 5.2. BAZA TECHNOLOGICZNA PROJEKTU Rysunek 5.11: Architektura frameworka Struts JSON-RPC JSON-RPC [34] jest to protokół umożliwiający zdalne wywołanie procedur przy wykorzystaniu formatu JSON. Komunikacja z wykorzystaniem tego protokołu polega na wysłaniu żądania od klienta zawierającego informacje potrzebne do wywołania zdalnej metody udostępnianej przez serwer. Po wywołaniu metody odsyłana jest odpowiedź zawierająca informację odnośnie statusu wykonania oraz zwróconych danych. Do przesyłania 1 Źródło: 62

JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE]

JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE] JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE] Parę słów o mnie 2 Nauczyciel akademicki od 2000 roku Od 2002 współpracuję z firmami jako programista i projektant aplikacji Od 2006 roku właściciel firmy

Bardziej szczegółowo

Procesy biznesowe w praktyce. Przykłady użycia z wykorzystaniem jbpm 4.4

Procesy biznesowe w praktyce. Przykłady użycia z wykorzystaniem jbpm 4.4 Procesy biznesowe w praktyce Przykłady użycia z wykorzystaniem jbpm 4.4 1 Agenda Definicja i zastosowanie procesu biznesowego Języki dziedzinowe (DSL) a rozwiązania BPM JBPM: jbpm 4.4 krótka charakterystyka

Bardziej szczegółowo

Modelowanie procesów biznesowych, przepływu pracy i wdrażanie aplikacji w oparciu o Jboss jbpm lub Activiti

Modelowanie procesów biznesowych, przepływu pracy i wdrażanie aplikacji w oparciu o Jboss jbpm lub Activiti Kod szkolenia: Tytuł szkolenia: JBPM Modelowanie procesów biznesowych, przepływu pracy i wdrażanie aplikacji w oparciu o Jboss jbpm lub Activiti Dni: 2 Szkolenie jest zgodne z wersją 6.x, możliwe są również

Bardziej szczegółowo

Spis treúci. 1. Wprowadzenie... 13

Spis treúci. 1. Wprowadzenie... 13 Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...

Bardziej szczegółowo

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

Język UML w modelowaniu systemów informatycznych Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 4 Diagramy aktywności I Diagram aktywności (czynności) (ang. activity

Bardziej szczegółowo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Michał Adamczyk. Język UML

Michał Adamczyk. Język UML Michał Adamczyk Język UML UML I. Czym jest UML Po co UML II.Narzędzia obsługujące UML, edytory UML III.Rodzaje diagramów UML wraz z przykładami Zastosowanie diagramu Podstawowe elementy diagramu Przykładowy

Bardziej szczegółowo

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language) Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu

Bardziej szczegółowo

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017 Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy

Bardziej szczegółowo

ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI

ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI XVIII Forum Teleinformatyki mgr inż. Michał BIJATA, doktorant, Wydział Cybernetyki WAT Michal.Bijata@WAT.edu.pl, Michal@Bijata.com 28 września 2012 AGENDA Architektura

Bardziej szczegółowo

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI KARTA PRZEDMIOTU przedmiotu Stopień studiów i forma Rodzaj przedmiotu Grupa kursów Zaawansowane techniki analizy systemowej oparte na modelowaniu warsztaty Studia podyplomowe Obowiązkowy NIE Wykład Ćwiczenia

Bardziej szczegółowo

Informatyzacja przedsiębiorstw WYKŁAD

Informatyzacja przedsiębiorstw WYKŁAD Informatyzacja przedsiębiorstw WYKŁAD dr inż. Piotr Zabawa IBM/Rational Certified Consultant pzabawa@pk.edu.pl wersja 0.1.0 07.10.2010 Wykład 1 Modelowanie procesów biznesowych Przypomnienie rodzajów narzędzi

Bardziej szczegółowo

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla studenta

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla studenta Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne

Bardziej szczegółowo

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

WPROWADZENIE DO UML-a

WPROWADZENIE DO UML-a WPROWADZENIE DO UML-a Maciej Patan Instytut Sterowania i Systemów Informatycznych Dlaczego modelujemy... tworzenie metodologii rozwiązywania problemów, eksploracja różnorakich rozwiązań na drodze eksperymentalnej,

Bardziej szczegółowo

Wymiana opisu procesów biznesowych pomiędzy środowiskiem Eclipse i EMC Documentum

Wymiana opisu procesów biznesowych pomiędzy środowiskiem Eclipse i EMC Documentum Wymiana opisu procesów biznesowych pomiędzy środowiskiem Eclipse i EMC Documentum Stanisław Jerzy Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Systemy CMS (Content

Bardziej szczegółowo

Podstawy programowania III WYKŁAD 4

Podstawy programowania III WYKŁAD 4 Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.

Bardziej szczegółowo

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy

Bardziej szczegółowo

SOA Web Services in Java

SOA Web Services in Java Wydział Informatyki i Zarządzania Wrocław,16 marca 2009 Plan prezentacji SOA 1 SOA 2 Usługi Przykłady Jak zacząć SOA Wycinek rzeczywistości Problemy zintegrowanych serwisów : Wycinek Rzeczywistości Zacznijmy

Bardziej szczegółowo

UML cz. III. UML cz. III 1/36

UML cz. III. UML cz. III 1/36 UML cz. III UML cz. III 1/36 UML cz. III 2/36 Diagram współpracy Diagramy współpracy: prezentują obiekty współdziałające ze sobą opisują rolę obiektów w scenariuszu mogą prezentować wzorce projektowe UML

Bardziej szczegółowo

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

Bardziej szczegółowo

Projekt architektury systemów informatycznych Uniwersytetu Warszawskiego w oparciu o metodykę TOGAF. Tomasz Turski 26.05.2011

Projekt architektury systemów informatycznych Uniwersytetu Warszawskiego w oparciu o metodykę TOGAF. Tomasz Turski 26.05.2011 Projekt architektury systemów informatycznych Uniwersytetu Warszawskiego w oparciu o metodykę TOGAF Tomasz Turski 26.05.2011 Plan prezentacji Architektura korporacyjna Frameworki Pryncypia Metodyka TOGAF

Bardziej szczegółowo

Wykład 1 Inżynieria Oprogramowania

Wykład 1 Inżynieria Oprogramowania Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI

Bardziej szczegółowo

Wykład Ćwiczenia Laboratorium Projekt Seminarium

Wykład Ćwiczenia Laboratorium Projekt Seminarium WYDZIAŁ ELEKTRONIKI KARTA PRZEDMIOTU Nazwa w języku polskim Języki programowania Nazwa w języku angielskim Programming languages Kierunek studiów (jeśli dotyczy): Informatyka - INF Specjalność (jeśli dotyczy):

Bardziej szczegółowo

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych

Bardziej szczegółowo

Analiza i projektowanie aplikacji Java

Analiza i projektowanie aplikacji Java Analiza i projektowanie aplikacji Java Modele analityczne a projektowe Modele analityczne (konceptualne) pokazują dziedzinę problemu. Modele projektowe (fizyczne) pokazują system informatyczny. Utrzymanie

Bardziej szczegółowo

Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)

Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura

Bardziej szczegółowo

Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML. Jakub Morkis, Piotr Chmielewski

Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML. Jakub Morkis, Piotr Chmielewski Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML Jakub Morkis, Piotr Chmielewski BPMN - Historia Formowanie grumy tworzącej notację Sierpień 2001, 58 członków reprezentujących 35 firm,

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne przedmioty.

Bardziej szczegółowo

Projektowanie oprogramowania

Projektowanie oprogramowania Wrocław, 27.09.2010 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

Język UML w modelowaniu systemów informatycznych Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 10 Diagramy wdrożenia I Diagramy wdrożenia - stosowane do modelowania

Bardziej szczegółowo

UML w Visual Studio. Michał Ciećwierz

UML w Visual Studio. Michał Ciećwierz UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować

Bardziej szczegółowo

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych

Bardziej szczegółowo

Model referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami

Model referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami Politechnika Gdańska Wydział Zarządzania i Ekonomii Katedra Zastosowań Informatyki w Zarządzaniu Zakład Zarządzania Technologiami Informatycznymi Model referencyjny Open Source dla dr hab. inż. Cezary

Bardziej szczegółowo

Szkolenie: Budowa aplikacji SOA/BPM na platformie Oracle SOA Suite 11g

Szkolenie: Budowa aplikacji SOA/BPM na platformie Oracle SOA Suite 11g Szkolenie: Budowa aplikacji SOA/BPM na platformie Oracle SOA Suite 11g Opis szkolenia: Termin SOA, czyli Service Oriented Architecture, oznacza architekturę systemów informatycznych opartą o usługi. Za

Bardziej szczegółowo

Modelowanie i Programowanie Obiektowe

Modelowanie i Programowanie Obiektowe Modelowanie i Programowanie Obiektowe Wykład I: Wstęp 20 październik 2012 Programowanie obiektowe Metodyka wytwarzania oprogramowania Metodyka Metodyka ustandaryzowane dla wybranego obszaru podejście do

Bardziej szczegółowo

Analityk i współczesna analiza

Analityk i współczesna analiza Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura

Bardziej szczegółowo

Narzędzia CASE dla.net. Łukasz Popiel

Narzędzia CASE dla.net. Łukasz Popiel Narzędzia CASE dla.net Autor: Łukasz Popiel 2 Czym jest CASE? - definicja CASE (ang. Computer-Aided Software/Systems Engineering) g) oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania

Bardziej szczegółowo

Podstawy modelowania programów Kod przedmiotu

Podstawy modelowania programów Kod przedmiotu Podstawy modelowania programów - opis przedmiotu Informacje ogólne Nazwa przedmiotu Podstawy modelowania programów Kod przedmiotu 11.3-WI-INFP-PMP Wydział Kierunek Wydział Informatyki, Elektrotechniki

Bardziej szczegółowo

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp... 11. Podziękowania...

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp... 11. Podziękowania... Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników Spis treúci Wstęp... 11 Podziękowania... 13 O autorach... 15 Robert A. Maksimchuk... 15 Eric J. Naiburg... 15 Przedmowa...

Bardziej szczegółowo

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2 Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy

Bardziej szczegółowo

Krótka Historia. Co to jest NetBeans? Historia. NetBeans Platform NetBeans IDE NetBeans Mobility Pack Zintegrowane moduły. Paczki do NetBeans.

Krótka Historia. Co to jest NetBeans? Historia. NetBeans Platform NetBeans IDE NetBeans Mobility Pack Zintegrowane moduły. Paczki do NetBeans. GRZEGORZ FURDYNA Krótka Historia Co to jest NetBeans? Historia Wersje NetBeans Platform NetBeans IDE NetBeans Mobility Pack Zintegrowane moduły NetBeans Profiler Narzędzie do projektowania GUI Edytor NetBeans

Bardziej szczegółowo

DYNAMICZNE ASPEKTY PROCESÓW BIZNESOWYCH. Wszystkie prawa zastrzeżone

DYNAMICZNE ASPEKTY PROCESÓW BIZNESOWYCH. Wszystkie prawa zastrzeżone DYNAMICZNE ASPEKTY PROCESÓW BIZNESOWYCH TOMASZ GZIK WPROWADZENIE 1 Dlaczego mówi się o dynamicznych procesach biznesowych? 2 Co się o nich mówi? 3 Definicje 3 Dynamiczne aspekty procesów 4 Kierunki rozwoju

Bardziej szczegółowo

Zdalne monitorowanie i zarządzanie urządzeniami sieciowymi

Zdalne monitorowanie i zarządzanie urządzeniami sieciowymi Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Infomatyki Stosowanej Piotr Benetkiewicz Nr albumu: 168455 Praca magisterska na kierunku Informatyka

Bardziej szczegółowo

Architektura oprogramowania w praktyce. Wydanie II.

Architektura oprogramowania w praktyce. Wydanie II. Architektura oprogramowania w praktyce. Wydanie II. Autorzy: Len Bass, Paul Clements, Rick Kazman Twórz doskonałe projekty architektoniczne oprogramowania! Czym charakteryzuje się dobra architektura oprogramowania?

Bardziej szczegółowo

System zarządzający grami programistycznymi Meridius

System zarządzający grami programistycznymi Meridius System zarządzający grami programistycznymi Meridius Instytut Informatyki, Uniwersytet Wrocławski 20 września 2011 Promotor: prof. Krzysztof Loryś Gry komputerowe a programistyczne Gry komputerowe Z punktu

Bardziej szczegółowo

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:

Bardziej szczegółowo

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH Przygotował: mgr inż. Radosław Adamus Wprowadzenie: W procesie definiowania wymagań dla systemu tworzyliśmy Model Przypadków

Bardziej szczegółowo

DLA SEKTORA INFORMATYCZNEGO W POLSCE

DLA SEKTORA INFORMATYCZNEGO W POLSCE DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej

Bardziej szczegółowo

AUREA BPM HP Software. TECNA Sp. z o.o. Strona 1 z 7

AUREA BPM HP Software. TECNA Sp. z o.o. Strona 1 z 7 AUREA BPM HP Software TECNA Sp. z o.o. Strona 1 z 7 HP APPLICATION LIFECYCLE MANAGEMENT Oprogramowanie Application Lifecycle Management (ALM, Zarządzanie Cyklem życia aplikacji) wspomaga utrzymanie kontroli

Bardziej szczegółowo

REFERAT PRACY DYPLOMOWEJ

REFERAT PRACY DYPLOMOWEJ REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany

Bardziej szczegółowo

OSGi Agata Hejmej 4.05.2009

OSGi Agata Hejmej 4.05.2009 OSGi Agata Hejmej 4.05.2009 Plan prezentacji Co to jest OSGi Jakie problemy rozwiązuje Opis standardu Przykładowa aplikacja Podsumowanie korzyści Co to jest OSGi? Standard, który pozwala na tworzenie wysoce

Bardziej szczegółowo

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski INFORMATYKA W ZARZĄDZANIU Wykład VI dr Jan Kazimirski jankazim@mac.edu.pl http://www.mac.edu.pl/jankazim MODELOWANIE SYSTEMÓW UML Literatura Joseph Schmuller UML dla każdego, Helion 2001 Perdita Stevens

Bardziej szczegółowo

STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe

STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe Technologie informacyjne prof. dr hab. Zdzisław Szyjewski 1. Rola i zadania systemu operacyjnego 2. Zarządzanie pamięcią komputera 3. Zarządzanie danymi

Bardziej szczegółowo

Podstawy modelowania biznesowego w inżynierii oprogramowania

Podstawy modelowania biznesowego w inżynierii oprogramowania Podstawy modelowania biznesowego w inżynierii oprogramowania 1. Rola modelowania biznesowego w inżynierii oprogramowania 2. Przegląd notacji (BPMN, UML w zast. biznesowym) 3. Powiązania modeli biznesowych

Bardziej szczegółowo

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Wersja: 1.0 17.06.2015 r. Wstęp W dokumencie przedstawiono skróconą wersję pryncypiów architektury korporacyjnej podmiotów publicznych.

Bardziej szczegółowo

Technologie informacyjne - wykład 12 -

Technologie informacyjne - wykład 12 - Zakład Fizyki Budowli i Komputerowych Metod Projektowania Instytut Budownictwa Wydział Budownictwa Lądowego i Wodnego Politechnika Wrocławska Technologie informacyjne - wykład 12 - Prowadzący: Dmochowski

Bardziej szczegółowo

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use

Bardziej szczegółowo

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Jerzy Brzeziński, Anna Kobusińska, Dariusz Wawrzyniak Instytut Informatyki Politechnika Poznańska Plan prezentacji 1 Architektura

Bardziej szczegółowo

UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne.

UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne. 45. UML, jego struktura i przeznaczenie. Przeznaczenie UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne. Pozwala obrazować, specyfikować, tworzyć

Bardziej szczegółowo

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki Dariusz Brzeziński Politechnika Poznańska, Instytut Informatyki Język programowania prosty bezpieczny zorientowany obiektowo wielowątkowy rozproszony przenaszalny interpretowany dynamiczny wydajny Platforma

Bardziej szczegółowo

koniec punkt zatrzymania przepływów sterowania na diagramie czynności

koniec punkt zatrzymania przepływów sterowania na diagramie czynności Diagramy czynności opisują dynamikę systemu, graficzne przedstawienie uszeregowania działań obrazuje strumień wykonywanych czynności z ich pomocą modeluje się: - scenariusze przypadków użycia, - procesy

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE WYKŁAD ĆWICZENIA LABORATORIUM PROJEKT SEMINARIUM

PRZEWODNIK PO PRZEDMIOCIE WYKŁAD ĆWICZENIA LABORATORIUM PROJEKT SEMINARIUM Politechnika Częstochowska, Wydział Zarządzania PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu Kierunek Forma studiów Poziom kwalifikacji Rok Semestr Jednostka prowadząca Osoba sporządzająca Profil Rodzaj

Bardziej szczegółowo

Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Opracował Jan T. Biernat

Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Opracował Jan T. Biernat Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Program, to lista poleceń zapisana w jednym języku programowania zgodnie z obowiązującymi w nim zasadami. Celem programu jest przetwarzanie

Bardziej szczegółowo

Historia modeli programowania

Historia modeli programowania Języki Programowania na Platformie.NET http://kaims.eti.pg.edu.pl/ goluch/ goluch@eti.pg.edu.pl Maszyny z wbudowanym oprogramowaniem Maszyny z wbudowanym oprogramowaniem automatyczne rozwiązywanie problemu

Bardziej szczegółowo

Zaawansowane programowanie w języku C++

Zaawansowane programowanie w języku C++ Kod szkolenia: Tytuł szkolenia: C/ADV Zaawansowane programowanie w języku C++ Dni: 3 Opis: Uczestnicy szkolenia zapoznają się z metodami wytwarzania oprogramowania z użyciem zaawansowanych mechanizmów

Bardziej szczegółowo

ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO W RAMACH PROJEKTU

ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO W RAMACH PROJEKTU Projekt Rozwój elektronicznej administracji w samorządach województwa mazowieckiego wspomagającej niwelowanie dwudzielności potencjału województwa ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO

Bardziej szczegółowo

Dotacje na innowacje. Inwestujemy w waszą przyszłość.

Dotacje na innowacje. Inwestujemy w waszą przyszłość. PROJEKT TECHNICZNY Implementacja Systemu B2B w firmie Lancelot i w przedsiębiorstwach partnerskich Przygotowane dla: Przygotowane przez: Lancelot Marek Cieśla Grzegorz Witkowski Constant Improvement Szkolenia

Bardziej szczegółowo

Informatyczne fundamenty

Informatyczne fundamenty Informatyczne fundamenty Informatyka to szeroka dziedzina wiedzy i praktycznych umiejętności. Na naszych studiach zapewniamy solidną podstawę kształcenia dla profesjonalnego inżyniera IT. Bez względu na

Bardziej szczegółowo

Programowanie współbieżne i rozproszone

Programowanie współbieżne i rozproszone Programowanie współbieżne i rozproszone WYKŁAD 11 dr inż. CORBA CORBA (Common Object Request Broker Architecture) standard programowania rozproszonego zaproponowany przez OMG (Object Management Group)

Bardziej szczegółowo

Nowości oraz trendy w obszarze BPM nurty i kierunki rozwoju. Jarosław Żeliński analityk biznesowy, projektant systemów

Nowości oraz trendy w obszarze BPM nurty i kierunki rozwoju. Jarosław Żeliński analityk biznesowy, projektant systemów Nowości oraz trendy w obszarze BPM nurty i kierunki rozwoju Jarosław Żeliński analityk biznesowy, projektant systemów O mnie qod 1991 roku w branży IT i zarządzania jako analityk projektant rozwiązań qod

Bardziej szczegółowo

DSL w środowisku Eclipse. Grzegorz Białek Architekt techniczny, Sygnity S.A.

DSL w środowisku Eclipse. Grzegorz Białek Architekt techniczny, Sygnity S.A. DSL w środowisku Eclipse Grzegorz Białek Architekt techniczny, Sygnity S.A. Agenda Wstęp do tematu (10 min) Sens tworzenia języków biznesowych UML jako język biznesu? Zintegrowane środowisko deweloperskie

Bardziej szczegółowo

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus Automatyzacja procesów biznesowych Andrzej Sobecki ESB Enterprise service bus Plan prezentacji Zdefiniowanie problemu Możliwe rozwiązania Cechy ESB JBI Normalizacja wiadomości w JBI Agile ESB Apache ServiceMix

Bardziej szczegółowo

Czym jest Java? Rozumiana jako środowisko do uruchamiania programów Platforma software owa

Czym jest Java? Rozumiana jako środowisko do uruchamiania programów Platforma software owa 1 Java Wprowadzenie 2 Czym jest Java? Język programowania prosty zorientowany obiektowo rozproszony interpretowany wydajny Platforma bezpieczny wielowątkowy przenaszalny dynamiczny Rozumiana jako środowisko

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych

Modelowanie i analiza systemów informatycznych Katolicki Uniwersytet Lubelski Jana Pawła II Wydział Matematyki, Informatyki i Architektury Krajobrazu Modelowanie i analiza systemów informatycznych ćwiczenia informacja wstępna dr Viktor Melnyk, prof.

Bardziej szczegółowo

Web frameworks do budowy aplikacji zgodnych z J2EE

Web frameworks do budowy aplikacji zgodnych z J2EE Web frameworks do budowy aplikacji zgodnych z J2EE Jacek Panachida promotor: dr Dariusz Król Przypomnienie Celem pracy jest porównanie wybranych szkieletów programistycznych o otwartym kodzie źródłowym

Bardziej szczegółowo

Projektowanie Modeli Usług dla rozwiązań typu SOA

Projektowanie Modeli Usług dla rozwiązań typu SOA Projektowanie Modeli Usług dla rozwiązań typu SOA Service Oriented Modeling and Architecture (SOMA ) IBM Global Business Services, zdefiniował zestaw usług konsultingowych oraz narzędzi pomagających organizacjom

Bardziej szczegółowo

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek TECHNOLOGIE OBIEKTOWE WYKŁAD 2 Anna Mroczek 2 Diagram czynności Czym jest diagram czynności? 3 Diagram czynności (tak jak to definiuje język UML), stanowi graficzną reprezentację przepływu kontroli. 4

Bardziej szczegółowo

Korporacyjna Magistrala Usług na przykładzie Oracle Service Bus

Korporacyjna Magistrala Usług na przykładzie Oracle Service Bus Kod szkolenia: Tytuł szkolenia: ESB/OSB Korporacyjna Magistrala Usług na przykładzie Oracle Service Bus Dni: 3 Opis: Adresaci szkolenia Szkolenie adresowane jest do programistów Java, analityków systemowych

Bardziej szczegółowo

Diagram przypadków użycia

Diagram przypadków użycia Diagram przypadków użycia Diagram przypadków użycia opisuje system z punktu widzenia użytkownika, pokazuje, co robi system, a nie jak to robi. Diagram ten sam w sobie zazwyczaj nie daje nam zbyt wielu

Bardziej szczegółowo

I. Opis przedmiotu zamówienia

I. Opis przedmiotu zamówienia I. Opis przedmiotu zamówienia Przedmiotem zamówienia jest świadczenie usług z zakresu zapewnienia zasobów ludzkich z branży IT przez okres 12 miesięcy od dnia zawarcia umowy ramowej, polegających na zapewnieniu

Bardziej szczegółowo

Inżynieria oprogramowania

Inżynieria oprogramowania Inżynieria oprogramowania Wykład 8 Inżynieria wymagań: analiza przypadków użycia a diagram czynności Patrz: Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język UML 2.0 w modelowaniu systemów

Bardziej szczegółowo

Wdrożenie technologii procesowej IBM BPM w EFL

Wdrożenie technologii procesowej IBM BPM w EFL Wdrożenie technologii procesowej IBM BPM w EFL Marcin Naliwajko Z-ca dyrektora Departamentu Technologii Dominik Lisowski Starszy Architekt Systemów IT Grupy EFL WebSphere Message Broker 2008 r. Wdrożenie

Bardziej szczegółowo

BPMN- BUSINESS PROCESS MODELING NOTATION Narzędzie tworzenia metamodeli procesów biznesowych. Diagram moŝe e być zmieniany na kaŝdym etapie Ŝycia procesu: od stworzenia, poprzez rozwój, wykonanie, monitorowanie

Bardziej szczegółowo

Czym jest jpalio? jpalio jpalio jpalio jpalio jpalio jpalio jpalio jpalio

Czym jest jpalio? jpalio jpalio jpalio jpalio jpalio jpalio jpalio jpalio Czym jest jpalio? jpalio to unikalna platforma technologiczna pozwalająca na stworzenie szeregu produktów dostosowanych do indywidualnych preferencji klienta. W naszej ofercie znajduje się m.in. system

Bardziej szczegółowo

INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE

INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE Studia podyplomowe dla nauczycieli INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE Przedmiot JĘZYKI PROGRAMOWANIA DEFINICJE I PODSTAWOWE POJĘCIA Autor mgr Sławomir Ciernicki 1/7 Aby

Bardziej szczegółowo

Dokumentacja projektu QUAIKE Architektura oprogramowania

Dokumentacja projektu QUAIKE Architektura oprogramowania Licencjacka Pracownia Oprogramowania Instytut Informatyki Uniwersytetu Wrocławskiego Jakub Kowalski, Andrzej Pilarczyk, Marek Kembrowski, Bartłomiej Gałkowski Dokumentacja projektu QUAIKE Architektura

Bardziej szczegółowo

Inżynieria oprogramowania. Jan Magott

Inżynieria oprogramowania. Jan Magott Inżynieria oprogramowania Jan Magott Literatura do języka UML G. Booch, J. Rumbaugh, I. Jacobson, UML przewodnik użytkownika, Seria Inżynieria oprogramowania, WNT, 2001, 2002. M. Fowler, UML w kropelce,

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.

Bardziej szczegółowo

Modelowanie procesów biznesowych, przepływu pracy oraz reguł biznesowych na przykładzie Drools i jbpm lub Activiti

Modelowanie procesów biznesowych, przepływu pracy oraz reguł biznesowych na przykładzie Drools i jbpm lub Activiti Kod szkolenia: Tytuł szkolenia: BPMR Modelowanie procesów biznesowych, przepływu pracy oraz reguł biznesowych na przykładzie Drools i jbpm lub Activiti Dni: 5 Opis: Adresaci Szkolenia: Szkolenie adresowane

Bardziej szczegółowo

Projektowanie systemów informatycznych. wykład 6

Projektowanie systemów informatycznych. wykład 6 Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany

Bardziej szczegółowo

Kontrola spójności modeli UML za pomocą modelu. Stanisław Jerzy Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Kontrola spójności modeli UML za pomocą modelu. Stanisław Jerzy Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Kontrola spójności modeli UML za pomocą modelu przestrzennego DOD Stanisław Jerzy Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Obecne metody kontroli spójności modeli

Bardziej szczegółowo

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla nauczyciela

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla nauczyciela Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram

Bardziej szczegółowo

omnia.pl, ul. Kraszewskiego 62A, 37-500 Jarosław, tel. +48 16 621 58 10 www.omnia.pl kontakt@omnia.pl

omnia.pl, ul. Kraszewskiego 62A, 37-500 Jarosław, tel. +48 16 621 58 10 www.omnia.pl kontakt@omnia.pl .firma Dostarczamy profesjonalne usługi oparte o nowoczesne technologie internetowe Na wstępie Wszystko dla naszych Klientów Jesteśmy świadomi, że strona internetowa to niezastąpione źródło informacji,

Bardziej szczegółowo

Egzamin / zaliczenie na ocenę*

Egzamin / zaliczenie na ocenę* WYDZIAŁ PODSTAWOWYCH PROBLEMÓW TECHNIKI Zał. nr 4 do ZW33/01 KARTA PRZEDMIOTU Nazwa w języku polskim : INŻYNIERIA OPROGRAMOWANIA Nazwa w języku angielskim: SOFTWARE ENGINEERING Kierunek studiów (jeśli

Bardziej szczegółowo