ČESKÉ VYSOKÉ U ČENÍ TECHNICKÉ V PRAZE
FAKULTA ELEKTROTECHNICKÁ
Katedra řídicí techniky
Diplomová práce Editor pro Stochastické Petriho sít ě na WWW pomocí Java technologií
MARTIN ŠREMER
Vedoucí práce: Ing. Josef Čapek, Ph.D. Praha, 2006
Abstrakt
Tato práce pojednává o návrhu a implementaci obecného editoru graf ů pro WWW a jeho specializaci na Stochastické časované Petriho sít ě. Typ editovaného grafu, styl zobrazení a datový formát pro jeho perzistentní uložení definuje až uživatel pomocí XML dokumentu. Editor umož ňuje nadefinovat libovolný po čet typ ů vrchol ů, hran a na n ě navázaných informací databázového charakteru (tzv. vlastnosti). Zárove ň uživatel předepíše tvary použité pro zobrazení vrchol ů, typ k řivek p ředstavujících hrany a zp ůsob zobrazení vlastností. Editovaný graf je ukládán nebo na čítán z nebo do XML dokumentu, jeho strukturu se editor „nau čí“ z Relax NG schématu. To je základem výše zmín ěného XML dokumentu, z něhož jsou na čteny definice typu grafu. Obecnost editoru je demonstrována na Petriho sítích a grafu p ředstavujícího rodokmen. Pro implementaci byla zvolena Java. Program m ůže být vložen do HTML stránky jako Java applet i používán jako desktopová aplikace. Editor si m ůžete stáhnout a nebo p římo vyzkoušet na WWW adrese:
Abstract
This thesis deals with design and implementation of general (vertices-edges) graph editor for use on WWW and its specialization in Stochastic timed Petri nets. The type of edited graph, the style of graphic representation and the data format for its persistent store defines user himself per XML document. The graph editor enables to define arbitrary number of vertices types, edges and to them linked informations of database character (so- called properties of object). At the same time user prescribes the shapes used for representation of vertices, the type of curves representing edges and the method of properties representation. Edited graph is saved or loaded from or to XML document and graph editor “learns” its structure from Relax NG schema. It is the base of above mentioned XML document, from which are counted the definitions of graph type. General behaviours of the editor are demonstrated on Petri nets and graph representing genealogy.The application was implemented in Java. The program can be inserted into HTML page as the Java applet and used as a desktop application. The graph editor is possible to try or download on WWW address:
2
3 Prohlášení
Prohlašuji, že jsem svou diplomovou práci vypracoval samostatn ě a použil jsem pouze podklady (literaturu, projekty, SW atd.) uvedené v přiloženém seznamu.
V Praze dne 26. 5. 2006 ………………………………. podpis
4 Pod ěkování
Na tomto míst ě bych rád pod ěkoval vedoucímu práce Ing. Josefu Čapkovi, Ph.D. za cenné p řipomínky, pomoc p ři řešení problém ů, nezm ěrnou trp ělivost, inspiraci a čtení tohoto textu. Kolegovi Tomáši Ivánkovi, který pracuje na podobném projektu založeném na DHTML, PHP a JS, za p řínosné diskuze. A v neposlední řad ě rodin ě, jež m ě p ři práci podporovala.
5
Obsah
Úvod ...... 8
1 Použité technologie...... 10 1.1 Java...... 10 1.2 XML ...... 11 1.2.1 Základní názvosloví...... 11 1.2.2 Relax NG...... 12 1.2.3 XSL Transformace ...... 14 2 Realizace editoru ...... 15 2.1 Základní koncepce...... 15 2.1.1 Požadavky...... 15 2.1.2 Implementace...... 16 2.1.3 Architektura...... 16 2.1.4 Zajišt ění obecnosti editoru...... 17 2.2 Hlavní komponenty ...... 19 2.2.1 Hlavní okno ...... 19 2.2.2 Interní editovací okno...... 20 2.2.3 Kreslící komponenta...... 21 2.2.4 Uložišt ě grafických objekt ů...... 22 2.2.5 Obecný editovací dialog...... 24 2.3 Objekty grafu...... 26 2.3.1 Základní rozhraní objekt ů grafu ...... 26 2.3.2 Abstraktní p ředek objekt ů grafu...... 29 2.3.3 Spole čný p ředek vrchol ů a hran ...... 30 2.3.4 Vrchol...... 31 2.3.4.1 Abstraktní vrchol...... 31 2.3.4.2 Obecný vrchol...... 32 2.3.5 Hrana ...... 34 2.3.5.1 Abstraktní p ředek hran ...... 34 2.3.5.2 Jednoduchá hrana ...... 36 2.3.5.3 Zaoblená hrana ...... 37 2.3.6 Uživatelské vlastnosti...... 38 2.3.6.1 Jednoduchá vlastnost...... 38 2.3.6.2 Monitorovatelná vlastnost ...... 38 2.3.6.3 Editovatelná vlastnost...... 39 2.3.6.4 Textová vlastnost...... 39 2.3.6.5 Číselná vlastnost...... 40 2.3.6.6 Vlastnost barva ...... 40 2.3.6.7 Výb ěrová vlastnost ...... 40 2.3.7 Grafické vlastnosti...... 41 2.3.7.1 Tah čáry a výpl ň ...... 41 2.3.7.2 Font...... 42 2.3.7.3 Rodina písma...... 43 2.3.7.4 Sou řadnice pozice...... 44
6 2.3.7.5 Nato čení objektu...... 44 2.3.7.6 ID objektu...... 44 2.3.7.7 Jméno a verze editoru...... 45 2.3.8 Po čátek grafu ...... 45 2.3.9 Vykreslova č vlastností...... 45 2.3.9.1 Abstraktní vykreslova č...... 45 2.3.9.2 Vykreslova č textu...... 46 2.3.10 Výb ěr hran a vrchol ů ...... 49 3 Propojení s XML ...... 50 3.1 Podp ůrné definice...... 50 3.1.1 Základní koncepce...... 50 3.1.2 Po čátek grafu ...... 51 3.1.3 Element vrcholu...... 53 3.1.4 Skin vrcholu...... 55 3.1.5 Vyzna čení hrany...... 61 3.1.6 Jednoduché vlastnosti...... 63 3.1.7 Skupinová výb ěrová vlastnost...... 69 3.1.8 Grafické vlastnosti...... 71 3.2 Na čtení podp ůrných definic...... 73 3.3 Uložení dokumentu grafu...... 78 3.4 Načtení dokumentu grafu ...... 80 4 Specializace na Petriho sít ě ...... 83 4.1 Petriho sít ě ...... 83 4.1.1 Základní pojmy...... 83 4.1.2 Petriho sít ě s časovanými p řechody...... 84 4.1.3 Stochastické Petriho sít ě...... 85 4.1.4 Stochastické časované Petriho sít ě ...... 85 4.2 PNML, PNDT...... 86 4.2.1 Základní pojmy...... 86 4.2.2 Základní PNTD...... 87 4.3 StochPNTD...... 90 4.3.1 Vznik ...... 90 4.3.2 Dodefinované vlastnosti...... 90 4.4 Podp ůrné definice pro STPN...... 92 4.4.1 Prvky grafu...... 92 5 Specializace na rodokmen ...... 94 6 Záv ěr...... 96 7 Použité zdroje ...... 98 8 Seznam použitého SW...... 100 8.1 Knihovny p římo obsažené v editoru...... 100 8.2 SW použité pro vývoj editoru...... 100 8.3 Ostatní software...... 100 9 Seznam použitých zkratek...... 102 10 Přílohy ...... 103 10.1 Obsah p řiloženého CD...... 103 10.2 Souhrn vlastností n ěkterých editor ů ...... 104 10.3 XSL transformace pro odstran ění vno řených dokument ů v RNG ...... 106 10.4 XSL transformace pro odstran ění referencí v RNG ...... 108
7 Úvod
Pro člov ěka nejp řirozen ějšími zp ůsoby zachycení nebo vyjád ření myšlenek je mluvené nebo psané slovo spolu s obrázky. P řitom n ěkdy i pom ěrn ě jednoduchý obrázek dokáže nahradit složitý popis a pokud je vhodn ě vyhotoven, je doba pro jeho pochopení n ěkolikrát menší, než v případ ě psaného slova. Speciálním druhem obrázku je grafické vyjád ření grafu chápaného jako množina vrchol ů a hran, které je propojují. Grafy našly uplatn ění v mnoha vědních oborech, p ředevším v technických. Vhodné a hojn ě používané jsou p ři modelování r ůzných systém ů, proces ů a jejich simulací. Kde jejich grafická reprezentace usnad ňuje modelování, d ělá model p řehledným a pokud je používáno kvalitních nástroj ů tak i snadno udržovatelným. Cílem této práce je navrhnout a vytvo řit editor graf ů, který bude podporovat ur čitou skupinu graf ů. Jak bude široká nebylo p řesn ě stanoveno, minimáln ě však musí editor umož ňovat vytvá ření a editaci Stochastických časovaných Petriho sítí (STPN), což je zjednodušen ě aparát vhodný pro modelování a simulace diskrétních systém ů. P ůvodn ě m ěl editor být specializovaný pouze na tento druh Petriho sítí. Jedním z požadavk ů byla možnost p řidání či zm ěny atribut ů (informací databázového charakteru) navázaných na vrcholy a hrany Petriho sít ě bez zásahu do programového kódu. Druhým d ůležitým požadavkem bylo perzistentní ukládání sít ě v nějakém standardním formátu. Pro jednoduché (autonomní) Petriho sít ě existuje dnes již standardizovaný formát založený na XML a nazvaný PNML. V dob ě, kdy jsem ješt ě p řemýšlel, jak v ůbec práci zapo čít, to byl jen návrh na ISO normu. Hrozily tak budoucí zm ěny. Horší však bylo, že neexistoval žádný standard nebo alespo ň majoritn ě užívaný formát pro uložení a vým ěnu STPN. Rozhodl jsem se, že nadefinuji vlastní založený na PNML, ale editor na n ěj „neuvážu“ a dám možnost uživateli říci, jak má být editovaný graf uložen do XML dokumentu. Jinak řečeno až za b ěhu programu bude známo jakou má strukturu XML dokument pro uložení a na čtení grafu. Sou časn ě jsem zobecnil požadavek na definování atribut ů vrchol ů a hran, čímž vznikl nový a to takový, že bude umožn ěno definovat libovolný po čet vrchol ů a hran, jejich grafická podoba a libovolný po čet informací databázového charakteru na ně navázaných. Souhrnn ě lze říci, že editor sám o sob ě nebude p říliš „v ědět“ co d ělat, nau čí se to až z nějakého popisu „sv ěta“ jednoho typu grafu, který mu poskytne uživatel. Editor by m ěl umožňovat provoz na WWW. Tento cíl je vyvozen z představy, že editor naváže na [SW 9], kterému bude poskytovat podklady pro simulaci. Osobn ě ho však vidím jako menší prioritu než výše zmín ěné cíle. Dalšími hrub ě stanovenými cíly je uživatelsky p říjemný a propracovaný systém pro zm ěnu pohledu na graf, možnost definovat tvar vrcholu co možná nejobecn ěji, minimáln ě tak, že si ho uživatel složí z primitivních geometrických prvk ů, možnost umís ťování objektů do striktn ě pevného rastru, export grafu beze ztráty kvality ve vektorovém formátu a precizní vykreslování tvar ů tak, aby se výstup z editoru dal použít v tišt ěných
8 dokumentech. Tyto cíle jsem stanovil na základ ě vyzkoušení n ěkolika editor ů (viz 10.2), které umož ňují do jisté míry zvolit typ editovaného grafu a to p ředevším podle toho, co se mi nejvíce nelíbilo. Na druhou stranu m ě n ěco zaujalo a nechal jsem se inspirovat. Nenašel jsem žádný editor, který by umož ňoval definovat i formát pro perzistentní ukládání grafu. Nejpropracovan ější je MS Visio 2003 [SW 13], který je p ředevším skloubením p říjemného uživatelského rozhraní a funk čnosti. Celý text této práce je rozd ělen do šesti částí. První obsahuje stru čný popis používaných technologií, druhá pojednává o realizaci editoru, v návaznosti na ni t řetí popisuje zp ůsob na čtení typu editoru z XML a uložení resp. na čtení dokumentu grafu. Čtvrtá obsahuje popis formátu pro uložení Stochastických časovaných sítí a specializaci editoru na n ě. Předposlední krátce demonstruje specializaci na editování rodokmenu. Poslední je záv ěrem, v němž jsem shrnul čeho bylo dosaženo a jak by se dalo a bylo by vhodné pokra čovat ve vývoji editoru.
9 1 Použité technologie
1.1 Java Java je programovací jazyk vyvinutý spole čností Sun. Její syntaxe je odvozena od C++. Podle spole čnosti Sun je Java: „jednoduché, robustní, objektov ě orientované na platform ě nezávislé vícevláknové, dynamické univerzální programovací prost ředí“. Pozoruhodnou skute čností je, že se Java uplatnila v tak širokém spektru aplikací. Lze ji najít jak ve velkém http serveru tak nap ř. v mobilním telefonu. Toto rozší ření je zp ůsobeno tím, že je Java nezávislá na platform ě. Jedná se o interpretovaný jazyk, který zjednodušen ě zpracovává interpret obsažený ve virtuálním stroji. Architektura Javy zajiš ťuje odstín ění od konkrétního opera čního systému a tak i od hardware. Skládá se z těchto sou částí: Programovacího jazyku Java. Formátu souboru .class . Aplika čního programového rozhraní Javy (API). Virtuální stroje Javy (JVM, Java Virtual Machine). Pro spušt ění programu vytvo řeného v Jav ě je nutné mít nainstalované prost ředí pro její zpracování JRE (Java Runtime Enviroment), které obsahuje aplika ční rozhraní Javy a virtuální stroj. JRE je v závislosti na tom jaké obsahuje aplika ční rozhraní ší řeno ve t řech balících, kterým se říká platformy: Java 2 Platform, Standard Edition (J2SE). Obsahuje základní sadu t říd jazyku Java a třídy pot řebné pro tvorbu grafického uživatelského rozhraní (GUI). V dnešní dob ě Java poskytuje dv ě knihovny pro tvorbu GUI. Starší AWT a nov ější Swing. Java 2 Platform, Enterprise Edition (J2EE). Tato platforma je ur čena p ředevším pro web servery. Obsahuje nástroje pro vytvá ření servlet ů, JSP (Java Server Pages, dynamicky generované stránky, obdoba PHP) a objekt ů EJB (Enterprise JavaBeans). Java 2 Platform, Micro Edition . Obsahuje t řídy a nástroje pro vývoj programového vybavení pro mobilní za řízení, spot řební elektroniku a systémy v automobilovém pr ůmysl. Bezesporu nejv ětší výhodou Javy je její nezávislost na platform ě. Další výhody shrnu do n ěkolika bod ů:
10 Bezpe čnost. P ři vývoji Javy kladli auto ři velký d ůraz na bezpe čnosti, která je podpo řena tím, že je Java interpretovaný jazyk. Distribuované objekty. Java platforma obsahuje prost ředky pro psaní distribuovaných objekt ů a to s důrazem na maximální jednoduchost. Podpora Internetu. Java platforma má vestav ěnu podporu TCP/IP protokolu. Pokud nap ř. vyvstane požadavek na číst soubor z webového serveru je možné to provést tém ěř stejn ě jako na číst soubor z lokálního systému soubor ů. Možnost vytvá řet Java applety. Applet je program založený na t říd ě JApplet (nebo Applet), který lze vložit do WWW stránky. Je to elegantní cesta jak poskytnout uživateli aplikaci bez toho, aby si ji musel instalovat. Dobrá produktivita. Java řeší za programátora velké množství problému a je navržena tak, aby mu maximáln ě podpo řila produktivitu práce. Zavedení konvencí psaní zdrojového kódu. Velkou výhodou je zavedení styl jak se mají jmenovat t řídy, atributy, lokální prom ěnné atp. Zárove ň velká popisná hodnota názv ů t říd z knihoven Java platformy šet ří čas a umož ňuje si identifikátory lépe pamatovat. Oproti nap ř. C/C++, kde se hodn ě užívá zkratek. Existence velkého množství knihoven. Java je mezi programátory hodn ě rozší řena a tak existuje velké množství voln ě dostupných knihoven. V žádném jiném programovacím jazyce asi neexistuje tak široká podpora zpracování XML. Mezi hlavní nevýhody Javy pat ří p ředevším menší rychlost než provád ění nativního kódu a také je často kritizována knihovna Swing pro tvorbu GUI. Poskytuje sice hodn ě zajímavých funkcí, ale je pomalá a příliš složitá. Více o jazyku Java lze najít v [13], [14] a [15].
1.2 XML 1.2.1 Základní názvosloví XML je (eXtensible Markup Language) je zna čkovací jazyk čitelný pro člov ěka a nezávislý na platform ě. Vznikl z obecn ějšího SGML (Standard Generalized Markup Language). Specifikaci XML udržuje organizace W3C. Více o historii atp. je v [4]. Hlavní rysy XML jsou: XML je rozši řitelný jazyk. Z jiného pohledu specifikace XML říká jaké zásady mají být dodrženy p ři tvorb ě, ne říká nic o tom co bude p řesn ě uloženo a jak. Mezinárodní podpora. M ůžeme nadefinovat kódování dokumentu. Implicitn ě je použito Unicode. Možnost konverze do jiných formát ů a nebo jen zm ěna struktury dokumentu pomocí XSL transformace. Je považováno za standard. Existuje široká nabídka knihoven pro programové zpracování XML. V podstat ě se d ělí na SAX (Simple API for XML) a DOM (Document Object Model). SAX je parser, který na čítá části dokumentu a podle nich vyvolává události. P řístupy založené na modelu DOM vytvá řejí strom objekt ů podle obsahu XML dokument.
11 Je možné ov ěř it správnost (validnost) dokumentu za použití standardních nástroj ů (validátor ů). XML dokument se skládá z element ů a atribut ů (Obrázek 1.1). Atribut je atomický tj. dále ned ělitelný a obsahuje n ějakou hodnotu. Element m ůže obsahovat n ěkolik atribut ů, element ů a hodnoty. V dokumentu je zapsán jako zna čka jejíž jméno je vloženo do znaku „<“ a „>“. Tyto zna čky existují dv ě. Tzv. po čáte ční a koncový tag. Pokud je element prázdný je povolen zkrácený zápis bez koncového tagu. Na po čátku dokumentu je definováno jeho kódování a verze XML. První element (
Obrázek 1.1 Jednoduchý XML dokument s popisem jednotlivých částí.
1.2.2 Relax NG Relax NG je XML dokument pomocí n ěhož je standardizovaným zp ůsobem popsána struktura XML dokumentu. Pro definice základních datových typ ů RNG využívá knihovnu WXS [3].V následující části krátce popíšu n ěkolik základních element ů RNG. Není to vyčerpávající p řehled. Více lze najít v knize [2], u čebnici plné p říklad ů [5] a specifikaci od autora [1].
Definice elementu Element je definován elementem
12 Výpis 1.1 RNG definice prázdného elementu a obsahujícího text.
Pokud má element obsahovat další elementy jednoduše definice vno říme do sebe. Přitom záleží na jejich po řadí (Výpis 1.2).
Výpis 1.2 Definice vno řených element ů.
Definice atributu Atribut elementu definuje element
Výpis 1.3 Definice atributu elementu.
Další datové typy Jako další datové typy lze použít element s atributem type, který svou hodnotou ur čí datový typ. Základní jsou: decimal , integer , int , double , float , byte , string , boolean (podrobn ě v [3] nebo [5]). Výb ěr z několika hodnot je možné p ředepsat pomocí
Výpis 1.4 Definice výb ěrové hodnoty, (A) i (B) vyhovují p ředpisu, (C) nevyhovuje.
13 Výb ěr vzoru Pomocí elementu
Výpis 1.5 Volba mezi elementem, skupinou dvou elementu a atributem. Všechny XML elementy (A), (B), (C) definici vyhovují.
Volitelnost vzoru Volitelnost vzoru je definována elementem
Kvantifikace vzoru Ur čení po čtu opakování vzoru (nap ř. elementu) ur čuje element
Výpis 1.6 Ur čení po čtu opakování vzoru, (A) i (B) vyhovují.
1.2.3 XSL Transformace XSL transformace je XML dokument, který p ředepisuje šablony pro zm ěnu struktury XML dokumentu na jiný a nebo i do jiného formátu nap ř. prostého textu. Samotný p řevod provádí XSLT Procesor. Více lze najít v on-line u čebnici [6].
14 2 Realizace editoru
2.1 Základní koncepce 2.1.1 Požadavky Hlavním požadavkem na editor je možnost m ěnit strukturu, grafickou reprezentaci a datový formát pro perzistentní uložení grafu. Realizaci editoru p ředcházela analýza řešené problematiky a diskuse s vedoucím práce, z čehož vyplynulo n ěkolik základních požadavk ů. Jejich spln ění je cílem této práce. Souhrnem se jedná o: Obecnost editoru. Klí čovým požadavkem je podpora co nejširší škály graf ů bez nutnosti zasahovat do programového kódu editoru. Až uživatel ur čí strukturu grafu, jaké typy vrchol ů a hran bude obsahovat, jak budou zobrazeny a jaké informace databázového charakteru na n ě budou navázány. Variabilnost datového formátu grafu. Stejn ě jako typ editovaného grafu uživatel specifikuje datový formát pro jeho perzistentní uložení. Aby byl požadavek splnitelný byly datové formáty omezeny na ty, které jsou založené na XML. Rozši řitelnost. Návrh editoru a jeho implementace by m ěla umož ňovat snadné přidání nové funkcionality bez nutnosti rozsáhlých změn souvisejícího okolí. Nap ř. přidání hrany vykreslené zatím nepodporovaným typem křivky by se m ělo obejít bez zásahu do implementace vrcholu, plátna atp. Nezávislost na platform ě. Editor by nem ěl být vázán na jeden opera ční systém nebo hardwarové vybavení cílového PC. Možnost provozu na WWW. Implementace editoru a zvolené technologie by měly umožnit editor spoušt ět bez nutnosti instalace, nejlépe tak aby s ním uživatel mohl pracovat p římo ve WWW prohlíže či . Ergonomie. Grafické uživatelské rozhraní (GUI) editoru má být co možná nejjednodušší, aby se ho uživatel nau čil snadno ovládat a za krátkou dobu s ním dokázal efektivn ě pracovat. Zvýšená pozornost má být v ěnována komfortu nastavení pohledu na editovaný graf, což je u podobného software často opomíjeno. Kvalitní grafická reprezentace grafu. Editor by měl podpo řit uživatele ve vytváření esteticky kvalitních graf ů, k čemuž je nutný precizní výpo čet jeho geometrie, volba vhodného renderování a možnost exportu grafu minimáln ě v jednom vektorovém a jednom rastrovém grafickém formátu beze ztráty kvality a bez zkreslení.
15 2.1.2 Implementace Pro realizaci editoru byl zvolen programovací jazyk Java verze 1.5, p řičemž je editor realizován jako applet. Jedním z požadavk ů na editor kladených je provoz na WWW. V základu existují dv ě strategie. Bu ď použít DHTML a JavaScript se silnou podporou na stran ě serveru anebo editor pomocí Internetu ší řit s tím, že jeho kód bude vykonán na cílovém stroji, což lze realizovat nap ř. jako Java applet nebo pomocí technologie ActiveX. Zvolena byla druhá možnost a to p ředevším proto, že aplikace založené na DHTML poskytují velice špatný aparát pro vytvo ření interaktivních grafických aplikací, které by funk čně dosahovaly kvalit desktopových. Dále je nelze použít bez p řístupu na Internet, v případ ě grafické aplikace vznikají problémy s výkonem 1 a v neposlední řad ě je jejich vývoj mnohem náro čnější (špatné možnosti lad ění, r ůzné chování prohlíže čů ). Oproti tomu technologie ActiveX nebo Java applet umož ňují program vytvo řit tém ěř se stejným komfortem a funkcionalitou jako klasickou desktopovou aplikaci a přitom je lze snadno poskytnout uživateli (bez nutnosti instalace). Nakonec bylo rozhodnuto, že bude editor realizován jako Java applet. A to p ředevším z těchto d ůvod ů: Podpora na hodn ě platformách (Windows, Linux, Solaris, Mac OS X, ...). Sta čí aby byl na cílovém po číta či nainstalován virtuální stroj jazyka Java (JVM), WWW prohlíže č s plug-inem. Není nutné applet nijak registrovat jako ActiveX komponenty. Lze pom ěrn ě jednoduše vytvo řit applet, který p ůjde použít jako klasická desktopová aplikace. Uživatelé mají v ětší d ůvěru v applety než v ActiveX komponenty. Existuje velké množství voln ě dostupných (neplacených) nástroj ů (IDE) pro vývoj aplikací v Jav ě a tak i applet ů. Hlavní nevýhodou applet ů oproti p řístupu založeném na DHTML je nutnost instalace virtuálního stroje na cílovém stroji a plug-inu do prohlíže če, nedůvěra v ně ze strany uživatel ů a pomalejší start aplikace. Pro b ěh editoru je vyžadován virtuální stroj (JVM) kompatibilní se specifikací Javy 1.5. Vývoj a testování jsem provád ěl na JVM od firmy Sun Microsystems ší řeného jako Java Development Kit (JDK) 2 ve verzích 1.5.0_1 až 1.5.0_6 na opera čním systému Windows 2000. P řitom jsem používal vývojové prost ředí Eclipse SDK 3 ve verzích 3.0 až 3.1. Po dokon čení v ětších celk ů jsem jejich funk čnost ov ěř oval ješt ě na opera čním systému Windows XP a Debian GNU/Linux 3.1 (taktéž s JVM od spole čnosti Sun). 2.1.3 Architektura Editor je tvo řen Java appletem, který je poskytnut uživateli bu ď jako sou část WWW stránky a nebo jako nezávislá aplikace. V prvním p řípad ě m ůže být na serveru umíst ěn libovolný po čet definic typ ů graf ů (tzv. podp ůrných definic, více v 2.1.4 a 3.1), jež si editor stáhne prost řednictvím http protokolu (Obrázek 2.1). Grafy jsou ukládány jako XML
1 Obvykle je editace grafické reprezentace informací pomocí DHTML provád ěna pomocí r ůzných manipulací s objekty (obrázky, texty, ...) v DOM, které zobrazuje WWW prohlíže č. Tyto operace jsou pom ěrn ě časov ě náro čné a při interaktivní zm ěně více jak cca 30 objekt ů sou časn ě dnešní prohlíže če (IE, Mozilla, Opera) p řestávají výkonov ě sta čit. 2 JVM spole čnosti Sun Microsystems je možné bezplatn ě získat pro r ůzné opera ční systémy na adrese http://java.sun.com/j2se/1.5.0/. 3 Domovská WWW stránka IDE Eclipse SDK je http://www.eclipse.org/eclipse/, kde je zdarma ke stažení.
16 dokumenty (soubory). V obou p řípadech provozu editoru je umožn ěno jejich ukládání nebo na čítání pouze z lokálního systému soubor ů, což applet nem ůže pokud není digitáln ě podepsán. To je nutnou, ne však posta čující podmínkou. Uživatel ješt ě musí potvrdit, že podepsanému appletu d ůvěř uje. Pokud tak neu činí nebude si moci uložit vytvo řené grafy ani je na číst.
Obrázek 2.1 Poskytnutí editoru uživateli a využívané zdroje pro na čínání nebo ukládání XML dokument ů.
Applet editoru je navržen tak, aby šlo v budoucnu použít i jiné zdroje dat než pouze lokální systém soubor ů. Je tak otev řena možnost v budoucnu rozší řit editor na systém s třívrstvou architekturou, kde by aplika ční server zajiš ťoval ukládání vytvo řených graf ů na vzdáleném stroji (serveru) a jejich vým ěnu mezi uživateli. Odstín ění od konkrétního zdroje je provedeno na dvou úrovních. První znamená používání datových proud ů pro čtení a zápis XML dokument ů. Je použita jak při práci s dokumenty graf ů, tak s dokumenty podp ůrných definic. Druhá úrove ň odstín ění jde dále a je použita pouze p ři ukládání nebo na čítání dokumentu grafu. Tyto operace jsou zast řešeny dv ěma objektovými třídami, které implementují ve řejné metody pro manipulaci a vyhledávání element ů, atribut ů a hodnot v dokumentu grafu. Zbytek programového kódu striktn ě p řistupuje k dokumentu pomocí nich a tak pokud by je n ěkdo p řekryl v odvozených t řídách, nemusely by se data v důsledku na čítat ani z XML dokumentu, ale nap ř. z rela ční databáze. Zmín ěné metody neprovádí triviální operace, umož ňují p řístup k částem dokumentu na vyšší úrovni pomocí XML cesty (více v oddílu 3.3 a 3.4) takže ješt ě navíc zamezují duplicit ě programového kódu. 2.1.4 Zajišt ění obecnosti editoru V dob ě p řekladu zdrojového kódu editoru není známo co p řesn ě bude vykreslovat a kam to uloží, to je zjišt ěno až za jeho b ěhu z tzv. podp ůrných definic. Ty jsou vytvo řeny uživatelem z plochého RNG schématu výstupního dokumentu grafu dopln ěním zna ček z pomocného prostoru jmen (Obrázek 2.2). Jedná se tedy o XML dokument, z něhož je na čten popis struktury grafu, typy a grafická reprezentace vrchol ů a hran a to kam do XML dokumentu grafu budou uloženy informace jež ho popisují (blíže v 3.1). Podle podp ůrných definic je vytvo řena šablona typu grafu. Pokud uživatel založí nový graf je vytvo řena její
17 přesná kopie 4, ve které kreslící komponenta (viz 2.2.3) na základ ě požadavk ů uživatele vytvo ří graf (Obrázek 2.3). Obdobn ě je postupováno p ři otvírání grafu. Je vytvo řen klon šablony a do n ěj na čteny údaje z XML dokumentu grafu. Šablon graf ů m ůže editor obsahovat n ěkolik, a je možné sou časn ě editovat n ěkolik graf ů z nich vytvo řených.
Výst. dokument XML (graf)
uložení nebo načtení grafu
XSLT Ploché Editor RNG procesor XML RNG
Relax NG schéma Uživatel Podpůrné editace grafu výst. dokumentu definice
Uživatel Obrázek 2.2 Specializace editoru na konkrétní typ grafu.
Šablona Kopie Kreslící XML typu grafu šablony komponenta
Podpůrné Založ nový definice graf. editace grafu
Uživatel Obrázek 2.3 Vytvo ření nového grafu podle šablony jeho typu.
Šablona typu grafu je uložišt ě grafických objekt ů (z 2.2.4) napln ěné pouze šablonami vrchol ů a hran, což jsou speciální instance objektových t říd (viz 2.3) reprezentujících prvky grafu. Šablony objekt ů grafu, tedy vrchol ů a hran, jsou vytvo řeny podle podp ůrných definic (3.2). Obsahují defaultní hodnoty konkrétních objekt ů, zp ůsob vykreslení a strom vlastností (viz 2.3.1), kterých existuje n ěkolik typ ů. Vlastnost je zjednodušen ě bu ď objekt obsahující n ějakou hodnotu, objekt obsahující n ěkolik vlastností anebo obsahující oboje. Jejím ú čelem je nést hodnotu popisující nad řazený objekt (nap ř. jméno vrcholu, jeho barvu, pozici) a nebo vyjad řovat jeho složit ější popis množinou vlastností (nap ř. adresa skládající se z ulice, m ěsta a čísla popisného). Nový graf je pouze kopie šablony jeho typu tj. také uložišt ě grafických objekt ů s šablonami objekt ů grafu. Pokud chce uživatel vložit nap ř. nový vrchol (nakreslit ho na plátno) vytvo ří uložišt ě grafických objekt ů klon šablony požadovaného typu vrcholu, nastaví mu nové ID, intern ě si ho zaregistruje a předá ho kreslící komponent ě, která vyzve uživatele k ur čení jeho polohy. Klonování šablony je zásadní operací a znamená vytvo ření její v ěrné kopie v četn ě kopie celého podstromu navázaných vlastností (blíže viz rozhraní TreeCloneable , 2.3.1). Obdobný princip je použit i při vytvá ření nové hrany.
4 Šablona je uložišt ě grafických objekt ů, kopie (klon) je vytvářena do hloubky, ale ne absolutní, vše co se p ři editaci grafu nem ění kopírováno není. Jedná se nap ř. o vzory tvar ů vrchol ů.
18
Obrázek 2.4 Vyložení nového vrcholu typu „p řechod“ do grafu, čísla v kroužcích zna čí po řadí akcí, (1) je požadavek uživatel vložit vrchol, ..., (5) je umíst ění vrcholu.
2.2 Hlavní komponenty 2.2.1 Hlavní okno Hlavní třída a zárove ň okno, chcete-li obrazovka, editoru jsou tvo řeny t řídou Main odvozenou od JApplet 5. Program je možné spoušt ět i jako desktopovou aplikaci. Její GUI 6 je založeno na knihovn ě Swing standardn ě dodávané s Java platformou, veškerý popis ovládacích prvk ů atp. je umíst ěn mimo zdrojový kód pro možnost snadné lokalizace. Základní návrh uživatelského rozhraní je založen na MDI tj. možnosti mít zárove ň otev řeno n ěkolik dokument ů graf ů (Obrázek 2.5). P řitom je možné v jeden okamžik editovat pouze graf v aktivním vnit řním okn ě tvo řeném t řídou EditorFrame . Její metody pro manipulaci s grafem a zm ěnu pohledu na n ěj jsou volány v poslucha čích událostí generovaných instancemi JMenuAction , přiřazených tla čítk ům (ikonkám) z panel ů nástroj ů, položkám v menu a globálním klávesovým zkratkám. Zárove ň je se stavem aktivního interního okna synchronizován spodní informa ční panel. Třída Main má ve své kompetenci p řenesen ě správu šablon typ ů graf ů (z 2.1.4). Přímo jsou obsaženy v instanci t řídy GraphTemplates , která umož ňuje jejich p řidávání, mazaní, na čítání z podp ůrných definic (viz 3.2), vyhledání podle popisu typu grafu (viz 3.3) a klonování. Mimo toho, že uživatel na čte podp ůrné definice ze souboru jsou na čítány ješt ě ze zdroj ů: Z JAR archivu aplikace ihned po jejím startu. Přitom je seznam soubor ů s podp ůrnými definicemi umíst ěn také v JAR archivu na cest ě vspne/client/res jako textový soubor internalGraphTypes . Jeho každý řádek bu ď za číná znakem „#“ a pak je chápán jako komentá ř a nebo je na n ěm uvedena cesta k souboru podpůrných definic. Pokud je editor spušt ěn jako desktopová aplikace jsou na čteny podp ůrné definice z cest (nebo URL) p ředaných jako její parametry odd ělené mezerami.
5 JApplet je t řída z knihovny Java platformy. 6 Graphical User Interface neboli grafické uživatelské rozhraní.
19 Pokud je editor spušt ěn jako applet integrovaný do HTML stránky jsou na čteny podp ůrné definice z adres p ředaných v parametrech appletu. Ty jsou obsaženy v elementu
Obrázek 2.5 Hlavní okno editoru, (1) neaktivní vnitřní okno, (2) aktivní vnit řní okno, (3) informa ční panel, (4) panely nástroj ů, (5) menu aplikace.
Na čítání dokument ů graf ů t řída Main provádí vytvo řením nové instance t řídy DocumentReader . Dle jeho prvotní analýzy nalezne p říslušnou šablonu grafu, nebo vyzve uživatele k na čtení odpovídajících podp ůrných definic. Do klonu šablony nechá na číst objektem typu DocumentReader graf, jež je poté zobrazen v novém interním oknu (podrobnosti viz 3.2). 2.2.2 Interní editovací okno Zobrazení vnit řního okna jednoho editovaného grafu, jeho uložení a export zajiš ťuje třída EditorFrame . Její GUI se skládá pouze z kreslící komponenty (plátna) tvo řené t řídou VSPNECanvas (viz 2.2.3), která v sou činnosti s uložišt ěm grafických objekt ů provádí samotnou editaci. Uložení grafu realizuje t řída DocumentWriter po p ředání výstupního datového proudu a uložišt ě grafických objekt ů (t řída Graph ). Export grafu do vektorového a nebo grafického formátu je realizován pomocí balí čku Vector Graphics z FreeHEP 7 knihovny. Její použití je triviální sta čí vytvo řit instanci
7 Free HEP knihovna sdílí zdrojové kódy pro použití ve fyzice vysokých energií, je ší řena pod licencí LGPL jako Open source. Její část Vector Graphics je obsažena na p řiloženém CD. Dostupná je z WWW adresy http://java.freehep.org/vectorgraphics/.
20 dialogu pro export a předat mu referenci na komponentu vykreslující exportovaný obrázek. Přesto, že podporováno velké množství grafických formát ů (jpg, png, emf, pdf, eps, cgm, svg, raw a další) je nejkvalitn ější export do Windows Enhanced Metafile (emf), neboť je převod až na „ostrá“ napojení r ůzných segment ů p řesný. Zápis pdf, eps a svg v případ ě editoru produkuje obrázky bez textu. P říkladem vyexportovaných graf ů do emf je Obrázek 5.2 nebo Obrázek 4.8. 2.2.3 Kreslící komponenta Zobrazení grafu a jeho interaktivní editaci zajiš ťuje ve spolupráci s uložišt ěm grafických objekt ů kreslící komponenta (plátno). Její t řída VSPNECanvas je odvozena od JComponent z knihovny Swing . Graf je renderován do skrytého obrázku (bufferu), který je poté vykreslen na obrazovku (jedná se o tzv. double buffering). Je tak zamezeno blikání obrazu vznikajícího v důsledku dlouhé doby pot řebné pro vytvo ření rastrové podoby tvar ů, z nichž je graf složen. A není t řeba provád ět renderování p ři každém p řekreslení komponenty. Pokud dojde ke zm ěně grafu je vytvo řena rastrová podoba do bufferu a ta do příští zm ěny vykreslována. Komponenta umož ňuje m ěnit pohled na graf. P řitom se nem ění pozice a geometrické rozm ěry objekt ů tvo řících graf, ale p ři každém vykreslení jsou jejich logické sou řadnice transformovány do sou řadného systému cílového za řízení (obrazovky). Transformace je provád ěna podle afinní transformace kontextem za řízení ( Graphics2D z knihoven Javy) pracujícím nad skrytým bufferem. Ten také zajistí vyrenderování primitivních geometrických prvk ů. Výhodou tohoto postupu je izolace implementace do jedné t řídy (není roztroušena po objektech grafu) a možnost jednoduše udržovat historii pohled ů. Implementováno bylo n ěkolik r ůzných možností zm ěny pohledu: Posun obrazu. Prob ěhne na základ ě dvou bod ů zadaných uživatelem. První je úchopový. Druhý ur čuje kam bude úchopový p řesunut. Posun v reálném čase. Je jako posun obrazu s tím, že druhý bod m ůže uživatel posouvat a sou časn ě sledovat výsledek. Bodové zv ětšení. P řiblíží anebo oddálí obraz v přednastaveném pom ěru se zachováním bodu v HW sou řadnicích. Zv ětšení výb ěru. Zv ětší obdélníkovou část grafu tak aby byla celá zobrazena a umíst ěna do st ředu komponenty. Zv ětšení v reálném čase. Zv ětšuje nebo zmenšuje obraz v pom ěru, který zadává uživatel pomocí pohybu polohovacím za řízením (myší). Na po čátku je zadán úchopový bod jehož pozice bude zachována. Poté uživatel pohybuje myší, což zp ůsobuje zm ěnu m ěř ítka. P řitom pohyb na sever znamená zv ětšení, na jih zmenšení. Rychlost zv ětšování resp. zmenšování je dána úhlem trajektorie pohybu vzhledem k vodorovné rovin ě. Zobrazení celého grafu. Zobrazí celý graf s tím, že ho zmenší v přednastaveném pom ěru tak, aby po jeho obvodu vznikl okraj (nap ř. 10% ší řky resp. výšky komponenty). Při editaci a vkládání prvk ů grafu je s nimi manipulováno pomocí jejich základních rozhraní (oddíl 2.3.1), velkou m ěrou se ú častní uložišt ě grafických objekt ů (2.2.4). Vkládán je pouze vrchol nebo hrana. P ři vkládání vrcholu je p ředem znám jeho typ. Podle něj uložišt ě grafických objekt ů (dále jen uložišt ě) vytvo ří nový vrchol a komponenta ho posune do uživatelem požadované pozice. Vytvo ření hrany je složit ější, protože není předem znám její typ. Po výb ěru výstupního vrcholu hrany je z uložišt ě získána instance
21 jednoduché hrany (viz. 2.3.5.2) p ředstavující univerzální hranu (Obrázek 2.6). Ta je dále používána pro vykreslení k řivky hrany p ři zadávání mezilehlých kontrolních bod ů. Pokud je zadán bod ležící v nějakém vrcholu najde uložišt ě šablonu hrany schopné propojit dané typy vrchol ů a vytvo ří z ní novou (postup viz 2.1.4). Univerzální hrana nové p ředá své kontrolní body a ta je pak propojena s vrcholy a vložena do struktur pro uchování objekt ů grafu.
Uložiště grafických objektů
Uživatel Šablona hrany 1
kontrolní uložení body 3 2 předání 5 kontrolních bodů Univerzalni Nová hrana Hrana 4 Obrázek 2.6 Vytvá ření nové hrany, číslo v kole čku zna čí po řadí operace.
Při editaci grafických objekt ů lze m ěnit jejich polohu, nato čení, mazat je a editovat jejich vlastnosti ve spolupráci s obecným editovacím dialogem. Hranu nelze natá čet a samostatn ě posouvat, ale je možné m ěnit polohu jejích kontrolních bod ů. Až na mazání objekt ů mají všechny operace stejný pr ůběh: 1. (Nalezení objektu ) Uložišt ě grafických objekt ů nalezne objekt nebo objekty vybrané bodem a nebo obdélníkovou oblastí. Skupina objekt ů je chápána jako jeden objekt (popsaný v 2.3.10). 2. (Vyjmutí objektu ) Nalezený objekt je vyjmut z uložišt ě a odpojen od okolních objekt ů pomocí metod z rozhraní Connectable (viz 2.3.1). Poté je vytvo řen jeho přesný klon (rozhraní TreeCloneable ) a p ůvodní objekt ponechán v záloze. 3. (Editace ) S klonem objektu je provedena požadovaná zm ěna (posun, nato čení, editace vlastností). 4. (Uložení objektu ) Po dokon čení editace je klon objektu zaintegrován do grafu, uložen do uložišt ě a jeho originál vložen na konec historie zm ěn grafu pro možnost návratu (historie je také v uložišti). V pr ůběhu kroku t ři je objekt vyjmut z uložišt ě grafických objekt ů a vykreslován na popud plátna. Ihned po vyjmutí objektu je vyrenderován celý graf bez vyjmutého objektu do skrytého bufferu. V pr ůběhu nap ř. posunu objektu je pak opakovan ě vykreslován buffer a na n ěj objekt vždy v nové poloze. 2.2.4 Uložišt ě grafických objekt ů Objekty tvo řící graf a jejich šablony jsou udržovány v uložišti grafických objekt ů reprezentovaném t řídou Graph . P řitom je uložišt ě používáno ve dvou rolích. Jednak jako šablona typu grafu a pak neobsahuje žádné vykreslitelné objekty. A nebo p římo reprezentuje v opera ční pam ěti kreslený graf. P řitom p řechod od jedné role k druhé znamená naklonování šablony a její napln ění grafickými objekty (viz 2.1.4). Intern ě jsou grafické objekty a šablony organizovány do vzájemn ě provázaných map. Mapa je datová struktura pro uchování prvk ů pod klí či, dle kterých je pak rychle vrací.
22 Klí čem je obvykle textový řet ězec, ale není to nutnost. V knihov ě kolekcí Java platformy je mapa implementována jako rozptylová (hash) tabulka (t řída HashMap nebo starší HashTable). Prvky jsou uloženy v jednom nebo více polí pod indexy ur čenými z klí čů vhodnou hashovací funkcí. Tím dochází k rozptylu prvk ů po celém poli. Pokud je chceme všechny sekven čně vrátit je nutné projít celé pole i když je jen částe čně zapln ěno, což může být u velkých map časov ě hodn ě náro čné. Tento nedostatek řeší tzv. linkovaná mapa (linked map, t řída LinkedHashMap 8), která oproti oby čejné vkládané prvky spojuje obvykle do obousm ěrného spojového seznamu. Sekven ční získání všech prvk ů je pak realizováno s časovou náro čností p řibližn ě stejnou jako u pole (array). V dalším textu nebudu pro jednoduchost druhy map rozlišovat, linkované jsou použity všude tam, kde je třeba prvky sekven čně procházet.
Všechny objekty M Typy výstupních vrcholů S
Propojovací pravidla M
Šablony hran L A B M Šablony vrcholů a b M
L L Hrany typu „A“ L Hrany typu „B“ L L Vrcholy typu „a“
Vrcholy typu „b“ L Vrchol Vrchol typu „a“ typu „a“
Obrázek 2.7 Základní datová struktura pro uložení grafických objekt ů, (M) mapa, (L) mapa kombinovaná s obousm ěrným spojovým seznamem, (S) množina 9.
Datová struktura pro uložení grafických objekt ů je celá obsažena v hlavní map ě, která obsahuje pod klí či další mapy (Obrázek 2.7). Šablony vrchol ů nebo hran jsou uloženy
8 Linkovaná mapa z knihovny kolekcí řeší pro pot řeby editoru nevhodn ě konkuren ční p řístup tj. vkládání, odebírání a procházení prvk ů sou časn ě pomocí klí čů a iterátoru (sekven čně). Jelikož zdrojové kódy knihoven Java platformy nejsou Open source (nelze je m ěnit a dál distribuovat) a nelze dosáhnout vhodné funkcionality bez zásahu do privátních metod použil jsem a vhodn ě upravil ekvivalent LinkedMap z Commons Collections knihovny, která je sou částí The Jakarta Project (http://jakarta.apache.org/commons/collections/). 9 Mapa (HashMap, HashTable) je struktura, z níž jsou prvky rychle dostupné podle klí čů (nap ř. textových). Linkovaná mapa (LikedMap, LinkedHashMap) má všechny prvky ješt ě provázané do obousm ěrného spojového seznamu pro rychlé sekven ční procházení. Množina (Set) umož ňuje rychle zjistit jestli obsahuje n ějaký prvek.
23 v map ě pod klí či, které se shodují s názvem jejich typu. Stejné klí če používají mapy pro uložení map vrchol ů a hran odvozených od šablon a tvo řících samotný graf. P řitom vrchol nebo hrana jsou v map ě uloženy pod svými identifikátory. Vykreslova če vlastností jsou všechny uloženy v jedné map ě, aby je bylo možné efektivn ě prohledávat. Struktura obsahuje i pravidla propojování vrchol ů hranami. Ta říkají jaký typ hrany m ůže propojit dvojici typ ů vrchol ů. P řitom se rozlišuje výstupní a vstupní typ. Slouží k tomu mapa v níž jsou uloženy seznamy referencí na šablony hran pod klí čí tvo řenými z typ ů vrchol ů. Klí č je řet ězec znak ů složený z typu výstupního vrcholu, odd ělova če a typu výstupního vrcholu. Nap ř. pokud hrana m ůže vycházet z vrcholu typu „place“ a kon čit ve vrcholu typu „transition“ bude reference na její šablonu uložena v seznamu pod klí čem „place |->| transition“. Uložišt ě grafických objekt ů není pouze datová struktura. Umož ňuje provád ět operace nad ur čitými okruhy objekt ů a to: Vykreslit celý graf na p ředaný kontext za řízení ( Graphics2D ). Zjistit jakou plochu graf zabírá v logických sou řadnicích (bounding box celého grafu). Najít objekt do n ěhož pat ří bod p ředaný v logických sou řadnicích a postupn ě vracet další vyhovující. Najít objekt, který protíná a nebo je obsažen v předaném obdélníku. Najít objekty, které jsou celé ve výb ěrové obdélníkové oblasti. Jsou vráceny jako objekt výb ěru (2.3.10). Vyhledávání objekt ů z ur čitého okruhu ve skute čnosti zajiš ťuje na to specializovaný objekt. Jeho kostru tvo ří abstraktní t řída AbstractFinder . Ta obsahuje abstraktní metodu, která o jednom objektu rozhodne jestli spl ňuje kritéria vyhledávání. Okruh prohledávaných objekt ů není pevný, je tvo řen seznamem kolekcí (tj. map atp.), které mají být prohledány. Samotné hledání se z vn ějšku jeví jako postupné procházení pole pomocí iterátoru. Další funkcí uložišt ě grafických objekt ů je udržování historie zm ěn grafu. K tomuto účelu je používána cyklická fronta pevné délky tj. p ři jejím zapln ění budou p řemazávány nejstarší prvky. Ve front ě jsou uloženy instance t řídy Action , která obsahuje p říznak o jakou operaci nad grafem se jedná a data pro její vrácení zp ět, což jsou obvykle grafické objekty p řed provedením akce. Vracet akce zp ět (undo operace) je nutné provád ět v opa čném po řadí než byly vykonány, pokud by se n ějaká vynechala došlo by k chyb ě, protože objekty tvo řící data pro obnovení mohou mít reference na objekty zm ěněné v čase po nich. 2.2.5 Obecný editovací dialog Obecný editovací dialog slouží k editaci vlastností navázaných na grafické objekty a nebo pouze jich samotných. Je reprezentován t řídou GeneralDialog . Je založen na komponent ě JTree z knihovny Swing a umož ňuje zobrazit jakýkoli objekt implementující rozhraní GraphObject (z 2.3.1) i s jeho celým podstromem vlastností. Od konkrétní datové reprezentace zobrazovaných strom ů je komponenta JTree odstín ěna pomocí modelu dat TreeModel . Zobrazení anebo editaci jednoho uzlu stromu zajišťuje objekt implementující rozhraní TreeCellRenderer a TreeCellEditor . Oba vracejí na žádost JTree komponentu, která bude pro danou operaci použita. P ři vykreslování je dokonce jen vykreslena na obrazovku a pak „zahozena“. Jelikož je v našem p řípad ě komponenta představující uzel v obou případech stejná vytvá ří ji v obou p řípadech TreeCellBuilder a předává ji rendereru a editoru uzlu (Obrázek 2.8).
24 TreeModel TreeCellEditor 1 7 Uzel Německá dej mi uzel Národnost: 6 „narodnost“ „narodnost“ Změna Sestavení 5 2 uzlu Uzel komponenty 4 3 JTree „narodnost“ Osoba Jméno: Jan Novák TreeCellBuilder Německá TreeCellRenderer 3 Národnost: Uzel Sestavení 4 „narodnost“ komponenty 5 6 Národnost: Německá
Obrázek 2.8 Vytvá ření komponent pro vykreslení uzl ů stromu vlastností, čísla v kroužcích jsou po řadí operací, kroužek čárkovanou čarou pro editaci uzlu, plný pro pouhé zobrazení.
Komponenta pro zobrazení jednotlivých uzl ů stromu je sestavena na základ ě jeho objektového typu. Nap ř. pro vlastnost PropertyTextChoice (viz 2.3.6.7) bude obsahovat JComboBox , pro PropertyNumber JTextField atp. U všech zobrazitelných vlastností obsahuje JCheckBox pro zapnutí/vypnutí viditelnosti na plátn ě. P říklad komponenty viz Obrázek 2.9.
Obrázek 2.9 Obecný editovací dialog, zobrazen vrchol p ředstavující p řechod s identifikátorem „T2“, zašediv ělá pole mají needitovatelné vlastnosti.
25 2.3 Objekty grafu Objekty grafu tvo ří jádro editoru. Jsou instancemi množiny vzájemn ě provázaných tříd. Používají se ve dvou kontextech. Jako šablony objekt ů intern ě reprezentujících prvky grafu a jako samotné tyto objekty. Šablony jsou instance vytvo řené na základ ě podp ůrných definic (viz 3.1 a 3.2). Obsahují defaultní hodnoty a jejich vhodným klonováním jsou vytvá řeny objekty zastupující reálné prvky grafu v editoru. Tyto instance jsou m ěněny na základ ě uživatelských vstup ů v kreslící komponent ě (viz 2.2.3). Jak šablony tak i jejich klony tvo řící graf jsou uloženy v uložišti grafických objekt ů (oddíl 2.2.4). V následujících podkapitolách je uveden popis t říd objekt ů grafu a jejich základních rozhraní. 2.3.1 Základní rozhraní objekt ů grafu Vytvo řil jsem n ěkolik základních rozhraní 10 , která ur čují díl čí funkcionalitu spole čnou pro více objektových t říd tvo řících graf. Je tak jednozna čně ur čeno jak t řídy grafu spolupracují mezi sebou a s vn ějším okolím jako je nap ř. uložišt ě grafických objekt ů a kreslící komponenta (popis v 2.2.4 a 2.2.3). P ři implementaci t říd pak není t řeba hlídat široké souvislosti a lze snadno celý systém rozši řovat beze zm ěn toho co již existuje. UML diagram (Obrázek 2.10) znázor ňuje vztahy mezi rozhraními.
Obrázek 2.10 Hierarchie rozhraní t říd tvo řících graf
Nejd ůležit ější rozhraní GraphObject deklaruje stromovou strukturu vlastností navázanou na graf, vrcholy a hrany. Je rozší řením rozhraní TreeNode , TreeCloneable a XMLObject . Každá t řída implementující GraphObject musí mít podle rozhraní TreeNode seznam potomk ů a jednoho p ředka. To postihuje model grafu složený z globálních vlastností, vrchol ů a hran. Přičemž vrchol i hrana mohou také disponovat vlastnostmi a ty lze dále rekurzivn ě rozkládat na jednodušší, čímž vytvá řejí stromovou strukturu (Obrázek 2.10). TreeNode je sou částí standardních knihoven Javy. Používá se v datovém modelu pro prvky zobrazené v komponent ě JTree , čehož využívám p ři editaci vlastností v obecném editovacím dialogu (viz 2.2.5). Strukturu objekt ů definovanou výše je t řeba p ři vytvá ření a manipulaci s objekty klonovat do hloubky. Univerzálním rozhraním pro tuto činnost je TreeCloneable , které rozši řuje rozhraní Cloneable obsažené v Java API. Klonování zajiš ťují deklarované
10 Rozhraní neboli interface je syntaktická struktura deklarující metody a konstanty, neobsahuje implementaci (více v [14] a [15]).
26 metody clone() , updateReferences() a cloneSubTree() . Klonovat lze jakýkoli podstrom vlastností (Obrázek 2.11) zavoláním metody cloneSubTree() na p říslušný uzel. Ta volá metodu clone() s tím, že jí p ředá do časnou mapu 11 pro uchování dvojic reference na originál a reference na klon. Clone() vytvo ří klon objektu, jehož t řída je členskou metodou, uloží ho do mapy referencí pod klí čem rovným referenci na jeho originál a na konci své činnosti ho vrací jako svou návratovou hodnotu. Mezi tím však zavolá metody clone() všech následník ů uzlu ve stromové struktu ře. To pokra čuje jako řet ězová reakce dokud není dosaženo list ů stromu. Po návratu do cloneSubTree() je vytvo řen klon základního stromu, ale nejsou aktuální reference mimo jeho strukturu ( čárkovaná hrana viz Obrázek 2.11). Neaktuálnost vznikne nutností neklonovat některé objekty dvakrát. Pokud objekt obsahuje referenci na objekt, který není jeho rodi č anebo přímý potomek nenaklonuje ho, pouze klonu nastaví referenci na originál. Nahrazení za reference na nové objekty zajistí metoda updateReferences() volaná postupn ě u všech vytvo řených klon ů. Obnovení je realizováno podle mapy referencí a předaného objektu CloningSettings , který obsahuje nastavení klonování. To ur čuje jestli má být u klon ů nastaveno nové ID, jestli se jedná o klonování více podstrom ů a vedou mezi nimi reference atp. Klonování více podstrom ů postihuje klonování vrcholu a na n ěj navazujících hran. Scéná ř je podobný jako u jednoho stromu. Nejd říve se naklonují všechny podstromy bez obnovení referencí s tím, že se sdílí mapa referencí. Pak se postupn ě na klony podstrom ů zavolá metoda updateReferences() . Ta obnoví všechny reference k nimž najde protějšky ve sdílené map ě.
Obrázek 2.11 Strom vlastností vrcholu s referencí mimo strukturu stromu.
Rozhraní XMLObject deklaruje metody nutné pro perzistentní uložení a na čtení objektů z XML dokumentu. Uložení resp. na čítání probíhá prost řednictvím DOMu 12 . Každý uložitelný objekt obsahuje cestu ke svému ko řenovému XML elementu 13 . Cesta je relativní od XML elementu jeho rodi če (dle GraphObject ). Ukládání zajiš ťuje metoda writeSelf() , které je p ředán XML element p ředka. Metoda zodpovídá za uložení celého podstromu objekt ů tj. každý objekt po uložení sebe sama zavolá tuto metodu i na všechny své p římé potomky a ty postupují zcela stejn ě. Na čítání z DOMu obstarává metoda readSelf() , postup je obdobný ukládání.
11 Mapa (rozptylová [hash] tabulka) je datová struktura, do které je možné ukládat dvojice (klí č, hodnota) a rychle vyhledávat hodnoty podle klí če. V knihovn ě kolekcí Java platformy je implementována třídou HashMap a nebo starší HashTable. 12 Dokument Object Model (DOM) je objektový model XML dokumentu, vytvo řený parserem. 13 XML element je zjednodušen ě tag. Nap ř.
27 Funkcionalitu pro vykreslení objektu na plátn ě deklaruje rozhraní drawable , které rozši řuje Storable . Základní metodou je draw() sloužící k běžnému zobrazení objektu. Po jejím zavolání se objekt vykreslí na p ředaný kontext za řízení a to bez navázaných objekt ů jako jsou vykreslova če vlastností (viz 0). Naproti tomu metoda drawSelected() vykreslí objekt i s navázanými objekty a to v barv ě, kterou ur čuje kontext za řízení. Je určena k zobrazení vybraného objektu. Rozhraní dále říká, že objekt musí mít bázový bod. Vzhledem k němu se vykreslují navázané objekty. O zm ěně bázového bodu objekt informuje zaregistrované poslucha če typu PositionListener , což je rozhraní s jedinou metodou positionChanged() . Té je p ředána událost typu PositionEvent , která obsahuje zdroj událost a novou polohu bázového bodu. Nakonec rozhraní deklaruje metody pro zjištění jestli n ějaký bod nebo obdélník pat ří do bounding boxu objektu anebo přesn ě do jeho tvaru. Rozhraní Storable ur čuje funkcionalitu nutnou pro ukládání objekt ů do uložišt ě grafických objekt ů (viz 2.2.4) a odpovídá za tvorbu nových objekt ů. Každý uložitelný objekt má své jedine čné ID v rámci svého typu a mapu v níž je pod ID uložen. Objektu lze přiřadit generátor ID. Ten generuje ID ve tvaru prefix + číslo. Nap ř. pokud je prefix „MUZ“ budou platná ID: „MUZ0“, „MUZ1“ až „MUZn“, kde n je nezáporné celé číslo. Generátor a mapa jsou spole čné vždy pro skupinu instancí objektové t řídy se stejným typem. Typ je zde atribut třídy (textový řet ězec), který je shodný pro všechny instance založené na stejné definici v podp ůrných definicích (o nich blíže v 3.1). Vytvo ření nového objektu daného typu se provádí klonováním šablony deklarovaným v rozhraní TreeCloneable . Šablona je jen speciální instance objektové t řídy daného typu, která je vytvo řena podle podp ůrných definic. Z nich je na čten i typ objektu. Storable dále předepisuje metody, které zajistí vložení ( selfInsert() ) a vyjmutí (selfRemove() ) objektu z uložišt ě grafických objekt ů. Connectable je rozhraní deklarující metody nutné k integraci a vyjmutí objektu z obklopujícího okolí. Ne říká nic o tom jak je objekt s okolím propojen. Zmíněná funkcionalita je využita p ři editaci jednotlivých prvk ů grafu. P ředtím, než je objekt zm ěněn (nap ř. posunut, napojen na jiný) je vytvo řen jeho klon. P ůvodní objekt je vyjmut z okolí a místo n ěj zaintegrován klon. Veškeré zm ěny se provád ějí s klonem. Pokud je uživatel potvrdí je v grafu ponechán klon a originál je uložen do historie pro možnost návratu. Pokud uživatel zm ěny nepotvrdí je klon vyjmut a nazp ět zaintegrován originální objekt. Rozhraní ConnectableByEdge p ředepisuje funkcionalitu nezbytn ě nutnou pro objekt, na který m ůže být napojena hrana. Takový objekt musí hran ě poskytnout bázový bod, obrysový tvar, tlouš ťku jeho čáry a metody pro zaregistrování a odregistrování vstupní a výstupní hrany. Z bázového bodu a obrysového tvaru je vypo čten bod napojení hrany, který je následn ě zkorigován s ohledem na tlouš ťku obrysového tvaru. Dvojice rozhraní Movable a Rotable deklaruje metody používané p ři posunu a otáčení grafických objekt ů. Samotný fakt, že objektová t řída implementuje jedno z rozhraní je nutná, ne však posta čující podmínka k povolení provedení p říslušné operace. Tu povolí až instance t řídy pomocí metod isMovable() a isRotable() . Rozhraní deklarují také metody, které zajiš ťují vykreslení objektu b ěhem editace. P řitom musí objekt zajistit i vykreslení navázaných objekt ů (vykreslova čů vlastností, navázaných hran atp.). Rozhraní Erasable ur čuje metody pot řebné k mazání a obnovení objekt ů. P ředtím než je objekt vymazán dotáže se ho komponenta s ním manipulující zda musí tuto operaci uživatel potvrdit. Pokud je potvrzení vyžadováno vrátí objekt lokalizovanou zprávu popisující důvod vymazání. Nap ř. pokud je na vrchol napojena hrana bude zpráva „ Na vrchol jsou napojeny hrany. Opravdu ho chcete vymazat? “. Vymazaný objekt je vždy uložen do historie zm ěn grafu pro možnost obnovení objektu.
28 Poslední rozhraní je Renderer a deklaruje funkcionalitu objektu, který n ějakým zp ůsobem zobrazí vlastnost na plátn ě. Říkejme mu vykreslova č vlastnosti. Jeho rozhraní rozšiřuje Drawable , Movable , Rotable , Erasable , TreeCloneable a Connectable (viz Obrázek 2.10). K tomu p řidává metody nutné k napojení na vykreslovanou vlastnost a grafický objekt vzhledem k jehož pozici se vykresluje. Vykreslova č není p římo objekt grafu, nespadá do stromu vlastností. Je sou částí zobrazované vlastnosti a nemá bez ní žádný význam, proto ani není ukládán do XML dokumentu. Vlastnosti popisující jeho grafickou podobu sdílí s vykreslovanou vlastností. Ta zodpovídá za jejich perzistentní uložení. A také je pln ě v její kompetencí vytvo ření a zrušení vykreslova če. Mazání resp. obnovení deklarované rozhraním Erasable u vykreslova če znamená pouze jeho skrytí resp. zobrazení. 2.3.2 Abstraktní předek objekt ů grafu Implementace uzlu stromu vlastností je umíst ěna do abstraktní t řídy AbstractGraphObject , která spl ňuje požadavky rozhraní GraphObject (Obrázek 2.12). Třída obsahuje seznam potomk ů tvo řený standardním kontejnerem java.util.Vector , který je schopný rozši řovat svou kapacitu dle pot řeby a dostupné opera ční pam ěti. Dále udržuje referenci na svého rodi če. Ten je null pokud se jedná o ko řen stromu vlastností. Umož ňuje p řidávat a odebírat potomky, kterým se sama nastavuje jako p ředek. Dále implementuje tuto funkcionalitu: Obsahuje XML cestu k elementu, který tvo ří objekt v XML dokumentu grafu. Za vznik a zánik této cesty pln ě odpovídá. Najde a nebo vytvo ří XML element z předchozího bodu p ři ukládání do XML dokumentu grafu. Do elementu nic neuloží to je ponecháno na odvozené t říd ě. Najde XML element p ři na čítání z XML dokumentu. Ukládá a na čítá všechny následníky ze stromu vlastností do XML dokumentu grafu. Obsahuje lokalizovaný název objektu pro GUI a udržuje p říznak jestli je objekt viditelný v obecném editovacím dialogu (2.2.5). Klonuje podstrom vlastností navázaných na uzel, ale neaktualizuje reference mimo jeho strukturu, nebo ť na této úrovni žádné neexistují. Třída ponechává na následnících v hierarchii t říd implementaci toho jestli je objekt možno m ěnit v editovacím dialogu a nastavování grafických vlastností (z 2.3.6). Ty „nastavuje“ i negrafický objekt, ale jen tak, že jejich nastavení p řepošle relevantnímu objektu. Nap ř. vlastnost svému vykreslova či.
29
Obrázek 2.12 Předkové všech objekt ů p římo tvo řících graf.
2.3.3 Spole čný p ředek vrchol ů a hran Předek spole čný pro vrcholy a hrany je abstraktní t řída GraphicalObject odvozená od AbstractGraphObject , implementuje rozhraní Drawable a Storable (viz. Obrázek 2.12). Zajiš ťuje uložení a vytvá ření jednozna čného identifikátoru objektu, jeho náležitost k ur čitému typu objektu, vkládání a vyjímání objektu z uložišt ě grafických objekt ů. Ke generování ID využívá IDGenerator , který umož ňuje: Generovat jednozna čný identifikátor složený z textové p ředpony a číselného základu. P ředponu nelze m ěnit po vytvo ření generátoru. Číselný základ je nezáporné celé číslo 14 , které v generované posloupnosti identifikátor ů roste pokud předtím nebyl žádný identifikátor zrušen. Rušit a „recyklovat“ identifikátory. Po smazání je ID navráceno generátoru, který ho za řadí do množiny použitelných ID. Taková ID pak vrací p řednostn ě než aby generoval nová. Rezervovat identifikátor p ředtím zrušený. Tuto funkci použije objekt, který byl smazán a následn ě obnoven aby se mu nezm ěnilo ID. Přidat nevygenerovaný identifikátor. Toho je využito p ři na čítání objekt ů z XML dokumentu. Ukládání do uložišt ě grafických objekt ů se provádí pomocí reference na tzv. domovskou mapu. Tu získá objekt od své šablonu p ři klonování. Šablona jí získá p ři zaregistrování do uložišt ě grafických objekt ů, který pro každou šablonu, a tak i typ objektu, alokuje novou mapu. Samotné vložení nebo vyjmutí se provede bez ú časti uložišt ě, integritu zajišťuje jedinečnost identifikátor ů objekt ů. T řída dále udržuje seznam poslucha čů události o zm ěně polohy objektu a poskytuje aparát pro její ší ření. Třída GraphicalObject nezajiš ťuje vykreslení grafického objektu. Tj. neimplementuje metody p ředepsané rozhraním Drawable . To je ponecháno na jejích následnicích v hierarchii objektových t říd.
14 Celé číslo je implementováno jako long . To m ůže nabývat hodnot od -223372036854775808 do 9223372036854775807 v četn ě.
30 2.3.4 Vrchol
2.3.4.1 Abstraktní vrchol Abstraktní t řída AbstractVertex je p ředkem všech vrchol ů v grafu a implementuje veškerou funkcionalitu pot řebnou k propojení s hranami ( AbstractEdge ). Neur čuje jak bude vrchol vykreslen. Je odvozena od t řídy GraphicalObject a p řejímá rozhraní Rotable , Movable , Erasable a ConnectableByEdge (Obrázek 2.13). Vyjma posledn ě jmenovaného rozhraní ponechává konkrétní implementaci metod na odvozené t říd ě.
GraphicalObject «interface» Movable «interface» ConnectableByEdge «implements» «implements» «interface» «implements» Erasable má výstupní hranu AbstractEdge AbstractVertex má vstupní hranu 0..* 0..1 «implements» «interface» 0..* 0..1 Rotable «interface» Skinable
«implements» GeneralVertex 0..* 0..* «interface» SkinChangeListener
1 má grafický popis obrys. tvaru VertexSkin PropertyLineGraphics má grafický popis vnitřního tvaru 1 1 1..* 1 0..1 má grafický popis výplně obrys. tvaru 1 1 PropertyFillGraphics má grafický popis výplně vnitřního tvaru 1
0..1
Obrázek 2.13 Hierarchie t říd tvo řících obecný vrchol.
Napojení na hrany je realizováno dv ěma spojovými seznamy. Jeden slouží k uchování referencí na výstupní hrany, druhý na vstupní. T řída umož ňuje tyto operace s hranami: Zaregistrování a odregistrování vstupní nebo výstupní hrany, kterou o tom informuje. Odregistrování a zaregistrování všech napojených hran v rámci integrace a odpojení objektu od okolí (viz rozhraní Connectable , oddíl 2.3.1). Do časné vyjmutí všech napojených hran z uložišt ě grafických objekt ů za ú čelem převzetí jejich vykreslení. To využije odvozená t řída nap ř. p ři interaktivní zm ěně polohy.
31 Překreslení všech napojených hran. Informování napojených hran o zm ěně tvaru vrcholu a síle tlouš ťky čáry, kterou bude vykreslen. Odpojení vrcholu od hran, které nejsou obsaženy v předané množin ě. Vytvo ření m ělké kopie seznam ů hran. Obnovení referencí na hrany po klonování skupiny hran a vrchol ů.
2.3.4.2 Obecný vrchol Třída GeneralVertex p ředstavuje do jisté míry obecný vrchol, její instance jsou používány pro všechny editorem podporované vrcholy. Je odvozena od t řídy AbstractVertex (Obrázek 2.13) k jejíž funkcionalit ě p řidává grafické znázorn ění vrcholu na plátn ě. Obecnost vrcholu spo čívá v široké variabilnosti vykreslovaných tvar ů, které představují vrchol na plátn ě. P řitom je ješt ě možné aby m ěl vrchol sadu r ůzných vzhled ů – skin ů a ty na základ ě požadavk ů okolí používal. Grafická zna čka vrcholu je složena z obrysového a nepovinného vnit řního tvaru (Obrázek 2.14). Obrysový tvar musí být tvo řen uzav řenou cestou a obsahovat bázový bod. Na vnit řní nejsou kladeny žádné požadavky, má pouze dekorativní charakter. Bázový bod slouží k uchopení vrcholu na plátn ě, napojení vykreslova čů vlastností a v sou činností s obrysovým tvarem k napojení hrany. Oba tvary jsou reprezentovány nějakými t řídami z Java API, které implementují rozhraní Shape . To spl ňují nap ř. t řídy Rectangle2D (obdélník), Ellipse2D (elipsa) nebo GeneralPath . Poslední je cesta složená z úse ček, obloukových a kubických Bézierových k řivek, která m ůže být souvislá a uzav řená. Tím je zaru čena pom ěrn ě velká obecnost celkového tvaru vrcholu (Obrázek 2.15).
Obrázek 2.14 Skládání tvaru obecného vrcholu.
32
Obrázek 2.15 P říklady tvar ů vrcholu. A, B mají neviditelný obrys. tvar sloužící pouze k napojení hran. C demonstruje použití Bézierových k řivek. D primitivní geom. tvary. U E až H je šrafování tvo řeno vnit řním tvarem (jedná se o sadu skin ů).
Zm ěna polohy a nato čení vrcholu je prováděna pomocí afinní transformace sou řadnic a to vždy vzhledem k bázovému bodu. Vrchol obsahuje dv ě sady tvar ů a afinní transformaci sou řadnic. Jedna sada je vzorová, druhá pracovní. Pokud se s vrcholem nic ned ěje vykresluje pracovní sadu bez toho, že by n ěco p řepo čítával. Při posouvání nebo rotaci vrchol adekvátn ě upraví afinní transformaci a její aplikací na vzorovou sadu vygeneruje pracovní, kterou vykreslí. Sou časn ě upraví polohu bázového bodu. Na n ěj se neaplikuje afinní transformace. P ři rotaci se nijak nem ění (otá čení kolem n ěj) a posun znamená jeho umíst ění do požadované pozice. Transformaci tvaru ( Shape ) ve skute čnosti obstarává t řída AffineTransformExt , ve které je uložena transforma ční matice. Ta je odvozena od AffineTransform z Java API, jejíž členská metoda createTransformedShape(Shape) vytvá ří z objekt ů typu Shape transformované tvary (také typu Shape ). Výb ěr objekt tj. zjištění jestli n ějaký bod nebo obdélník pat ří do vrcholu se provádí na základ ě obrysového tvaru pomocí metod contains() a intersects() . Jejich implementace je sou částí všech primitivních grafických prvk ů z Java API. Vykreslení obrysového a vnit řního tvaru provádí kontext za řízení Graphics2D získaný od plátna nebo uložišt ě grafických objekt ů. Ve vykreslování se postupuje v tomto po řadí: výpl ň obrysového tvaru, výpl ň vnit řního tvaru, vytažení segment ů cesty vnit řního tvaru a vytažení uzav řené cesty tvaru obrysového. Barvu, tlouš ťku a styl čáry použitý pro vytažení nastavuje kontextu za řízení grafická vlastnost PropertyLineGraphics . Její obdobou pro výpl ň je PropertyFillGraphics (více o nich v 2.3.6). Ob ě vlastnosti vrchol získá od aktuáln ě používaného skinu spolu se sadou tvar ů. Jedna instance vrcholu muže být zobrazena n ěkolika zp ůsoby. Vrchol obsahuje několik skin ů (t řída VertexSkin ) uložených v map ě pod textovými klí či. Každý skin má vzor obrysového tvaru, vzor vnit řního tvaru (nepovinný), po čáte ční bázový bod a grafické vlastnosti obou tvar ů. Zm ěnu vrcholu iniciuje externí objekt pomocí volání metody z rozhraní Skinable . Té p ředá klí č skinu, jehož nastavení požaduje. Vrchol si skin nastaví jako sv ůj aktuální, za řadí jeho grafické vlastnosti do svého stromu vlastností a vygeneruje nový pracovní tvar. O zm ěně informuje napojené hrany a zaregistrované poslucha če typu SkinChangeListener vyjma toho, který zm ěnu inicioval. Nastavení jiného aktuálního skinu se neobejde bez zm ěny afinní transformace pro generování pracovního tvaru. Situace je znázorn ěna na obrázku (Obrázek 2.10), kde je p ůvodní skin ozna čen písmenem A, nastavovaný je B. Jejich po čáte ční bázové body jsou Z a P. P ůvodní transformace T promítá po čáte ční bázový bod Z do bázového bodu vrcholu V. Aby byly tvary po vým ěně
33 slícovány je nutné upravit transformaci T na H pomocí translace K tj. tak aby promítala bod P do bodu V. Po vygenerování pracovního tvaru z nového skinu tak z ůstane bázový bod vrcholu na stejném míst ě. Vrchol p řidává do svého stromu vlastností grafické vlastnosti zobrazující jeho ID, posun a nato čení. Vlastnosti neobsahují p římo dané údaje, jen je zobrazují v editovacím dialogu a umož ňují jejich zm ěnu. Sou časn ě se starají o uložení a na čtení hodnot z XML dokumentu grafu. Stejn ě jsou na tom vlastnosti popisující grafické parametry vykreslení tvaru, které vrchol získá od skin. Rozdíl je pouze v tom, že nesou p říslušné hodnoty.
Obrázek 2.16 Zm ěna skinu vrcholu z A na B. Z a P jsou po čáte ční bázové body skin ů. H a T znázor ňují transformace pro vytvá ření pracovního tvaru vrcholu.
2.3.5 Hrana
2.3.5.1 Abstraktní p ředek hran Předkem hran grafu je abstraktní t řída AbstractEdge , která má ve své kompetenci napojení na vrcholy, správu kontrolních bod ů a manipulaci se svým tvarem. To až na vytvo ření tvaru hrany postihuje celou její funkcionalitu. Je odvozená od GraphicalObject . Implementuje rozhraní Movable a Erasable (Obrázek 2.17). Omezení jaké typy vrchol ů muže hrana propojit jsou centráln ě udržována v uložišti grafických objekt ů, hrana se o to nestará.
34
Obrázek 2.17 Hierarchie objekt ů tvo řících hrany.
Tvar hrany ur čují kontrolní body. To jsou body, jejichž proložením vznikne k řivka znázor ňující hranu na plátn ě. Zárove ň prost řednictvím nich probíhá manipulace s hranou Na úrovní abstraktní hrany existují dva jejich typy. Umíst ěné ve vrcholu (t řída ControlPointInVertex ) a mezilehlé (t řída ControlPoint ). Ve vrcholu muže ležet pouze po čáte ční a koncový kontrolní bod. Hrana je vždy obsahuje a pomocí nich získává informaci o tom jaké vrcholy propojuje. Počet mezilehlých bod ů je volitelný. Všechny kontrolní body jsou navzájem propojeny do obousm ěrného spojového seznamu. Jejich konkrétní implementace hrana nevytvá ří, p řenechává to na odvozených t řídách. Deklaruje pro tento ú čel t ři abstraktní metody: ControlPoint newIntermediateCP() pro vytvo ření instance mezilehlého kontrolního bodu typu. ControlPointInVertex newBeginCP() pro vytvo ření instance po čáte čního kontrolního bodu. ControlPointInVertex newEndCP() pro vytvo ření koncového kontrolního bodu. Křivku hrany sestavují kontrolní body, hrana k ní doplní jen koncovou zna čku – šipku. Oba tvary jsou odd ělen ě uchovány ve t říd ě GeneralPath z Java API. P ři p řekreslování hrana vytvo ří prázdnou instanci t řídy GeneralPath a předá jí po čáte čnímu kontrolnímu bodu. Ten do ní vloží část k řivky, která spadá do jeho kompetence a p ředá ji dalšímu bodu. Tak se postupuje dokud není dosaženo koncového bodu. Vytvo řený tvar si hrana uchovává dokud není zm ěn n ějaký její kontrolní bod a nebo napojený vrchol. Jeho vykreslení na kontext za řízení p ředchází nastavení tahu tvo řícího čáru. To zajiš ťuje grafická vlastnost PropertyLineGraphics napojená ve stromu vlastností hrany. P řitom je pro koncovou šipku vždy vynucena plná čára. Vykreslení šipky je volitelné. Do stromu vlastností hrana dále p řidává vlastnost obsahující ID její, vstupního a výstupního vrcholu. Pro manipulaci s hranou jsou implementovány tyto funkce:
35 Nastavení po čáte čního a koncového kontrolního bodu do vrcholu a nebo na ur čitou pozici. Přidání mezilehlého kontrolního bodu. Nastavení pozice vybraného kontrolního bodu. Zám ěna kontrolního bodu za p ředaný. Převzetí kontrolních bod ů od jiné hrany. Nalezení kontrolního bodu pat řícího do p ředané obdélníkové plochy. Ov ěř ení jestli p ředaným obdélníkem prochází k řivka hrany. Translace hrany. Tj. posun všech kontrolních bod ů a následné vygenerování k řivky hrany. Vykreslení obdélníkových zna ček kontrolních bod ů.
2.3.5.2 Jednoduchá hrana Hrana propojující kontrolní body jen úse čkami je tvo řena t řídou SimpleEdge . Implementuje pouze metody vyráb ějící kontrolní body. Jako po čáte ční kontrolní bod instancuje t řídu BeginControlPoint , koncový je tvo řen t řídou EndControlPoint a mezilehlý je typu IntermediateControlPoint . Vytvá ření tvaru hrany je pln ě v kompetenci kontrolních bod ů, které se postupn ě volají v po řadí od po čáte čního do koncového. Každý kontrolní bod poskytuje následujícímu a předcházejícímu bod, na který má navázat. Pokud bod navázání nelze v daném okamžiku ur čit vrací jeho odhad. Po čáte ční kontrolní bod typu BeginControlPoint , pouze hledá bod napojení na vrchol. Ten p ředá následujícímu kontrolnímu bodu. Vrchol mu k tomu poskytne sv ůj obrysový tvar, tlouš ťku jeho tahu a bázový bod. Bod napojení vznikne z pr ůse číku obrysového tvaru a úse čky s po čátkem v bázovém bodu vrcholu, koncem v kontrolním bod ě následujícím za po čáte čním (Obrázek 2.18). Pokud pr ůse čík ů existuje n ěkolik volí se ten nejvzdálenější od kontrolního bodu vrcholu. Aby bylo napojení p řesné provede se korekce s ohledem na tlouš ťku t obrysového tvaru (detail A). Veškeré výpo čty jsou provád ěny na základ ě analytické geometrie, čemuž odpovídají dosažené výsledky (Obrázek 2.19). Pokud je po čáte ční kontrolní bod umíst ěn mimo vrchol nic nepo čítá a poskytuje následujícímu svou polohu jako bod k navázání.
Obrázek 2.18 Bod napojení hrany na vrchol, t je tlouš ťka čáry obrysového tvaru vrcholu.
36 Mezilehlý kontrolní bod ( IntermediateControlPoint ) jednoduché hrany vykresluje úse čku mezi svou pozicí a bodem, který získá od p ředchozího kontrolního bodu. Sám poskytuje následujícímu kontrolnímu bodu vlastní pozici jako bod k navázání. Koncový kontrolní bod ( EndControlPoint ) zjistí bod napojení na sv ůj vrchol stejným postupem jako po čáte ční kontrolní bod. Pak z něj natáhne úse čku do bodu, který získá od předchozího kontrolního bodu a poskytne ho hran ě, aby v ěděla kam umístit koncovou šipku.
Obrázek 2.19 Příklad jednoduché hrany a dosažená p řesnost napojení na vrcholy. Případ A – napojení na úse čku, B –napojení na kubickou Bézierovu k řivku.
2.3.5.3 Zaoblená hrana Zaoblená hrana prokládá kontrolní body úse čkami a oblouky. Výsledek vypadá jako jednoduchá hrana se zaoblenými „rohy“ (Obrázek 2.20). Implementuje jí t řída RoundedEdge (Obrázek 2.17). Mechanizmus tvorby její k řivky probíhá stejn ě jako u jednoduché hrany. Rozdíl je pouze v použití jiného mezilehlého kontrolního bodu a to typu RoundedIntermediateCP . Tomu hrana p ředává polom ěr zaoblení, skute čný m ůže být menší podle aktuální situace.
Obrázek 2.20 Zaoblená hrana s vyzna čenými kontrolními body. B1 je po čáte ční.
Mezilehlý kontrolní bod RoundedIntermediateCP p řidává do tvaru hrany úse čku, která vede od p ředchozího kontrolního bodu, a oblouk te čný na ní a spojnici s následujícím kontrolním bodem. P řed tím než to ud ělá vypo čítá maximální možný polom ěr zaoblení Rmax oblouku (Obrázek 2.21) podle vztahu (2.1). P ři tom vychází z bodu napojení N, který mu poskytne p ředchozí kontrolní bod Bi-1 a bodu C získaného od následujícího kontrolního bodu Bi+1 . Bod C leží v polovin ě úse čky |B i, B i+1 |. Je to jednoduchý odhad kam bude
37 zasahovat oblouk u bodu Bi+1 . Pokud je Rmax menší než polom ěr zaoblení hrany je sestrojen te čný oblouk s polom ěrem Rmax , jinak je dodržen hranou p ředepsaný. Koncový bod sestrojeného oblouku je p ředán následujícímu kontrolnímu bodu, aby se na n ěj napojil. p R = ⋅ MIN {d ,d } (2.1) max 2v 1 2
Obrázek 2.21 Ur čení maximálního možného zaoblení oblouku u kontrolního bodu Bi. N a C jsou body k napojení vrácené okolními kontrolními body Bi-1 a Bi+1 .
2.3.6 Uživatelské vlastnosti Uživatelské vlastnosti zachycují informace databázového charakteru navázané na vrcholy, hrany i celý graf. Uživatel je m ůže m ěnit prost řednictvím obecného editovacího dialogu (viz 2.2.5).
2.3.6.1 Jednoduchá vlastnost Jednoduchá vlastnost není nositelkou žádné hodnoty, m ůže obsahovat pouze skupinu podvlastností. Její t řída Property je odvozena od AbstractGraphObject (Obrázek 2.22), od n ěj dědí schopnost mít kone čný seznam podobjekt ů a n ějaký popis v dialogu. K tomu přidává deklaraci metod nutných k editaci vlastností v dialogu (2.2.5). Jejich funk ční implementace je na odvozených t řídách. Stru čně se jedná o: Nastavení hodnoty vlastnosti. Povolení nebo zakázání zm ěn vlastnosti. Zapnutí nebo vypnutí vykreslování vlastnosti na plátn ě v četn ě možnosti provést tuto zm ěnu u všech vlastností v jejím podstromu.
2.3.6.2 Monitorovatelná vlastnost Vlastnost jejíž zm ěny může sledovat jiný objekt je tvo řena t řídou MonitorableProperty . Implementuje systém rozesílání zpráv poslucha čů m, který využívají odvozené t řídy. Poslucha č je objekt implementující rozhraní PropertyListener . To obsahuje jedinou metodu propertyChanged() , kterou vlastnost volá p ři zm ěnách. P ředává jí zprávu typu PropertyEvent . V té je uveden zdroj vzniku události (odkaz na vlastnost) a objekt nesoucí zm ěny vlastnosti. Obvykle se jedná o novou hodnotu vlastnosti a nebo o objekt sestavený na základ ě hodnot podvlastností (nap ř. font). Seznam poslucha čů si vlastnost udržuje v dynamickém poli. Umož ňuje jejich p řidávání a
38 odebírání. P ři klonování samotné vlastnosti a množiny poslucha čů na si na n ě aktualizuje odkazy.
2.3.6.3 Editovatelná vlastnost Aparát pro ukládání a na čítání hodnoty vlastnosti z XML dokumentu zavádí abstraktní třída EditableProperty . Každá vlastnost od svého super p ředka AbstractGraphObject dědí cestu k XML elementu ve výstupním dokumentu kam má být uložena. Editovatelná vlastnost k ní p řidává relativní cestu ( XMLPath viz Obrázek 2.22) pro uložení hodnoty vlastnosti. Sama žádnou hodnotu nenese. Její textovou podobu získává pomocí abstraktní metody setXMLPath() , kterou implementují odvozené t řídy. P ři na čítání se postupuje obdobn ě. Na čte se textová podoba hodnoty z XML dokumentu a p ředá se abstraktní metod ě setXMLValue() . Vlastnost pln ě implementuje propojení s vykreslova čem, který může zobrazovat její hodnotu na plátn ě. Odstín ění od konkrétní hodnoty je ud ěláno pomocí abstraktních metod getValue() a getValueStr() . První vrací p římo hodnotu, druhá hodnotu p řevedenou na textový řet ězec. Je na vykreslova či jakou z nich použije.
AbstractGraphObject
Property
MonitorableProperty «interface» PropertyListener 0..* 0..*
-vlastnost -cesta k hodnote XMLPath EditableProperty «interface» SkinChangeListener 1 1
0..1 «interface» «implements» 1 Renderer
PropertyTextChoice PropertyNumber PropertyText PropertyColor
Obrázek 2.22 Hierarchie t říd uživatelských vlastností.
2.3.6.4 Textová vlastnost K zachycení informací textového rázu o objektech slouží textová vlastnost. Používá se nap ř. pro názvy vrchol ů. Reprezentuje jí t řída PropertyText odvozená od EditableProperty. Zd ěděné abstraktní metody pro získání hodnoty ( getValue() , getValueStr() ), na čtení a uložení do XML dokumentu ( setXMLValue() , getXMLValue() ) implementuje jako triviální gettery a settery. P řináší jedinou funkci navíc
39 a to ov ěř ení jestli předaná hodnota spl ňuje její omezující podmínky. To se používá p řed nastavením vlastnosti v editovacím dialogu. Jediné možné omezení je zamítnutí prázdného textového řet ězce.
2.3.6.5 Číselná vlastnost Nositelkou numerických informací o objektech grafu je číselná vlastnost (t řída PropertyNumber , Obrázek 2.22). Umož ňuje uchovávat desetinná i celá čísla. Konkrétní typ je nastaven podle p ředané defaultní hodnoty p ři vytvo ření vlastnosti. Podporovány jsou typy double , float , long , integer a byte . Číselný rozsah daný typem je možné omezit nastavením intervalu povolených hodnot a to bu ď v četn ě a nebo mimo krajních hodnot. Vlastnost podporuje speciální druh p řevodu čísla na textový řet ězec a zp ět. Používá se při zobrazení v editovacím dialogu a na plátn ě. Spo čívá v nalezení co nejkratšího zápisu. Přitom m ůže být použit i vědecký formát. Nap ř. číslo 0,005 bude p řevedeno na „0,005“, ale 0,0005 už na „5E-4“. Funguje to i pro celá čísla. Pro desetinnou čárku se používá lokalizovaný znak. P ři ukládání do XML dokumentu je použit formát čísel odpovídající specifikaci datových typ ů15 ve W3C XML Schématu [3].
2.3.6.6 Vlastnost barva Informaci o barv ě nese vlastnost reprezentovaná t řídou PropertyColor . Nemusí se jednat o barvu vykreslovaného objektu (grafickou vlastnost). Barva je vnit řně reprezentována červenou, zelenou a modrou složkou (objektem Color z knihoven Javy). Alfa kanál není podporován. Pouze je jedna barva určena jako 100% pr ůhledná. Lze jí měnit u každé instance vlastnosti zvláš ť. S tím je možné nastavit i textový řet ězec, který ji reprezentuje v XML dokumentu. Standardn ě je to „transparent“. Jiné barvy se do XML ukládají a na čítají v CSS2 formátu [10] vyjma slovního pojmenování barev. Podporované tvary jsou: rgb(R, G, B) – kde R ( červená), G (zelená) a B (modrá) jsou barevné složky vyjádřené celým číslem 0 do 255 . Nap ř. fialová bude „rgb(255, 0, 255)“. rgb(R%, G%, B%) – kde R, G a B jsou procentuelní zastoupení jednotlivých barevných složek. Fialová barva bude uložena jako „rgb(100%, 0, 100%)“. #rrggbb – kde rr je hexadecimální zápis červené složky, gg zelené a bb modré. Pro fialovou barvu to je „#FF00FF". #rgb – což je hexadecimální zápis barev se dvojenými znaky. Fialová bude ve tvaru „#F0F“. (Podporováno pouze na čítání tohoto formátu.)
2.3.6.7 Výb ěrová vlastnost Výb ěrová vlastnost je nositelem informace, která nabývá jednu z množiny specifikovaných textových hodnot. Nap ř. vrchol p ředstavující osobu by mohl mít vlastnost národnost, která by mohla mít jednu z hodnot: { česká; slovenská; n ěmecká; ruská}. Vlastnost reprezentuje t řída PropertyTextChoice . Možné hodnoty vlastnosti jsou uloženy v poli jako textové řet ězce. Výb ěr aktuální probíhá na základ ě jejího indexu. Pokud je požadavek nastavit vlastnost na hodnotu podle její textové podoby najde se index sekven čním prohledáním pole. K poli hodnot existuje ješt ě prot ějšek s hodnotami, které se ukládají do výstupního XML dokumentu.
15 Stejné datové typy používá i Relax NG [1].
40 Volitelnou schopností vlastnosti je měnit skiny vrcholu sou časn ě se zm ěnou vlastní hodnoty. Ale jen za p ředpokladu, že je ve stromu vlastností vrcholu a může nabývat práv ě tolika r ůzných hodnot jako má vrchol skin ů. P řiřazení skin ů k hodnotám vlastnosti je realizováno polem klí čů skin ů. A to tak, že odpovídající si dvojice (hodnota, skin) mají ve svých polích stejný index. P ři nastavování aktuální hodnoty je pak klí č skinu získán prostou indexací a vrchol požádán o jeho nastavení. Aby nedošlo k nekonzistentnosti nastavený skin – hodnota vlastnosti v situaci, kdy vrcholu skin m ění více objekt ů je u něj vlastnost zaregistrována pro odb ěr události o zm ěně skinu. Po p řijetí zprávy o této události si automaticky nastaví odpovídající hodnotu. Další volitelnou schopností vlastnosti je prohazování jejího seznamu podvlastností. K tomu obsahuje pole seznam ů podvlastností, které velikostí odpovídá poli možných hodnot. Podvlastnosti ze seznam ů mohou také obsahovat podvlastnosti takže vlastn ě dochází k zám ěně celých podstrom ů vlastností. Zám ěna seznamu probíhá tak, že se u starého seznamu vynutí u všech vlastností skrytí jejich vykreslova če, pokud byly zobrazeny, a zapamatování že tuto akci provedly. Pak se seznamy prohodí a u všech vlastností z nov ě nastaveného seznamu se požádá o to, aby zobrazily vykreslova če skryté v minulosti operací provedenou na starém seznamu. Klonování vlastnosti má svá specifika. Pole možných hodnot vlastnosti, pole hodnot pro uložení do XML a pole skin ů (pokud existuje) klonováno není. Ale pole seznam ů podvlastností klonováno je a to do hloubky pomocí metod z rozhraní TreeCloneable . Kdyby se to ned ělalo sdílely by jednotlivé instance, vytvá řené klonováním, seznamy podvlastností. D ůsledkem by bylo nežádoucí chování, kdy zm ěna hodnoty podvlastnosti u jedné instance zm ění tu samou hodnotu u instance druhé. 2.3.7 Grafické vlastnosti Grafické vlastnosti slouží k zachycení a někdy jen zp řístupn ění, uložení a na čtení hodnot, které ur čují styl vykreslení vrchol ů, hran a vlastností (pomocí vykreslova čů ), pozice objekt ů na kreslícím plátn ě, jejich nato čení, identifikátory atp. Zpravidla jsou odvozeny a nebo složeny z uživatelských vlastností.
2.3.7.1 Tah čáry a výpl ň Parametry tahu čáry a výpln ě postihují vlastnosti PropertyLineGraphics a PropertyFillGraphics . Jsou odvozeny od t řídy Property a implementují rozhraní PropertyListener . Samotné údaje jsou uloženy v podvlastnostech. U výpln ě je to pouze barva reprezentovaná t řídou PropertyColor . U tahu čáry to jsou: Barva čáry jako instance t řídy PropertyColor . Styl vykreslení čáry jako instance t řídy PropertyTextChoice s výb ěrem z hodnot: {plná, čárkovaná, te čkovaná}. Hodnoty jsou lokalizované. Vlastnost je vytvá ří načtením ze zdroj ů (resources) editoru. Výstupní hodnoty do XML dokumentu jsou přednastaveny na {solid, dash, dot}, ale lze je ovlivnit definicí v podp ůrných definicích. Tlouš ťka čáry reprezentovaná instancí t řídy PropertyNumber nastavenou na typ float s omezením na nezáporná čísla. O zm ěně jednotlivých podvlastností jsou ob ě vlastnosti informovány prost řednictvím zasílaných zpráv (princip v 2.3.6.2). Samy, ale zprávu o zm ěně nezasílají to musí zajistit objekt, který jí inicioval. Výhradn ě to je editovací dialog, který po zm ěně jakékoli vlastnosti objektu vynutí jeho p řekreslení. To ale neznamená p řepo čítání geometrie, která
41 závisí na tlouš ťce tahu čáry. Proto PropertyLineGraphics poskytuje metodu setLineWidthListener (), která registruje poslucha če zm ěn u podvlastnosti reprezentující tlouš ťku. Ob ě vlastnosti umož ňují přímo nastavit kontext za řízení. Metoda, která to zajiš ťuje vrací true pokud má smysl n ěco vykreslovat, jinak false , což znamená, že je nastavena barva na pr ůhlednou.
2.3.7.2 Font Třída PropertyFont obsahuje vlastnosti popisující font. Je odvozena od t řídy MonitorableProperty ( Obrázek 2.23 ), aby mohla informovat okolí o zm ěnách, nebo ť zm ěna fontu vyžaduje p řepo čítání geometrie (viz 0). Konkrétní atributy fontu obsahují podvlastnosti: PropertyFontFamily – rodina písma. PropertyTextChoice – tvar písma. Možné hodnoty jsou {normální, kurzíva, sklon ěné}. PropertyNumber – velikost písma. Omezeno na nezáporné hodnoty typu float . PropertyTextChoice – duktus (váha) písma. Možnosti jsou {normální, tučný}. PropertyTextChoice – dekorace písma. S možnostmi {nic, podtržení, nadtržení, přeškrtnutí}. PropertyTextChoice – horizontální zarovnání textu. Možnosti jsou {doleva, na st řed, napravo}. (Vertikální zarovnání je pevn ě na ú čaří.) PropertyColor – barva písma. Instance t řídy PropertyFont je svých podvlastností registrována pro odb ěr události o zm ěnách hodnoty. Pokud dojde ke zm ěně jedné z vlastností sestaví objekt Font (z knihoven Javy) a sama rozešle událost o zm ěně hodnoty. Na stejném principu je založeno na čítání a ukládání parametr ů písma do XML dokumentu grafu, kdy je vše na podvlastnostech. PropertyFont pouze vyzve všechny podvlastnosti k uložení resp. na čtení.
42 Property
PropertyFillGraphics MonitorableProperty PropertyLineGraphics
EditableProperty PropertyFont
PropertyNumber PropertyText PropertyTextChoice PropertyID
PropertyRotation PropertyPosition PropertyToolInfo PropertyFontFamily
Obrázek 2.23 Odvození grafických vlastností od uživatelských (vypln ěné te čkami), asociace mezi t řídami jsou pro p řehlednost vynechány.
2.3.7.3 Rodina písma Třída PropertyFontFamily obsahuje název rodiny písma. Je odvozena od t řídy PropertyTextChoice ( Obrázek 2.23 ), které automaticky nastaví pole možných hodnot. Ty se dají rozd ělit na standardní HTML a systémové rodiny písma. První obsahuje písma serif , monotype a sans-serif , která jsou mapována na interní písma knihoven Javy (Tabulka 2.1). Mapování p římo zajiš ťuje pomocný objekt FontList . Ten zárove ň umož ňuje získání názv ů systémových font ů (fonty poskytované opera čním systémem), které se mohou lišit na každém uživatelském PC. Do XML dokumentu grafu vlastnost ukládá bu ď HTML název rodiny písma a nebo přímo systémový název fontu. Pokud je pak dokument grafu otvírán na PC, kde není nainstalováno použité systémové písmo je místo n ěj použito Serif s tím, že si vlastnost uchová i název neznámé rodiny. Tu drží tak dlouho dokud uživatel neprovede zm ěnu hodnoty vlastnosti. A pokud se tak nestane do okamžiku uložení do XML dokumentu grafu bude do n ěj uložen název neznámé rodiny fontu.
Tabulka 2.1 P řiřazení rodin font ů z knihoven Javy rodinám z HTML. Název v HTML Název v Jav ě serif Serif sans-serif SansSerif monotype Monospaced
43 2.3.7.4 Sou řadnice pozice Sou řadnici pozice objektu zachycuje t řída PropertyPosition odvozená od PropertyNumber ( Obrázek 2.23 ), kterou inicializuje na datový typ Double . Pozice grafických objekt ů je intern ě uložena v objektu grafického objektu. Vlastnost PropertyPosition zajiš ťuje pouze její zobrazení, editaci v dialogu, uložení a na čtení do XML dokumentu grafu. Pro zaznamenání pozice musejí existovat dv ě instance jedna pro x-ovou a druha pro y-ovou sou řadnici. Ob ě si udržují referenci na nad řazený objekt typu Movable a to jakou sou řadnici p ředstavují. P ři zm ěně hodnoty vlastnosti je vyžádán posun nad řazeného objektu pomocí metody translate() ve sm ěru jedné osy o rozdíl nové a staré hodnoty. Úpln ě stejn ě je to provedeno p ři na čtení z XML dokumentu grafu, jež je provád ěno p ředkem PropertyNumber tak jako ukládání. PropertyPosition pouze zjistí aktuální polohu nad řazeného p ředka a předá jí metodám z PropertyNumber .
2.3.7.5 Nato čení objektu Nato čení objektu postihuje vlastnost tvo řená t řídou PropertyBearing odvozená od PropertyNumber . Nato čení objektu je jeho azimut (Obrázek 2.24) tj. úhel od x-ové osy sou řadného systému umíst ěného do bázového bodu objektu, kladný pokud jde proti sm ěru hodinových ru čiček. Samotný údaj o nato čení objektu je uložen v nad řazeném grafickém objektu typu Rotable . Nap ř. u vrcholu je obsažené v afinní transformaci generující jeho tvar. Vlastnost si jeho hodnotu vyžádá pokud jí chce zobrazit nebo uložit do XML dokumentu grafu. V editovacím dialogu je zobrazován vždy úhel ve stupních v rozmezí od -180 do 180 včetn ě. Uživatel m ůže zadávat hodnoty od -360 do 360 , které jsou p řepo čítány na radiány a poslány nad řazenému objektu, aby se nato čil. Do výstupního dokumentu grafu vlastnost ukládá úhel v radiánech a nebo stupních podle toho jak to p ředepisují podp ůrné definice. Ukládaná hodnota je v rozmezí od -180 do 180 pro stupn ě a od -π do π v četn ě pro radiány. Načítaná hodnota je omezena stejn ě jako při editaci v dialogu tj. na interval od -2 π do 2 π. Samotné uložení nebo na čtení zajiš ťují metody p ředka PropertyNumber , kterým je p ředána hodnota ve správných jednotkách.
Obrázek 2.24 Konvence pro nato čení objektu β, B je bázový bod objektu.
2.3.7.6 ID objektu Jednozna čný identifikátor grafického objektu zobrazuje, ukládá a na čítá z XML dokumentu grafu vlastnost reprezentovaná t řídou PropertyID . Která je odvozena od t řídy EditableProperty ( Obrázek 2.24 ). Identifikátor je intern ě uložen v grafickém objektu.
44 Vlastnost ho od n ěj získává pokaždé když ho pot řebuje. Je to tak proto, že ne každý objekt, který má své ID má i tuto vlastnost a zobrazování nebo ukládání vlastnosti neprobíhá tak často jako nap ř. vyjímání objektu z uložišt ě grafických objekt ů, kdy se ID používá jako klí č do p říslušné mapy. Dalším d ůvodem je pot řeba pomocí vlastnosti zachytit skute čnost, kdy je jeden objekt v relaci s jiným. V grafu to je napojení hrany na vrcholy, kdy je jejich vztah ve výstupním dokumentu uložen v elementu hrany jako ID vstupního a výstupního vrcholu. Vlastnost je v editovacím dialogu pouze zobrazitelná. Zm ěnu její hodnoty tj. identifikátoru objektu uživatel nem ůže provést. Pokud by byla zm ěna povolena musel by být k přinesenému užitku neúm ěrn ě složit ější generátor ID (z oddílu 2.3.3), hrana (viz 2.3.5.1) a uložišt ě grafických objekt ů (viz 2.2.4). U posledních dvou je to zp ůsobeno přesunutím omezení, které typy vrchol ů hrana m ůže obsahovat na stranu uložišt ě objekt ů. V omezené mí ře je možné vlastnost zobrazit na kreslícím plátn ě pomocí vykreslova če vlastností jako text. Ten nelze posouvat, otá čet a měnit atributy jeho písma. Reflektuje to skute čnost, že je ID p ředevším interní popis objektu. Popis (identifikátor, jméno objektu) pro uživatele by m ěla zajiš ťovat n ěkterá uživatelská vlastnost (2.3.6).
2.3.7.7 Jméno a verze editoru Informace o editoru lze do výstupního dokumentu uložit pomocí vlastnosti tvo řené třídou PropertyToolInfo . Ta je odvozena od vlastnosti PropertyText a je trvale neviditelná v editovacím. Obsahuje text, který je bu ď jméno programu tvo řícího editor (VSPNE 16 ) a nebo jeho verzi. Oba údaje jsou na čítány z textového souboru, který je uložen v archivu programu (JARu). Který údaj má vlastnost obsahovat specifikuje uživatel v podp ůrných definicích. Jedinou schopností a také ú čelem vlastnosti je uložit tyto údaje do výstupního dokumentu grafu. 2.3.8 Po čátek grafu Objekt tvo řící ko řen stromu vlastností celého grafu a sloužící k navázání jejich vykreslova čů je reprezentován t řídou GraphPropertiesBase odvozenou od t řídy GraphicalObject . Graf muže obsahovat strom vlastností, které nejsou navázané ani na vrchol ani na hranu. Tyto vlastnosti je možné zobrazovat pomocí vykreslova čů (viz 2.3.9 ), které se zobrazují v nějaké vzdálenosti od bázového bodu jiného grafického objektu. A práv ě GraphPropertiesBase poskytuje bázový bod umíst ěný do po čátku logického souřadného systému všem vykreslova čů m vlastností celého grafu. Funkcionalitu, deklarovanou p ředkem GraphicalObject , zam ěř enou na grafické znázorn ění objektu implementuje jako prázdnou a p ři volání p říslušných metod vyhazuje výjimku UnsupportedOperationException.
2.3.9 Vykreslova č vlastností
2.3.9.1 Abstraktní vykreslova č Zobrazení všech uživatelských vlastností a vlastnosti PropertyID na kreslícím plátn ě zajiš ťuje vykreslova č vlastností, který není ukládán do XML dokumentu grafu a není součástí stromu vlastností definovaném rozhraním GraphObject (viz 2.3.1). P ředkem
16 VSPNE je ozna čení pro tento editor. Zkratka je z anglického Variable Stochastic Petri Net Editor tj. prom ěnný editor Stochastických PN.
45 všech vykreslova čů vlastností je t řída AbstractRenderer , která částe čně implementuje rozhraní Renderer (Obrázek 2.25). P řesn ěji implementuje funkcionalitu danou rozhraním Storable tj. vše pot řebné pro uložení vykreslova če do uložišt ě grafických objekt ů. Vykreslení a napojení na hranu je ponecháno na odvozených t řídách. Vykreslova č samostatn ě bez vlastnosti nemá smysl. Jednak od ní získává hodnotu, kterou n ějak graficky vyjád ří a pak s ní také sdílí grafické vlastnosti popisující jeho atributy. Ty má vykreslovaná vlastnost za řazené do svého stromu podvlastností, ukládá je do XML dokumentu grafu. Jejich vytvoření, ale je na vykreslova či, který je hran ě poskytne po propojení s ní. Vykreslova č vlastnosti je uložen v uložišti grafických objekt ů, které ho p ři b ěžném překreslení grafu vykreslí. P řitom zaru čí, že budou vykreslova če vykreslovány jako poslední (nic je nep řekryje). Pro uložení do uložišt ě t řída AbstractRenderer poskytuje funkce obdobné t ěm co implementuje t řída GraphicalObject (viz 2.3.3). Stru čně se jedná o vložení a vyjmutí z uložišt ě, naklonování se, vygenerování nového ID. Zásadní rozdíl oproti GraphicalObject je v tom, že obsahuje konstantní typ objektu („ renderer “). Druh vykreslova če je ur čen pouze jeho t řídou. D ůsledkem je, že jsou všichni vykreslova či uloženi do jedné mapy v uložišti a sdílejí jeden generátor ID. Pro ten je rezervovaný prefix identifikátoru „ $#PR “. ID vykreslova če se nikam neukládá a slouží pouze pro jeho rychlé nalezení v uložišti, to nap ř. pro jeho do časné vyjmutí, když je t řeba, aby se nevykresloval na plátn ě.
Obrázek 2.25 Strom d ědi čnosti vykreslova čů a navázání na vlastnost.
2.3.9.2 Vykreslova č textu Vykreslova č zobrazující hodnotu vlastnosti jako jednu řádku textu je tvo řen t řídou TextRenderer , která je odvozena od AbstractRenderer . Vykreslova č je napojen na vlastnost, jejíž hodnotu zobrazuje a na grafický objekt, který ve svém stromu vlastností obsahuje vykreslovanou vlastnost. Onen grafický objekt je vždy hrana, vrchol nebo GraphPropertiesBase . K propojení s ním dochází už p ři na čítání podp ůrných definic na úrovni šablony a nelze ho zm ěnit. Oproti tomu se vykreslova č m ůže napojovat na vlastnost kdykoli, ale jen za podmínky, že je cílová vlastnost ve stromu vlastností grafického objektu, na který je vykreslova č napojen. Propojení vykreslova če s vlastností znamená p ředevším zaregistrování vykreslova če pro odb ěr zpráv o zm ěně hodnoty a sdílení grafických vlastností. To jsou:
46 PropertyFont – popis atribut ů fontu. PropertyPosition – vzdálenost vykreslova če od nad řazeného grafického objektu. PropertyBearing – nato čení textu vykreslova če. Sdílené vlastnosti slouží k editaci grafických vlastností vykreslova če a k uložení příslušných hodnot do XML dokumentu grafu. Tam jsou tvo řeny podelementy anebo atributy elementu vlastnosti. Z toho také vyplývá, že vlastnost jejíž hodnota je perzistentn ě uložena jako atribut m ůže být vykreslena, ale všechny její (a tak i vykreslova če) grafické vlastnosti budou pro uživatele nem ěnitelné. Napojení na grafický objekt ur čuje polohu vykreslova če. Ta je dána bázovým bodem vykreslova če V, který se nachází v uživatelem ur čené vzdálenosti ( xoffset , y offset ) od bázového bodu B grafického objektu (Obrázek 2.26). Vykreslova č je u grafického objektu registrován pro odb ěr zpráv o zm ěně polohy, čímž je zajišt ěn jejich sou časný posun.
Obrázek 2.26 Navázání vykreslova če na grafický objekt, B je bázový bod graf. objektu, V vykreslova če.
Geometrický tvar textu je intern ě reprezentován jako GlyphVector z knihoven Javy a úse čka (Line2D ) tvo řící podtržení, nadtržení nebo p řeškrtnutí. Obojí dopl ňuje obdélník (Rectangel2D ) reprezentující bounding box (oblast pro detekci jestli n ějaký bod spadá do vykresleného textu). GlyphVector je řada pozic jednotlivých znak ů tvo řících nápis a lze ho p římo vykreslit na ur čenou pozici pomocí kontextu za řízení ( Graphics2D ). Tvar znak ů ur čuje t řída Font z Java knihoven, která umož ňuje získat základní geometrii písma – písmovou osnovu 17 (Obrázek 2.27). Pokud není m ěněna poloha vykreslova če, rotace, hodnota vykreslované vlastnosti a atributy fontu je vykreslení triviální. Nastaví se barva kontextu za řízení ( Graphics2D ), p ředá se mu k vykreslení vektor znaku ( GlyphVector ) s ur čením jeho polohy a pokud existuje tak dekora ční úse čka. Poloha vektoru znak ů je ur čována vzhledem k bázovému bodu vykreslova če. Vertikáln ě je text umíst ěn tak aby byl bázový bod na základní dotažnici (ú čaří, base line, viz Obrázek 2.27). Horizontální umíst ění je ur čeno podle zarovnání textu. Pokud má být text zarovnán doleva je bázový bod vykreslova če slícován s bodem TL, pokud na st řed tak s bodem TS a p ří zarovnání doprava s bodem TR. Dekora ční úse čka je sestrojena o délce k jako ekvidistanta základní dotažnice. Ekvidistantní vzdálenost (Obrázek 2.28) je bu ď p římo poskytnuta t řídou Font a nebo p řibližn ě ur čena, což je nutné v případ ě, že zvolený font (rodina) vzdálenost pro podtržení ( τ), nadtržení ( µ) a p řeškrtnutí (ε) neobsahuje. P řibližná vzdálenost nadtržení µ se bere jako akcentová dotažnice. Vzdálenost p řeškrtnutí je ε = 4.0 h , kde h je vzdálenost mezi ú čařím a horní dotažnicí. Odhad ekvidistantní vzdálenosti úse čky tvo řící podtržení je τ = 75.0 d , kde d je vzdálenost mezi dolní a základní dotažnicí. Zbývá sestrojení bounding boxu. GlyphVector sice poskytuje metodu pro jeho získání, ale p ři nato čení textu je p říliš nepřesný (Obrázek 2.29, p řípad B). Proto je bounding box sestrojen jako obdélník (Obrázek 2.29, p řípad A) o ší řce k a výšce dané délkou kolmice vedoucí od dolní dotažnice k akcentové tj. a+d (Obrázek 2.27).
17 O geometrii písma lze najít více informací v [8].
47
ÁProperty
Obrázek 2.27 Písmová osnova ÁProperty
Obrázek 2.28 Polohy dekora ční úse čky s vyzna čením ekvidistantních vzdáleností µ, τ, ε v ůč i ú čaří.
Při zm ěně polohy vykreslova če textu je vektor znak ů vykreslován do posunuté polohy. Na dekora ční úse čku a bounding box je aplikována afinní transformace – translace, která vygeneruje nové, posunuté tvary ( Shape ). Ty jsou pak standardním zp ůsobem vykresleny Pokud má být text otá čen, je zm ěněna vykreslovaná hodnota a nebo jsou zm ěněny parametry fontu (duktus, velikost, rodina, tvar) je nejprve vytvo řen font ( Font ). Z jeho písmové osnovy se sestrojí dekora ční úse čka a bounding box. Pak se jednotlivé znaky fontu pomocí afinní transformace ( AffineTransform ) nato čí do požadovaného sm ěru. Nato čený font vygeneruje vektor znak ů ( GlympVector ), který se vykreslí. Stejná transformace se použije na vytvo řenou dekora ční úse čku a obdélník bounding boxu.
ÁP ÁP rop rop erty erty
Obrázek 2.29 Bounding box nato čeného textu, p řípad A p řesn ě vypo čítaný, B ur čený knihovnami Javy.
48 2.3.10 Výb ěr hran a vrchol ů Spole čnou manipulaci s množinou vrchol ů a hran zajiš ťuje t řída Selection (Obrázek 2.30), reprezentující do časný grafický objekt. Vzniká p ři požadavku posouvat a nebo smazat skupinu vrchol ů a hran. Vytvo ření provádí uložišt ě grafických objekt ů na požádání kreslící komponenty (plátna). To s výb ěrem pracuje stejn ě jako kdyby se jednalo nap ř. o jeden vrchol a to díky tomu, že Selection implementuje rozhraní stejná jako jednotlivé objekty. Možnosti t řídy jsou: Posouvat a mazat množinu vrchol ů a hran. Naklonovat se hloubkov ě s obnovením referencí u všech obsažených objekt ů. Vyjmou vybrané objekty z uložišt ě grafických objekt ů. Nastavit nová ID všem vybraným objekt ům (použitu u kopírování výb ěru v kombinaci s posunem a klonováním). Vykreslit všechny objekty na plátno s vynucením jejich barvy a potla čením vykreslení pozadí. Vymazat vybrané objekty. Vrátit všechny výše vyjmenované akce zp ět pomocí svého klonu uloženého do historie úprav grafu (undo operace).
«interface» «interface» Drawable «interface» Erasable Movable
«implements» «implements» «implements» «implements» «interface» TreeCloneable «interface» «implements» Selection Connectable «implements» «interface» Storable
Obrázek 2.30 Rozhraní implementované objektem sdružujícím hrany a vrcholy do skupiny.
49 3 Propojení s XML
3.1 Podp ůrné definice 3.1.1 Základní koncepce Strukturu, zp ůsob grafické reprezentace a formát uložení grafu určují tzv. podp ůrné definice, které jsou založeny na Relax NG dopln ěného o elementy z pomocného prostoru jmen. Strukturu grafu z velké časti reflektuje datový formát jeho perzistentního uložení. Ten jsem omezil na XML dokumenty, jejichž strukturu lze popsat pomocí standardizovaného formátu DTD (Document Type Definition), WXS 18 (W3C XML Schéma) nebo RNG (Relax NG 19 ). DTD pochází z jazyka SGML, neobsahuje prostory jmen, používá vlastní syntaxi a je vhodné spíše pro definování popisu textových dokument ů, nikoli datových. Proto jsem ho nepoužil. Volba mezi WXS a RNG už nebyla tak jednozna čná. Oba zp ůsoby popisu XML dokumentu podporují prostory jmen, jejich syntaxe je stejná jako u XML dokumentu 20 a jsou vhodné i pro definování XML dokument ů datové povahy. P řiklonil jsem se k RNG, protože je jednodušší než WXS, je standardem ISO [9] a lze ho p řevést na WXS. Scéná ř vytvá ření podp ůrných definic je následující. Uživatel vytvo ří RNG schéma XML dokumentu, do kterého bude uložen graf. Schéma p řevede na ploché a doplní do n ěj zna čky z pomocného prostoru jmen, kterému říkejme SD (od Support Definitions). Kostru podp ůrných definic tvo ří ploché RNG schéma XML dokumentu pro perzistentní uložení grafu, které jednozna čně říká jak budou uloženy objekty tvo řící graf. Schéma musí být nutn ě ploché, protože datov ě stejné části dokumentu mohou významov ě v grafu reprezentovat odlišné objekty. RNG schéma je uživatelsky p říjemn ější vytvá řet a používat jako neploché a tak jsem vytvo řil XSL transformaci (10.3 a 10.4) , která nahradí elementy
18 W3C XML Schéma je často ozna čováno zkratkou WXS a XSD. Zkrácen ě se mu říká „XML Schéma“ a to i p řesto, že Relax NG je také XML schéma. 19 Relax NG je zkratkou REgular LAnguage for XML Next Generation. Jeho zápis pomocí syntaxe XML se obvykle ozna čuje RNG. 20 WXS a RNG jsou XML dokumenty definující strukturu XML dokument ů, mohou popsat i sami sebe.
50 3.1) obsahuje pomocný element
Výpis 3.1 Zano ření definice XML elementu do elementu z pomocného prostoru jmen SD.
Hlavní elementy z prostoru jmen podp ůrných definic (SD) jsou
51 volitelně element
Výpis 3.2 P říklad definování po čátku grafu v podp ůrných definicích, element
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" ns="http://www2.stpnplay.com/vspne/schema/Genealogy" datatypeLibrary="http://.../XMLSchema-datatypes">
Nejd ůležit ějším atributem elementu
Tabulka 3.1 Atributy elementu
52 Zapouzd řená RNG definice (
Výpis 3.3 P říklad definice typu vrcholu v četn ě povinných grafických vlastností.
53
Atribut type-name elementu
Tabulka 3.2 Atributy elementu
Tabulka 3.3 Typy grafických vlastností podporovaných vrcholem. Typ vlastnosti Popis Povinná position Interní identifikátor typu vrcholu. ANO id ID vrcholu. ANO rotation Nato čení vrcholu. NE line-color Barva čáry obrysového tvaru vrcholu. NE line-style Styl čáry obrys. tvaru vrcholu (plná, čárkovaná, ...) NE line-width Tlouš ťka čáry obrysového tvaru. NE inner-line-color Barva čáry vnit řního tvaru vrcholu. NE inner-line-style Styl čáry vnit řního tvaru. NE inner-line-width Tlouš ťka čáry vnit řního tvaru. NE
Grafický popis vrcholu je obsažen v elementu
54 3.1.4 Skin vrcholu Skin vrcholu popisuje grafické znázorn ění vrcholu, je reprezentován elementem
Tabulka 3.4 Atributy elementu skinu
Skin se skládá z obrysového tvaru, vnit řního tvaru a bázového bodu. Definice geometrie obrysového tvaru (Výpis 3.4) je povinná a tvo řena vý čtem primitivních grafických prvků (popis níže), z kterých je složen výsledný geometrický útvar. Ten musí být jednoduchý a uzav řený. Voliteln ě ho lze doplnit definicí defaultních atribut ů jeho čáry a výpln ě v podob ě elementu
Výpis 3.4 Základní kostra definice skinu vrcholu.
. . .
21 Atribut id skinu je v RNG schématu podp ůrných definic typu ID. Pokud podle schématu mají být podp ůrné definice validní musí být id skinu unikátní pro všechny definice vrchol ů, ale editor to vyžaduje pouze v rámci definice jednoho.
55
Popis p řednastaveného stylu čáry a výpln ě obrysového a nebo vnit řního tvaru vrcholu je tvo řen elementem
Výpis 3.5 Elementy definující atributy vykreslení čáry a výpln ě.
Tabulka 3.5 Atributy elementu
Vnit řní nebo vn ější geometrický tvar vrcholu je složen z jednoho a více primitivních prvk ů, které jsou kruh (
56 Příkladem je seskupení dvou kruh ů a úse ček (Obrázek 3.1). Naopak p ři skládání tvar ů z úse čky, oblouku a kubické Bézierovy k řivky na po řadí jejich definic záleží. Aby primitivy tohoto typu byly vzájemn ě navázány musí elementy jejich definic být se řazeny tak jak na sebe navazují ve výsledném tvaru. Přitom koncový bod jednoho segmentu musí ležet v po čáte čním bodu segmentu, jehož definice následuje (Obrázek 3.2, p řípad A). Spojení navázaných segment ů je „ostré“. Naproti tomu pokud dva segmenty nenavazují a jejich po čáte ční resp. koncové body leží na sob ě je místo jejich styku oblé a p ři pokusu vyplnit zdánliv ě uzav řený tvar dostaneme chybný výsledek (Obrázek 3.2, p řípad B). Pro geometrická primitiva jsem zavedl vlastní definice (zna čky). Na první pohled se nabízí pro popis tvaru využít n ějaký již existující jazyk založený na XML. Konkrétně SVG 22 . Tuto cestu jsem nezvolil, nebo ť je SVG příliš složité, definuje spole čně s popisem geometrie grafické atributy (výpl ň atp.) a používá diskutabilní konstrukce jako nap ř. seznam n ěkolika bod ů v jednom atributu. P ředevším možnost v SVG definovat širokou škálu typ ů čar, výplní a transformací separátn ě pro jednotlivé geometrické prvky by vedla k tomu, že bych musel popis drasticky omezit, protože je v editoru zna čně jednodušší, uveden jen pro celý tvar a v důsledku od n ěj separován do vlastností. Stejn ě tak by bylo nutné omezit nabízené geometrické prvky (nejsou podporovány kvadratické Bézierovy křivky p ři napojování hran). Ve výsledku bych tak byl nucen definovat vlastní popis, který by se tvá řil jako SVG a přinášel jeho neduhy jako již zmín ěné atributy se seznamem bodů23 , což dle mého mín ění popírá hierarchický popis objekt ů. Jejich dekompozici na jednodušší, což vidím jako jeden ze základních princip ů XML. Z těchto d ůvod ů jsem zavedl vlastní popis p řizp ůsobený p řesn ě možnostem editoru.
Obrázek 3.1 Seskupení primitivních geometrických tvar ů bez vzájemného navazování.
Úse čka Úse čku definuje element
Oblouk Element
22 SVG je zkratka Scalable Vector Graphics, což je standardizovaný XML formát pro popis vektorové grafiky zaštít ěný W3C. 23 P říklad takové definice je element
57
Obrázek 3.2 Navazování primitivních geom. prvk ů (zde úse ček), p řípad A uzav řená cesta, p řípad B neuzav řená (segmenty 2, 3 a 4 nenavazují).
Definice oblouku ur čeného dv ěma body obsahuje povinn ě element
Obrázek 3.3 Parametry definice oblouku ur čeného pomocí dvou bod ů, B a E jsou jeho po čáte ční a koncový bod.
58
Tabulka 3.6 Atributy elementu
Definice oblouku te čného na dv ě úse čky obsahuje t ři elementy
Obrázek 3.4 Význam parametr ů definice oblouku ur čeného te čnými úse čkami, Z je po čáte ční bod oblouku, K koncový.
Kubická Bézierova k řivka Kubickou Bézierovu k řivku 24 definuje element
24 Více o Bézierových k řivkách v [11].
59
Obrázek 3.5 Kubická Bézierova k řivka a její definice, A je po čáte ční kontrolní bod, B koncový, C a D jsou mezilehlé.
Kružnice Element
Elipsa Elipsu definuje element
Obrázek 3.6 Příklad definice elipsy, S je její st řed.
Obdélník Definicí obdélníku je element
Obrázek 3.7 Příklad definice obdélníku, bod T ur čuje jeho polohu.
60 3.1.5 Vyzna čení hrany RNG element definující element v dokumentu grafu obalený elementem
Výpis 3.6 P říklad definice zaoblené hrany v četn ě povinných grafických vlastností.
61
Povinné atributy elementu
62 Tabulka 3.7 Grafické vlastnosti podporované hranou. Typ vlastnosti Popis Povinná id ID hrany. ANO source-id ID výstupního vrcholu hrany. ANO target-id ID vstupního vrcholu hrany. ANO edge-cp Pozice mezilehlých kontrolních bod ů. ANO line-color Barva čáry hrany. NE line-style Styl čáry hrany (plná, čárkovaná, te čkovaná) NE line-width Tlouš ťka čáry hrany. NE
Obrázek 3.8 Definice koncové šipky hrany.
3.1.6 Jednoduché vlastnosti Jednoduchá uživatelská vlastnost slouží k zachycení jedné hodnoty charakterizující nad řazený objekt. Jejím rozší řením je grafická vlastnost (viz 3.1.7). Vlastnost tvo ří element
Výpis 3.7 P říklad základní konstrukce definice jednoduché uživatelské vlastnosti.
63
Hlavním atributem elementu vlastnosti
Tabulka 3.8 Atributy elementu
Příznak true* lze m ěnit hodnotu vlastnosti editable NE boolean editovatelnosti. false hodnotu nelze m ěnit Příznak zda se true bude zobrazena na plátn ě draw má defaultn ě NE boolean vykreslit. false* nebude zobrazena
Tabulka 3.9 Grafické vlastnosti podporované jednoduchou uživatelskou vlastností. Typ vlastnosti Popis Povinná
64 font-color Barva písma. NE font-family Rodina písma. NE font-style Tvar písma (normální, kurzíva, sklon ěné) NE font-size Velikost písma. NE font-align Zarovnání textu. NE font-weight Duktus (váha) písma. NE font-decoration Dekorace textu (nic, podtržené, nadtržené, p řeškrtnuté) NE visibility Příznak jestli je vlastnost zobrazena na plátn ě. NE rotation Nato čení vykreslova če vlastnosti. NE offset Vzdálenost vykreslova če od referen čního objektu. NE
Element
Výpis 3.8 Definice vlastnosti bez ko řenového elementu (a tak bez podvlastností).
65
Tabulka 3.10 Atributy elementu
Konstanta Konstantní vlastnost jako RNG definici datového typu obsahuje element
Výpis 3.9 P říklad definice konstantní vlastnosti.
Text a barva Pokud je definice datového typu tvo řena RNG elementem
66 barva a element
Tabulka 3.11 Atributy elementu
Výpis 3.10 Definice vlastnosti nesoucí barvu.
67 Hodnota číselné povahy Číselná vlastnost obsahuje RNG definici datového typu ve tvaru s tím, že atribut type nabývá jedné z hodnot: decimal – reálné číslo float – 32 bitové desetinné číslo podle IEEE 754-1985 double – 64 bitové desetinné číslo podle IEEE 754-1985 integer – celé číslo bez dalšího omezení long – celé číslo od -9223372036854775808 do 9223372036854775807 v četn ě. int – celé číslo od -2147483648 do 2147483647 v četn ě. short – celé číslo od -32768 do 32767 v četn ě. byte – celé číslo od -128 do 128 Voliteln ě m ůže element obsahovat omezení reprezentovaná elementem (Výpis 3.11). Typ omezení je dán hodnotou jeho atributu name , podporované typy uvádí Tabulka 3.12. Intern ě je vlastnost obsahující hodnotu číselné povahy reprezentována instancí t řídy PropertyNumber (2.3.6.5),
Tabulka 3.12 Podporované hodnoty atributu name elementu pro omezení číselných datových typ ů. Hodnota Význam minIclusive Minimální možná hodnota v četn ě. minExclusive Spodní limit hodnoty. maxInclusive Maximální možná hodnota v četn ě. maxExclusive Horní limit hodnoty.
Výpis 3.11 Definice číselné vlastnosti omezené na hodnoty z intervalu <-100, 1000).
Výb ěr z několika položek Výb ěrová vlastnost obsahuje RNG definici datového typu založenou na elementu
68 v podob ě atributu dlabel . Jako výchozí hodnota vlastnosti bude zvolena položka s atributem default a nebo prvn ě uvedená. Při absenci atributu dlabel bude místo jeho hodnoty použita hodnota uvedená v elementu
Výpis 3.12 P říklad definice jednoduché výb ěrové vlastnosti.
Omezením vlastností je, že jedné definici v rámci definice typu vrcholu nebo hrany odpovídá jedna vlastnost ve výstupním dokumentu grafu. Nelze tedy p ředepsat vlastnost jejíž ko řenový element bude v RNG schématu výstupního dokumentu grafu definován jako mnohonásobný (
25 To odpovídá kontextovému modelování v RNG blíže viz [2].
69 vlastnosti sady definovány v elementu
Výpis 3.13 P říklad definice skupinové výb ěrové vlastnosti.
Skupinová výb ěrová vlastnost nepodporuje žádné grafické vlastnosti. Obsahuje sice vykreslova č (
70 nár ůst složitosti t řídy PropertyTextChoice , která vlastnost intern ě reprezentuje. Grafické vlastnosti by totiž musely být definovány duplicitně v každé sad ě podvlastností a p ři zm ěně hodnoty vlastnosti (vybrání jiné položky) by se musely od vykreslova če odpojit grafické vlastnosti z předchozí sady a napojit ty z práv ě zvolené. 3.1.8 Grafické vlastnosti Definice grafických vlastností vyzna čují místa kam se uloží atributy grafické reprezentace objekt ů, jejich ID a speciální hodnoty jako nap ř. název a verze editoru. Vlastnosti neobsahuji žádné podvlastnosti a ani je nelze, s výjimkou té co obsahuje ID objektu, zobrazit na kreslícím plátn ě. Struktura definic je v základu stejná jako u uživatelských vlastností. Zm ěnou je vynechání popisu vykreslova če a definic podvlastností. Rozší ření je zavedeno pouze u vlastnosti, která zachycuje sou řadnice bodu. Všechny grafické vlastnosti reprezentuje element
Výpis 3.14 P říklad vý čtové grafické vlastnosti.
Před vytvo řením element ů grafických objekt ů DocumentWriter vytvo ří v DOMu uzel s komentá řem, který obsahuje informace o grafu a bude použit při na čítání. Komentá ř (Výpis 3.16) obsahuje informace o typu grafu. První řádek pouze informuje o použité verzi editoru, druhý obsahuje interní identifikátor typu grafu (atribut name , Tabulka 3.1), t řetí o verzi typu grafu (atribut version , Tabulka 3.1) a poslední obsahuje URI schématu výstupního dokumentu grafu. To je zapsáno i do ko řenového elementu jako atribut xmlns . Důvodem zápisu komentá ře je skute čnost, že pouze podle URI schématu na čítaného dokumentu grafu nelze rozpoznat jeho typ. Pro stejné schéma m ůže totiž existovat n ěkolik typ ů graf ů (podp ůrných definic).
Výpis 3.17 P říklad vypsaných kontrolních bod ů hrany se stejným po čátkem cesty k jejich sou řadnicím. Bázová cesta je {graphics, position}, cesta k hodnot ě x-ové sou řadnice {x}, k y-ové {y} , konce obou ozna čeny jako atributy.
Vytvo ření element ů v DOMu odpovídajících jednotlivým grafickým objektů iniciuje DocumentWriter , který s nimi manipuluje pomocí rozhraní XMLObject . Nejprve je zkonstruován ko řenový element grafu, tedy ten jež obsahuje celý graf. Cestu k němu obsahuje po čátek grafu (instance GraphPropertiesBase ) získaný z uložišt ě. Poté je pomocí metody writeSelf() z rozhraní XMLObject vynuceno zapsání stromu vlastností celého grafu navázaného na objekt po čátku grafu. Metod ě writeSelf() p ředá DocumentWriter odkaz na sebe sama a na ko řenový element. Po čátek grafu v ní pouze zavolá tuto metodu na všechny jeho p římé potomky ve stromu vlastností se stejnými parametry. To jsou pouze vlastnosti, které pomocí metod poskytnutých p ředaným objektem DocumentWriter vytvoří své ko řenové elementy (p řesná definice ko řenového elementu viz 3.2) v DOMu, zapíší svou hodnotu, pokud ji mají, a zavolají metodu writeSelf() na všechny své podvlastnosti s tím, že v ní p ředají stejný DocumentWriter a odkaz na sv ůj ko řenový element. Podvlastnosti totiž obsahují XML cesty relativní k němu. Takto je pokra čováno dokud není v DOMu vytvo řena část dokumentu
79 odpovídající celému stromu vlastností. Na to DocumentWriter získá z uložišt ě iterátor přes všechny vrcholy a postupn ě u každého zavolá metodu pro vypsání, jako element k navázání jim p ředá odkaz na element po čátku grafu. Každý vrchol pak vytvo ří sv ůj nový ko řenový element a do n ěj nechá vypsat vlastnosti na n ěj navázané. Stejn ě jsou vypsány i všechny hrany, které mimo svého stromu vlastností ješt ě vypíší všechny mezilehlé kontrolní body, protože nejsou intern ě reprezentovány jako vlastnosti. Hrana si „pamatuje“ dva páry XML cest pro jejich uložení. Jeden pro x-ovou druhý pro y-ovou sou řadnici. Každý z pár ů obsahuje cestu bázovému elementu sou řadnice a cestu k hodnot ě. Pokud je bázová cesta stejná pro ob ě sou řadnice je vytvo řen její koncový element pro každý bod nový (Výpis 3.17). Pokud je bázová cesta pro každou sou řadnici jiná je vytvo řen nový element pro každou z nich zvláš ť (Výpis 3.18).
Výpis 3.18 P říklad uložených kontrolních bod ů s různou bázovou XML cestou. Cesty k x-ové sou řadnici jsou: bázová {graphics, cp-position-x} , k hodnot ě {val} s koncem jako atributem, k y-ové ve stejném po řadí {graphics} a {cp- position-y} .
3.4 Na čtení dokumentu grafu Objektová t řída DocumentReader zajiš ťuje na čtení grafu z XML do uložišt ě grafických objekt ů. Celá operace je rozd ělena na dv ě fáze. V první je vytvo řen DOM na čítaného dokumentu a vyextrahován typ na čítaného grafu (Obrázek 3.13). Druhá provede samotné na čtení grafických objekt ů. Pokud je objevena chyba formátu dokumentu grafu je vyhozena výjimka typu DocumentFormatException , p řitom je možné omezen ě řídit co je za chybu považováno. P ři striktním na čítání je chybou i to, že neexistuje element nebo atribut nesoucí hodnotu n ějaké vlastnosti. Pokud je striktní na čítání vypnuto jsou u takových vlastností ponechány defaultní hodnoty a chyba hlášena není.
80
Obrázek 3.13 Na čítání grafu z XML do uložišt ě grafických objekt ů.
Na čítaný dokument p řevede DocumentReader do DOMu pomocí prost ředk ů z rozhraní JAXP stejn ě jako je to ud ěláno p ři na čítání podp ůrných definic (oddíl 3.2). Z něj získá informace o typu na čítaného grafu na základ ě komentá ře ze za čátku dokumentu a hodnot ě atributu xmlns jeho ko řenového elementu (Výpis 3.16). Z údaj ů sestaví objekt typu GraphTypeDescription , který p ředá nad řazené komponent ě. Pokud n ějaké údaje chybí neuvede je. Nad řazená komponenta podle popisu najde uložišt ě grafických objekt ů se šablonami odpovídajícími popisu a předá ho objektu DocumentReader , aby do n ěj na četl objekty z DOMu. Objekty grafu se na čítají samy pomocí metody selfRead() deklarované v rozhraní XMLObject (2.3.1). Na čítání řídí DocumentReader a to tak, že nejprve na čte po čátek grafu (GraphPropertiesBase ), všechny vrcholy a nakonec všechny hrany. Na čtení po čátku je jednoduché, nebo ť existuje pouze jeden. DocumentReader najde podle XML cesty po čátku ko řenový element grafu a zapamatuje si ho pro pozd ější použití. Pak ho p ředá po čátku v metod ě readSelf() aby se na četl. Ten odkaz na element pouze p ředá vlastnostem, které jsou na n ěj navázané. Ty obsahují také metodu readSelf() . Po jejím zavolání najdou podle své XML cesty svou hodnotu v DOMu , pokud ji nenajdou nechají si defaultní, a zavolají všechny své podvlastnosti, aby se na četly. Tak se pokra čuje dokud není na čten celý strom. Na čítání vrchol ů a hran je stejné. DocumentReader z uložišt ě objekt ů postupn ě získává jejich šablony, pro každou provede tyto operace: 1. (Nalezení ko řenových element ů) Získá od šablony objektu cestu ke ko řenovému elementu objektu a najde v DOMu všechny vyhovující elementy. 2. (Vylou čení element ů) Pro každý nalezený element se pokusí najít ID na čítaného objektu. Pokud neexistuje a nebo jeho prefix (pro ID „P10“ je to „P“) neodpovídá prefixu ID šablony element vylou čí z dalšího na čítání. 3. (Na čtení objektu ) Pro všechny vyhovující elementy naklonuje šablonu a klonu nařídí aby se z elementu na četl. P řitom klon na čte i všechny své vlastnosti. Klonování je provád ěno hloubkov ě dle metod z rozhraní TreeCloneable (viz 2.3.1). 4. (Vložení objektu ) Na čtený objekt – klon uloží do uložišt ě grafických objekt ů. A na řídí mu aby se propojil se svým okolím (metody z rozhraní Connectable ,viz 2.3.1). To ud ělá p ředevším hrana, která se naváže na sv ůj vstupní a výstupní vrchol. Ty existují protože jsou vrcholy na čteny jako první a pokud ne je oznámena chyba formátu dokumentu.
81 Přístup k dokumentu grafu je odstín ěn pomocí metod, které vyhledávají elementy, atributy a jejich hodnoty podle p ředané XML cesty. Tyto metody používá jak samotný DocumentReader tak jednotlivé grafické objekty. Je tak možnost v budoucnu pro zápis použít potomka t řídy DocumentReader , která graf na čte z jiného zdroje než je XML soubor (jeho datový proud). Stejn ě tak je realizován zápis grafu (p ředchozí oddíl).
82 4 Specializace na Petriho sít ě
4.1 Petriho sít ě Petriho sít ě jsou formálním a grafickým aparátem vhodným pro modelování systém ů diskrétních událostí. Vznikly v 60. letech 20. století za ú čelem rozší řit modelovací schopnosti kone čných automat ů. Mají široké spektrum uplatn ění, čemuž odpovídá i mnoho rozší ření, která časem vznikla. V následujícím textu jen stru čně nazna čím co Petriho sít ě jsou a pojednám o některých rozší řeních jako jsou Stochastické Petriho Sít ě. Více informací lze najít v [16], [17], [18]. 4.1.1 Základní pojmy Neformáln ě je Petriho sí ť (PN) graf obsahující dv ě disjunktní množiny vrchol ů – místa (places ) a přechody ( transitions ), které propojují orientované a ohodnocené hrany (arcs ). Přitom lze propojit vždy pouze místo s přechodem a nebo p řechod s místem, nikdy ne stejné typy vrchol ů. Ohodnocení hrany znamená p řiřazení celého kladného čísla – váhy (Obrázek 4.1). Podobn ě m ůže každé místo obsahovat celý kladný po čet zna ček (token ů, tokens ) , čemuž se říká zna čení PN ( marking ). Pokud do p řechodu Tj vede hrana z místa Pi říkáme, že je Pi vstupním místem p řechodu Tj. Naopak místo do n ěhož vede hrana z přechodu nazýváme jeho výstupním místem.
Obrázek 4.1 Grafická reprezentace Petriho sít ě.
83 Vývoj systému modelovaného Petriho sítí znamená zm ěnu zna čení. K přemíst ění token ů v síti dochází aktivací (odpálením) n ějakého p řechodu. Základní podmínkou aktivace je tzv. uvoln ění p řechodu. K tomu dojde pokud všechna jeho vstupní místa obsahují minimáln ě tolik token ů kolik je váha z nich jdoucí hrany do p řechodu. K samotné aktivaci dochází u Petriho sítí bez vazeb na okolí (autonomní PN) v blíže neur čený okamžik. U Petriho sítí s nějakou vazbou na okolí (neautonomní PN) pak na základ ě externí události nebo n ějaké jiné vazby nap ř. na čas. Po aktivaci p řechodu je ze všech jeho vstupních míst odebrán po čet zna ček shodný s vahami p říslušných hran a do všech jeho výstupních míst p řidán po čet zna ček odpovídající vahám hran do nich jdoucích z odpáleného p řechodu (Obrázek 4.2).
Obrázek 4.2 Zm ěna zna čení Petriho sít ě po odpálení p řechodu T1.
4.1.2 Petriho sít ě s časovanými p řechody Jedním z mnoha rozší ření Petriho sítí jsou takové, jejichž funkce je časov ě závislá. Řadí se do skupiny neautonomních PN a nej čast ěji je u nich čas asociován s místy (P- časované, P-timed ) nebo s přechody (T-časované, T-timed ). PN s časovanými p řechody lze rozd ělit podle typu asociace času na s atomickou aktivací p řechodu ( atomic firing ) a s třífázovou aktivací ( three-phase firing ). Časovaná PN s třífázovou aktivací má k p řechod ům p řiřazeno nezáporné číslo τ udávající dobu trvání p řechodu. Pokud je p řechod uvoln ěn jsou tokeny nutné k aktivaci v jeho vstupních místech rezervovány tj. nelze je použít k uvoln ění nebo aktivaci jiných přechodů. Po uplynutí doby τ od rezervace je p řechod aktivován, rezervované tokeny odebrány vstupním míst ům a naopak p řidány míst ům výstupním, stejn ě jako u neautonomní PN. U PN s atomickou aktivací p řechod ů je každému z nich p řiřazeno nezáporné číslo ξ. Pro názornost pr ůběhu odpálení si p ředstavme, že má každý p řechod sv ůj lokální časova č. Pokud dojde k uvoln ění p řechodu je časova č nastaven na dobu ξ. Hodnota časova če se s přibývajícím časem plynule snižuje. V okamžiku, kdy dosáhne nuly je p řechod aktivován tj. dojde ke zm ěně zna čení PN. Pokud je uvoln ěno sou časn ě n ěkolik p řechod ů jsou nastaveny v jeden okamžik všechny jejich časova če. Jejich dekrementace probíhá pro všechny stejn ě rychle. P řechod s nejnižším časem se odpálí, čímž deaktivuje všechny přechody, jejichž časova č ješt ě nedosáhl nulové hodnoty. Tím jsou zastaveny jejich časova če, které se mohou rozb ěhnout p ři další aktivaci p řechodu, p řitom se volí jedna ze dvou strategií: Časova č se rozb ěhne z hodnoty, kterou si pamatuje z minulého (p řerušeného) odpo čítávání. Časova č je nastaven na hodnotu ξ a nastartována jeho dekrementace.
84 4.1.3 Stochastické Petriho sít ě
Stochastická Petriho sí ť (SPN) je speciálním p řípadem PN s časovanými p řechody Tj, jejichž doby trvání ξi jsou náhodné veli činy s exponenciálním rozd ělením. Jeho distribu ční funkce je
− x = ξ ≤ = − µ > F(x) P( j x) 1 e ; x 0 (4.1) a hustota pravd ěpodobnosti
− x 1 µ f (x) = e , (4.2) µ kde µ > 0 je hodnota EX = µ, p řevrácená hodnota λ = 1/ µ se nazývaná intenzita (poruch). 4.1.4 Stochastické časované Petriho sít ě Stochastická časovaná Petriho Sí ť (STPN) je Petriho sí ť s časovanými p řechody, které mohou mít dobu trvání nulovou, p řesn ě ur čenou nebo vyjád řenou pomocí náhodné veli činy. P řitom rozd ělení pravd ěpodobnosti doby trvání u stochastických p řechod ů je obecné a jeho výb ěr záleží na konkrétní aplikaci. Uvedu n ěkolik rozd ělení z [17], která dále používám. Abych se neopakoval vynechám exponenciální.
Rovnom ěrné rozd ělení Je ur čeno hustotou pravd ěpodobnosti 1 f (x) = pro a < x < b , (4.3) b − a kde a je pozi ční parametr, s = (b – a) m ěř ítko (Obrázek 4.3), p řitom a,b ∈ R, a < b . EX = (a+b)/2 je st řední hodnota.
Obrázek 4.3 Hustota pravd ěpodobnosti f(x) rovnom ěrného rozd ělení.
Logaritmicko-normální rozd ělení Náhodná veli čina X má logaritmicko-normální rozd ělení LN( ζ, σ2) pokud má hustotu pravd ěpodobnosti
(ln x−ζ ) 2 − 1 σ 2 f (x) = e 2 pro x > 0 , (4.4) 2πσx
kde parametry − ∞ < ζ < ∞, σ 2 > 0 jsou st řední hodnota a rozptyl logaritmu náhodné veli činy Y = ln(X) , která má normální rozd ělení N( ζ, σ2).
85 Erlangovo rozd ělení Je odvozeno od Gama rozd ělení a ur čeno hustotou pravd ěpodobnosti
xa−1 − x f = e b pro x > 0, (4.5) baΓ(a)
kde parametry b ∈ R, b > 0 (m ěř ítko) a a > 0 (tvar) je p řirozené číslo, Γ() je gama funkce (více v [19]).
Rozd ělení Raylegh Tail Rayleghovo rozd ělení se zv ětšením (fází) σ > 0 a spodní mezí a > 0 má hustotu pravděpodobnosti
a 2 − x 2 x 2 f (x) = e 2σ pro x > a, a,σ ∈ R (4.6) σ 2
4.2 PNML, PNDT 4.2.1 Základní pojmy PNML ( Petri Net Markup Language ) je datový formát pro perzistentní ukládání Petriho Sítí založený na XML. Hlavními rysy PNML je snadná rozši řitelnost, obecnost, nezávislost na platform ě, snadná transformace do jiného formátu a možnost zpracování pomocí standardních nástroj ů. Poslední t ři vlastnosti jsou d ůsledkem toho, že je PNML založeno na XML. Obecnost znamená, že lze pomocí PNML zachytit širokou škálu dnes existujících typ ů Petriho sítí, což pln ě podporuje k tomu nutná rozši řitelnost. Definici PNML pro uložení konkrétního typu PN tvo ří v zásad ě t ři propojená Relax NG schémata 31 . První nazvané autory 32 „ Core model “ (v [21], dále Core PNML) definuje základní strukturu spole čnou pro všechny Petriho sít ě a samo o sob ě není použitelné. Jeho specializace je provedena pomocí druhého schématu nazvaného PNTD ( Petri Net Type Definition ). Třetí schéma auto ři pojmenovali „ Conventions Document “ (dále dokument konvencí) a umístili do ň prvky využitelné v PNTD a sou časn ě spole čné pro r ůzné typy Petriho sítí. Jedná se p ředevším o různé popisku prvk ů, po čáte ční zna čení míst a váhu hran. Core PNML existuje ve t řech verzích: BasicPNML , StructuredPNML a ModularPNML . První definuje strukturu základní Petriho sít ě, druhé to samé s tím, že dovoluje zaznamenat PN rozd ělenou na n ěkolik částí – stránek. ModularPNML umož ňuje dekomponovat PN na n ěkolik vzájemn ě provázaných modul ů (více v [26]). Pokud dále budu mluvit o Core PNML budu mít na mysli práv ě BasicPNML. Ve výsledku se jeví jako celkové schéma PNML dokument PNTD, který popisuje prvky závislé na konkrétním typu sít ě. Vytvo ření PNTD je ponecháno na uživateli PNML, který si do n ěj vloží Core PNML a dokument konvencí (Obrázek 4.4). Core PNML obsahuje reference (elementy ) na definice „vnit řků“ míst, p řechod ů a hran specifických pro danou PN. P řevážn ě se jedná o různé popisky. Relace mezi místy, hranami a přechody jsou definovány p římo v Core PNML. Prot ějšky ke zmín ěným referencím – definice je nutné vytvo řit v PNTD. P řitom lze využít definic z dokumentu
31 Schémata jsou dostupná z WWW: http://www2.informatik.hu-berlin.de/top/pnml/pnml.html 32 Autory PNML a souvisejícího jsou p ředevším Ekkart Kindler, Michael Weber a Christian Stehno.
86 konvencí, které p ředepisují názvy objekt ů, zna čení míst atp. A i pokud nic z dokumentu konvencí použít nechceme musíme ho do PNTD vložit kv ůli Core PNML.
Conventions Core PNML PNTD Document
(BasicPNML.rng) (ptNetb.pntd) (conv.rng)
Obrázek 4.4 Návaznost RNG schémat definujících PNML, v závorkách jména XML soubor ů.
4.2.2 Základní PNTD Definici PNTD základní autonomní Petriho sít ě vytvo řili auto ři PNML. Je dostupná z jejich WWW stránek jako soubor ptNetb.pntd 33 (dále budu používat ozna čení ptNetb ). Strukturu XML dokumentu definovaného ptNetb ukažme na jednoduchém p říkladu Petriho sítě (Obrázek 4.5).
Obrázek 4.5 Příklad jednoduché Petriho sít ě k ukládání v PNML.
Struktura dokumentu Ko řenovým elementem dokumentu je element
Výpis 4.1 Základní struktura dokumentu typu ptNetb (PNML).
33 P římá adresa k souboru ptNetb.pntd je http://www2.informatik.hu- berlin.de/top/pnml/pntd/ptNetb.pntd.
87
Místo Místo je reprezentované elementem
Výpis 4.2 Element místa „P1“.
88
Přechod Přechod je zapsán jako element
Výpis 4.3 Kostra elementu p řechodu „T1“.
Hrana Hrana je tvo řena elementem
Výpis 4.4 Element hrany propojující p řechod „T1“ s místem „P2“.
89
Tento popis PNML není zdaleka vy čerpávající více lze najít v [23] (neformální popis, příklady, návod jak vytvo řit PNTD), [25] (p říklady specializace PNML), [26] (modulární PNML), [21] (formální popis, UML diagramy, základní RNG schémata, norma ISO).
4.3 StochPNTD 4.3.1 Vznik StochPNTD je up řesn ění Core PNML pro perzistentní uložení Stochastických časovaných Petriho sítí (STPN, viz 4.1.4). Jedním z požadavk ů na editor je, aby umož ňoval vytvá řet grafy odpovídající STPN, k čemuž je nutné disponovat datovým formátem pro její perzistentní uložení. Jelikož žádný takový založený na XML nebo dokonce PNML neexistuje vytvo řil jsem vlastní a nazval ho StochPNTD 34 . Jako Core model jsem použil BasicPNML (více v 4.2.1). A up řes ňující PNTD odvodil od ptNetb (základní PN) p řidáním časových vlastností k přechodu. Dokument konvencí jsem ponechal beze zm ěn.
Obrázek 4.6 Složení PNTD pro STPN (StochPNTD).
4.3.2 Dodefinované vlastnosti V definicích základních Petriho sítí (ptNetb) byl pouze rozší řen element p řechodu
34 Odpovídající RNG schéma je v souboru StochPNTD.pntd a umíst ěno na p řiloženém CD viz p říloha 10.1.
90 povoleny r ůzné podelementy (Tabulka 4.2), nap ř. pokud atribut type nabývá hodnoty stochastic-lognormal obsahuje element
Tabulka 4.1 P řípustné hodnoty atributu type a jejich význam. Hodnota Význam – doba trvání p řechodu zero nulová (použito jako defaultní hodnota) deterministic přesn ě ur čená (deterministická) stochastic-uniform náhodná veli čina s rovnom ěrným rozd ělením stochastic-lognormal náhodná veli čina s logaritmicko normálním rozd ělením stochastic-exponential náhodná veli čina s exponenciálním rozd ělením stochastic-erlang náhodná veli čina, Erlangovo rozd ělení stochastic-raylegh-tail náhodná veli čina, rozd ělení Raylegh tail
Tabulka 4.2 Podelementy elementu
Výpis 4.5 Datová reprezentace p řechodu s časovými vlastnostmi
91
4.4 Podp ůrné definice pro STPN
Vytvá ření a editace Stochastických časovaných Petriho sítí je umožn ěna až po na čtení příslušných podp ůrných definic. Ty jsou založeny na schématu StochPNTD (viz 4.3), které definuje strukturu XML dokumentu pro jejich perzistentní uložení. Schéma se skládá ze t ří díl čích, což není editorem podporováno. Slou čení jsem provedl pomocí XSL transformace (p říloha 10.3). Dalším krokem bylo p řevedení na ploché RNG schéma a to také pomocí XSL transformace (p říloha 10.4). V plochém schématu jsem vyzna čil význam jednotlivých částí pomocí element ů z pomocného prostoru jmen (popsaných v 3.1). Místo a přechod byly ozna čeny jako vrcholy, hrana (arc) jako hrana, atributy (jména, ID, zna čení, časové vlastnosti, váha hrany) jako vlastnosti. Výsledné podp ůrné definice jsou na p řiloženém CD jako soubor StochPNTD_sd.xml (umíst ění viz 10.1). 4.4.1 Prvky grafu Petriho sí ť se skládá z dvou typ ů vrchol ů – míst a přechod ů. Hrana je pouze jedna. Jejich zobrazení jsem p řevzal z normy [20] a literatury [16], [17], [18]. Místo je vykresleno jako kruh, v němž je umíst ěno číslo vyjad řující jeho po čáte ční zna čení. To je intern ě tvo řeno vlastností. Jeho zm ěna sou časn ě s vypnutím zobrazení a nebo zm ěnou stylu vykreslení je možná v editovacím dialogu. Další dv ě vlastnosti jsou ID a název vrcholu. Název lze libovoln ě posouvat a měnit, to neplatí pro ID (Obrázek 4.8), u kterého lze jen vypnout zobrazení a to díky tomu, že je v PNML definováno jako atribut tj. nem ůže mít nic co by ho popisovalo. Vypnuté zobrazení se díky tomu ani neuloží do XML dokumentu grafu. Přechod má vn ější tvar definován jako obdélník. P řitom obsahuje sedm skin ů, které se používají podle toho jaké je nastaveno zpožd ění (Obrázek 4.7). Typ zpožd ění je reprezentován výb ěrovou vlastností s názvem v dialogu „Čas“ a nelze m ěnit jeho polohu vykreslení ani atributy textu. S volbou jiného zpožd ění se zm ění i podvlastnosti, které ho up řes ňují. U těch lze zapnout vykreslení na plátn ě i měnit pozici s atributy textu. Stejn ě tomu je u vlastnosti zachycující jméno p řechodu.
92
Obrázek 4.7 Skiny vrcholu reprezentujícího p řechod.
Hrana je v grafu pouze jedna a umož ňuje propojit p řechod s místem a nebo místo s přechodem, nikdy ne stejné typy vrchol ů. Je definována jako zaoblená s maximálním polom ěrem 10 (pixel ů p ři zv ětšení 1:1) a šipkou u vstupního vrcholu. Jedinou její vlastností je váha, která m ůže obsahovat kladné celé číslo. Je možnost ji vykreslit na plátn ě, m ěnit polohu a atributy textu.
Obrázek 4.8 P říklad Petriho sít ě nakreslené v editoru.
93 5 Specializace na rodokmen
Obecnost editoru p ředevším pokud jde o podporované tvary vrchol ů, demonstrují podpůrné definice, po jejichž na čtení editor umož ňuje vytvá řet jednoduché rodokmeny. Ten je zde chápán jako strom, jehož jeden uzel p ředstavuje osobu a jeho následníci její rodi če. P řitom je možné zanést i relaci „jsou sourozenci“, aby nedocházelo často ke k řížení hran (a také pro, že to demonstruje neorientovanou hranu). Pro rodokmen jsem definoval vlastní formát pro ukládání, jeho RNG schéma je Genealogy.rng (p řiloženo na CD, viz 10.1). Z něj vyzna čením datových částí pomocí element ů z prostoru jmen SD vznikly podp ůrné definice Genealogy_sd.xml (přiloženo na CD).
Obrázek 5.1 Obrysové a vnit řní tvary vrchol ů rodokmenu, vlevo muže, vpravo ženy.
Graf rodokmenu obsahuje dva typy vrchol ů, jeden znázor ňující muže, druhý ženu. Každý z nich obsahuje jako popisky jméno a příjmení osoby a jeden skin skládající se z vnit řního a vn ějšího tvaru (Obrázek 5.1). Viditelný je pouze vnit řní tvar, obrysový slouží pouze k napojení hran. Je tak zamezeno vzniku pohoršujících motiv ů, jež by mohly vzniknout napojením hrany. Neviditelnost obrysového tvaru je zajišt ěna pomocí trvalého natavení jeho barev na 100% transparentní. Uživatel m ůže m ěnit pouze barvu obrysu a výpln ě vnit řního tvaru. Typy hran jsou t ři. První vyjad řuje relaci mezi osobou a ženou typu „osoba má matku“. Druhou je možné propojit pouze muže/ženu s mužem a říká „osoba má otce“. Poslední je neorientovaná, dovoluje propojit všechny 4 kombinace typ ů vrchol ů a ur čuje sourozenecký vztah (Obrázek 5.2).
94
Obrázek 5.2 P říklad rodokmenu vytvo řeného v editoru, černá hrana říká „ osoba má otce“, šedivá „má matku“, čárkovaná vyjad řuje relaci mezi sourozenci.
Editor neumož ňuje omezit vstupní a výstupní stupe ň vrchol ů. P ři vytvá ření rodokmenu nelze definovat omezení říkající, že má osoba pouze jednoho otce a jednu matku. Tím je povoleno uživateli vytvo řit nesmyslný rodokmen. Zavést takové omezení je jedno z možných budoucích rozší ření editoru.
95 6 Záv ěr
Práce popisuje funk ční obecný editor graf ů, který je možné používat pro vytvá ření a editaci Stochastických časovaných Petriho sítí a jednoduchého rodokmenu, po vytvo ření další podp ůrných definic i na jiné typy graf ů. P řitom byly v základu spln ěny na po čátku stanovené cíle. N ěkteré více do hloubky, jiné mén ě, čímž dávají možnosti v pokra čování. Základní principy, na nichž je editor postaven a čím je zajímavý se poda řilo implementovat všechny. Konkrétn ě jde o možnost definovat strukturu grafu, typy jeho vrchol ů, hran, styl a tvar jejich vykreslení, libovolný po čet na n ě navázaných informací databázového charakteru (vlastností) a strukturu XML dokumentu pro perzistentní uložení grafu. Editor až za b ěhu na čítá typy a grafickou reprezentaci vrchol ů. Geometrický tvar vrcholu m ůže být tvo řen uzav řenou cestou sloužící k napojení hran a vnit řním dekora čním tvarem. Oboje lze složit z úse ček, oblouk ů a kubických Bézierových k řivek. Pro obecn ější popis by se dala ješt ě p řidat kvadratická Bézierova k řivka, prakticky ji však lze úsp ěšn ě nahradit kubickou. Stejn ě jako vrcholy si m ůže uživatel nadefinovat jaké typy hran bude vytvá řený graf obsahovat. P řitom m ůže stanovit pravidla, jaké typy vrchol ů m ůže hrana propojit, pokud má být použitelná musí alespo ň jedno pravidlo definovat. Hrana je intern ě vždy orientovaná, pokud má být neorientovaná je nutné definovat dv ě pravidla, která umožní propojit vrcholy. Explicitní zápis neorientovanosti hrany do výstupního dokumentu lze provést pomocí neviditelné, konstantní vlastnosti. Grafický popis hran byl implementován jen ve dvou provedeních a to hrana složená z úse ček a složená z úse ček a oblouk ů. Napojení na vrchol je uskute čněno analytickým výpo čtem pr ůse číku a následnou korekcí tlouš ťek čar jak hrany tak vrcholu. P řitom je použita aproximace ekvidistanty tvaru vrcholu, která dosahuje natolik dobrých výsledk ů i u kubických Bézierových k řivek, že je i tisk v rozlišení 1200dpi p ři velkém zv ětšení bezproblémový. Rozší řit by se u hrany dal po čet k řivek, jež jí reprezentují. Užite čné by bylo p ředevším zavedení Bézierových k řivek. Implementace je k tomu p řipravena (blíže viz 2.3.5). Dále nebylo implementováno p řidávání a mazání kontrolních bod ů. Hrana v takovém p řípad ě musí být smazána a znovu nakreslena. Informace databázového charakteru (vlastnosti) je možné definovat jako navázané na hrany, vrcholy a celý graf. Podporované typy hodnot jsou text, číslo, výb ěr z několika položek a barva. P řitom je možné ur čit omezení zadávaných hodnot a to pomocí RNG definic. Není možné definovat vlastnost, kterou by šlo kopírovat v rámci jednoho nad řazeného objektu. Nap ř. není možné p ředepsat, že vrchol p ředstavující osobu bude mít definovánu vlastnost telefonní číslo a při editaci vrcholu bude zadán jejich libovolný po čet (nap ř. 3). Tato funkcionalita by šla p řidat a je na pozd ějších rozší řeních. Stejn ě jako
96 přidání dalších omezení hodnot vlastností (nap ř. regulární výrazy) a implementování vlastnosti pro uložení času a data. Vykreslova č vlastností byl implementován pouze jeden – vykreslující hodnotu vlastnosti jako text. P řitom bylo dosaženo subjektivn ě kvalitního grafického výsledku a to i při natá čení popisku. V této oblasti je velký prostor pro další pokra čování, nap říklad by se u Petriho sítí hodil vykreslova č zobrazující číselnou vlastnost jako skupinu zna ček (tokenů). Jak bude graf uložen uživatel definuje pomocí plochého RNG schématu. P řitom musí dodržet n ěkolik zásad. P ředevším je nutné, aby elementy vrchol ů a hran byly kvantifikovány jako vyskytující se v libovolném po čtu. Informace o propojení vrchol ů hranami jsou vždy uloženy v elementu hrany. Myslím však, že je to kompromisním řešením mezi složitostí a funk čností. Definice pomocí RNG schématu klade trochu v ětší nároky na uživatele, který bude chtít vytvo řit vlastní typ grafu, komer ční produkty jako nap ř. MS Visio 2003 to neumož ňují v ůbec a pokud chce uživatel dosáhnout jisté struktury XML dokumentu musí graf vyexportovat do XML a pak napsat XSL transformaci pro převod, což je mnohem náro čnější. Nespornou výhodou komer čních produkt ů však je interaktivní vytvá ření tvar ů vrchol ů. Byly definovány podp ůrné definice pro Stochastické časované PN. Pro uložení je použito rozší ření StochPNTD základního PNML, jež jsem provedl. Jako nedostatek vidím především zobrazení zna čení vrchol ů pouze textem. Abych demonstroval míru obecnosti editoru definoval jsem ješt ě typ grafu zahrnující kreslení rodokmenu. Editor m ůže být zaintegrován do WWW stránky a tak používán uživateli bez jakékoli instalace. Internetový provoz nebyl p ředevším z časových a stanovených priorit více rozveden. Uživatel musí grafy ukládat na lokální systém soubor ů. Mnohem v ětší možnosti dává ukládání na server a sdílení s jinými uživateli. To reflektuje návrh p řístupu k dokumentu grafu, který by v důsledku ani nemusel být XML dokument. Avšak samotná implementace serveru a komunikace klient – server spadá do oblasti možných vylepšení aplikace. Grafická komponenta, jež zobrazuje graf, umož ňuje m ěnit pohledy na ň pomocí metod funk čně srovnatelným se základní sadou pro práci s pohledy v AutoCADu [SW 15]. Podobn ě vysp ělé možnosti zm ěny pohledu na graf neumož ňují ani komer ční produkty pro editaci graf ů. V žádném (p říloha 10.2) jsem nap ř. nenalezl zv ětšení v reálném čase. Export nakresleného grafu je možný v rastrové podobě (JPG, PNG) nebo ve vektorové (kvalitní EMG). Samotný p řevod je provád ěn pomocí balí čku Vector Graphics z FreeHEP knihovny [SW 1]. P řitom nap ř. p řevod do SVG nebo PDF nedopadne dob ře, není vykreslen text. Kvalitu exportu m ůže čtená ř posoudit z obrázk ů (Obrázek 4.8, Obrázek 5.1 a Obrázek 5.2). Z pohledu výkonu nebyla aplikace nikterak systematicky vyla ďována (profilována). Subjektivním hodnocením je odezva editoru plynulá na po číta či s procesorem Intel Pentium 4 1,8 GH a 256 MB RAM. P ři otev ření grafu s 2000 vrcholy a třemi hranami na každý editor využije n ěco málo pod 40 MB pam ěti. V tomto ohledu je také co zlepšovat. Minimální konfigurace na níž jsem provozoval editor je Intel PII 300MHz s 128MB, ale to už je spodní hranice použitelnosti. Souhrnn ě je editor použitelný. Pokud jde o možné sm ěry vylepšování vidím jako vhodné nejd říve provést optimalizaci s ohledem na použití pam ěti a poté rozší ření o funkce pro lepší práci na WWW.
97 7 Použité zdroje
[1] CLARK, James, MURATA, Makoto. RELAX NG Specification [online]. OASIS, c2001, 3 December 2001 [cit. 2006-05-5]. Dostupný z WWW:
98 [16] BAYER, Ji ří, HANZÁLEK, Zden ěk, ŠUSTA, Richard. Logické systémy pro řízení . 1. vyd. Praha : Vydavatelsví ČVUT, 2000. 269 s. Skripta. ISBN 80-01-02147-5. [17] ČAPEK, Josef. Petri Net Simulation of Non-deterministic MAC Layers of Computer Communication Networks. [s.l.], 2001. iv, 148 s. Department of Control Engineering Faculty of Electrical Engineering, Czech Technical University. Dizerta ční práce. [18] BALBO, Gianfranco, et al. Modelling with Generalized Stochastic Petri Nets . Marco Ajmone Marsan. 1st edition. [s.l.] : Wiley Series in Parallel Computing, John Wiley and Sons, 1994. 316 s. Dostupný z WWW:
99 8 Seznam použitého SW
8.1 Knihovny p římo obsažené v editoru Níže uvedený seznam obsahuje knihovny a nebo jiné věci datové povahy, jichž nejsem autorem a jsou p římo obsaženy v editoru. Provázání s Java platformou pokládejme za samoz řejmost.
[SW 1] VectorGraphic package of FreeHEP Java library. Knihovna pro vykreslení obrázku do vektorových a rastrových obrázk ů. Použito pro export grafu. [cit. 2006-05-21]. Dostupné z WWW:
8.2 SW použité pro vývoj editoru Zde uvedený seznam obsahuje software, který jsem používal p ředevším p ři implementaci editoru a není b ěžnou sou částí programového vybavení PC.
[SW 5] Saxon 6.5.3. XSLT procesor. Dostupné z WWW: http://saxon.sourceforge.net/ [SW 6] GNU Emacs v. 21.3.1 . Editace XML soubor ů. Dostupné z WWW:
8.3 Ostatní software Tato sekce obsahuje seznam program ů, které jsem vyzkoušel, inspirovali m ě a nebo je z jiného d ůvodu zmi ňuji v textu této práce.
[SW 9] StpnPlay a stochastic Petri net modelling and simulation tool. Čapek Josef. Editor a simulátor Stochastických časovaných Petriho sítí. [cit. 2006-05-21]. Dostupné z WWW:
100 [SW 10] Visualizing Graphs with Java (VGJ) v.1.03 . Editor graf ů. [cit. 2006-05-21]. Dostupné z WWW:
101 9 Seznam použitých zkratek
API Application Programming Interface XML eXtensible Markup Language RNG REgular LAnguage for XML Next Generation, ekvivalent Relax NG SD Support Definitions (Používáno pro ozna čení pomocného prostoru jmen podp ůrných definic.) DTD Document Type Definition DOM Document Object Model JSE Java Standard Edition JDK Java Development Kit JAXP Java API for XML Processing JAR Java Archive JVM Java Virtual Machine UML Unified Modeling Language PN Petri Net SPN Stochastic Petri Net STPN Stochastic Timed Petri Net PNML Petri Net Meta Language PNTD Petri Net Type Definition WWW World Wide Web W3C World Wide Web Consortium PC Personal Computer IDE integrated development environment MDI Multiple Document Interface GUI Graphical User Interface LGPL GNU Lesser General Public Licence SW Software HW Hardware
102 10 Přílohy
10.1 Obsah p řiloženého CD
Adresá ř /bin vspne.jar – Editor graf ů (Variable Stochastic Petri Net Editor). index.html – Vzor stránky pro umíst ění editoru na web.
Adresá ř /bin/lib Vector Graphics z knihovny FreeHEP. Pokud není ve stejném adresá ři i vspne.jar nebude fungovat export. WWW:
Adresá ř /scr vpsne.zip – Zdrojové kódy editoru. javadoc.zip – Dokumentace zdrojových kód ů.
Adresá ř /Tools Obsahuje XSLT procesor Saxon 6.5.3. WWW:
Adresá ř /xml/rng Genealogy.rng – RNG schéma dokumentu rodokmenu. StochPNTD.rng – RNG schéma dokumentu Stochastických časovaných Petriho sítí. SupportDefinitions_99.rng – RNG schéma podp ůrných definic.
Adresá ř /xml/rng/pnml basicPNML.rng – Core model PNML základních Petriho sítí. WWW:
103 ptNetb.pntd – PNTD základních autonomních PN. WWW:
10.2 Souhrn vlastností některých editor ů
Před samotnou tvorbou editoru jsem prozkoumal n ěkteré již existující. Abych se vyvaroval tomu co se mi v nich nelíbí. V následujícím uvedu jejich krátký vý čet se stru čnou charakteristikou klad ů a zápor ů ( často subjektivních). P řitom jsem se soust ředil především na zápory.
Visualizing Graphs with Java v.1.03 [SW 10] Klady: Lze používat na WWW jako Java applet. Zápory: Tvar vrcholu bud elipsa, obdélník nebo rastrový obrázek. Nep řesné vykreslování, výstup nevhodný to tišt ěných publikací. Velice špatné možnosti zm ěny pohledu. Prakticky pouze posun obrazu a špatn ě přístupné p řiblížení pomocí zadání číselného pom ěru z klávesnice. Graf je ukládán do GML což je textový formát, ale ne založený na XML. uDraw(Graph) Version 3.1.1 [SW 11] Klady: Automatické hledání vhodného tvaru grafu (n ěkdy nevýhoda). Stabilní a rychlý. Možno zvolit tvar vrcholu ze základních geometrických prvk ů, ale nelze ho sestavit. Zápory: Nelze exportovat do vektorového grafického formátu. Špatné možnosti nastavení pohled ů. Jen jednoduché p řiblížení, zobrazení všeho a posun pomocí tzv. sokolího oka. yEd - Java™ Graph Editor v. 2.4.1 [SW 14] Celkov ě velice povedený editor. Klady: Automatické uspo řádání grafu s vynikajícími výsledky, lze i přibližný celkový tvar grafu. Rychlost programu.
104 Volba z pom ěrn ě hodn ě tvar ů vrchol ů, ale nelze je sestavovat. K řivka hrany neovlivnitelná (jen pomocí kontrolních bod ů). Bezi na WWW jako Java applet. Lze uložit graf jako XML dokument, jeho strukturu nelze volit. Zápory: Nep řesné napojování hran na geometrii vrcholu. Není zohledn ěna tl. čáry jeho obrysu. Export do WMF dává velice špatné výsledky, elipsa je nap ř. jako „oblá ček“ kostrbatá. Export do PDF dosahuje kvalit pro užití v tišt ěných publikacích. Zm ěny pohled ů splní základní možnosti, ale nenašel jsem jejich historii. Kole čko myši zv ětšuje tak, že je zachován st řed obrazovky, což není intuitivní a člov ěku se ztrácí to co by cht ěl vid ět. Je komer ční, lze ho používat voln ě s tím, že je zobrazen ve vyexportovaných grafech nápis v čem byl vytvo řen.
Smart Draw 7 [SW 12] Klady: Možnost definovat libovolné tvary vrchol ů, široká nabídka k řivek hran. Renderování je precizní, export možný do WMF a další, vhodné pro tisk. Velké množství p říklad ů a rozsáhlá dokumentace. Zápory: Velice špatné možnosti pohledu na graf. Nepodporuje v tomto ohledu standardní kl. zkratky ani kole čko myši. Celkov ě je neintuitivní ovládání. Nelze exportovat graf do XML. Cena cca 200 USD.
Microsoft Visio 2003 [SW 13] Klady: Možnost definovat libovoln ě tvary vrchol ů. Hrana m ůže být složena z úse ček, oblouk ů, k řivek. Možnost exportu do XML. Po grafické stránce se dají vytvo řit perfektní výsledky vhodné pro tisk. Pov ětšinou intuitivní ovládání. Zápory: Problém s umís ťováním objekt ů. Rastr pro to ur čený se m ění podle zv ětšení, což přináší problémy. I když dosta čující sortiment možností pohled ů na graf dal by se doplnit nap říklad o interaktivní zv ětšování/zmenšování (RT zoom).
105 10.3 XSL transformace pro odstran ění vno řených dokument ů v RNG
106
107
10.4 XSL transformace pro odstran ění referencí v RNG
108
109
110