}w!"#$%&'()+,-./012345<ya

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w!"#$%&'()+,-./012345<ya Procesní řízení v e-learningu DIPLOMOVÁ PRÁCE Bc. Daniel Tovarňák Brno, leden 2011

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: Mgr. Jiří Kolář ii

3 Poděkování Tímto bych rád poděkoval své rodině za projevenou trpělivost a nekonečnou podporu při tvorbě této práce, stejně jako po celou dobu studia. Zároveň bych chtěl poděkovat mému vedoucímu Mgr. Jiřímu Kolářovi za poskytnutí mnoha věcných rad a připomínek, nejen v souvislosti s touto prací. V neposlední řadě také děkuji všem odborníkům a kolegům z Fakulty informatiky Masarykovy univerzity, jež byli ochotni předat mi své znalosti a zkušenosti. Dík patří také všem mým dobrým přátelům. iii

4 Shrnutí Tato diplomová práce se zabývá možnostmi využití principů procesního řízení (Business Process Management) v kontextu elektronické výuky, přičemž klade důraz především na technologický aspekt věci. Práce dále čtenáře seznamuje s moderními technologiemi z oblasti procesního řízení a blíže se zaměřuje na standard BPMN 2.0. Praktickou část práce tvoří prototyp nástroje na podporu výuky založený na procesech. Práce je řešena v rámci projektu MEDUSY. iv

5 Klíčová slova procesní řízení, procesy, e-learning, elektronická výuka, Business Process Management, životní cyklus BPM, Activiti BPM, Spring, Ruby on Rails, JRuby, BPM, BPMN 2.0, MEDUSY v

6 Obsah 1 Úvod Moderní e-learning Blended learning Motivace pro použití procesního řízení Procesy Cíle práce Procesní řízení a e-learning Procesní řízení (Business Process Management) Dva světy Procesní řízení z manažerského pohledu Procesní řízení jako SWE Proces (podnikový proces, business process) Životní cyklus BPM Definice (Definition) Modelování (Modeling) Spuštění (Execution) Monitoring Optimalizace (Optimization) Procesní řízení a e-learning Procesy ve výuce Přínosy automatizace Nepřímé efekty na kvalitu výuky Přímé efekty na kvalitu výuky Výukové (Pedagogické) vzory Vzor Fixer Upper [5] Životní cyklus BPM v elektronické výuce Návrh Modelování Spuštění Monitoring Optimalizace Projekt MEDUSY Cíle a úkoly projektu Technologie Definice Use Case diagram (UML) Activity diagram (UML) Modelování BPMN Elementy BPD vi

7 3.2.2 XPDL Spuštění BPEL Od BPMN ke spuštění Ruční převod Mapování Důsledky Monitoring a optimalizace BPMN Meta-model Další změny Diagram kolaborace Diagram konverzace Choreografie BPEL Mapování Důsledky Základní elementy BPMN Aktivity (Activities) Události (Events) Typy událostí Tok procesu (Sequence flow) Brány (Gateways) Exclusive Gateway Parallel Gateway Inclusive Gateway Event-based Gateway Bazény a plavecké dráhy (Pools and Swimlanes) Plavecké dráhy BPM software Procesní engine Apache ODE (Apache License v2) jbpm (LGPL) BPMS Bonita Open Solution Intalio BPMS Activiti BPM Activiti BPM Activiti BPM Engine Process Virtual Machine Programové api Konfigurační soubor Přístup ke komponentám vii

8 4.1.3 Persistence Workflow REST API Komponenta Příklad požadavku Spring Podpora BPMN Příklady None Start Event Conditional Sequence Flow Script Task User Task (Java) Service Task Procesní engine detailněji Proměnné Výrazy Formuláře Interní rendering Externí rendering Příklad Service Task (servicetask) Modelový proces kurzu Communication and Soft Skills Kurz Softskills Návrh procesu Role Potřebné komponenty Základní aktivity Stručný scénář kurzu Modelování procesu Poznámky k procesu Set up Course Enrollment & Import students Team bulding Team session Photos Perform assessment Invite members Implementace procesu Nástroj na podporu výuky Použité technologie Ruby on Rails JRuby Architektura viii

9 6.2.1 Implementační zkratky Role Uživatelské formuláře Moduly Process Engine User Management Topics & Teams Picasa albums My Team (Teamspace) Course Space Feedbacks Monitoring Shrnutí Technologie Podpůrná funkcionalita Interoperabilita Autentizace a správa uživatelů Uživatelské úkoly a formuláře Podpora více kurzů a jejich záloha Závěr Literatura a zdroje A Příklad z Kapitoly 4 Activiti Hello World A.1 Prerekvizity pro spuštění A.2 Struktura aplikace A.2.1 Run.java A.2.2 ConsoleReader.java A.2.3 hello-world.bpmn20.xml A.2.4 config.xml A.3 Spuštění B Nástroj na podporu výuky B.1 Prerekvizity pro spuštění B.1.1 Knihovny Ruby (RubyGems) B.1.2 Knihovny Java B.2 Struktura aplikace B.2.1 Gemfile B.2.2./app B.2.3./config B.2.4./db B.2.5./doc B.2.6./lib B.2.7./public B.2.8./resources ix

10 B.2.9./script B.2.10./test B.2.11./vendor B.2.12./WEB-INF B.3 Spuštění B.4 Online ukázka C Implementace procesu Softskills C.1 Procesní definice C.2 Uživatelské třídy x

11 Kapitola 1 Úvod Vzdělání není pouhým nashromážděním jednotlivých vědomostí, jako těstem není mouka, voda, sůl, kvasnice a tak dále, dohromady naházené. 1.1 Moderní e-learning Tomáš G. Masaryk Současné e-learningové 1 nástroje dnes již velmi úspěšně zvládají klasické paradigma výuky, tj. poměrně jednostranný tok informací ve směru Lektor Student a následné hodnocení studenta v závislosti na zvládnutí látky. Díky masivnímu nástupu webových technologií a fenoménu Web mohou moderní nástroje poskytnout prostředky pro zpětnou vazbu studentů, jejich vzájemnou kolaboraci, či spolupráci na obsahu výuky (chaty, diskuse, wiki, osobní blogy atd.) v duchu Personcentered learning. Pro takovéto spojení elektronické výuky a principů Web 2.0 je někdy trefně používán výraz E-learning 2.0. Výzkumy naznačují, že kvalitně zvládnutý e-learning může být v některých případech (záleží to ovšem na mnoha faktorech) dokonce efektivnější, než prezenční výuka a ve většině případů dosahuje alespoň stejné, nebo jen nepatrně horší výsledky, jako konvenční forma výuky (face-to-face). [1] Výhody elektronické výuky 24/7 přístup k učivu možnost volby vlastního tempa výuky přístup k více kurzům z jednoho místa přístup ke kurzu z více míst (domov, kancelář) monitoring postupu (progress monitoring) 1. Pojmem e-learning máme na mysli i mnohá synonyma (v současné době), jako například: Computer-Based Learning, Web-Based Learning, Online learning atd. 2. Termínem Web 2.0 se označuje moderní internetová aplikace, založená především na principu RIA (Rich Internet Application) a obsahu generovaném uživateli. Více naleznete například na < org/wiki/web_2.0> 1

12 1.2. BLENDED LEARNING Výhody prezenční výuky okamžitá zpětná vazba lidský kontakt budování soft-skills využití osobnosti lektora Není pochyb o tom, že oba světy mají své výhody i nevýhody, lze pochopit, že kontakt s živým člověkem je v některých situacích nenahraditelný, a naopak výuka založená na ICT nese obrovský potenciál v manipulaci a prezentaci informací. Je tedy přirozené, chtít spojit oba světy dohromady, potom hovoříme o tzv. blended learningu. Již zmíněná studie velmi pozitivně hodnotí jak výsledky kombinované výuky (blended), tak elektronické výuky důsledně řízené lektorem. [1] 1.2 Blended learning Blended learning 3 (BL) spojuje různá výuková prostředí a metody a dává tak lektorům i studentům možnost dosahovat lepších výsledků. Studenti se mohou mnohem aktivněji zapojovat do procesu a obsahu výuky a spolupracovat s lektorem, jež naopak získává potřebnou odezvu. Jednoduchým příkladem BL budiž smyšlený kurz, který kombinuje prezenční, dálkovou (distanční) a elektronickou výuku: Studenti se účastní vybraných přednášek a navíc využívají videopřenosů. K dispozici mají také tištěná skripta určená k samostudiu. S případnými dotazy a problémy se mohou obrátit na diskusní fórum. Svoje znalosti si navíc mohou prohloubit a procvičit v e-learning systému. DISTANT FACE-TO-FACE E-LEARNING Obrázek 1.1: Blended learning 3. z angličtiny blend = míchat, mixovat 2

13 1.3 Motivace pro použití procesního řízení 1.3. MOTIVACE PRO POUŽITÍ PROCESNÍHO ŘÍZENÍ Zatím jsme vesměs uvedli přínosy jednotlivých typů výuky pouze z pohledu studenta, je však třeba zohlednit i druhou stranu mince. Úspěšně zvládnout a vytvořit kvalitní edukativní prostředí založené na BL (ale i čistě na e-learningu) klade na lektora (resp. lektorský tým) velké časové a organizační nároky. Mnoho e-learningových a ICT nástrojů některé z úkolů automatizuje a ulehčuje (přiřazení studentů ke kurzu, hromadné zprávy, interaktivní osnovy), jsou-li však používány ad-hoc a bez nějakého řádu, často není dosaženo kýženého efektu. Při spolupráci více lidí (lektoři, cvičící, asistenti) navíc vzniká další entropie Procesy Zavedení rolí, definice jasných pravidel, postupů, opakovatelných procesů a některých principů procesního řízení, může přispět k vytvoření uceleného výukového prostředí, což s sebou, mimo jiné, přináší několik výhod: refaktoring a optimalizace procesů monitoring formalizace edukačních principů a postupů V tomto místě je třeba zdůraznit, že efektivní použití procesů by vždy měla také provázet vhodná metodika pro jejich řízení právě toto je i v našem případě důvod pro zaměření na principy procesního řízení (Business Process Management) jako celku. 1.4 Cíle práce S ohledem na výše uvedené fakty konstatujme, že mezi cíle této práce patří: Seznámit čtenáře s důvody a principy zavedení procesního řízení v obecné rovině a následně diskutovat použití těchto principů v prostředí elektronické výuky. Představit současné moderní technologie a postupy, jež se v tomto kontextu objevují náš hlavní zájem bude směřovat zejména k možnostem standardu BPMN 2.0 (s důrazem na automatizaci procesů). Praktickým těžištěm práce bude vývoj procesně orientovaného nástroje na podporu výuky. Aplikace bude sloužit především jako tzv. proof-of-concept ideje použití procesů ve výuce. Vzniknuvší zkušenosti, postupy a problémy budou zdokumentovány a dále zohledněny v rámci open-source projektu MEDUSY. 3

14 Kapitola 2 Procesní řízení a e-learning V této kapitole nejdříve vymezíme základní pojmy a principy procesního řízení a uvedeme motivaci pro jeho zavedení. Představíme si životní cyklus procesního řízení a detailněji popíšeme jednotlivé etapy. Poté budeme diskutovat možnosti BPM ve vztahu k elektronické výuce. Na závěr si krátce představíme projekt MEDUSY, v jehož rámci je řešena tato práce. 2.1 Procesní řízení (Business Process Management) Procesní řízení je evolucí předchozích přístupů k zavedení a řízení procesů v rámci podnikání. Máme na mysli moderní pojetí procesu v rozmezí posledního čtvrt století ač tento pojem rozhodně nebyl neznámý, teprve v 80. letech minulého století začal být proces v širší míře vnímán jako výrazné aktivum organizace a zároveň prostředek ke zvýšení kvality služeb, a tím i zlepšení pozice na trhu Six Sigma 1990 Business Process Reengineering Total Quality Management Business Process Management Obrázek 2.1: Historický kontext procesního řízení Společným jmenovatelem všech metodik (včetně procesního řízení) a zároveň motivací pro zavedení a řízení procesů je naplnění těchto faktorů: vyšší kvalita služeb lepší flexibilita 4

15 zvýšení konkurenceschopnosti zlepšování procesů kontrola procesů 2.1. PROCESNÍ ŘÍZENÍ (BUSINESS PROCESS MANAGEMENT) Obrázek 2.2: Dva aspekty procesního řízení < Dva světy Důležitým faktem je, že na pojem procesního řízení se lze vždy dívat ze dvou úhlů. Jednak jako na manažerskou disciplínu, a jednak jako na oblast softwarového inženýrství (SWE). Hranice (a její překonání) těchto dvou odlišných aspektů procesního řízení je již od počátku předmětem mnoha diskusí. Jde zejména o plynulost přechodu mezi oběma světy zneviditelnění této hranice, chcete-li Procesní řízení z manažerského pohledu Jedná se o manažerskou disciplínu, založenou na kontinuálním vylepšování (podnikových) procesů, za účelem dosažení specifických (obchodních) cílů. [2] Hlavním předmětem zájmu jsou podnikové procesy, jejich kvalita, efektivita, vyspělost a zároveň dopad na fungování organizace a její strukturu. Orientace na lidi je velkým rozdílem oproti předchozím přístupům k řízení procesů (např. Business Process Reengineering) Procesní řízení jako SWE Jedná se o sadu ICT nástrojů, SWE postupů a metodik, použitých převážně k naplnění cílů jednotlivých etap takzvaného životního cyklu BPM (viz sekce 2.1.3) a cílů BPM jako tako- 5

16 2.1. PROCESNÍ ŘÍZENÍ (BUSINESS PROCESS MANAGEMENT) vého. Tato práce se procesním řízením zabývá převážně jako oblastí softwarového inženýrství. Již zmiňovaný BPR byl zaměřen právě na tento aspekt řízení procesů, bohužel až přespříliš Proces (podnikový proces, business process) Proces je sled aktivit a úkolů s definovaným začátkem a koncem, navržený za účelem vytvoření specifického produktu, nebo služby, s ohledem na strukturu a cíle organizace. [3] Procesy mohou být vnořovány do sebe, potom hovoříme o tzv. pod-procesech. Procesy jsou někdy rozděleny do dvou skupin podle funkce, kterou vykonávají: Hlavní procesy naplňují primární cíle podnikání. Jsou vybudovány na základě knowhow a zkušeností. Kvalitní proces poskytuje přidanou hodnotu a může přinést náskok před konkurencí (competitive advantage). Podpůrné procesy, jak již název napovídá, poskytují dodatečnou podporu pro hlavní procesy. Podpůrné procesy mohou výrazně ovlivnit výsledný výkon a efektivitu hlavního procesu. business process Rejected Send invoice Accept payment Order Accepted Fill order Close order Recieve order request Ship order Obrázek 2.3: Business proces Životní cyklus BPM Životním cyklem BPM se označuje soubor etap, jimiž v procesním řízení prochází každý proces (nebo skupina procesů). První etapa navazuje na etapu poslední a vytváří tak nekonečný (iterativní) cyklus. Každá etapa zahrnuje různý poměr již zmiňovaných aspektů BPM, zároveň může mít svůj vlastní vývojový cyklus, či metodiku. Je jednoduché si představit, že 6 Daniel Tovarnak 1 of 1

17 2.1. PROCESNÍ ŘÍZENÍ (BUSINESS PROCESS MANAGEMENT) například u Spuštění to bude nějaká metodika SWE. Jednotlivé fáze a jejich počet se napříč dostupnými zdroji jemně liší, uved me tedy jistou společnou množinu Definice (Definition) V první etapě jsou analyzovány a identifikovány existující (reálné) procesy, včetně určení vztahů a rolí participujících v procesu. Jedná se v podstatě o kombinaci zachycení požadavků, analýzy a prvotního návrhu, tak jak je známe ze SWE. Definování procesu je většinou kompetencí vlastníka procesu a business analytika. Běžným výstupem bývá obyčejný strukturovaný text. V pokročilejších fázích může dojít na vývojové diagramy (flowcharts), či jiné prostředky pro formalizaci toku procesu. Definition Optimization Business Process Management Modeling Monitoring Execution Obrázek 2.4: Životní cyklus BPM Modelování (Modeling) Modelování zahrnuje vytvoření posloupnosti aktivit a úkolů na základě požadavků vlastníka procesu a výstupu prvotního návrhu. V praxi je výstupem procesní model srozumitelný pro většinu aktérů soubor diagramů v nějaké procesní notaci. Součástí modelování mohou být i simulace a testování procesu. Na modelu spolupracuje vlastník procesu spolu s analytikem zkušeným v dané oblasti. Modelováním se zabývá například oblast softwarového inženýrství nazývaná Business Process Modeling Spuštění (Execution) Úkolem této fáze je převod procesního modelu do spustitelné formy, respektive vykonání takových kroků a implementačních prací, které povedou ke spuštění procesu v akceptovatelné formě, včetně nasazení a administrace. Tato etapa je v kompetenci IT odborníků ve spolupráci s ostatními aktéry. 7

18 2.2. PROCESNÍ ŘÍZENÍ A E-LEARNING Monitoring Úkolem monitoringu je sběr a dat sledování dat za účelem vyhodnocení běhu procesu. Jedná se například o monitoring výkonu, sledování statistik a identifikaci případných problémů a defektů vzniklých v předchozích etapách. Toto není Business Activity Monitoring Optimalizace (Optimization) V této etapě jsou vyhodnocena všechna data z předchozích fází a vyvozeny potřebné závěry vedoucí k případnému zvýšení efektivity procesu. Na základě výstupů z optimalizace začíná nová iterace životního cyklu a tyto výstupy jsou zohledněny v příslušných fázích. 2.2 Procesní řízení a e-learning Procesní řízení nemusí vždy přímo souviset s podnikovou sférou (v tomto může být anglický ekvivalent poněkud zavádějící). Jelikož však mají procesy a procesní řízení kořeny zejména v enterprise sféře, lze se s tímto označením setkat i v jiných ( ne-podnikových ) oblastech. V takových případech je většinou procesní řízení zaměřeno převážně na svůj technologický aspekt a manažerská část je zásadně ovlivněna cílovou doménou. Toto je v podstatě i případ BPM v elektronické výuce Procesy ve výuce Lze se shodnout na tom, že výuka samotná je proces. Rozdělení a podoba procesů v e- learningu v podstatě odpovídá situaci z klasického BPM, pouze s drobnými specifiky. Vlastníkem procesu je v tomto případě většinou lektor. Hlavní procesy (Výukové procesy) výukový proces je sled aktivit a událostí tvořící náplň, či cíl výuky. Ve spojení s časovým ohodnocením tvoří výukový proces plán výuky. Nalezení výukových procesů je předmětem empirického zkoumání, resp. pedagogickým problémem. Podpůrné procesy se podílí na tvorbě a správě výukového prostředí a stejně tak, jako v klasickém případě, poskytují doplňkovou funkcionalitu pro procesy hlavní Přínosy automatizace V podnikové sféře vede zavedení BPM k jasnému cíli snížení nákladů a zvýšení zisku. U elektronické výuky bychom tímto cílem mohli označit vyšší efektivitu a kvalitu vzdělání. Zavedení procesů (a zejména jejich automatizace) by se na kvalitu výuky mělo promítnout jako kombinace přímých a nepřímých efektů. 8

19 2.2. PROCESNÍ ŘÍZENÍ A E-LEARNING Nepřímé efekty na kvalitu výuky Snížení počtu administrativních úkonů, jejich automatizace a podpora týmové spolupráce v lektorském týmu vede k rovnoměrnému rozdělení povinností a kompetencí lektor má více času na přípravu náplně výuky. Zejména u blended learningu může být časová úspora netriviální. Okamžitý přehled o stavu situace, splněných a nesplněných úkolech lektorský tým má možnost pružně reagovat na danou situaci. Možnost kontinuálního vyhodnocování úspěšnosti a následného vylepšování daného výukového procesu Přímé efekty na kvalitu výuky Student má jasně definované úkoly a povinnosti včetně časového horizontu podpora kontinuální práce a zátěže studenta. Možnost okamžitého srovnání s ostatními studenty v situaci, kdy je to žádoucí pozitivní motivace. Možnost využití sofistikovaných služeb a nástrojů, zejména pro technologicky zaměřené kurzy. Jednodušší sdílení informací a vědomostní báze mezi různými výukovými prostředími Výukové (Pedagogické) vzory Řekli jsme, že nalezení výukových procesů je pedagogickým problémem každý kurz, či přednášená problematika vyžaduje odlišný přístup. Tomuto tématu se mimo jiné věnuje projekt Pedagogical patterns [4] soubor pedagogických vzorů a postupů pro různou množinu problémů (zejména v technických kurzech). Použití pedagogických vzorů může v mnohém zjednodušit tvorbu i optimalizaci výukových procesů a zároveň zkvalitnit výuku z pedagogického hlediska. Naopak formalizace jednotlivých vzorů pomocí procesů může pomoci při následné diskuzi, či opakovaném použití. Pro představu si uved me jeden z těchto vzorů Vzor Fixer Upper [5] Studenti, nebo skupina studentů mají za úkol provést analýzu a opravu 1 chyb v předem připraveném (rozumně velkém) artefaktu (program, návrh) tyto chyby jsou však vytvořeny záměrně. 1. Pojem Fixer Upper označuje v USA nemovitost ve špatném stavu, která je sice obyvatelná, ale vyžaduje mnoho dodatečných stavebních prací a úprav. 9

20 2.2. PROCESNÍ ŘÍZENÍ A E-LEARNING Podnět Studenti často pracují pouze na problémech omezené velikost a složitosti. Často nemusí mít dostatečné zkušenosti pro tvorbu složitějších artefaktů. Problémem bývá také omezený čas. Tento přístup dovoluje studentům bez zahlcení pracovat s velkými artefakty a přiblížit je reálné praxi. Druhým faktorem je práce s chybami obecně studenti při výskytu chyb v jejich vlastní práci často tápou (chybové hlášky, výjimky apod.) Kontext Vzor může být použit v mnoha situacích a v různém rozsahu. Typické použití kurzy programování, výuka analýzy a návrhu. Může být použito také v kurzech zabývajících se problematikou QA. Motivace Studenti musí často nastudovat oblast, jejíž pochopení závisí na znalosti souvisejících témat. Pokud jsou tato témata přednesena postupně, studenti často nevidí důležité souvislosti. Schopnost analyzovat a opravovat chyby také pokulhává. Fixer Upper Analýza a oprava chyb ve velkém artefaktu je v silách většiny studentů, na rozdíl od tvorby takového artefaktu. Studenti si dokážou udělat obrázek o skutečné velikosti a složitosti řešení problémů v praxi. Fixer- Upper - Lector Modify artefact Implement errors Fixer- Upper Lector Pick artefact Introduce artefact Present solution Assessment Fixer- Upper - Student Student Build team Find errors Discussion Obrázek 2.5: Fixer Upper 10

21 2.2. PROCESNÍ ŘÍZENÍ A E-LEARNING Řešení Studenti dostanou k dispozici vcelku velký artefakt v podobě programu, aplikace, či návrhu. Artefakt představuje řešení nějakého problému, ale zatímco je obecně korektní, jsou v něm uměle vytvořeny chyby. Většina z nich je jasně nápadných, některé jsou obtížnější. Úkolem studentů je najít, zdokumentovat a opravit chyby. Dalším úkolem je věnovat pozornost struktuře artefaktu. V konečné fázi následuje diskuze. Důsledky Tento vzor dovoluje studentům aktivně pracovat s velkými artefakty (mnohem většími než by sami dokázali vytvořit). Přínosem jsou také nabyté znalosti potřebné pro hledání chyb. V případě programů mohou studenti narazit na syntaktické i sémantické chyby. V dalších případech se může jednat například o chyby v návrhu atd. Důležitým předpokladem je vysoká kvalita daného artefaktu, včetně dobré dokumentace. Povaha chyb by měla být různorodá, jejich závažnost naopak úměrná znalostem studentů. Úkoly tohoto typu často poskytují živnou půdu pro množství otázek a podporují diskusi mezi studenty Životní cyklus BPM v elektronické výuce Formalizace výuky pomocí procesů je podstatným principem, jež může vést ke kvalitnějšímu vzdělání. Důležitým a nedílným krokem je také adopce celého životního cyklu BPM. Lektor, stejně jako vrcholový manažer, nikdy nebude vytvářet přímo spustitelné procesy, zároveň však představuje důležitou roli při jejich monitorování a optimalizaci. Životní cyklus pro e-learning se od svého ekvivalentu v klasickém BPM liší velmi málo, faktem však je, že se vše děje v obecně menším měřítku a na vývoji procesu spolupracuje méně lidí. Určitým specifikem může být délka celé iterace, a to v závislosti na době, po jakou proces běží většinou celý semestr Návrh Lektor poskytne potřebné informace o kurzu, včetně jednotlivých rolí, kompetencí, aktivit, výstupů a požadavků v podobě scénáře kurzu. Scénář je konzultován s cvičícími, případně návrhářem procesu. Nedílnou součástí je také analýza z pedagogického pohledu Modelování Na základě informací z předchozí etapy je vytvořen procesní model s ohledem na funkce a možnosti výukového prostředí. Model by měl být vytvořen zkušeným členem lektorského týmu. 11

22 2.3. PROJEKT MEDUSY Spuštění Procesní model je převeden do spustitelné formy a do základního výukového systému je případně přidána potřebná funkcionalita Monitoring Proces je monitorován kompetentními rolemi. Použití BAM přináší nesporné množství výhod, zejména ve smyslu kontroly výsledků a chování studentů Optimalizace Běh procesu (kurzu) je vyhodnocen a optimalizován s důrazem na zapojení pedagogických principů. 2.3 Projekt MEDUSY MEDUSY je open-source projekt zaměřený na vývoj moderní platformy pro elektronickou výuku. Hlavním specifikem je procesní orientace systému, zejména v souvislosti s tokem výuky. V současnosti je projekt v rané fázi analýzy a prvotního návrhu. Tato práce představuje případovou studii a proof-of-concept pro využití procesů a procesního řízení v elektronické výuce. Hlavní stránka projektu se nachází na adrese < Cíle a úkoly projektu prostudovat možnosti využití procesního řízení v elektronické výuce vytvořit prostředí pro snadné modelování výukových procesů, jejich správu a monitoring identifikovat časté výukové vzory zavést prostředky a technologie pro komunikaci s externími nástroji a službami vybudovat systém pro podporu blended learningu vývoj infrastruktury pro technické kurzy zejména funkcionalitu pro automatizovanou instalaci a správu virtuálních strojů (Virtuální laboratoře) poskytnout prostředky pro správu multimediálního obsahu vybudovat aktivní komunitu Některé z úkolů jsou v současné době řešeny v rámci dalších závěrečných prací kolegů z Fakulty Informatiky. DP: Modelování výukových procesů (Bc. Jiří Novák) DP: Použití webových služeb v oblasti e-learningu (Bc. Miroslav Baláž) DP: Virtuální laboratoře (Bc. Bohuslav Kabrda) 12

23 2.3. PROJEKT MEDUSY BP: E-learningové CMS a formáty (Bc. Emil Červeňan) BP: E-learningové vzory v kurzech na Masarykově univerzitě (Milan Mužík) System subsystem Test management system Content based LMS User Interface Process orchestration engine Multimedia & streaming Modelling tool Virtual labs LDAP Obrázek 2.6: Prvotní návrh architektury projektu MEDUSY 13

24 Kapitola 3 Technologie Doposud jsme se záměrně bavili o procesním řízení pouze v obecné rovině, řekli jsme si, že jej lze rozdělit na dva aspekty manažerský a technologický. V této kapitole podrobněji rozebereme právě současné technologie a standardy používané v procesním řízení, jakožto v disciplíně SWE. Tato kapitola nemá v úmyslu jakkoliv suplovat technickou dokumentaci, ale pouze podat přehled o jednotlivých technologiích. Dodejme, že předmětem našeho zájmu jsou především technologie spojené s modelováním a spouštěním procesů, ostatní etapy životního cyklu BPM zmíníme pouze okrajově. 3.1 Definice Tato fáze, i přes svou nesmírnou důležitost, používá technologii pouze pro zachycení stavu světa v co nejsrozumitelnější formě. Nalezení a definice procesů je záležitostí zkušeností a zejména znalostí reálných procesů. To, jak kvalitně je analýza spolu s prvotním návrhem provedena, má drtivý dopad na neméně důležitou fázi modelování. Pravdou je, že samotné nalezení procesů je spíše záležitostí metodiky než technologie. Pěkný příklad procesní analýzy lze nalézt například v [6] Use Case diagram (UML) Klasický Use Case diagram se hodí zejména na zachycení rolí, případně zásadní funkcionality procesu. Obrázek 3.1: Use Case Diagram 14

25 3.2. MODELOVÁNÍ Activity diagram (UML) Activity diagram může být použit k prvotnímu namodelování toku procesu. Je dostatečně jednoduchý a výstižný a zároveň má vcelku dobrou expresivitu. Obrázek 3.2: Activity Diagram 3.2 Modelování Procesní model je soubor diagramů v nějaké procesní notaci + specifikace. Použití té, či oné notace může významně ovlivnit jeho kvalitu. Procesní notace musí mít vysokou expresivitu, ale zároveň musí být dostatečně čitelná pro všechny účastníky BPM cyklu. De-facto standardem v procesním modelování je procesní notace BPMN 1.2 (OMG). Více o modelování procesů a procesních notacích (zejména ve vztahu k e-learningu) naleznete v práci kolegy Jiřího Nováka [7] BPMN 1.2 BPMN alias Business Process Modeling Notation je (jak již název napovídá) grafická notace pro modelování podnikových procesů. Výsledkem modelování je Business Process Diagram (BPD). Záměrně zde nezmiňujeme vlastnosti BPMN ve verzi 2.0, jelikož se jedná o tak zásadní revizi, že je jí věnován vlastní oddíl (3.5). Hlavním cílem BPMN je poskytnout notaci, která je snadno čitelná všemi uživateli. Od business analytika, který vytváří prvotní návrhy procesů, přes vývojáře, zodpovědné za implementaci technologie, která tyto procesy bude spouštět, až po manažery, kteří budou tyto procesy řídit a monitorovat. Takto BPMN překlenuje hranici mezi modelováním procesů a jejich implementací. BPMN 1.2 Specifikace [8] 15

26 3.2. MODELOVÁNÍ Elementy BPD Sada elementů BPMN byla navržena tak, aby splnila již několikrát uvedené požadavky snadnou čitelnost a zároveň vysokou expresivitu. Výsledkem je malá množina základních elementů rozdělená do 4 kategorií. S rostoucí komplexitou procesu můžou být do diagramu přidány jemné variace jednotlivých elementů, aniž by to snížilo jeho čitelnost. Jednotlivými konstrukty se budeme blíže zabývat v oddíle o BPMN 2.0, na tomto místě uvedeme pouze zmiňované kategorie elementů: 1. elementy toku (flow objects) definují chování procesu (a) aktivity (b) události (c) brány 2. spojovací elementy (connecting objects) propojují elementy toku s ostatními elementy (a) tok procesu (b) tok zprávy (c) vztah 3. plavecké dráhy (swimlanes) sdružují související elementy používáno zejména pro zachycení rolí (a) bazény (b) dráhy 4. artefakty vyjadřují další informace o procesu a jednotlivých elementech (a) datový objekt (b) skupina (c) anotace XPDL Tato verze specifikace nespecifikuje mechanismy pro výměnu BPMN diagramů. BPMN 1.2 Specifikace [8] XPDL, neboli XML Process Definition Language, je formát zajišt ující přenositelnost BP- MN diagramů mezi různými nástroji a produkty. Formát je odpovědí na fakt, že BPMN elementy jsou dány pouze svojí grafickou reprezentací (tzn. každý nástroj si je ukládá po svém). Současná verze XPDL 2.1 dokáže vyjádřit většinu elementů BPMN verze 1.1, nejedná se však o plné mapování 1:1. Velkým plusem je rozšiřitelnost, výrobci modelovacích nástrojů tak mohou procesní definice obohacovat o vlastní metadata (dokumentace atd.) 16

27 3.3. SPUŠTĚNÍ 3.3 Spuštění V této fázi vyvstává potřeba převést procesní model do spustitelné formy. Výsledkem takovéhoto převodu je procesní definice v nějakém konkrétním jazyce. Taková definice je následně spustitelná v běhovém prostředí daného jazyka (procesní engine). Transformace zahrnuje doplnění modelu o implementační detaily proměnné, algoritmy, nebo například WSDL definice, pokud proces konzumuje nějakou WS-* službu. Spuštěním procesní definice vzniká konkrétní instance procesu BPEL BPEL je jazyk založený na XML, určený k formálnímu popisu business procesů složených z volání Webových služeb (webové služby ve smyslu standardů WS-*). Aktuální verze nese název WS-BPEL 2.0 a je standardem OASIS (Organization for the Advancement of Structured Information Standards). Proces popsaný pomocí BPEL je nasazen do prostředí, které jej následně interpretuje (spouští). [9] BPEL slouží k orchestraci služeb, tedy ke vhodné koordinaci volání jejich jednotlivých operací tak, aby tvořily podnikový proces. Proces je řízen centrálně a služby si nejsou vědomy toho, že jsou jeho součástí. Sám proces je ve výsledku opět službou, může být tedy součástí nějakého procesu vyšší úrovně. V současné době se jedná o nejpoužívanější způsob spouštění procesů. [9] Více detailů o BPEL naleznete například v [10] Od BPMN ke spuštění V oddíle 3.2 jsme uvedli, že BPMN je de-facto standardem v oblasti modelování procesů, je tedy logické, chtít převádět BPMN modely do jazyka BPEL (nebo jiného proprietárního formátu, pro který existuje procesní engine). Avšak transformace grafické notace do XML formátu je přinejmenším problematická. V současnosti se objevují dvě řešení. Oblíbená je však kombinace obou Ruční převod Jak již nadpis napovídá, jedná se o manuální převod BPMN do BPEL. Celý proces je v podstatě namodelován znovu (v proprietární notaci, resp. BPEL), ale s přihlédnutím k implementačním detailům. To, zda budou oba modely vyjadřovat totéž, záleží zejména na schopnostech a zkušenostech developera Mapování BPEL, jakožto XML formát, nemá žádnou konkrétní formu vizualizace. Mnohdy je nahrazován omezenou množinou grafických elementů BPMN. Pro analytika je vytvořena iluze modelování v BPMN, ve skutečnosti jsou však jednotlivé konstrukty v reálném čase mapo- 17

28 3.4. MONITORING A OPTIMALIZACE vány na BPEL. Business analytik a vývojář tedy používají pro popis procesů tentýž jazyk, ale s různou mírou implementačních detailů Důsledky Oba uvedené způsoby mají značné nevýhody, v prvním případě vzniká při převodu nezanedbatelná entropie. Navíc dochází k narušení BPM cyklu ve fázi optimalizace se lze pouze dohadovat, zda daný defekt, či úzké místo, vznikl při modelování, nebo je výsledkem nepřesného převodu. Ve druhém případě je občas množina elementů omezena proto, že některé z nich je velice těžké namapovat na BPEL, nebo takové namapování nemusí být jednoznačné z toho plyne snížení expresivity dané pseudo-notace. Co je horší, takto vytvořený proces je závislý na konkrétním nástroji vzniká závislost na jednom výrobci (vendor lock-in). BPMN BPMN BPMN Modelovací nástroj 1 XPDL Modelovací nástroj 2 XPDL Nástroj pro simulaci BPEL BPEL? Spuštění (Engine 1) Spuštění (Engine 2) Simulace Obrázek 3.3: Role BPMN, XPDL a BPEL 3.4 Monitoring a optimalizace Ve krátkosti uved me, že monitoring jako takový, je záležitostí hlavně procesního engine, tudíž je závislý na konkrétním produktu. Realita je ale taková, že téměř všechny volně dostupné BPM nástroje nabízejí komponentu pro monitoring pouze při zakoupení komerční licence. Optimalizace nezávisí na žádné konkrétní technologii, pouze navrhuje možná zlepšení a opravu defektů v dalších iteracích životního cyklu v závislosti na výsledcích běhu procesu. 3.5 BPMN 2.0 BPMN 2.0 (Business Process Model and Notation) je dlouho očekávaná a několikrát odložená revize původní BPMN specifikace. Adresuje zejména problémy s přenositelností, jed- 18

29 3.5. BPMN 2.0 noznačnou formalizací (respektive serializací do XML) a spustitelností procesního modelu. V tuto chvíli je ve stádiu finalizační fáze (specifikace je ve verzi Beta2). Co jsou, mimo jiné, cíle BPMN2? navázat na předchozí specifikace široká podpora nástrojů a výrobců možnost zobrazit stejný model s různou úrovní detailů přenositelnost mezi nástroji podpora automatizace (spustitelnosti) procesů Meta-model Jak již napovídá modifikace názvu standardu, nejzásadnější změnou oproti předchozím specifikacím je definice meta-modelu jednotlivých konstruktů (Abstract syntax meta-model). Zmiňovaný meta-model lze rozdělit do několika částí: Abstraktní syntaxe + sémantika meta-model založený na MOF. Každý konstrukt BPMN má danou syntaxi a specifikaci sémantiky. Z abstraktní syntaxe lze odvodit strojově čitelnou definici syntaxe například schéma ve formátu XSD. Sémantika pro spuštění (execution semantics) každý element má jasně definované chování v případě spuštění. Toto chování je jednoznačné. Notace specifikace grafické notace každého elementu, součástí je i specifikace povolených rozšíření a modifikací této notace (barvy, vizuální styl atd.) Meta-model pro přenositelnost diagramů (Diagram Interchange) zachycuje grafickou reprezentaci diagramu ve smyslu rozvržení a přesné polohy jednotlivých elementů. Z meta-modelu je opět odvozeno i příslušné XSD schéma. Díky výše uvedeným principům lze v konečné fázi namodelovaný proces reprezentovat jako XML naplnění výše uvedených cílů je tak čistě implementačním problémem Další změny Mezi další změny oproti původní specifikaci patří přidání nových typů událostí a aktivit. Více detailů naleznete ve specifikaci [11]. Podstatnou novinkou jsou dva nové typy diagramů a také nové elementy pro zachycení choreografie v procesu Diagram kolaborace Tento typ diagramu má za úkol zachytit posílané zprávy mezi účastníky procesu. V tomto diagramu jsou jednotliví účastníci reprezentováni pomocí bazénů a komunikace odpovídá tokům zpráv mezi nimi. 19

30 3.5. BPMN Diagram konverzace Tento diagram je zjednodušenou podmnožinou diagramu kolaborace s tím, že se zaměřuje převážně na vztah dvou a více rolí (účastníků) tj. zobrazuje role, které spolu komunikují conver (konverzují). V podstatě se jedná o souhrnný přehled veškeré komunikace mezi účastníky procesu. Reservation creation Customer Reservation claim Reservation manager Manager (or Waiter) Obrázek 3.4: Diagram konverzace Choreografie Choreografie je typ procesu, který se zaměřuje na výměnu zpráv (a její průběh) mezi účastníky. Vyjadřuje způsob, jakým spolu účastníci komunikují a jaké zprávy používají s ohledem na průběh procesu. Viz obrázek 3.5 choreo Time Reservation number Customer Create reservation Reservation manager Customer Have dinner Manager Waiter Reservation number Table number Obrázek 3.5: Choreography diagram Daniel Tovarnak 1 of 1 20

31 3.6. ZÁKLADNÍ ELEMENTY BPMN BPEL Mapování Součástí specifikace, což může být překvapivé, je i explicitní mapování BPMN schématu na BPEL proces. Je důležité podotknout, že specifikace klade dodatečné podmínky na podobu mapovaného procesu (zdrojový proces například nemůže obsahovat smyčky) Důsledky Je patrné, že použitím standardu BPMN 2.0 se lze vyhnout všem dosud zmíněným problémům a neduhům souvisejícím se starší verzí specifikace. Jde především o univerzální přenositelnost mezi nástroji, či spustitelnost. Díky tomu je možné použít (a sdílet) stejný procesní model ve všech etapách BPM cyklu. Ve smyslu automatizace procesu má použití BPMN 2.0 zásadní důsledky. Fáze spuštění již nemusí znamenat transformaci procesu, ale pouze doplnění implementačních detailů. Nasazením procesní definice do vhodného běhového prostředí lze teoreticky dosáhnou funkcionality ekvivalentní (ne-li lepší) s převodem do jazyka BPEL. Tento fakt rozdmýchává v BPM komunitě vzrušené debaty, jedná se zejména o otázku, zda BPMN2 zcela nahradí jazyk BPEL. 3.6 Základní elementy BPMN 2.0 Nyní si detailněji popíšeme základní elementy a jejich variace dle specifikace BPMN 2.0. Podotkněme, že většina uvedených informací platí i pro předchozí verzi standardu, jen rozdělení do kategorií se mírně liší. Na tomto místě si uvedeme často používané elementy také s ohledem na procesní modely uvedené v této práci. Nejlepším zdrojem pro hlubší studium zůstává specifikace standardu. [11] tasks Aktivity (Activities) Task User Task Recieve Task Service Task Script Task Manual Task Obrázek 3.6: Tasky Aktivity představují vykonání nějaké činnosti v rámci procesu. Aktivitou může být úkol (Task), pod-proces, nebo volání jiné aktivity (Call Activity). Rozdíl mezi pod-procesem a voláním aktivity je takový, že pod-proces je součástí dané procesní definice a slouží především 21

32 3.6. ZÁKLADNÍ ELEMENTY BPMN 2.0 k zpřehlednění diagramu. Na druhou stranu Call Activity je mechanismus určený k volání (externích) znovupoužitelných procesů. Task představuje atomickou činnost v rámci procesu, kterou již nelze dále dělit. User Task je činnost vykonávaná člověkem za asistence softwarového vybavení, nebo procesního engine. Seznam uživatelských úkolů musí být nějakým způsobem dostupný a udržovaný (správce úkolů, workflow komponenta). Standard dále specifikuje způsob přiřazování úkolů jednotlivým účastníkům. Manual Task je stejně jako User Task činnost vykonávaná člověkem, avšak bez účasti SW vybavení. Service Task nějakým způsobem využívá automatizovanou službu, nebo aplikaci. Script Task představuje skript v nějakém jazyce, jež je interpretován běhovým prostředím. (Prostředí samozřejmě musí tento jazyk podporovat.) Recieve Task čeká na zprávu z externího zdroje. Po přijetí zprávy je úkol považován za dokončený a tok procesu dále pokračuje. Pro každou aktivitu může být dále specifikována tzv. multiplicita počet a způsob opakování dané aktivity (viz spodní 3 aktivity na obrázku 3.6). Cyklus (Loop) opakuje danou aktivitu dokud platí specifikovaná podmínka. Multi-Instance vykonává danou aktivitu n-krát dle zadání ve specifikaci. Počet opakování může být vypočítán dynamicky (at run-time). Jednotlivé instance aktivity mohou být vykonány paralelně, nebo sekvenčně Události (Events) Události jsou pokročilý způsob, jak zachytit specifické dění v průběhu procesu. Události ovlivňují samotný tok procesu, mají nějakou příčinu, nebo naopak důsledek, a většinou lze na ně nějakým způsobem reagovat. Jelikož se jedná o dosti rozsáhlou problematiku uvedeme pouze základy. Kompletní přehled událostí naleznete v dokumentaci standardu [11]. Události lze rozdělit do tří základních skupin podle výskytu v životním cyklu procesu. Start Event představuje vždy událost v místě, kde proces začíná. End Event představuje vždy událost v místě, kde proces končí. Intermediate Event Intermediate Event označuje událost mezi začátkem a koncem procesu. Každá událost má navíc jeden ze dvou druhů: 22

33 signals ZÁKLADNÍ ELEMENTY BPMN 2.0 Step 1 Step 2 start at [ :30] wait for message throw signal Obrázek 3.7: Události v procesu Události, jež čekají (catch) na spoušt. Všechny události Start a některé události Intermediate čekají na spoušt (caching events). Události, jež produkují (throw) nějakou hodnotu. Všechny události End a některé události Intermediate produkují nějakou hodnotu (throwing events). Spolu s hodnotou je u throwing event produkována také příslušná spoušt, jež může signals2 být zachycena událostí catching event. Start Event Intermediate event End event message timer throwing signal Obrázek 3.8: Přehled událostí Daniel Tovarnak 1 of Typy událostí Mezi často používané typy událostí patří například: Message Event událost má podobu zprávy v dohodnutém formátu. Timer Event událost má podobu časového okamžiku (např :30). Signal Event událost má podobu interního signálu. 23

34 3.6. ZÁKLADNÍ ELEMENTY BPMN Tok procesu (Sequence flow) Přechody mezi jednotlivými elementy vcelku intuitivně představuje tok procesu (Sequence Flow). Podmíněný gateways tok procesu (Conditional Sequence Flow) se používá především u bran jako element, na němž je definována podmínka. Třetí variantou je výchozí tok u brány (Default Sequence Flow). Obrázek 3.9: Exclusive, Parallel, Inclusive, Event-Based a Complex Gateway Brány (Gateways) Brány poskytují podporu pro rozhodování a větvení (fork) v procesu. Jestliže dorazí tok procesu k bráně, je na základě podmínek a typu brány rozhodnuto jakým způsobem bude tok pokračovat. Podmínky jsou definovány na odchozích (podmíněných) tocích. Některé brány navíc mohou sloužit ke sjednocení toků (join). Z pohledu simulace dodejme, že brána má vždy nulovou cenu a nulový čas provedení. Uved me si čtyři v praxi používané brány Exclusive Gateway gateway2 Při větvení je vybrán nejvýše 1 odchozí tok na základě definovaných podmínek. V praxi by to měl být právě jeden tok (tzn. alespoň jedna větev by měla být pravdivá, nebo by měl být definován výchozí tok). Při sjednocení toků proces pokračuje po příchodu jakéhokoliv (jednoho) toku. parallel gateway parallel 1 price > = 5000 step A exclusive gateway parallel 2 price < 5000 step B Obrázek 3.10: Paralell a Exclusive Gateway v procesu Parallel Gateway Daniel Tovarnak 1 of 1 Paralelní brána je prostředek k práci s více souběžnými toky. Při větvení jsou paralelně spuštěny všechny odchozí toky. Při sjednocení je paralelní brána synchronizující proces po- 24

35 3.6. ZÁKLADNÍ ELEMENTY BPMN 2.0 kračuje pouze po příchodu všech toků Inclusive Gateway Můžeme říci, že tato brána je v podstatě kombinací předchozích dvou případů. Při větvení může být vybrána jakákoliv kombinace odchozích toků (0..n) a tyto toky mohou běžet paralelně. V praxi by však měl být vybrán alespoň 1 tok. Použití této brány pro sjednocení je trošku problematické je třeba explicitně definovat synchronizaci. Požadované chování však může být docíleno použitím kombinace ostatních bran. gateway3 price > step1 synchronizing? step 2 default step 3 Obrázek 3.11: Inclusive Gateway Event-based Gateway gateway4 V podstatě se jedná o Exclusive Gateway založenou na událostech. Tato brána vybere jednu větev v závislosti na dané události. Nelze ji použít pro sjednocení toků. Handle message Handle SMS Time out Obrázek 3.12: Event-based Gateway Daniel Tovarnak 1 of 1 25

36 3.7. BPM SOFTWARE Bazény a plavecké dráhy (Pools and Swimlanes) Bazén představuje autonomního účastníka procesu, nejčastěji ve smyslu samostatného systému. Komunikace mezi jednotlivými účastníky (bazény) má podobu toku zpráv (Message Flow). Hlavním cílem bazénů je zvýšit přehlednost a vypovídající hodnotu diagramu. Bazén, který obsahuje námi modelovaný proces většinou přestavuje systém, jež máme pod kontrolou, nebo je předmětem našeho zájmu někdy též bílá skříňka. Naopak externí účastník bývá často zobrazen jako prázdný bazén černá skříňka. pools-lanes Plavecké dráhy Plavecká dráha se vyskytuje vždy uvnitř bazénu a slouží k jeho logickému (vizuálnímu) rozdělení. Je třeba zdůraznit, že význam drah není nijak specifikován a je plně v rukou modeláře. Nejčastěji jsou dráhy používány k vyjádření rolí participujících v procesu. Lector Assign topic Student System Write essay Upload essay Ex ternal system Obrázek 3.13: Plavecké dráhy a bazény 3.7 BPM software V předchozích odstavcích jsme shrnuli všechny současné standardy procesního řízení. Nyní si v krátkosti představme konkrétní nástroje a SW produkty, jež mohou být reálně použity v BPM projektech. Předmětem našeho zájmu jsou hlavně open-source řešení Procesní engine Procesní engine je komponenta, která interpretuje (spouští) konkrétní procesní definici v daném jazyce. Uved me dva nejznámější zástupce pro jazyky BPEL a jpdl. 26 Daniel Tovarnak 1 of 1

37 3.7. BPM SOFTWARE Apache ODE (Apache License v2) ODE (Orchestration Director Engine) je procesní engine kompatibilní se standardem WS- BPEL. ODE se řadí mezi nejpoužívanější open-source běhová prostředí pro jazyk BPEL a to také díky skvělému výkonu. Navíc nabízí mnoho rozšíření (podpora pro REST atd.) nad rámec specifikace. Více na < jbpm (LGPL) jbpm neboli JBoss Business Process Management je procesní engine pro BPEL a jpdl. Po svém uvedení zaznamenalo jbpm obrovský úspěch a miliony stažení. Po odchodu hlavních vývojářů na jaře 2010 však nad jbpm visí otazník. Běhové prostředí je založeno na principu tzv. Process Virtual Machine, jež umožňuje jednoduchou adopci nových procesních jazyků. Více o principech PVM naleznete v oddíle Další informace o projektu se nachází na < BPMS BPMS neboli Business Process Management Suite je SW produkt (nebo skupina produktů), jež implementuje vhodné standardy a poskytuje technologickou podporu pro již mnohokrát zmíněné etapy životního cyklu (převážně pro 2 a 3 etapu). Přechod mezi jednotlivými etapami je plynulý a celý cyklus probíhá v unifikovaném prostředí. Většina BPMS produktů používá (v poslední době velmi oblíbený) obchodní model, založený na vlastní open-source komunitě. 1 Základní verze produktu je vždy distribuována pod nějakou open-source licencí, v kontrastu s komerční edicí produktu, jež většinou zahrnuje technickou podporu, rozšířené možnosti integrace, či sofistikovanější komponenty Bonita Open Solution Bonita Open Solution je klasickým zástupcem moderních BPMS. Projekt byl založen v roce 2001 jako open-source alternativa ke komerčním produktům. Produkt staví na třech základních komponentách. Více o BOS lze nalézt například v [12] a také na< bonitasoft.com/>. Bonita Studio Hlavní vývojové a modelovací prostředí, vybudované nad platformou Eclipse, poskytuje uživatelům funkcionalitu pro modelování, simulaci a implementaci business procesů. Pro modelování je použita upravená notace BPMN 1.2. Implementace procesu zahrnuje tvorbu uživatelských formulářů, mapování dat a doplnění tzv. konektorů. Konektory mají podobu Java tříd a jsou hlavním prostředkem k programové implementaci procesu. Mohou sloužit k 1. Cesta k tomuto modelu mívá dva scénáře komercializace open-source projektu, nebo naopak otevření zdrojových kódů komerčního produktu. 27

38 3.7. BPM SOFTWARE interakci s běhovým prostředím, databází, LDAP serverem, či produkty třetích stran. Namodelovaný a implementovaný proces má podobu archivu, jež obsahuje veškeré programové komponenty potřebné ke spuštění. Proces samotný je uložen jako proprietární XML. Bonita Execution Engine Běhové prostředí nástroje Bonita poskytuje programové API pro spouštění a správu implementovaných procesů. Procesní engine lze nasadit do většiny běžných aplikačních serverů. K zajištění persistence je použit framework Hibernate, z čeho plyne vcelku bohatá podpora databází. Zajímavostí je celkem dobře dokumentované, poměrně kompletní REST API a také zabudovaná workflow komponenta. Bonita User Experience Poslední komponentou je webová aplikace, která představuje kompletní uživatelské rozhraní pro správu procesů, monitoring běhového prostředí, a navíc poskytuje podporu pro uživatelskou interakci s procesy. Aplikace je multijazyčná a snadno integrovatelná, dovoluje však pouze omezené možnosti uživatelských úprav (s vynaložením rozumného úsilí) Intalio BPMS Intalio je společnost, jež se v současné době zaměřuje na poskytování širokého portfolia aplikací, služeb a integračních řešení pro cloud computing. Součástí vývojových aktivit je také standalone BPMS nástroj s příznačným názvem. I přes svoji lehce omezenou funkcionalitu je open-source edice mezi vývojáři velmi oblíbená. Produkt lze rozdělit na dvě zásadní komponenty. Intalio Designer Intalio Designer je samostatný nástroj určený pro business analytiky, softwarové inženýry a administrátory. Poskytuje podporu pro tvorbu procesních modelů a následné provázání procesu s externími systémy a uživatelskými rozhraními. Výsledný proces lze následně jednoduše spustit v běhovém prostředí Intalio BPMS Server. Podotkněme, že modelování probíhá v upravené BPMN 1.2 notaci. Po každém uložení je proces automaticky přeložen do spustitelné podoby ve formátu BPEL 2.0. Nástroj je dostupný jako samostatná aplikace, nebo jako sada pluginů pro platformu Eclipse. Intalio Server Intalio Server je BPEL 2.0 kompatibilní procesní engine, jehož srdcem je upravený Apache ODE. To zajišt uje zpětnou kompatibilitu modelovaných procesů a také zaručuje vysoký výkon. Workflow komponenta je vybudována kolem projektu Intalio Tempo. Tempo je workflow engine založený na standardu BPEL4People a projektu Orbeon pro správu uživatel- 28

39 3.7. BPM SOFTWARE ských formulářů. Obě komponenty jsou dostupné skrze jednotné uživatelské rozhraní v podobě webové aplikace. Ke komunikaci se serverem lze alternativně využít sadu WS-* služeb Activiti BPM Poněkud stranou stojí BPM nástroj Activiti, určený pro jazyk BPMN2. Ač je jeho součástí plnohodnotný procesní engine (production-ready), obsahuje také sadu doplňující nástrojů, jež jsou určeny pro podporu jednotlivých etap BPM cyklu ty se však stále nachází ve fázi vývoje. Activiti tedy nelze zařadit čistě mezi ostatní běhová prostředí, avšak označení BPMS je také přinejmenším nepřesné. Při výběru stěžejní technologie pro praktickou část práce padlo rozhodnutí právě na procesní engine nástroje Activiti BPM. Ač je na BPM trhu absolutní novinkou, poskytovaná funkcionalita by měla být dostačující pro naše účely. Důležitou roli hrál také stav dokumentace, podpora vývojářů a flexibilita daného řešení. Největší váhu měl však fakt, že se jedná o engine založený na BPMN 2.0 vznikla tak jedinečná možnost analyzovat hlouběji vůbec první procesní engine pro tento standard. Důvodem byl také způsob, jakým Activiti přistupuje ke tvorbě aplikací založených na procesech a procesním řízení. 29

40 Kapitola 4 Activiti BPM V této kapitole si blíže představíme projekt Activiti, a to zejména jeho hlavní komponentu procesní engine. Budeme se zabývat především funkcionalitou a architekturou tohoto běhového prostředí, včetně technických detailů. Větší polovinu této kapitoly pojmeme jako základní technickou průpravu, jež pomůže čtenáři lépe se orientovat v následujících kapitolách. Activiti je Business Process Management a worklflow systém, zaměřený na business uživatele, vývojáře a administrátory. Je postaveno na rychlém a stabilním BPMN2 procesním engine v jazyce Java a je vyvíjeno pod licencí Apache. Hlavní stránka projektu 1 Activiti je vyvíjeno pod taktovkou několika velkých hráčů současné BPM a enterprise sféry. Jedná se především o společnosti stavějící na open-source vývoji. Patří mezi ně například: Alfresco, společnost vyvíjející stejnojmenný systém pro správu obsahu (Enterprise Content Management), SpringSource, jež stojí za vývojem aplikačního rámce Spring, Signavio, tvůrce úspěšného BPM editoru, Camunda, specializující se na tvorbu komplexních BPM systémů a MuleSoft, tvůrce oblíbené integrační platformy. Největší devizou Activiti je jistě flexibilní procesní engine, na jehož základě lze vybudovat vaši BPM aplikaci, nebo dokonce vlastní BPMS. Běhové prostředí podporuje uspokojivou škálu často používaných databází a téměř všechny běžné aplikační servery, přičemž prioritou do budoucna je nadále rozšiřovat možnosti integrace s dalšími technologiemi a produkty (integrace s Mule ESB, kompatibilita s OSGi, atd.). Součástí distribuce je i sada doplňujících komponent zaměřených na jednotlivé etapy životního cyklu. Samotní autoři dodávají, že zatímco vynikající engine je nutností, hlavním cílem je na jeho základě vytvořit kvalitní nástroje. Dodejme, že na rozdíl od běhového prostředí, nejsou jednotlivé komponenty zatím použitelné v produkčním nasazení. Nástroje mají podobu samostatných webových aplikací. Activiti Cycle nástroj zaměřený na podporu spolupráce více lidí při modelování a automatizaci procesu. Má za úkol zejména překlenout přechod mezi business světem a vývojáři. 1. < 30

41 4.1. ACTIVITI BPM ENGINE Obrázek 4.1: Activiti BPM [< Activiti Probe rozhraní pro monitoring a kompletní správu běhového prostředí sledování instancí procesů, správa procesních definic, monitoring procesů. Activiti Explorer uživatelské rozhraní pro interakci s běhovým prostředím (správa uživatelských úkolů, spouštění procesních definic atd.). V podstatě lze označit jako uživatelské rozhraní pro workflow. Activiti Modeler nástroj pro modelování procesů, založený na projektech Oryx a Signavio Modeler. 4.1 Activiti BPM Engine Nejpodstatnější komponentou Activiti, ke které směřuje i náš zájem, je jeho procesní engine. Jedná se v podstatě o evoluci jbpm běhové prostředí je postaveno na principu známém jako Process Virtual Machine (PVM). PVM je architektonická vrstva, na jejímž základě je vybudována podpora pro konkrétní procesní jazyk (viz dále). Mezi základní vlastnosti tohoto běhového prostředí patří: Vysoký výkon Stabilita 31

42 4.1. ACTIVITI BPM ENGINE Snadná customizace Podpora transakcí Podpora asynchronních úkolů Runtime Service Task Service BPMN 2.0 Support... Form Service Process Virtual Machine Persistence layer Obrázek 4.2: Procesní engine Activiti Process Virtual Machine Velmi zjednodušeně PVM vychází z faktu, že proces je zároveň graf množina uzlů a přechodů PVM tedy implementuje základní funkcionalitu pro pohyb v takovémto grafu. Pravidla pro tvar procesů předepisuje syntaxe konkrétního jazyka. Chování uzlů a přechodů je záležitostí sémantiky. Problém podpory daného jazyka je tak otázkou namapování jeho syntaxe a sémantiky na konstrukty PVM. Pro detailnější popis principů Process Virtual Machine čtenáře odkážeme na [13]. Programové komponenty, jež jsou vybudovány kolem PVM, tvoří následně funkcionalitu celého běhového prostředí. Management Service obstarává funkcionalitu pro spouštění dlouhotrvajících úkolů a poskytuje rozhraní pro získávání informací o persistentním úložišti. Identity Service obstarává všechny potřebné funkce pro správu uživatelů a uživatelských rolí. Task Service je workflow komponenta procesního engine. Poskytuje rozhraní pro práci s uživatelskými úkoly (User Tasks). Repository Service poskytuje rozhraní pro deployment procesních definic a dalších artefaktů. 32

43 4.1. ACTIVITI BPM ENGINE Form Service slouží k načítání a renderování formulářů pro interakci z uživatelem. Runtime Service je služba pro správu, spouštění a interakci s běžícími procesy (instancemi procesů). History Service slouží jako základní komponenta pro monitoring procesů. Obrázek 4.3: Programové API Activiti [15] Programové api Jestliže je procesní engine použit jako samostatná programová komponenta ve vaší aplikaci, nejčastější způsob práce s ním je skrze programové API. Na obrázku 4.3 vidíme strukturu tohoto API. Ze všeho nejdříve je potřeba instanicovat vlastní běhové prostředí, k čemuž slouží třída ProcessEngineConfiguration. Nejběžnějším způsobem práce s touto třídou je načtení konfiguračního souboru, na jehož základě je následně engine instanciován. ProcessEngine engine = ProcessEngineConfiguration. createprocessengineconfigurationfromresource("config.xml"). buildprocessengine(); Konfigurační soubor config.xml je konfigurační soubor, obsahující zejména nastavení persistentního úložiště, případně konfiguraci ostatních programových komponent (poštovní server atd.) Poněkud matoucí může být fakt, že se sice jedná o konfigurační soubor pro framework Spring, ale je použit pouze interně, bez jakékoliv závislosti na Spring kontejneru. O skutečné podpoře rámce Spring pojednává oddíl 4.3 <beans...> <bean id="processengineconfiguration" class="org.activiti.engine.impl.cfg. 33