MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Vizualizace firemních procesů v prostředí virtuální reality
BAKALÁŘSKÁ PRÁCE
Luděk Křivánek
Brno, jaro 2007
Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Vedoucí práce: RNDr. Jaroslav Ráček, Ph.D. ii
Poděkování Rád bych zde poděkoval RNDr. Jaroslavu Ráčkovi, Ph.D. a Mgr. Janu Flasarovi, Ph.D. za cenné rady poskytnuté při tvorbě této práce.
iii
Shrnutí Virtuální realita oproti 2D vizualizaci umožňuje nové a zajímavé zobrazování a modelování firemních procesů. Výsledkem mé práce je zásuvný modul pro systém VRECKO, který nabízí základní funkce pro modelování firemních procesů a konvertor pro převod vymodelovaného firemního procesu v programu Borland Together do formy zobrazitelné ve virtuální realitě s využitím systému VRECKO a zmíněného zásuvného modulu.
iv
Klíčová slova firemní proces, procesní řízení, vizualizace firemních procesů, konvertor firemních procesů, virtuální realita, Borland Together, VRECKO, HCI laboratoř
v
Obsah 1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Firemní procesy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 Hlavní rysy procesního řízení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Proces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Čtyři úrovně náhledu na procesní řízení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4 Manažerské procesy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4.1 Strategické řízení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4.2 Taktické řízení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4.3 Operativní řízení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Modelování procesních diagramů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Procesní diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Dvoudimenzionální modelování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1 Uživatelské možnosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.2 Ukázkový příklad procesního diagramu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.3 Přístupný software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Modelování ve virtuální realitě . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1 Virtuální realita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.2 Tři úrovně VR aplikací . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.3 Prezentace prvků diagramu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.4 Prezentace nástrojů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4 Použitá technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1 Systém VRECKO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1 Multiplatformnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.2 Rozšiřitelnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.3 Konstrukce systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.4 Formát Wavefront . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 4.2 OpenSceneGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3 Hardware obsluhující virtuální realitu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4 Moderní značkovací jazyky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4.1 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4.2 Schémata XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4.3 XPath a XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5 Zásuvný modul AP_BusinessProcess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1 Stanovené cíle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2 Zásuvné moduly systému VRECKO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.1 Objekt Ability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3 Konfigurace systému VRECKO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3.1 Avatar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3.2 Připojená zařízení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.3 Definice událostí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.4 Implementace zásuvného modulu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4.1 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4.2 Nástroje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.4.3 Elementy diagramu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.4.4 Datové toky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.4.5 Manipulace s elementy diagramu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4.6 Odstraňování elementů diagramu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4.7 Obarvování elementů diagramu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 vi
5.4.8 Nová scéna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.9 Uložení a načtení scény . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Ukázkové screenshoty vymodelovaných diagramů . . . . . . . . . . . . . . . . . . . . . . . . . 6 Konvertor T2V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Objektová analýza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Teorie transformace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Postup konvertoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Použití konvertoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Použitý software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B Obsah přiloženého CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27 27 29 30 30 31 31 32 34 35 36 37
vii
Kapitola 1
Úvod Přístup procesního řízení zpřehledňuje vedení rozsáhlejších systémů, můžeme tedy říci, že modelování firemních procesů slouží k zabezpečení realizace strategických cílů. Firemní proces provazuje aktivity na nižších úrovních řízení se strategickými cíli a měřítky stanovenými vrcholovým vedením. Umožňuje průběžné sledování naplňování cílů a odhaluje případné odchylování skutečnosti od plánu. Model firemního procesu může posloužit i jako podklad pro tvorbu příslušného softwaru. Více se o teorii firemních procesů dočtete ve druhé kapitole. Modelování firemního procesu pomocí grafického modelu spěje k uspořádanějším myšlenkám a představám. Analytici dospívají ke kvalitnějším a robustnějším řešením. Práci zjednodušuje příslušný modelovací software, který uživatele překvapí důmyslnými nástroji a jednoduchostí vymodelovat procesní diagram dle představ. Zaběhlé postupy modelování a přínosy modelování ve virtuální realitě naleznete ve třetí kapitole. Dostupnost virtuální reality zatím není jednoduchá. Je vyžadován poměrně drahý hardware, a na trhu se ve větším množství neobjevuje software uspokojující praktické potřeby uživatelů. Fakultní laboratoř HCI je vybavena dostatečnou technologií pro vizualizaci i interakci uživatele s virtuálním světem. Použitou technologii představuje čtvrtá kapitola, kde je sepsáno vše podstatné a potřebné pro realizaci této práce. Cílem mé práce je nabídnout uživateli modelování procesních diagramů ve virtuálním prostředí. Zásuvný modul „AP_BusinessProcess“ pro systém VRECKO nabízí základní funkce modelování diagramů: pokládání prvků diagramu do scény – manipulaci s nimi, jejich odstraňování a obarvování, a dále ukládání a načítání hotového či rozpracovaného diagramu. O implementaci výsledného zásuvného modulu se dočtete v páté kapitole. Druhým cílem mé práce je konvertor, který umožní zobrazovat a upravovat ve virtuálním prostředí vymodelované procesní 2D diagramy. Konvertor „T2V“ vhodně transformuje diagramy z programu Borland Together do formátu, který je zobrazitelný systémem VRECKO. Jak jsem docílil správné funkčnosti konvertoru objasní šestá kapitola. V závěrečné kapitole hodnotím mnou odvedenou práci a uvádím další možné směry výzkumu a vývoje.
1
Kapitola 2
Firemní procesy Prozatím se v organizování vnitřních činností podniků používá především funkční řízení vyjadřované pomocí organizačního schématu. Tento způsob řízení je zastaralý, těžce udržovatelný a vzniká při něm mnoho komunikačních a kompetenčních bariér v důsledku ohraničených organizačních jednotek. Moderní pojetí procesního způsobu řízení umožňuje lepší správu, zprůhlednění a pružnost běhu firmy. Vycházíme ze skutečnosti, že každý produkt (výrobek nebo služba) vzniká určitým sledem činností (procesem). Práce „protéká“ funkčními jednotkami, které můžeme jednotlivě dle potřeby upravovat a aktualizovat. A právě tento přístup zrychluje produktivitu firem, zvyšuje jejich spolehlivost a přidává na kvalitě výroby. Snižuje se také potřeba řídící práce, protože pracovníci jsou organizováni mezi sebou a řešení řady situací je vyznačeno předem. Velmi důležitou součástí přístupu jsou manažerské procesy, které musí zajistit realizaci zakázek a jejich soustavné zlepšování. Přechod na procesní způsob řízení vede (obvykle dynamicky) ke zvýšení informovanosti o zákaznících, omezení konfliktů mezi jednotlivými odděleními a zkrácení prodlev mezi různými kroky celého procesu. Rozborem organizace firmy lze odhalit přebytečné nebo duplicitní činnosti, které lze z procesu odstranit. Procesní řízení směřuje k vyšší produktivitě práce, snížení nákladů a schopnosti konkurovat vyspělejším podnikům. Veškeré vstupy, meziprodukty a produkty mají elektronickou podobu a pracujeme s nimi v rámci počítačové paměti. Fyzické elementy jsou představovány zjednodušenou elektronickou identifikací tak, že ztvárněná elektronická náhrada nese informace o jejich důležitých vlastnostech a pro jednoznačné odlišení mezi daty je elementům přiřazen identifikační klíč - např. číslo nebo jméno. K prokázání identifikace vykonavatele procesu se používá časové razítko a elektronický podpis. Takový postup identifikace může posloužit při případném právním či jiném sporu jako důkaz průběhu procesu. Časové razítko dokazuje existenci konkrétních digitálních dat ve specifikovaném časovém okamžiku. Nesmí být umožněno orazítkovat dokument časovým údajem odlišným od aktuálního. Každá změna dokumentu musí být zjistitelná, tedy při každé změně dokumentu se odesílá požadavek (obsahující identifikátor dokumentu, neboli hash dokumentu) vydavateli časového razítka (Time-Stamp Authority - TSA). TSA vygeneruje digitální podpis zahrnující zaslaný hash dokumentu, přesný časový údaj a vlastní identifikaci. Dva typy časových razítek: absolutní (úspěšná za předpokladu přesného času) a relativní (založená na jednosměrné hashovací funkci, která bezpečně prokáže sled činností). Pro uložení definice procesu se používá relační databáze, XML formát nebo vlastní jazyky.
2.1 Hlavní rysy procesního řízení - zvýšení rychlosti řízení a zkrácení doby odezvy na požadavky zákazníka - snížení potřeby řídící operativní práce - zvýšení výkonnosti podniku 2
- možnost analýzy procesů a jejich zlepšování - stanovení jednoznačné pravomoci a odpovědnosti
2.2 Proces Základní vlastnosti - skládá se z uspořádaných činností (kroků či aktivit), které společně realizují firemní plán - jeho organizační struktura určuje účelná pravidla a vzájemné vztahy - je opakovatelný - má jednoznačně definovaný počátek a konec - transformuje vstupy na výstupy - využívá zdroje
2.3 Čtyři úrovně náhledu na procesní řízení 1) úroveň organizace (podniku) - celá organizace je vnímána jako jeden proces - měření je prováděno na vstupu a výstupu organizace (výroba, náklady, výplaty apod.) 2) úroveň procesů - organizace je rozčleněna na uspořádané procesy: - hlavní (marketing, obchod, výroba, poskytování služeb, servis) - podpůrné neboli vedlejší (finance, lidské zdroje, informatika) - měření a hodnocení je prováděno na vstupu a výstupu každého procesu 3) úroveň činností (aktivit) - každý proces je rozčleněn na uspořádané činnosti (aktivity): - výkonné (transformační), kontrolní a rozhodovací - automatizované (vykonávány počítačem) - manuální (nepodléhají automatizaci, tedy nejsou vykonávány počítačem) - měření je prováděno na vstupu a výstupu každé činnosti - modely procesů na této úrovni nazýváme "statické" 4) úroveň událostí - každá činnost začíná a končí událostí, je tedy možno měřit činnost nejen jako celek, ale i její jednotlivé výskyty v reálném čase - na této úrovni je možno realizovat řízení pracovního toku (Workflow) - modely procesů na této úrovni nazýváme "dynamické"
2.4 Manažerské procesy Procesní model organizace vytváří důležité pojítko mezi strategickou a provozní (workflow) úrovní organizace. Nicméně je chybou, pokud se organizace orientuje bezprostředně na návrh a implementaci procesů bez jednoznačného propojení s vizí, strategickými cíli a jejich měřítky. Je nutné ověřit nezbytnost a relevantnost jednotlivých procesů pro fungování organizace a dosažení vytčených strategických cílů. Procesní měřítka musí být vždy v souladu se stanovenými měřítky jednotlivých strategických cílů. Vždy musí být možné zpětně vysledovat, jakým způsobem 3
jednotlivé procesy a jejich měřítka ovlivňují úspěšné naplnění strategie.
2.4.1 Strategické řízení - hledá odpověď na otázky co a jak změnit, aby firma trvale prosperovala (určení cílů podnikání) - zjišťuje potřeby stávajících a potenciálních zákazníků, zaměstnanců, dodavatelů - rozhoduje, která potřeba bude firmou naplněna – alokace zdrojů - stanoví cíle zvolených změn včetně způsobu jejich měření, požadovaných hodnot a termínů realizace - vypracovává zásady jednání, které naplní stanovené cíle - navrhuje způsob motivace k žádanému jednání Shrnutí do formy procesů sběr dat ke strategickému plánování (data o prostředí, konkurenci, zákaznících, dodavatelích, vlastní výkonnosti) -> analýza dat -> (re)definování strategických cílů -> realizace strategických cílů
2.4.2 Taktické řízení - realizuje strategické cíle (snaha o dosáhnutí zisků) - stanoví způsob využití stávajících zdrojů - rozhoduje jakým způsobem budou potřeby zvolené při strategickém rozhodování realizovány - zpracovává projekt realizace potřebných změn včetně požadavků na zdroje - vypracovává pravidla jednání v manažerských procesech - zajišťuje motivaci k žádanému jednání - hodnotí postupy a míru dosažení stanovených cílů Shrnutí do formy procesů sběr dat o postupu realizace cílů a změn, shromažďování dat o vlivu realizovaných změn na úroveň dosahovaných výsledků -> analýza dat -> definování způsobů dosažení strategických cílů -> realizace taktických cílů
2.4.3 Operativní řízení - zajišťuje požadované činnosti v určených termínech včetně realizace plánovaných změn - minimalizuje spotřeby použitých zdrojů – lidí, materiálu, zařízení, energie, atd. - vypracuje pravidla jednání v hlavních a podpůrných procesech - motivuje pracovníky k žádanému jednání a současně jej i kontroluje - hodnotí výsledky Shrnutí do formy procesů sběr dat o realizaci úkolů -> analýza dat -> definování způsobu dosažení taktických cílů (úkolů)-> realizace úkolů
4
Kapitola 3
Modelování procesních diagramů Přechod od návrhu procesního diagramu s papírem a tužkou k modernímu softwaru, který nabízí řadu modelovacích nástrojů a doplňků, byl velmi usnadňujícím krokem k budování rozsáhlých diagramů a leckdy v podstatě i nutnou podmínkou pro dokončení hodnotného návrhu. Modelování diagramů je prozatím ve větší míře rozšířeno pouze v ploše (2D), a tak třetí rozměr přivádí mnoho nových otázek a požadavků. Cesta k plnohodnotnému modelování ve virtuální realitě tedy není jednoduchá. Jak například umožnit uživateli psaní textu, když je obklopen virtuálním světem? Řešením může být vizualizace „virtuální klávesnice“. Ovšem takový způsob vyžaduje jednotlivě snímat pohyby uživatelových prstů a detekovat jejich geometrické kolize s virtuálními klávesami. Kromě potřebného hardwaru je nezbytné naprogramovat chování klávesnice do příjemného uživatelského očekávání. Tato práce ukazuje jak je možné ve virtuálním světě graficky vizualizovat procesní diagramy a obsluhující uživatelské menu. Výsledná aplikace této práce nabízí několik základních nástrojů, které odhalují modelování 3D diagramů pomocí volných rukou v prostoru. V následujících podkapitolách si ukážeme již zaběhlé tradice 2D modelování a vybrané důmyslné nástroje uspokojující uživatelovy potřeby. Posléze pak modelování v prostoru simulované ve virtuální realitě, kde neopomeneme vyzdvihnout možnosti virtuální reality. Následuje představení aplikace pro systém VRECKO, která umožňuje modelování procesních diagramů a je jedním z výsledků této práce.
3.1 Procesní diagram Procesní diagram je v podstatě zmapování organizačních vztahů, které zahrnuje potřebné činnosti (procesy), vazby mezi nimi, jejich souslednost a zodpovědné pracovníky. Každá činnost je označená pomocí identifikátoru (řetězec znaků, zpravidla písmena a číslice) a má přiřazeny další hodnoty, jako je délka trvání činnosti, náklady na provedení činnosti, pravděpodobnost uskutečnění činnosti, apod. Na 2D diagramu je sled činností znázorňován zleva doprava (nebo shora dolů). Diagram obvykle obsahuje jednu startovní a jednu koncovou událost. Pro přehlednost organizace firmy lze diagram rozdělit na tzv. swimlane (plavecké dráhy), kde každá swimlane pojme část procesů diagramu. Tento přístup vedle grafického zpřehlednění nabízí i separátní výpočty souhrnných finančních nákladů na jednotlivá oddělení podniku, případně jejich časová vytížení apod.
3.2 Dvoudimenzionální modelování Modelovací nástroje a doplňky jsou dnes již na velmi vysoké úrovni. Uživatelské prostředí zahrnuje řadu praktických a po návyku nepostradatelných dovedností jako je například vyvolání kontextového menu po kliknutí pravého tlačítka myši, která ušetří uživateli čas a hledání příslušných nástrojů. Pomocí myši se do scény vkládají i jednotlivé prvky modelu. Nabízenou samozřejmostí jsou možnosti tisku a ukládání vyhotovených či rozpracovaných 5
diagramů. Přístupný je i export diagramů do formátu XML, což umožňuje dle potřeb vytáhnout z rozsáhlých dat požadované informace, které se takto stávají dostupné pro další software nebo jiné zpracování.
3.2.1 Uživatelské možnosti Vybral jsem několik modelovacích nástrojů a doplňků, u kterých stojí za povšimnutí jejich důmyslnost a praktičnost. Použité obrázky jsem převzal z dokumentací k produktu Business Process Visual ARCHITECT.
Obrázek 3.1: Prezentace doplňku Resource-centric interface
Resource-centric interface („zdrojové centrální rozhraní“) Po najetí kurzoru na objekt se kolem elementu objeví ikonky zastupující nástroje, což uživateli ušetří čas, neboť je zkrácena trajektorie kurzoru k aktivaci často používaných nástrojů. Expanded Sub Process („rozbalený podproces“) Při modelování rozsáhlých projektů je přínosné vidět u každého procesu i jeho další případné podprocesy. Po kliknutí na proces je uživatelské prostředí převedeno na modelování těchto podprocesů.
Obrázek 3.2: Prezentace doplňku Expanded Sub Process
Styl propojení Pro zvýšení přehlednosti je praktické vybírat z několika různých stylů datových toků. Každý styl propojení může představovat jiný typ přenosu informací. Obrázek 3.3: Prezentace doplňku Styl propojení
Sweeper („zametací stroj“) Nabízí hromadné posuny vybraných prvků v diagramu. Lze využít k vytvoření prostoru pro nové elementy uvnitř rozpracovaného diagramu, anebo jen pro zvýšení celkové přehlednosti diagramu. Obrázek 3.4: Prezentace nástroje Sweeper
3.2.2 Ukázkový příklad procesního diagramu Na obrázku 3.5 je vystřižena část procesního diagramu, který naleznete celý na přiloženém CD. Tento model byl vyhotoven v programu Borland Together a představuje firemní proces společnosti, která tiskne bakalářské práce. Elementy activity představují činnosti (procesy). Elementy decision 6
rozhodují mezi následujícími činnostmi. Činnosti mezi elementy join musí být dokončeny než dojde k činnosti následující po spojovacím elementu join. V ukázkovém příkladu tedy dojde k vazbě bakalářské práce až bude dokončen tisk i případná příprava přílohy.
Obrázek 3.5: Ukázka procesního diagramu
3.2.3 Přístupný software Business Process Visual ARCHITECT Jeden z produktů firmy Visual Paradigm (hlavní sídlo firmy: Hong Kong). http://www.visual-paradigm.com/
Obrázek 3.6: Business Process Visual ARCHITECT
Borland Together Produkt firmy Borland (hlavní sídlo firmy: Cupertino, USA). http://www.borland.com/us/products/together/
7
3.3 Modelování ve virtuální realitě Diagram se ve virtuální realitě dostává do vizualizace, kde je uživatel ponořen do činnosti, při jejímž konání téměř nevnímá rušivé elementy okolí. S použitím vhodného hardwaru lze modelovat diagram pomocí pohybů obou rukou, což přidává modelování zcela nový prožitek. Uživatelské menu s nástroji je možno vizualizovat 2D i 3D. Na prvním místě pro pozdvihnutí vizualizace diagramu v prostoru je vyhnutí se nejasným a neúhledným překřížením datových toků. Dále lze získat pohled na vymodelovaný diagram z různých stran natáčením scény. Popisky prvků diagramu lze neustále udržovat nasměrované k uživatelskému pohledu, čímž nepřestávají být čitelné a model tak neztrácí svojí hodnotu. Zásluhou třetího rozměru vizualizace se uživateli nabízí rozšířená pracovní plocha. Do diagramů lze kromě 2D obrázků importovat různé 3D objekty vymodelované například v programu Rhinoceros 3D nebo Cinema. Jejich příkladem jsou malé objekty jako je například telefon, auto nebo pracovní stroje. Ale nabízí se například i možnost zobrazení celého areálu firmy, ve kterém lze vhodně rozmístit procesy dle jejich skutečné fyzické pozice. Swimlanes (plavecké dráhy) je možno vizualizovat průhlednými kvádry, popřípadě jinými 3D objekty, které mohou mít podobu místnosti či budovy. Další možností je procesy patřící do jedné swimlane obarvit stejnou barvou.
3.3.1 Virtuální realita Virtuální realita (dále VR) je počítačem vizualizované prostředí snažící se uživatelům poskytnout iluzi, že se nacházejí v umělém (virtuálním) světě. Virtuální svět je uložen v paměti počítače a pomocí pokročilého hardwaru nabízí jak zrakový a sluchový, tak hmatový prožitek. U pokročilých simulátorů dokonce působí i na lidský vjem rovnováhy. 3D prostor je definován souřadnicovým systémem, v němž jsou body prostoru jednoznačně určeny. Objekty mají svou polohu a tvar popsán souřadnicemi (na osách x, y a z) a jejich povrch je tvořen polygony s přiřazenou barvou nebo texturou. Na objekty lze použít řadu transformací. Mohou být natočeny, zvětšeny, zmenšeny, zkoseny nebo posunuty. Zobrazovaná scéna je představována výpočtem viditelných bodů z uživatelova pohledu (nazýváno rendering), který je určen souřadnicemi pozorovatele, jeho orientací pohledu a úhlem výhledu (FOF - Field Of View). Uživatelova bytost ve virtuálním světě může nabývat různých podob a je nazývaná avatar. Avatar může být například člověk, zvíře nebo pohádková postava.
Obrázek 3.7: Uživatelova bytost ve virtuálním světě - avatar
Abychom uživateli navodili pocit reality, musí zobrazovaný svět na uživatele působit dokonale, tedy plynule a hladce. Zpracování jakékoliv operace musí proběhnout rychlostí označovanou realtime. Například překreslení scén na zobrazovacím médiu je potřeba provést nejméně 20krát 8
za sekundu (20Hz) a vysílání pulsů lidskému tělu 1000krát za sekundu (1kHz). Multi-user VR (víceuživatelská VR) dovoluje více uživatelům společně se aktivně účastnit dění ve VR. Propojením počítačů do sítě mohou uživatelé z různých míst planety sdílet společnou virtuální kancelář nebo virtuální konferenční sál. Hlavní znaky VR: - přístup k pohledům jinak nepřístupným - realistická prezentace nestandardních situací
3.3.2 Tři úrovně VR aplikací Aplikace rozlišujeme podle zpřístupnění VR uživateli. Immersive (pohlcující) VR Uživatel je dokonale obklopen virtuálním prostředím a je v maximální možné míře oproštěn od vjemů skutečného světa. Často je použit simulátor, který se naklání a vyvolává pocity spojené se scénou VR. Pokročilý hardware dokonce nabízí zařízení, která jsou schopna měnit odpor či tlak proti tělu uživatele a tím umožňuje fyzicky pociťovat VR. Augmented (rozšiřující) VR Okolní svět je kombinován s prvky VR. Součástí systému bývá kamera, jejíž pozice a orientace je synchronizována s pohybem uživatele s využitím různých senzorů. Využití nalezneme například u vojenských letadel a vozidel - objekty ze skutečného světa jsou při pohledu tímto systémem virtuálně obohaceny symboly značící nepřátelské a spřátelené objekty. Další zajímavé využití najdeme v oblasti kultury. Uživatel prochází historicky zajímavými místy a přes speciální brýle vidí počítačem doplněné stavby, předměty nebo i postavy lidí z minulosti. Na obrázku 3.8 jsou na nádvoří zámku vizualizací doplněny tři postavy přibližující styl života dřívějších let. Této technologie lze využít při procházení podniku k vizualizaci různých informací, které se dají využít například ke kontrole správného průběhu a naplňování firemního plánu.
Obrázek 3.8: Augmented VR
Non-Immersive/Desktop (jednoduchá) VR Uživatel není obklopen virtuálním prostředím. Stojí například před monitorem nebo projekčním plátnem. Není využito speciálních technických zařízení.
9
3.3.3 Prezentace prvků diagramu Start / End (začátek / konec) Flow (datový tok) Válec společně s kuželem. Element spojující prvky diagramu a znázorňující směr toku dat. Obrázek 3.9: Elementy start a flow
Activity (proces) Prvek reprezentující činnost.
Obrázek 3.10: Element activity
Decision (rozhodovací prvek) Dva kužely. Na obrázku žlutý prvek diagramu. Slouží jako rozhodující prvek, který na základě splněné podmínky směruje datové toky k dalším prvkům diagramu.
Obrázek 3.11: Element decision
Join (spojovací prvek) Znázorněn kvádrem uprostřed obrázku. Prvek, který organizuje tok dat. K následující činnosti dojde až poté, co jsou obdrženy informace ze všech příchozích datových toků. Obrázek 3.12: Element join
3.3.4 Prezentace nástrojů
Obrázek 3.13: Nástroj Activity
Obrázek 3.14: Nástroj Decision
Activity (Činnost) Dle pozice pravé ruky vloží do scény oválný objekt představující činnost. Vložený objekt je opatřen popiskem a je možné jej obarvovat.
Decision (Rozhodovací element) Dle pozice pravé ruky vloží do scény dva kužele zabalené průhlednou krychlí, kterou je možné obarvovat. Prvek je opatřen popiskem a představuje rozhodující element diagramu. 10
Join (Spojovací element) Dle pozice pravé ruky vloží do scény kvádr zabalený o něco větším průhledným kvádrem, který je možné obarvovat. Obrázek 3.15: Nástroj Join
Remove (Odstranit) Odstraní ze scény vybraný objekt. Pokud k němu jsou připojeny datové toky, odstraní je také. Obrázek 3.16: Nástroj Remove
Obrázek 3.17: Nástroj Flow
Flow (Datový tok) Uživatel pro vložení datového toku musí postupně vybrat dva objekty, přičemž datový tok je orientován v pořadí jejich výběru. Kužel představující směr datového toku je umístěn v polovině mezi propojenými objekty. Dosahujeme tak zvýšené přehlednosti, neboť předcházíme častějšímu skrytí kužele za objektem po natočení scény. Color (Obarvit) Po aktivaci nástroje je možné vybírané prvky obarvit.
Obrázek 3.18: Nástroj Color
Obrázek 3.19: Nástroj New
New (Nový) Založení nového diagramu, které vyvolá odstranění všech stávajících objektů ze scény.
Open (Otevřít) Načte scénu z naposled uloženého XML. Obrázek 3.20: Nástroj Open
Save (Uložit) Uloží scénu do XML. Obrázek 3.21: Nástroj Save
Exit (Konec) Opuštění aplikace. Obrázek 3.22: Nástroj Exit
11
Kapitola 4
Použitá technologie 4.1 Systém VRECKO
Obrázek 4.1: Screenshot vizualizace systému VRECKO
Základní technologií je systém VRECKO, který je otevřeným multiplatformním systémem pro tvorbu aplikací obsluhující virtuální realitu. Systém VRECKO je vyvíjen v laboratoři HCI (Human Computer Interaction Laboratory) na Masarykově univerzitě. Při jeho vývoji je kladen zřetel zejména na možnost dynamické změny vlastností prvků virtuálního prostředí a na snadnou konfigurovatelnost a rozšiřitelnost systému.
4.1.1 Multiplatformnost VRECKO je vyvíjeno v programovacím jazyku C++ a je postaveno na open source technologiích. Pro vykreslování scény využívá knihoven OpenGL a OpeneSceneGraph. Interpretace 3D zvuku je docíleno použitím knihovny OpenAL. Díky této konstrukci je možnost používat VRECKO na různých operačních systémech jako je například MS Windows nebo GNU/Linux.
4.1.2 Rozšiřitelnost Pomocí zásuvných modulů (pluginů) je jednoduché přiřazovat virtuálním objektům různé schopnosti a definovat chování k okolí virtuálního světa, kde komunikaci zajišťují reakce na různé vstupy a výstupy. Ukázkovým pluginem je například existence uživatelských rukou ve virtuálním světě, pomocí kterých lze uchopit okolní virtuální objekty a manipulovat s nimi. Zásuvné moduly jsou dynamicky linkované knihovny, které si systém dle potřeby načítá a zpracovává.
4.1.3 Konstrukce systému VRECKO podporuje chování v reálném čase, což vyžaduje důmyslnou konstrukci a výkonný hardware. Základním objektem systému je World, který si udržuje přehled všech používaných objektů. Objekt Scene si uchovává v paměti vytvořené virtuální objekty a pamatuje si uživatelův pohled (pozici a orientaci uživatele). EventDispatcher odchytává a zpracovává události objevující se v systému a tím zajišťuje potřebnou komunikaci jednotlivých prvků virtuálního světa. Vysílaní události může být přímé mezi určitými objekty, ale i hromadné, kdy vyslanou událost odchytí všechny objekty, které jsou na ni nastaveny. Entita Scheduler umožňuje časované vyvolávání 12
událostí. Virtuální objekt na scéně zastupuje v paměti počítače objekt EnvironmentObject, který nese informace o jeho geometrii, vlastnostech a transformacích (posunutí, rotace a změna velikosti). Geometrie objektů je načítána z formátu Wavefront, který je možno vymodelovat v dostupných 3D modelářích, jako je například Rhinoceros 3D. Je tedy možno zobrazovat vedle primitivních objektů i složitější objekty – například budovy. Každý virtuální objekt může mít přiřazeny schopnosti (Abilities), které jsou představovány zásuvnými moduly. Tento přístup vytváří prostor pro psaní nových aplikací. Systém podporuje načítání scény z XML souboru, ve kterém lze nastavit zobrazované virtuální objekty. U každého objektu se zde nastavuje i jeho geometrie, transformace, vlastnosti i schopnosti.
3.1.4 Formát Wavefront Formát Wavefront je standard ukládání 3D objektů (přípona *.obj). Tento standard podporuje i systém VRECKO a načítané virtuální objekty pochází právě z tohoto formátu. Objekt uložený v tomto formátu je podle svých souřadnic vkládán do virtuálního světa. Struktura formátu Wavefront: #cesta k souboru, který definuje materiály objektů mtllib options.mtl #jméno materiálu usemtl partition0 #geometrie objektu v float float float (souřadnice jednoho bodu v prostoru) vn float float float (normála) vt float float (souřadnice textury) f int int int ... (nebo) f int/int int/int int/int . . . (nebo) f int/int/int int/int/int int/int/int ... (tvar polygonu - čísla představují indexy bodů/textur/normál, indexy jsou určeny pořadím svého typu v souboru)
Příklad: # kostka.obj v111 v 1 1 -1 v 1 -1 1 v 1 -1 -1 v -1 1 1 v -1 1 -1 v -1 -1 1 v -1 -1 -1 f1342 f5786 f1562 f3784 f1573 f2684
4.2 OpenSceneGraph OpenSceneGraph (zkratka OSG) je open source knihovna. Nabízí efektivní vykreslování scény, detekce kolizí, funkce pro pohodlnou grafickou práci se scénou a funkce pro objekty ve scéně. VRECKO je s touto knihovnou plně provázáno a v zásuvných modulech VRECKA je tak poskytnuta možnost využívat funkce OSG.
13
4.3 Hardware obsluhující virtuální realitu Stereoskopická projekce Pomocí dvou projektorů jsou promítány na plátno dva pohledy na scénu, přičemž jeden pohled je určen pro pravé a druhý pohled pro levé oko.
Obrázek 4.2: Stereoskopická projekce
Polarizační brýle Převádí pozorovateli obraz stereoskopické projekce do plnohodnotného 3D.
Obrázek 4.3: Polarizační brýle
Nest of Birds Přístroj, který dokáže souběžně sledovat orientaci a polohu až čtyř senzorů. S vysokou frekvencí předává přesná data. Technologie využívá indukci magnetického pole, ve kterém se senzory mohou umístit například na uživatelovy ruce nebo hlavu.
Obrázek 4.4: Nest of Birds
Rukavice (Pinch Gloves) Ve spojení s Nest of Birds umožňují uchopit virtuální předmět a pracovat s ním, měnit jeho polohu či nastavení. Kombinacím dotyků konečků prstů lze přiřadit různé události, které v podstatě zastupují známé kliknutí myší. Kombinací je například dotek levého palce a pravého ukazováčku.
Obrázek 4.5: Rukavice
14
4.4 Moderní značkovací jazyky 4.4.1 XML Jazyk XML je podobný jazyku HTML. A díky tomu je pro mnohé z nás rychle pochopitelný. Struktura XML může také sloužit pro tvorbu internetových stránek, ale na rozdíl od HTML je použitelná i v jiných případech. Liší se tím, že uzly dokumentu mohou nést libovolné označení a uzly neslouží ke způsobu zobrazení dat, ale k jejich popisu. To je pro nás ocenitelné z důvodu zvýšené přehlednosti a zlepšené možnosti vyhledávání v dokumentu. Zavedením jmenných prostorů (namespaces) můžeme v jednom dokumentu současně používat několik na sobě nezávislých druhů značkovaní. Ukázkové XML, na jehož podobné konstrukci je založeno vyexportované XML z programu Borland Together: <process> <elements>
proces1 proces1 <model> <element>
<element>
4.4.2 Schémata XML Schémata přesně určují a vymezují strukturu XML dokumentů. XML dokument má ve svém obsahu uvedenou cestu k příslušnému XML schématu, podle kterého lze samotný dokument validovat. Dokument je validní, právě když má správnou strukturu dle stanoveného schématu. Přiblížíme si zde pouze dvě schémata, se kterými jsem se při práci setkal. DTD (Document Type Definition) Jazyk pro popis schématu dokumentu pocházející ještě z jazyka SGML. DTD díky tomu má jednu velkou výhodu – podporuje ho velké množství aplikací. To je však současně jeho jedinou výhodou. Mezi nevýhody patří to, že nepodporuje jmenné prostory, neumožňuje určení datového typu pro obsah elementů a atributů. Nabízí sice jednoduchý a kompaktní zápis, ale používá syntaxi, se kterou se v XML nesetkáváme. DTD k ukázkovému XML z podkapitoly 4.4.1:
15
XML Schéma XML Schéma k ukázkovému XML z podkapitoly 4.4.1: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="process"> <xs:complexType> <xs:sequence> <xs:element name="elements" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="activity" type="activityType" maxOccurs="unbounded"/> <xs:element name="model" minOccurs="1" maxOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="element" type="elementType" maxOccurs="unbounded"/> <xs:complexType name="activityType"> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:attribute name="id" type="xs:int" use="required"/> <xs:complexType name="elementType"> <xs:sequence> <xs:element name="ref" type="refType"/> <xs:element name="geometry" type="xs:string"/> <xs:complexType name="refType"> <xs:attribute name="refid" type="xs:int" use="required"/>
4.4.3 XPath a XSLT XPath (XML Path Language) je jazyk, který umožňuje adresovat jednotlivé části dokumentu. S jazykem XPath můžeme jednoduchým zápisem získat například libovolný podstrom XML dokumentu nebo pouze uzly s určitou hodnotou. XSLT slouží jako šablona transformace, která 16
společně s jazykem XPath překonvertuje vstupní XML do nové struktury. Na principu této ukázkové šablony je založen i konverzní můstek aplikovaný v Konvertoru T2V. <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/">
<xsl:for-each select="//activity"> <xsl:sort select="@id"/> <xsl:variable name="id"> <xsl:value-of select="@id" /> <EnvironmentObject> <xsl:value-of select="$id"/> <xsl:value-of select="name"/> <xsl:value-of select="//element[@idref=$id]/parent::*/preceding-sibling::element.geometry"/>
17
Kapitola 5
Zásuvný modul AP_BusinessProcess V této kapitole naleznete hlavní cíle zásuvného modulu, postupy k jejich dosažení a rozebranou implementaci zásuvného modulu.
5.1 Stanovené cíle Cílem zásuvného modulu je uživateli nabídnout základní nástroje k modelování procesních diagramů. Prvním základním nástrojem je umisťování prvků diagramu do scény dle pohybů a pokynů uživatelových virtuálních rukou. Vedle jednoduchého vkládání objektů je třeba nabídnout uživatelům co nejsnadnější propojovaní prvků diagramu datovými toky. Pro editovatelné uspořádání prvků diagramu je nutná možnost manipulace s prvky a dále i nevyhnutelná potřeba jednotlivé prvky diagramu odstraňovat. Ke zvýšení přehlednosti a logičnosti diagramu je cílem nabídnout nástroj, který umožní jednotlivé objekty obarvovat. Pro dosáhnutí plnohodnotné aplikace je nezbytné doplnit nástroje pro založení nového diagramu, jeho uložení do souboru a načtení ze souboru. Pro plné využití prostoru je dalším cílem umožnit natáčení celého modelu kolem všech tří os prostoru (x, y a z) a textové popisky prvků udržovat neustále čitelné k pohledu uživatele.
5.2 Zásuvné moduly systému VRECKO Jednotlivé objekty ve virtuálním světě mohou mít různé schopnosti. Tyto schopnosti zprostředkovávají zásuvné moduly. Zásuvný modul je představován dynamicky linkovanou knihovnou, která splňuje kritéria systému VRECKO a na požádání vytvoří v paměti počítače instanci potomka objektu Ability a předá systému její ukazatel. Příslušný ukazatel je posléze provázán s virtuálními objekty, které danou schopnost mají nabídnout. Toto provázání lze provést při inicializaci aplikace i za jejího běhu (dynamické změny vlastností prvků virtuálního prostředí). Zásuvný modul musí být schopný interakce s uživatelem, je tedy potřebné nějakým způsobem udržovat komunikaci hardwaru a zavedených objektů. Tuto komunikaci zajišťuje objekt systému VRECKO EventDispatcher, který zajišťuje i komunikaci mezi samotnými virtuálními objekty.
5.2.1 Objekt Ability Na objektu Ability jsou založeny schopnosti virtuálních objektů. V této části si jej rozebereme podrobněji, čímž se vyhneme nejasnostem v následujících podkapitolách popisujících implementaci zásuvného modulu. Objektové programování umožňuje u potomků objektů překrývat rodičovské metody. Schopnosti objektů jsou potomky objektu Ability a pro jejich konkrétní definici je nabídnuto 18
překrytí základních metod, které si stručně rozebereme dále. void preInitialize() Používá se pro inicializaci hodnot a definování vstupů a výstupů. Je volána před načtením parametrů schopnosti. bool loadXMLParameters(DOMNode *pParametersNode) Načítá ze stromové struktury uzlů potřebné parametry dané schopnosti. Zde je možné provést i prvotní zpracování načtených parametrů. void postInitialize() Po načtení parametrů je zavolána tato metoda. void update() Každou schopnost je možno přiřadit do seznamu objektu Scheduler, který dle zadané frekvence volá právě tuto metodu. void processEvent(std::string strInputName, void *pValue) Metoda volaná objektem EventDispatcher. Zde je tedy možnost předepsat zpracování a reakci na vstupní události. DOMNode* DiagramFlow::getXMLParameters(DOMDocument *pDocNode) Pro další zpracování, například pro export do souboru XML, tato metoda vrátí k příslušné schopnosti její parametry a vlastnosti v přehledné stromové struktuře.
5.3 Konfigurace systému VRECKO Prvním krokem před spuštěním systému VRECKO je jeho počáteční konfigurace. Vedle základní konfigurace pro vizualizaci si systém při inicializaci načítá konfigurační soubor XML, kde je možné definovat jednotlivé virtuální objekty včetně jejich geometrie, transformací, vlastností a schopností. Dále se zde uvádí připojená zařízení a jejich komunikační porty. A nakonec jsou zde definovány události, jejich identifikátor, vysílač a příjemce. Celý konfigurační soubor potřebný pro správnou funkčnost mého výsledného pluginu pod systémem VRECKO je k nahlédnutí na přiloženém CD. V následujících podkapitolách si podrobněji rozebereme potřebná nastavení v konfiguračním souboru XML.
5.3.1 Avatar Hlavním virtuálním objektem virtuálního světa je objekt Avatar, který představuje uživatele ve virtuálním světě. Udržuje si v paměti uživatelovu polohu, orientaci pohledu a případné další virtuální objekty pohybující se společně s uživatelem. Těmito objekty svázanými s uživatelem jsou například uživatelovy ruce. Já jsem této možnosti využil pro vizualizaci aplikačních nástrojů, díky čemuž má pohybující se uživatel nástroje neustále „po ruce“. Navíc jsem zde přidal možnost uživateli toto menu umístit do libovolné pozice, která pevně zachovává závislost polohy nástrojů k avatarově poloze.
19
5.3.2 Připojená zařízení Příklad nastavení připojeného zařízení do systému:
1 COM1 Zdrojový kód 5.1: Definice připojeného zařízení
Uzel
nastaví identifikátor zařízení, které je dle uzlu připojeno ke komunikačnímu portu COM1. V tomto případě se zde očekávají připojené rukavice (Pinch Glove).
5.3.3 Definice událostí Pro definování různých kombinací dotyků prstů rukavicí Pinch Glove vypadá definice události následovně: <Event InterconnectionType="ACTIVATE_INPUT"> <Sender>De|1#Contact|RT.RP. EO|1#Ab|BusinessProcess::GUI#Default|1 Zdrojový kód 5.2: Definice události
Vidíme, že se jedná o zápis dat do stromové struktury formátu XML. Uzel <Sender> definuje, že vysílačem události je zařízení s identifikátorem „1“ (dle předchozí podkapitoly se jedná o rukavice Pinch Glove) a inicializující kombinací prstů je dotyk pravého palce (Right Thumb) a pravého malíčku (Right Pinkie). Tabulka 5.1: Vysvětlení řetězce uvedeného v uzlu <Sender> (Zdrojový kód 5.2)
Podřetězec
Popis De Značí uvedení zařízení (Device) 1 Identifikátor zařízení
Contact Identifikátor události ze zařízení RT.RP. Hodnota události (Right Thumb & Right Pinkie) Uzel definuje příjemce události. Ve výše uvedeném příkladě vzniklou událost obdrží a zpracovává objekt zásuvného modulu BusinessProcess nazvaný GUI. Tabulka 5.2: Vysvětlení řetězce uvedeného v uzlu (Zdrojový kód 5.2)
Podřetězec
Popis EO Značí uvedení virtuálního objektu 1 ID virtuálního objektu 20
Ab Schopnost (Ability) BusinessProcess Jmenný prostor GUI Objekt, který přijímá událost Default ID přijímané události 1 Hodnota přijímané události V tomto formátu je možno definovat i události vysílané například klávesnicí nebo myší.
5.4 Implementace zásuvného modulu V této části blíže popisuji konstrukci a implementaci zásuvného modulu AP_BusinessProcess, včetně uvedení částí zdrojového kódu. Vysvětlíme si zde důležité elementy pluginu a uvedeme si jejich princip a využití. Každý virtuální objekt ve scéně (Environment Object, dále EO) má vlastní identifikátor představovaný celým kladným číslem. V následující tabulce uvádím rozdělení virtuálních objektů vynucené pro jejich základní rozlišení. Tabulka 5.3: Rozdělení virtuálních objektů dle identifikátorů
Identifikátor EO
Popis EO
{1}
GUI (uživatelské menu), nelze smazat.
{2...10}
objekty, které nelze smazat
{11...900000}
prvky diagramu: činnosti, rozhodovací elementy, spojovací el., startovní a koncové el.
{900001...950000}
prvky diagramu: datové toky
{950001...1000000}
nástroje GUI
{1100000}
avatar
{1100001}
pravá ruka
{1100002}
levá ruka
5.4.1 GUI Základním objektem, který řídí předávání zpráv mezi objekty, obsluhuje volání nástrojů a zprostředkovává uživatelské menu, je objekt GUI. Komunikaci umožňují události systému identifikované jako Click a Default. Událost Click je vyslána dotykem pravého palce a pravého ukazováčku rukavic Pinch Glove. Důsledkem této události může být buď výběr nástroje a nebo v případě, že nevybíráme nástroj, dojde k aktivaci nástroje naposled vybraného. Aktivací nástroje se rozumí vyvolání jeho dovednosti, tedy například umístění objektu do scény či uložení scény. V následující ukázce zdrojového kódu je popsaná reakce objektu GUI na událost Click, kterou zpracovává metoda processEvent(). Prvním krokem po obdržení události Click se objekt GUI pokusí detekovat kolizi pravé ruky s virtuálním objektem. Pokud nedetekuje kolizi s objektem představujícím nástroj, dojde k aktivaci naposled vybraného nástroje. Zde ještě nesmíme opomenout, že událost Click má dvě 21
hodnoty: True nebo False. Hodnotu True v případě kontaktu prstů a False v případě uvolnění tohoto kontaktu. Výběr nástroje probudí u konkrétního objektu reprezentujícího nástroj schopnost pulzovat a objekt GUI si pro další použití zapamatuje ukazatele na tento vybraný nástroj. //finding EO right hand vrecko::Scene *scene = owner->getScenePtr(); vrecko::EnvironmentObject *hand = scene->getEnvironmentObject(1100001); if(hand){ //value of received event (click~true, release~false) bool *pbool = (bool*)pValue; //detect selection of tool vrecko::EnvironmentObject *eo = scene->getCollisionObject(hand); if((eo) && eo->getID()>950000){ //mark tool as active activeTool = (BusinessProcess::Tool *)eo->getAbility("BusinessProcess::Tool"); //pulse of tool vrecko::Ability *a = eo->getAbilityWithInput("Use"); if (a) a->processEvent("Use", pValue); //if no colision with tool -> activate tool (if some tool is actived..) }else{ if (activeTool && *pbool) activeTool->activate(); } //EO hand not found }else{ cout << "EO hand not found.\n"; } Zdrojový kód 5.3: Výstřižek z objektu GUI
Událost Default je vyslána stisknutím pravého palce a pravého malíčku. Vyvolá umístění uživatelského prostředí do výchozí polohy. Další vlastností uživatelského menu je totiž možnost jeho variabilní polohy v prostoru. Například jeho úplné odložení z pohledu uživatele nebo takové umístění, kdy uživateli zůstanou viditelné pouze nástroje barev (Obrázek 5.1). /* owner … instance virtuálního objektu GUI */ if (strInputName == "Default"){ //set default position of gui owner->setPosition(osg::Vec3(7,4.5,0)); owner->setRotation(osg::Vec3(0,0,0));
} Zdrojový kód 5.4: Výstřižek z objektu GUI
22
Obrázek 5.1: Variabilní poloha uživatelského menu
5.4.2 Nástroje Další důležitou složkou konstrukce pluginu je objekt Tool, který je z objektového pohledu rodičem všech nástrojů z uživatelského menu. Uvádím zde dvě důležité metody tohoto objektu. void Tool::activate() Metoda, kterou je potřeba v potomcích objektu překrýt. Je zavolána v případě aktivace vybraného nástroje. void Tool::addToScene(osg::Vec3 pos) Dle parametru, kterým je vektor, umístí do prostoru virtuální objekt - krychličku potaženou texturou dle příslušného nástroje. Tomuto virtuálnímu objektu je též touto metodou přiřazena schopnost pulzovat, která je využita při aktivaci nástroje. Aktivovaný nástroj pulzuje, dokud není uživatelem vybrán jiný nástroj. Tuto metodu si volá objekt GUI.
5.4.3 Elementy diagramu Pří důkladnějším pohledu na vymodelovaný diagram zjistíte, že elementy diagramu jsou pro dosáhnutí efektivnější vizualizace představovány tělesem, které je umístěno uvnitř dalšího ovšem průhledného tělesa. Toto průhledné těleso může nabývat různých barev dle použitého nástroje pro obarvování. Veškeré elementy diagramu s výjimkou datových toků obstarává a zprostředkovává objekt DiagramItem, který načítá geometrii virtuálních objektů dle typu elementu a opatřuje prvky výchozím popiskem „Default text“. Dále si tento objekt udržuje seznam všech datových toků, se kterými je propojen. Důvod pro udržování si tohoto seznamu je prostý. Při manipulaci s elementy diagramu musí být manipulováno i s jeho připojenými datovými toky a v případě odstranění některého elementu, dojde i k odstranění připojených datových toků. Seznam je udržován v soukromém atributu objektu pojmenovaném m_vFlow. V ploše známe funkce textu pro zarovnání vlevo, vpravo, na střed, nahoru a dolů. V prostoru možnosti zarovnání přibývají. Neustálé udržování popisků prvků v čitelné formě z pohledu uživatele je docíleno OSG funkcí setAxisAlignment, jejíž význam lze přeložit jako úhlové zarovnání. Konkrétně pro natočení textu k pohledu uživatele slouží parametr této funkce s hodnotou osgText::Text::SCREEN.
23
5.4.4 Datové toky Virtuální objekt představující datový tok má schopnost pamatovat si dva elementy diagramu, které propojuje. Této schopnosti jsem dal jméno DiagramFlow (potomek objektu Ability). Dle elementů, které propojuje, umístí do scény válec, jehož jedna podstava má střed totožný se středem prvního elementu a druhá podstava má střed totožný se středem druhého elementu. Dále si vypočítáme střed středů těchto dvou propojených elementů a do něj umístíme kužel orientovaný ve směru datového toku (Obrázek 5.2).
Obrázek 5.2: Datové toky
Schopnost DiagramFlow si tedy pamatuje oba identifikátory virtuálních objektů, které propojuje. První zastupuje počáteční prvek datového toku a druhý představuje koncový prvek datového toku. Jejich jména jsou m_iStartID a m_iEndID. Metoda display() dle těchto dvou identifikátorů umístí do scény objekty datového toku. Uvádím zde výstřižek zdrojového kódu, který se stará o vytvoření a příslušné transformace nových virtuálních objeků (Zdrojový kód 5.5). Vkládaný válec podstoupí transformaci zvětšení či zmenšení a posléze rotaci. Kužel podstoupí pouze rotaci. //Start and End vertex osg::Vec3 osgStart = ((owner->getScenePtr())->getEnvironmentObject(m_iStartID))->getPosition(); osg::Vec3 osgEnd = ((owner->getScenePtr())->getEnvironmentObject(m_iEndID))->getPosition(); //place this EO in the middle between joined EOs owner->setPosition((osgEnd + osgStart)/2); m_osgCylinder->setCenter(osg::Vec3(0,0,0)); //position of center m_osgCylinder->setRadius(0.05); //radius m_osgCylinder->setHeight((osgEnd - osgStart).length()); //height m_osgCone->setCenter(osg::Vec3(0,0,0)); //position of center m_osgCone->setRadius(0.2); //radius m_osgCone->setHeight(0.8); //height //rotation from vec1 to vec2 osg::Vec3f *vec1 = new osg::Vec3f(0, 0, 1);
24
osg::Vec3f *vec2 = new osg::Vec3f(osgEnd - osgStart); osg::Quat *quat = new osg::Quat(); quat->makeRotate(*vec1,*vec2); m_osgCylinder->setRotation(*quat); m_osgCone->setRotation(*quat); Zdrojový kód 5.5: Výstřižek metody display() objektu DiagramFlow
Metoda update() vyvolává aktualizaci polohy a velikosti virtuálního objektu, který představuje datový tok.
5.4.5 Manipulace s elementy diagramu Při manipulaci s elementy diagramu nesmíme zapomenout na jejich provázané datové toky. Pro plynulou a pohodlnou práci s diagramy je cílem práce udržovat elementy neustále propojené, a to i při samotné manipulaci s objekty. Každý element diagramu si díky své schopnosti DiagramItem pamatuje ukazatele na své připojené datové toky ve vlastním soukromém atributu m_vFlow. Během manipulace s prvkem diagramu je ukazatel schopnosti DiagramItem přiřazen objektu Scheduler, který volá její metodu update() na předepsané frekvenci. Tato metoda postupně prochází atribut m_vFlow a u každého datového toku vyvolá jeho překreslení. void DiagramItem::update() { //update all flows added to this item! for(std::vector::iterator it = m_vFlow.begin(); it != m_vFlow.end(); it++) { //update added flow BusinessProcess::DiagramFlow *a = (BusinessProcess::DiagramFlow *) ((vrecko::EnvironmentObject *)*it)->getAbility("BusinessProcess::DiagramFlow"); a->update(); } } Zdrojový kód 5.6: Metoda update() objetku DiagramItem
5.4.6 Odstraňování elementů diagramu Při odstraňování nesmíme zapomenout odstranit společně s odstraňovaným elementem diagramu všechny jeho provázané datové toky. To nám umožňuje vlastnost všech prvků diagramu pamatovat si seznam ukazatelů na připojené datové toky. Situaci máme zkomplikovanou, neboť každý datový tok propojuje elementy dva. Ukazatele datového toku je tedy nutné vymazat z paměti druhého elementu, který v diagramu zůstává. V následující ukázce zdrojového kódu je uvedena samotná metoda activate() nástroje ToolRemove, který odstraňování zprostředkovává. Použita je zde SGO funkce, která se postará o bezpečné odebrání datového toku ze scény. Zabrání u vykreslovaných 25
virtuálních objektů chybnému sáhnutí do paměti počítače. void ToolRemove::activate() { //finding EO hand vrecko::Scene *scene = owner->getScenePtr(); vrecko::EnvironmentObject *hand = scene->getEnvironmentObject(1100001); if(hand){ //detect selection of tool vrecko::EnvironmentObject *eo = scene->getCollisionObject(hand); //remove only diagram elements if(eo && eo->getID()>10 && eo->getID()<950000){ //eo with id < 900.000 can have some flows, we remove them too if(eo->getID()<900000){ BusinessProcess::DiagramItem *di = (BusinessProcess::DiagramItem *) eo->getAbility("BusinessProcess::DiagramItem"); std::vector vf = di->getFlow(); for(std::vector::iterator it = vf.begin(); it != vf.end(); it++) { //remove flow ((BusinessProcess::DiagramFlow *)((vrecko::EnvironmentObject *)*it) ->getAbility("BusinessProcess::DiagramFlow")) ->removeFlowFromVector(eo->getID()); scene->removeEnvironmentObjectW(((vrecko::EnvironmentObject *)*it)->getID()); scene->SGO_removeChild((osg::Group*) (scene->getEORoot()),((vrecko::EnvironmentObject *)*it)); } } //remove eo scene->removeEnvironmentObjectW(eo->getID()); scene->SGO_removeChild((osg::Group*)(scene->getEORoot()),eo); } } } Zdrojový kód 5.7: Metoda activate() objektu ToolRemove
26
5.4.7 Obarvování elementů diagramu Obarvování objektů obstarává objekt ToolColor. Barva ukládaná jako jeho atribut je použita vedle obarvení prvků diagramu i k obarvení příslušného nástroje v uživatelském menu. K obarvení elementů diagramu slouží metoda void DiagramItem::setItemColor(const osg::Vec3 color) schopnosti DiagramItem. //find geode with loaded geometry osg::Geode *geode = (osg::Geode *)group2->getChild(0); osg::Drawable *drawable = (osg::Drawable *)geode->getDrawable(0); osg::StateSet *state = drawable->getStateSet(); osg::Material *material = (osg::Material *)state->getAttribute(osg::StateAttribute::MATERIAL); osg::Vec4 c = osg::Vec4(color, 0.5); material->setAmbient(osg::Material::FRONT_AND_BACK, c); material->setDiffuse(osg::Material::FRONT_AND_BACK, c); Zdrojový kód 5.8: Výstřižek metody setItemColor() objektu DiagramItem
5.4.8 Nová scéna Ze scény postupně odstraní všechny elementy diagramu, včetně provázaných datových toků. void ToolNew::activate(){ vrecko::Scene *scene = owner->getScenePtr(); std::map eomap = scene->getEOMap(); for(std::map::iterator it = eomap.begin(); it != eomap.end(); it++){ //remove all diagram items from scene if(it->second->getID() > 9 && it->second->getID() < 950000) { scene->removeEnvironmentObjectW(it->second->getID()); scene->SGO_removeChild((osg::Group*)(scene->getEORoot()),it->second); } } } Zdrojový kód 5.9: Metoda activate() objektu ToolNew
5.4.9 Uložení a načtení scény z XML Pro uložení a načtení scény jsem upravil objekt ReaderWriter pocházející ze systému VRECKO. Tento objekt spolupracuje se dvěma metodami schopností virtuálních objektů - getXMLParameters a loadXMLParameters. Jeho předností je umění pracovat s uzly stromové struktury a dovednost vytvořené instance virtuálních objektů a jejich schopnosti uložit do stromové struktry, či je ze stromové struktury vytvořit. Dále uvádím příkladnou metodu getXMLParameters objektu DiagramFlow.
27
DOMNode* DiagramFlow::getXMLParameters(DOMDocument *pDocNode) { DOMText *pText; DOMElement *pNode; char numberStr[15]; //Parameters ----DOMNode* pNodeParam = pDocNode->createElement(strToXerces("Parameters")); //Value ----pNode = pDocNode->createElement(strToXerces("Start")); pNodeParam->appendChild(pNode); sprintf(numberStr, "%d", m_iStartID); pText = pDocNode->createTextNode(strToXerces(numberStr)); pNode->appendChild(pText); //Type ----pNode = pDocNode->createElement(strToXerces("End")); pNodeParam->appendChild(pNode); sprintf(numberStr, "%d", m_iEndID); pText = pDocNode->createTextNode(strToXerces(numberStr)); pNode->appendChild(pText); //Return ----return pNodeParam; } Zdrojový kód 5.10: Metoda getXMLParameters() objektu DiagramFlow
28
5.5 Ukázkové screenshoty vymodelovaných diagramů Na prvním obrázku jsou nad prvky diagramu i uživatelovy virtuální ruce.
Obrázek 5.3: Screenshot z vizualizace systémem VRECKO
Obrázek 5.4: Screenshot z vizualizace systémem VRECKO
29
Kapitola 6
Konvertor T2V Celý konvertor je vypracován pomocí nástroje Netbeans 5.5, který nabízí pohodlné prostředí pro psaní aplikací v programovacím jazyce JAVA. Konvertor je obsluhován pomocí přehledného uživatelského rozhraní. Princip konverze 2D modelu na 3D model pro virtuální realitu je založen na transformaci XSLT a následném přepočítání některých hodnot jednotlivých prvků diagramu. Výstupem konvertoru je validní XML soubor zobrazitelný ve virtuální realitě s využitím systému VRECKO.
6.1 Objektová analýza Konvertor má plnit následující úkoly: - konvertovat XML z Borland Together do XML pro systém VRECKO - validovat dokumenty XML podle libovolného XML schématu - umožnit zadání cesty ke vstupnímu a výstupnímu XML souboru - nastavit a případně změnit cesty k používaným XML schématům a ke XSLT, toto nastavení ukládat a pamatovat si jej i při dalších spuštěních programu - pracovat se soubory „t2v“ pamatujícími si cesty k vstupnímu a výstupnímu XML souboru - nabídnout přehledné uživatelské prostředí (GUI) Práci celého programu jsem rozdělil tak, že jedna hlavní třída řídí a propojuje dalších sedm tříd (Obrázek 6.1). Je tedy snadné do struktury konvertoru zasahovat a jednotlivé objekty případně aktualizovat.
Obrázek 6.1: Objektová analýza konvertoru T2V
30
6.2 Teorie transformace Export XML z programu Borland Together je nabízen dle několika standardů. Vybral jsem standard UML 1.3 a standard XMI 1.3. Dle mnou vypracované šablony XSLT lze přehledně napsat i šablonu pro další standardy. V exportovaném XML z Borland Together máme o vztazích elementů pouze informaci, které z nich jsou propojené a jakým směrem mezi nimi data protékají. Proto ve výsledném 3D modelu nelze načíst i různá zalomení datových toků, které si uživatel vytvořil v původním 2D diagramu a prvky diagramu jsou z tohoto důvodu propojeny pouze rovným objektem. Obarvení elementů diagramu je provedeno dle plaveckých drah (swimlane), ve kterých jsou v původním 2D diagramu umístěny.
6.3 Postup konvertoru Prvním krokem konvertoru je ověření si zadaných cest k potřebným souborům (XML schématům, šabloně XSLT a vstupnímu XML). Následuje validace vstupního XML dle zadaného schématu. Dalším krokem je aplikace XSLT. Následující zdrojový kód (6.1) je výstřižek z šablony XSLT, která je použita pro transformaci exportovaného XML z Borlandu Together na XML pro systém VRECKO. <xsl:for-each select="//UML:ActionState"> <xsl:sort select="@xmi.id"/> <xsl:variable name="id"> <xsl:value-of select="@xmi.id" /> <EnvironmentObject> <xsl:value-of select="$id"/> <xsl:value-of select="@name"/> <xsl:value-of select="//Foundation.Core.ModelElement[@xmi.idref=$id]/par ent::*/parent::*/@geometry"/> DiagramItem BusinessProcess <Parameters> <xsl:value-of select="@name"/> activity <xsl:value-of select="//UML:ActivityGraph.partition//Foundation.C ore.ModelElement[@xmi.idref=$id]/parent::*/parent::*/@xmi.id"/>
31
Zdrojový kód 6.1: Výstřižek XSLT
Po aplikaci XSLT je potřeba upravit hodnoty některých uzlů. Konvertor začne obarvením elementů diagramu dle jejich plavecké dráhy (Zdrojový kód 6.2). //item colors according to partitions ArrayList c = new ArrayList(); c.add("0.8 0.0 0.0"); c.add("0.0 0.8 0.0"); c.add("0.0 0.0 0.8"); c.add("0.8 0.0 0.8"); c.add("0.8 0.8 0.0"); c.add("0.0 0.8 0.8"); c.add("0.4 0.0 0.0"); c.add("0.0 0.4 0.0"); c.add("0.0 0.0 0.4"); c.add("0.4 0.4 0.0"); ArrayList partitions = new ArrayList(); String p_id=""; NodeList colors = (NodeList) p.evaluate("//ItemColor", doc, XPathConstants.NODESET); for(int i = 0; i < colors.getLength(); i++){ p_id = colors.item(i).getTextContent(); if(!partitions.contains(p_id)){ partitions.add(p_id); } colors.item(i).setTextContent((String)c.get(partitions.indexOf(p_id))); } Zdrojový kód 6.2: Výstřižek z metody compile() objektu Convertor
Pak následuje upravení hodnot transformací a nakonec upravení identifikátorů objektů. Kompletní zdrojový kód naleznete na přiloženém CD.
6.4 Použití konvertoru Konvertor je postaven na přehledném uživatelském prostředí, které je celé v anglickém jazyce. Nejprve je potřeba v horním menu hlavního okna aplikace (Obrázek 7.2) vybrat záložku Tools a následně nástroj Options. Tím se nám spustí nové okno (Obrázek 7.3), kde nastavíme potřebné přístupové cesty k XML schématům a šabloně XSLT. Změny potvrdíme tlačítkem Save, čímž je 32
konvertor připraven k použití. V hlavním okně vybíráme vstupní XML reprezentující 2D diagram a cestu výstupního XML, kam se uloží 3D diagram pro systém VRECKO.
Obrázek 6.2: GUI konvertoru T2V
Obrázek 6.3: GUI konvertoru T2V
33
Kapitola 7
Závěr Zásuvný modul AP_BusinessProcess je vhodným podkladem pro další vývoj modelování procesních diagramů ve virtuální realitě. Ukazuje, jak je možné ve virtuálním světě graficky vizualizovat procesní diagramy a obsluhující uživatelské menu. Nabízí několik základních nástrojů, které odhalují modelování 3D diagramů pomocí pohybů a pokynů lidských rukou. Konvertor T2V umožňuje vizualizaci společně s editací již hotových a rozsáhlých 2D diagramů, čímž usnadňuje případný přechod k modelování 3D diagramů. Přechod od ovládání aplikace pomocí klávesnice a myši k ovládání nástrojů lidskýma rukama ve volném prostoru dle mých zkušeností přivádí uživateli větší volnost a kreativitu. Dále modelování firemního procesu ve virtuálním světě přináší vyšší úroveň vnoření uživatele do požadované činnosti. Ve virtuální realitě si v blízké budoucnosti bude možné v celém týmu vyměňovat názory či analytické představy řešení problému. Žádnou roli nebude hrát to, zda jednotliví účastníci jednání pobývají právě v kanceláři, u moře nebo v letadle. S rychlostí dnešního vývoje počítačového hardwaru je nevyhnutelné postupné rozšíření virtuální reality, časem klesnou nákupní ceny potřebných komponentů a tím se zvýší dostupnost a zájem lidstva o virtuální realitu. Už dnes je kromě zábavných atrakcí a herních center mnoho dalších zajímavých využití, např. ve zdravotnictví simulace operací výukového charakteru nebo léčení různých fobií (z výšek, z pavouků, apod.). I modelování procesních diagramů ve virtuální realitě má tedy naději, že bude rozšířeno a jeho použití ve virtuálním světě najde oblibu u mnoha uživatelů. Tato práce rozšířila mé vědomosti v mnoha oblastech témat informatiky. I přes občasnou kritiku procesního řízení firmy si jsem jistý, že jeho aplikace v praxi chodu firmy pomůže. Možnost přehledného dohledu nad realizací cílů musí vést ke snadnějšímu řízení firmy a vyhnutí se zbytečným ztrátám. Hlubší zkoumání a poznání virtuální reality mi odhalilo nové nabídky informačních technologií. Moderní značkovací jazyky mi dokázaly svou sílu a širokou možnost uplatnění. Vyzkoušel a osvojil jsem si objektové programování aplikací v jazyce C++ a jazyce JAVA. Během celé práce jsem získal mnoho zkušeností, které jsou velmi přínosné pro můj další osobní rozvoj.
34
Literatura [1] Jaroslav Ráček: Procesní řízení [výukový materiál], Fakutla Informatiky Masarykovy University, [2] The Workflow Managment Coalition, [3] Jan Flasar: Interaction Techniques in Non-Immersive Virtual Environment [diplomová práce], Fakutla Informatiky Masarykovy University, 2005, [4] Filip Dostál: Modelování povrchů ve VR [diplomová práce], Fakutla Informatiky Masarykovy University, 2006, [5] Pavel Černohorský: GUI pro systém VRECKO [bakalářská práce], Fakutla Informatiky Masarykovy University, 2006, [6] Jan Flasar: VRECKO Documentation, Human-Computer Interaction Laboratory, 2006, . [7] OpenSceneGraph, [8] Moderní značkovací jazyky, [9] ZVON.org, [10] Wikipedia, [11] JAVA, [12] dom4j, [13] Carda, A.: Workflow : Nástroj manažera pro řízení podnikových procesů, 2003 [14] Carda, A.: Workflow : Řízení firemních procesů, 2001 [15] Žára, J. a Beneš, B. a Sochor, J. a Felkel, P.: Moderní počítačová grafika, 2004, Computer press
35
Příloha A
Použitý software VRECKO Microsoft Visual Studio C++ Java Runtime Environment (JRE) 1.3.0_02 Netbeans IDE 5.5 Borland Together 6.0 Business Process Visual ARCHITECT Rhinoceros 3D OpenOffice 2.1
36
Příloha B
Obsah přiloženého CD Plugin AP_BusinessProcess - zdrojový kód programu - testovací souboru pod systém VRECKO - ukázkové procesní diagramy uložené v XML - 3D objekty elementů diagramu ve formátu Wavefront - vyfocené scény ukázkového 3D modelu procesu Konvertor T2V - zdrojový kód programu - XSLT podporující standard UML 1.3 a XMI 1.3 - potřebné knihovny pro spuštění (*.jar) 2D model ukázkového procesního diagramu - ve formátu programu Borland Together - ve formátu JPG - exportované XML dle různých standardů Elektronická podoba této práce - formát PDF - formát programu OpenOffice Writer
37
