}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Procesní rˇízení v e-learningu D IPLOMOVÁ PRÁCE
Bc. Daniel Tovarnák ˇ
Brno, leden 2011
Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Vedoucí práce: Mgr. Jiˇrí Koláˇr ii
Podˇekování Tímto bych rád podˇekoval své rodinˇe za projevenou trpˇelivost a nekoneˇcnou podporu pˇri tvorbˇe této práce, stejnˇe jako po celou dobu studia. Zárovenˇ bych chtˇel podˇekovat mému vedoucímu Mgr. Jiˇrímu Koláˇrovi za poskytnutí mnoha vˇecných rad a pˇripomínek, nejen v souvislosti s touto prací. V neposlední rˇ adˇe také dˇekuji všem odborníkum ˚ a kolegum ˚ z Fakulty informatiky Masarykovy univerzity, jež byli ochotni pˇredat mi své znalosti a zkušenosti. Dík patˇrí také všem mým dobrým pˇrátelum. ˚
iii
Shrnutí Tato diplomová práce se zabývá možnostmi využití principu˚ procesního rˇ ízení (Business Process Management) v kontextu elektronické výuky, pˇriˇcemž klade duraz ˚ pˇredevším na technologický aspekt vˇeci. Práce dále cˇ tenáˇre seznamuje s moderními technologiemi z oblasti procesního rˇ ízení a blíže se zamˇerˇ uje na standard BPMN 2.0. Praktickou cˇ ást práce tvoˇrí prototyp nástroje na podporu výuky založený na procesech. Práce je rˇ ešena v rámci projektu MEDUSY.
iv
Klíˇcová slova procesní rˇ í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
Obsah 1
2
3
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Moderní e-learning . . . . . . . . . . . . . . . . . . . . . . 1.2 Blended learning . . . . . . . . . . . . . . . . . . . . . . . 1.3 Motivace pro použití procesního rˇ ízení . . . . . . . . . . . 1.3.1 Procesy . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Cíle práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . Procesní rˇízení a e-learning . . . . . . . . . . . . . . . . . . . . 2.1 Procesní rˇ ízení (Business Process Management) . . . . . . 2.1.1 Dva svˇety . . . . . . . . . . . . . . . . . . . . . . . 2.1.1.1 Procesní rˇ ízení z manažerského pohledu 2.1.1.2 Procesní rˇ ízení jako SWE . . . . . . . . . 2.1.2 Proces (podnikový proces, business process) . . . 2.1.3 Životní cyklus BPM . . . . . . . . . . . . . . . . . 2.1.3.1 Definice (Definition) . . . . . . . . . . . . 2.1.3.2 Modelování (Modeling) . . . . . . . . . . 2.1.3.3 Spuštˇení (Execution) . . . . . . . . . . . . 2.1.3.4 Monitoring . . . . . . . . . . . . . . . . . 2.1.3.5 Optimalizace (Optimization) . . . . . . . 2.2 Procesní rˇ ízení a e-learning . . . . . . . . . . . . . . . . . 2.2.1 Procesy ve výuce . . . . . . . . . . . . . . . . . . . 2.2.2 Pˇrínosy automatizace . . . . . . . . . . . . . . . . 2.2.2.1 Nepˇrímé efekty na kvalitu výuky . . . . 2.2.2.2 Pˇrímé efekty na kvalitu výuky . . . . . . 2.2.3 Výukové (Pedagogické) vzory . . . . . . . . . . . 2.2.3.1 Vzor Fixer Upper [5] . . . . . . . . . . . . 2.2.4 Životní cyklus BPM v elektronické výuce . . . . . 2.2.4.1 Návrh . . . . . . . . . . . . . . . . . . . . 2.2.4.2 Modelování . . . . . . . . . . . . . . . . . 2.2.4.3 Spuštˇení . . . . . . . . . . . . . . . . . . . 2.2.4.4 Monitoring . . . . . . . . . . . . . . . . . 2.2.4.5 Optimalizace . . . . . . . . . . . . . . . . 2.3 Projekt MEDUSY . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Cíle a úkoly projektu . . . . . . . . . . . . . . . . . Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Definice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Use Case diagram (UML) . . . . . . . . . . . . . . 3.1.2 Activity diagram (UML) . . . . . . . . . . . . . . . 3.2 Modelování . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 BPMN 1.2 . . . . . . . . . . . . . . . . . . . . . . . 3.2.1.1 Elementy BPD . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 2 3 3 3 4 4 5 5 5 6 6 7 7 7 8 8 8 8 8 9 9 9 9 11 11 11 12 12 12 12 12 14 14 14 15 15 15 16 vi
4
3.2.2 XPDL . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Spuštˇení . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 BPEL . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Od BPMN ke spuštˇení . . . . . . . . . . . . . . . 3.3.2.1 Ruˇcní pˇrevod . . . . . . . . . . . . . . . 3.3.2.2 Mapování . . . . . . . . . . . . . . . . . 3.3.2.3 Dusledky ˚ . . . . . . . . . . . . . . . . . 3.4 Monitoring a optimalizace . . . . . . . . . . . . . . . . . 3.5 BPMN 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Meta-model . . . . . . . . . . . . . . . . . . . . . 3.5.2 Další zmˇeny . . . . . . . . . . . . . . . . . . . . . 3.5.2.1 Diagram kolaborace . . . . . . . . . . . 3.5.2.2 Diagram konverzace . . . . . . . . . . . 3.5.2.3 Choreografie . . . . . . . . . . . . . . . 3.5.2.4 BPEL Mapování . . . . . . . . . . . . . 3.5.3 Dusledky ˚ . . . . . . . . . . . . . . . . . . . . . . 3.6 Základní elementy BPMN 2.0 . . . . . . . . . . . . . . . 3.6.1 Aktivity (Activities) . . . . . . . . . . . . . . . . 3.6.2 Události (Events) . . . . . . . . . . . . . . . . . . 3.6.2.1 Typy událostí . . . . . . . . . . . . . . . 3.6.3 Tok procesu (Sequence flow) . . . . . . . . . . . 3.6.4 Brány (Gateways) . . . . . . . . . . . . . . . . . . 3.6.4.1 Exclusive Gateway . . . . . . . . . . . . 3.6.4.2 Parallel Gateway . . . . . . . . . . . . . 3.6.4.3 Inclusive Gateway . . . . . . . . . . . . 3.6.4.4 Event-based Gateway . . . . . . . . . . 3.6.5 Bazény a plavecké dráhy (Pools and Swimlanes) 3.6.5.1 Plavecké dráhy . . . . . . . . . . . . . . 3.7 BPM software . . . . . . . . . . . . . . . . . . . . . . . . 3.7.1 Procesní engine . . . . . . . . . . . . . . . . . . . 3.7.1.1 Apache ODE (Apache License v2) . . . 3.7.1.2 jBPM (LGPL) . . . . . . . . . . . . . . . 3.7.2 BPMS . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.2.1 Bonita Open Solution . . . . . . . . . . 3.7.2.2 Intalio|BPMS . . . . . . . . . . . . . . . 3.7.3 Activiti BPM . . . . . . . . . . . . . . . . . . . . . Activiti BPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Activiti BPM Engine . . . . . . . . . . . . . . . . . . . . 4.1.1 Process Virtual Machine . . . . . . . . . . . . . . 4.1.2 Programové api . . . . . . . . . . . . . . . . . . . 4.1.2.1 Konfiguraˇcní soubor . . . . . . . . . . . 4.1.2.2 Pˇrístup ke komponentám . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16 17 17 17 17 17 18 18 18 19 19 19 20 20 21 21 21 21 22 23 24 24 24 24 25 25 26 26 26 26 27 27 27 27 28 29 30 31 32 33 33 34 vii
5
6
4.1.3 Persistence . . . . . . . . . . . . . . . . . . . . . 4.1.4 Workflow . . . . . . . . . . . . . . . . . . . . . 4.2 REST API Komponenta . . . . . . . . . . . . . . . . . . 4.2.1 Pˇríklad požadavku . . . . . . . . . . . . . . . . 4.3 Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Podpora BPMN2 . . . . . . . . . . . . . . . . . . . . . 4.4.1 Pˇríklady . . . . . . . . . . . . . . . . . . . . . . 4.4.1.1 None Start Event . . . . . . . . . . . . 4.4.1.2 Conditional Sequence Flow . . . . . . 4.4.1.3 Script Task . . . . . . . . . . . . . . . 4.4.1.4 User Task . . . . . . . . . . . . . . . . 4.4.1.5 (Java) Service Task . . . . . . . . . . . 4.5 Procesní engine detailnˇeji . . . . . . . . . . . . . . . . 4.5.1 Promˇenné . . . . . . . . . . . . . . . . . . . . . 4.5.2 Výrazy . . . . . . . . . . . . . . . . . . . . . . . 4.5.3 Formuláˇre . . . . . . . . . . . . . . . . . . . . . 4.5.3.1 Interní rendering . . . . . . . . . . . . 4.5.3.2 Externí rendering . . . . . . . . . . . 4.6 Pˇríklad . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Service Task (serviceTask) . . . . . . . . . . . . Modelový proces kurzu Communication and Soft Skills . 5.1 Kurz Softskills . . . . . . . . . . . . . . . . . . . . . . . 5.2 Návrh procesu . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Role . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Potˇrebné komponenty . . . . . . . . . . . . . . 5.2.3 Základní aktivity . . . . . . . . . . . . . . . . . 5.2.4 Struˇcný scénáˇr kurzu . . . . . . . . . . . . . . . 5.3 Modelování procesu . . . . . . . . . . . . . . . . . . . 5.4 Poznámky k procesu . . . . . . . . . . . . . . . . . . . 5.4.1 Set up Course . . . . . . . . . . . . . . . . . . . 5.4.2 Enrollment & Import students . . . . . . . . . 5.4.3 Team bulding . . . . . . . . . . . . . . . . . . . 5.4.4 Team session . . . . . . . . . . . . . . . . . . . 5.4.5 Photos . . . . . . . . . . . . . . . . . . . . . . . 5.4.6 Perform assessment . . . . . . . . . . . . . . . 5.4.7 Invite members . . . . . . . . . . . . . . . . . . 5.5 Implementace procesu . . . . . . . . . . . . . . . . . . Nástroj na podporu výuky . . . . . . . . . . . . . . . . . . 6.1 Použité technologie . . . . . . . . . . . . . . . . . . . . 6.1.1 Ruby on Rails . . . . . . . . . . . . . . . . . . . 6.1.2 JRuby . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Architektura . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34 34 35 35 36 37 38 38 38 38 38 39 39 39 40 40 40 41 41 42 43 43 43 43 43 44 44 44 44 45 45 45 45 45 46 46 47 48 48 49 49 49 viii
6.2.1 Implementaˇcní zkratky . . . . . . 6.2.2 Role . . . . . . . . . . . . . . . . . . 6.2.3 Uživatelské formuláˇre . . . . . . . 6.3 Moduly . . . . . . . . . . . . . . . . . . . . 6.3.1 Process Engine . . . . . . . . . . . 6.3.2 User Management . . . . . . . . . 6.3.3 Topics & Teams . . . . . . . . . . . 6.3.4 Picasa albums . . . . . . . . . . . . 6.3.5 My Team (Teamspace) . . . . . . . 6.3.6 Course Space . . . . . . . . . . . . 6.3.7 Feedbacks . . . . . . . . . . . . . . 6.3.8 Monitoring . . . . . . . . . . . . . 6.4 Shrnutí . . . . . . . . . . . . . . . . . . . . 6.4.1 Technologie . . . . . . . . . . . . . 6.4.2 Podpurná ˚ funkcionalita . . . . . . 6.4.3 Interoperabilita . . . . . . . . . . . 6.4.4 Autentizace a správa uživatelu˚ . . 6.4.5 Uživatelské úkoly a formuláˇre . . 6.4.6 Podpora více kurzu˚ a jejich záloha 7 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . Literatura a zdroje . . . . . . . . . . . . . . . . . . . A Pˇríklad z Kapitoly 4 — Activiti Hello World . A.1 Prerekvizity pro spuštˇení . . . . . . . . . . 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ˇení . . . . . . . . . . . . . . . . . . . B Nástroj na podporu výuky . . . . . . . . . . . B.1 Prerekvizity pro spuštˇení . . . . . . . . . . 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 . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51 51 52 52 52 53 53 53 53 53 53 54 54 54 54 54 55 55 55 56 58 59 59 59 60 60 60 60 60 61 61 61 61 61 62 62 62 62 62 63 63 63 ix
B.2.9 ./script . . . . . . B.2.10 ./test . . . . . . . B.2.11 ./vendor . . . . . . B.2.12 ./WEB-INF . . . . . B.3 Spuštˇení . . . . . . . . . . . B.4 Online ukázka . . . . . . . . C Implementace procesu Softskills C.1 Procesní definice . . . . . . C.2 Uživatelské tˇrídy . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
63 63 63 63 63 64 65 65 66
x
Kapitola 1
Úvod Vzdˇelání není pouhým nashromáždˇením jednotlivých vˇedomostí, jako tˇestem není mouka, voda, sul, ˚ kvasnice a tak dále, dohromady naházené. —Tomáš G. Masaryk
1.1
Moderní e-learning
Souˇcasné e-learningové1 nástroje dnes již velmi úspˇešnˇe zvládají klasické paradigma výuky, tj. pomˇernˇe jednostranný tok informací ve smˇeru 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 2.02 mohou moderní nástroje poskytnout prostˇredky pro zpˇetnou vazbu studentu, ˚ jejich vzájemnou kolaboraci, cˇ 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 principu˚ Web 2.0 je nˇekdy trefnˇe používán výraz E-learning 2.0. Výzkumy naznaˇcují, že kvalitnˇe zvládnutý e-learning muže ˚ být v nˇekterých pˇrípadech (záleží to ovšem na mnoha faktorech) dokonce efektivnˇejší, než prezenˇcní výuka a ve vˇetšinˇe pˇrípadu˚ dosahuje alesponˇ stejné, nebo jen nepatrnˇe horší výsledky, jako konvenˇcní forma výuky (face-to-face). [1] Výhody elektronické výuky • • • • •
24/7 pˇrístup k uˇcivu možnost volby vlastního tempa výuky pˇrístup k více kurzum ˚ z jednoho místa pˇrístup ke kurzu z více míst (domov, kanceláˇr) monitoring postupu (progress monitoring)
1. Pojmem e-learning máme na mysli i mnohá synonyma (v souˇcasné dobˇe), jako napˇríklad: Computer-Based Learning, Web-Based Learning, Online learning atd. 2. Termínem Web 2.0 se oznaˇcuje moderní internetová aplikace, založená pˇredevším na principu RIA (Rich Internet Application) a obsahu generovaném uživateli. Více naleznete napˇríklad na
1
1.2. BLENDED LEARNING Výhody prezenˇcní výuky • • • •
okamžitá zpˇetná vazba lidský kontakt budování soft-skills využití osobnosti lektora
Není pochyb o tom, že oba svˇety mají své výhody i nevýhody, lze pochopit, že kontakt s živým cˇ lovˇekem je v nˇekterých situacích nenahraditelný, a naopak výuka založená na ICT nese obrovský potenciál v manipulaci a prezentaci informací. Je tedy pˇrirozené, chtít spojit oba svˇety dohromady, potom hovoˇríme o tzv. blended learningu. Již zmínˇená studie velmi pozitivnˇe hodnotí jak výsledky kombinované výuky (blended), tak elektronické výuky duslednˇ ˚ e rˇízené lektorem. [1]
1.2
Blended learning
Blended learning3 (BL) spojuje ruzná ˚ výuková prostˇredí a metody a dává tak lektorum ˚ i studentum ˚ možnost dosahovat lepších výsledku. ˚ Studenti se mohou mnohem aktivnˇeji zapojovat do procesu a obsahu výuky a spolupracovat s lektorem, jež naopak získává potˇrebnou odezvu. Jednoduchým pˇríkladem BL budiž smyšlený kurz, který kombinuje prezenˇcní, dálkovou (distanˇcní) a elektronickou výuku: Studenti se úˇcastní vybraných pˇrednášek a navíc využívají videopˇrenosu. ˚ K dispozici mají také tištˇená skripta urˇcená k samostudiu. S pˇrípadnými dotazy a problémy se mohou obrátit na diskusní fórum. Svoje znalosti si navíc mohou prohloubit a procviˇcit v e-learning systému.
DISTANT
FACE-TO-FACE
E-LEARNING
Obrázek 1.1: Blended learning
3.
z angliˇctiny | blend = míchat, mixovat
2
ˇ 1.3. MOTIVACE PRO POUŽITÍ PROCESNÍHO RÍZENÍ
1.3
Motivace pro použití procesního rˇízení
Zatím jsme vesmˇes uvedli pˇrínosy jednotlivých typu˚ výuky pouze z pohledu studenta, je však tˇreba zohlednit i druhou stranu mince. Úspˇešnˇe zvládnout a vytvoˇrit kvalitní edukativní prostˇredí založené na BL (ale i cˇ istˇe na e-learningu) klade na lektora (resp. lektorský tým) velké cˇ asové a organizaˇcní nároky. Mnoho e-learningových a ICT nástroju˚ nˇekteré z úkolu˚ automatizuje a ulehˇcuje (pˇriˇrazení studentu˚ ke kurzu, hromadné zprávy, interaktivní osnovy), jsou-li však používány ad-hoc a bez nˇejakého rˇ ádu, cˇ asto není dosaženo kýženého efektu. Pˇri spolupráci více lidí (lektoˇri, cviˇcící, asistenti) navíc vzniká další entropie. 1.3.1
Procesy
Zavedení rolí, definice jasných pravidel, postupu, ˚ opakovatelných procesu˚ a nˇekterých principu˚ procesního rˇ ízení, muže ˚ pˇrispˇet k vytvoˇrení uceleného výukového prostˇredí, což s sebou, mimo jiné, pˇrináší nˇekolik výhod: • • •
refaktoring a optimalizace procesu˚ monitoring formalizace edukaˇcních principu˚ a postupu˚
V tomto místˇe je tˇreba zduraznit, ˚ že efektivní použití procesu˚ by vždy mˇela také provázet vhodná metodika pro jejich rˇ ízení — právˇe toto je i v našem pˇrípadˇe duvod ˚ pro zamˇerˇ ení na principy procesního rˇ í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ˇrí: •
Seznámit cˇ tenáˇre s duvody ˚ a principy zavedení procesního rˇ ízení v obecné rovinˇe a následnˇe diskutovat použití tˇechto principu˚ v prostˇredí elektronické výuky.
•
Pˇredstavit souˇcasné moderní technologie a postupy, jež se v tomto kontextu objevují — náš hlavní zájem bude smˇerˇ ovat zejména k možnostem standardu BPMN 2.0 (s durazem ˚ na automatizaci procesu). ˚
•
Praktickým tˇežištˇem práce bude vývoj procesnˇe orientovaného nástroje na podporu výuky. Aplikace bude sloužit pˇredevším jako tzv. „proof-of-concept“ ideje použití procesu˚ ve výuce.
•
Vzniknuvší zkušenosti, postupy a problémy budou zdokumentovány a dále zohlednˇeny v rámci open-source projektu MEDUSY.
3
Kapitola 2
Procesní rˇízení a e-learning V této kapitole nejdˇríve vymezíme základní pojmy a principy procesního rˇ ízení a uvedeme motivaci pro jeho zavedení. Pˇredstavíme si životní cyklus procesního rˇ ízení a detailnˇeji popíšeme jednotlivé etapy. Poté budeme diskutovat možnosti BPM ve vztahu k elektronické výuce. Na závˇer si krátce pˇredstavíme projekt MEDUSY, v jehož rámci je rˇ ešena tato práce.
2.1
Procesní rˇízení (Business Process Management)
Procesní rˇ ízení je evolucí pˇredchozích pˇrístupu˚ k zavedení a rˇ ízení procesu˚ v rámci podnikání. Máme na mysli moderní pojetí procesu v rozmezí posledního cˇ tvrt století — aˇc tento pojem rozhodnˇe nebyl neznámý, teprve v 80. letech minulého století zaˇcal být proces v širší míˇre vnímán jako výrazné aktivum organizace a zárovenˇ prostˇredek ke zvýšení kvality služeb, a tím i zlepšení pozice na trhu.
1986 Six Sigma
1980
1990 Business Process Reengineering
1983 Total Quality Management
2002 Business Process Management
2010
Obrázek 2.1: Historický kontext procesního rˇ ízení Spoleˇcným jmenovatelem všech metodik (vˇcetnˇe procesního rˇ ízení) a zárovenˇ motivací pro zavedení a rˇ ízení procesu˚ je naplnˇení tˇechto faktoru: ˚ • •
vyšší kvalita služeb lepší flexibilita 4
ˇ 2.1. PROCESNÍ RÍZENÍ (BUSINESS PROCESS MANAGEMENT) • • •
zvýšení konkurenceschopnosti zlepšování procesu˚ kontrola procesu˚
Obrázek 2.2: Dva aspekty procesního rˇ ízení
2.1.1
Dva svˇety
Duležitým ˚ faktem je, že na pojem procesního rˇ ízení se lze vždy dívat ze dvou úhlu. ˚ Jednak jako na manažerskou disciplínu, a jednak jako na oblast softwarového inženýrství (SWE). Hranice (a její pˇrekonání) tˇechto dvou odlišných aspektu˚ procesního rˇ ízení je již od poˇcátku pˇredmˇetem mnoha diskusí. Jde zejména o plynulost pˇrechodu mezi obˇema svˇety — zneviditelnˇení této hranice, chcete-li. 2.1.1.1 Procesní rˇ ízení z manažerského pohledu Jedná se o manažerskou disciplínu, založenou na kontinuálním vylepšování (podnikových) procesu, ˚ za úˇcelem dosažení specifických (obchodních) cílu. ˚ [2] Hlavním pˇredmˇetem zájmu jsou podnikové procesy, jejich kvalita, efektivita, vyspˇelost a zárovenˇ dopad na fungování organizace a její strukturu. Orientace na lidi je velkým rozdílem oproti pˇredchozím pˇrístupum ˚ k rˇ ízení procesu˚ (napˇr. Business Process Reengineering) 2.1.1.2 Procesní rˇ ízení jako SWE Jedná se o sadu ICT nástroju, ˚ SWE postupu˚ a metodik, použitých pˇrevážnˇe k naplnˇení cílu˚ jednotlivých etap takzvaného životního cyklu BPM (viz sekce 2.1.3) a cílu˚ BPM jako tako5
ˇ 2.1. PROCESNÍ RÍZENÍ (BUSINESS PROCESS MANAGEMENT) vého. Tato práce se procesním rˇ ízením zabývá pˇrevážnˇe jako oblastí softwarového inženýrství. Již zminovaný ˇ BPR byl zamˇerˇ en právˇe na tento aspekt rˇ ízení procesu, ˚ bohužel až pˇrespˇríliš. 2.1.2
Proces (podnikový proces, business process)
Proces je sled aktivit a úkolu˚ s definovaným zaˇcátkem a koncem, navržený za úˇcelem vytvoˇrení specifického produktu, nebo služby, s ohledem na strukturu a cíle organizace. [3] Procesy mohou být vnoˇrovány do sebe, potom hovoˇríme o tzv. pod-procesech. Procesy jsou nˇekdy rozdˇeleny do dvou skupin podle funkce, kterou vykonávají: •
Hlavní procesy naplnují ˇ primární cíle podnikání. Jsou vybudovány na základˇe knowhow a zkušeností. Kvalitní proces poskytuje pˇridanou hodnotu a muže ˚ pˇrinést náskok pˇred konkurencí (competitive advantage).
•
Podpurné ˚ procesy, jak již název napovídá, poskytují dodateˇcnou podporu pro hlavní procesy. Podpurné ˚ procesy mohou výraznˇe ovlivnit výsledný výkon a efektivitu hlavního procesu.
business process
Rejected
Send invoice
Accept payment
Accepted
Order
Fill order
Recieve order request
Close order
Ship order
Obrázek 2.3: Business proces
2.1.3
Životní cyklus BPM
Životním cyklem BPM se oznaˇcuje soubor etap, jimiž v procesním rˇ ízení prochází každý proces (nebo skupina procesu). ˚ První etapa navazuje na etapu poslední a vytváˇrí tak nekoneˇcný (iterativní) cyklus. Každá etapa zahrnuje ruzný ˚ pomˇer již zminovaných ˇ aspektu˚ BPM, zárovenˇ muže ˚ mít svuj ˚ vlastní vývojový cyklus, cˇ i metodiku. Je jednoduché si pˇredstavit, že 6
Daniel Tovarnak
1 of 1
ˇ 2.1. PROCESNÍ RÍZENÍ (BUSINESS PROCESS MANAGEMENT) napˇríklad u Spuštˇení to bude nˇejaká metodika SWE. Jednotlivé fáze a jejich poˇcet se napˇríˇc dostupnými zdroji jemnˇe liší, uved’me tedy jistou spoleˇcnou množinu. 2.1.3.1 Definice (Definition) V první etapˇe jsou analyzovány a identifikovány existující (reálné) procesy, vˇcetnˇe urˇcení vztahu˚ a rolí participujících v procesu. Jedná se v podstatˇe o kombinaci zachycení požadavku, ˚ analýzy a prvotního návrhu, tak jak je známe ze SWE. Definování procesu je vˇetšinou kompetencí vlastníka procesu a business analytika. Bˇežným výstupem bývá obyˇcejný strukturovaný text. V pokroˇcilejších fázích muže ˚ dojít na vývojové diagramy (flowcharts), cˇ i jiné prostˇredky pro formalizaci toku procesu.
Business Process Management
Mo ni to rin g
Ex
g elin Mod
Opt imiz atio n
Definition
n io ut c e
Obrázek 2.4: Životní cyklus BPM
2.1.3.2 Modelování (Modeling) Modelování zahrnuje vytvoˇrení posloupnosti aktivit a úkolu˚ na základˇe požadavku˚ vlastníka procesu a výstupu prvotního návrhu. V praxi je výstupem procesní model srozumitelný pro vˇetšinu aktéru˚ — soubor diagramu˚ v nˇejaké procesní notaci. Souˇcá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ˇríklad oblast softwarového inženýrství nazývaná Business Process Modeling. 2.1.3.3 Spuštˇení (Execution) Úkolem této fáze je pˇrevod procesního modelu do spustitelné formy, respektive vykonání takových kroku˚ a implementaˇcních prací, které povedou ke spuštˇení procesu v akceptovatelné formˇe, vˇcetnˇe nasazení a administrace. Tato etapa je v kompetenci IT odborníku˚ ve spolupráci s ostatními aktéry. 7
ˇ 2.2. PROCESNÍ RÍZENÍ A E-LEARNING 2.1.3.4 Monitoring Úkolem monitoringu je sbˇer a dat sledování dat za úˇcelem vyhodnocení bˇehu procesu. Jedná se napˇríklad o monitoring výkonu, sledování statistik a identifikaci pˇrípadných problému˚ a defektu˚ vzniklých v pˇredchozích etapách. Toto není Business Activity Monitoring. 2.1.3.5 Optimalizace (Optimization) V této etapˇe jsou vyhodnocena všechna data z pˇredchozích fází a vyvozeny potˇrebné závˇery vedoucí k pˇrípadnému zvýšení efektivity procesu. Na základˇe výstupu˚ z optimalizace zaˇcíná nová iterace životního cyklu a tyto výstupy jsou zohlednˇeny v pˇríslušných fázích.
2.2
Procesní rˇízení a e-learning
Procesní rˇ ízení nemusí vždy pˇrímo souviset s podnikovou sférou (v tomto muže ˚ být anglický ekvivalent ponˇekud zavádˇející). Jelikož však mají procesy a procesní rˇ ízení koˇreny zejména v enterprise sféˇre, lze se s tímto oznaˇcením setkat i v jiných („ne-podnikových“) oblastech. V takových pˇrípadech je vˇetšinou procesní rˇ ízení zamˇerˇ eno pˇrevážnˇe na svuj ˚ technologický aspekt a manažerská cˇ ást je zásadnˇe ovlivnˇena cílovou doménou. Toto je v podstatˇe i pˇrípad BPM v elektronické výuce. 2.2.1
Procesy ve výuce
Lze se shodnout na tom, že výuka samotná je proces. Rozdˇelení a podoba procesu˚ v elearningu v podstatˇe odpovídá situaci z klasického BPM, pouze s drobnými specifiky. Vlastníkem procesu je v tomto pˇrípadˇe vˇetšinou lektor. •
Hlavní procesy (Výukové procesy) — výukový proces je sled aktivit a událostí tvorˇ ící nápln, ˇ cˇ i cíl výuky. Ve spojení s cˇ asovým ohodnocením tvoˇrí výukový proces plán výuky. Nalezení výukových procesu˚ je pˇredmˇetem empirického zkoumání, resp. pedagogickým problémem.
•
Podpurné ˚ procesy se podílí na tvorbˇe a správˇe výukového prostˇredí a stejnˇe tak, jako v klasickém pˇrípadˇe, poskytují doplnkovou ˇ funkcionalitu pro procesy hlavní.
2.2.2
Pˇrínosy automatizace
V podnikové sféˇre vede zavedení BPM k jasnému cíli — snížení nákladu˚ a zvýšení zisku. U elektronické výuky bychom tímto cílem mohli oznaˇcit vyšší efektivitu a kvalitu vzdˇelání. Zavedení procesu˚ (a zejména jejich automatizace) by se na kvalitu výuky mˇelo promítnout jako kombinace pˇrímých a nepˇrímých efektu. ˚ 8
ˇ 2.2. PROCESNÍ RÍZENÍ A E-LEARNING 2.2.2.1 Nepˇrímé efekty na kvalitu výuky •
Snížení poˇctu administrativních úkonu, ˚ jejich automatizace a podpora týmové spolupráce v lektorském týmu vede k rovnomˇernému rozdˇelení povinností a kompetencí — lektor má více cˇ asu na pˇrípravu náplnˇe výuky. Zejména u blended learningu muže ˚ být cˇ asová úspora netriviální.
•
Okamžitý pˇrehled o stavu situace, splnˇených a nesplnˇených úkolech — lektorský tým má možnost pružnˇe reagovat na danou situaci.
•
Možnost kontinuálního vyhodnocování úspˇešnosti a následného vylepšování daného výukového procesu.
2.2.2.2 Pˇrímé efekty na kvalitu výuky •
Student má jasnˇe definované úkoly a povinnosti vˇcetnˇe cˇ asového horizontu — podpora kontinuální práce a zátˇež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ástroju, ˚ zejména pro technologicky zamˇerˇ ené kurzy.
•
Jednodušší sdílení informací a vˇedomostní báze mezi ruznými ˚ výukovými prostˇredími.
2.2.3
Výukové (Pedagogické) vzory
ˇ Rekli jsme, že nalezení výukových procesu˚ je pedagogickým problémem — každý kurz, cˇ i pˇrednášená problematika vyžaduje odlišný pˇrístup. Tomuto tématu se mimo jiné vˇenuje projekt Pedagogical patterns [4] — soubor pedagogických vzoru˚ a postupu˚ pro ruznou ˚ množinu problému˚ (zejména v technických kurzech). Použití pedagogických vzoru˚ muže ˚ v mnohém zjednodušit tvorbu i optimalizaci výukových procesu˚ a zárovenˇ zkvalitnit výuku z pedagogického hlediska. Naopak formalizace jednotlivých vzoru˚ pomocí procesu˚ muže ˚ pomoci pˇri následné diskuzi, cˇ i opakovaném použití. Pro pˇredstavu si uved’me jeden z tˇechto vzoru. ˚ 2.2.3.1 Vzor Fixer Upper [5] Studenti, nebo skupina studentu˚ mají za úkol provést analýzu a opravu1 chyb v pˇredem pˇripraveném (rozumnˇe velkém) artefaktu (program, návrh) – tyto chyby jsou však vytvoˇreny zámˇernˇe. 1. Pojem Fixer Upper oznaˇcuje v USA nemovitost ve špatném stavu, která je sice obyvatelná, ale vyžaduje mnoho dodateˇcných stavebních prací a úprav.
9
ˇ 2.2. PROCESNÍ RÍZENÍ A E-LEARNING Podnˇet •
ˇ Studenti cˇ asto pracují pouze na problémech omezené velikost a složitosti. Casto nemusí mít dostateˇcné zkušenosti pro tvorbu složitˇejších artefaktu. ˚ Problémem bývá také omezený cˇ as. Tento pˇrístup dovoluje studentum ˚ bez zahlcení pracovat s velkými artefakty a pˇriblížit je reálné praxi.
•
Druhým faktorem je práce s chybami obecnˇe — studenti pˇri výskytu chyb v jejich vlastní práci cˇ asto tápou (chybové hlášky, výjimky apod.)
Kontext •
Vzor muže ˚ být použit v mnoha situacích a v ruzném ˚ rozsahu. Typické použití — kurzy programování, výuka analýzy a návrhu. Muže ˚ být použito také v kurzech zabývajících se problematikou QA.
Motivace •
Studenti musí cˇ asto nastudovat oblast, jejíž pochopení závisí na znalosti souvisejících témat. Pokud jsou tato témata pˇrednesena postupnˇe, studenti cˇ asto nevidí du˚ ležité souvislosti. Schopnost analyzovat a opravovat chyby také pokulhává.
•
Analýza a oprava chyb ve velkém artefaktu je v silách vˇetšiny studentu, ˚ na rozdíl od tvorby takového artefaktu. Studenti si dokážou udˇelat obrázek o skuteˇcné velikosti a složitosti rˇ ešení problému˚ v praxi.
Fixer Upper
Pick artefact
Introduce artefact
Lector
Modify artefact
Present solution
Assessment
Fix er- Upper - Student Student
Fix er- Upper
Fix er- Upper - Lector Implement errors
Build team
Find errors
Discussion
Obrázek 2.5: Fixer Upper
10
ˇ 2.2. PROCESNÍ RÍZENÍ A E-LEARNING ˇ Rešení •
Studenti dostanou k dispozici vcelku velký artefakt v podobˇe programu, aplikace, cˇ i návrhu. Artefakt pˇredstavuje rˇ ešení nˇejakého problému, ale zatímco je obecnˇe korektní, jsou v nˇem umˇele vytvoˇreny chyby. Vˇetšina z nich je jasnˇe nápadných, nˇekteré jsou obtížnˇejší.
•
Úkolem studentu˚ je najít, zdokumentovat a opravit chyby. Dalším úkolem je vˇenovat pozornost struktuˇre artefaktu. V koneˇcné fázi následuje diskuze. Dusledky ˚
•
Tento vzor dovoluje studentum ˚ aktivnˇe pracovat s velkými artefakty (mnohem vˇetšími než by sami dokázali vytvoˇrit). Pˇrínosem jsou také nabyté znalosti potˇrebné pro hledání chyb. V pˇrípadˇe programu˚ mohou studenti narazit na syntaktické i sémantické chyby. V dalších pˇrípadech se muže ˚ jednat napˇríklad o chyby v návrhu atd.
•
Duležitým ˚ pˇredpokladem je vysoká kvalita daného artefaktu, vˇcetnˇe dobré dokumentace. Povaha chyb by mˇela být ruznorodá, ˚ jejich závažnost naopak úmˇerná znalostem studentu. ˚ Úkoly tohoto typu cˇ asto poskytují živnou pudu ˚ pro množství otázek a podporují diskusi mezi studenty.
2.2.4
Životní cyklus BPM v elektronické výuce
Formalizace výuky pomocí procesu˚ je podstatným principem, jež muže ˚ vést ke kvalitnˇejšímu vzdˇelání. Duležitým ˚ a nedílným krokem je také adopce celého životního cyklu BPM. Lektor, stejnˇe jako vrcholový manažer, nikdy nebude vytváˇret pˇrímo spustitelné procesy, zárovenˇ však pˇredstavuje duležitou ˚ roli pˇri 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ˇeje v obecnˇe menším mˇerˇ ítku a na vývoji procesu spolupracuje ménˇe lidí. Urˇcitým specifikem muže ˚ být délka celé iterace, a to v závislosti na dobˇe, po jakou proces bˇeží — vˇetšinou celý semestr. 2.2.4.1 Návrh Lektor poskytne potˇrebné informace o kurzu, vˇcetnˇe jednotlivých rolí, kompetencí, aktivit, výstupu˚ a požadavku˚ v podobˇe scénáˇre kurzu. Scénáˇr je konzultován s cviˇcícími, pˇrípadnˇe návrháˇrem procesu. Nedílnou souˇcástí je také analýza z pedagogického pohledu. 2.2.4.2 Modelování Na základˇe informací z pˇredchozí etapy je vytvoˇren procesní model s ohledem na funkce a možnosti výukového prostˇredí. Model by mˇel být vytvoˇren zkušeným cˇ lenem lektorského týmu. 11
2.3. PROJEKT MEDUSY 2.2.4.3 Spuštˇení Procesní model je pˇreveden do spustitelné formy a do základního výukového systému je pˇrípadnˇe pˇridána potˇrebná funkcionalita. 2.2.4.4 Monitoring Proces je monitorován kompetentními rolemi. Použití BAM pˇrináší nesporné množství výhod, zejména ve smyslu kontroly výsledku˚ a chování studentu. ˚ 2.2.4.5 Optimalizace Bˇeh procesu (kurzu) je vyhodnocen a optimalizován s durazem ˚ na zapojení pedagogických principu. ˚
2.3
Projekt MEDUSY
MEDUSY je open-source projekt zamˇerˇ 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ˇcasnosti je projekt v rané fázi analýzy a prvotního návrhu. Tato práce pˇredstavuje pˇrípadovou studii a „proof-of-concept“ pro využití procesu˚ a procesního rˇ ízení v elektronické výuce. Hlavní stránka projektu se nachází na adrese . 2.3.1 • • • • • • • •
Cíle a úkoly projektu prostudovat možnosti využití procesního rˇ ízení v elektronické výuce vytvoˇrit prostˇredí pro snadné modelování výukových procesu, ˚ jejich správu a monitoring identifikovat cˇ asté výukové vzory zavést prostˇredky 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 stroju˚ (Virtuální laboratoˇre) poskytnout prostˇredky pro správu multimediálního obsahu vybudovat aktivní komunitu
Nˇekteré z úkolu˚ jsou v souˇcasné dobˇe rˇ ešeny v rámci dalších závˇereˇcných prací kolegu˚ z Fakulty Informatiky. • • •
DP: Modelování výukových procesu˚ (Bc. Jiˇrí Novák) DP: Použití webových služeb v oblasti e-learningu (Bc. Miroslav Baláž) DP: Virtuální laboratoˇre (Bc. Bohuslav Kabrda) 12
2.3. PROJEKT MEDUSY • •
ˇ BP: E-learningové CMS a formáty (Bc. Emil Cerve nan) ˇ BP: E-learningové vzory v kurzech na Masarykovˇe univerzitˇe (Milan Mužík)
System
Email subsystem Test management system
User Interface
Content based LMS
Process orchestration engine
Multimedia & streaming
Modelling tool Virtual labs LDAP
Obrázek 2.6: Prvotní návrh architektury projektu MEDUSY
13
Kapitola 3
Technologie Doposud jsme se zámˇernˇe bavili o procesním rˇ ízení pouze v obecné rovinˇe, rˇ ekli jsme si, že jej lze rozdˇelit na dva aspekty — manažerský a technologický. V této kapitole podrobnˇeji rozebereme právˇe souˇcasné technologie a standardy používané v procesním rˇ ízení, jakožto v disciplínˇe SWE. Tato kapitola nemá v úmyslu jakkoliv suplovat technickou dokumentaci, ale pouze podat pˇrehled o jednotlivých technologiích. Dodejme, že pˇredmˇetem našeho zájmu jsou pˇredevším technologie spojené s modelováním a spouštˇením procesu, ˚ ostatní etapy životního cyklu BPM zmíníme pouze okrajovˇe.
3.1
Definice
Tato fáze, i pˇres svou nesmírnou duležitost, ˚ používá technologii pouze pro zachycení stavu svˇeta v co nejsrozumitelnˇejší formˇe. Nalezení a definice procesu˚ je záležitostí zkušeností a zejména znalostí reálných procesu. ˚ To, jak kvalitnˇe je analýza spolu s prvotním návrhem provedena, má drtivý dopad na neménˇe duležitou ˚ fázi modelování. Pravdou je, že samotné nalezení procesu˚ je spíše záležitostí metodiky než technologie. Pˇekný pˇríklad procesní analýzy lze nalézt napˇríklad v [6]. 3.1.1
Use Case diagram (UML)
Klasický Use Case diagram se hodí zejména na zachycení rolí, pˇrípadnˇe zásadní funkcionality procesu.
Obrázek 3.1: Use Case Diagram 14
3.2. MODELOVÁNÍ 3.1.2
Activity diagram (UML)
Activity diagram muže ˚ být použit k prvotnímu namodelování toku procesu. Je dostateˇcnˇe jednoduchý a výstižný a zárovenˇ má vcelku dobrou expresivitu.
Obrázek 3.2: Activity Diagram
3.2
Modelování
Procesní model je soubor diagramu˚ v nˇejaké procesní notaci + specifikace. Použití té, cˇ i oné notace muže ˚ významnˇe ovlivnit jeho kvalitu. Procesní notace musí mít vysokou expresivitu, ale zárovenˇ musí být dostateˇcnˇe cˇ itelná pro všechny úˇcastníky BPM cyklu. De-facto standardem v procesním modelování je procesní notace BPMN 1.2 (OMG). Více o modelování procesu˚ a procesních notacích (zejména ve vztahu k e-learningu) naleznete v práci kolegy Jiˇrího Nováka [7]. 3.2.1
BPMN 1.2
BPMN alias Business Process Modeling Notation je (jak již název napovídá) grafická notace pro modelování podnikových procesu. ˚ Výsledkem modelování je Business Process Diagram (BPD). Zámˇernˇe zde nezminujeme ˇ vlastnosti BPMN ve verzi 2.0, jelikož se jedná o tak zásadní revizi, že je jí vˇenován vlastní oddíl (3.5). Hlavním cílem BPMN je poskytnout notaci, která je snadno cˇ itelná všemi uživateli. Od business analytika, který vytváˇrí prvotní návrhy procesu, ˚ pˇres vývojáˇre, zodpovˇedné za implementaci technologie, která tyto procesy bude spouštˇet, až po manažery, kteˇrí budou tyto procesy rˇ ídit a monitorovat. Takto BPMN pˇreklenuje hranici mezi modelováním procesu˚ a jejich implementací. —BPMN 1.2 Specifikace [8] 15
3.2. MODELOVÁNÍ 3.2.1.1 Elementy BPD Sada elementu˚ BPMN byla navržena tak, aby splnila již nˇekolikrát uvedené požadavky — snadnou cˇ itelnost a zárovenˇ vysokou expresivitu. Výsledkem je malá množina základních elementu˚ rozdˇelená do 4 kategorií. S rostoucí komplexitou procesu mužou ˚ být do diagramu pˇridány jemné variace jednotlivých elementu, ˚ aniž by to snížilo jeho cˇ itelnost. Jednotlivými konstrukty se budeme blíže zabývat v oddíle o BPMN 2.0, na tomto místˇe uvedeme pouze zminované ˇ kategorie elementu: ˚ 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ˇrují další informace o procesu a jednotlivých elementech (a) datový objekt (b) skupina (c) anotace
3.2.2
XPDL Tato verze specifikace nespecifikuje mechanismy pro výmˇenu BPMN diagramu. ˚ —BPMN 1.2 Specifikace [8]
XPDL, neboli XML Process Definition Language, je formát zajišt’ující pˇrenositelnost BPMN diagramu˚ mezi ruznými ˚ nástroji a produkty. Formát je odpovˇedí 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ˇcasná verze XPDL 2.1 dokáže vyjádˇrit vˇetšinu elementu˚ BPMN verze 1.1, nejedná se však o plné mapování 1:1. Velkým plusem je rozšiˇritelnost, výrobci modelovacích nástroju˚ tak mohou procesní definice obohacovat o vlastní metadata (dokumentace atd.) 16
ˇ 3.3. SPUŠT ENÍ
3.3
Spuštˇení
V této fázi vyvstává potˇreba pˇrevést procesní model do spustitelné formy. Výsledkem takovéhoto pˇrevodu je procesní definice v nˇejakém konkrétním jazyce. Taková definice je následnˇe spustitelná v bˇehovém prostˇredí daného jazyka (procesní engine). Transformace zahrnuje doplnˇení modelu o implementaˇcní detaily — promˇenné, algoritmy, nebo napˇríklad WSDL definice, pokud proces konzumuje nˇejakou WS-* službu. Spuštˇením procesní definice vzniká konkrétní instance procesu. 3.3.1
BPEL
BPEL je jazyk založený na XML, urˇcený k formálnímu popisu business procesu˚ složených z volání Webových služeb (webové služby ve smyslu standardu˚ 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ˇredí, které jej následnˇe interpretuje (spouští). [9] BPEL slouží k orchestraci služeb, tedy ke vhodné koordinaci volání jejich jednotlivých operací tak, aby tvoˇrily podnikový proces. Proces je rˇ ízen centrálnˇe a služby si nejsou vˇedomy toho, že jsou jeho souˇcástí. Sám proces je ve výsledku opˇet službou, muže ˚ být tedy souˇcástí nˇejakého procesu vyšší úrovnˇe. V souˇcasné dobˇe se jedná o nejpoužívanˇejší zpusob ˚ spouštˇení procesu. ˚ [9] Více detailu˚ o BPEL naleznete napˇríklad v [10]. 3.3.2
Od BPMN ke spuštˇení
V oddíle 3.2 jsme uvedli, že BPMN je de-facto standardem v oblasti modelování procesu, ˚ je tedy logické, chtít pˇrevádˇet 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ˇrinejmenším problematická. V souˇcasnosti se objevují dvˇe „ˇrešení“. Oblíbená je však kombinace obou. 3.3.2.1 Ruˇcní pˇrevod Jak již nadpis napovídá, jedná se o manuální pˇrevod BPMN do BPEL. Celý proces je v podstatˇe namodelován znovu (v proprietární notaci, resp. BPEL), ale s pˇrihlédnutím k implementaˇcním detailum. ˚ To, zda budou oba modely vyjadˇrovat totéž, záleží zejména na schopnostech a zkušenostech developera. 3.3.2.2 Mapování BPEL, jakožto XML formát, nemá žádnou konkrétní formu vizualizace. Mnohdy je nahrazován omezenou množinou grafických elementu˚ BPMN. Pro analytika je vytvoˇrena iluze modelování v BPMN, ve skuteˇcnosti jsou však jednotlivé konstrukty v reálném cˇ ase mapo17
3.4. MONITORING A OPTIMALIZACE vány na BPEL. Business analytik a vývojáˇr tedy používají pro popis procesu˚ tentýž jazyk, ale s ruznou ˚ mírou implementaˇcních detailu. ˚ 3.3.2.3 Dusledky ˚ Oba uvedené zpusoby ˚ mají znaˇcné nevýhody, v prvním pˇrípadˇe vzniká pˇri pˇrevodu nezanedbatelná entropie. Navíc dochází k narušení BPM cyklu — ve fázi optimalizace se lze pouze dohadovat, zda daný defekt, cˇ i úzké místo, vznikl pˇri modelování, nebo je výsledkem nepˇresného pˇrevodu. Ve druhém pˇrípadˇe je obˇcas množina elementu˚ omezena proto, že nˇekteré z nich je velice tˇežké namapovat na BPEL, nebo takové namapování nemusí být jednoznaˇcné — z toho plyne snížení expresivity dané pseudo-notace. Co je horší, takto vytvoˇrený proces je závislý na konkrétním nástroji — vzniká závislost na jednom výrobci (vendor lock-in). BPMN Modelovací nástroj 1
BPMN XPDL
Modelovací nástroj 2
BPMN 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ˇe procesního engine, tudíž je závislý na konkrétním produktu. Realita je ale taková, že témˇerˇ všechny volnˇe dostupné BPM nástroje nabízejí komponentu pro monitoring pouze pˇri zakoupení komerˇcní licence. Optimalizace nezávisí na žádné konkrétní technologii, pouze navrhuje možná zlepšení a opravu defektu˚ v dalších iteracích životního cyklu v závislosti na výsledcích bˇehu procesu.
3.5
BPMN 2.0
BPMN 2.0 (Business Process Model and Notation) je dlouho oˇcekávaná a nˇekolikrát odložená revize puvodní ˚ BPMN specifikace. Adresuje zejména problémy s pˇrenositelností, jed18
3.5. BPMN 2.0 noznaˇcnou formalizací (respektive serializací do XML) a spustitelností procesního modelu. V tuto chvíli je ve stádiu finalizaˇcní fáze (specifikace je ve verzi Beta2). Co jsou, mimo jiné, cíle BPMN2? • • • • •
3.5.1
navázat na pˇredchozí specifikace široká podpora nástroju˚ a výrobcu˚ možnost zobrazit stejný model s ruznou ˚ úrovní detailu˚ pˇrenositelnost mezi nástroji podpora automatizace (spustitelnosti) procesu˚
Meta-model
Jak již napovídá modifikace názvu standardu, nejzásadnˇejší zmˇenou oproti pˇredchozím specifikacím je definice meta-modelu jednotlivých konstruktu˚ (Abstract syntax meta-model). Zminovaný ˇ meta-model lze rozdˇelit do nˇekolika cˇ á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ˇe cˇ itelnou definici syntaxe — napˇríklad schéma ve formátu XSD.
•
Sémantika pro spuštˇení (execution semantics) — každý element má jasnˇe definované chování v pˇrípadˇe spuštˇení. Toto chování je jednoznaˇcné.
•
Notace — specifikace grafické notace každého elementu, souˇcástí je i specifikace povolených rozšíˇrení a modifikací této notace (barvy, vizuální styl atd.)
•
Meta-model pro pˇrenositelnost diagramu˚ (Diagram Interchange) — zachycuje grafickou reprezentaci diagramu ve smyslu rozvržení a pˇresné polohy jednotlivých elementu. ˚ Z meta-modelu je opˇet odvozeno i pˇríslušné XSD schéma.
Díky výše uvedeným principum ˚ lze v koneˇcné fázi namodelovaný proces reprezentovat jako XML — naplnˇení výše uvedených cílu˚ je tak cˇ istˇe implementaˇcním problémem. 3.5.2
Další zmˇeny
Mezi další zmˇeny oproti puvodní ˚ specifikaci patˇrí pˇridání nových typu˚ událostí a aktivit. Více detailu˚ naleznete ve specifikaci [11]. Podstatnou novinkou jsou dva nové typy diagramu˚ a také nové elementy pro zachycení choreografie v procesu. 3.5.2.1 Diagram kolaborace Tento typ diagramu má za úkol zachytit posílané zprávy mezi úˇcastníky procesu. V tomto diagramu jsou jednotliví úˇcastníci reprezentováni pomocí bazénu˚ a komunikace odpovídá tokum ˚ zpráv mezi nimi. 19
3.5. BPMN 2.0 3.5.2.2 Diagram konverzace Tento diagram je zjednodušenou podmnožinou diagramu kolaborace s tím, že se zamˇerˇ uje pˇrevážnˇe na vztah dvou a více rolí (úˇcastníku) ˚ — tj. zobrazuje role, které spolu komunikují conver (konverzují). V podstatˇe se jedná o souhrnný pˇrehled veškeré komunikace mezi úˇcastníky procesu. Reservation creation
Reservation manager
Customer
Reservation claim
Manager (or Waiter)
Obrázek 3.4: Diagram konverzace
3.5.2.3 Choreografie Choreografie je typ procesu, který se zamˇerˇ uje na výmˇenu zpráv (a její prubˇ ˚ eh) mezi úˇcastníky. Vyjadˇruje zpusob, ˚ jakým spolu úˇcastníci komunikují a jaké zprávy používají s ohledem na prubˇ ˚ eh procesu. Viz obrázek 3.5
choreo
Time
Reservation number
Customer
Customer
Create reservation
Have dinner Manager
Reservation manager
Waiter
Reservation number
Table number
Obrázek 3.5: Choreography diagram Daniel Tovarnak
1 of 1
20
3.6. ZÁKLADNÍ ELEMENTY BPMN 2.0 3.5.2.4 BPEL Mapování Souˇcástí specifikace, což muže ˚ být pˇrekvapivé, je i explicitní mapování BPMN schématu na BPEL proces. Je duležité ˚ podotknout, že specifikace klade dodateˇcné podmínky na podobu mapovaného procesu (zdrojový proces napˇríklad nemuže ˚ obsahovat smyˇcky). 3.5.3
Dusledky ˚
Je patrné, že použitím standardu BPMN 2.0 se lze vyhnout všem dosud zmínˇeným problémum ˚ a neduhum ˚ souvisejícím se starší verzí specifikace. Jde pˇredevším o univerzální pˇrenositelnost mezi nástroji, cˇ 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í dusledky. ˚ Fáze spuštˇení již nemusí znamenat transformaci procesu, ale pouze doplnˇení implementaˇcních detailu. ˚ Nasazením procesní definice do vhodného bˇehového prostˇredí lze teoreticky dosáhnou funkcionality ekvivalentní (ne-li lepší) s pˇrevodem do jazyka BPEL. Tento fakt rozdmýchává v BPM komunitˇe 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ˇeji popíšeme základní elementy a jejich variace dle specifikace BPMN 2.0. Podotknˇeme, že vˇetšina uvedených informací platí i pro pˇredchozí verzi standardu, jen rozdˇelení do kategorií se mírnˇe liší. Na tomto místˇe si uvedeme cˇ asto používané elementy také s ohledem na procesní modely uvedené v této práci. Nejlepším zdrojem pro hlubší studium zustává ˚ specifikace standardu. [11] tasks
3.6.1
Aktivity (Activities)
Task
User Task
Recieve Task
Service Task
Script Task
Manual Task
Obrázek 3.6: Tasky Aktivity pˇredstavují vykonání nˇejaké cˇ innosti v rámci procesu. Aktivitou muž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ˇcástí dané procesní definice a slouží pˇredevším 21
3.6. ZÁKLADNÍ ELEMENTY BPMN 2.0 k zpˇrehlednˇení diagramu. Na druhou stranu Call Activity je mechanismus urˇcený k volání (externích) znovupoužitelných procesu. ˚ •
Task pˇredstavuje atomickou cˇ innost v rámci procesu, kterou již nelze dále dˇelit.
•
User Task je cˇ innost vykonávaná cˇ lovˇekem za asistence softwarového vybavení, nebo procesního engine. Seznam uživatelských úkolu˚ musí být nˇejakým zpusobem ˚ dostupný a udržovaný (správce úkolu, ˚ workflow komponenta). Standard dále specifikuje zpusob ˚ pˇriˇrazování úkolu˚ jednotlivým úˇcastníkum. ˚
•
Manual Task je stejnˇe jako User Task cˇ innost vykonávaná cˇ lovˇekem, avšak bez úˇcasti SW vybavení.
•
Service Task nˇejakým zpusobem ˚ využívá automatizovanou službu, nebo aplikaci.
•
Script Task pˇredstavuje skript v nˇejakém jazyce, jež je interpretován bˇehovým prostˇredím. (Prostˇredí samozˇrejmˇe musí tento jazyk podporovat.)
•
Recieve Task cˇ eká na zprávu z externího zdroje. Po pˇrijetí zprávy je úkol považován za dokonˇcený a tok procesu dále pokraˇcuje.
Pro každou aktivitu muže ˚ být dále specifikována tzv. multiplicita — poˇcet a zpusob ˚ 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ˇcet opakování muže ˚ být vypoˇcítán dynamicky (at run-time). Jednotlivé instance aktivity mohou být vykonány paralelnˇe, nebo sekvenˇcnˇe.
3.6.2
Události (Events)
Události jsou pokroˇcilý zpusob, ˚ jak zachytit specifické dˇení v prubˇ ˚ ehu procesu. Události ovlivnují ˇ samotný tok procesu, mají nˇejakou pˇríˇcinu, nebo naopak dusledek, ˚ a vˇetšinou lze na nˇe nˇejakým zpusobem ˚ reagovat. Jelikož se jedná o dosti rozsáhlou problematiku uvedeme pouze základy. Kompletní pˇrehled událostí naleznete v dokumentaci standardu [11]. Události lze rozdˇelit do tˇrí základních skupin podle výskytu v životním cyklu procesu. • • •
Start Event pˇredstavuje vždy událost v místˇe, kde proces zaˇcíná. End Event pˇredstavuje vždy událost v místˇe, kde proces konˇcí. Intermediate Event Intermediate Event oznaˇcuje událost mezi zaˇcátkem a koncem procesu.
Každá událost má navíc jeden ze dvou druhu: ˚ 22
signals1
3.6. ZÁKLADNÍ ELEMENTY BPMN 2.0
Step 1
start at [11.11.2020 11:30]
Step 2
wait for message
throw signal
Obrázek 3.7: Události v procesu •
Události, jež cˇ ekají (catch) na spoušt’. Všechny události Start a nˇekteré události Intermediate cˇ ekají na spoušt’ (caching events).
•
Události, jež produkují (throw) nˇejakou hodnotu. Všechny události End a nˇekteré události Intermediate produkují nˇejakou hodnotu (throwing events).
•
Spolu s hodnotou je u throwing event produkována také pˇríslušná spoušt’, jež muže ˚ být zachycena událostí catching event.
signals2
Start Event
Intermediate event
End event
message
throwing timer
signal
Obrázek 3.8: Pˇrehled událostí Daniel Tovarnak
3.6.2.1 Typy událostí
1 of 1
Mezi cˇ asto používané typy událostí patˇrí napˇríklad: • • •
Message Event — událost má podobu zprávy v dohodnutém formátu. Timer Event — událost má podobu cˇ asového okamžiku (napˇr. 12. 12. 2012 10:30). Signal Event — událost má podobu interního signálu.
23
3.6. ZÁKLADNÍ ELEMENTY BPMN 2.0 3.6.3
Tok procesu (Sequence flow)
Pˇrechody mezi jednotlivými elementy vcelku intuitivnˇe pˇredstavuje tok procesu (Sequence Flow). Podmínˇegateways ný tok procesu (Conditional Sequence Flow) se používá pˇredevším u bran jako element, na nˇemž je definována podmínka. Tˇretí variantou je výchozí tok u brány (Default Sequence Flow).
Obrázek 3.9: Exclusive, Parallel, Inclusive, Event-Based a Complex Gateway
3.6.4
Brány (Gateways)
Brány poskytují podporu pro rozhodování a vˇetvení (fork) v procesu. Jestliže dorazí tok procesu k bránˇe, je na základˇe podmínek a typu brány rozhodnuto jakým zpusobem ˚ bude tok pokraˇcovat. Podmínky jsou definovány na odchozích (podmínˇených) tocích. Nˇekteré brány navíc mohou sloužit ke sjednocení toku˚ (join). Z pohledu simulace dodejme, že brána má vždy nulovou cenu a nulový cˇ as provedení. Uved’me si cˇ tyˇri v praxi používané brány. 3.6.4.1 Exclusive Gateway
gateway2
Pˇri vˇetvení je vybrán nejvýše 1 odchozí tok na základˇe definovaných podmínek. V praxi by to mˇel být právˇe jeden tok (tzn. alesponˇ jedna vˇetev by mˇela být pravdivá, nebo by mˇel být definován výchozí tok). Pˇri sjednocení toku˚ proces pokraˇcuje po pˇríchodu jakéhokoliv (jednoho) toku.
parallel gateway price > = 5000 parallel 1
step A
parallel 2
ex clusive gateway
step B price < 5000
Obrázek 3.10: Paralell a Exclusive Gateway v procesu
3.6.4.2 Parallel Gateway Tovarnak Paralelní bránaDaniel je prostˇ redek k práci s více soubˇežnými toky. Pˇri vˇetvení jsou paralelnˇe spuš- 1 of 1 tˇeny všechny odchozí toky. Pˇri sjednocení je paralelní brána synchronizující — proces po-
24
3.6. ZÁKLADNÍ ELEMENTY BPMN 2.0 kraˇcuje pouze po pˇríchodu všech toku. ˚
3.6.4.3 Inclusive Gateway Mužeme ˚ rˇ íci, že tato brána je v podstatˇe kombinací pˇredchozích dvou pˇrípadu. ˚ Pˇri vˇetvení muže ˚ být vybrána jakákoliv kombinace odchozích toku˚ (0..n) a tyto toky mohou bˇežet paralelnˇe. V praxi by však mˇel být vybrán alesponˇ 1 tok. Použití této brány pro sjednocení gateway3 je trošku problematické — je tˇreba explicitnˇe definovat synchronizaci. Požadované chování však muže ˚ být docíleno použitím kombinace ostatních bran.
synchronizing? price > 10000 step1
step 2
default
step 3
Obrázek 3.11: Inclusive Gateway
3.6.4.4 Event-based Gateway gateway4
V podstatˇe se jedná o Exclusive Gateway založenou na událostech. Tato brána vybere jednu vˇetev v závislosti na dané události. Nelze ji použít pro sjednocení toku. ˚
Handle message
Handle SMS
Time out
Obrázek 3.12: Event-based Gateway
Daniel Tovarnak
1 of 1
25
3.7. BPM SOFTWARE 3.6.5
Bazény a plavecké dráhy (Pools and Swimlanes)
Bazén pˇredstavuje autonomního úˇcastníka procesu, nejˇcastˇeji ve smyslu samostatného systému. Komunikace mezi jednotlivými úˇcastníky (bazény) má podobu toku zpráv (Message Flow). Hlavním cílem bazénu˚ je zvýšit pˇrehlednost a vypovídající hodnotu diagramu. Bazén, který obsahuje námi modelovaný proces vˇetšinou pˇrestavuje systém, jež máme pod kontrolou, nebo je pˇredmˇetem našeho zájmu — nˇekdy též bílá skˇrínka. ˇ Naopak externí úˇcastník bývá cˇ asto zobrazen jako prázdný bazén — cˇ erná skˇrínka. ˇ
3.6.5.1 Plavecké dráhy Plavecká dráha se vyskytuje vždy uvnitˇr bazénu a slouží k jeho logickému (vizuálnímu) rozdˇelení. Je tˇreba zduraznit, ˚ že význam drah není nijak specifikován a je plnˇe v rukou modeláˇre. Nejˇcastˇeji jsou dráhy používány k vyjádˇrení rolí participujících v procesu.
Assign topic
Student
System
Lector
pools-lanes
Write essay
Upload essay
Ex ternal system Obrázek 3.13: Plavecké dráhy a bazény
3.7
BPM software
V pˇredchozích odstavcích jsme shrnuli všechny souˇcasné standardy procesního rˇ ízení. Nyní si v krátkosti pˇredstavme konkrétní nástroje a SW produkty, jež mohou být reálnˇe použity v BPM projektech. Pˇredmˇetem našeho zájmu jsou hlavnˇe open-source rˇ ešení.
3.7.1
Procesní engine
Procesní engine je komponenta, která interpretuje (spouští) konkrétní procesní definici v daném jazyce. Uved’me dva nejznámˇejší zástupce pro jazyky BPEL a jPDL. 26
Daniel Tovarnak
1 of 1
3.7. BPM SOFTWARE 3.7.1.1 Apache ODE (Apache License v2) ODE (Orchestration Director Engine) je procesní engine kompatibilní se standardem WSBPEL. ODE se rˇ adí mezi nejpoužívanˇejší open-source bˇehová prostˇredí pro jazyk BPEL a to také díky skvˇelému výkonu. Navíc nabízí mnoho rozšíˇrení (podpora pro REST atd.) nad rámec specifikace. Více na . 3.7.1.2 jBPM (LGPL) jBPM neboli JBoss Business Process Management je procesní engine pro BPEL a jPDL. Po svém uvedení zaznamenalo jBPM obrovský úspˇech a miliony stažení. Po odchodu hlavních vývojáˇru˚ na jaˇre 2010 však nad jBPM visí otazník. Bˇehové prostˇredí je založeno na principu tzv. Process Virtual Machine, jež umožnuje ˇ jednoduchou adopci nových procesních jazyku. ˚ Více o principech PVM naleznete v oddíle 4.1.1. Další informace o projektu se nachází na . 3.7.2
BPMS
BPMS neboli Business Process Management Suite je SW produkt (nebo skupina produktu), ˚ jež implementuje vhodné standardy a poskytuje technologickou podporu pro již mnohokrát zmínˇené etapy životního cyklu (pˇrevážnˇe pro 2 a 3 etapu). Pˇrechod mezi jednotlivými etapami je plynulý a celý cyklus probíhá v unifikovaném prostˇredí. Vˇetšina BPMS produktu˚ používá (v poslední dobˇe velmi oblíbený) obchodní model, založený na vlastní open-source komunitˇe.1 Základní verze produktu je vždy distribuována pod nˇejakou open-source licencí, v kontrastu s komerˇcní edicí produktu, jež vˇetšinou zahrnuje technickou podporu, rozšíˇrené možnosti integrace, cˇ i sofistikovanˇejší komponenty. 3.7.2.1 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ˇcním produktum. ˚ Produkt staví na tˇrech základních komponentách. Více o BOS lze nalézt napˇríklad v [12] a také na. Bonita Studio Hlavní vývojové a modelovací prostˇredí, vybudované nad platformou Eclipse, poskytuje uživatelum ˚ funkcionalitu pro modelování, simulaci a implementaci business procesu. ˚ Pro modelování je použita upravená notace BPMN 1.2. Implementace procesu zahrnuje tvorbu uživatelských formuláˇru, ˚ mapování dat a doplnˇení tzv. konektoru. ˚ Konektory mají podobu Java tˇríd a jsou hlavním prostˇredkem k programové implementaci procesu. Mohou sloužit k 1. Cesta k tomuto modelu mívá dva scénáˇre — komercializace open-source projektu, nebo naopak otevˇrení zdrojových kódu˚ komerˇcního produktu.
27
3.7. BPM SOFTWARE interakci s bˇehovým prostˇredím, databází, LDAP serverem, cˇ i produkty tˇretích stran. Namodelovaný a implementovaný proces má podobu archivu, jež obsahuje veškeré programové komponenty potˇrebné ke spuštˇení. Proces samotný je uložen jako proprietární XML. Bonita Execution Engine Bˇehové prostˇredí nástroje Bonita poskytuje programové API pro spouštˇení a správu implementovaných procesu. ˚ Procesní engine lze nasadit do vˇetšiny bˇežných aplikaˇcních serveru. ˚ K zajištˇení persistence je použit framework Hibernate, z cˇ eho plyne vcelku bohatá podpora databází. Zajímavostí je celkem dobˇre dokumentované, pomˇernˇe kompletní REST API a také zabudovaná workflow komponenta. Bonita User Experience Poslední komponentou je webová aplikace, která pˇredstavuje kompletní uživatelské rozhraní pro správu procesu, ˚ monitoring bˇehového prostˇredí, a navíc poskytuje podporu pro uživatelskou interakci s procesy. Aplikace je multijazyˇcná a snadno integrovatelná, dovoluje však pouze omezené možnosti uživatelských úprav (s vynaložením rozumného úsilí). 3.7.2.2 Intalio|BPMS Intalio je spoleˇcnost, jež se v souˇcasné dobˇe zamˇerˇ uje na poskytování širokého portfolia aplikací, služeb a integraˇcních rˇ ešení pro cloud computing. Souˇcástí vývojových aktivit je také standalone BPMS nástroj s pˇríznaˇcným názvem. I pˇres svoji lehce omezenou funkcionalitu je open-source edice mezi vývojáˇri velmi oblíbená. Produkt lze rozdˇelit na dvˇe zásadní komponenty. Intalio|Designer Intalio|Designer je samostatný nástroj urˇcený pro business analytiky, softwarové inženýry a administrátory. Poskytuje podporu pro tvorbu procesních modelu˚ a následné provázání procesu s externími systémy a uživatelskými rozhraními. Výsledný proces lze následnˇe jednoduše spustit v bˇehovém prostˇredí Intalio|BPMS Server. Podotknˇeme, že modelování probíhá v upravené BPMN 1.2 notaci. Po každém uložení je proces automaticky pˇreložen do spustitelné podoby ve formátu BPEL 2.0. Nástroj je dostupný jako samostatná aplikace, nebo jako sada pluginu˚ 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ˇetnou kompatibilitu modelovaných procesu˚ a také zaruˇcuje 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živatel28
3.7. BPM SOFTWARE ských formuláˇru. ˚ Obˇe komponenty jsou dostupné skrze jednotné uživatelské rozhraní v podobˇe webové aplikace. Ke komunikaci se serverem lze alternativnˇe využít sadu WS-* služeb. 3.7.3
Activiti BPM
Ponˇekud stranou stojí BPM nástroj Activiti, urˇcený pro jazyk BPMN2. Aˇc je jeho souˇcástí plnohodnotný procesní engine (production-ready), obsahuje také sadu doplnující ˇ nástroju, ˚ jež jsou urˇceny pro podporu jednotlivých etap BPM cyklu — ty se však stále nachází ve fázi vývoje. Activiti tedy nelze zaˇradit cˇ istˇe mezi ostatní bˇehová prostˇredí, avšak oznaˇcení BPMS je také pˇrinejmenším nepˇresné. Pˇri výbˇeru stˇežejní technologie pro praktickou cˇ ást práce padlo rozhodnutí právˇe na procesní engine nástroje Activiti BPM. Aˇc je na BPM trhu absolutní novinkou, poskytovaná funkcionalita by mˇela být dostaˇcující pro naše úˇcely. Duležitou ˚ roli hrál také stav dokumentace, podpora vývojáˇru˚ a flexibilita daného rˇ ešení. Nejvˇetší váhu mˇel však fakt, že se jedná o engine založený na BPMN 2.0 — vznikla tak jedineˇcná možnost analyzovat hloubˇeji vu˚ bec první procesní engine pro tento standard. Duvodem ˚ byl také zpusob, ˚ jakým Activiti pˇristupuje ke tvorbˇe aplikací založených na procesech a procesním rˇ ízení.
29
Kapitola 4
Activiti BPM V této kapitole si blíže pˇredstavíme projekt Activiti, a to zejména jeho hlavní komponentu — procesní engine. Budeme se zabývat pˇredevším funkcionalitou a architekturou tohoto bˇehového prostˇredí, vˇcetnˇe technických detailu. ˚ Vˇetší polovinu této kapitoly pojmeme jako základní technickou prupravu, ˚ jež pomuže ˚ cˇ tenáˇri lépe se orientovat v následujících kapitolách. Activiti je Business Process Management a worklflow systém, zamˇerˇ ený na business uživatele, vývojáˇre 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 projektu1 Activiti je vyvíjeno pod taktovkou nˇekolika velkých hráˇcu˚ souˇcasné BPM a enterprise sféry. Jedná se pˇredevším o spoleˇcnosti stavˇející na open-source vývoji. Patˇrí mezi nˇe napˇríklad: Alfresco, spoleˇcnost vyvíjející stejnojmenný systém pro správu obsahu (Enterprise Content Management), SpringSource, jež stojí za vývojem aplikaˇcního rámce Spring, Signavio, tvurce ˚ úspˇešného BPM editoru, Camunda, specializující se na tvorbu komplexních BPM systému˚ a MuleSoft, tvurce ˚ oblíbené integraˇcní platformy. Nejvˇetší devizou Activiti je jistˇe flexibilní procesní engine, na jehož základˇe lze vybudovat vaši BPM aplikaci, nebo dokonce vlastní BPMS. Bˇehové prostˇredí podporuje uspokojivou škálu cˇ asto používaných databází a témˇerˇ všechny bˇežné aplikaˇcní servery, pˇriˇcemž prioritou do budoucna je nadále rozšiˇrovat možnosti integrace s dalšími technologiemi a produkty (integrace s Mule ESB, kompatibilita s OSGi, atd.). Souˇcástí distribuce je i sada doplnujících ˇ komponent zamˇerˇ ených na jednotlivé etapy životního cyklu. Samotní autoˇri dodávají, že zatímco vynikající engine je nutností, hlavním cílem je na jeho základˇe vytvoˇrit kvalitní nástroje. Dodejme, že na rozdíl od bˇehového prostˇredí, nejsou jednotlivé komponenty zatím použitelné v produkˇcním nasazení. Nástroje mají podobu samostatných webových aplikací. •
1.
Activiti Cycle – nástroj zamˇerˇ ený na podporu spolupráce více lidí pˇri modelování a automatizaci procesu. Má za úkol zejména pˇreklenout pˇrechod mezi business svˇetem a vývojáˇri.
30
4.1. ACTIVITI BPM ENGINE
Obrázek 4.1: Activiti BPM [] •
Activiti Probe – rozhraní pro monitoring a kompletní správu bˇehového prostˇredí — sledování instancí procesu, ˚ správa procesních definic, monitoring procesu. ˚
•
Activiti Explorer – uživatelské rozhraní pro interakci s bˇehovým prostˇredím (správa uživatelských úkolu, ˚ spouštˇení procesních definic atd.). V podstatˇe lze oznaˇcit jako uživatelské rozhraní pro workflow.
•
Activiti Modeler – nástroj pro modelování procesu, ˚ založený na projektech Oryx a Signavio Modeler.
4.1
Activiti BPM Engine
Nejpodstatnˇejší komponentou Activiti, ke které smˇerˇ uje i náš zájem, je jeho procesní engine. Jedná se v podstatˇe o evoluci jBPM — bˇehové prostˇredí je postaveno na principu známém jako Process Virtual Machine (PVM). PVM je architektonická vrstva, na jejímž základˇe je vybudována podpora pro konkrétní procesní jazyk (viz dále). Mezi základní vlastnosti tohoto bˇehového prostˇredí patˇrí: • •
Vysoký výkon Stabilita 31
4.1. ACTIVITI BPM ENGINE • • •
Snadná customizace Podpora transakcí Podpora asynchronních úkolu˚
Runtime Service
Form Service
BPMN 2.0 Support
Process Virtual Machine
Persistence layer
...
Task Service
Obrázek 4.2: Procesní engine Activiti
4.1.1
Process Virtual Machine
Velmi zjednodušenˇe PVM vychází z faktu, že proces je zárovenˇ graf — množina uzlu˚ a pˇrechodu˚ — PVM tedy implementuje základní funkcionalitu pro pohyb v takovémto grafu. Pravidla pro tvar procesu˚ pˇredepisuje syntaxe konkrétního jazyka. Chování uzlu˚ a pˇrechodu˚ 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ˇejší popis principu˚ Process Virtual Machine cˇ tenáˇre odkážeme na [13]. Programové komponenty, jež jsou vybudovány kolem PVM, tvoˇrí následnˇe funkcionalitu celého bˇehového prostˇredí. •
Management Service obstarává funkcionalitu pro spouštˇení dlouhotrvajících úkolu˚ a poskytuje rozhraní pro získávání informací o persistentním úložišti.
•
Identity Service obstarává všechny potˇrebné funkce pro správu uživatelu˚ 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 artefaktu. ˚ 32
4.1. ACTIVITI BPM ENGINE •
Form Service slouží k naˇcítání a renderování formuláˇru˚ pro interakci z uživatelem.
•
Runtime Service je služba pro správu, spouštˇení a interakci s bˇežícími procesy (instancemi procesu). ˚
•
History Service slouží jako základní komponenta pro monitoring procesu. ˚
Obrázek 4.3: Programové API Activiti [15]
4.1.2
Programové api
Jestliže je procesní engine použit jako samostatná programová komponenta ve vaší aplikaci, nejˇcastˇejší zpusob ˚ práce s ním je skrze programové API. Na obrázku 4.3 vidíme strukturu tohoto API. Ze všeho nejdˇríve je potˇreba instanicovat vlastní bˇehové prostˇredí, k cˇ emuž slouží tˇrída ProcessEngineConfiguration. Nejbˇežnˇejším zpusobem ˚ práce s touto tˇrídou je naˇctení konfiguraˇcního souboru, na jehož základˇe je následnˇe engine instanciován. ProcessEngine engine = ProcessEngineConfiguration. createProcessEngineConfigurationFromResource("config.xml"). buildProcessEngine();
4.1.2.1 Konfiguraˇcní soubor config.xml je konfiguraˇcní soubor, obsahující zejména nastavení persistentního úložištˇe, pˇrípadnˇe konfiguraci ostatních programových komponent (poštovní server atd.) Ponˇekud matoucí muže ˚ být fakt, že se sice jedná o konfiguraˇcní soubor pro framework Spring, ale je použit pouze internˇe, bez jakékoliv závislosti na Spring kontejneru. O skuteˇcné podpoˇre rámce Spring pojednává oddíl 4.3 <property name="databaseType" value="mysql" /> <property name="jdbcUrl" value="jdbc:mysql://localhost:3306/dbschema" /> <property name="jdbcDriver" value="com.mysql.jdbc.Driver" /> <property name="jdbcUsername" value="josef" /> <property name="jdbcPassword" value="josef" /> <property name="mailServerHost" value="smtp.mymail.cz" /> <property name="mailServerPort" value="5025" />
4.1.2.2 Pˇrístup ke komponentám Jednotlivé komponenty jsou po instanciování bˇehového prostˇredí pˇrístupné v následujícím duchu: RuntimeService runtimeService = engine.getRuntimeService(); IdentityService identityService = engine.getIdentityService(); ... TaskService taskService = engine.getTaskService();
Rozepisovat se nˇejak sáhodlouze o jednotlivých metodách a tˇrídách, jež jsou k dispozici ve zminovaných ˇ komponentách, by bylo mrháním cˇ asu jak cˇ tenáˇre, tak autora této práce. Nejlepším zdrojem pro hlubší studium je jistˇe Javadoc API bˇehového prostˇredí [14]. My se spokojíme s nˇekolika ilustraˇcními pˇríklady. /* Aktuálnˇ e bˇ ežící instance */ List instances = runtimeService. createProcessInstanceQuery().list(); /* Deployment BPMN2 procesní definice */ repositoryService.createDeployment(). addClasspathResource("definition.bpmn20.xml").deploy();
4.1.3
Persistence
Veškeré artefakty, stav bˇežících procesu, ˚ promˇenné, cˇ i procesní definice, nutné k bˇehu Activiti engine jsou v reálném cˇ ase ukládány do persistentního úložištˇe. Toto rˇ ešení dovoluje zotavení bˇehového prostˇredí po pádu, cˇ i restartu systému. Velkým plusem je také podpora transakcí jakožto prostˇredku pro zajištˇení integrity dat. Mezi souˇcasnˇe podporované databáze patˇrí: H2, MySQL, Postgres, cˇ i Oracle. 4.1.4
Workflow
Workflow komponenta je nedílnou souˇcástí procesního engine, konkrétnˇe služba TaskService poskytuje veškerou nutnou funkcionalitu pro práci s uživatelskými úkoly. 34
4.2. REST API KOMPONENTA /* Všechny úkoly (workitems) uživatele franta */ List tasks = taskService.createTaskQuery(). taskAssignee("franta").list(); Task task = tasks.get(0); /* Splnˇ ení daného úkolu */ taskService.complete(task.getId());
4.2
REST API Komponenta
Procesní engine lze využít také jako externí službu vnˇe aplikace — bˇehové prostˇredí je spolu s REST API komponentou nasazeno ve vhodném aplikaˇcním serveru a komunikace probíhá v podobˇe HTTP požadavku˚ na webovou službu. Možnou nevýhodou tohoto pˇrístupu muže ˚ být o nˇeco menší flexibilita. Dodejme, že REST API je autory zatím oznaˇcováno jako experimentální a množina podporovaných operací není nijak závratnˇe velká. Kompletní API lze nalézt v dokumentaci [15]. 4.2.1
Pˇríklad požadavku
Formát, ve kterém se komunikuje, je JSON (JavaScript Object Notation), v následujícím jednoduchém pˇríkladˇe pˇredpokládáme, že základní adresa na kterou smˇerˇ ujeme požadavky má napˇríklad tvar . # POŽADAVEK, Všechny úkoly uživatele franta GET http://localhost:8080/activiti-rest/service/tasks?assignee=franta # ODPOVˇ Eˇ D { "data": [ { "id": 127, "name": "Write homework", "description": "Write assigned essay", "priority": 70, "assignee": franta, "executionId": 158, "formResourceKey": "cz/muni/fi/xtovarn/essay.form" } ], "total": 1, "start": 0, "sort": "id", "order": "asc", "size": 1 }
35
4.3. SPRING
4.3
Spring
Activiti podporuje aplikaˇcní rámec Spring2 , což znaˇcnˇe zvyšuje jeho integraˇcní potenciál. Procesní engine muže ˚ být zpˇrístupnˇen v Inversion of Control (IOC) kontejneru jako bean komponenta, a naopak bˇežící procesy mohou využívat ostatní definované komponenty (napˇríklad Quartz Scheduler, cˇ i Hibernate). Použití Springu a Dependency Injection paradigmatu navíc znaˇcnˇe ulehˇcuje a zpˇrehlednuje ˇ vývoj. Dalším nezanedbatelným pˇrínosem je napˇríklad pokroˇcilé rˇ ízení transakcí. Útržek smyšleného (Spring) konfiguraˇcního souboru spring-config.xml je uveden níže. <property name="targetDataSource"> <property name="driverClass" value="com.mysql.jdbc.Driver"/> ... <property name="dataSource" ref="dataSource"/> <property name="transactionManager" ref="transactionManager"/> <property name="databaseType" value="mysql"/> <property name="processEngineConfiguration" ref="processEngineConfiguration"/> ...
Procesní engine je následnˇe instanciován z aplikaˇcního kontextu, jež je urˇcen danou konfigurací. Od této chvíle je práce s bˇehovým prostˇredím stejná jako v pˇrípadˇe instanciace skrze programové API v kombinaci se samostatným konfiguraˇcním souborem. ProcessEngine engine = (ProcessEngine) new ClassPathXmlApplicationContext("cz/examples/spring-config.xml"). getBean("processEngine"); 2.
36
4.4. PODPORA BPMN2
4.4
Podpora BPMN2
Z pohledu procesního rˇ ízení nás pˇredevším zajímá, jak velká je množina podporovaných elementu˚ a konstruktu˚ standardu BPMN 2.0., to jest tˇech, které jsou spustitelné v bˇehovém prostˇredí. Procesní definice pro Activiti engine má podobu XML souboru, jež je validní vuˇ ˚ ci BPMN2 schématu. Prázdnou procesní definici pˇredstavuje pˇríklad 4.4.1. Nˇekteré konstrukty mužou ˚ být pro vývojáˇre trošku tˇežkopádné a tak jsou, zcela v souladu se standardem, zavedena rozšíˇrení, jež jsou specifická pro Activiti engine. Tato rozšíˇrení splnují ˇ dvˇe základní pravidla: • •
procesní definice, jež obsahuje rozšíˇrení, musí být transformovatelná na standardní BPMN2 XML všechna rozšíˇrení jsou uvozena vlastním jmenným prostorem
<definitions id="definitions" ...> <process id="myProcessDefinition" name="Blank definifiton"> ...
Pˇríklad 4.4.1: Prázdná procesní definice Pokud není uvedeno jinak, odpovídá sémantika standardu BPMN 2.0 a pˇríkladum ˚ uveˇ deným v pˇredchozí kapitole. Ctenᡠr necht’ prosím omluví anglické názvy jednotlivých elementu, ˚ cˇ eský pˇreklad by byl u nˇekterých pˇrinejmenším krkolomný. Všechny aktuálnˇe podporované konstrukty a jejich detailní popis lze nalézt v dokumentaci [15]. Seznam v souˇcasnosti podporovaných elementu˚ následuje. • • • • • • • • • • • • • •
None Start Event None End Event Sequence Flow Conditional Sequence Flow Exclusive Gateway Parallel Gateway Script Task User Task (Java) Service Task Email Task Manual Task Sub Process Call Activity Timer Boundary Event
37
4.4. PODPORA BPMN2 4.4.1
Pˇríklady
4.4.1.1 None Start Event <startEvent id="start" name="My Start Event" />
Jelikož se jedná o tzv. prázdnou událost, musí být procesní definice spuštˇena externˇe. Budeme-li se držet zatím uvedených pˇríkladu, ˚ mohlo by to vypadat nˇejak takto: runtimeService.startProcessInstanceByKey("myProcessDefinition");
4.4.1.2 Conditional Sequence Flow <sequenceFlow id="flow" sourceRef="start" targetRef="someTask"> 18}]] >
4.4.1.3 Script Task <scriptTask id="scriptTask" name="Greet from script" scriptFormat="groovy"> <script> System.out.println("Hello from script!");
Script Task používá skriptovací engine založený na standardu JSR-223 (skriptování v Javˇe). Skript muže ˚ být tedy v libovolném jazyce pro nˇejž existuje JSR-223 kompatibilní knihovna. 4.4.1.4 User Task Podstatu uživatelských aktivit jsme si vysvˇetlili v oddíle o BPMN2 (3.5). Každý aktivní úkol je k dispozici pˇres službu TaskService. Ukažme si na pˇríkladu, jak jsou tasky rozdˇelovány mezi participanty procesu, respektive uživatele, kteˇrí jsou definováni v procesním engine. <userTask id="essayTask" name="Write essay"> josef
Takto zapsaný task je pˇrímo pˇriˇrazen uživateli s id josef a ten se stává jeho vlastníkem (assignee). Všechny úkoly daného uživatele, lze získat napˇríklad takto: 38
ˇ 4.5. PROCESNÍ ENGINE DETAILN EJI taskService.createTaskQuery().taskAssignee("josef").list();
Druhou možností je nepˇriˇrazovat task pˇrímo, ale radˇeji definovat tzv. kandidátní vlastníky — každý kandidátní vlastník má právo stát se vlastníkem úkolu. <userTask id="feedBack" name="Provide Feedback"> <potentialOwner> user(josef), group(students)
V uvedeném pˇríkladu jsou kandidátními vlastníky uživatel josef a všichni uživatelé ve skupinˇe students. Dodejme, že task muže ˚ mít jen jednoho vlastníka a pouze ten jej muže ˚ prohlásit za splnˇený. taskService.complete("taskId", "josef");
4.4.1.5 (Java) Service Task Java Service Task je hlavní prostˇredek, jak implementovat uživatelskou funkcionalitu v procesu. Nejˇcastˇeji se jedná o volání speciální externí Java tˇrídy, která implementuje rozhraní org.activiti.engine.delegate.JavaDelegate. Více napˇríklad v oddíle 4.6.1. <serviceTask id="javaService" name="Java Service Task" activiti:class="cz.example.SomeLogic" />
4.5
Procesní engine detailnˇeji
Nˇekteré z pokroˇcilých vlastností bˇehového prostˇredí lze vysvˇetlit až v tuto chvíli, kdy má cˇ tenáˇr dostateˇcnou pˇredstavu o jeho základních principech. Jedná se pˇredevším o detaily související s nˇekterými ze služeb. 4.5.1
Promˇenné
V rámci bˇehového prostˇredí má každá procesní instance možnost práce s promˇennými. Tyto promˇenné jsou následnˇe dostupné jak pˇres programové API, tak zejména v procesní definici díky tzv. výrazum ˚ (viz dále). K pˇrístupu k promˇenným pˇres programové API slouží zejména služba RuntimeService. Pˇríklad níže ukazuje, jak lze nastavit promˇenné pˇri startu nové instance, nebo pˇri dokonˇcení uživatelského tasku. Map<String, Object> map = new HashMap<String, Object>(1); map.put("string_var", "String Variable");
39
ˇ 4.5. PROCESNÍ ENGINE DETAILN EJI
runtimeService.startProcessInstanceByKey("myProcessDefinition", map); Map<String, Object> map2 = new HashMap<String, Object>(1); map2.put("bool_var", true); taskService.complete("taskId", map2);
4.5.2
Výrazy
Souˇcástí bˇehového prostˇredí je komponenta pro vyhodnocování UEL (Unified Expression Language) výrazu, ˚ respektive engine JUEL pro jazyk Java. Výrazy jsou urˇceny zejména k použití v procesních definicích. Díky nim lze pˇristupovat k promˇenným dané procesní instance, ale také k definovaným bean komponentám. V následujícím pˇríkladˇe ilustrujeme použití obou zmínˇených typu˚ výrazu. ˚ <sequenceFlow id="flow" sourceRef="start" targetRef="springTask"> <serviceTask id="springTask" name="Spring java service" activiti:expression="${springBean.function()}" />
4.5.3
Formuláˇre
Uživatelská interakce s procesem je zajištˇena díky zabudované podpoˇre formuláˇru. ˚ For3 muláˇre lze definovat pomocí atributu activiti:formKey, jež pˇredstavuje jeho unikátní identifikátor. Procesní engine dovoluje dva odlišné pˇrístupy k práci s formuláˇri, a to ve smyslu jejich renderování. <userTask id="handleRequest" name="Submit review" activiti:formKey="cz/examples/forms/review.form"> ...
4.5.3.1 Interní rendering Pˇri interním renderingu je generování formuláˇru˚ záležitostí procesního engine. V tomto pˇrípadˇe již zmínˇený atribut pˇredstavuje odkaz na reálný HTML formuláˇr, respektive na šablonu formuláˇre v nˇejakém znaˇckovacím jazyce (který je podporován bˇehovým prostˇredím). Ve formuláˇri se mohou objevit také výrazy, o nichž jsme pojednávali výše. 3. Pouze na elementu startEvent (proces je spuštˇen na základˇe uživatelských dat) a samozˇrejmˇe na elementu pro uživatelský úkol (userTask).
40
ˇ 4.6. P RÍKLAD 4.5.3.2 Externí rendering Druhou možností je generování odkazovaného formuláˇre vlastními prostˇredky mimo bˇehové prostˇredí. Atribut activiti:formKey muže ˚ být navíc použit jako pouhý identifikátor libovolného formuláˇre v rámci externí aplikace. V obou pˇrípadech je tak zpusob ˚ vygenerování daného formuláˇre zcela v rukách vývojáˇre.
4.6
Pˇríklad
V rámci této kapitoly vznikl také malý pˇríklad, jež má za úkol demonstrovat nˇekteré z faktu, ˚ které jsme si uvedli. Jedná se o procesní variaci na obligátní pˇríklad všech knih o programoHelloWorld vání — Hello World. Dodejme, že kompletní zdrojové kódy jsou souˇcástí pˇríloh této práce. Podrobnˇejší informace a pokyny pro spuštˇení naleznete také v Pˇríloze A.
Get name
Say Hello
Obrázek 4.4: Hello World — proces Obrázek výše pˇredstavuje jednoduchý proces namodelovaný v BPMN2. Service Task Get name má za úkol naˇcíst jméno z konzole, Script Task Say Hello toto jméno vytiskne na obrazovku. Pˇríklad níže pˇredstavuje spustitelnou procesní definici (neboli implementaci procesu). <definitions ...> <process id="helloWorld"> <startEvent id="theStart"/> <serviceTask id="javaService" name="Get name" activiti:class="cz.muni. ... .ConsoleReader"/> <scriptTask id="theScriptTask" name="Say Hello" scriptFormat="groovy"> <script> System.out.println("Hello " + name + "!!") <endEvent id="theEnd"/> <sequenceFlow id="flow1" sourceRef="theStart" targetRef="javaService"/> <sequenceFlow id="flow2" sourceRef="javaService"
41
Daniel Tovarnak
1 of 1
ˇ 4.6. P RÍKLAD targetRef="theScriptTask"/> <sequenceFlow id="flow3" sourceRef="theScriptTask" targetRef="theEnd"/>
4.6.1
Service Task (serviceTask)
Tˇrída ConsoleReader obsahuje potˇrebnou logiku pro naˇctení vstupu a jeho uložení do promˇenné name. Dle požadavku na Java Service Task musí tato tˇrída implementovat rozhraní org.activiti.engine.delegate.JavaDelegate (viz pˇríklad níže). public class ConsoleReader implements JavaDelegate { public void execute(DelegateExecution execution) throws Exception { Scanner sc = new Scanner(System.in); String input = null; while (input == null || input.equals("")) { System.out.println("Please type your name and press ENTER:"); input = sc.nextLine(); } /* Set variable name, which is later used in Script Task */ execution.setVariable("name", input); } }
Pˇríklad 4.6.1: Tˇrída ConsoleReader
42
Kapitola 5
Modelový proces kurzu Communication and Soft Skills Jako modelový proces pro praktickou cˇ ást byl vybrán výukový proces kurzu PV206 — Communication and Soft Skills, vyuˇcovaný na FI MU profesorkou Renate Motschnig z Vídenské ˇ univerzity. V této kapitole krátce popíšeme prubˇ ˚ eh vytváˇrení procesního modelu a zejména pˇredstavíme proces samotný. Dodejme, že výsledný proces nemusí zcela pˇresnˇe kopírovat skuteˇcnost, ale jako ilustrace výukového procesu je více než dostateˇcný.
5.1
Kurz Softskills
Cílem kurzu je pomoci studentum ˚ zlepšit schopnosti v ohledech komunikace, týmové práce, moderace a dalších tzv. soft-skills a to ohledem na požadavky studentu˚ samotných. V pru˚ bˇehu kurzu budou studenti sdílet své názory a zkušenosti v následujících oblastech: active listening, komunikace zamˇerˇ ená na cˇ lovˇeka, moderaˇcní schopnosti, budování týmu, rˇ ízení konfliktu˚ a pˇríbuzná témata. [16]
5.2
Návrh procesu
Jako prvotní návrh procesu posloužil typický scénáˇr kurzu PV206, vypracovaný paní profesorkou Motschnig a pˇripomínkovaný vedoucím práce. Originální scénáˇr je souˇcástí pˇríloh této práce. Shrnme ˇ nejduležitˇ ˚ ejší body. 5.2.1
Role
• • • •
Lektor (Course owner) Student Cviˇcící (Tutor) Tým (Team)
5.2.2
Potˇrebné komponenty
• • •
Diskusní fórum Formuláˇre pro zpˇetnou vazbu Sdílení souboru˚ 43
5.3. MODELOVÁNÍ PROCESU • • •
Fotogalerie Správa témat Pˇrihlašování do kurzu
5.2.3 • • • • • • •
Tvorba týmu˚ a týmových rolí Pˇríprava prezentací každého týmu Prezentace každého týmu Zpˇetná vazba na prezentace týmu˚ Zpˇetná vazba na podobu kurzu Obrazová dokumentace pˇrednášek Hodnocení lektorem
5.2.4 1. 2. 3. 4. 5. 6. 7.
5.3
Základní aktivity
Struˇcný scénáˇr kurzu Pˇríprava kurzu Seznámení s kurzem Pˇrednes teorie Sestavení týmu˚ Pˇríprava prezentací Prezentace Hodnocení
Modelování procesu
Prvotní model procesu vytvoˇril kolega Jiˇrí Novák. Do následujících iterací se zapojil pˇredevším autor této práce a pˇripomínky poskytl vedoucí práce. Proces je namodelován v jazyce BPMN 2.0. Spolupráce na procesním modelu byla ulehˇcena výbˇerem vhodného nástroje. K modelování byla použita modelovací platforma spoleˇcnosti Signavio s licencí pro akademické úˇcely. Signavio je platforma pro jednoduché modelování, sdílení a kolaborativní vývoj BPMN 2.0 procesu. ˚ Jedná se o web-based nástroj poskytovaný jako služba (SaaS). Mezi zajímavé funkce patˇrí export do BPMN 2.0 XML a dalších formátu˚ vˇcetnˇe XPDL.
5.4
Poznámky k procesu
Proces jako takový je vcelku samopopisný, nˇekteré z aktivit však zaslouží bližší vysvˇetlení, respektive nˇekolik doplnujících ˇ poznámek. 44
5.4. POZNÁMKY K PROCESU 5.4.1
Set up Course
•
Cílem aktivity Add facilitators je manuální pˇridání všech uživatelu, ˚ kteˇrí se podílejí na tvorbˇe kurzu (cviˇcící, pomocníci), vˇcetnˇe pˇriˇrazení pˇríslušných rolí.
•
Set up initial forum topic (uvítací pˇríspˇevek) zduraz ˚ nuje ˇ použití externího diskusního fóra (pˇredmˇetové fórum IS MU).
•
Publish course info — informace o kurzu jsou ve formˇe souboru nahrány do sdíleného prostoru.
5.4.2
Enrollment & Import students
Podproces Enrollment odráží skuteˇcnost, že zápis pˇredmˇetu probíhá v rámci Informaˇcního systému MU. První dva týdny výuky (v dobˇe zmˇeny zápisu) se navíc muže ˚ množina zapsaných studentu˚ podstatnˇe mˇenit. Hromadný import uživatelu˚ (Import students) je tedy nejlepší provést až po prvních dvou týdnech výuky. 5.4.3
Team bulding
Pˇredmˇetem tohoto podprocesu je tvorba týmu. Pˇrednášející pˇredstaví dostupná témata a studenti pˇrímo na pˇrednášce utvoˇrí týmy. Každému týmu je pˇridˇeleno téma a zárovenˇ tým nahlásí svého zástupce (Import students). 5.4.4
Team session
Každý tým si pˇripraví potˇrebné podklady a materiály pro pˇridˇelené téma. Výsledky své práce následnˇe tým odprezentuje ostatním studentum ˚ v rámci pˇrednášky. Po prezentaci následuje diskuze mezi studenty. 5.4.5
Photos
Podproces Pictures Photos pˇredstavuje fakt, že každá pˇrednáška je fotograficky dokumentována. Fotografie jsou následnˇe nahrány do sdíleného prostoru. V našem konkrétním pˇrípadˇe se jedná o webovou službu Google Picasa. ()
Take pictures
Upload to gallery
Obrázek 5.1: Podproces Photos
45
5.4. POZNÁMKY K PROCESU 5.4.6
Perform assessment
Pˇrednášející na základˇe aktivity ohodnotí kladnˇe nebo zápornˇe jednotlivé studenty. Do hodPerform assessment nocení se také zapoˇcítává kvalita odezvy na danou pˇrednášku. Hodnocení následnˇe lektor zadá do aplikace Poznámkové bloky v IS MU.
IS MU Perform assessment
Assign points
Obrázek 5.2: Podproces Perform assessment
5.4.7
Invite members
Podproces Invite members se znaˇcnou mˇerou podílí na budování týmu — každý Team leader má právo pozvat své kolegy do týmu, ale pouze tehdy, pokud již nejsou pozváni, nebo nemají tým. Po pˇrijetí je pozvaný pˇridán do daného týmu.
Team building - invitation
Invite student to team
Team leader
Set student as invited
Handle invitation
#{!invitation_accepted}
Remove student from invited
#{invitation_accepted}
Add student to team
Obrázek 5.3: Podproces Invite members Daniel Tovarnak
1 of 1
46
5.5. IMPLEMENTACE PROCESU
5.5
Implementace procesu
Již jsme si rˇ ekli, že ke zdárnému spuštˇení procesu je tˇreba do procesního modelu doplnit potˇrebné implementaˇcní detaily. Vzhledem k faktu, že v souˇcasnosti neexistuje žádný použitelný nástroj, který by toto ulehˇcoval, probíhala implementace jako ruˇcní úprava procesu uloženého v BPMN2 XML. Mimo jiné se jednalo o doplnˇení rozšíˇrení specifických pro procesní engine Activiti (napˇr. formuláˇre), ale také implementaci potˇrebných Java tˇríd (Java Service Task) — to vše s ohledem na vytvoˇrenou aplikaci pro podporu výuky (viz dále). Vzhledem k tomu, že bˇehové prostˇredí Activiti (zatím) nepodporuje multi-instance, bylo tˇreba tento nedostatek obejít. Jako úˇcinné (byt’ neˇcisté) rˇ ešení se ukázalo použití událostí a signálu. ˚ Pro více detailu˚ cˇ tenáˇre laskavˇe odkážeme na kompletní implementaci procesu, která je souˇcástí pˇríloh práce. <definitions id="definitions" ...> <process id="photos" name="Take and upload photos"> <startEvent id="start" name=""/> <manualTask id="takePictures" name="Take pictures" /> <userTask id="upload" name="Upload photos to gallery"> <documentation> Please upload taken photos to the Picasa Gallery <potentialOwner> group(tutors) <endEvent id="theEnd1"/> <sequenceFlow id="flow0" sourceRef="start" targetRef="takePictures"/> <sequenceFlow id="flow1" sourceRef="takePictures" targetRef="upload"/> <sequenceFlow id="flow2" sourceRef="upload" targetRef="theEnd1"/>
Pˇríklad 5.5.1: Podproces Photos — implementace
47
Kapitola 6
Nástroj na podporu výuky Hlavním cílem praktické cˇ ásti bylo vytvoˇrit nástroj na podporu výuky, jež bude založen na konkrétním výukovém procesu. Jak jsme již uvedli v Kapitole 5, jako prototyp byl vybrán výukový proces kurzu PV206. Cílem bylo implementovat pˇredevším funkcionalitu, která je potˇrebná k bˇehu zmínˇeného procesu. Výsledek má podobu webové aplikace. Tato kapitola shrnuje použité technologie, architekturu, základní implementaˇcní detaily a také popisuje aplikaci samotnou. Pˇred pˇreˇctením této kapitoly cˇ tenáˇri doporuˇcujeme, aby si aplikaci alesponˇ zbˇežnˇe prohlédl a vyzkoušel.1 Z hlediska dalšího studia zustávají ˚ nejduležitˇ ˚ ejším zdrojem informací zdrojové kódy aplikace, její dokumentace a Pˇríloha B, která obsahuje pokyny pro spuštˇení a zárovenˇ odkaz na bˇežící ukázku.
6.1
Použité technologie
Na konci Kapitoly 3 jsme si uvedli motivaci pro použití procesního engine Activiti, jakožto prostˇredku k reálnému využití procesu. ˚ Zárovenˇ podotknˇeme, že sada nástroju˚ kolem Activiti BPM byla pro náš úˇcel nedostaˇcující, a to hned z nˇekolika duvod ˚ u˚ — nízká flexibilita, obtížná customizace, cˇ i zcela chybˇející funkcionalita. Dalším úkolem tedy bylo vytvoˇrit uživatelské prostˇredí pro práci s bˇehovým prostˇredím Activiti a interakci s bˇežícími procesy (podpora uživatelských úkolu). ˚ Navíc bylo tˇreba implementovat komponenty, které poskytují podpurnou ˚ funkcionalitu (sdílení souboru, ˚ správa témat, správa uživatelu˚ atd.) Vše bylo potˇreba vytvoˇrit rychle a maximálnˇe flexibilnˇe, s du˚ razem na agilní vývoj. Doplnujícím ˇ kritériem pro výbˇer vhodných technologií byly také autorovy znalosti a schopnosti. Pˇrirozeným krokem pro vývoj webové aplikace bylo použití nˇejakého MVC frameworku pro jazyk Java (Spring MVC, Seam, Stripes), což se však ukázalo jako pˇríliš tˇežkopádné — tyto technologie spoléhají na kvalitní a kompletní návrh. Jako extrémnˇe efektivní se nakonec ukázal vývoj postavený na MVC rámci Ruby on Rails (RoR, Rails) v kombinaci s bˇehovým prostˇredím (runtime) JRuby.
1. Tento pˇrístup vychází z autorova pˇresvedˇcení, že cˇ tenáˇre zajímá pˇredevším fakt, jaké aplikace poskytuje možnosti, jak se s ní pracuje, jak vypadá, a už ménˇe to, jak je napˇríklad implementován upload souboru. ˚
48
6.2. ARCHITEKTURA 6.1.1
Ruby on Rails
Ruby on Rails je známý MVC rámec pro rapidní vývoj webových aplikací, založený na programovacím jazyce Ruby, který vychází z jazyku˚ jako je Perl, Smalltalk, cˇ i Lisp. Ruby je dynamický, objektovˇe-orientovaný jazyk, který se vyznaˇcuje pˇredevším jednoduchou a velmi elegantní syntaxí, což má za dusledek ˚ vysokou produktivitu a výbornou cˇ itelnost kódu. Jazyk Ruby je jedním z klíˇcových faktoru, ˚ jež stojí za úspˇechem RoR. Rails pˇredstavuje kompletní aplikaˇcní rámec (full-stack framework) — jeho souˇcástí jsou všechny komponenty potˇrebné pro vývoj robustní webové aplikace. At’ již se jedná o ORM nástroj, jazyk pro tvorbu HTML šablon, cˇ i podporu I18n. Vysoká efektivita vývoje je dosažena také díky filozofii DRY (Don’t Repeat Yourself) a principu Convention Over Cofiguration. Více informací o RoR frameworku lze nalézt na domovských stránkách projektu, nebo v [17]. 6.1.2
JRuby
Standardní implementace Ruby je napsaná v jazyce C a má podobu klasického interpretu (Matz’s Ruby Interpreter). Pro MRI v souˇcasnosti existuje nˇekolik zajímavých alternativ, mezi nˇež patˇrí také nativní implementace v jazyce Java. JRuby dovoluje bˇeh Ruby kódu v prostˇredí JVM (Java Virtual Machine) se všemi výhodami které to pˇrináší: • • • • • • •
vysoký výkon škálovatelnost multithreading pˇrenositelnost JIT kompilace volání Ruby → Java použití libovolných Java knihoven
Vzhledem k nativní podpoˇre RoR frameworku pˇredstavuje JRuby pro vývojáˇre zajímavé rˇ ešení. Souˇcástí JRuby je také nástroj pro tvorbu standardních WAR archivu, ˚ které lze následnˇe nasadit do libovolného aplikaˇcního serveru, nebo servlet kontejneru (Glassfish, Tomcat). Pro podrobné informace o JRuby odkážeme cˇ tenáˇre na hlavní stránku projektu ().
6.2
Architektura
Výsledná architektura aplikace je pˇrímo odvozená od použitých technologií. Nejpodstatnˇejším principem je zpˇrístupnˇení bˇehového prostˇredí Activiti v RoR aplikaci, respektive zpˇrístupnˇení aplikaˇcního kontextu Spring, v nˇemž je procesní engine definován jako bean komponenta (viz oddíl 4.3). Trik spoˇcívá v tom, že aplikaˇcní kontext definujeme ve stejném kontextu (daného servlet kontejneru) jako JRuby runtime — viz útržek ze souboru web. xml. 49
6.2. ARCHITEKTURA <web-app> ... <param-name>contextConfigLocation <param-value>classpath*:resources/spring-config.xml <listener> <listener-class> org.springframework.web.context.ContextLoaderListener
Po nasazení war souboru, respektive spuštˇení aplikace je naˇctena nejen naše RoR aplikace, ale také aplikaˇcní kontext s konfigurací v souboru resources/spring-config. xml. Odtud vede jen kruˇ ˚ cek k mimoˇrádnˇe efektní fuzi ˚ RoR/Spring — bˇehové prostˇredí JRuby definuje globální promˇennou $servlet_context, jež pˇredstavuje ukazatel na aktuální (servlet) kontext v nˇemž se nachází. Níže uvedený pˇríklad koneˇcnˇe ukazuje jak z RoR aplikace získat pˇrístup k bˇehovému prostˇredí Activiti, respektive jeho Java API metodám. Modul ProcessEngine a jeho metody jsou následnˇe dostupné v celé RoR aplikaci. module ProcessEngine def application_context # Standard Spring way! Pure Java # $servlet_context is of type javax.servlet.SerlvetContext org.springframework.web. context.support.WebApplicationContextUtils. getWebApplicationContext($servlet_context) end def process_engine application_context.getBean("processEngine") end def task_service process_engine.getTaskService() end ... def management_service process_engine.getManagementService() end end
Toto, aˇc neobvyklé, ale nesmírnˇe elegantní spojení nám pˇrináší flexibilitu vývoje v RoR a zárovenˇ sílu Javy a Spring frameworku (a samozˇrejmˇe pˇrístup k Activiti). Dodejme, že 50
6.2. ARCHITEKTURA pˇredstavené rˇ ešení je velmi cˇ isté, transparentní a zárovenˇ vláknovˇe bezpeˇcné.
MySQL Database
Servlet Context Spring Application Context
JRuby Runtime
Activiti Engine
RoR Application
Servlet Container
Obrázek 6.1: Architektura aplikace
6.2.1
Implementaˇcní zkratky
Pˇri vývoji prototypu se programátor nikdy zcela nevyhne použití rˇ ešení a technik, která jsou v produkˇcním nasazení nežádoucí, nebo nepˇrípustná. V pˇrípadˇe naší aplikace je takové necˇ isté rˇ ešení použito pˇri práci s uživateli a jejich skupinami/rolemi. Vzhledem k tomu, že procesní engine využívá vlastní komponentu pro práci s uživateli, bylo by nadbyteˇcné vytváˇret nový model v rámci RoR aplikace (autentizace, autorizace). Legitimním rˇ ešením by mohlo být napˇríklad použití komponenty IdentityService, což se však ukázalo jako neefektivní. RoR aplikace tedy pˇrímo využívá databázového schématu Activiti (pˇrímý pˇrístup do DB). 6.2.2
Role
Mimo role vystupující v procesu (viz Kapitola 5) existuje v systému další sada (bezpeˇcnostních) rolí, které slouží pˇredevším k autorizaci uživatelu˚ v rámci aplikace. Dá se rˇ íci, že v našem konkrétním pˇrípadˇe oprávnˇení pro jednotlivé bezpeˇcnostní role odpovídají oprávnˇením, které by také mˇely mít role z procesu. Napˇríklad role Admin odpovídá reálnˇe roli Course Owner, což však nemusí být v obecném pˇrípadˇe pravdou. Bezpeˇcnostní role jsou: •
Admin
•
Power User
•
User
Pro autorizaci je použit nástroj (rozšiˇrující modul) CanCan. Zpusob ˚ použití demonstruje pˇríklad uvedený níže. 51
6.3. MODULY class Ability include CanCan::Ability def initialize(user, params) if user.is? :admin can :manage, :all can :access, :all end ... end end
6.2.3
Uživatelské formuláˇre
Aplikace obsahuje funkcionalitu pro generování uživatelských formuláˇru, ˚ definovaných v procesu. Z pohledu bˇehového prostˇredí se tedy jedná o možnost tzv. externího renderingu (viz 4.5.3), a to v obou variantách. Systém dokáže vygenerovat reálný formuláˇr (nasazený v bˇehovém prostˇredí), zárovenˇ je však možné (v omezené míˇre) z procesu pomocí identifikátoru odkazovat formuláˇre, které jsou souˇcástí aplikace.
6.3
Moduly
Pˇredstavme si nyní krátce duležité ˚ moduly aplikace. Vzhledem k tomu, že aplikace sama o sobˇe je vcelku intuitivní, nebudeme zabíhat do pˇrílišných detailu. ˚ Nˇekteré podrobnosti jsme si uvedli již v Kapitole 5. 6.3.1 •
Process Engine Pˇrístupné pro roli: Admin
Tento modul slouží ke správˇe bˇehového prostˇredí Activiti, pˇredpokládá dobrou znalost systému a jednotlivých procesu. ˚ Modul je rozdˇelen na tˇri perspektivy. •
Deployment — slouží ke správˇe a uploadu BAR archivu˚ jež obsahují procesní definice a další artefakty. Po smazání daného deploymentu jsou zárovenˇ zastaveny (znicˇ eny) všechny procesní instance.
•
Definitions — pˇredstavuje rozhraní pro práci s procesními definicemi, zejména jejich spouštˇení.
•
Instances — pˇredstavuje seznam jednotlivých bˇežících instancí vˇcetnˇe detailních informací. Tuto perspektivu lze také použít k násilnému ukonˇcení instancí.
52
6.3. MODULY 6.3.2 •
User Management Pˇrístupné pro roli: Admin
Modul pro kompletní správu uživatelu. ˚ Dovoluje tvorbu, editaci a mazání uživatelu˚ a uživatelských skupin. Pro autorizaci v rámci RoR aplikace slouží skupiny typu security-role, zatímco skupiny pro procesní engine mají typ assigment. Souˇcástí modulu je také funkcionalita pro hromadný import uživatelu˚ z IS MU (formát CSV). 6.3.3 •
Topics & Teams Pˇrístupné pro roli: Power User
Perspektiva pro správu témat je zajímavá pˇredevším tím, že pˇri tvorbˇe témat jsou zárovenˇ automaticky vytvoˇreny i pˇríslušné týmy, jež lze následnˇe spravovat ve vlastní perspektivˇe (pˇridávání cˇ lenu, ˚ kompletní info o týmech atp.) 6.3.4 •
Picasa albums Pˇrístupné pro roli: Power User
Již jsme uvedli, že správa fotografií je rˇ ešena externˇe pomocí služby Google Picasa. Tato perspektiva umožnuje ˇ alesponˇ vytvoˇrení pseudo-alba pomocí tzv. embed kódu. Validní embed kód lze vygenerovat pomocí zmínˇené služby. 6.3.5 •
My Team (Teamspace) Pˇrístupné pro roli: User (Musí být cˇ lenem týmu)
Perspektiva pro týmovou spolupráci poskytuje funkcionalitu pro budování týmu (pozvánky) a spoleˇcný prostor pro sdílení souboru. ˚ 6.3.6 •
Course Space Pˇrístupné pro roli: Power User, User
Základní pˇrehled všech duležitých ˚ informací týkajících se kurzu — dostupné soubory, všeobecné zprávy, doplnující ˇ informace a pˇredevším seznam úkolu˚ daného uživatele. 6.3.7 •
Feedbacks Pˇrístupné pro roli: Power User
Modul Feedbacks poskytuje pˇrístup ke všem vyplnˇeným formuláˇrum ˚ se zpˇetnou vazbou. Každému formuláˇri lze pˇriˇradit ohodnocení v podobˇe bodu. ˚ 53
6.4. SHRNUTÍ 6.3.8 •
Monitoring Pˇrístupné pro roli: Power User
Tento modul má za úkol demonstrovat schopnosti procesního engine v oblasti monitoringu procesu. ˚ Zobrazuje napˇríklad 10 nejdéle cˇ ekajících (nesplnˇených) úkolu, ˚ nebo 10 úkolu, ˚ jejichž dokonˇcení trvalo nejdéle.
6.4
Shrnutí
Prototyp aplikace má za úkol poskytnout odrazový mustek ˚ pro následný vývoj systému MEDUSY, zejména z pohledu použitých technologií, možných pˇrekážek, ale také otázek týkajících se obecného návrhu. Pojd’me si shrnout nejduležitˇ ˚ ejší fakta a poznatky, jež vyvstaly pˇri tvorbˇe prototypu a pˇrípadnˇe do budoucna diskutovat vhodná rˇ ešení. 6.4.1
Technologie
Volba procesního engine Activiti se ukázala jako opodstatnˇená — vývoj lze oznaˇcit za rychlý, snadno testovatelný a flexibilní. Výkon je plnˇe dostaˇcující, samotná funkcionalita je až na nˇekolik výjimek (podpora multi-instancí) dostateˇcná. Velkou výhodou je živá komunita — at’ už ve smyslu podpory, ale také z pohledu vývoje a inovace. Použití MVC frameworku Ruby on Rails (v kombinaci s JRuby) pro další vývoj lze bez výhrad doporuˇcit, vhodnou alternativou muže ˚ být rámec Spring MVC. 6.4.2
Podpurná ˚ funkcionalita
Hlavní možnosti systému by mˇely být urˇceny pˇredevším funkcionalitou, kterou lze využít ve výukových procesech. Dá se rˇ íci, že zatímco implementace funkcionality související s procesy a bˇehovým prostˇredím je vcelku pˇrímoˇcará, nejvˇetší procento práce pˇripadne právˇe na implementaci podpurných ˚ komponent, pˇrípadnˇe (dle uvážení) na výbˇer a úpravu existujících aplikací a nástroju. ˚ Bylo by napˇríklad zbyteˇcné chtít implementovat wiki, cˇ i diskusní fórum, naopak funkcionalita potˇrebná pro odezvu studentu˚ (feedback), nebo tˇreba týmovou spolupráci zaslouží bližší pozornost (ve smyslu peˇclivého návrhu a implementace). 6.4.3
Interoperabilita
Podmínkou by mˇela být vysoká interoperabilita a znovupoužitelnost jednotlivých komponent (napˇríklad za pomoci kvalitního REST rozhraní), zárovenˇ s ohledem na použití v kontextu výukových procesu. ˚ Pˇri použití více samostatných aplikací, by mˇelo být použito jednotné uživatelské rozhraní a pˇrechod mezi nimi by mˇel být bezešvý a pro uživatele transparentní. 54
6.4. SHRNUTÍ 6.4.4
Autentizace a správa uživatelu˚
V souvislosti s pˇredchozím odstavcem musíme zduraznit, ˚ že pˇri použití více autonomních aplikací je tˇreba zajistit možnost jediného pˇrihlášení (Single Sign-on — SSO). Správa uživatelu˚ by dále mˇela být pˇresunuta mimo procesní engine — v souvislosti s tím je také vhodné zvážit použití LDAP serveru. 6.4.5
Uživatelské úkoly a formuláˇre
Je tˇreba zvážit zpusob ˚ práce s uživatelskými úkoly v pˇrípadˇe, že úkol zahrnuje interakci se systémem, kterou nelze dost dobˇre vyˇrešit interním formuláˇrem v rámci bˇehového pro2 Rešením ˇ stˇredí — jakým zpusobem ˚ kontrolovat, že uživatelský úkol byl opravdu splnen? ˇ muže ˚ být, vybudovat takovou funkcionalitu, která by dovolovala spojit (v procesní definici) uživatelský úkol s jakýmkoliv formuláˇrem v rámci systému (tak, jak je to naznaˇceno v rámci našeho prototypu).3 6.4.6
Podpora více kurzu˚ a jejich záloha
Samozˇrejmostí, na kterou je tˇreba se zamˇerˇ it, je podpora více kurzu. ˚ Použití samostatné aplikace pro každý kurz je nepˇrijatelné (napˇríklad z pohledu udržovatelnosti). Uživatel by mˇel mít navíc možnost vidˇet všechny své úkoly napˇríˇc kurzy, se kterými je spojen. Otázkou také zustává ˚ záloha jednotivých bˇehu˚ kurzu.
2. Uživatel má napˇríklad za úkol upload urˇcitého souboru. Necht’ je taková funkce v aplikaci k dispozici, jak však zabránit uživateli, aby neprohlásil úkol za splnˇený bez toho, že zmínˇený soubor opravdu nahraje? 3. To znamená, že v souladu s poznámkou výše, by uživatel musel soubor opravdu nahrát a teprve potom by aplikace automaticky prohlásila úkol za splnˇený.
55
Kapitola 7
Závˇer Tato práce si vzala za úkol analyzovat možnosti využití procesu˚ a procesního rˇ ízení v elektronické výuce (resp. blended learningu), s ohledem na technologickou stránku vˇeci. Dalším (více pragmatickým) cílem bylo poskytnout vˇedomostní základnu pro další práci na projektu MEDUSY. Za tímto úˇcelem byl vytvoˇren prototyp aplikace na podporu výuky. Shrnme ˇ si nejduležitˇ ˚ ejší skuteˇcnosti, jež vedly k naplnˇení cílu˚ stanovených v úvodu této práce (1.4). V první kapitole byl cˇ tenáˇr krátce seznámen s motivací, jež stojí za myšlenkou využití procesu˚ v elektronické výuce. Zárovenˇ bylo zduraznˇ ˚ eno, že efektivní použití procesu˚ jde ruku v ruce s použitím vhodné metodiky pro jejich rˇízení. Mezi takové metodiky patˇrí i procesní rˇ ízení (Business Process Management), jemuž je vˇenována kapitola druhá, která pˇredstavuje základní principy a pojmy BPM a diskutuje použití této metodiky (a samozˇrejmˇe procesu) ˚ v kontextu elektronické výuky, vˇcetnˇe možných výhod a specifik. Duležité ˚ je zavedení pojmu životního cyklu BPM a jeho jednotlivých etap. Zárovenˇ je tˇreba vyzdvihnout fakt, že tvorba výukových procesu˚ je do velké míry i pedagogickým problémem. Tˇretí kapitola shrnuje souˇcasné notace a standardy, používané v jednotlivých etapách životního cyklu BPM. Duraz ˚ byl kladen pˇredevším na problematiku spouštˇení (automatizace) procesu. ˚ Podstatná cˇ ást kapitoly je vˇenována zcela novému standardu BPMN 2.0, který adresuje problémy pˇredchozích rˇ ešení. Jako nosná technologie pro zamýšlený nástroj na podporu výuky byl zvolen procesní engine Activiti. Activiti BPM je pˇredmˇetem cˇ tvrté kapitoly — jedná se pˇredevším o technický popis možností a vlastností tohoto nástroje. Hlavním úˇcelem této kapitoly bylo poskytnout cˇ tenáˇri základy práce s bˇehovým prostˇredím Activiti tak, aby se dále orientoval v praktických cˇ ástech práce. V páté kapitole je pˇredstaven konkrétní výukový proces, inspirovaný skuteˇcným kurzem Fakulty informatiky — PV206 Communication and Softskills. Na základˇe modelového procesu byla následnˇe vytvoˇrena potˇrebná funkcionalita v rámci již zminované ˇ aplikace na podporu výuky. Šestá kapitola detailnˇeji seznamuje cˇ tenáˇre s výslednou aplikací a charakterem implementaˇcních prací, pˇriˇcemž zárovenˇ navrhuje rˇ ešení na nejpalˇcivˇejší problémy a upozornuje ˇ na možná úskalí. Tato kapitola (a výsledná aplikace pˇredevším) je duležitým ˚ podkladem pro následný vývoj v rámci projektu MEDUSY a také podstatným pˇrínosem této práce. 56
Literatura a zdroje [1] MEANS, B., et al.: Evaluation of Evidence-Based Practices in Online Learning: A MetaAnalysis and Review of Online Learning Studies , U.S. Department of Education, 2010, [cit. 2010-12-14]. Dostupný z WWW: . 1.1, 1.1 [2] Business process management: Wikipedia : the free encyclopedia [online] , Wikipedia Foundation, 2010, [cit. 2010-12-14]. Dostupný z WWW: . 2.1.1.1 [3] Business process: Wikipedia : the free encyclopedia [online] , Wikipedia Foundation, 2010, [cit. 2010-12-14]. Dostupný z WWW: . 2.1.2 [4] The Pedagogical Patterns Project [online]: , [cit. 2010-12-14]. Dostupný z WWW: . 2.2.3 [5] BERGIN, J.: Fourteen Pedagogical Patterns [online], 2007, [cit. 2010-12-14]. Dostupný z WWW: . (document), 2.2.3.1 [6] DOBROVOLNÝ, J.: Procesní analýza vysoké školy [Diplomová práce], Masarykova Univerzita, 2010. 3.1 [7] NOVÁK, J.: Modelování výukových procesu˚ [Diplomová práce], Masarykova Univerzita, 2011. 3.2 [8] BPMN 1.2: Business Process Model and Notation (BPMN) : Version 1.2, Object Management Group, 2009, [cit. 2010-12-14]. Dostupný z WWW: . 3.2.1, 3.2.2 ˇ [9] TOVARNÁK, D.: Smˇerování komunikace na ESB [Bakaláˇrská práce], Masarykova Univerzita, 2008. 3.3.1 ˇ P.: Využití BPEL v servisnˇe-orientovaných architekturách [Diplomová práce], [10] ŠAFÁR, Masarykova Univerzita, 2007. 3.3.1 [11] BPMN 2.0 Beta2: Business Process Model and Notation (BPMN) : Version 2.0, Object Management Group, 2010, [cit. 2010-12-14]. Dostupný z WWW: . 3.5.2, 3.6, 3.6.2 [12] MAYER, M.: Informaˇcní podpora procesu˚ krizového rˇ ízení [Diplomová práce], Masarykova Univerzita, 2010. 3.7.2.1 [13] BAEYENS, T. a FAURA, M.: The Process Virtual Machine [online] , 2007, [cit. 201012-14]. Dostupný z WWW: . 4.1.1 57
[14] Activti BPM [online]: Activiti - Engine 5.0 API, 2010, [cit. 2010-12-14]. Dostupný z WWW: . 4.1.2.2 [15] Activti BPM [online]: Activiti 5.0 User Guide, 2010, [cit. 2010-12-14]. Dostupný z WWW: . 4.3, 4.2, 4.4 [16] Pˇredmˇetový katalog Masarykovy univerzity [online]: PV206 Communication and Soft Skills, 2010, [cit. 2010-12-14]. Dostupný z WWW: . 5.1 [17] FISHER, T.: Ruby on Rails Bible, Wiley Publishing, Inc., 2008, ISBN 978-0-470-25822-4. 6.1.1 ˇ [18] REPA, V.: Podnikové procesy, Grada, 2007, ISBN 978-80-247-2252-8.
58
Pˇríloha A
Pˇríklad z Kapitoly 4 — Activiti Hello World A.1 • •
A.2
Prerekvizity pro spuštˇení JRE6 apache-maven-2.2.1
Struktura aplikace
Zdrojové kódy pˇríkladu jsou souˇcástí pˇríloh práce. Aplikace využívá Apache Maven (pom. xml), jakožto nástroj pro rˇ ešení závislostí, kompilaci a spuštˇení — od toho se také odvíjí adresáˇrová struktura pˇríkladu. | | helloworld-example.iml | pom.xml | o---.idea +---src \---main +---java | \---cz | \---muni | \---fi | \---xtovarn | \---examples | \---helloworld | +---run | | Run.java | | | \---service | ConsoleReader.java | +---process | hello-world.bpmn20.xml | \---resources config.xml
59
ˇ A.3. SPUŠT ENÍ A.2.1 Run.java Tˇrída Run pˇredstavuje spustitelnou cˇ ást pˇríkladu (obsahuje metodu main). Zde je instanciováno bˇehové prostˇredí a následnˇe dochází k nasazení a spuštˇení procesu. A.2.2 ConsoleReader.java Tˇrída ConsoleReader, tak jak jsme si ji popsali v sekci 4.6.1. A.2.3 hello-world.bpmn20.xml Procesní definice ve formátu BPMN2 XML (viz oddíl 4.6). A.2.4 config.xml Standardní konfiguraˇcní soubor pro Activiti Engine. Jistou zajímavostí je použití In-Memory databáze jako perzistentího úložištˇe. <property name="databaseType" value="h2" /> <property name="jdbcUrl" value="jdbc:h2:mem:activiti;DB_CLOSE_DELAY=1000" /> <property name="jdbcDriver" value="org.h2.Driver" /> <property name="jdbcUsername" value="sa" /> <property name="jdbcPassword" value="" /> <property name="databaseSchemaUpdate" value="true" />
Pˇríklad A.2.1: config.xml
A.3
Spuštˇení
Díky použití nástroje Maven je spuštˇení celého pˇríkladu nadmíru jednoduché: mvn clean compile exec:java
60
Pˇríloha B
Nástroj na podporu výuky Naše aplikace je vystavˇena nad frameworkem Ruby on Rails, což výraznˇe ovlivnuje ˇ její podobu. Druhým specifikem je použití bˇehového prostˇredí JRuby. Pˇred bližším zkoumáním doporuˇcujeme cˇ tenáˇri alesponˇ zbˇežnˇe prostudovat materiály dostupné na
B.1 • • •
B.1.1
Prerekvizity pro spuštˇení JRE6 MySQL databáze jruby-1.5.6
Knihovny Ruby (RubyGems)
Naše aplikace používá nástroj Bundler urˇcený pro správu závislostí a knihoven pro Ruby. Pˇred startem aplikace jsou speciálním pˇríkazem nainstalovány všechny potˇrebné knihovny (viz dále). Jelikož tento nástroj není standardní souˇcástí distribuce JRuby, je nutné jej ruˇcnˇe nainstalovat pˇríkazem jgem install bundler. B.1.2
Knihovny Java
Veškeré knihovny, nutné pro bˇeh procesního engine Activiti (vˇcetnˇe tˇech, potˇrebných k bˇehu procesu Softskills), jsou souˇcástí aplikace, není tedy tˇreba jejich manuální instalace. Knihovny se nachází v adresáˇri ./lib v koˇrenovém adresáˇri aplikace.
B.2
Struktura aplikace
Nástroj vpodstatˇe kopíruje bˇežnou adresáˇrovou strukturu typické RoR aplikace. Zdrojové kódy, vˇcetnˇe všech knihoven, naleznete mezi pˇrílohami této práce. Dokumentace se nachází ve složce ./doc. <softskills-app-jors> | | .gitignore
61
B.2. STRUKTURA APLIKACE | config.ru | Gemfile | Gemfile.lock | Rakefile | README | run.bat | run.sh | softskills-app-jors.iml | o---.idea o---app o---config o---db o---doc o---lib o---log o---public o---resources o---script o---test o---vendor \---WEB-INF
B.2.1
Gemfile
Specifikuje dodateˇcné knihovny a závislosti, které jsou nutné pro správný bˇeh aplikace. B.2.2
./app
Hlavní adresáˇr aplikace, obsahuje veškerou podstatnou funkcionalitu — kontrolery (Controllers), modely (Models) a pohledy (Views). B.2.3
./config
Jak již název napovídá, soubory v tomto adresáˇri slouží k pokroˇcilé konfiguraci aplikace (smˇerování požadavku, ˚ databáze atd.) B.2.4
./db
V adresáˇri se nachází aktuální databázové schéma, soubory potˇrebné pro ORM mapování, stejnˇe jako záznamy sloužící k naplnˇení databáze. B.2.5
./doc
Dokumentace aplikace a vygenerovaný RDoc (obdoba JavaDoc). 62
ˇ B.3. SPUŠT ENÍ B.2.6
./lib
Knihovny potˇrebné k bˇehu aplikace. B.2.7
./public
Všechny soubory z této složky jsou veˇrejnˇe dostupné. Nachází se zde pˇredevším obrázky, CSS styly, soubory pro Javascript, a další statické soubory. B.2.8
./resources
Konfiguraˇcní soubory potˇrebné k bˇehu procesního engine Activiti. B.2.9
./script
Systémové skripty pro pokroˇcilé operace v rámci aplikace. B.2.10 ./test Tento adresáˇr obsahuje všechny soubory, které souvisí s testováním aplikace. B.2.11 ./vendor Složka pro aplikace a nástroje tˇretích stran, nˇekdy také využívaná pro vlastní externí moduly. B.2.12 ./WEB-INF Obsahuje soubor web.xml, jež je potˇrebný ke spuštˇení aplikace pomocí nástroje trinidad.1
B.3
Spuštˇení
V tomto krátkém návodu pˇredpokládáme, že jsou splnˇeny všechny prerekvizity uvedené výše a uživatel má potˇrebná pˇrístupová práva. Návod byl otestován na OS Linux (Debian Lenny). 1. V koˇrenovém adresáˇri aplikace spust’te pˇríkaz jruby -S bundle install, jež automaticky nainstaluje dodateˇcné knihovny. 2. Ve vaší MySQL databázi vytvoˇrte libovolné schéma (databázi), pˇrípadnˇe pˇridejte vhodné uživatele a nastavte jejich práva. Na tomto schématu spust’te SQL skript resources/db/activiti.mysql.create.sql, který vytvoˇrí potˇrebné tabulky pro Activiti engine. 1.
Trinidad je v podstatˇe Ruby wrapper pro server Apache Tomcat.
63
B.4. ONLINE UKÁZKA 3. V souborech config/database.yml (ˇcást development) a resources/springconfig.xml (bean komponenta dataSource) nastavte správné údaje pro datové úložištˇe v závislosti na pˇredchozím bodˇe a adrese vašeho DB serveru. 4. Pˇríkazem jruby -S rake db:migrate2 vytvoˇríte v databázi tabulky pro naši aplikaci. 5. Pˇríkazem jruby -S rake db:seed naplníte databázi potˇrebnými daty. 6. Po spuštˇení pˇríkazu jruby -S trinidad −− config v koˇrenovém adresáˇri bude hlavní stránka aplikace dostupná na adrese . Dále postupujte dle uvedených pokynu. ˚
B.4
Online ukázka
Vzhledem k tomu, že zprovoznˇení aplikace muže ˚ být pro ménˇe zkušené uživatele cˇ asovˇe nároˇcné, cˇ tenáˇri bude dostupná online ukázka na adrese . Je zˇrejmé, že tato adresa se muže ˚ v cˇ ase mˇenit, aktuální odkaz bude proto také dostupný na . Jestliže obˇe možnosti selžou, kontaktuje prosím autora této práce.
2.
Pˇríkaz jruby -S rake vždy spouštˇejte v koˇrenovém adresáˇri aplikace
64
Pˇríloha C
Implementace procesu Softskills V této pˇríloze si krátce popíšeme poslední dva projekty, které pˇredstavují implementaci našeho modelového procesu. Oba projekty používají nástroj Apache Maven, práce s nimi je tedy velmi jednoduchá. Zdrojové kódy naleznete v pˇrílohách práce.
C.1
Procesní definice
<softskills-process-maven> | | pom.xml | softskills-process-maven.iml | o---.idea \---src \---main \---java \---cz \---muni \---fi \---xtovarn \---activiti \---softskills initial_questionare.bpmn20.xml invitation.form.html multiple-initial_questionare.bpmn20.xml multiple-overall_feedback.bpmn20.xml multiple-session_feedback.bpmn20.xml multiple-team_session.bpmn20.xml out.bpmn20.xml overall_feedback.bpmn20.xml perform_assessment.bpmn20.xml photos.bpmn20.xml session_feedback.bpmn20.xml team-invitation.bpmn20.xml team_session.bpmn20.xml
Tento projekt pˇredstavuje implementaci potˇrebných procesu˚ ve formˇe BPMN2 XML. Po spuštˇení pˇríkazu mvn clean package bude projekt sestaven a výsledný jar archiv je pˇri65
ˇ C.2. UŽIVATELSKÉ T RÍDY praven k nasazení do bˇehového prostˇredí Activiti (perspektiva Deployment v naší aplikaci). Zduraznˇ ˚ eme, že potˇrebné tˇrídy, jež implementují uživatelskou funkcionalitu, jsou pˇredmˇetem druhého projektu.
C.2
Uživatelské tˇrídy
<softskills-service-maven> | | pom.xml | softskills-service-maven.iml | o---.idea \---src \---main \---java \---cz \---muni \---fi \---xtovarn \---activiti \---softskills Signal.java StartMultipleInitialQuestionare.java StartMultipleOverallFeedback.java StartMultipleSessionFeedback.java StartMultipleTeamSession.java
Tento projekt obsahuje uživatelské tˇrídy, jež jsou potˇrebné k bˇehu procesu Softskills. Pˇríkaz mvn clean package sestaví projekt do podoby jar knihovny. Upozornˇeme, že tato knihovna neslouží k nasazení do bˇehového prostˇredí — musí být umístˇena mezi ostatní Java knihovny potˇrebné k bˇehu naší aplikace, tzn. do složky./lib.
66
