Masarykova univerzita Fakulta informatiky Modelování výukových procesii Diplomová práce Jirí Novák Brno, podzim 2010 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatní?. Všechny zdroje, prameny a literaturu, které jsem pri vypracování používal nebo z nich cerpal, v práci rádne cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: Mgr. Jiri Kolár ii Poděkování Děkuji Mgr. Jiřímu Kolářovi ze jeho odborné vedení práce a cenné rady pro psaní textové Části práce. iii Shrnutí Tato práce se venuje hledání casto opakovaných scénářů ve výuce a následnému rozšíření aplikace pro vizuální modelování business procesia o nové prvky reprezentující nalezené výukové vzory. Editor je založený na open source nástroji Signavio Core Components. Vytvorená rozšírení používají technologie JSON a Java. Pro modelování procesii se v nástroji používá notace BPMN 2.0. Práce vznikla jako soucást projektu MEDUSY. iv Klíčová slova BPMN 2.0, výukový proces, vzor, business proces, MEDUSY, modelování, JSON, Java v Obsah 1 Úvod............................................. 1 1.1 Cíl práce........................................ 1 1.2 MEDUSY........................................ 1 1.3 Struktura práce.................................... 3 2 Business Process Management.............................. 4 2.1 Business Process.................................... 4 2.2 Business Process Management ........................... 6 2.3 Postup modelování procesu............................. 8 2.4 Notace pro modelování procesii........................... 9 2.4.1 Sít'ové diagramy............................... 9 2.4.2 Notace WfMC................................. 10 2.4.3 Process Flowchart (Diagram procesních retezců)............. 10 2.4.4 (Control) Data Flow Diagram........................ 10 2.4.5 Petriho site................................... 11 2.4.6 Unified Modeling Language (UML) - Diagram aktivit ......... 12 2.4.7 Business Process Modeling Notation.................... 13 2.4.7.1 Tokové objekty........................... 14 2.4.7.2 Spojovací objekty ......................... 15 2.4.7.3 Plavecké dráhy........................... 15 2.4.7.4 Artefakty.............................. 16 2.4.8 Bůsiness Process Model and Notation ................... 17 2.5 Spouštení business procesu............................. 19 3 Výukové procesy...................................... 20 3.1 Definice výukového procesu............................. 20 3.2 Modelování výukových procesu.......................... 20 3.2.1 CPM (Co-operative Problem-based Learning Metamodel) ....... 21 3.2.2 coUML ..................................... 22 3.2.3 Prolix Graphical Learning Modeler..................... 23 3.2.4 ReCoůrse Editor ............................... 24 3.2.5 Reload Editor................................. 24 3.2.6 CompendiůmLD ............................... 25 3.2.7 Learning Activity Management System (LAMS) ............. 25 3.3 Spouštení výukových procesu............................ 26 4 Výber technologií pro MEDUSY............................. 27 4.1 Notace a jazyk..................................... 27 4.1.1 Modelování .................................. 27 4.1.2 Implementace................................. 28 4.1.3 Spouštení procesů (behová prostredí)................... 28 4.1.4 Monitoring .................................. 28 4.1.5 Použití externích slůžeb v procesů..................... 29 vi 4.1.6 Dokumentace................................. 29 4.1.7 Shrnutí..................................... 29 4.2 Nástroje pro práci s BPMN 2.0............................ 30 4.2.1 Oryx editor.................................. 30 4.2.2 Activiti..................................... 31 4.2.3 Drools Flow.................................. 32 4.2.4 jBPM5..................................... 33 4.2.5 Shrnutí..................................... 33 5 Vzory............................................. 34 5.1 Vzory.......................................... 34 5.1.1 Definice.................................... 34 5.1.2 Popis vzoru.................................. 35 5.2 Související projekty.................................. 37 5.2.1 Pedagogical Patterns Project ........................ 38 5.2.2 E-LEN..................................... 38 5.2.3 Person Centered e-Learning (PCeL).................... 38 6 Výukové vzory pro MEDUSY .............................. 41 6.1 Popis vzorU...................................... 41 6.2 Vzory .......................................... 41 6.2.1 Domácí úkol s přepracováním....................... 42 6.2.2 Domácí úkol s termínem odevzdání.................... 43 6.2.3 Individuální projekt s výberem tématu .................. 43 6.2.4 Týmový projekt s výberem tématu..................... 44 6.2.5 Písemná a ústní zkouška........................... 45 6.2.6 Vnitrosemestrální test............................ 46 6.2.7 Jednoduchý odpovedník........................... 47 7 Rozšírení modelovacího nástroje............................. 48 7.1 Signavio Core Components (SCC) ......................... 48 7.2 Stencil set........................................ 48 7.3 Rozšírení notace.................................... 49 7.3.1 Možnosti.................................... 50 7.3.1.1 Volání vzoru............................ 50 7.3.1.2 Parametrizace ........................... 50 7.3.2 Řešení a problémy.............................. 50 7.3.2.1 Script Task + Call Activity.................... 50 7.3.2.2 Script Task + Service Task..................... 51 7.3.2.3 Notace ................................ 51 7.3.3 Activiti rozšírření ............................... 53 7.3.4 Pohledy .................................... 53 7.4 Rozšírení funkcionality................................ 54 7.4.1 Vývojársky príjemná forma xml...................... 54 7.4.2 MEDUSY transformace ........................... 56 vii 8 Použití aplikace....................................... 57 8.1 Použití nových prvků aplikace........................... 57 8.2 Implementace vzorů................................. 58 9 Záver............................................. 59 9.1 Zhodnocení výsledků................................. 59 9.2 Budoucípráce..................................... 60 Literatura............................................. 64 A Další výukové vzory.................................... 65 A.1 Domácí úkol...................................... 65 A.2 Zpětná odezva pres diskusní fórum ........................ 65 A.3 Písemná zkouška................................... 66 A.4 Ústní zkouška..................................... 67 A.5 Zpětná odezva pres formuláre............................ 67 A.6 Zápis do predmetu se schválením ......................... 68 B Návod na implementaci vzorU.............................. 69 C Obsah priloženého CD .................................. 74 viii Kapitola 1 Úvod 1.1 Cíl práce V dnešní dobe asi nikdo nepochybuje o významu vzdelání. Při výberu z uchazedä o za-mestnání rozhodují znalosti a zkušenosti. Firmy dbají o prohlubování znalostí svých zamestnanou - porádají školení, semináre a požadují po svých zamestnancích sebevzdelávání. E-learning se stal jedním ze zpusobu, jak vzdelávání dosáhnout. Své uplatnení e-learning našel i v akademickém prostředí. Vyucující jejvyužívají v rámci výuky svých predmetu k šírení materiálu studentum, k testování jejich znalostí a k domácím úkolum. Jelikož význam e-learningu bude do budoucna dále narustat, má smysl e-learningové technologie rozvíjet a rozširovat možnosti využití. Tato práce má do rozvoje prispeet. Práce vzniká jako soucást projektu MEDUSY1 a její cíle je možné shrnout do následujících trí bodiä: • Zmapovat stávající nástroje a technologie pro modelování business a výukových procesia a vybrat z nich technologie pro projekt MEDUSY. • Nalézt casto opakované vzory ve výuce a zadefinovat je takovým způsobem, aby je bylo možné využít jako výukové procesy. • Navrhnout a implementovat, nebo rozšínt stávájící nástrojpro modelování procesů o nové prvky reprezentující cřasto používané výukové vzory. 1.2 MEDUSY Projekt MEDUSY (Multi-Purpose Education System) vznikl v laboratori LaSArIS2 Fakulty informatiky Masarykovy univerzity za podpory spolecnosti Red Hat Czech Republic3. Jedná se o open source projekt zameřrřený na vývoj e-learningového prostrředí, které by meřlo klasickou výuku nejen doplnřovat, ale umožnit její cřást prřesunout do tohoto prostrředí za úcřelem zefektivneřní výuky. Při vytvárení je snahou využít osvedcených postupů z již používaných systémů a ty doplnit o nové postupy a technologie, prřicřemž základním stavebním prvkem má být procesneř 1. 2. 3. 1 1.2. MEDUSY orientovaný prístup a to jak k vytvárení výukových kurzu, tak k výuce všeobecne. Důležitá je pritom modularita vytváreného systému, aby do nej bylo možné zapojit LMS systémy zamerené na správu obsahu a materiálu. Cílem je také snadná propojitelnost pomocí webových služeb s externími systémy. Nedílnou soucástí systému má také být technologie, která bude pripravovat jak fyzické, tak virtuální stanice pro potreby technických kurzu podle definovaných požadavku. Hlavní cíle projektu se dají shrnout do nekolika následujících bodu: • Využítí procesia z pohledu Business Process Managementu v e-learningu a vytvorení prostredí pro modelování, spouštení a monitorování výukových procesií. • Nalézt casto se vyskytující vzory ve výuce a zadefinovat je takovým zpusobem, aby je bylo možné využít jako výukové procesy. • Využít externí systémy a služby podporující e-learning. • Vytvorit modul pro správu a prípravu fyzických a virtuálních stanic a laboratoří pro technické kurzy. • Využít prři výuce v e-learningovém prostrředí multimédia. Výstup této práce má v rámci projektu sloužit vyucujícím a vývojárum. U vyucujících se predpokládá, že vytvořený (upravený) nástrojpoužijí pro vizuální namodelování svého kurzu, který chteřjí prřevést do e-learningové formy. Vývojárři model vezmou, implementují a nasadí do procesního beřhového prostrředí. Nasazený proces provede vyucřující a studenty výukou tím, že jim oznámí, co kdy mají deřlat a jaké k tomu potrřebují materiály. Modelovací nástroj má být jednou ze základních komponent zamýšleného systému, ne-bot' bez toho, aby mel vyucující k dispozici nástrojpro vytvárení kurzu, postrádá celý systém smysl. Navíc vytvárření modelu výuky musí být co nejjednodušší, teřžko lze prředpoklá-dat, že by vyucující meli zájem nástrojpoužívat, pokud je složitý a „hází jim klacky pod nohy". Vizuální modelování procesií se jeví jako nejrychleji pochopitelný způsob vytvárení procesů výuky. V rámci projektu jsou kromeř této práce zpracovávány tyto bakalárřské a diplomové práce: • Použití webových služeb v oblasti e-learningu - M. Baláž, • E-learningové CMS a formáty v nich používané - R. Garcar, • Procesní rízení v e-learningu - D. Tovarnák, • Virtuální laboratorře, resource allocation - B. Kabrda. Z techto prací závisí vytvárení modelovacího nástroje na diplomové práci D. Tovarnáka, který se zabývá problematikou spouštení výukových vzoru a procesii. Závislost spocívá v použitých technologiích, které musí být v obou pracích stejné nebo alesponř vzájemneř 2 1.3. STRUKTURA PRÁCE kompatibilní. Přesněji řečeno, výstup vytváření modelu výuky musí být ve stavu co nej-blíže spuštení v behovém prostredí navrženém v dané práci. Ostatních prací se tato dotýká jen okřajove, nebot' je možné, že vytvořené modely výuky budou využívat výstupy techto prací, například formou volání webových služeb. 1.3 Struktura práce Zmapováním nástroju a technologií pro modelovaní procesu se zabývají dve kapitoly práce. Nejprve je osvetleno, co to je business proces, k cemu slouží Business Process Management, jaký je životní cyklus procesu a jaké existují grafické notace pro modelování business procesii. Ve druhé kapitole jsou také střucne zmíneny možnosti spouštení procesia. Jak již bylo naznaceno, další cást práce mapuje notace a technologie používané pro modelování výukových procesu a možnosti jejich spouštení. Ctvřtá kapitola diskutuje možnosti použití technologií v projektu MEDUSY a uvádí, proc bylo vybráno použití Business Process Model and Notation (BPMN 2.0). Diskuse je prová-deřna nad možnostmi technologií z hlediska modelovaní a následné implementace procesu, spouštení procesii, monitoringu a možnosti použití externích služeb v procesu. V kapitole jsou také shrnuty nástroje pro práci s procesy v notaci BPMN 2.0. Abychom mohli přejít k hledání a definování výukových vzoru pro projekt MEDUSY, je vhodné uvést, odkud se vzal pojem vzor a jeho definici. Tím se budeme zabývat v kapitole páté. Ta také ukazuje již používané šablony pro popis vzoru a představuje související projekty, které se venují vzořům ve výuce. Nalezené vzory popisuje další kapitola. Ta ve své první cřásti obsahuje šablonu pro popis vzořu, která bude používána v projektu MEDUSY. Její základ je v textovém popisu scénáře výukového vzoru a v procesním modelu. Po této definici se šestá kapitola venuje vzořům, které lze nalézt ve výuce na vysoké škole - domácí úkoly, individuální a týmové projekty, zkoušky, atd. Šestá kapitola nejprve představuje nástrojvybraný pro úpravu a následne se venuje rozšírení grafické notace o nové prvky a rozšírení funkcionality aplikace. Nad řámec zadání práce se zde venujeme i implementaci ukládání namodelovaných procesu ve vývojářsky prříjemné formeř. Předposlední cást práce obsahuje návod na použití nových prvku aplikace při vytváření modelů výuky. Devátou kapitolou je záveřr, který shrnuje dosažené výsledky a zminřuje možnosti navázání na tuto práci. 3 Kapitola 2 Business Process Management Než se budeme moci věnovat problematice modelování procesia, je nutné osvětlit několik pojmu. Na zaCátku této kapitoly tedy vysvetlím, co to je business proces, k Cemu slouží Business Process Management (BPM, cesky procesní rízení). A dále se budu venovat notacím používaným k zachycení a modelování procesií. 2.1 Business Process Základním pojmem používaným v procesním rízení je business proces. Přicemž existuje nekolik jeho definic [41]. Proces je tok práce postupující od jednoho cřloveřka k druhému a v prřípadeř vetších procesů i z jednoho oddelení do druhého, pricemž procesy lze definovat na celé rade úrovní. Vždy však mají jasne vymezený zacátek, urcitý pocet kroků uprostred a jasne vymezený konec. —M. Robson, P. Ullah Proces je soubor cinností, který vyžaduje jeden nebo více druhů vstupů a tvorří výstup, který má hodnotu pro zákazníka. —M. Hammer Proces je po cástech usporádaná množina kroků, jež smerují ke splnení požadovaného cíle opakovatelným způsobem. —I. Vondrák Proces tedy lze chápat jako cástecne usporádanou množinu cinností, která může vyžadovat jeden nebo více vstupů a která produkuje opakovatelným způsobem požadovaný výstup mající hodnotu pro zákazníka. Každý proces pracuje s událostmi, rolemi a datovými objekty, má definovaný pocátek a konec, může reagovat na události a vetvit se. U každého procesu můžeme merit nekteré jeho parametry - dobu trvání celého procesu nebo jednotlivých cřinností, kvalitu, náklady, atd. Každý proces má svého vlastníka. Vlastníkem procesu [38] je práve jedna osoba, která odpovídá za jeho provádení, za dodržování správného postupu a za jednotlivé cřinnosti. 4 2.1. BUSINESS PROCESS (Činností [25] rozumíme cást procesu, která tvorí jeden logický krok procesu, a její popis. (Činnost muže být automatizovaná, nebo manuální. Manuální cinnost je taková cin-nost, která nepodporuje pocítacovou automatizaci. Automatizovaná cinnost vyžaduje lidské nebo technické zdroje pro vykonání procesu. Lidské zdroje jsou potrebné tehdy, když je cinnost prirazena nejakému úcastnikovi procesu [25]. Role jsou prirazovány k jednotlivým cinnostem procesu s cílem definovat, jaké dovednosti jsou pro danou cřinnost potrřebné. Lidské zdroje jsou poté prřirřazovány k cřinnostem na zákládeř teřchto rolí, urcřují totiž, jak se shodují schopnosti osob s potrřebnými kompetencemi a dovednostmi. Úcastníkem procesu je vetšinou lidský zdroj, který vykonává práci reprezentovanou instancí cřinnosti beřžícího procesu. o- Napsat finanční report Schválit finanční report ■o Obrázek 2.1: Business proces K tomu, abychom mohli s procesy lépe pracovat, je třeba je zadefinovat. Definicí procesu [25] rozumíme jeho reprezentaci ve forme?, která umožnuje automatizované zpracování. Tím muže být modelování nebo vykonání pomocí Workflow Management Systemu. Definice procesu obsahuje informace o síti cinností a vztahu mezi cinnostmi, podmínky pro spušteřní, prřerušení a ukoncření procesu, informace o jednotlivých cřinnostech, úcřastnících procesu, aplikacích a datech. Definice procesu je tvorena popisem techto objektu (entit) [38]: • Proces - popis celého procesu • (Cinnost - definice jednotlivých cinností, z nichž se proces skládá • Přechod - defince prechodu mezi cinnostmi • Účastník - deklarace úcastníku procesu • Aplikace - deklarace aplikací, které proces používá • Data - deklarace dat používaných procesem Rozlišujeme tří druhy procesu [41]: • Primární proces Výsledkem primárního procesu jsou výstupy požadované externím zákazníkem, prředstavují hlavní náplnř práce organizace. Prříklad: Montáž kola, Univerzita vzdeřlává studenty. • Sekundární proces Pro organizace jsou sekundární procesy pouze „doplnkovou" cinností. Jako svuj primární vstup používají sekundární výstup nekterého z primárních procesu v organizaci. Príklad: Univerzita prodává skripta studentum. 5 2.2. BUSINESS PROCESS MANAGEMENT • Podpůrný proces Umožňuje existenci primárních a sekundárních procesia. Príklad: Univerzita ubytovává studenty, Firma poskytuje školení svým zamestňancUm. Už z definice procesu si lze všimnout, že se tento pojem týká prakticky všech organizací. Pomocí procesii je možné zachytit zpusob fungování organizace - výrobní postupy, administrativu, atd. A práve se správou (řízením) procesu se objevuje termín Business Process Management. 2.2 Business Process Management Podle toho, v jaké skupine lidí se pohybujeme, se mení i význam pojmu Business Process Management (BPM) tak, jako ho tito lidé chápou. Podnikoví manažen tento pojem berou jako manažerskou disciplínu, kdežto lidé z oblasti IT jako technologii [6]. Z manažerského pohledu [8] [33] je BPM disciplína, která vede ke zlepšování business procesu v organizaci za pomoci rízení jejich celého životního cyklu. Je to vlastne inženýrský postup, který nahrazuje zlepšování procesu na intuitivní úrovní pomocí razných metod a nástroju. Motivací pro zavádení BPM do organizací krome samotného zlepšování procesu je také snížení provozních nákladu (díky vetší efektivite a lepší organizaci práce) a formalizace procesu a s tím spojené udržení know-how i pri odchodech zamestnancu. Pokud se na BPM podívame jako na technologii [14] [33], zjistíme, že se zacala objevovat v 90. letech. Z pocátku se jednalo jen o modelovací nástroje doplnené o systémy pro správu dokumentu a workflow (zajišťuje lidskou interakci s procesy). Spolecnost Gartner Inc.1 zavedla v roce 2005 termín BPM 2. generace a soucasne urcila, jaké nástroje, technologie a postupy jsou schopny podporovat životní cyklus procesu od zacátku až do konce. Mezi hlavní komponenty BPM systému 2. generace patrí zejména: • Modelovací nástroj - software pro prevod specifikace procesu na procesní model (do grafické podoby) • Procesní engine - behové prostredí pro procesy. Serverová aplikace pro spouštení procesu zapsaných ve spustitelné forme? • Workflow - nástrojpro lidskou interakci • Business Activity Monitoring - nástrojke sledování procesu a jejich instancí v reálném case • Business Rules Engine - behové prostredí pro vyhodnocování rozhodovací logiky uvnitr procesii podle uložených pravidel Takovýto soubor nástrojů se oznacuje jako Business Process Management Suite 2.0. Jak jsem už zmínil výše, BPM se dotýká celého životního cyklu procesu. Ten se sestává z cyklického opakování následujících peti kroku [33] [7]: l. 6 2.2. BUSINESS PROCESS MANAGEMENT • Návrh procesu Smyslem této fáze je vytvoření prvotního návrhu procesu. Vrcholový manažer konzultací s odborným pracovníkem v dané oblasti vytvoří specifikaci procesu. Podle této specifikace se identifikují existující procesy. U tech se uřcí jejich vstupy a výstupy. Dále se urcí úcastníci procesu a vlastník procesu. Také je nutné stanovit ukazatele výkonnosti (Key Performance Indicators, KPI), což jsou financní nebo veřcné ukazatele, které meřrří výkonnost procesu (jedná se o konkrétní meřrřitel-nou hodnotu), např. pro proces obsluhy helpdesku může být jedním z KPI pocet s odpovedí spokojených zákazníků za nejakou casovou jednotku. Důležité je, aby proces byl zachycen správneř a byl úcřinný. • Modelování procesu Jak už z názvu této fáze vyplývá, jejím cílem je proces z fáze předchozí namodelovat. To je úkolem business specialisty. Důležité je zachytit přesne to, co se v procesu deje, způsobem srozumitelným pro všechny úcastníky životního cyklu procesu. K zachycení se používají řůzné grafické notace, nejcasteji Business Process Modeling Notation (BPMN), která je díky své jednoduchosti cřitelná jak pro IT specialisty, tak pro manažery. Navíc jsou pro veřtší srozumitelnost z modelu vy-pušteny technické detaily. Notacím pro modelování se venuje kapitola 2.4. • Implementace, vykonání procesu Vykonáním procesu se myslí jeho spušteřní v beř-hovém prostrředí. To má za úkol integracřní vývojárř. Který musí proces prřevést (implementovat) z grafické reprezentace do spustitelné podoby (BPMN je pouze grafická notace). Tou může být například Business Process Execution Language2 (BPEL). Beřhem implementace se uprřesnřují datové typy, s kterými proces bude pracovat, a propojení na jiné systémy. Proces implenentovaný v BPELu může komunikovat se svým okolím pomocí webových služeb. Také se v této fázi implementují business pravidla pro rozhodování uvnitrř procesu. Soucřástí implementace je její otestování. • Monitorování procesu V této fázi je cílem křome meření výkonnosti procesu získat podklady pro jejich zlepšování a detekovat prřípadné chyby vzniklé ve fázích prřed-chozích. Monitorování probíhá na spušteřných procesech a má jej na starost liniový manažer. K monitorování se používá nástroj pro Business Activity Monitoring, který v reálném case sleduje výkonnost procesu a vyhodnocuje definovaná KPI. Výsledky monitoringu následne slouží k optimalizaci sledovaných procesu. • Optimalizace procesu Pro optimalizaci procesu existují dva důvody. Prvním je zlepšování procesu, tím druhým pak zmena procesu (např. z důvodu zavádení nové technologie). Zlepšování procesu probíhá na základe analýzy údajů z monitoringu. Hledají se úzká místa, neefektivní cinnosti procesu a cinnosti s příliš vysokými náklady na zdroje. Tuto fázi má na starost business analytik, který výsledky své analýzy prředává dál vrcholovému manažerovi, který navrhne optimalizace. Ty prředá k namodelovaní a takto stále dokola probíhá celý životní cyklus procesu. 2. 7 2.3. POSTUP MODELOVÁNÍ PROCESUJ o Vrcholový manažer Liniový manažer IT specialista Obrázek 2.2: Životní cyklus procesu [31] Se zavádením BPMS do podniku prestává být kladen duraz na jejich organizacní strukturu. Funkcní zpusob rízení je nahrazen rízením, které je založeno na procesech. U funkc-ního zpusobu hrály prim dovednosti (specializace) pracovníku, kterí podle nich byli deleni do oddeřlených funkcřních jednotek vykonávajících práci. Koordinace práce a komunikace mezi organizacními jednotkami muže vnášet do podniku radu problému. Procesní zpusob rízení je orientován na výsledný produkt, který je vytváren urcitým sledem cřinností, tedy procesem. Tyto procesy nejsou ovlivneřny organizacřní strukturou. Pracovníci a postup jsou rřízeni procesem. Díky tomu je jasné, kdo s kým má komunikovat, jak má práce postupovat a kdo má za co zodpovednost. Zavedení procesního zpusobu rízení je nutnou podmínkou pro nasazení BPMS do organizace. 2.3 Postup modelování procěsU Pracovní postupy v dnešních organizacích nejsou jednoduché. Práce postupuje bud' od jednoho zameřstnance ke druhému, nebo z oddeřlení do oddeřlení, prřípadneř do tohoto postupu mohou zasahovat externí subjekty. Díky tomu muže docházet k neocekávaným událostem -zpoždení dodávek, chyby v dodávkach, atd. Tyto postupy (procesy) pak mužeme studovat jen pomocí z'ednodušených modelu. Modely musí obsahovat všechny podstatné informace, nebot' slouží ke konzultacím mezi manažery a zameřstnanci. Snahou tedy je zachytit realitu co nejveřrneřji. Pro zachycení procesií existuje nekolik typu reprezentací - slovní (velice neformální forma pro procesy s manuálními cinnostmi), orientovaný graf (vizuální forma) a definice procesu, která by meřla být strojoveř srozumitelná. V této kapitole bych se rád veřnoval vizuální forme procesů - grafickým notacím, nebot' ty jsou nejprehlednejší a vedou k rychlejšímu pochopení modelovaného problému. Nejenom, že modely slouží k vyjasííování situace mezi manažery a zamestnanci, ale také 8 2.4. NOTACE PRO MODELOVÁNÍ PROCESUJ slouží jako model pro implementaci a nasazení BPMS do organizace. Tak jako naprříklad u modelování ve stavebnictví, je i zde nutné zacřít sbeřrem dat. To má na starosti procesní analytik, který musí projít firemní smernice a normy, pozorovat postupy v organizaci a komunikovat se zameřstnanci (vlastníci, management, znalci oblasti). Pokud už procesní analýza v organizaci kdysi probíhala, může použít i její výsledky. Poté následuje vytvorření prvotního návrhu modelu podle zanalyzovaných dat. Tento model projde neřko-lika koly pripomínkování u znalců dané oblasti. Po schválení je vytváren slovník pojmů a vysvetlivek, který může být také využit pri pripomínkování. Posledním krokem je kontrola, kdy se dává výsledek nejen znalcům procesu, ale také vlastníkům. 2.4 Notace pro modelování procesii 2.4.1 Síťové diagramy Jedná se o grafickou reprezentaci cinností vyvinutou v 60. letech 20. století. Základem je vi-zualizace cinností a prechodů mezi nimi. Každá aktivita zachycená na diagramu je popsána jednoznacným identifikátorem a prípadne dalšími parametry (cena cinnosti, doba trvání). Procesy lze dekomponovat do podprocesů a tím získat vetší prehlednost diagramu. Na diagramu je vyznacena jedna pocátecní a jedna koncová aktivita. Existují dva druhy síťových diagramů: i Activity on Arrow (AoA, jinak Arrow Diagramming Method) - uzly reprezentují události (pocřátek, konec cřinnosti) a cřáry reprezentují samotné cřinnosti. ii Activity on Node (AoN, jinak Precedence Diagramming Method) - uzly reprezentují cřinnosti a cřáry znacří závislosti mezi cřinnostmi. Obrázek 2.3: Notace AoA a AoN [41] 9 2.4. NOTACE PRO MODELOVÁNÍ PROCESUJ 2.4.2 Notace WfMC Svoji notaci vydala také Workflow Management Coalition3. Jejich cílem bylo, aby bylo možné proces snadno zadefinovat. Notace podporuje všechny základní komponenty - sekvenCní razení, paralelní vykonání cinností (kdy se více cinností muže vykonávat zároven), výber další cesty podle podmínky a cykly. Na diagramu plyne cas zleva doprava, nebo shora dolu. 2.4.3 Process Flowchart (Diagram procesních řetězců) Jedná se notaci, která se dívá na výrobu produktu nebo dodání služeb z vyšší perspektivy [41] [38]. Diagram procesních retezcu používá k zachycení procesu vývojový diagram, na kterém lze zobrazit jak pruduktivní, tak neproduktivní cinnosti. Do tohoto diagramu je možné zanést i informace, které nejsou pro samotné modelování nutné, napr. trvání cinností (celého procesu) a vzdálenost mezi cinnostmi. K modelování je používáno pet standardních funkcních symbolu - Operace, Inspekce, Transport, (Cekání, Uložení. Diagram procesních retezcu muže být využit i pro analýzu efektivnosti procesu. A to z dtivodu, že obsahuje informace o casech trvání a delí cinnosti na produktivní (operace) a neproduktivní (inspekce, transport, cekání, uložení). Step Operation Transport Inspect Delay Storage Description of process II Distance (feet) 1 □ d v Unload apples from truck 20 2 o V □ d v Move to inspection station 100 ft 3 o d v Weigh, inspect, sort 30 4 o *Cq^ d 7 Move to storage 50 ft 5 o o n Wait until needed 350 6 o ^r"D d v Move to peeler 20 ft 7 d v Apples peeled and cored 15 8 o o ďjS^T Soak in water until needed 20 9 d v Place on conveyor 5 10 o \d d v Move to mixing area 20 ft 11 o ob d v Weigh, inspect, sort 30 Page 1 of 3 Total 430 190 ft Obrázek 2.4: Diagram procesních retezcu [41] 2.4.4 (Control) Data Flow Diagram Data Flow Diagram (DFD, cesky diagram datových toků) je modelovací nástroj[3], který vznikl pro úcely strukturované analýzy systémů. Zobrazuje systém jako sít' procesů, které 3. 1o 2.4. NOTACE PRO MODELOVÁNÍ PROCESU plní urcité funkce a předávají si mezi sebou potrebné informace, a davá tak funkcne (pro-cesne) orientovaný pohled na systém. Jelikož se ve výsledku jedná o jednoduchý a srozumitelný pohled na systém, lze jejsnadno vysvetlit zákazníkovi, s kterým se poté rrrůžerne nad modelem bavit. V notaci existují ctyri základní typy komponent: • Terminátor reprezentuje externí entitu, se kterou systém komunikuje. Jedná se o zdroj (príjemce) všech informací, které do systému vstupují (z nej vystupují). Terminátor se znací obdélníkem s názvem vepsaným uvnitr. • Pročes je jedinou cástí systému, která muže převádet vstupní data na výstupní. Každý proces by mel být pojmenován výstižným názvem a mít jedinecný identifikátor. V diagramu se proces znací elipsou s vepsaným identifikátorem a názvem. • Datový tok vyznacuje, jak se pohybují data nebo fyzické predmety uvnitr systému. Datový tok je v diagramu vyznacřen šipkou, která ukazuje smeřr toku, a názvem, který vystihuje prřenášená data. • Pamet v systému slouží k ukládání dat kvťili pozdejšímu zpracování. Je nejcasteji implementována databází, soubory nebo archivem. Pamet' se znací dvema vodorovnými cřárami s názvem vepsaným mezi nimi. Obrázek 2.5: Proces v notaci DFD Krome diagramu datových toku existuje i jeho rozšířená varianta - diagram datových toku s rízením (CDFD) [3]. V tomto typu diagramu jsou krome dat transformujících procesii znaceny i rídící procesy. Jejich úcelem je synchronizace a rízení systému a jeho funkcí. Rídící proces se zakresluje elipsou s identifikátorem a názvem vepsanými uvnitr. 2.4.5 Petriho síte Další notací, kterou zmíním, jsou Petriho síte [38]. Ty jsou rozšírením modelovacích schopností konecných automatu. Petriho sítí? oznacují širokou trídu matematických modelu, které umožnují modelovat a popisovat rídicí toky a informacní závislosti uvnitr systému. Pro modelování existují trří základní prvky - Místa (Places, dílcří stavy), Prřechody (Transition, prře-chody) a Znacky (Tokens, podmínky). Princip Petriho sítí je založen na prechodech mezi jednotlivými místy v závislosti na rozmísteřní znacřek v daných místech celé síteř. Rozšírření prřinesla do Petriho sítí také operace AND, OR, které zvyšují modelovací schopnosti. 11 2.4. NOTACE PRO MODELOVÁNÍ PROCESUJ Obrázek 2.6: Proces v notaci Petriho sítí [38] 2.4.6 Unified Modeling Language (UML) - Diagram aktivit UML je grafický jazyk pro analýzu, specifikaci, návrh a dokumentaci programových systému, za kterým stojí spolecnost Object Management Group4 (OMG). Jejím cílem bylo navrhnout jazyk pro modelování programových systému, který by podporoval objektove orientovaný prřístup k analýze a návrhu. S postupem cřasu se UML zacřalo používat jako nástroj pro modelování všeobecne [4]. UML je sada 13 diagramu, pricemž UML nedefinuje žádnou metodiku, jak tyto diagramy použít. Diagramy lze rozdeřlit na dva typy - diagramy struktury (naprř. diagram trříd) a diagramy chování, mezi které patrí diagram aktivit [38]. Ty jsou v podstateř „vývojovými diagramy". Procesy lze modelovat jako aktivitu, která se skládá z uzlu spojených hranami. Krome procesu lze diagramy aktivit modelovat i chování tríd a specifikovat prípady užití. Diagram se muže skládat z následujících komponent: • Aktivita reprezentuje vykonání dále nedelitelné cinnosti [38] [41]. Znací vyvolání operace, nebo krok procesu. Aktivita je definována svým názvem. V diagramu se znacří oválem. V prřípadeř, že je aktivita složiteřjší a je rozkreslena na další úrovní diagramu, je toto v diagramu naznacřeno speciálním symbolem. • Pocátecní a koncový stav jsou speciální stavy [38], které explicitne urcují, kde proces zacříná, respektive koncří. V diagramu je pocřátecřní stav vyznacřen vyplneřným kolecř-kem a koncový je oznacřen plným kolecřkem s bílým okrajem. • Prechod znací presun z jedné aktivity na druhou [35]. K prechodu muže dojít tehdy, když je aktivita, z které prřechod vychází, dokoncřena. Prřechod znázornřuje tok rřízení. Prřechod se v diagramu modeluje cřarou s šipkou ve smeřru prřechodu. Prřechody je možné veřtvit. Tak vznikají paralelní a alternativní toky. • Rozhodovací blok neboli alternativní vetvení slouží k vetvení prechodu [38]. Jedná se o vyjádrení logické spojky XOR. Rozhodovací blok zakresujeme do diagramu ko-socřtvercem a podmínka veřtvení je uvedena v hranatých závorkách. Výbeřr cesty pak 4. 12 2.4. NOTACE PRO MODELOVÁNÍ PROCESŮ probíhá podle možných výsledků podmínky (stráž) zapsaných k přechodům, které vycházejí z tohoto bloků. Tyto stráže můsejí být vzájemní? výlůCné a úplné. Pro spojení alternativních toků sloůží taktéž znaCka kosoCtverce. • Synchronizace vyjadrůje logickoů spojků AND [41]. Definůje místo vytvorení a sloů-cení paralelních toků. K paralelnímů vetvení lze pridat podmínků, tak aby se soů-beežný tok vykonal jen pri jejím splnení. Podmínka se zapisuje k prechodů do pod-mínené aktivity. Synchronizace se do diagramů zakreslůje tlůstoů plnoů caroů. • Plavecká dráha sloůží k vyznacení odpovedností za cásti procesů [38]. Jelikož jednotlivé aktivity mohoů být vykonávány různými sůbjekty, je nůtné nejakým způsobem rozlišit, kdo za jakoů aktivitů zodpovídá. Jinými slovy znázornůje úcastníky procesů. Dráhy v diagramů zakreslůjeme obdélníky. • Objektový tok pomáhá v diagramů vyjádrit, jaké objekty se úcastní vykonání aktivity [38]. U každého objektů můžeme evidovat, v jakém stavů se nachází. Ten se pri provedení aktivity může zmenit. Objektový tok spojůje aktivity s objekty a naopak. Tok je v diagramů znacen prerůšovanoů caroů s šipkoů, objekt obdélníkem s vepsaným názvem a stavem. Jako ůkázků vezmeme proces zkoůšení. Toho se úcastní zkoůšející a stůdent. Prvním krokem je zverejnení okrůhů zkoůšení a materiálů, drůhým pak výber otázek pro zkoůšků. Tyto dva úkony provádí zkoůšející. Na třetí aktivite, zkoůšení, pracůje stůdent. Tím vznikne objekt Zkoušky, který je v následůjící aktivite zkoůšejícího oznámkován. Poslední aktivitoů je zverejnení výsledků, která prodůkůje objekt Výsledky. Aktivity Zveřejnění materiálu a Zveřejnění výsledku se skládájí z podprocesů. Ôľ 15 2 N Zveřejnit obsah a materiály L + J Vytvořit a vybrat otázky Poznámkovat^] 1 zkoušky J Zveřejnit výsledky ^ + J -> Výsledky f Student \ ^Zkoušer Obrázek 2.7: Proces zkoušení 2.4.7 Business Process Modeling Notation Business Process Modeling Notation (BPMN) je grafická notace, která vznikla k modelování business procesii. Jedná se o soubor grafických elementu a pravidel pro jejich spojování. 13 2.4. NOTACE PRO MODELOVÁNÍ PROCESUJ BPMN bylo vyvinuto organizací Business Process Management Initiative5, do které je zapojeno mnoho velkých „hráců" na poli vývoje softwaru (Hewlett-Packard, IBM, atd.). První verze vznikla v kvetnu 2004 a formálne byla prijata v únoru 2006. V soucasné dobe existuje BPMN ve verzi 1.2 z ledna 2009 [13]. Primárním cílem autoru bylo vytvorit notaci, která bude dostatecne jednoduchá a srozumitelná pro všechny úcastníky životního cyklu procesu (od business specialistu pres vý-vojáre až k business analytikům). Druhotným cílem bylo vytvorení notace, která umožní modelovat i komplexní business procesy. BPMN zmenšilo mezeru, která byla v komunikaci mezi návrhem procesu a jeho implementací. Díky zainteresování velkých firem a velkému množství nástrojui pro modelování se BPMN stalo de facto standardem pro modelování procesu [12]. Specifikace notace definuje jen grafický zápis procesii. Nedefinuje, jak mají být modely ukládány, prenášeny nebo spoušteny. Definuje však, jak lze jednotlivé elementy jazyka pre-vádet do jazyka Business Process Execution Language (BPEL). Pro zápis procesů je v BPMN urcen jediný typ diagramu - Business Process Diagram (BPD), který je tvoren sítí grafických objektů a toků informací mezi nimi. Jednotlivé grafické elementy mají pevne daný svůj tvar. To zajišťuje, že jsou od sebe všechny elementy dobre odlišitelné. K ješte lepšímu odlišení může pomoci to, že je sice pevne dán tvar elementů, ale můžeme libovolne menit jejich barvu a velikost. V diagramu můžeme použít i vlastní grafický objekt, který nesmí být tvarem zamenitelný s již existujícím elementem. Mel by také sloužit jen pro upresnení diagramu a nemel by tak ovlivnovat tok procesu. BPD rozeznává ctyri kategorie grafických objektů: • Tokové objekty (Flow Objects) • Spojovací objekty (Connecting Objects) • Plavecké dráhy (Swimlanes) • Artefakty (Artifacts) 2.4.7.1 Tokové objekty Mezi tokové objekty patrí ty elementy, které souvisí s tokem informací v procesu a vyjadřují nejakou aktivitu. Tokové objekty lze rozdelit do trech skupin [13]: • Událost (Event) vyjadruje to, co se odehrává v průbehu procesu. To může být prijetí zprávy, cřasový limit nebo chybový stav. Podle toho, kdy událost nastane, deřlíme události na trři typy - pocřátecřní (ty, které proces startují), strřední (nastávají v prui beřhu procesu) a koncové (proces jimi koncí). Pocátecní události znacíme kruhem s tenkým okrajem, strední kruhem s dvema okraji a koncové kruhem s širokým okrajem. Podle typu události zakreslujeme do kruhu znacřky, naprř. obálku, nebo cřasovacř. 5. 14 2.4. NOTACE PRO MODELOVÁNÍ PROCESŮ • Aktivita (Activity) znací jednotku práce, která má být vykonána. Muže být bud' atomická, nebo složená, pak se jí ríká subproces. Aktivita se mUže také opakovat. Do diagramu zakreslujeme aktivity pomocí obdélníku se zaoblenými rohy. Subproces rozlišujeme umístením znacky plus dole uprostřed obdélníku, opakovanou aktivitu malým kroužkem se šipkou tamtéž. Atomické aktivity muže dále rozlišovat, napr. Ůser task (činnost vykonává clovek za pomoci softwaru), Script task (skript, který je spoušten behovým prostredím procesu), Send task (cinnost, která zasílá zprávu externímu úcasníkovi procesu). Mezi další typy patrí: Receive task, Manual task, Service task [13]. • Brána (Gateway) oznacuje místo uvnitr procesu, kde dochází k rozbíhání, nebo sou-behu toku procesu. K rozbíhání dochází na základe podmínky. Vycházející toky se musí vzájemní? vylucovat. Brána taktéž muže oznacovat místo, ve kterém dochází k rozdelení toku za úcelem paralelního zpracování. Brána se zakresluje kosoctver-cem stojícím na špici. Znackou uvnitr kosoctverce rozlišujeme chování brany. 2.4.7.2 Spojovací objekty Slouží ke spojování tokových objektu navzájem nebo s artefakty. Pospojované tokové objekty tvorí kostru procesu. Existují tri druhy spojovacích objektu [13]: • Sekvenční tok (Sequence Flow) urcuje poradí spouštení jednotlivých aktivit. Znací se plnou cřarou s vyplneřnou šipkou. • Tok zpráv (Message Flow) reprezentuje komunikaci mezi dvema úcastníky procesu, kterří spolu komunikují pomocí zpráv. Do diagramu jej zakreslujeme prřerušovanou cřarou s prázdnou šipkou. • Asočiače (Assočiation) se používá ke spojení objektu s dodatecřnou informací. Tou mohou být data, text nebo jiný artefakt. V diagramu je asociace zachycena pomocí tecřkované cřáry. 2.4.7.3 Plavecké dráhy Stejne jako diagram aktivit, BPMN používá k zobrazení úcastníku procesu (nebo jejich rolí) plavecké dráhy. V rámci plaveckých drah existují dva druhy objektu [13]: • Bazén (Pool) reprezentuje jednotlivé úcastníky procesu. V rámci jednoho poolu se nachází vždy pouze jeden proces. Komunikace mezi pooly probíha pomocí zasílaní zpráv. Pool je možné použít jako tzv. blackbox. To znacří ucřástníka procesu, se kterým komunikujeme, ale neznáme jeho interní proces. Graficky je pool znacen obdélníkem s vepsaným názvem úcřastníka. 15 2.4. NOTACE PRO MODELOVÁNÍ PROCESU • Dráha (Laně) je podcástí poolu. V rámci jednoho poolu muže existovat vícero drah. Používá se pro znacení rolí nebo organizacních oddelení. Úcelem je prehlednejší roz-deřlení aktivit procesu. Komunikace mezi dráhami probíhají za pomoci sekvencřních toku. Dráha se rozprostírá uvnitr celého poolu a delí jejbud' vertikálne, nebo hori-zontálneř. 2.4.7.4 Artefakty Artefakty se používají ke znacření dodatecřných a uprřesnřujících informací pro proces. Nesmí však mít vliv na jeho beh. Notace BPMN definuje tri druhy artefaktu [13]: • Datový objěkt (Data Objěct) znací data, která jsou bud' produkována, nebo požadována urcřitou aktivitou. Do diagramu zakreslujeme datový objekt listem papíru (obdélníkem) s prřehnutým rohem. K aktivitám je prřipojujeme asociacřní vazbou. • Sěskupění (Group) se používá pro dokumentacřní oddeřlení cřásti procesu. Nemá žádný vliv na toky v procesu. Seskupení má v notaci BPMN znacřku obdélníku kresleného prřerušovanou cřarou. • Poznámka (Annotation) je informacní text, kterým se ctenárum modelu sdelují do-datecřné informace. K objektu, o neřmž poskytuje informace, je prřipojen asociacřní vazbou. Notaci BPMN shrnuje následující obrázek. Obrázek 2.8: Notace BPMN [12] Pro názornou ukázku notace vezmeme proces interní objednávky ve firme (obrázek 2.9). Proces má jeden pool oznacující celou firmu. Ta se v tomto prípade delí na 3 úcastníky. Jedním je zameřstnanec, který si neřco objednal - objednatel, druhým je technické oddeřlení a posledním financní reditel. Proces zacíná u objednatele, který si vytvorí objednávku. Ta 16 2.4. NOTACE PRO MODELOVÁNÍ PROCESUJ musí projít posouzením a schválením u technického oddelení. Pokud objednávka schválena není, je proces ukoncen. V opacném případe se zjišťuje, zda je cena nižší než 40000 Kc. Pokud ano, je objednávka schválena, jinak objednávku musí posoudit financní ředitel, který ji může bud' schválit, nebo zamítnout. Obrázek 2.9: Proces objednávky v notaci BPMN [11] 2.4.8 Business Process Model and Notation Protože BPMN nepodporuje přímé spouštení procesů a převod do BPELu není příliš uživatelsky příjemný, pustilo se konsorcium OMG do vývoje nástroje, který by umožnoval nejen jednoduché a srozumitelné modelování, ale i přenositelnost modelu a přímé spuštení procesu. Tímto nástrojem by se mela stát notace Business Process Model and Notation (BPMN 2.0). První specifikace BPMN 2.0 se spatřila svetlo sveta v srpnu 2009 ve verzi beta 1. Aktuální verzí je beta 2 pocházející z kvetna 2010 [9]. Proti BPMN prřichází BPMN 2.0 noveř s metamodelem pro vyjádrření procesu. Jelikož se pro business procesy objevila velká rřada notací a je tedy možné zachytit proces a jeho chování různými způsoby, definuje Business Process Definition Metamodel koncept, pojmy, vztahy a sémantiku pro výmenu procesních modelů mezi různými nástroji. Grafická notace je přejata z BPMN, přicemž u nekterých elementů byl pozmenen jejich význam, a navíc je rozšířena o nekolik nových prvků: • Call activity oznacuje v procesu odkaz na jiný globálne definovaný proces, který použijeme jako podproces. Call activity nahrazuje v BPMN 1.2 definovaný znovupou-žitelný podproces. V diagramu zakreslujeme Call activity jako obdélník se zaoblenými rohy s tlusteř zakreslenou okrajovou cřarou. • Eskalace události (Escalation-event) je úplne novým typem události, která nalezne 17 2.4. NOTACE PŘO MODELOVÁNÍ PROCESU uplatneřní pokud potrřebujeme v procesu prřenést zodpoveřdnost za cřinnost na vyšší úroven. Jako jednoduchý príklad eskalace muže posloužit proces žádosti o pujcku. Řekneme, že pracovník banky na prepážce může rozhodovat o pujckách do 20000 Kcř, o vyšších rozhoduje vedoucí pobocřky. A práveř zde je možné použít událost eska-lace, která prřenese zodpoveřdnost za toto rozhodnutí na vedoucího. Jelikož se jedná o událost, ke které dochází v prubehu procesu, v diagramu se zakresluje kruhem se dvema okraji a s nahoru smerovanou „šipkou". • Instance vytvárejíčí brány (Instantiate Gateway) jsou novým konceptem v BPMN 2.0. Jedná se o dve nové brány - paralelní a výlucnou reagující na událost. Tyto brány mohou stát na zacřátku procesu a samotná instance procesu se vytvorří až v momenteř, kdy nastane nekterá z událostí. U BPMN 1.2 šlo obdobné chování simulovat udá-lostní branou umístenou za pocátecní událost, ovšem toto vytvárelo instance procesu drřív, než k události došlo. Symbol pro zakreslení v diagramu je obdobný jako udá-lostní brány z verze 1.2 jen v kosoctverci byl kruh se dvema okraji nahrazen kruhem s okrajem jedním. Mezi branami zustala i původní varianta bran. • Neprerušitelné události Pokud k této události dojde, v procesu dojde ke spuštení paralelní vetve procesu k vetvi hlavní. Ta musí být v procesu odpovídajícím zpuso-bem obsloužena, např. muže dojít ke spojení techto cest. Nepřerušitelná událost se do diagramu zakresluje kroužkem kresleným cárkovanou carou [34]. BPMN 2.0 také prináší dva nové diagramy - konverzacní a model choreografie. Konverzacřní diagramy byly vytvorřeny pro lepší zachycení toho, kdo s kým komunikuje a co si posílají. Úcastníci procesu jsou zachyceni pomoci poolu [10]. I watit to 3ee doctor ŕ -e- \ Patient Contact Dr. Office Dr. Office -9- J Go to see doctor Obrázek 2.10: Choreography task [15] Diagram choreografie reprezentuje detailnejší pohled než konverzacní diagram. Modely choreografie zachytávají sekvence interakcí mezi úcastníky procesu. Základním prvkem je tzv. choreography task, který reprezentuje interakci mezi dvema úcastníky procesu. Na tomto elementu je rozlišeno, kdo komunikaci zahajuje [10]. 18 2.5. spouštEní business procesuj 2.5 Spouštění business procesii Jak jsem již napsal, životní cyklus procesu obsahuje i jeho spušteřní. K tomu je zapotrřebí mít beřhové prostrředí (procesní engine) pro proces a proces zapsaný ve spustitelné podobeř. K tomuto zápisu existují jazyky, které jsou všechny založeny na XML, což jim zarucuje nezávislost na platformeř. Jedním z jazyků, který můžeme použít pro zápis procesu na vykonatelné úrovní je BPEL. Ten rřídí produkci procesu za pomoci volání odpovídajících webových služeb v odpovídající cřas s odpovídajícími parametry. S použitím BPELu se to má tak, že proces zapsaný v notaci BPMN nemůže být přímo spušten, je nutné jejpřevádet do BPELu, přidat mapování promeřnných, volání externích webových služeb, atd. Jedná se o vytvárření stejného modelu v jiné notaci. Další možností je nástrojjBPM 4.4 a jazyk jPDL. Model se vytváří pomocí notace vycházející z BPMN a specifikace jazyka jPDL uvádí, jak takto vytvořený proces spustit. Spustitelným jazykem s patrne nejvetším potenciálem do budoucna je BPMN 2.0. Zací-nají se pro neřj objevovat první nástroje jak pro modelování, tak spoušteřní - Oryx, Activiti BPM Suite a Drools Flow. 19 Kapitola 3 Výukové procesy Tato cřást práce pojednává o tom, jaké technologie lze použít k zachycení výukových pro-cesui . Než se však budu veřnovat prřímo teřmto technologiím, je nezbytné uvést, co to je výukový proces. 3.1 Definice výukového procesu Pod pojmem výukový proces mui žeme chápat cřástecřneř usporřádanou množinu aktivit, která má vést k zlepšení veřdomostí nebo schopností jedincui . Proces má jasneř daný pocřátek a konec, je opakovatelný a mui že vyžadovat jeden nebo více vstupui . Výstupem, který má hodnotu pro zákazníka (studenta), jsou noveř nabyté veřdomosti. Stejneř jako business proces pracuje i výukový proces s událostmi, rolemi a datovými objekty. Zjednodušeneř rřecřeno se jedná o scénáre výuky, které definují, co mají studenti, školitelé a další úcastníci delat s danými zdroji a nástroji (diskusní forum, chat, e-learning). Proces výuky je treba plánovat pred jejím zapocřetím. Jak si můžeme všimnout, definice výukového procesu je témer shodná s definicí business procesu. Jediný rozdíl je v podstateř jen v jejím užším zameřrření. 3.2 Modelování výukových procesii Stejneř jako u business procesui existují i pro modelování procesui výukových dobré dui vody. Modelování má ctyri jasné cíle [21], které mají vést ke zkvalitnení vzdelávání. Jsou to: • definovat pedagogické scénáre, • výmena takto definovaných modelů a objektů, • spoušteřní teřchto scénárřui na pomocí neřjakého LMS systému, • analýza, návrh, diskuse a plánování, co nejvhodneřjšího formátu výuky. Learning Management System (LMS) je pocřítacřový systém urcřený pro správu celého procesu výuky. Obsahuje cřásti pro organizaci, správu a plánování výuky, správu uživatelui (ucitelé, studenti, atd.) a s tím spojenou správu jejich kompetencí. LMS také slouží jako pro-strředí pro správu obsahu výukových kurzui . LMS systémy také obsahují moduly pro sle- 20 3.2. MODELOVÁNÍ VÝUKOVÝCH PROCESŮ dování aktivit uživatelu. Soucástí LMS mohou být i nástroje pro komunikaci a spolupráci uživatelu při plnení požadovaných aktivit [32]. Kvuli výše zmíneným ctyrem cílum vzniklo nekolik typu notací a formátu. Ty se dají deřlit na spustitelné v LMS a nespustitelné. Dále se dají deřlit podle formálnosti, prřesneřji rře-ceno, jakým zpusobem je definován formát zápisu, zda se jedná napr. o XML soubor pevne daný svou XML šablonou, nebo se jedná jen o textový popis, bez udání toho, jak prřesneř má být, která cřást modelu zapsána. Taktéž se notace dají deřlit podle toho, zda využívají vizuální formu, nebo formu založenou na textu [21]. Pro cřloveřka nejsrozumitelneřjší formou zápisu je forma vizuální. Zde se objevily notace vycházející z UML diagramu, prípadne notace nove vytvorené. 3.2.1 CPM (Co-operative Problem-based Learning Metamodel) Jednou z notací vycházejících z diagramu aktivit je notace CPM. Ta vznikla jako výstup disertační práce od P. Laforcade [17] [20]. Už z názvu si lze všimnout, že jejím cílem byla podpora tzv. Problem-based learningu. Což je výuková strategie orientovaná na studenty, ve které studenti spolupracují na rešení problému a vzájemní? si sdelují zkušenosti. Obrázek 3.1: Proces v notaci CPM [20] 21 3.2. MODELOVÁNÍ VÝUKOVÝCH PROCESŮ Díky plaveckým drahám je možné srozumitelne definovat v modelu role, díky aktivitám studijní cinnosti, atd. Soucástí notace je na ŮML nezávislý metamodel, který definuje vztahy mezi jednotlivými elementy. Každý prvek je pevne definován a má s touto definicí pevne svázaná pravidla. Výsledný model je ukládán jako XML soubor odpovídající standardu IMS Learning Design. IMS Learning design (IMS LD) je standard, který vyvinulo IMS Global Learning Consor-tium1 [27]. Jedná se o specifikaci, která definuje jak popisovat výukové scénáre. Tato specifikace nemá užší zameřrření a je pomocí ní možné popisovat všechny typy výuky. Cílem je mít pevneř stanovený formát, který by bylo možné sdílet jak mezi uživateli, tak mezi systémy. Jeho nevýhodou je to, že doposud neexistuje LMS systém, který by bylo možné použít pro jeho spoušteřní. 3.2.2 coUML CPM není jedinou notací pro modelování výukových procesia založenou na ŮML. Príkla-dem další je modelovací jazyk coŮML. Ten lze použít beřhem jakékoli fáze návrhu a vývoje výukového procesu, kde vizuální modely a strukturované popisy mohou být užitecřné pro vývojový tým [19]. coŮML vychází z praxe a zkušenosti autoru a byl publikován v roce 2007 s cílem vyhovet následujícím požadavkům [19]: • podpora pro místní a cřasové aktivity, podpora rozhodnutí (podmínek) a soubeřžnosti, • razné úrovne detailu pohledu na aktivity, • prřirřazení rolí k cřinnostem, • aktivity konzumují, respektive produkují razné dokumenty, • cíle výuky mohou být modelovány a prřipojeny k cřinnostem, • cinnosti mohou být oznaceny bud' „online", „presencní", nebo „blended (smíšené)". Při modelování pomocí coŮML se používají tri druhy artefaktu [19]: • Primární Mezi primární artefakty patrí dva diagramy - model aktivit kurzu, který popisuje aktivity výuky a používá k tomu rozšírření diagramu aktivit a model struktury kurzu, který popisuje komplexní pohled na návrh kurzu a využívá diagram vycházející z diagramu trříd. • Sekundární Sem spadají tri diagramy - model rolí popisuje role (ucitel, student, atd.) a prípadne i vztahy mezi nimi a vychází z diagramu případu užití, model cílů výslovne definuje cíle výuky a jejich vztahy a využívá se diagram tríd a model dokumentu obsahuje seznam v kurzu používaných dokumentu a muže také obsahovat prirazení rolí k temto dokumentum. 1. 22 3.2. MODELOVÁNÍ VÝUKOVÝCH PROCESUJ • Pomocné Mezi pomocné artefakty patří jediný diagram - model balíku kurzu, který obsahuje popis kurzu na vysoké úrovni. Jedná se o tabulku shrnující důležité informace o procesu - název kurzu a jeho popis, textový popis struktury výuky, o jaký typ výuky se jedná, popis prostředí a ve výuce používaných nástrojů, pocty studentů, seznam ucitelů, popis výukové strategie a seznam modelů použitých pro popis celého kurzu. Znacřnou nevýhodou této notace je to, že k ní neexistuje nástroj, který by bylo možné využít prřímo k modelování. Obrázek 3.2: Diagram cílů pro výuku tvorby animací [19] 3.2.3 Prolix Graphical Learning Modeler Aplikace Graphical Learning Modeler (GLM) je jedním z výstupů výzkumného projektu Prolix2, jehož cílem bylo nalézt a vyvinout rřešení pro procesneř orientovaný prřístup k výuce založený na servisne orientované architektuře. Aplikace GLM je založena na Eclipse IDE a je urcena pro modelování výukových kurzů. Ty mohou být ukládány v aplikaci vlastním formátu nebo mohou být exportovány balíky odpovídající specifikaci IMS LD. Jelikož se jedná o specifikaci využívající XML soubory, kterou není lehké se naucit tak, aby byl clo-veřk schopný veřdeřt jak tyto dokumenty psát a balíky vytvárřet, bylo nutné vytvorřit aplikaci, která by toto umožnřovala bez prředchozích znalostí. Výsledkem je aplikace, která schovává implementacní detaily specifikace IMS LD za pomoci funkcí typu „Táhni a pust'". Clovek tak nemusí rozumet technické stránce [24]. GLM využívá vlastní grafickou notaci, ve které je možné barevne rozlišovat aktivity, přiřazovat k nim role, přiřazovat materiály k aktivitám a definovat casy, ve kterých dané 2. 23 3.2. MODELOVÁNÍ VÝUKOVÝCH PROCESŮ aktivity musí proběhnout. V notaci je možné používat jak podmínky, tak paralelní činnosti. Součástí aplikace jsou také vytvorené šablony, které je možné použít ve vlastních modelech. Mezi preddefinované šablony patrí modely pro brainstorming, razné typy diskusí a jedno-minutovku (krátký test pro rychlé overení znalostí). Obrázek 3.3: Proces jednominutovky ve výuce Projekt Prolix byl ukonCen a aplikace se přestala vyvíjet, navazuje na ni aplikace Open-GLM3. 3.2.4 ReCourse Editor GLM není jediným editorem vyhovujícím specifikaci IMS LD. Jen je v podstate jediným, který pro vytvárení kurzů používá grafickou notaci. Mezi další editory patrí ReCourse Edi-tor4. Ten je produktem TENCompetence Foundation5 a zameřrřuje se na uživatele, kterří mají alespon malé zkušenosti se specifikací IMS LD, nebot' se pro vytvárení výukových modelů používají formulárře. 3.2.5 Reload Editor Dalším editorem je Reload Editor. Ten je jedním z výstupui projektu Reusable eLearning Object Authoring & Delivery6 (RELOAD), který se soustředil na vývojopen source nástrojů pro ulehcření vytvárření, sdílení, znovupoužití výukových objektui a služeb. Prřicřemž by použití teřchto nástrojui meřlo vést k rozšírření rozsahu pedagogických prřístupui realizovaných pomocí ucřebních plánui . Sada nástrojui obsahuje Learning Design Editor pro vytvárření zno-vupoužitelných modelui výuky, Metadata and Content Packaging Editor, který slouží pro vytvárření balíku pro sdílení a spoušteřní v LMS systému. Editor podporuje jak formát IMS LD, tak formát SCORM. Pro oba formáty byly vytvoreny i přehrávace, které lze použít k vyzkoušení namodelované výuky [42]. Specifikace SCORM (Sharable Content Object Reference Model) popisuje jak vytvorit výukový obsah, který by byl spustitelný v LMS systému vyhovujícímu taktéž této specifikaci. Rovnež definuje, jaké funkce musí LMS systém podporovat, aby mohl s tímto obsahem pracovat [44]. Podobneř jako ReCourse Editor vyžaduje i Reload Editor alesponř minimální znalosti IMS LD specifikace, nebot' se zde také k vytváření výukového obsahu používají formuláre. 3. 4. 5. 6. 24 3.2. MODELOVÁNÍ VÝUKOVÝCH PROCESŮ 3.2.6 CompendiumLD Dalším z řady nástrojů pro modelování výukových procesia je CompendiumLD, který je vyvíjen jako součást Open University Learning Design Initiative7. CompendiumLD je aplikace pro tvorbu výukových aktivit za pomoci grafického rozhraní. Primární cílovou skupinou uživatelů jsou ucitelé, školitelé a další osoby zapojené do výuky. Aplikace má sloužit jako nástroj, který jim pomuže s vyjadrením predstav o strukture a podobe výuky. Nad modely mohou uživatelé diskutovat a získávat tak podneřty pro jejich zlepšení. Modelování probíhá pomocí vlastní grafické notace metodou „Táhni a pust'". Aplikace slouží pouze jako nástroj pro návrh, jelikož umožnuje export pouze do webových stránek, obrázku a do XML souboru, nikoliv však do spustitelného formátu [16]. Notace v CompendiumLD obsahuje symboly pro definování aktivit, výstupu ucení, materiálů pro ucení, rolí, nástroju pro vytvárení výstupu, casovace pro nastavení casu trvání cřinností a podmínky. Obrázek 3.4: Proces v notaci CompendiumLD [16] 3.2.7 Learning Activity Management System (LAMS) LAMS je systém pro vytvárení, správu, dorucování (studentum) a monitorování výukových cřinností. Systém se zameřrřuje na cřinnosti, které vyžadují vzájemnou spolupráci více lidí. LAMS obsahuje grafické rozhraní pro návrh a vytváření sekvencí výuky, prípadne celých scénářu (procesu). Dále obsahuje systém pro správu uživatelu. Modelování se provádí metodou „Táhni a pust'", kdy uživateli stací umisťovat aktivity do diagramu a poté je pospojovat. Nástrojobsahuje preddefinované symboly pro ruzné individuální cinnosti, skupinové úkoly, konzultace pomocí chatu a diskusních fór, požadavky na odevzdání dokumentu, zkoušení, atd. Studentum se díky tomu mohou nabízet správné nástroje (dokumenty) ve správný cas [29] [30]. 7. 25 3.3. SPOUŠTĚNÍ VÝUKOVÝCH PROCESŮ LAMS není jen systém pro modelování výuky, ale je také LMS systémem. Studenti se tak mohou přihlašovat prímo do systému, ve kterém probíhá výuka a ucitel může jejich postup sledovat. 3.3 Spouštění výukových procesii Jedním z cílů, proC výukové procesy modelujeme, je jejich následné spouštení uvnitr nejakého systému. Pokud se nejedná o nástroj(notaci) ciste jen pro modelování, tak až na LAMS, který je sám sobe LMS systémem, potrebují ostatní notace a nástroje ke spustení vytvorených procesů externí LMS systém. Aby bylo možné procesy do LMS systémů nahrávat vzniklo nekolik standardů, které definují, jak má vypadat balík s výukou a jaké funkce musí mít LMS systém, aby s temito balíky mohl pracovat. Mezi nejznámejší patrí jíž zmínené specifikace IMS LD a SCORM. Pro tu první neexistuje žádný LMS systém, jen prehrávace namodelovaných scénářů. Pro druhou jich však existuje hned nekolik, z tech open source napríklad Moodle nebo Chamilo. Dalším problémem je fakt, že vetšina soucasných nástrojů pro modelování výukových procesů export do balíků podle specifikace SCORM nepodporuje a pokud ano (Reload Editor), tak není úplne snadné tento nástrojpoužívat, nebot' se proces výuky vytvárí prostred-nictvím formulárů. Pokud se proces nahraje do LMS systému, studentovi se pak stacří do neřj prřihlásit a požadovaný proces si spustit. Výukou ho provází LMS systém, který mu zobrazuje cřinnosti k vykonání v tom porřadí, v jakém byly nastaveny vyucřujícím. Pokud se student bude držet pokynů, nemelo by se stát to, že zacne odpovídat na nejaký test bez toho, aby mel alespon k dispozici studijní materiály. Z pohledu vyucujícího je možné v LMS systému sledovat spuštené studentské procesy a díky tomu mít prřehled o tom, jak je kdo pracovitý a jak studenti plní jednotlivé úkoly. Lze průbežne sledovat, kdo si vše nechává na poslední chvíli, i to, zda opakované provádení cřinností vede ke zlepšení znalostí studenta. 26 Kapitola 4 Výběr technologií pro MEDUSY 4.1 Notace a jazyk K tomu, abychom mohli zhodnotit dostupné softwarové technologie, je treba presne urcit, jaké požadavky na ne máme a k cemu presne nám mají tyto pomoci. Pomineme-li základní požadavek v podobe modelování a spouštení procesia, potrebujeme, aby zvolená notace pro modelování byla jednoduchá a dostatecne srozumitelná pro všechny osoby zapojené do vytvárení kurzu. Ruku v ruce s tím jde požadavek na co nejjednodušší postup implementace procesu, tedy prevodu diagramu do spustitelné formy. Dále je potrebné mít přehled o efektivnosti navržených procesií a postupu studentu v jimi spuštené instanci výukového procesu. Užitecné muže být hodnocení technologií podle toho, zda umožnují za behu procesu volat externí služby. Toho se dá využít napríklad za situace, ve které si uätel v jedné cřinnosti procesu zvolí, jaké stanice chce v ucřebneř prřipravit a tento jeho požadavek se za pomoci webové služby odešle. Zajisté tento výcet neobsahuje všechna možná kritéria, podle kterých je možné technologie hodnotit, jedná se však patrneř o ty nejdui ležiteřjší. Mezi další zajímavá doplnřková kritéria lze zarřadit kvalitu dokumentace. Jelikož se má ve výsledku jednat o systém založený na procesech, budeme dále uvažovat jen ty technologie a notace, které vedou ke spustitelnému procesu. 4.1.1 Modelování První modelování, ke kterému beřhem vytvárření kurzu dochází, je to, jež má zachytit základní prui beřh kurzu. Takovýto model vytvárří vedoucí kurzu, pro kterého je dui ležité, aby zachytil realitu pokud možno co nejveřrneřji. K tomu potrřebuje notaci, která mu toto umožní a prřitom bude jednoduchá na pochopení, srozumitelná i pro ostatní osoby zapojené do výuky a jednoznacná. Velkou výhodou notace může být i prenositelnost modelu a to zejména, pokud na jeho vytvárření spolupracuje více lidí. Vezmeme-li notace pro modelování výukových procesui , tak nejprřehledneřjší a nejjedno-dušší na pochopení jsou ty, které vychází z UML, zejména z diagramu aktivit - notace CPM. Ovšem ani notace použité v LAMS a GLM v prehlednosti a jednoduchosti nezaostávají, nebot' jsou cíleny přímo na vyucující a nepredpokládá se zpracování modelu další osobou. Z pohledu business procesu se jako nejjednodušší jeví jeví notace BPMN a BPMN 2.0, které byly navrženy s cílem jednoduchosti a srozumitelnosti pro všechny úcastníky životního cyklu procesu. 27 4.1. NOTACE A JAZYK 4.1.2 Implementace Dalším krokem ve zpracování výukového procesu je jeho implementace podle modelu. To je vetšinou úkolem programátora. Zámerne píši vetšinou, nebot' pri použití nástroje GLM není další prřevod vytvorřeného modelu nutný, stacří jen, aby si vyucřující sám v editoru nastavil všechny potrřebné náležitosti. V prípade použití nástroju a technologií z oblasti business procesů je prevod modelu u neřkterých notací nevyhnutelný. Model v notaci BPMN je nutné prřevádeřt do BPELu, prří-padneř je možné oželet jistou dávku prřehlednosti a použít nástroj, který sice používá notaci podobnou BPMN, ale ukládá model přímo do BPELu, napr. Intalio Designer nebo jBPM. Do budoucna se nejperspektivneřji jeví použití BPMN 2.0, které, co se notace týká, vychází z BPMN a k nemu definuje metamodel pro ukládání a prenos modelů mezi nástroji a sémantiku pro spouštení procesů. Pri použití BPMN 2.0 by vyucujícímu stacilo namodelovat proces a další vlastnosti a údaje by doplnil programátor prřímo do tohoto modelu, z procesu implementace by tím vypadlo akékoliv prřekreslování modelu. 4.1.3 Spouštení pročesU (behová prostredí) Aby dva výše zmíneřné kroky meřly smysl, e trřeba namodelované a implementované procesy spustit v beřhovém prostrředí. Všeobecným problémem témeřrř všech notací a technologií zameřrřených na výukové procesy e to, že sice umožnřu í export do spustitelného formátu (IMS LD), avšak pro tento formát neexistu e žádné beřhové prostrředí. Jediným v LMS systémech spustitelným formátem je SCORM, pro ten zas na druhou stranu neexistuje grafický modelovací nástroj. Spouštet balíky vytvorené podle specifikace SCORM je možné napr. v LMS systému Chamilo. Zvláštním prřípadem je systém LAMS, který je sám sobeř beřhovým prostrředím. O poznání lepší situace vládne na poli spouštení business procesů. Pro BPEL jich existuje neprřeberné množství, namátkou naprř. Apache ODE nebo OpenESB. Pro jazyk jPDL je procesním enginem jBPM. O poznání horší situace se objevuje na poli volneř dostupných behových prostredí pro BPMN 2.0, nebot' existují jen dve - Activiti a Drools Flow. S tím, že podpora BPMN 2.0 by se mela objevit i v jBPM od verze 5. 4.1.4 Monitoring Důležitou funkcí, bez které se procesne orientovaný e-learningový systém neobejde, je monitoring bežících procesů. Vyucující jejmůže využít pro sledování toho, jak jeho studenti postupují kurzem, zda plní to, co mají a jak jsou prři tom úspeřšní. Další osobou, která monitoring procesů využije, je procesní analytik, prípadne správce procesního behového pro-strředí, který sleduje, zda jsou implementované procesy efektivní a zda by je nebylo možné vylepšit. První cást monitoringu, monitorování studentů, je soucástí vetšiny dnešních LMS systému, ve kterých lze sledovat co studenti splnili, co jim zbývá a jak byli pri plnení úkolů úspeřšní. Druhá cřást monitoringu v teřchto systémech chybí. 28 4.1. NOTACE A JAZYK Zameríme-li se na oblast bůsiness procesia, tak v ní se poůžívá k monitorování procesia Bůsiness Activity Monitoring, ve kterém se ke sledování procesii poůžívají khcové ůkazatele výkonnosti (KPI). Ty merí konkrétní hodnoty a dávají na výstůp, jak se darí, ci nedarí plnit plánované hodnoty. Přeneseme-li KPI do procesů vzdelávání, tak príkladem jednodůchého ůkazatele může být pocet stůdentů, kterí dosáhli v průbežném testů více jak 70% úspešnosti. K monitorování stacří jen správneř ůrcřit, co chceme sledovat a s jakými hodnotami máme na-merené srovnávat. Kvalita monitorovacích nástrojů se však liší nástrojod nástroje a nekterá beřhová prostrředí pro procesy ani komponentů pro monitoring zatím neobsahůjí (Activiti). 4.1.5 Použití externích služeb v procesu Jak jsem již zmínil na zacátků kapitoly, ůžitecnoů schopností procesů může být možnost volání slůžeb externích systémů ůvnitr procesů. Jako príklad byla ůvedena príprava pracovních stanic. Tím možnosti volání slůžeb nekoncří, pomocí slůžeb je teoreticky možné získat seznam stůdentů predmetů z jiného systémů, různé materiály, ci si nechat generovat licencní cřísla k aplikacím poůžívaným v dalších cřinnostech ůvnitrř procesů. Možnosti vyůžití slůžeb jsoů široké a je vhodné tůto schopnost do systémů ůmístit. V prípade technologií cílených na vytvárení výůkových procesů poůžití webových slůžeb není možné v žádné z nich. U bůsiness procesů toto však možné je. Volání externích slůžeb podporůje jak BPEL, tak jBPM i BPMN 2.0. 4.1.6 Dokumentace Celkem zajímavým kritériem, podle kterého se dají systémy hodnotit, je kvalita poskytované dokůmentace. Teřžko lze prři nasazování systémů nebo zavádeřní technologie ocřekávat, že vše půjde hladce a nevyskytne se žádný problém. Prvním místem, kam se pri výskytů problémů cřloveřk podívá, je dokůmentace a jediné, co je zde možné rříci, je to, že její kvalita se liší prodůkt od prodůktů a nelze vyvozovat obecné záveřry. U CPM se dokůmentace na webových stránkách aplikace nachází, jejím nedostatkem je její malá obsáhlost a jazyk poůžitý pro její zápis. Dokumentace je totiž psána ve francoůz-štineř. V prřípadeř systémů LAMS je dokůmentace na výborné úrovní, kromeř textového popisů instalace a poůžití, obsahůje i video tůtoriály, casto kladené otázky a různé technické informace. U nástrojů pro vytvárení bůsiness procesů existůjí dokumentace prímo pro jednotlivé nástroje nebo i prímo specifikace jazyků a standardy pro zápis procesů, které je možné pro získání informací taktéž poůžít. 4.1.7 Shrnutí Jak si lze všimnoůt podle jednotlivých cřástí, hodnocení vychází nejlépe pro nástroje a technologie z oblasti bůsiness procesů. Ono je to logické, nebot' vždy se rozvíjí lépe to, co ge-nerůje zisk, nebo alespon minimalizůje ztráty. A to je práve jeden z důvodů, proc Bůsiness 29 4.2. NÁSTROJE PRO PRÁCI S BPMN 2.0 Process Management vznikl. Tedy do vývoje BPM byly vloženy znacné financní prostredky, které se s postupem cřasu meřly v podobeř úspor vrátit. Kdežto v prřípadeř rozvoje technologií pro výuku se jedná ve veřtšineř prřípadui jen o akademické iniciativy, kterým se neveřnuje dostatecné množství lidských a financních zdroju. Z tohoto duvodu jejich vyspelost není taková a pro další práci na vývoji procesneř orientovaného e-learningového systému bych se odvážil doporucřit veřnovat jen technologiím z oblasti BPM, prředevším pak BPMN 2.0, které i když není prozatím standardem, má velký potenciál ulehcřit implementaci procesui a jejich prenositelnosti z/do ruzných systému 4.2 Nástroje pro práci s BPMN 2.0 Cílem této podkapitoly je nalézt nástroj, kterým by bylo možné modelovat výukové procesy v notaci BPMN 2.0 s tím, že namodelované procesy musí jít dále zpracovávat - implementovat a spouštet. Nesmí se tedy jednat jen o grafické modelování, ale musí být možné v nástroji ukládat namodelovaný proces jako XML soubor vyhovující specifikaci BPMN 2.0. Jelikož se v prípade projektu MEDUSY jedná o open source projekt, je nutné hledat jen nekomercřní nástroje. Mezi ty patrří Oryx editor a jeho deriváty použité dalších projektech, prípadne další grafické nástroje vznikající v rámci techto projektuj. 4.2.1 Oryx editor Oryx je webový editor pro modelování business procesuj pomocí ruzných grafických notací, napr. Event-driven Process Chain, BPMN 1.2, BPMN 2.0, atd. Jedná se o akademický open source projekt z veřtší cřásti vyvíjený v rámci Business Process Technology Group1 na Hasso-Plattner-Institute. Cílem projektu je umožnit lidem vytváret a sdílet modely s business partnery, klienty a dalšími osobami. Modely je kromeř sdílení možné upravovat i ve více lidech v rámci jednoho vývojového (modelovacího) prostrředí. Jedná se o názornou ukázku Web 2.0 v praxi, která dovoluje zájemci o modelování pracovat bez toho, aby musel instalovat na svém pocřítacři cokoliv kromeř webového prohlížecře. Editor je vytvárřen tak, aby byl rozširřitelný. Je tedy možné do neřj prřidávat další notace nebo další funkcionalitu. Pro nás je v editoru nejzajímavejší funkcí modelování pomocí notace BPMN 2.0. Tu editor implementuje v její poslední verzi (k 19.10.2010 se jedná o beta2 verzi z kvetna 2010). S tím, že krome modelování editor obsahuje funkce pro export vytvorených modeluj, aby je bylo možné prenášet do dalších nástrojuu nebo je spouštet, nebot' v editoru je možné definovat atributy jednotlivých prvkuj modelu i celého procesu. Export vytvorřených modeluj je možný do xml souboru podle specifikace BPMN 2.0, do xpdl souboru (xml formát pro výmenu procesních modelu mezi ruuznými nástroji), grafických formátu (png, svg) a pdf souboru. Pokud se na editor Oryx podíváme z technologického hlediska, nalezneme za ním JavaScript na straneř klienta a jazyk Java na straneř serveru. A práveř použitím teřchto dvou jazykuj je možné funkcionalitu editoru rozširřovat. Dalším možným rozšírřením je prřidání vlastní grafické notace nebo úprava stávající. 1. 30 4.2. NÁSTROJE PRO PRÁCI S BPMN 2.0 To se provádí vytvárením tzv. Stencil Setu. Což je popis grafických objektu a pravidel, které urcují jak spolu tyto objekty souvisí. Grafickým objektem muže být napríklad uzel (obdélník) nebo hrana (šipka), která spojuje dva grafické objekty. Soucástí stencil setu jsou další doplnřkové atributy, které je pak možné využít prři dalším zpracování - export do vlastního formátu nebo úprava vzhledu diagramu (zmena barvy objektu) [39]. Úpravou funkcionality Oryx editoru vznikl komercní modelovací nástrojSignavio Process Editor. Ten neřkteré své cřásti uvolnil pod MIT License2 jako Signavio Core Components3. Ty jsou využity jako soucást projektil Activiti, Drools Flow a mají být využity i v jBPM. 4.2.2 Activiti Presneji Activiti BPM Suite je workflow a BPM systém, jehož primárními uživateli jsou lidé (management) z business oblasti, vývojárři, procesní analytici a systémoví administrátorři. Základem tohoto open source systému je procesní engine vytvorřený v jazyce Java. Ten podporuje jen procesy vytvorřené v BPMN 2.0 a snaží se o co nejlepší podporu vytvárření spustitelných procesu. Dovoluje vývojárum vytváret „vlastní" aktivity podle požadavku managementu jako trřídy v jazyce Java a tím mohou vznikat komplexní aktivity a prřitom model procesu zůstává takový, jak jejmanagement navrhl. Architekturu systému naznacuje obrázek 4.1, na nemž jsou modre vyznaceny komponenty, kterými se projekt Activiti zabývá [1]. Dedicated Tools Stored Content Collaboration _ _ Tool Obrázek 4.1: Architektura Activiti BPM Suite [1] Mezi komponenty systému patrří webová aplikace Activiti Explorer pro správu cřinností (prihlašování se k cinnostem a jejich vykonání) a spouštení instancí procesu. Její funkcio- 2. 3. 31 4.2. NÁSTROJE PRO PRÁCI S BPMN 2.0 nalita by meřla do budoucna umožnit prřesunutí cřinnosti na jinou osobu, zjistit, kterří další uživatelé systému jsou do procesu zapojeni, vytvárřet dílcří cřinnosti a ty prřirřazovat uživate-lum a monitorovat instance procesu. Systémovým administrátorum je urcena aplikace Activiti Probe, která je urcena pro monitorování beřhového prostrředí jako celku. Lze pomocí ní zjistit, zda je procesní engine spuš-teřn, nebo zda dochází k neřjakému problému. Také v režimu cřtení umožnřuje prřístup k databázi, která obsahuje informace o uživatelích, procesech a jejich instancích. Do budoucna by se v této aplikaci mely objevit funkce pro správu uživatelu a uživatelských skupin. Další komponentou v Activiti je aplikace s názvem Cycle. Jejím cílem je usnadnit prubeh životního cyklu procesu. Usnadnení má probíhat sdílením dokumentu a modelu mezi všemi osobami zapojenými do životního cyklu, aby byla nad všemi materiály možná diskuse. Z pohledu této práce je nejduležitejší soucástí systému Activiti Modeler. Jedná se o webovou aplikaci vycházející ze Signavio Core Components a upravenou takovým zpusobem, že jediným podporovaným typem diagramu je Business Process Diagram podle notace BPMN 2.0, který je ukládán v souborovém systému na serveru ve forme xml souboru dle specifikace. Stejne jako u editoru Oryx je i tento možné rozširovat o další grafické notace vytváre-ním stencil setu. Jako iniciativa k projektu vzniká i modelovací nástroj jako plugin do prostrředí Eclipse IDE. Jelikož je vývoj témeřrř na úplném zacřátku, obsahuje nástroj jen neřkolik málo základních objektu. Do budoucna se tento nástrojjeví zajímave, umožnil by totiž, aby se k návrhu, implementaci a nahrání balíku s procesem na server použil jediný vývojový nástroj. 4.2.3 Drools Flow Dalším systémem, který se snaží zaintegrovat do sebe podporu BPMN 2.0 je komunitní projekt Drools Flow4 spadající pod JBoss spolecnosti Red Hat. Jedná se o projekt zamerený na modelování a spouštení business procesu. Ke spouštení se využívá další z komunitních projektu této organizace, BPMS systém s názvem Drools Guvnor. K modelování procesu zde slouží bud' plugin do Eclipse IDE, nebo je zde i k dispozici editor založený na Oryxu. S obema editory se však objevuje nekolik nedostatku. Prvním je ten, že editor pro Eclipse IDE neobsahuje všechny konstrukty jazyka BPMN 2.0. U druhé možnosti modelování vyvstává problém s tím, že dostupný editor pracuje jen se specifikací BPMN 2.0 ve verzi beta1, zatímco procesní engine ocekává vstup v podobe procesu dle specifikace beta2. Dokumentace systému proto navrhuje i tretí možnost vytvárení modelu a to formou rucřního psaní xml souboru. U celého systému se objevují ješteř další dva nedostatky. Jedním ze zastaralost dokumentace, která se témer celá venuje vlastní notaci a o použití BPMN 2.0 nabízí jen velice strohé informace. Poslední problém se objevuje prři nahrávání procesu do Guvnor aplikace. Tam se procesy ukládají do složek podobným balíkum z jazyka Java. Aby bylo možné proces spouštet, je nutné balík s noveř nahraným procesem sestavit. Pokud prři sestavování dojde k chybeř (v xml 4. 32 4.2. NÁSTROJE PRO PRÁCI S BPMN 2.0 souboru je chyba), systém zareaguje vypsáním obecné chybové zprávy, ze které není možné zjistit, k cřemu došlo a kde chybu hledat. Na druhou stranu tento BPMS systém obsahuje komponentu pro monitoring procesu. 4.2.4 jBPM5 Posledním volneř dostupným systémem, který má obsahovat podporu pro BPMN 2.0 je jBPM 5. V prípade tohoto systému se jedná také o komunitní projekt JBoss. Systém je kompletne postaven na predchozím nástroji. Oficiálne ješte nebyla uvolnena verejná verze a jsou k dispozici pouze verze vývojové, které si prřenesly neřkteré chyby z nástroje Drools Flow (sestavování balíku, editor pro Ecipse IDE s neúplnou podporou všech prvku). 4.2.5 Shrnutí (liste z pohledu modelování procesu je jedno, zda se v projektu MEDUSY použije přímo editor Oryx, nebo nástrojz nej odvozený. Duležité je, aby na vybraný nástrojnavazovaly nástroje další tak, aby s nimi bylo možné pokrýt celý životní cyklus procesu. Už z popisu jednotlivých produktu si lze všimnout, že s podporou BPMN 2.0 je na tom nejlépe systém Activiti BPM Suite. Sice neobsahuje všechny potrřebné komponenty, protože mu chybí proti Drools Flow modul pro monitoring, ale vývoj nástroje neustále pokracřuje a další verze jsou plánovány v mesícních iteracích. U ostatních systému je postup prací a jejich harmonogram nejasný. Po konzultaci projektového týmu MEDUSY, jsme se rozhodli použít pro další vývoj e-learningového systému Activiti BPM Suite. Ten kromeř výše zmíneřného nabízí možnost vývoje vlastních aplikací, které by se systémem Activiti spolupracovaly. Navenek totiž poskytuje rozhraní REST, kterým je možné se systémem komunikovat, naprříklad jím lze nahrávat implementované procesy, formulárře k uživatelským cřinnostem, atd. Popis tohoto rozhraní je uveden v uživatelské dokumentaci produktu. 33 Kapitola 5 Vzory V první cřásti této kapitoly postupneř popíšeme, co to jsou vzory, k cřemu slouží ajaké zpui soby pro jejich popis existují. Druhá cřást prředstavuje neřkolik s výukovými vzory souvisejících projektui . 5.1 Vzory 5.1.1 Definice Definic pojmu vzor se v průbehu casu a v různých oborech objevilo povícero. Nejvíce jsou vzory používány v: • architekturře, • softwarovém inženýrství, • pedagogice a e-learningu. A práveř v architekturře se pojem vzor objevuje poprvé. Bylo to na konci 70. let 20. století v pracích stavebního architekta Ch. Alexandera. Ten v nich popsal rřadu prříkladui architektonických návrhui ohledneř rozložení meřst nebo návrhu interiéru bytu v jednotném formátu. A v knize A Pattern Language: Towns, Buildings, Construction [2] sepsal první definici pojmu vzor. Každý vzor popisuje problém, který se v našem prostrředí vyskytuje znovu a znovu a popisuje jádro rřešení tohoto problému takovým zpui sobem, že mui -žeme toto rřešení použít kolikrát potrřebujeme bez toho, abychom deřlali stejnou veřc dvakrát. —Ch. Alexander Ackoliv se pojem vzor objevil v architekture, približne o 10 let pozdeji nalezl své uplatnení také v softwarovém inženýrství a návrhu uživatelských rozhraní a v druhé polovine 90. let se objevuje jeho použití při definici pedagogických (výukových) scénářů a popisu výuky. V softwarovém inženýrství se o rozšírření tohoto pojmu postarala zejména kniha Design Patterns: Elements of Reusable Object-Oriented Software [26], napsaná tzv. Gang of Four1 1. 34 5.1. VZORY (GoF), která se zabývá objektove orientovanými návrhovými vzory, jež definuje jako snadno použitelné, systematické popisy pojmenovaných, významných a opakujících se návrhových problému v objektove orientovaných softwarových systémech. A cílem je abstrakce od jakékoliv konkrétní formy. V oblasti pedagogiky se vzory zacřal v devadesátých letech zabývat The Pedagogical Patterns Project2, pricemž v poslední dobe zacíná být o použití vzoru zájem v oblasti e-learningu, kam vlastneř svým zameřrřením spadá i tato práce. Dle Pedagogical Patterns Project (PPP) slouží vzory k zachycení té nejlepší praxe z urcřité oblasti, v jejich prřípadeř v oblasti výuky a ucení tak, že vždy reší nejaký problém, který se muže vyskytovat v ruzných kontextech. Projekt PPP je orientován spíše na organizacní stránku výuky, napr. v jakém poradí vy-ucovat látku ruzné složitosti, jak motivovat studenty a jak je hodnotit. Pro oblast e-learningu se však spíše hodí pojetí vzoru obdobné jako v architekture (od Ch. Alexandera), nebot' cílem není nalézt a použít ty nejlepší príklady, ale nalézt rešení ruzných problému s tím, že ten, kdo bude vytvářet e-learningový kurz, si vybere to pro nej nejvhodnejší řešení [18]. Ono jak si lze povšimnout, tak definice vzoru od Alexandera je sepsána tak obecným zpusobem, že z ní nelze poznat, v jakém oboru vznikla, ale to není na škodu, nebot' je díky tomu možné snadno shrnout poznatky o definicích. Ve svete, ve kterém žijeme, se casto rřeší opakované problémy, které acřkoliv nemusí být stejné celé, neřjaká jejich cřást se opakovat muže. A práve popisem jádra řešení casto opakovaného problému se zabývají vzory, které musí být, co nejvíce abstraktní, tedy nesmí být svázány s konkrétní instancí neřjakého problému. Takováto provázanost by snížila znovupoužitelnost vzoru. Soucřástí vzoru není jen popis rřešení problému, ale také popis problému samého, název vzoru, motivace pro použití daného rřešení, atd. Tím se dostáváme k další podkapitole, která se zabývá práveř popisem vzoru. 5.1.2 Popis vzorU K tomu, aby vzory byly použitelné a tím pádem pro nás mely smysl, je nezbytné, je srozumitelným zpusobem popsat. První zpusob popisu vzoru se objevil s jeho první definicí. Ch. Alexander popisoval vzory pomocí nekolika elementu, mezi ty nejduležitejší patrí [23]: • Názěv - jednoznacný název identifikující vzor. • Kontěxt - situace, ke kterým se vzor vztahuje. • Okolnosti (požadavky) - okolnosti, které mohou omezit rešení, nebo navrhnout re-šení alternativní. Pokud se neřkteré okolnosti navzájem ovlivnřují, je rřešení problému složiteřjší. • Řěšění - popis zpusobu, jak rešit näzné okolnosti. Muže obsahovat diagramy a obrázky. • Vztah k dalším vzorum 2. 35 5.1. VZORY Další formou popisu vzoru je ta, kterou navrhl GoF pro své objektově orientované návrhové vzory. Popis vzoru se skládá z následujících 13 elementu [18]: • Název vzoru a klasifikace - jméno strucne sdelující podstatu vzoru a klasifikace, která urcuje typ vzoru. • ÚCel vzoru - oznacuje princip vzoru, co daný vzor delá a jaký návrhový problém řeší. • Další názvy - seznam názvu, pod kterými je tento vzor také znám. • Motivace - obsahuje scénář, který ilustruje návrhový problém a popisuje, jak tento vzor problém rřeší. • Použitelnost - udává příklad situací, ve kterých muže být daný vzor použit a popisuje, jak tyto situace poznat. • Struktura - grafická reprezentace tříd vyskytujících se ve vzoru zakreslených v notaci Object Modeling Notation (OMT) a diagramy interakcí, které slouží pro popis spolupráce mezi objekty. • ÚCastníci - seznam tríd a objektu vyskytujících se ve vzoru a jejich zodpovedností. • Spolupráce - popis toho, jak spolu úcastníci spolupracují za úcelem splnení jejich zodpoveřdností. • Dusledky (následky) - popisuje zmeny a výsledky použití vzoru. • Implementace - uvádí seznam nedostatku, rad, technik a na použitém jazyku závislých problému ohledne implementace daného vzoru. • Ukázkový kód - ukazuje fragmenty zdrojového kódu s cílem ilustrovat možnou implementaci vzoru. • Príklady použití - uvádí minimálne dva příklady použití vzoru v reálných systémech, pricemž tyto príklady musí pocházet z razných domén. • Související vzory - obsahuje seznam vzoru souvisejících s tímto, uvádí rozdíly mezi nimi a seznam vzoru, s kterými je možné tento použít. K popisu techto elementu se používá text, diagramy a fragmenty zdrojových kódu. Co se definování vzoru týce, nezťistala pozadu ani oblast e-learningu. A i zde vznikly šablony pro popis nalezených vzora Šablona projektu E-LEN3je ciste textová a vychází z Ale-xanderovy šablony. O poznání zajímaveji se jeví šablona definovaná v rámci projektu Person Centered e-Learning4 (PCeL), nebot' její soucástí je i použití UML diagramu. Tato šablona obsahuje 10 elementu pro popis vzoru [18]: 3. 4. 36 5.2. SOUVISEJÍCÍ PROJEKTY • Název vzoru - smysluplný název stručně sdělující podstatu vzoru. • Úcel vzoru - krátký text o situaci nebo scénáři, na který se vzor zaměřuje. • Motivace - pokud je to vhodné, je zde uvedena motivace pro použití vzoru, napríklad zde mohou být uvedeny nedostatky tradicního scénáre (prubehu), nebo efekty, které má použití vzoru na výuku. • Scénár - v závislosti na úcelu vzoru tato cást popisuje žádanou podobu nebo jinak se opakující scénár, který popisuje vzor. • Sekvence - tento element popisuje sled aktivit ve scénári modelovaný jako diagram aktivit z jazyka UML. • Struktura - ukazuje asociace a vztahy mezi entitami zapojenými do scénáře v podobe UML diagramu popisujících statickou strukturu (nejcasteji diagram tríd). • Taxonomie (závislosti) - tato cást vkládá vzor do hierarchické síte vzoru založené na generalizaci a specializaci. • Parametry - zde je uveden seznam parametru vzoru a jejich hodnot, napríklad je zde možné uvést pocet úcastníku scénáre, vstupy a výstupy scénáre, požadovanou úroven odborných znalostí, autora scénáře a další dle potreby. • Príklady - tato cást popisuje príklady uvedení vzoru do praxe. • Webové šablony - pokud je to vhodné, tato sekce uvádí jak lze vzor podporit v rámci webového výukového prostredí, například je zde možné uvést prototypy uživatelských rozhraní. Z techto šablon je možné odvodit nejduležitejší atributy, které vzory popisují. Patrí sem zejména název vzoru, jeho úcřel, motivace pro použití a kontext, ve kterém je daný vzor vhodné použít. Pokud je to možné, tak je vhodné pro snadneřjší pochopení uvést také neřja-kou grafickou formu vzoru, at' už obrázek, nebo diagram. 5.2 Související projekty V kapitole s definicemi vzoru jsem zmínil, že pro oblast e-learningu je vhodnejší definice od Ch. Alexandera. V kontextu projektu MEDUSY a modelování výukových procesia to znamená, že při vytváření procesních modelu chceme, abychom nemuseli casto opakované cřásti výuky modelovat stále dokola. Potrřebujeme tedy tyto cřasto opakované cřásti (vzory) zdokumentovat a zakreslit takovým zpusobem, aby je ten, kdo bude model výuky vytváret, mohl snadno prři své práci využít. V prředchozí kapitole jsem prři popisu šablon zmínil, že výukovými vzory se zabývaly i jiné projekty. Nekteré z nich byly (jsou) teoretictejší a zabývají se výukovými vzory z pedagogického hlediska a chováním osob zapojených do výuky, ty další se oblasti e-learningu dotýkají více. 37 5.2. SOUVISEJÍCÍ PROJEKTY 5.2.1 Pedagogical Patterns Project Asi prvním projektem, který se zacal zabývat využitím vzorů ve výuce, je Pedagogical Patterns Project (PPP). Cílem projektů je hledání a sber vzorů, které mají pomoci vyuCujícím lépe ucit a studentům lépe studovat. Jde vlastne o sdelování zkušeností ohledne provere-ných metod výuky [40]. Výstupem projektu jsou vzory v podobí? výukových scénářů zachycených v textové podobe. Vytvorené vzory nejsou svázány s žádnou konkrétní oblastí pedagogiky a ani nepopisují, jaké technologie se mají použít [18]. Při popisu nalezených vzorů se používá šablona vycházející z Alexanderovy a popisuje vzory ve cřtyrech cřástech. První zasazuje vzor do kontextu, druhá zachycuje okolnosti a klí-cřový problém, trřetí navrhuje rřešení a poslední cřtvrtá cřást obsahuje diskuzi nad rřešením a príklady [40] [18]. V rámci projektů vznikly vzory obsahující popis toho, jak udržet studenty aktivní v prů-behu výuky, jak získávat od studentů zpetnou odezvu, jak efektivne vést semináre, atd. [40] 5.2.2 E-LEN Cílem projektů E-LEN, jenž probíhal v letech 2003 - 2005 bylo vytvorit sít' e-learningových center a organizací, které se zameřrřují na technologie v e-learningu používané. Kromeř samotné struktury teřchto center a používané infrastruktury bylo dalším cílem projektu sesbírat z praxe návrhové vzory pro e-learning a tyto nalezené príklady rozšírit kvůli zkvalit-není výuky. Do projektů byla zapojena rada evropských univerzit, napríklad University of Cyprus, National Technical University of Athens, atd. [22] Sesbírané návrhové vzory jsou prístupné verejnosti skrze vzniklý repositár vzorů. Výstupem je nekolik desítek vzorů, jenž jsou rozdeleny do ctyr kategorií podle oblastí, kterých se týkají - správa zdrojů a LMS systémy, celoživotní vzdelávání, vzdelávání založené na spolupráci a adaptivní vzdelávání [22]. Vzory jsou v repositári popsány textove. Jedním z nalezených vzorů je správa online dotazníků [22], ve kterém se za rešený problém bere to, jak by mel být online dotazník vytváren, dorucován studentům a hodnocen. Analýza problému popisuje důležitost dotazníků při overování znalostí studentů a to, že hodnocení může být automatizováno. Rešení navržené autory vzoru obsahuje informace o tom, že dotazníky by meřly umožnřovat jak otevrřené, tak uzavrřené typy otázek s prředde-linovanými odpoved'mi, zaškrtávací testy. Autorům by mely dotazníky dovolit definovat cas na zodpovezení, způsob hodnocení, atd. Z tohoto si lze povšimnout, že autori vzorů se veřnovali i doporucřením pro implementaci. 5.2.3 Person Centered e-Learning (PCeL) Co se týce výstupů, tak nejzajímavejším projektem je PCeL a disertacní práce M. Derntla [18] z Vídeňské univerzity na téma vzorů pro PCeL. Přístup zamerený na cloveka pochází z práce psychologa C. R. Rogerse. Ten se zabýval psychoterapií, zejména pak vztahem mezi terapeutem a klientem a svou práci založil na 38 5.2. SOUVISEJÍCÍ PROJEKTY trech principech [43] [18]: • rovnost, reálnost, uprímnost pri jednání s klientem, žádné používání pretvárky, • akceptace, respekt, pozitivní prístup ke klientovi, • empatie, být schopen cítit to, co cítí klient. S teřmito principy se nemusíme omezovat jen na psychoterapii, lze je také aplikovat v oblasti vzdeřlávání. Rovnost prři jednání se studenty se bere jako samozrřejmost, reálnosti ve výuce se dá dosáhnout řešením skutecných problému, akceptace studentu je možné dosáhnout jejich zapojením do rozhodování, nastavením jejich osobních cíluj a dáním urcřité svobody pri práci s cílem budování jejich sebeduvery [18]. Své korřeny má v práci C. R. Rogerse projekt PCeL profesorky R. Motschnig, který se snaží zkombinovat prřínosy prřístupu zameřrřeného na cřloveřka ve výuce s možnostmi a prříle-žitostmi, které nabízí e-learningové technologie. Hlavní hypotézou PCeL je, že pokud prře-nos informací prřesuneme na pocřítacř (navzájem propojené webové stránky s odkazy), tím více casu získáme na prohlubování znalostí formou výuky tvárí v tvár [36]. A práve pri výuce tvárří v tvárř se uplatní schopnost vyucřujícího použít principy teorie C. R. Rogerse. V tomto typu výuky jsou studentum poskytnuty materiály a zdroje a studentům je dána velká volnost, která jim má dát možnost seberealizace a podnítit jejich zveřdavost. Z tohoto popisu je možné odvodit, že takto vyucřované kurzy nebudou tak prřipravené jako kurzy konvencní a budou vyžadovat v prubehu od vyucujícího i urcitou dávku improvizace a na jeho pocátku zvýšené úsilí pri vytvárení zdroju a obsahu [36]. E-learningové nástroje mají práveř ulehcřit vyucřujícímu prři vytvárření zdrojuj a obsahu. Ucitel tak složití? nemusí vytváret materiály vlastní, ale díky elektronické podobe muže stu-dentuj m poskytnout jen odkazy na jím doporucřené materiály. Studenti tím získávají možnost tyto materiály studovat sobe vhodným zpusobem a v case a míste, které jim vyhovují. E-learning samozrřejmeř ve výuce nenachází uplatneřní jen pro vytvárření a studování ma-teriáluj , lze jej využit i pro diskuse, komunikaci se studenty, získávání zpeřtné odezvy od studentu, sebehodnocení studentu a testování znalostí [36]. Disertacní práce M. Derntla hledá a popisuje výukové vzory pro PCeL [18]. Vytvorená šablona pro popis nalezených vzoruj byla popsána v sekci 5.1.2. Jako soucřást práce vznikl i webový repositárř5 výukových vzoruj . V neřm jsou vzory deřleny do balíkuj podle cřásti výuky, kterou zachycují. Struktura vzoruj uvnitrř balíkuj je prřehledneř zakreslena pomocí diagramu trříd. Repositárř deřlí vzory do 6 balíkuj: • Kůrzy - seminárře, kurzy s projektem. • Hodnocení - sebehodnocení, hodnocení kolegu, zkoušky. • Zpetná odezva - použití dotazníku, použití diskusních fór. • Interaktivní vzory - brainstorming, team building. 5. 39 5.2. SOUVISEJÍCÍ PROJEKTY • Projektově řízená výuka - využití iterací a inkrementů ve výuce. • Obecné - obecne znovupoužitelné vzory - prezentace, meetingy. Z duvodu lepší srozumitelnosti jsou vzory prezentovány v repositári i v grafické podobe. Ta za svuj základ bere diagram aktivit. Aktivity jsou barevne rozlišeny a oznacovány podle toho, zda se odehrávají tváří v tvár (P), online (W), nebo smíšene (B). U aktivit se mohou objevit i symboly odkazující na další diagram (vzor) [37]. Jako ukázka diagramu poslouží jeden z nalezených vzoru - Smíšené hodnocení [5]. To probíhá zpocátku paralelne, kdy zhodnocení studenta provede vyucřující, ostatní studenti a student sám osobneř. Všechny cinnosti probíhají online a výstupem jsou hodnocení, která vyucující musí projít. Nakonec vyucující muže volitelní? zorganizovat meeting. I__. (Instructor \ / Self-Evaluation n ] ( Peer-Evaluation n] Evaluation jf>) \_ l-"a"i j?) \ jř) l rr i Obrázek 5.1: Vzor Smíšené hodnocení [5] Grafická podoba vzoru je interaktivní a pokud nejaká aktivita odkazuje na podproces, je možné jej prostým kliknutím na aktivitu v diagramu zobrazit. Vzniklý repositár muže velice dobře posloužit pri vytvárení nových kurzu a nekteré jednodušší vzory lze uplatnit v jakékoliv výuce. 40 Kapitola 6 Výukové vzory pro MEDUSY V této cásti práce nejprve vytvoríme šablonů pro popis výůkových vzorů a dále se bůdeme venovat hledání casto opakovaných vzorů ve výůce pro projekt MEDUSY. 6.1 Popis vzoru Nebůde prřekvapením, že navržená šablona vychází z šablon drříve v textů zmíneřných, ne-bot' ty svémů úcřelů sloůží velice dobrře. Pro další práce lze tyto šablony vzít a poůžít je jako vzor k vytvorření vlastní. Pak ůž jen záleží na tom, za jakým úcřelem šablonů vytvárříme a jaké popisůjící elementy potrřebůjeme. Pro potrřeby projektů MEDUSY navržená šablona obsahůje následůjící elementy: • Název - smyslůplný název strůcne sdelůjící podstatů vzorů. • Účel vzoru - krátký text o scénári, na který se vzor zamerůje. • Úcastníci - seznam ůživatelských rolí vyskytůjících se ve vzorů. • Scénář - tato cást popisůje ve výůce se opakůjící vzor a jeho průbeh. • Procesní model - tento element popisůje scénárř jako Bůsiness Process Diagram v notaci BPMN 2.0. • Parametry - seznam parametrů, které pro své spůštení vzor požadůje, napr. pocet možností, které má stůdent na odevzdání úkolů, pokůd jej chybneř vypracůje. Ac se může šablona na první pohled zdát príliš strůmá, není tomů tak. Obsahůje ne-zbytneř nůtné elementy pro pochopení toho, o co ve vzorů jde a prřitom nezateřžůje cřtenárře zbytecnými informacemi. Takovýmto způsobem poskytované informace o vzorů by mely tomů, kdo si bůde v modelovacím nástroji kůrz vytvárřet, stacřit k rozhodnůtí, zda je pro neřj daný vzor vhodný. 6.2 Vzory Pri hledání vzorů jsme vycházeli z prostredí, ve kterém se v oblasti vzdelávání pohybůjeme nejvíce, tedy z výůky na vysoké škole. Ta probíhá v semestrech, behem nichž se můžeme 41 6.2. VZORY setkat s prednáškami, seminári a cviceními. Taktéž se v prubehu výuky rrmžeme setkat s domácími úkoly, projekty, testy a zkouškami. V neřkterých kurzech vyucřující používají i formy e-learningu - online materiály, odpoveřdníky (prředprřipravené formulárře) a diskusní fóra. A práve cinnosti v podobe úkolu, projektil, testu, zkoušek a využití e-learningu jsou pri hledání výukových vzoru nejzajímavejší, protože se ve výuce opakují. 6.2.1 Domácí úkol s prepracovaním Jednou z variant použití domácího úkolu ve výuce je jejstudentum zadat, nechat je úkol vypracovat a vrátit jim jej k prřepracování. • Název: Domácí úkol s prepracováním • Úcel vzoru: Vypracování domácího úkolu s možností přepracování chybného úkolu. • Úcastníci: Vyucující, Student • Scénár: Proces zacíná u vyucujícího, který vytvorí zadání úkolu. Studenti úlohu vypracují a odevzdají. Po odevzdání musí vyucřující úkoly zkontrolovat a sepsat hodnocení. Student si zobrazí hodnocení a pokud má student úkol ohodnocen jako správneř vypracovaný, proces pro neřj koncří. Pokud ne a studentovi ješteř zbývá pokus na opravu, je mu dán úkol k prřepracování, jinak proces koncří. Po prřepracování úkolu jej musí student odevzdat, ucřitel opravit a ohodnotit. Tím vzniká v procesu cyklus. Procesní model: Obrázek 6.1: Domácí úkol s prepracováním • Parametry: Jediným vstupním parametrem procesu je cříselné vyjádrření pocřtu pokusu, které má student na vypracování úkolu, atribut maxAttempts. 42 6.2. VZORY 6.2.2 Domácí úkol s termínem odevzdání • Název: Domácí úkol s termínem odevzdání • Úcel vzoru: Vypracování domácího úkolů s nastavením casů k odevzdání úkolů. • Úcastníci: Vyůcůjící, Stůdent • Scénár: Proces zacíná ů vyůcůjícího, který vytvorí zadání úkolů. Následne stůdenti úlohů vypracůjí a odevzdají. Po odevzdání můsí vyůcřůjící úkoly zkontrolovat a ohodnotit. Na odevzdání úkolů má stůdent ůrcřitoů dobů, která zacříná zadáním úkolů. Procesní model: Obrázek 6.2: Domácí úkol s termínem odevzdání • Parametry: Jediným vstůpním parametrem procesů je doba k odevzdání úkolů -atribůt duration. Tento údajse vyjadrůje jako doba trvání podle standardů ISO 8061 [28]. Napríklad údaj„P4D" oznacůje dobů trvání v podobe 4 dní. 6.2.3 Individuální projekt s výběrem tématu Další možností, jak overovat praktické schopnosti studentů, jsou projekty, at' už individuální, nebo týmové. Tento vzor práve? jednu variantu individuálního projektu popisuje. • Název: Individuální projekt s výberem tématu • Úcel vzoru: Vypracování individuálního projektu výberem tématu a obhajobou. • Účastníci: Vyucující, Student • Scénár: Proces zacíná u vyucujícího, který vytvorí zadání projektil. Každý student si jedno zadání vybere a rozpracuje. Pri další práci má student možnost konzultace postupu s vyucujícím. Po dokoncení práce na projektu jejstudenti odevzdají. 43 6.2. VZORY Po odevzdání vyucřující projekty projde a zkontroluje. Zatímco ucřitel provádí kontrolu, studenti mají cřas si prřipravit prezentaci na obhajobu. Po obhajobeř vyucřující projekt ohodnotí. Tím proces koncří. Procesní model: Obrázek 6.3: Individuální projekt s výberem tématu • Parametry: Žádné. 6.2.4 Týmový projekt s výberem tématu • Název: Týmový projekt s výbeřrem tématu • Úcel vzoru: Vypracování týmového projektu s následnou obhajobou. • Úcastníci: Vyucující, Student, Vedoucí týmu, Tým • Scénár: Proces zacíná u vyucujícího, který vytvorí zadání projektil. Každý student si jedno zadání vybere. Podle témat se studenti domluví a vytvorí týmy. Uvnitr týmů si studenti rozdeřlí role. Aby studenti mohli zacřít pracovat na projektech, je nutné je prřirřadit do projektových skupin. To postupneř provedou vyucřující a vedoucí týmu - vyucující priradí do skupin vedoucí a ti rozesílají pozvánky dalším clenum týmu. Behem tohoto prirazování si mohou studenti v týmech rozdelit úkoly. Aby studenti prřesneř veřdeřli, co mají deřlat, následuje konzultace s vyucřujícím. Po rozpracování projektu muže dojít znovu ke konzultaci. Po dokoncení projektu je vedoucí týmu odevzdají. Zatímco ucřitel provádí kontrolu, studenti v týmech mají cřas na prřípravu prezentace na obhajobu. Po obhajobeř vyucřující projekt ohodnotí. Tím proces koncří. • Procesní model: 44 6.2. VZORY Obrázek 6.4: Týmový projekt s výbeřrem tématu • Parametry: Žádné. 6.2.5 Písemná a ústní zkouška • Název: Písemná a ústní zkouška • Úcel vzoru: Ukoncení predmetu písemnou a ústní zkouškou. • Úcastníci: Vyucující, Student • Scénár: Proces zacíná u studenta, který se zapíše na termín zkoušky, dojde na ni a napíše písemný test. Následuje cřást ústní zkoušky, prři které kromeř zkoušení studenta dojde i k opraveř jeho testu. Ústní zkouška je ukoncřena udeřlením známky. Pokud student zkoušku udeřlal, proces koncří. Pokud ne a má možnost využít další termín, tak se na nej muže zapsat. V každém jiném případe proces kond • Parametry: Žádné. Procesní model: 45 6.2. VZORY Obrázek 6.5: Písemná a ústní zkouška 6.2.6 Vnitrosěměstrální těst Teoretické znalosti je kromeř záveřrecřných zkoušek možné oveřrřovat i beřhem semestru. K tomu na školách slouží vnitrosemestrální testy. • Názěv: Vnitrosemestrální test • Účěl vzoru: Overení znalostí studentu testem v prubehu semestru. • Účastníci: Vyucující, Student • Scénár: Proces zacíná u vyucujícího, který zverejní termín testu. Studenti se na termín zapíší, na test dojdou a napíší ho. Vyucřující testy opraví a ohodnotí. Procěsní moděl: Obrázek 6.6: Vnitrosemestrální test Paramětry: Žádné. 46 6.2. VZORY 6.2.7 Jednoduchý odpovědník Kromě vnitrosemestrálních testů je možné kontrolovat znalosti studentů i pomocí různých forem e-learningu. Jednou z nich jsou automaticky vyhodnocované odpovedníky. • Název: Jednoduchý odpovedník • ÚCel vzoru: Overení znalostí studentu odpovedníkem. • ÚCastníci: Vyucující, Student • Scénář: Proces zacíná u vyucujícího, který vytvorí testový odpovedník v e-learningovém systému. Dále ho zverejní studentum, kterí jejmusí vyplnit. • Procesní model: yi ■U Ich ^ Create t|Li eiLiĽnriLiire ÍA 1 ^Pu blish quesrionnaire ^-1-J . \ ^ Fill in quesíionnaire III -O Obrázek 6.7: Jednoduchý odpovedník • Parametry: Žádné. Další vzory jsou soucástí prílohy A. 47 Kapitola 7 Rozšírení modelovacího nástroje Nalezené vzory postrádají další smysl bez toho, abychom je meli kde použít. K tomu je nutné vytvorit, nebo upravit stávající nástrojpro modelování. Tech sice volne dostupných existuje velice málo, ale svými funkcemi vyhovují a co je důležité, jsou rozširitelné a upra-vitelné. Tato kapitola se venuje práve rozšiřování vybraného modelovacího nástroje o nové prvky, které umožní pri modelování výukových procesii využít predpripravené elementy. 7.1 Signavio Core Components (SCC) Stejne jako Oryx, z nehož je vyvinut, je i SCC webovým editorem pro modelování business procesů. Umožnuje procesy zachytit prostrednictvím jBPM diagramu (upravené BPMN 1.2) a tří diagramů notace BPMN 2.0 - business process diagramu, diagramu konverzace a diagramu choreografie. Pro modelování výukových procesů je nejvhodnejší business process diagram. Prři jeho použití jsou výsledné modely ukládány jako dva soubory na prředem definovaném míste v souborovém systému serveru. Jeden z techto souborů je xml soubor dle specifikace BPMN 2.0, tím druhým je taktéž xml soubor, který obsahuje interní reprezentaci vytvoreného diagramu. Co se notací týce, je nástrojkonfigurovatelný do té míry, že můžeme definovat notace nové, upravovat a rozširovat stávající. Verřejnosti je aplikace prřístupná z projektového Subversion repositárře. Odkud je možné stáhnout aktuální verzi zdrojových kódů. Nasazení aplikace je otestováno na aplikacních serverech Apache Tomcat1 a JBoss2. Sestavení aplikace se provádí pomocí nástroje Apache Ant. S aplikací se stahují xml soubory s popisem sestavení a závislostí. Pred procesem sestavení aplikace je nutné upravit dle potreby konfiguracní soubor. Ten obsahuje informace o ceste k adresári pro nasazení webové aplikace v aplikacním serveru, URL adresu serveru, na kterém bude nasazena, cestu k adresárři, do kterého se budou ukládat vytvorřené procesní modely, a název konfigurace (seznam notací a rozšírení), která se má použít. 7.2 Stencil set V kapitole 4.2.1 bylo zmíneno, že k úpravám a vytvárením notací se používají tzv. Stencil sety, soubory s popisem grafických objektů a pravidel, které definují vzájemnou souvislost 1. 2. 48 7.3. ROZŠÍRENÍ NOTACE objektu. Soucástí stencil setu jsou tri druhy souboru. Prvním je soubor formátu JavaScript Object Notation3 (JSON) , který slouží pro popis prvku, jejich vlastností a souvislostí, druhým formátem je SVG4 soubor (Scalable Vector Graphics) použitý pro definici grafiky objektu, kterými proces modelujeme. Tretím použitým formátem je grafický formát PNG5 (Portable Network Graphics) použitý pro ikony v repositári prvku. Asi nejméneř známým formátem z teřchto trří je JSON. Jako prříklad jednoduché ukázky JSON objektu dobrře poslouží popis notace pro modelování. Ten obsahuje název notace, jmenný prostor, který slouží v aplikaci jako jednoznacný identifikátor, krátký textový popis notace, pole prvku notace (stencils) a objekt s pravidly pro prvky. { "title":"BPMN 2.0", "namespace":"http://b3mn.org/stencilset/bpmn2.0#", "description":"This is the BPMN 2.0 stencil set specification.", "stencils": [/*...*/], "rules": {/*...*/} } Stencil sety mají pevneř danou adresárřovou strukturu, která musí být dodržena, nebot' nástroj je naprogramován tak, aby se jí rřídil a potrřebné soubory v ní hledal. Pro prříklad vezmeme notaci s názvem medusy. medusy |- medusy.json |- icons (obsahuje ikony do repositáre prvku) |- view (obsahuje grafiku pro modelování) Pevne dáno je umístení JSON souboru a adresáru icons a view v kořenu notace. Uvnitř icons a view pak už muže být libovolná adresárová struktura, nebot' na prvky se v JSON souboru odkazuje relativne k temto adresárum. Pokud v notaci nepotrebujeme vlastní grafické soubory, je možné adresáre vypustit. Výborným zdrojem informací o stencil setech je bakalárská práce jednoho z autoru aplikace Oryx N. Peterse na téma Oryx Stencil Set Specification [39]. 7.3 Rozšírení notace Jelikož editor obsahuje stencil set s notací BPMN 2.0 a podporuje možnost definovat nové notace jako rozšírření stávajících, lze toho pro naše potrřeby pomeřrneř dobrře využít. Ve složce urcené pro rozšírení notací jsme proto vytvorili adresár bpmn2.0medusy ur-cený pro naše rozšírení. To obsahuje jen JSON soubor. Pro grafiku jsou použity grafické prvky z BPMN 2.0. Pokud tvoríme notaci jako rozšírení, v JSON souboru zadefinujeme, kterou notaci rozširujeme a dále mužeme pracovat na bázi „generalizace a specializace". 3. 4. 5. 49 7.3. ROZŠÍRENÍ NOTACE Pri vytvárení vlastního prvku u nej stací vytvorit atribut superId, který odkazuje na nejaký prvek z rozširřované notace, a tím náš prvek zdeřdí všechny atributy a vlastnosti prvku nad-razeného i s preddefinovanými hodnotami. 7.3.1 Možnosti 7.3.1.1 Volání vzoru Pro MEDŮSY potrebujeme najít způsob, jak do editoru pridat vlastní prvky, které budou reprezentovat nalezené výukové vzory i s možností jejich parametrizace. Potrřebujeme vytvorřit modelovací prvek, prostrřednictvím kterého budou vzory volány jako podproces. V BPMN 2.0 je možné volat podproces dvema zpusoby. Prvním zpusobem je použití Call Activity, tím druhým volání skrze Service Task. Použití Call Activity, neboli Collapsed Subprocess s nastaveným atribubem Call activity, dovoluje volat podproces pomocí jeho identifikátoru. K implementaci Service Task se v Acti-viti používají trřídy v jazyce Java, ve kterých je také možné volat podprocesy prostrřednictvím jejich identifikátoru. 7.3.1.2 Parametrizace Tím byly strucne shrnuty možnosti volání podprocesu. Kvuli parametrizaci je treba ješte predstavit možnosti definování promenných v procesu. Na zacátku je treba napsat, že v notaci BPMN 2.0 neexistuje prímo konstrukt pro promennou. Existují tri možnosti jak pri modelovaní nebo implementaci tento nedostatek obejít. Prři modelování lze použít Script Task a definici promenných vložit jako skript, dále je možné použít Service Task a promenné deklarovat ve volané Java tříde a tretí možností je rucne vepsat deklaraci do xml definice procesu. Poslední možnost je dalším z rozšírření, které prřináší použití Activiti. 7.3.2 Řešení a problémy Nyní zbývá možnosti pro deklaraci promenných a volání podprocesu dát dohromady a najít použitelné a co ne vhodneř ší rřešení. 7.3.2.1 Script Task + Call Activity Nejpohodlneřjším rřešení z pohledu použití modelovacího nástroje by bylo použít pro parametrizaci Script Task a pro zavolání vzoru Call Activity. Zde však narážíme na první problém editoru. Atribut CalledElement, který k zápisu identifikátoru u Call Activity slouží, není v editoru veden. A ten, kdo proces modeluje, tak nemá možnost prři vytvárření modelu uvést, jaký podproces se má volat. Jediný zpusob, jak toto uvést, je v externím editoru. Dokud nebude v modelovacím nástroji u Call Activity možné definovat prímo atribut CalledElement, nabízí se možnost využít nekterý z nepoužívaných atributu a následne upravit definici procesu pri ukládání napríklad XSLT šablonou. Jelikož by takovéto rešení 50 7.3. ROZŠÍŘENÍ NOTACE bylo pohodlné, bylo i první, které bylo vyzkoušeno v praxi. Na dvou námi namodelovaných a implementovaných procesech jsme zkoušeli volání podprocesu, který mel zpracovat proměnné z hlavního procesu. Zjistili jsme, že procesní engine Activiti 5.0 neumožnuje predávaní promenných do procesu volaného pres Call Activity. 7.3.2.2 Script Task + Service Task Tím zbylo pro volání vzoru rešení v podobe použití Service Task. Cesta ke tříde, která se má v Service Task volat se uvádí jako celé její classname. Ovšem zde narážíme na obdobný problém jako u Call Activity. V editoru není atribut, jenž by sloužil k definování trídy, neboť se jedná o Activiti rozšírení notace BPMN 2.0 a je tak nutné toto do definice procesu dopsat v externím aplikaci. I toto rešení tedy vyžaduje provedení XSLT transformace pri ukládání procesní definice. Jako u predchozí možnosti jsme zkoušeli implementovat dva procesy s voláním a parametrizací a předávání parametria pro kombinaci Script Task a Service Task funguje. 7.3.2.3 Notace Po vybrání elementu z notace BPMN 2.0 můžeme pokrocit k vytvárení prvku vlastních. Prvky volající podproces budou založeny na Service Task a parametrizace na Script Task. První, co je trřeba, je sepsat informace o notaci. { "title":"Medusy And Activiti", "namespace":"http://oryx-editor.org/stencilsets/extensions /bpmn2.0medusy#", "description":"The subset of BPMN 2.0 supported by Activiti and a set of activities for MEDUSY project.", "extends":"http://b3mn.org/stencilset/bpmn2.0#", "stencils": [/*...*/], "rules": {/*...*/} } Nejduležitejší cástí popisu je atribut extends, který nám urcuje, jakou notaci rozširujeme. Atribut rules by mel obsahovat definici vztahu mezi prvky. V našem prípade zůstane prázdný, nebot' nepoužijeme nic, co by nebylo již ve stencil setu pro BPMN 2.0. Atribut stencils obsahuje pole nových prvků. Jako ilustraci nových prvku zde uvedu definici prvku pro vzor Domácí úkol s přepracováním. { "type" : "node", "id" : "MedusySimpleHomeworkWithRepeat", "superId" : "Task", "title" : "Simple homework with possibility of work over", "groups" : ["Medusy Activities"], "description" : "A simple homework with rework - create assignment, work 51 7.3. ROZŠÍŘENÍ NOTACE out, submit, assign points, if homework is ok, then it ends, else student has to submit again. Every student have predefined count of attempts for homework work over.", "view" : "activity/node.task.svg", "icon" : "activity/task.png", "roles" : [ "all", "sequence_start", "sequence_end", "from_task_event", "to_task_event", "FromEventbasedGateway", "messageflow_start", "messageflow_end", "fromtoall" ], "properties" : [ { "id":"name", "value":"Homework with possibility of work over" }, { "id":"tasktype", "value":"Service" }, { "id":"operationref", "value":"MEDUSY:cz.muni.fi.medusy.xnovak2 5.homeworkWorkOver. HomeworkWorkOver" } ] } Takto definovaný JSON objekt obsahuje informace o tom, o jaký typ prvku se jedná, jeho identifikátor, identifikátor objektu nadřazeného, který rozširujeme, popisek do reposi-táre prvku, kategorii prvku v repositári, textový popis, odkazy na soubory s grafikou, pole rolí, v nichž se muže prvek vyskytovat a vlastnosti objektu. Ty slouží k definování hodnot atributů. Zde uvádíme, že prvek má mít urCitý název, že se jedná o Service Task a atribut operationref, který používáme pro odkazování se na spouštenou Java trídu. Poslední atribut je XSLT transformací preveden na atribut class ve jmenném prostoru activiti. Obdobne vypadá i definice objektu pro popis prvku pro parametrizaci. Hlavní rozdíl je v definici atributu. "properties": [ { "id":"name", "value":"Parametrization of simple homework with possibility of work over" 52 7.3. ROZŠÍRENÍ NOTACE { "id":"tasktype", "value":"Script" }, { "id":"script", "value":"maxAttempts = ?;" }, { "id":"scriptformat", "value":"groovy" } ] Kromeř názvu je uvedeno, že se jedná o Script Task a je zde uveden i samotný skript k provedení. Nám slouží k deklaraci promenných, zde je napríklad promenná maxAttempts. Autorovi modelu pak stacří prři jeho vytvárření nahradit otazník za cříselnou hodnotu. Pokud by promeřnná vyžadovala textovou hodnotu, byl by otazník uveden v uvozovkách. Posledním atributem je scriptformat, který nám ríká, v jakém jazyce je skript napsán. Totožným principem jsou rřešeny v aplikaci i ostatní vzory. 7.3.3 Activiti rozšírení Krome rozšírení notace o prvky MEDUSY do ní byly pridány i prvky, které jsou podporovány procesním enginem Actviti. Toto rozšírření vychází z JSON souboru distribuovaného se zdrojovými kódy Activiti BPM Suite a má za cíl ulehcřit práci osobeř implementující proces. Ta už pri vytvárení modelu pozná, jaké komponenty muže použít. 7.3.4 Pohledy K rozšírení aplikace o notaci nestaä ji jen vytvorit, je nutné ji uvést v konfiguracním souboru. Signavio Core Components obsahuje po stažení tri vytvorené konfigurace, z nichž se podle konfiguracního souboru pro sestavení vybere jedna. Pro naše úcely je plne vyhovující konfigurace pro projekt Activiti. V té je popsáno, že má sestavená aplikace obsahovat pouze BPMN 2.0 business process diagram. Pro urcření, jaká rozšírření notace se mají do aplikace pridat, zde slouží JSON soubor. V tom je treba uvést název notace, její identifikátor a cestu k JSON souboru popisujícím rozšírení. Také je zde možnost definovat perspectives (pohledy), z kterých jsou v repositárři komponent vytvárřeny záložky s danými modelovacími prvky. Pro naše rozšírení vypadá tato cást souboru následovne: "perspectives" : [ { "title" : "BPMN (Complete with Medusy)", "namespace" : "http://oryx-editor.org/stencilsets/perspectives /academicbpmn2Medusy#", 53 7.4. ROZŠÍŘENÍ FUNKCIONALITY "description" : "BPMN complete with Medusy elements. Features the whole standard and all elements from the specification.", "stencilset" : "http://b3mn.org/stencilset/bpmn2.0#", "extensions" : ["http://oryx-editor.org/stencilsets/extensions /bpmn2.0fullmedusy#"] }, { "title" : "BPMN (Medusy, Activiti)", "namespace" : "http://oryx-editor.org/stencilsets/perspectives /activitibpmn2#", "description" : "The subset of BPMN 2.0 supported by Activiti and MEDUSY.", "stencilset" : "http://b3mn.org/stencilset/bpmn2.0#", "extensions" : ["http://oryx-editor.org/stencilsets/extensions /bpmn2.0medusy#", "http://oryx-editor.org/stencilsets/extensions /bpmn2.0activiti#"] }, { "title" : "BPMN (Complete)", "namespace" : "http://oryx-editor.org/stencilsets/perspectives /academicbpmn2#", "description" : "BPMN complete. Features the whole standard and all elements from the specification.", "stencilset" : "http://b3mn.org/stencilset/bpmn2.0#", "extensions" : [] } ] Mužeme si všimnout, že zde není definován jen jeden pohled. V aplikaci je díky tomu možné volit mezi seznamem komponent pro MEDUSY a mezi seznamem obsahujícím celou notaci BPMN 2.0. 7.4 Rozšíření funkcionality 7.4.1 Vývojářsky příjemná forma xml Výstupem aplikace je namodelovaný proces uložený jako xml soubor podle specifikace. Ten krome informací nutných pro spuštení procesu obsahuje i atributy, které nejsou v soucasné dobe procesním enginem Activiti podporované nebo informace týkající se diagramu, vcetne rozmístení jednotlivých prvku. To vede k velké nepřehlednosti xml souboru, která se projevuje pri rucním doplnování dalších nezbytných údaju. Namodelovaný UserTask s nastaveným uživatelem, který má cřinnost provést, je editorem zapsán následovne: sid-4CECD4 57-AB9E-4 55 6-A4 5 6-53BAF7 607A8C sid-0AC6F5 8C-1D0 8-4E4 2-8E9D-C8532 7 7E7 0CA novak Element userTask navíc obsahuje krome nepodporovaných atributu také jednoznacný identifikátor elementu uvnitř procesu. Ten, pokud jejchceme pri odkazování v rámci procesu použít, je takovéto podobeř nezapamatovatelný. Cílem této cřásti je upravit (rozšírřit) aplikaci takovým zpusobem, aby se procesní definice ukládala v lépe zpracovatelném formátu a prři transformaci byly nahrazeny atributy, které jsou používány v našem rozšírření notace, teřmi atributy, jež lze využít prři spoušteřní procesu. Vzhledem k tomu, že se v prřípadeř aplikace SCC jedná o open source, je možné aplikaci libovolne upravovat. Asi nejsložitejší cinností pri úprave cizího softwaru je prostudovat zdrojové kódy a najít co, kde a jak upravit. SCC je na rozširování dobre pripraveno. Přímo v korenovém adresári aplikace je k tomu dedikována složka platform extensions, ve které je projekt venující se rozšírením podpory BPMN 2.0. Tím bychom meli dáno umístení pro naše rozšírření. Nyní potrebujeme nalézt zpusob, jakým máme rozšírení vytvorit. Backend SCC je vy-tvoren v jazyce Java, což nám přímo zpusob urcuje. Musíme vytvorit balík s potřebnými trřídami. Úprava definice procesu do príjemné podoby z pohledu vývojáre je soucástí aplikace Activiti Cycle (AC), ke které je k dispozici jar knihovna. Je tedy možné řešení z AC prozkoumat a prřípadneř alesponř cřást použít. Vyzkoušením tohoto rřešení lze zjistit, že AC prřevádí a ukládá proces do námi požadované formy - odstranřuje nadbytecřné atributy a odstranřuje z xml souboru informace o diagramu. Výše uvedený príklad elementu UserTask mužeme prřevést do následující formy: SequenceFlow_1 SequenceFlow novak Krome odstranení nepotrebných atributů transformace upravila identifikátor elementu userTask. Nový identifikátor se prebírá z atributu name, názvu prvku, který se modelovacím nástroji používá jako textový popisek prvku. Z uvedeného plyne, že mužeme použít rešení z AC a vytvorit balík s trídou, která použije ar knihovnu aplikace AC. Jistým omezením e nedostupnost avadoc dokumentace k této knihovneř. To prři implementaci naší trřídy vedlo kolikrát ke zkoušení trříd a metod „naslepo". 7.4.2 MEDUSY transformace Nyní, když máme nalezen zpusob, který použijeme pro transformaci do prehledné podoby, musíme nalézt cestu, která povede k úprave atributu z našeho rozšírení notace. Ů Service Task potrebujeme nahradit atribut operationRef="MEDUSY: PathToJavaClass" za activiti:class="PathToJavaClass". Krome zmeny atributu je potreba do xml souboru doplnit definici jmenného prostoru activiti. Víc v xml souboru není potrřeba meřnit a jako vhodné rřešení se nám jeví použití XSLT transformace, ve které stacří kontrolovat název atributu a prři shodeř provést úpravu. Výsledkem rozširřování funkcionality aplikace je balík s trřídou MedusyConverter. Ta k vytvorení své instance vyžaduje parametry v podobe cesty k ceste souboru s definicí XSLT transformace a textový rřeteřzec reprezentující model jako JSON object, což je forma, ve které si editor udržuje diagram v pameřti. Pomocí trřídy MedusyConverter postupneř provádíme prřevod JSON objektu na BPMN 2.0 xml a poté do vývojárřsky prříjemné podoby. Posledním krokem, který provádíme je XSLT transformace. Kvuli té byla do aplikace pridána knihovna Saxon6. Sama vytvorená trída je nám k nicemu, pokud ji nikde nepoužijeme. Ve zdrojových kódech SCC musíme nalézt tu trídu, která zajišťuje ukládání souborů. O to se u notace BPMN 2.0 stará trída BPMN20XMLFileUtil a ukládá vytvorený proces presne podle specifikace, aby byla zajišteřna prřenositelnost modelu mezi nástroji. Jelikož trřída MedusyConverter produkuje xml soubor, který je neprenositelný, může se hodit, aby ukládání tímto způsobem zůstalo zachováno. Ůpravili jsme tedy kód této trídy takovým způsobem, aby byl editorem ukládán tretí soubor. Z důvodu rozlišení souborů je do názvu souboru automaticky vkládán text „medusy". 6. 56 Kapitola 8 Použití aplikace 8.1 Použití nových prvků aplikace Tato kapitola strucřneř ukazuje použití nových prvkuj , o které byla aplikace rozšírřena, z pohledu vyucřujícího prři vytvárření modelu kurzu. Ze strany vyucřujícího se prředpokládá ale-sponř elementární znalost notace BPMN 2.0. Musíme veřdeřt, že proces zacříná pocřátecřní událostí a koncí koncovou, k cemu slouží ruzné druhy aktivit, jak se používají brány, atd. V této kapitole je nám predstaveno jen použití prvku souvisejících s vytvoreným vzorem Domácí úkol s přepracováním. Po spuštení editoru mužeme pres menu vytvorit libovolnou adresárovou strukturu, nebo Business Process Diagram. Obrázek 8.1: Menu aplikace K ilustraci použití editoru vytvoříme následující proces. Obrázek 8.2: Ukázkový proces použití nových prvku K tomu potrebujeme na plochu z repositáre prvku pretáhnout pocátecní událost, koncovou událost a dva prvky z kategorie Medusy Activities - (Parametrization) Homework with possibility of work over a Homework with possibility of work over, a následne vše pospojujeme podle vzoru použitím Sequence Flow. Všechny námi vytvorené prvky mají v repositári i svůj popis. Ten se zobrazí po najetí kurzorem myši na prříslušný prvek. 57 8.2. IMPLEMENTACE VZORŮ J Medu&y Activities D Written and oral examination Mid-term test [ Mid-term test - teacher publish date, student enroll for test, write it and pis finally teacher revise tests and assign points. Obrázek 8.3: Repositář prvků s popisem prvku Z duvodu použití Service task pro spouštení vzoru není možné prímo z diagramu prohlížet použitý vzor. Ten si mužeme prohlédnout proklikání adresárové struktury z úvodní obrazovky editoru. Vzory se nachází ve složce Patterns. Prvek parametrizace je urcený k tomu, abychom mohli nastavit hodnoty promenných, které podproces úkolu vyžaduje. V modelu oznacíme prvek parametrizace a nastavení promenných provedeme v nabídce Attributes na pravé strane editoru. Pro nastavení hodnot musíme editovat atribut Script. Obrázek 8.4: Parametrizace U tohoto vzoru je nutné jen nastavit pocet pokusu, které má student na odevzdání úkolu. Místo otazníku musíme doplnit císelnou hodnotu. Pokud by promenná vyžadovala hodnotu textovou, byl by otazník uzavřený v uvozovkách. Nakonec stací diagram uložit pod vhodným názvem a prípadne pri ukládání vytvorený diagram popsat. Výsledkem jsou trři uložené soubory v souborovém systému. Další už je na vývojárři, který proces uložený ve vývojárřsky prříjemné formeř vezme a implementuje do stavu spustitelného v procesním enginu. 8.2 Implementace vzoru Procesní engine Activiti ve své verzi 5.0 nepodporuje všechny konstrukty specifikace BPMN 2.0 (multi instance aktivit, predávání promenných pri volání podprocesu pomocí Call activity) a pri implementaci procesia je nutné na toto brát ohled. Príklad prevodu jednoho z vzorů má výrazne popisný charakter a je uveden v pnloze B. 58 Kapitola 9 Záver 9.1 Zhodnocení výsledku Prvním cílem práce bylo vybrat nástroje a technologie pro projekt MEDUSY ůrcřené pro vizů-ální modelování výůkových procesů. Po zmapování možností byla pro modelování vybrána technologie z oblasti BPM, a to BPMN 2.0. Jedná se o grafickoů notaci s prímoů návazností spoůštení vytvoreného modelů. Výber byl založen na srozůmitelnosti grafické notace, možností následné implementace namodelovaných procesii a jejich spoůštení, monitoringů a možnosti vyůžití externích slůžeb prři beřhů procesů. Dalším cílem práce bylo nalézt cřasto opakované vzory ve výůce a popsat je takovým způi sobem, aby je bylo možné vyůžít prři modelování celých výůkových procesůi . Vznikla šablona, pomocí které bůdoů vzory popisovány. Šablona se skládá z názvů vzorů, jeho úcřelů, seznamů úcřastníkůi zapojených do vzorů, textového popisů scénárře, procesního modelů v notaci BPMN 2.0 a seznamů parametrů, které vzor vyžadůje pro své spůštení. Ac se můi že navržená šablona zdát pomeřrneř strůcřná, obsahůje ty nejdůi ležiteřjší informace a díky textovémů popisů vzorů a procesnímů modelů je dostatecřneř srozůmitelná. Výůkové vzory byly hledány ve výůce na vysoké škole. Vznikly vzory zachycůjící domácí úkoly, projekty individůální i týmové, růi zné typy záveřrecřných zkoůšek a e-learningové testy. Posledním cílem práce bylo navrhnoůt a implementovat, nebo rozšírřit již existůjící nástroj pro modelování procesůi o nové prvky reprezentůjící nalezené výůkové vzory, aby je bylo možné vyůžít prři modelování výůky. Jelikož pro poůžívanoů notaci existůjí rozširři-telné open soůrce nástroje, bylo možné toho vyůžít. V práci je rozširřován editor Signavio Core Components. V soůcřasné dobeř je ůpravená aplikace ve stavů fůnkcřního prototypů a je nasazena pro testovací provoz. Je prístůpná na http://kore.fi.můni.cz:10115/signaviocore/. Výstůpy aplikace jsoů ůkládány na http://www.fi.můni.cz/~xnovak25/models/. Prři implementaci vzorůi bylo nůtné prřistoůpit k ůrcřitým ústůpkůi m a docřasným rřešením (viz sekci 7.3), nebot' v prípade BPMN 2.0 se jedná o pomerne novoů technologii a neexis-tůje nástroj, který by plne podporoval její specifikaci. Asi nejdůležitejším nepodporovaným konstrůktem je můlti instance aktivity. Ta nalézá ůplatneřní naprříklad prři odevzdávání úkolůi stůdenty, kdy pro každého stůdenta potrřebůjeme spůstit práveř jednů tůto aktivitů. Z tohoto důi vodů vznikl jako soůcřást práce i návod, jak namodelované vzory prřevádeřt do spůstitelné formy. Nástroje vybrané pro projekt MEDUSY se však neůstále vyvíjí a je tedy do bůdoůcna pravdeřpodobné, že bůde možné tato docřasná rřešení odstranit. 59 9.2. BUDOUCÍ PRÁCE Nad rámec zadání je v aplikaci implementováno ukládání namodelovaných procesu ve vývojárřsky prříjemné formeř, protože aplikací ukládaný proces obsahoval velké množství nadbytecřných informací, které cřinily proces pro rucřní zpracování neprřehledným. Výsledek této práce má sloužit jako modelovací nástrojvýukových procesu v projektu MEDUSY. Jedná se o cřást zamýšleného procesneř orientovaného e-learningové systému. Ná-strojmá primárne sloužit vyucujícím a procesním vývojárum. Vyucující si v nem namodelují výuku kurzu nebo její cřást, kterou chteřjí prřenést do formy e-learningu, a následneř vývojárři proces implementují. Cást implementace muže probíhat taktéž v modelovacím nástroji, jelikož ten umožnřuje nastavení velkého množství vlastností procesu. 9.2 Budoucí práce Další vývojaplikace je znacne ovlivnen pokrokem v implementaci sady nástroju Activiti BPM Suite a editoru Signavio Core Components. Avšak už prředem je možné rříci, jaké další úpravy bude nutné provést. i Volání vzoru V soucasné dobe je volání vytvořených vzoru rešeno pres Service Task. Jedná se o rřešení vynucené a docřasné. V momenteř, kdy engine Activiti zacřne podporovat predávání promenných do podprocesu skrze Call Activity, bude vhodné na tento zpusob prevést vytvorené prvky pro volání vzoru. ii Multi instance aktivit Stejne jako u predchozí položky je i úprava multi instancí závislá na enginu Activiti. Soucasný zpusob pro implementaci je predstaven v príloze B. Nyní je nutné vzor „kouskovat" a implementovat dodatecné Java trídy. Po pridání podpory do Activiti by meřly být vzory použitelné ve stavu, v jakém byly vytvorřeny. iii Hledání dalších vzoru Hlavním cílem této práce nebylo najít všechny možné výukové vzory, ale najít možnosti rozšírření aplikace o vlastní prvky. Další z možných navazujících prací je hledání dalších výukových vzoru a jejich pridání do aplikace. iv Časové události S predchozími položkami souvisí pridání casových událostí do vzoru nalezených v této práci. V Activiti 5.0 jsou casové události pro aktivity podporovány, ale problém nastává u „našeho" docasného rešení multi instancí - casové události v nich nelze kvuli problémum se soubežností aktivit použít. v Aktuálnost aplikace Signavio Core Components se jako aplikace neustále vyvíjí. Jsou v ní opravovány chyby, je implementována nová funkcionalita. S tím jde ruku v ruce údržba aplikace pro projekt MEDUSY. Je tedy nutné hlídat a upravovat nové verze aplikace. 60 Literatura [1] Activiti Components, Activiti, (21.10.2010). 4.2.2,4.1 [2] Alexander, C. a Ishikawa, S. a Silverstein, M.: A Pattern Language: Towns, Buildings, Construction, Oxford University Press, 0195019199, 1977. 5.1.1 [3] Rácek, J.: Strukturovaná analýza systémů, Masarykova univerzita, 2006, 80-210-41900. 2.4.4, 2.4.4 [4] Arlow, J. a Neustadt, I.: UML 2 a unifikovaný proces vývoje aplikací: objektove orientovaná analýza a návrh prakticky, Computer Press, 9788025115039, 2007. 2.4.6 [5] Derntl, M.: Blended Evaluation, The Person-Centered e-Learning Pattern Repository, c2010, (11.12.2010). 5.2.3,5.1 [6] BPM slovnícček - BPM, BPM portál, (12.9.2010). 2.2 [7] Kolár, J.: Process design & BPMS, Ucební materiály k predmetu PV207 Business Process Management na Fakulteř informatiky Masarykovy univerzity, 2010. 2.2 [8] BPM slovnícček - BPM jako manažerská disciplína, BPM portál, (12.9.2010). 2.2 [9] Business Process Model and Notation (BPMN), Object Management Group, Inc., c1997-2010, (12.9.2010). 2.4.8 [10] Guntert, M.: Choreographies, BPMN Community, 17.9.2009, (21.9.2010). 2.4.8, 2.4.8 [11] Vašícek, P.: BPM prakticky - 4. část: Modelování procesu, BPM portál, 2008, (21.9.2010). 2.9 [12] Vašícek, P.: BPM prakticky - S. část: Úvod do BPMN, BPM portál, 2008, (21.9.2010). 2.4.7, 2.8 [13] Business Process Model and Notation (BPMN), version 1.2, Object Management Group, 3.1.2009, (21.9.2010). 2.4.7, 2.4.7.1, 2.4.7.2, 2.4.7.3,2.4.7.4 [14] BPM slovnícček - BPMS, BPM portál, (12.9.2010). 2.2 61 [15] Magic Draw - New and Noteworthy, No Magic, Inc., c2000-2010, (21.9.2010). 2.10 [16] CompendiumLD learning design software , The Open University, (20.10.2010). 3.2.6, 3.4 [17] Laforcade, P.: Cooperative Problem-Based Learning Metamodel, Site Web de Pierre Laforcade, 15.4.2006, (20.10.2010). 3.2.1 [18] Derntl, M.: Patterns for Person-Centered e-Learning (Dissertation), Universität Wien, 2005, (11.12.2010). 5.1.1, 5.1.2,5.2.1, 5.2.3 [19] K. Schneider, D.: CoUML, EduTech Wiki, 20.7.2009, (20.10.2010). 3.2.2, 3.2 [20] K. Schneider, D.: CPM, EduTech Wiki, 9.7.2009, (20.10.2010). 3.2.1,3.1 [21] K. Schneider, D.: Educational modeling language, EduTech Wiki, 15.4.2010, (20.10.2010). 3.2 [22] The E-LENProject, e-LEN, (11.12.2010). 5.2.2 [23] E-LEN: E-learning design pattern tutorial, The E-LEN Project, (11.12.2010). 5.1.2 [24] Neumann, S.: Graphical Learning Modeller: Design a course in 15 minutes, Prolix, 9.6.2009, (20.10.2010). 3.2.3 [25] WFMC-TC-1011 Ver 3 Terminology and Glossary English, Workflow Management Coalition, 5.2.1999, (10.9.2010). 2.1,2.1 [26] Gamma, E. a Helm, R. a Johnson, R. a Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 0201633612,1995. 5.1.1 [27] Learning Design Specification, IMS Global Learning Consortium, Inc., c2010, (20.10.2010). 3.2.1 [28] Wikipedia contributors: ISO 8601, Wikipedia, The Free Encyclopedia. , 1.1.2011, (2.1.2011). 6.2.2 62 [29] About LAMS, LAMS Foundation, (20.10.2010). 3.2.7 [30] Dalziel, J. a Dalziel, B.: LAMS Teacher's Guide, LAMS, 2006, (20.10.2010). 3.2.7 [31] Vašícek,P.: BPM prakticky-1. řást: Proc BPMs open source nástroji, BPM portál, 2008, (12.9.2010). 2.2 [32] K. Ellis, R.: A Field Guide to Learning Management Systems, American Society for Training & Development (ASTD), c2009, (20.10.2010). 3.2 [33] Macura, T.: Business Process Management System 2.0, Diplomová práce na Fakulte informatiky Masarykovy univerzity, 2009. 2.2 [34] Geneva, R.: Highlights from BPMN 2.0: Non-Interrupting Events, ProcessMode-ling.info, Geneva Productions LLC, 8.12.2009, (21.9.2010). 2.4.8 [35] Ošlejšek, R.: Objektové metody návrhu informacních systému, Ucební materiály k predmetu PA103 Objektové metody návrhu informacních systému na Fakulte informatiky Masarykovy univerzity, 18.3.2008. 2.4.6 [36] Person-Centered e-Learning, The Person-Centered e-Learning Pattern Repository, c2010, (11.12.2010). 5.2.3 [37] S enario modeling, The Person-Centered e-Learning Pattern Repository, c2010, (11.12.2010). 5.2.3 [38] Pekárková, L.: Techniky modelování a optimalizace podnikových procesů, Diplomová práce na Fakulteř informatiky Masarykovy univerzity, 2007. 2.1, 2.1, 2.4.3, 2.4.5, 2.6, 2.4.6 [39] Peters, N.: Oryx Stencil Set Specification, Hasso-Plattner-Institut, 30.6.2007, (21.10.2010). 4.2.1, 7.2 [40] The Pedagogical Patterns Project, The Pedagogical Patterns Project, (11.12.2010). 5.2.1 63 [41] Ráček, J- Procesní řízení, Učební materiály k předmětu PV165 Procesní řízení na Fakultě informatiky Masarykovy univerzity, 22.2.2010. 2.1, 2.1,2.3, 2.4.3, 2.4, 2.4.6 [42] Learning Design Editor, Reload, 12.6.2006, (20.10.2010). 3.2.5 [43] Smith, M.: Carl Rogers and informal education, the encyclopaedia of informal education, 3.9.2009, (11.12.2010). 5.2.3 [44] SCORM Explained, Rustici Software, (20.10.2010). 3.2.5 64 Príloha A Další výukové vzory A.1 Domácí úkol • Název: Domácí úkol • Úcel vzoru: Vypracovaní domácího úkolu. • Úcastníci: Vyucující, Student • Scénár: Proces zacíná u vyucujícího, který vytvorí zadání úkolu. Studenti úkol vypracují a odevzdají. Vyucřující úkoly opraví a zadá hodnocení. Procesní model: Obrázek A.1: Domácí úkol • Parametry: Žádné. A.2 Zpětná odezva pres diskusní fórum • Název: Zpeřtná odezva prřes diskusní fórum • Úcel vzoru: Získání zpetné odezvy od studentů na daná témata skrz diskusní fórum. • Úcastníci: Vyucující, Student • Scénár: Vyucující nejprve vytvorí témata v diskusní fóru. Studenti na daná témata diskutují a vyucřující nakonec odezvu ohodnotí. 65 A.3. PÍSEMNÁ ZKOUŠKA Procěsní moděl: Obrázek A.2: Zpeřtná odezva prřes diskusní fórum Paramětry: Žádné. A.3 Písěmná zkouška • Názěv: Písemná zkouška • Účěl vzoru: Ukoncení predmetu písemnou zkouškou. • Účastníci: Vyucující, Student • Scénár: Proces zacíná zápisem studenta na termín zkoušky a pokracuje dostavením se na ni. Vyucující zkoušky opraví, zadá známky a napíše studentum e-mail ohledne vyhodnocení zkoušky. Pokud student prospeřl, proces koncří. Pokud má k dispozici možnost opravy, muže se zapsat na další termín, jinak proces koná. Procěsní moděl: Obrázek A.3: Písemná zkouška Paramětry: Žádné. 66 A.4. ÚSTNÍ ZKOUŠKA A.4 Ústní zkouška • Název: Ústní zkoůška • Úcel vzoru: Ukoncení predmetů ústní zkoůškoů. • Úcastníci: Vyůcůjící, Stůdent • Scénár: Proces zacíná zápisem stůdenta na termín zkoůšky a pokracůje dostavením se na ni. Vyůcřůjící stůdenta vyzkoůší a zadá známků. Pokůd stůdent prospeřl, proces koncří. Pokůd má k dispozici možnost opravy, můi že se zapsat na další termín, jinak proces koncří. • Parametry: Žádné. Procesní model: Obrázek A.4: Ústní zkoůška A.5 Zpetná odezva pres formuláre • Název: Zpeřtná odezva prřes formůlárře • Úcel vzoru: Získání zpetné odezvy od stůdentů k danémů tématů vyplnením for-můlárře. • Úcastníci: Vyůcůjící, Stůdent • Scénár: Vyůcůjící vytvorí formůlár, stůdenti jejvyplní a vyůcůjící vyhodnotí. • Parametry: Žádné. Procesní model: 67 A.6. ZÁPIS DO PŘEDMĚTU SE SCHVÁLENÍM -J.I Yl ■TS 1 A ŕíSi / \ ^ Create reaction Review fcfl i_ Kj sheet reactions ^\^s k. J \. j J fc ^ Submit__ reactions L m J Obrázek A.5: Zpětná odezva přes formuláře A.6 Zápis do předmětu se schválením • Název: Zápis do předmětu se schválením • ÚCel vzoru: Podání žádosti o zápis do předmetu, kde je pro zápis vyžadováno schválení vyučujícím. • ÚCastníci: Vyučující, Student • Scénář: Student podá žádost o zápis do předmetu. Pokud vyucující žádost zamítne, nebo potvrdí, proces koncí. Další možností je, že si vyucující vyžádá další informace od studenta, který je odešle a proces rozhodování se opakuje. • Procesní model: IS MU NI Obrázek A.6: Zápis do predmetu se schválením • Parametry: Žádné. 68 Příloha B Návod na implementaci vzoru Pro jednoduchou ilustraci vezmeme vzor Jednoduchý odpovedník(viz 6.2.7). Z nej můžeme v prvním kroku vypustit bazén a dráhy, nebot' ty nám neposkytují žádné vlastnosti a atributy pro spušteřní. Obrázek B.1: Jednoduchý odpovědník bez bazénu Dalším krokem úprav je prirazení (upravení) vlastníku jednotlivých aktivit. To se provádí pres panel Attributes atributem Resources, ve kterém vytvoríme novou hodnotu bud' typu PotentialOwner, nebo HumanPerformer. U prvního se jako hodnota ResourceAssig-nmentExpression uvede název skupiny uživatelů, ze který se muže stát vlastník aktivity. U druhého typu jako hodnotu uvádíme identifikátor konkrétního uživatele. U prvních dvou aktivit provedeme tedy prirazení konkrétního uCitele kurzu, který vytváríme, nebo skupinu všech uCitelu kurzu a jeden z nich pri behu procesu pribere za svou. S tretí aktivitou narážíme na nepodporovanou vlastnost aktivit - multi instance. Jedná se pridelení jedné aktivity více osobám, které ji všechny musí vykonat. V oblasti výukových procesia se jedná o velice duležitou vlastnost. Využití najde témer ve všech procesech. Zde chceme, aby všichni studenti kurzu zodpovedeli odpovedník. V rámci práce D. Tovarnáka vniklo docasné rešení problému. Diagram je nutné upravit do následující podoby: Obrázek B.2: Jednoduchý odpovedník s Call activity PV999_teachers PV999_teachers V této procesní definici je za obe uživatelské aktivity zodpovedný jeden z uživatelu, jenž jsou cleny skupiny ucitelu predmetu PV999, který se o aktivitu prihlásí. K tomu je nutné vytvorit podproces, který bude z Call activity volán. Podproces obsahuje jen Service Task, z kterého je spouštena Java trída, která obstará spustení multi instance. Volaná trída StartQuestionnaire z databáze vezme seznam uživatelu (zde studenty pred- public class StartQuestionnaire extends AbstractBpmnActivity implements ActivityBehavior { public void execute(ActivityExecution execution) throws Exception { ProcessEngine engine = ProcessEngines.getDefaultProcessEngine(); if (execution.getVariable("threshold") == null) { List students = engine.getIdentityService() .createUserQuery().memberOfGroup("PV999_students").listO; execution.setVariable("threshold", students.size()); execution.setVariable("signals", 0); for (User student : students) { Map map = new HashMap(); map.put("student_id", student.getId()); map.put("parent_execution", execution.getId()); engine.getRuntimeService() .startProcessInstanceByKey("multi_quest", map); } targetRef="Service_task_for_questionnaire_subprocess"/> metu PV999), kterým se má z nich podproces, který vypl odpoveřdníku prřirřadit a spustí pro každého obsahuje. 71 B. návod na implementaci vzorů (Integer) execution.getVariable("signals"); else { /* JOIN */ Integer signals signals++; execution.setVariable("signals", signals); if (signals.equals((Integer) execution .getVariableC'threshold"))) { leave(execution); } Trída také obsahůje kód (vetev else v podmínce) pro soůbeh vytvořených podprocesů. Proces pokracůje dále až po ůkoncení všech vytvorených podprocesů. Z třídy volaný pod-proces vypadá následůjícím způi sobem: Obrázek B.4: Proces pro můlti instanci A má tůto procesní definici: Please fill in questionnaire. ${student_id} První Činnost je námi chtené vyplnení odpovedníku, druhá Činnost je servisní a má za úkol v procesním enginu oznámit ukončení podprocesu. public class Signal implements JavaDelegate { public void execute(DelegateExecution execution) throws Exception { ProcessEngine engine = ProcessEngines.getDefaultProcessEngine(); ExecutionImpl ei = (ExecutionImpl) engine.getRuntimeService() .createExecutionQuery().executionId(execution .getVariable("parent_execution").toString()).singleResult(); ClassDelegate classDelegate = (ClassDelegate) ei.getActivity() .getActivityBehavior(); classDelegate.execute(ei); } } Celý príklad je vytvoren pro Activiti ve verzi 5.0 a je soucástí CD prílohy práce. 73 Příloha C Obsah přiloženého CD Součástí práce je také CD obsahující adresáře: • Activiti 5.0 - Activiti BPM Suite ve verzi 5.0. • Medusy Patterns - vytvořené procesní modely jako xml soubory a aplikace pro Eclipse IDE s implementací vzoru. • SCC (revision 47) - zdrojové soubory aplikace Signavio Core Components, která je v práci rozšiřována. • SCC extensions - v práci vzniklé zdrojové kódy a rozšírení grafické notace pro aplikaci Signavio Core Components. • SCC foř MEDUSY - zdrojové soubory aplikace Signavio Core Components již obsahující vytvorřená rozšírření. • Text - text této práce ve formátu PDF a zdrojový kód práce ve formátu XML podle DTD DocBook. 74