Vektorový editor automatů. Bc. Milan Kříž

Transkript

1 České vysoké učení technické v Prze Fkult elektrotechnická Ktedr počítčů Diplomová práce Vektorový editor utomtů Bc. Miln Kříž Vedoucí práce: Ing. Jn Žďárek Studijní progrm: Elektrotechnik informtik, strukturovný, Nvzující mgisterský Oor: Výpočetní technik leden 2011

2 iv

3 v Poděkování Děkuji především vedoucímu práce z trpělivost podporu zejmén při testování progrmu psní tohoto textu. Dále ych chtěl poděkovt přítelkyni rodině z silnou podporu po celou dou studi. Poslední poděkování ptří tké společnosti Eccm s.r.o. z možnost získání cenných zkušeností, které jsem využil při implementci.

4 vi

5 vii Prohlášení Prohlšuji, že jsem práci vyprcovl smosttně použil jsem pouze podkldy uvedené v přiloženém seznmu. Nemám závžný důvod proti užití tohoto školního díl ve smyslu 60 Zákon č. 121/2000 S., o právu utorském, o právech souvisejících s právem utorským o změně některých zákonů (utorský zákon). V Jičíně dne

6 viii

7 Astrct The gol of this work is to dpt nd extend the existing sic utomt editor. The editor supports severl new grphicl elements nd some of its former deficiencies were removed. A set of stndrd sic lgorithms for finite utomt trnsformtion were implemented, long with support for utomtic positioning of grphs of the resulting utomt. There were dded n interfce to externl dynmiclly loded modules, so tht ny still missing lgorithm cn e implemented nd dded to extend the editor s functionlity. An export of trnsition tle to the L A TEX formt is supported, s well s simultion of finite utomt with possiility to export the steps of simultion in the VuCnSon-G formt. Astrkt Cílem práce je přeprcovt doplnit existující editor konečných utomtů. Byl přidán podpor několik dlších grfických elementů yly odstrněny některé nedosttky původní verze. Byl implementován sd zákldních lgoritmů pro operce nd konečnými utomty s podporou utomtického rozmisťování grfů výsledných utomtů. Je nvrženo rozhrní umožnující implementovt lgoritmy jko externí dynmicky nhrávné moduly, tkže může ýt funkcionlit editoru rozšířen o liovolný chyějící lgoritmus. Editor podporuje export přechodového zorzení ve formě tulky do formátu L A TEX tké umožňuje simulci práce konečných utomtů s možností exportu jednotlivých kroků simulce ve formátu VuCnSon-G. ix

8 x

9 Osh 1 Úvod VuCnSon-G Původní verze editoru Popis prolému, specifikce cíle Odstrnění nedosttků Rozšíření editoru Práce s konečnými utomty Anlýz návrh řešení Zjištění rozšiřitelnosti Ovládání editoru podpor opercí copy/pste Přesné vykreslování Bézierových křivek Podpor speciálních symolů znček Algoritmy pro operce nd konečnými utomty Rozhrní utomtu podpor pluginů Použití SmrtPointerů Detekce utomtu z nkresleného grfu Rozhrní pro lgoritmy Rozmisťovcí lgoritmus Rozmisťovcí heuristik Použití GrphViz knihoven Simulce práce konečných utomtů Relizce Jk zčít Droná vylepšení Přechody - Bézierovy křivky Speciální symoly znčky Tříd StringProcessor xi

10 xii OBSAH Předzprcování vstupního textu Sázení textu Podpor opercí copy/pste Algoritmy pro operce nd konečnými utomty Použití pluginů Komunikce editoru s lgoritmy Jednotlivé lgoritmy Rozmisťovcí lgoritmy Heuristik GrphViz wrpper Přechodová tulk Simulce práce konečných utomtů Generování slideshow Prolémy při implementci Qt komptiilit mezi verzemi Prolém s nčítáním knihovny Dlší dokumentce Testování Test 1 Speciální symoly mkr Test 2 Export do podporovných formátů Test 3 Export přechodového zorzení ve formě tulky Test 4 Algoritmy pro operce nd konečnými utomty Test 5 Simulce práce konečných utomtů Test 6 Rozmisťovcí lgoritmy Závěr 65 Litertur 67 A Vstupní grmtik pro prser 69 B Osh přiloženého CD 73

11 Seznm orázků 1.1 VuCnSon-G příkld VuCnSon-G příkld Původní verze editoru UML schém původní plikce digrm tříd Uprvené UML schém plikce digrm tříd Původní způso vykreslování VCurve Korektní způso vykreslování VCurve Detekce utomtů kolik utomtů je n orázku? Rozhrní IAlgorithm digrm tříd Rozhrní IAutomton jeho implementce digrm tříd Změn tvru přechodu sekvenční digrm Sázení textu sekvenční digrm Komunikce mezi editorem lgoritmy sekvenční digrm Rozhrní pluginu pro GrphViz digrm tříd Dilog pro simulci práce konečného utomtu Zorzení speciálních symolů test Použití modifikátorů písm test Export do EPS (vlevo) SVG test Export přechodového zorzení ve formě tulky test Algoritmus pro odstrnění ε-přechodů test Algoritmus pro odstrnění nedosžitelných stvů test Algoritmus pro odstrnění zytečných stvů test Algoritmus pro odstrnění více počátečních stvů test Algoritmus pro determinizci utomtu test Algoritmus pro minimlizci utomtu, deterministický utomt test Algoritmus pro minimlizci utomtu, minimální utomt test Algoritmus pro konstrukci utomtu pro sjednocení jzyků test xiii

12 xiv SEZNAM OBRÁZKŮ 5.13 Algoritmus pro konstrukci utomtu pro průnik jzyků test Simulce práce nedeterministického konečného utomtu test Simulce práce deterministického konečného utomtu test Rozmisťovcí heuristik test Rozmisťovcí heuristik n složitějším grfu test GrphViz plugin test GrphViz plugin n složitějším grfu test

13 Kpitol 1 Úvod Po úspěšné ohjoě klářské práce [6] vznikl nápd přeprcovt doplnit editor konečných utomtů n nástroj, který ude umět s nkreslenými utomty prcovt. Cílem smozřejmě není implementovt nástroj pro práci s reálnými konečnými utomty, le implementovt funkcionlitu umožňující výzkumníkům či studentům jednoduchým způsoem mnipulovt s vlstnoručně nkreslenými konečnými utomty. Studentům y tkový nástroj mohl umožnit sndnější pochopení konečných utomtů lgoritmů s nimi spojenými. Výzkumníkům y poté mohl umožnit zkoumání chování konečných utomtů v příjemném prostředí, kde udou moci utomty zároveň editovt, plikovt n ně různé lgoritmy, simulovt průchod exportovt je v podoě přechodové tulky do formátu L A TEX či grficky do různých vektorových i itmpových formátů, zejmén do L A TEXu, EPS dlších. 1.1 VuCnSon-G Blík VuCnSon-G [7] je souor mker zložených n líku PSTricks [17], umožňujících jednoduchý textový zápis grfů utomtů ve formátu L A TEX. Formát yl nvržen tk, y splňovl zákldní myšlenku, že jednoduchý utomt y měl ýt zpsán pomocí jednoduchých příkzů. Jelikož je lík detilně popsán jk v klářské práci, tk v mnuálu k líku [8], ude se v této práci předpokládt, že čtenář je s líkem seznámen. Pro úplnost textu je dále uvedeno stručné seznámení s mkry líku VuCnSon-G. Automt se kreslí do prostředí \VCPicture, které je určeno souřdnicemi levého dolního prvého horního rohu. Tyto dv ody určují mřížku pro kreslení utomtu, která může ýt i se souřdnicemi zorzen volitelně pomocí příkzů \ShowGrid, \ShowFrme, \HideGrid \HideFrme. Mřížk nikterk neomezuje pozice vykreslovných elementů ty tedy mohou ýt kresleny i mimo ni. Syntxe zápisu konečného utomtu s použitím líku VuCnSon-G je velmi jednoduchá pro stručné seznámení s líkem postčí několik následujících příkldů. Nejdůležitějšími elementy jsou stvy přechody. Kždý stv má své jednoznčné jméno, dle kterého se u přechodů určuje, ke kterým stvům náleží. Kompletní seznm elementů popis jejich použití je opět možno njít v mnuálu k líku. 1

14 2 KAPITOLA 1. ÚVOD \ShowGrid 5 \ShowFrme \egin{vcpicture}{(0,0)(5,5)} 4 %sttes Q f \Stte[Q_s]{(1,1)}{Q1} 3 \FinlStte[Q_f]{(4,4)}{Q2} %trnsitions 2 % initil trnsition from west to Q1 \Initil[w]{Q1} % edge etween Q1,Q2, lel t pos Q s \EdgeL[0.4]{Q1}{Q2}{} 0 \end{vcpicture} Orázek 1.1: VuCnSon-G příkld 1 \HideGrid \HideFrme \egin{vcpicture}{(0,0)(12,8)} %6 sttes \Stte[p]{(2,4)}{p} \Stte[q]{(5,6)}{q} \FinlStte[r]{(8,6)}{r} \Stte[s]{(5,2)}{s} \Stte[t]{(8,2)}{t} \FinlStte[u]{(10,4)}{u} %1 initil-finl \Initil{p} %12 trnsitions \EdgeL{p}{q}{} \EdgeL{p}{s}{} \LArcL[0.6]{q}{s}{} \LoopN{q}{} \EdgeL{q}{t}{} \EdgeL{q}{r}{} \EdgeL{r}{u}{} \EdgeL{s}{q}{} \VCurveL[0.6]{ngleA=-40,ngleB=-90,ncurv=1.2}{s}{u}{} \EdgeR{t}{s}{} \EdgeL{t}{r}{} \EdgeR{u}{t}{} \end{vcpicture} p q s r t u Orázek 1.2: VuCnSon-G příkld 2

15 1.2. PŮVODNÍ VERZE EDITORU Původní verze editoru Předchozí verze editoru yl npsán v C++ s použitím knihovny Qt [18]. V původní verzi editoru yl použit verze Qt Editor splňuje poždvek n multipltformnost s tím, že yl testován n OS Windows XP dále n linuxových distriucích OpenSuse Uuntu. Progrm umožňuje vektorové kreslení konečných utomtů dle formátu VuCnSon-G. Jelikož je tento formát poměrně rozsáhlý, yl zvolen pouze jeho část, která je dostčující k rozumné práci s konečnými utomty. Editor zvládá nčtení utomtu ze souoru oshujícího pouze mkr líku VuCnSon-G, le i z mker zčleněných do L A TEXového souoru. Je možné exportovt grf do několik dlších formátů. Z vektorových to jsou npříkld EPS [2] GrphML [1]. Smozřejmě je možné uložit grf konečného utomtu jko itmpu, npříkld do formátů BMP, PNG JPEG, což zjišťují stndrdní funkce knihovny Qt. Editor je v podsttě funkční, i když vykreslování přechodů je pouze přiližné ovládání není ntolik přímočré, y ylo dosttečně jednoduché sndno použitelné. Pro detilnější popis původní verze se doporučuje nhlédnout do výše zmiňovné klářské práce, kde je editor detilně popsán i s mnuálem k jeho ovládání. N orázku 1.3 je vidět původní verze editoru. Orázek 1.3: Původní verze editoru

16 4 KAPITOLA 1. ÚVOD

17 Kpitol 2 Popis prolému, specifikce cíle Původní verze editoru je sice funkční jeho použití nic nerání, nicméně má stále podsttné vdy. Nejdůležitější z nich je nepříliš přívětivé málo intuitivní ovládání. Editor nepodporuje ni kopírování vkládání elementů, což znčně rání sndnému kreslení větších utomtů. Mezi nevýhody jistě ptří i sence speciálních symolů (npř. řecké symoly různé druhy znček šipek). Vdou n kráse je i podpor exportu do vektorového formátu EPS, která je sice zhrnut, le export nezvládá zdlek všechny možnosti, které editor nízí. Pro dlší pokrčování je tedy potře dokončit původní verzi editoru. 2.1 Odstrnění nedosttků Jelikož se má z editoru stát o něco sofistikovnější nástroj pro práci s utomty, jeví se jko rozumné nejprve dotáhnout do konečné podoy zákldní část progrmu editor. Přinejmenším je tře zvážit možné implementční nedosttky, které y mohly ovlivňovt možnost přípdného rozšiřování funkcí editoru. Dále je potře předělt ovládání editoru tk, y ylo jeho používání přímočré jednoduché kreslení rozsáhlejších utomtů se tk nestávlo noční můrou. Proto ude vhodné doplnit editor o možnost oznčování více stvů. Díky tomu ude umožněno jejich hromdné přesouvání. Stejně tk podpor kopírování vkládání do schránky zjistí sndnější práci s editorem. Po grfické stránce je sice editor celkem zdřilý, le věrohodnost vykreslování vůči výstupu po překldu systémem L A TEX není zcel uspokojivá. Nejzávžnějším prolémem jsou elementy \VArc \VCurve. Šipk u přechodů rovněž neodpovídá skutečnému výstupu stejně tk umisťování textu neodpovídá plně výstupu dosženého překldem systémem L A TEX. Bylo y tedy doré vykreslování vylepšit. Export do EPS je dlším prolémem, který y ylo vhodné vyřešit. V původní verzi yl export do EPS vytvořen n koleni, což neylo nejšťstnější řešení. Mělo to sice výhodu, že si uživtel znlý PostScript [2] mohl výsledek ručně editovt. Nevýhodou všk je velmi otížná implementce všech možností, které editor i lík VuCnSon-G nízejí. Vyždovlo y to velmi dorou znlost PostScriptu výsledek y zřejmě stejně neyl příliš jednoduchý pro editci. Proto y ylo lepší prozkoumt možnosti knihovny Qt, která export do PostScriptu nízí přímo. 5

18 6 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 2.2 Rozšíření editoru Editor y měl ýt rozšířen o několik dlších elementů, které se ukázly jko čsto použitelné. Jsou to elementy závislé n velikosti jiných elementů, zejmén n šířce popisku, který oshují. Tyto elementy mjí příponu Vr. Elementy, které y měly ýt implementovány, jsou \StteVr, \FinlStteVr \LoopVr. Syntxe příkzů \StteVr \FinlStteVr je nlogická k příkzům \Stte, respektive \FinlStte. \StteVr[Lel]{(x,y)}{Nme} \FinlStteVr[Lel]{(x,y)}{Nme} Příkz \LoopVr má rovněž shodnou syntxi s příkzem \Loop, ovšem je tře dávt pozor n směr tohoto přechodu. Přímo v líku VuCnSon-G jsou podporovány pouze dv směry, jelikož vykreslování je v osttních přípdech prolemtické čsto je výsledek neuspokojivý vypdá ošklivě. \LoopVrN[pos]{Nme}{Lel} \LoopVrS[pos]{Nme}{Lel} Tohoto typu přechodu je možné docílit i pomocí přepínčů \VrLoopOn \VrLoopOff. V tomto přípdě je možné přidt Vr přechod i v jiném směru, le nedoporučuje se to. Jko využitelný se ukázl tké element \Lel, který umožňuje připojit k jednomu přechodu více popisků. \LelL[pos]{Lel} \LelR[pos]{Lel} Popisek se přiřdí vždy k nposledy definovnému přechodu nemůže se vyskytovt sám o soě. Dlším rozšířením y měl ýt podpor speciálních symolů, zejmén řecké ecedy. Jelikož možnosti L A TEXu jsou orovské, ylo y čsově velmi náročné implementovt všechny speciální symoly modifikátory textu, které L A TEX nízí. Proto ude tře nvrhnout řešení, které ude rozumně rozšiřitelné umožní přidávání symolů dle potřey. Nepředpokládá se implementce mtemtických vzorců. Při práci s většími grfy ývá čsto prolém se v editoru zorientovt, vzhledem k tomu že jednotlivé elementy jsou celkem velké vůči oknu editoru. Proto y ylo doré implementovt funkci přiližování oddlování scény. 2.3 Práce s konečnými utomty Hlvní myšlenkou této práce je využít nkreslený konečný utomt pro dlší práci s ním. Z grfu nkresleného v editoru y měl ýt sndno exportovtelná přechodová tulk přímo do L A TEXu. Dále je cílem implementovt zákldní lgoritmy nd konečnými utomty, což udou determinizce, minimlizce, průnik, sjednocení, odstrnění zytečných stvů, odstrnění nedosžitelných stvů, odstrnění ε-přechodů odstrnění více počátečních stvů.

19 2.3. PRÁCE S KONEČNÝMI AUTOMATY 7 Po plikci lgoritmů ude tře znovu vykreslit vzniklý utomt. Proto je nutné implementovt rozumné vykreslování. Vzhledem k tomu, že progrm je primárně editor, není nprosto nezytné implementovt dokonlé vykreslování, le zjistit vykreslování tkové, y uživtel ezpečně rozpoznl všechny elementy utomtu měl co možná nejméně práce s editcí grfu výsledného utomtu do esteticky uspokojivého stvu. Nkonec y měl ýt implementován simulce konečného utomtu, to pro deterministický i nedeterministický konečný utomt. Rovněž y ylo hezké umožnit export sekvence jednotlivých stvů utomtu při simulci, což y usndnilo tvoru prezentcí.

20 8 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

21 Kpitol 3 Anlýz návrh řešení Nejprve ude nutné nlyzovt vnitřní strukturu editoru zjistit, ude-li později možné sndno přidt dlší elementy, které formát VuCnSon-G nízí. Pokud udou ojeveny přípdné prolémy, musí ýt odstrněny co nejdříve. Důležité totiž je, y přípdné změny v editoru neovlivnily implementci rozšiřujících funkcí, jko jsou lgoritmy pro operce nd konečnými utomty, vykreslovcí lgoritmus či simulce průchodu konečným utomtem. Proto ude potře tyto části od smotného editoru vhodně oddělit. 3.1 Zjištění rozšiřitelnosti Původní verze editoru měl poměrně doře nvrženou hierrchii zákldních tříd reprezentujících jednotlivé elementy formátu VuCnSon-G. Zákldní třídy jsou Stte Trnsition, přičemž tříd Trnsition je strktní slouží jko áze konkrétních implementcí jednotlivých elementů reprezentujících přechody (npř. TrnsitionLine). N orázku 3.1 je zjednodušené UML schém původní třídní hierrchie. Nd původním návrhem je tře se zmyslet ze dvou úhlů pohledu. Prvním z nich je možnost plynulého rozšiřování o dlší elementy s co možná nejmenším záshem do již npsného kódu druhým, zd ude možné rozumně oddělit rozšiřující funkce pro práci s konečnými utomty. Z hledisk rozšiřitelnosti je doré, že všechny přechody mjí společného předk může s nimi tedy ýt zcházeno jednotně pomocí ukztele n Trnsition. Je le potře zvážit, jké elementy mohou ýt ještě přidávány. Původní návrh totiž počítá jen s jedním typem stvů ylo y tedy otížné přidt jednoduše nově poždovný StteVr. Proto y ylo doré uprvit hierrchii stvů odoně, jko je tomu u přechodů. Blík VuCnSon-G všk nízí přinejmenším ještě jeden element, se kterým původní návrh nepočítl \Lel. V původní verzi se počítlo pouze s tím, že kždý přechod může mít přidělen pouze jeden popisek. Pozdější rozšíření formátu všk zvedlo smosttný element Lel, díky kterému může ýt k jednomu přechodu přiřzen liovolný počet popisků. Proztím yl celá informce o textu uložen pouze ve třídě odpovídjící elementu, ke kterému popisek ptří, tedy ve stvu či přechodu. Nyní se le jeví výhodné vytvořit pro popisek smosttnou třídu. To ude doré i pro dlší poždovnou změnu podporu speciálních symolů znček. V této třídě mohou ýt uloženy informce o velikosti fontu, rvě, pozici 9

22 10 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Orázek 3.1: UML schém původní plikce digrm tříd

23 3.2. OVLÁDÁNÍ EDITORU A PODPORA OPERACÍ COPY/PASTE 11 popisku td. Stejně tk ude moci ýt ve třídě pro popisek implementován funkcionlit spojená s vykreslováním exportem do různých formátů, což způsoí zjednodušení třídy Trnsition větší loklitu kódu. Orázek 3.2 zorzuje zjednodušený třídní digrm po zmiňovných úprvách. Z povšimnutí stojí i tříd StringProcessor, která ude popsán v kpitole 3.4. Pro implementci rozšířené práce s konečnými utomty musí ýt především umožněn dosttečně strktní mnipulce se stvy přechody. Pokud udou mít všechny přechody svého společného předk stejně tk stvy, ude to dostčující pro zjištění oddělení editoru od rozšiřujících funkcí. Ty totiž nepotřeují informce o konkrétních elementech, le potřeují mít pouze informce o konečném utomtu, se kterým mjí prcovt. Díky tomu přidání nových elementů do editoru vůec neovlivní implementci rozšiřujících funkcí. Vzhledem k udržovtelnosti kódu je v původní verzi progrmu ještě jeden neduh. Chyí tu loklit při vytváření instncí jednotlivých elementů. Elementy se vytvářejí n několik místech při přidání nového se musí n všech těchto místech provést změny. Jednk se elementy vytvářejí v prseru při nčítání ze souoru v druhém přípdě se vytvářejí v závislosti n interkci s GUI pomocí myši. V tom přípdě se zorzí dilog, který má rovněž npevno uložen seznm možných typů elementů, které lze přidt. Dlším místem, kde se znovu řeší vytváření instncí elementů, je generátor vyhledávcích utomtů. Bylo y doré sjednotit vytváření elementů udržovt informci o existujících elementech n jednom místě v kódu. Možným řešením je sjednotit tyto informce v smosttných třídách, npř. StteMnger, TrnsitionMnger. V těchto třídách y se udržovl informce jk instnciovt jednotlivé elementy, le y mohly zjišťovt i převod ze jmén elementu n instnci opčně. Npříkld tkový StteMnger y poté mohl vrcet seznm možných jmen stvových elementů, který y se mohl využít v dilogu pro přidání či editci stvu, tím y se mohl kód n mnoh místech zoecnit. Jelikož se plánuje přidávání podpory dlších elementů formátu VuCnSon-G, ude smozřejmě nutné náležitě uprvit prser. Vzhledem k tomu, že ten yl v původní verzi nvržen celkem flexiilně, mělo y stčit přidt jen klíčová slov odpovídjící zvoleným elementům implementovt odpovídjící funkce rekurzivního sestupu. Avšk i zde se njde upltnění pro pomocné třídy n vytváření konkrétních instncí elementů, jko je Stte- Mnger. Když se pomocí nich ude vytvářet instnce elementu, ude veškerá informce pro převod z názvu n typ v těchto pomocných třídách. V prseru odpdne složité určování, jký typ elementu se má vlstně instnciovt, opět se tím zjednoduší kód všechen kód spojený se smotným vytvářením ojektů ude loklizován n jednom místě. 3.2 Ovládání editoru podpor opercí copy/pste Jk ylo zmíněno v minulé kpitole, ovládání neptřilo mezi nejsilnější stránky minulé verze editoru. To se ukázlo ž při skutečném používání n rozsáhlejších grfech, když uživtel musel čsto redundntní části grfu nklikt celé ručně. Proto ylo dokonce jednodušší nkreslit pouze zákldní podgrfy poté uprvit utomt ručně v textovém editoru. Zákldní nedosttky y se dly rozdělit n dv podprolémy. Prvním z nich je zytečná stvovost jednotlivých uživtelských kcí, kdy si uživtel musí npříkld pro přidání přechodu vyrt mód pro editci přechodů následně opět pro přidání stvu přepnout do

24 12 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Orázek 3.2: Uprvené UML schém plikce digrm tříd

25 3.2. OVLÁDÁNÍ EDITORU A PODPORA OPERACÍ COPY/PASTE 13 módu pro práci se stvy. Toto chování je le velmi omezující nepříjemné uživtel je většinou nepřímo nucen přizpůsoit kreslení grfu tk, že nejprve nkreslí všechny stvy poté přidává přechody. Odstrnění tohoto neduhu je přitom celkem jednoduché. Všechny čsté kce y měly ýt dostupné n jeden, mximálně dv kliky myší, pokud možno ez nutnosti dlouhých přejezdů mezi kliky v přípdě dvou kliků. Vzhledem k tomu, že většin myší má dnes minimálně tři tlčítk, je možné ez prolémů v jednom módu povolit všechny stndrdní kce, jko jsou přidání stvu, přidání přechodu, editce, přesun stvu či výěr více elementů. Jednotlivým kcím zývá jen přiřdit vhodné komince tlčítek zytek už je část ryze implementční. Přehled zvolených kcí je v tulce 3.1. Stvovost le nemusí nutně zmizet úplně npříkld pro usndnění práce s touchpdem y měl ýt zchován možnost přepnout se do specifického módu, kde ude většin činností uzpůsoen pro levé tlčítko myši. Akce přidání stvu oznčení stvu pro přidání přechodu editce elementu přesun stvu/skupiny stvů výěr skupiny elementů kopírování elementů vložení ze schránky vyjmutí elementů přidání dlšího popisku oznčení dlšího elementu zoom in/out Komince dvojklik myší do volného prostoru klik prostředním tlčítkem dvojklik n element prvý klik n element + výěr v popup menu drg&drop levým tlčítkem levý klik do volného prostoru tžení odélníku výěru prvý klik n vyrné elementy + výěr v popup menu Ctrl+C při vyrných elementech prvé klik do volného prostoru + výěr v popup menu Ctrl+V vloží do středu viditelné části editoru prvé klik n vyrné elementy + výěr v popup menu Ctrl+X při vyrných elementech prvý klik n přechod + výěr v popup menu Ctrl + levý klik n element Ctrl + kolečko myši Ctrl+"+" / Ctrl+"-", Ctrl+0 pro reset Tulk 3.1: Přehled uživtelských kcí S výěrem více elementů souvisí i druhý podprolém editoru. Tím je sence kopírování vkládání elementů. Qt nízí třídu pro sndnější práci se schránkou, všk je tře vyrné elementy do schránky nějk dostt. Nejjednodušší možností je serilizovt všechn dt potřená pro rekonstrukci kopírovných elementů do textové podoy tu uložit do schránky. K tomu udou zpotřeí ojekty, které ostrjí serilizci deserilizci (onovení ze schránky) jednotlivých instncí elementů. V extrémním přípdě y šlo dokonce do schránky ukládt přímo zápis ve formátu VuCnSon-G, tkže y uživtel mohl vkládt části editoru přímo z textového editoru. Nicméně tto možnost yl proztím zvržen, protože je zde velký prostor pro vznik chy.

26 14 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Při vkládání elementů je tře zvážit několik omezení. Prvním z nich je, jkým způsoem se udou volit jmén vkládných stvů tk, y nekolidovl s již existujícími stvy. Návrhy n řešení y mohly ýt různé, nicméně pro zjištění jednotnosti při vkládání se jeví jko nejrozumnější přejmenovt všechny vkládné stvy utomtickým pojmenováním. To s seou le nese dlší prolém. Je nutné si pmtovt, jk se změnil jmén stvů, y mezi nimi ylo možné správně vytvořit přechody. V souvislosti s vkládáním přechodů se nízí dlší otázk, jk řešit kopírování, když je vyrán přechod, le ne o stvy, ke kterým náleží. Proztím ylo zvoleno tkový přechod do schránky neukládt, i když v udoucnu y možná mohlo ýt lepší dát uživteli při vkládání šnci upřesnit, n který z existujících stvů se má tkový přechod npojit. Tento způso le není povžován z prioritní yl zvolen vrint jednodušší n implementci, protože se tím zúží prostor pro chyy. 3.3 Přesné vykreslování Bézierových křivek Vykreslování elementů, které používjí Bézierovy křivky, v původní verzi neodpovídlo vzhledu dosženému překldem mker líku VuCnSon-G systémem L A TEX. Proto ylo tře znovu důkldně prozkoumt způso vykreslování těchto elementů. Jedná se o přechody \VArc \VCurve. O přechody se vykreslují v podsttě stejnou metodou s tím rozdílem, že \VArc je jen speciálním přípdem \VCurve. Dokonce i přechody \Arc \ArcL jsou pouze specilizcí oecné křivky \VCurve. Z toho vyplývá, že je zytečné udržovt speciální kód pro kždý z přechodů, tím spíš když ten jediný správný je kód pro \VCurve. Bude tedy potře předělt tyto přechody tk, y využívly jen jeden lgoritmus pouze s dronými odlišnostmi, čímž se opět zjednoduší sprvovtelnost kódu. To všk není jediný prolém. N orázku 3.3 je vidět způso vykreslování \VCurve, jk yl uveden v klářské práci. Přechod má tři prmetry: nglea, ngleb ncurv. Úhly se měří oproti vektoru 1; 0 u prmetru ncurv ylo vyzkoumáno, že ovlivňuje vzdálenost kontrolních odů křivky A B. To vše ndále pltí, všk přeci yl v uvedeném postupu odhlen jeden podsttný rozdíl od skutečného vykreslování líkem VuCnSon-G, který způsoovl tk podsttné odlišení. V původní verzi se jko kontrolní ody, kromě A B, rly středy oou stvů S E. Ve skutečnosti to všk nemjí ýt středy, le ody n okrji stvu. Jsou to průsečíky polopřímky vycházející ze středu stvu pod úhlem nglea, resp. ngleb s okrjem stvu. U kultých stvů není tento rozdíl ve vykreslování tolik ptrný, všk při použití oválného stvu (\StteVr) je již docel mrkntní. A to tím více, čím delší popisek v tkovém stvu je. Proto ude nutné vykreslování uprvit, y odpovídlo orázku Podpor speciálních symolů znček Popisky stvů přechodů mohou oshovt prkticky jkýkoli text, který systém L A TEX dokáže vysázet. Z tohoto hledisk je tedy nemyslitelné implementovt všechny funkce, které L A TEX nízí. Je tedy tře rozumně rozšiřitelně implementovt zákldní podporu sázení znků. Zákldní prser formátu VuCnSon-G y neměl v žádném přípdě modifikovt kód popisků, y nedošlo k jeho modifikci ještě před smotným zprcováním sázecích lgoritmů. Toto všk součsný prser neumožňuje, proto ude nutné implementovt do prseru

27 3.4. PODPORA SPECIÁLNÍCH SYMBOLŮ A ZNAČEK 15 A B nglea ngleb S E Orázek 3.3: Původní způso vykreslování VCurve A B S nglea ngleb E Orázek 3.4: Korektní způso vykreslování VCurve prosté přečtení kódu popisku uvnitř definice stvu či přechodu. Prser tedy ude muset umět přečíst kód popisku (Lel) uvnitř hrntých či složených závorek nezměněný ho předt do editoru. Z implementčního hledisk y to všk neměl ýt nijk rzntní zásh. \Stte[Lel]{(x,y)}{Nme} \EdgeX[Pos]{Strt}{End}{Lel}... Jk již ylo zmíněno výše, ude doré mít smosttnou třídu pro popisky. V této třídě y měl ýt implementován veškerá logik týkjící se popisků. Jelikož v ní ude implementováno i smotné vykreslování popisku, neylo y doré implementovt logiku pro sázení přímo v této třídě, jelikož zprcování kódu popisku y mohlo ýt znovupoužitelné oddělené od vykreslování, exportu, td. Proto y měl ýt implementován tříd pro práci s textem, která ude zprcovávt kód popisku. Tto tříd StringProcessor ude oshovt logiku pro zprcování příkzů systému L A TEX ude muset ýt nvržen tk, y ylo možné sndno dodávt dlší funkcionlitu itertivně tk rozšiřovt sázecí možnosti editoru. V souvislosti se zprcováním textu ude tře implementovt převod kódů speciálních symolů n smotné symoly, což ude vyždovt výpis různých znků různým fontem. Řecká eced y měl ýt sázen fontem Symol osttní text stndrdním fontem editoru Aril. Zároveň je le možné, že ude potře používt n zákldě kódu popisku i jiný font, tkže y přepínání fontu mělo ýt odvislé od kódu kždého jednotlivého symolu. Dále ude muset ýt implementováno zprcování různých modifikátorů fontu, jko je změn velikosti písm, sklonu, tloušťky či tře nstvení sázení pro horní dolní index.

28 16 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Zákldní myšlenk StringProcessoru je tková, že zprcuje text přidá k němu popisnou strukturu, která ude oshovt veškeré informce potřené pro jeho vysázení. Osttní moduly, npříkld tříd pro popisek, tuto strukturu sndno využijí pro vykreslování. 3.5 Algoritmy pro operce nd konečnými utomty Nejdůležitějším rozšířením editoru je implementce lgoritmů pro práci s konečnými utomty. Tyto lgoritmy nemjí nic společného s editorem, proto y jejich implementce měl ýt oddělená od implementce editoru. Jediné, co lgoritmy potřeují o utomtu vědět, je jeho přechodové zorzení. Není tře lgoritmům podsouvt informce o grfickém zprcování přechodů či stvů. Nopk y ylo vhodné nvrhnout rozhrní pro konečný utomt, které y usndnilo implementci lgoritmů. Editor ude implementovt toto rozhrní ude pomocí něj předávt konečný utomt lgoritmům. Ty udou pomocí tohoto rozhrní s utomty prcovt vrátí uprvený konečný utomt zpět editoru, který jej vykreslí. Není tře, y lgoritmy implementovly rozhrní tké vlstně ni není tře, y o vnitřní implementci věděly. Ay mohl lgoritmus vytvářet utomt i ez znlosti implementce rozhrní, postčí, když mu editor předá zároveň s utomtem ojekt, který ude toto rozhrní implementovt AutomtCretor. Tento ojekt ude pro vytváření utomtu používt i editor ude tím tedy opět dosžen loklit kódu. Algoritmy udou s editorem komunikovt pouze pomocí tohoto rozhrní udou nprosto nezávislé n změnách rozšířeních editoru. Pokud se nezmění rozhrní, udou všechny lgoritmy stále komptiilní s editorem Rozhrní utomtu podpor pluginů Rozhrní IAutomton y mělo umožnit co nejjednodušší implementci lgoritmů, jelikož ude nvrženo přímo pro práci s utomty. Mělo y nízet funkce jko hsepsilon- Symols(), která vrátí true, pokud ude utomt oshovt ε-přechody, či getinitil- Sttes(), která vrátí seznm počátečních stvů utomtu. Toto rozhrní y mělo ýt zároveň nvrženo univerzálně, y šlo využít i pro dlší rozšiřující funkce editoru, jko je export do L A TEXu v podoě přechodové tulky či simulce konečných utomtů. Díky tomu se i u těchto funkcí zjistí minimální závislost n změnách v editoru. K tomuto rozhrní udou smozřejmě ptřit i strktní definice stvů přechodů, IStte ITrnsition. Algoritmus i osttní rozšiřující funkce udou s utomtem prcovt pouze pomocí těchto rozhrní. Opercí, které lze provádět nd konečnými utomty, je celá řd většinu z nich je možné implementovt několik lgoritmy. Když už je nvržen způso, jk lgoritmy oddělit od editoru, yl y škod neumožnit implementci lgoritmů rovněž odděleně. Progrmátor, který ude implementovt lgoritmus, nepotřeuje vědět v podsttě nic o vnitřní implementci editoru. Není tře ho nutit při implementci lgoritmu zshovt do kódu editoru. Nejlepší tedy ude umožnit implementci pluginů v podoě dynmických knihoven 1, které ude možné nhrát z ěhu progrmu. Díky Qt ude tento úkol velmi zjednodušen. Je v něm totiž implementován osluh pluginů pomocí třídy QPluginLoder. Díky této třídě ude npříkld možné implementovt zákldní lgoritmy ve sttické knihovně udou tedy 1 *.dll n systémech Windows, *.so n linuxových distriucích

29 3.5. ALGORITMY PRO OPERACE NAD KONEČNÝMI AUTOMATY 17 linkovány k editoru již v doě překldu. Přípdné pluginy ude poté stčit umístit do dné cesty editor si je sám z ěhu nhrje Použití SmrtPointerů Jelikož se ude utomt předávt mezi pluginy editorem, nízí se otázk, kdo y měl instnce utomtu, jeho stvů přechodů vlstnit. Někdo totiž musí tyto instnce smzt (zvolt n nich delete). Ale je nutné zjistit, y tyto instnce yly destruovány ž v momentě, kdy už k nim neude nikdo jiný přistupovt. Zároveň je tře předejít tomu, že ojekty nesmže nikdo. Jelikož je to potencionální místo pro vznik memory leků 2, ylo y vhodné tento prolém nějk ezpečně vyřešit. Nejezpečnější nejelegntnější řešení je použít ojekt typu SmrtPointer [11] (chytrý ukztel). Jedná se o ojekt splňující progrmátorský idiom RAII 3 [12]. Tto myšlenk spočívá oecně v tom, že zdroj je držen ojektem, který při svém zániku tento zdroj uvolní. Ke zdroji je přistoupeno při vytváření tkového držícího ojektu. V přípdě SmrtPointeru je zdrojem pměť, ke které je přistupováno pomocí ukztele n dresu, kde je pměť lokován. Existuje několik zákldních typů SmrtPointerů. Nejjednodušší implementce tohoto ukztele je i v STL 4, uto_ptr. Tento SmrtPointer je le pro řešení nšeho prolému příliš jednoduchý, protože nedovoluje držený ukztel sdílet, le umožňuje pouze jeho předávání. Dělá jen to, že při svém zániku delokuje pměť. Jeho výhod je v tom, že dojde-li k výjimce, uto_ptr tk jko tk znikne pměť ude vždy ezpečně delokován, jk ukzuje následující příkld: void d() { A~*p = new A(); foo(); delete p; } // foo muze vyvolt vyjimku // k tomuto nedojde - memory lek void ok() { std::uto_ptr<a> p(new A()); foo(); // foo muze vyvolt vyjimku } // utomticke volni std::~uto_ptr K vyřešení zmiňovného prolému s předáváním utomtů, ve skutečnosti s předáváním ukztelů n utomty, ude potře sofistikovnější typ SmrtPointeru. Jedná se o Shred- Pointer (sdílený ukztel). Jk název npovídá, ukztel má ýt sdílený. Jde o to, že držený ukztel se může předávt dlším ShredPointerům ke skutečné destrukci ojektu dojde ž ve chvíli, kdy už žádný ShredPointer nemá n ojekt referenci. Je tudíž použit metod počítání referencí. Tkový ShredPointer nízí i knihovn Qt, je jím QShredPionter<T>. 2 únik pměti, nstává v přípdě, že progrm již lokovnou pměť nepotřeuje, le není schopný ji uvolnit 3 Resource Acquisition Is Initiliztion 4 Stndrd Templte Lirry

30 18 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Právě tento chytrý ukztel ude vhodné využít v souvislosti s předáváním utomtů mezi editorem pluginy, neoť odpdne složité zjišťování včsné ( jisté) destrukce dynmicky lokovných ojektů pomocí delete. QShredPointer<A> r() { return QShredPointer<A>(new A()); } // novy oj2-1 reference void foo() { QShredPointer<A> p1(new A()); // novy oj1 -> 1 reference QShredPointer<A> p2(p1); // oj1 -> 2 reference p2 = r(); // p2 uvolni referenci n oj1 // prid referenci n oj2 // oj1 -> 1 ref, oj2 -> 1 ref QShredPointer<A> p3(p2); // oj1 -> 1 ref, oj2 -> 2 ref p1.cler(); // oj1 -> 0 ref, ude smzn p2.cler(); // oj2 -> 1 ref, neude smzn } // utomtick destrukce p3, oj2 -> 0 ref, ude smzn Celé kouzlo SmrtPointerů je vlstně v tom, že se klsický ukztel převede n lokální (stticky definovný) ojekt (SmrtPointer), n který se v C++ utomticky volá destruktor, jkmile znikne jeho pltnost (n konci loku }, při vzniku neosloužené výjimky či dosžení klíčového slov return) Detekce utomtu z nkresleného grfu Ay ylo možné vytvořit utomt pomocí implementce rozhrní IAutomton z grfu nkresleného v editoru, ude tře definovt nějká prvidl, jk může grf vypdt. Se stvy zřejmě prolém neude, nezáleží u nich totiž n popiscích. Avšk nkreslené přechody udou muset dodržovt jistá omezení. Npříkld přechod ez popisku postrádá v kontextu konečných utomtů smysl. Přechod je totiž vždy definován pro nějký vstupní symol neo prázdný řetězec. Z toho vyplývá, kde je omezení přechodů. Z popisků přechodu musí ýt vždy možné určit neprázdnou množinu vstupních symolů, pro které ude přechod definován. Pokud se toto nepodří, nedává dný grf konečného utomtu smysl nelze s ním dále prcovt. Jelikož v grfu konečného utomtu se zpisují symoly přechodů různými způsoy, je tře definovt povolené formy zápisu přechodu. Definujeme tedy lexikální vstupní grmtiku pro prser popisků. Lexikální grmtik element symol := symol spec_symol lphet_symol epsilon_symol :=... Z "\lph"... "\Zet"

31 3.5. ALGORITMY PRO OPERACE NAD KONEČNÝMI AUTOMATY 19 r_symol := \r{symol} epsilon_symol := "\vrepsilon" "\epsilon" CUSTOM lphet_symol := A "\Sigm" CUSTOM spec_symol := "\{" "\}" -, Vstupní grmtik LelText -> Chrcters Chrcters -> NormlPttern Chrcters -> BrPttern Chrcters -> EpsilonPttern Chrcters -> AOrAMinusPttern Chrcters -> EpsilonPttern -> epsilon_symol NormlPttern -> symol NormlPtternN NormlPtternN ->, symol NormlPtternN NormlPtternN -> BrPttern -> r_symol BrPtternN BrPtternN ->, r_symol BrPtternN BrPtternN -> AOrAMinusPttern-> lphet_symol AMinusPttern AMinusPttern -> - "\{" NormlPttern "\}" AMinusPttern -> Jk je vidět, mezi symoly se počítjí i znky řecké ecedy, což ovšem v prxi znmená, že kždý symol může ýt ve skutečnosti řetězec znků, npř. řetězec \lph odpovídá znku α. Astrkci nd tímto prolémem y měl řešit již výše zmiňovný StringProcessor, který rozpozná jednotlivé symoly přidá k nim pomocné informce pro sndnější práci s nimi. Syntxe správného zápisu všk již není doménou StringProcessoru měl y ýt řešen smosttně. K tomu poslouží LelSyntxChecker, který ude mít z úkol jednk ověřit správnost syntxe dále pk rozpoznt, pro který symol je přechod definován. Tím se opět oddělí řešení konkrétního prolému do smosttné třídy. Ve vstupní grmtice je doré si povšimnout, že přijímá i prázdný vstup (prázdné slovo). To je proto, že přechody mohou mít liovolný počet popisků (\Lel) když lespoň jeden z nich ude oshovt kód popisku, osttní mohou zůstt prázdné smysl přechodu ude zchován. V souvislosti s možností více popisků je tře výstupy z jednotlivých popisků spojit dohromdy opět určit, zd má výsledná množin symolů smysl (npř. může vzniknout prázdná množin). Dlší nejsností v grmtice y mohl ýt podo některých speciálních symolů, konkrétně řetězce \{ \}. Vzhledem k tomu, že grf musí ýt stále exportovtelný do formátu L A TEX, je nutné dodržovt stejné escpe-sekvence, jké jsou používné v systému L A TEX. Slovo CUSTOM oznčuje, že uživtel ude moci ndefinovt vlstní řetězec či znk pro dný lexikální symol. Vzhledem k tomu, že někdy může uživtel vyždovt speciální nstvení, npříkld nestndrdní znk pro oznčení ε-přechodu, vlstní symol pro oznčení ecedy pod., ude rozumné nídnout uživteli ruční zdání definice utomtu, tj. umožnit nstvit množinu

32 20 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ vstupních symolů, symol pro ecedu symol pro ε-symol. Zároveň se ude muset ověřovt, zd zdná definice dává smysl (npř. y symol pro ε-symol neyl zároveň v množině vstupních symolů). Proti této definici se ude nkreslený grf kontrolovt neude-li ji splňovt, ude se rát jko nekorektně definovný neude s ním tedy možné prcovt. Vzhledem k tomu, že je možné v editoru nkreslit rozsáhlé grfy udělt jen neptrnou chyu v definici přechodů, ude nutné, y se při detekci dokázlo určit, kde přesně je prolém tto informce mohl ýt uživteli výstižně sdělen. V souvislosti s detekcí utomtu je nutné zmínit ještě jedno omezení, které ylo po pečlivém uvážení zvedeno. Jelikož v jednom souoru (*.vcg, *.tex) může ýt potencionálně nkresleno více utomtů, nízel se otázk, zd toto podporovt. Po důkldnějším zmyšlení se ojevuje prolém, který není zcel jednoduše řešitelný. Tkový přípd ilustruje orázek 3.5. Jk kdo y měl určit, kolik utomtů je n orázku? Jedná se o dv utomty, neo je to jeden utomt s více počátečními stvy? Ay ylo zmezeno nejsnostem, ylo rozhodnuto, že kždý souor může oshovt jen jeden utomt. Z toho důvodu všk ude nutné lehce pouprvit prser, y s ním ylo možné nčítt více souorů zároveň jko vstup do lgoritmů pro operce typu sjednocení, průnik, td. Kdyy ylo povoleno více utomtů v jednom souoru, yl y zřejmě nutný netriviální zázh uživtele do detekce utomtu zřejmě y tím yl zmřen snh o jednoduché používání progrmu. Orázek 3.5: Detekce utomtů kolik utomtů je n orázku? Rozhrní pro lgoritmy Všechny lgoritmy udou implementovt jednotné rozhrní, čímž se zjistí jejich sndné použití ze strny editoru. Rozhrní IAlgorithm v podsttě potřeuje jen minimum metod. Nejdůležitější metodou ude run(). Vstupem této metody ude seznm utomtů, které má lgoritmus zprcovt. Dlší zjímvou metodou ude metod setautomtcretor(), která umožní editoru, y předl lgoritmům implementci rozhrní IAutomtCretor. Díky ní ude moci kždý lgoritmus jednoduše vytvářet utomt, stvy přechody i ez znlosti jejich implementce.

33 3.6. ROZMISŤOVACÍ ALGORITMUS 21 Algoritmy udou mít tké možnost implementovt vlstní dilog pro svá specifická nstvení. Ay editor mohl tento dilog používt, udou k dispozici metody hssettings- Dilog() runsettingsdilog(). Kždý lgoritmus ude smozřejmě umět vrátit své jméno počet utomtů, který očekává n vstupu. Jelikož udou lgoritmy implementovány ve formě pluginů, udou z důvodu jejich sndného exportu sdružovány v jediném ojektu implementujícím rozhrní IAlgorithmHolder. Tento ojekt v konstruktoru vytvoří instnce všech lgoritmů n požádání vrátí editoru seznm ukztelů. Jediné, co se ude muset exportovt, je právě tento sdružující ojekt. Díky tomuto ojektu ude nvíc možné udržovt skupiny lgoritmů, které pocházejí ze stejného pluginu. Jelikož některé lgoritmy mohou mít společné funkce, ude zákldní sd lgoritmů dědit z jedné ázové třídy BsicAlgorithm. Digrm n orázku 3.6 popisuje třídní hierrchii lgoritmů. Orázek 3.6: Rozhrní IAlgorithm digrm tříd 3.6 Rozmisťovcí lgoritmus Rozmisťování liovolných grfů je oecně velmi složitá úloh [4]. Rozmisťování grfu konečného utomtu je jednou podmnožinou tohoto typu úloh. Jedná se v podsttě o oecný orientovný grf, který je tře rozmístit do 2D plochy. Pokud ude grf utomtu neplnární, není možné ho nkreslit ez křížení hrn. Přesto je v práci poždvek, y si progrm dokázl pordit i s neplnárními grfy, které vzniknou po plikci některého z lgoritmů. Protože již při vývoji lgoritmů ude nutné je rozumně testovt, ude vhodné vykreslovcí lgoritmus zkomponovt do progrmu tk, y jej ylo možné jednoduše vyměnit

34 22 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ z jiný. Tkového odstínění vykreslovcího lgoritmu se dosáhne opět sndno pomocí rozhrní IDrwAlgorithm, které ude dále neměnné. Kždý vykreslovcí lgoritmus ude toto rozhrní implementovt pomocí tohoto rozhrní ude komunikovt s editorem, který mu předá výsledný utomt vrácený z některého z lgoritmů. To umožní v první fázi implementovt oprvdu hloupý lgoritmus NiveDrwAlgorithm, který vykreslí stvy utomtu tk, y yl kždý n jiných souřdnicích. K úvodnímu otestování funkčnosti lgoritmů to postčí. Podsttné je to, že díky rozhrní IDrwAlgorithm ude možné kdykoli dodt vylepšenou verzi rozmisťovcího lgoritmu Rozmisťovcí heuristik Implementce kvlitního rozmisťovcího lgoritmu není zcel triviální záležitostí jedná se o prolém, který y se dl zřejmě řešit v smosttné diplomové práci. Proto ylo rozhodnuto, že y pro zákldní potřey progrmu mohl postčit v podsttě celkem jednoduchá heuristik, která y utomt ve většině přípdů rozumně rozmístil. 1) zvol počáteční stv 2) nlezni nejkrtší cesty do všech osttních stvů 3) nlezni nejvzdálenější koncový stv 4) rekonstruuj zpmtuj si cestu do počátečního stvu - páteř 5) zčni v počátečním stvu vykresli páteř poslední stv vykresli v mx. vzdálenosti ze všech stvů 6) nstv vzdálenost v n 1 7) kresli stvy ve vzdálenosti v, jeden nhoru, jeden dolu 8) nstv vzdálenost v n v+1 9) pokud v < mximální vzdálenost, pokrčuj odem 7 10) vykresli nedostupné stvy 11) vykresli všechny přechody následujícím způsoem 12) pokud není mezi stvy přechod, vykresli Line pokud je jeden přechod, vykresli VArcL pokud jsou dv přechody, vykresli VArcR zvětšuj úhel VArc pro větší počet přechodů střídej L R Nvržená heuristik vznikl n zákldě pozorování učenicových utomtů, které jsou většinou kresleny zlev doprv jejich páteř [10] je v jedné rovině. Zčíná se vždy počátečním stvem nejvíce vprvo je jeden ze stvů koncových, čsto nejvzdálenější od zvoleného počátečního stvu. Přesně podle těchto předpokldů yl rozmisťovcí heuristik nvržen. Nejprve se zvolí jeden z počátečních stvů poté se k němu nlezne nejvzdálenější stv koncový. Jelikož ude v heuristice potře vzdáleností všech stvů od počátečního stvu, ude vhodné použít Dijkstrův lgoritmus pro nlezení nejkrtších cest do všech stvů z dného stvu [5]. Nepředpokládá se, že y koncových stvů ylo v poměru k počtu stvů utomtu výrzně mnoho, proto y mohlo stčit jednoduše projít koncové stvy njít nejvzdálenější z nich. Při počítání vzdáleností je možné zároveň uchovávt předk pro kždý stv. Pomocí toho půjde sndno zrekonstruovt páteř grfu. Nejprve se rozmístí stvy n páteři, poté se zčne stvy ve vzdálenosti jedn postupně se zvětšuje vzdálenost ž do nejvzdálenějšího stvu. Jelikož je možné, že existuje nekoncový stv, který je vzdálenější než nejvzdálenější

35 3.7. SIMULACE PRÁCE KONEČNÝCH AUTOMATŮ 23 koncový stv, ude hezké vykreslit poslední koncový stv tk, y yl co nejvíce vprvo. Dále je možné, že některé stvy nejsou dosžitelné ze zvoleného počátečního stvu musejí ýt vykresleny smosttně, ideálně co nejlíže utomtu. Jkmile jsou všechny stvy rozmístěny vykresleny, mohou se vykreslovt přechody. Zčne se přechody n páteři, y ylo vždy možné nkreslit rovné přechody. Poté se udou vykreslovt osttní přechody, jk je popsáno v pseudokódu. Tto heuristik celkem ezpečně zjistí, že uživtel ude vždy schopen rozpoznt všechny elementy utomtu přípdné estetické nedosttky si ude moci uprvit v editoru ručně. Důležité je, že se nestne, y se dv elementy plně překrývly. Jk ude tto heuristik v prxi použitelná ukáže ž testování Použití GrphViz knihoven Díky oddělení vykreslovcího lgoritmu pomocí rozhrní IDrwAlgorithm je možné implementovt rozličné rozmisťovcí lgoritmy. Proč le implementovt něco, co je již celkem rozumně vyřešeno? Jk ylo zjištěno, knihovn GrphViz [15] oshuje celou řdu vykreslovcích lgoritmů, tk y yl škod vyhýt se znovupoužitelnosti kódu, nvíc když má GrphViz i vhodnou licenci CPL [16]. Ay neyl editor závislý n knihovnách GrphVizu, měly y se tyto knihovny detekovt ž z ěhu progrmu. To y s seou ovšem přinášelo riziko v podoě nekomptiilních verzí. Progrm y musel nhrávt kždý symol zvlášť pokud y se změnily některé funkce v rozhrní GrphVizu, mohlo y docházet k pádům. Mnohem ezpečnější řešení ude npst vlstní plugin, který ude GrphViz využívt. Tento plugin ude dynmicky linkovná knihovn, která ude používt dynmicky linkovné knihovny GrphVizu. Díky podpoře pluginů v Qt y mělo ýt sndné nhrát vlstní GrphViz plugin, který zpřístupní knihovny GrphVizu pomocí deklrováného rozhrní. Když plugin nenjde potřené dynmické knihovny GrphVizu, mělo y Qt utomticky zjistit, že se plugin nepodří nhrát do progrmu vykreslovcí lgoritmus postvený n GrphVizu se neude používt. V principu ude tento rozmisťovcí lgoritmus vykonávt jednoduchou úlohu. Pouze převede utomt do struktury, kterou GrphViz potřeuje předá mu pomocí ní grf konečného utomtu. Poté zvolá funkci gvlyout(), která jednotlivé elementy grfu rozmístí zpětně si ze struktury, kterou GrphVizu předl, přečte pozice stvů, přípdně dodtečné informce o tvru přechodů. Podle těchto informcí již jednoduše vykreslí utomt v editoru. 3.7 Simulce práce konečných utomtů Součástí progrmu má ýt i podpor simulce průchodu konečným utomtem, to jk deterministickým, tk nedeterministickým. Jelikož editor musí implementovt rozhrní IAutomton pro lgoritmy, ylo y doré využít tuto implementci co nejvíce. Simulátor ude součástí editoru mohl y tedy použít jeho vnitřní implementci rozhrní utomtu AutomtonImpl. V tom přípdě ude vhodné, když v této vnitřní implementci ude dostupný odkz n původní grfické elementy v editoru Stte Trnsition. Díky tomu ude moci simulátor využívt editor přímo k zorzování grfické simulce průchodu konečným utomtem. Má-li le simulátor intergovt s utomtem, měl y dodržovt stejná prvidl pro editci elementů, jko používá smotný editor. To znmená, že kždá kce musí ýt proveden

36 24 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ přes QCommnd, čímž se zároveň zjistí zpětná krokovtelnost simulce i po jejím skončení. Bude tké nutné po dou simulce zkázt veškeré funkce editoru, které ovlivňují logickou strukturu utomtu (npř. přidávání mzání elementů). K smotné simulci poté poslouží jednoduchý dilog, kde ude možné zdt vstup. Poté y měl ýt umožněn uď utomtická, neo postupná simulce pomocí krokování. Tříd AutomtonImpl ude uchovávt ktivní stvy utomtu ude implementovt jednoduché rozhodovcí funkce, npříkld pro zjištění, zd je součsný přečtený vstup přijtý (tj. v množině ktivních stvů je lespoň jeden koncový). Součástí rozhrní utomtu jsou i rozhrní IStte ITrnsition. Právě jejich implementce udou oshovt odkz n grfické elementy. Jelikož je u přechodů díky Qt možné zjistit přímo souřdnice odu odpovídjícího procentuální pozici n křivce přechodu, mohl y ýt jednoduše implementován nimce přechodu z jednoho stvu do druhého. Orázek 3.7: Rozhrní IAutomton jeho implementce digrm tříd Digrm n orázku 3.7 y měl osvětlit myšlenku využití implementce rozhrní utomtu pro účely simulce. Rozhrní IAutomton, IStte ITrnsition jsou určen především pro lgoritmy, všk vnitřní implementce těchto rozhrní může ýt využit v dlších funkcích nástroje. Simulátor dostne od editoru implementci utomtu AutomtonImpl, která ude oshovt veškeré metody potřené k usndnění simulce. Z povšimnutí stojí tké metody getgrphicsstte() getgrphicstrnsition(), které umožní simulátoru prcovt přímo s ojekty n scéně. N digrmu je zorzen tké AutomtCretor, jehož rozhrní ude předáno lgoritmům ude pomocí něj umožněno vytváření utomtu. I v editoru y měl ýt k vytváření utomtu využíván výhrdně tento ojekt, neoť se tím zjistí loklit znlostí o vytváření utomtu jeho prvků udou tím usndněny přípdné změny.

37 3.7. SIMULACE PRÁCE KONEČNÝCH AUTOMATŮ 25 Jelikož ude mít simulátor možnost ovládt elementy v editoru, ude celkem jednoduché umožnit generování slideshow. Tto funkce y mohl ýt přínosem zejmén přednášejícím k usndnění generování vzorových příkldů do přednášek. Jediné, co ude nutné uprvit, je export do formátu L A TEX. Exportovné grfy utomtu v jednotlivých krocích simulce je tře spojovt uložit je všechny jko jeden celek.

38 26 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

39 Kpitol 4 Relizce Jelikož se projekt stl postupem čsu poměrně rozsáhlým dá se očekávt, že y se n udoucím vývoji mohl podílet i někdo dlší, hodil y se pro zčátky tkové práce lespoň minimální dokumentce. Tto kpitol si klde z cíl seznámit přípdné progrmátory se zákldními principy myšlenkmi použitými při implementci umožnit tk sndnější porozumění progrmu. Jedná se o odlehčený progrmátorský mnuál. Vzhledem k tomu, že psní dokumentce neývá silnou stránkou progrmátorů, ylo y doré udržovt dokumentci přímo v kódu, jelikož je to pro progrmátor většinou mnohem příjemnější. I v prxi se tto metod ukzuje jko velmi užitečná nvíc se díky tomu, že je kód i dokumentce pohromdě, sndněji udržuje jejich vzájemná konzistence. Stčí pouze zpisovt dokumentci ve formě speciálních komentářů. Pro vlstní generování dokumentce je poté použit nástroj DoxyGen [14]. Díky němu je možné vygenerovt konfigurovtelnou dokumentci v HTML či PDF. Bohužel, kód neyl tímto stylem dokumentován od zčátku, tkže ne všechny části progrmu jsou plně dokumentovány, le většin rozšiřitelných částí je zdokumentován lespoň minimálně. I tk všk DoxyGen umí vygenerovt různé typy digrmů zorzující vzthy mezi třídmi, které smy o soě mohou pomoci k lepší orientci v kódu. 4.1 Jk zčít Progrm je implementován testován s knihovnou Qt verze Pro sndnější pochopení kódu progrmu je vhodné se nejprve seznámit s knihovnou Qt, npříkld pomocí online dokumentce [19], která oshuje kompletní referenci ke knihovně spoustu jednoduchých příkldů. Dokumentce je tké součástí instlce Qt dá se prohlížet v progrmu ssistnt. Většin příkldů je dostupná z progrmu qtdemo, odkud jsou příkldy spustitelné u kždého příkldu je odkz n jeho dokumentci. Důležité je změřit se zejmén n Min Window, Grphics View Frmework Undo Frmework. Dále je potře seznámit se s Qt signály sloty. Nstvení projektu je uloženo v projektových souorech *.pro. Tyto souory využívá progrm qmke pro vygenerování Mkefile souorů pro mke či nmke. Pomocí projektových souorů je zároveň možné importovt projekt do různých vývojových prostředí. Hlvní projektový souor Automt_Editor.pro oshuje zákldní nstvení odkzy n podprojekty pomocí proměnné SUBDIRS. Jádro editoru je v podprojektu sources.pro, kde je 27

40 28 KAPITOLA 4. REALIZACE možné nstvit podporu pro SVG experimentálně zpnout vykreslování pomocí OpenGL. Podprojekt lgorithms.pro oshuje implementci zákldních lgoritmů jeho výstupem je sttická knihovn, která se linkuje s editorem. Volitelný podprojekt gvwrpper.pro oshuje implementci rozhrní IGrphViz jeho výstupem je dynmická knihovn. Pokud se tto dynmická knihovn při spuštění progrmu nchází v dresáři./plugins, je nhrán podpor pro rozmisťování pomocí GrphVizu je zpnutá. Posledním podprojektem je příkld implementce pluginu oshující lgoritmy plugin_howto.pro. Konstnty různá nstvení jsou osženy v souoru constnts.h. 4.2 Droná vylepšení V průěhu práce n editoru došlo i k několik droným vylepšením, která znčně zlepšují použitelnost editoru. V první řdě yl vylepšen export do EPS, který je nyní relizovný přímo pomocí třídy QPrinter, který umí vykreslit přímo grfické elementy osžené n scéně. Export je tedy nprosto věrný tomu, co zorzuje editor. Export yl tké rozšířen o podporu formátu SVG, to díky Qt SVG modulu třídě QSvgGenertor. Dlší výrznější změnou je podpor funkcí zoom in zoom out. V souvislosti se změnmi, které se týkjí ovládáním editoru, přiyl i podpor oznčování více elementů možnost mnipulce s celou oznčenou skupinou. Novinkou je tké možnost utomticky uprvit velikost scény podle nkreslených elementů, což zjišťuje funkce expndgrid(). Došlo tké k několik změnám v Prseru, které se týkjí nejen přidání nově podporovných elementů, le i pozměnění lexikálního nlyzátoru s cílem zlepšení rychlosti nčítání souoru. Vylepšen yl tké report chy vrovných hlášení. 4.3 Přechody - Bézierovy křivky Třídní hierrchie přechodů je zorzen n orázku 3.2 n strně 12. Záměrně jsou zorzeny dvě důležité metody, které ovlivňují vykreslování. Metod pint() je virtuální metod, v níž proíhá smotné vykreslování. Tto metod je volán utomticky z hlvní smyčky Qt, kdykoli je potře překreslit jednotlivé grfické elementy n scéně. Jelikož je překreslení potře velmi čsto (překryv okn, změn velikosti okn, ovlivnění jiným elementem,... ), je nutné, y tto metod yl implementován co nejjednodušeji. Ve většině těchto přípdů se totiž nemění tvr (shpe()) grfického elementu, tk není potře přepočítávt prmetry vykreslování. K tomuto účelu slouží metod djust(), která se utomticky volá při změně tvru přechodu. T může nstt jen v přípdě, že je posunut jeden ze stvů, k nimž přechod náleží. V metodě djust(), kterou implementuje kždý konkrétní přechod, je loklizován veškerý výpočet tvru přechodu. Sekvenční digrm n orázku 4.1 popisuje způso, jkým přechody regují n změny polohy připojených stvů. V metodě djust(), kterou implementují třídy reprezentující konkrétní přechody, je implementován výpočet čtyř kontrolních odů dle orázku 3.4 n strně 15. Počáteční koncový od S E leží n průsečíku okrje stvu polopřímky vycházející ze středu stvu pod poždovným úhlem (nglea, ngleb). Jsou nlezeny pomocí metody findintersected- Points() implementovné ve třídě Trnsition. Dále je vypočítán vektor _v (resp. _v), který má úhel odpovídjící prmetru nglea (resp. ngleb) je umístěn do odu S

41 4.3. PŘECHODY - BÉZIEROVY KŘIVKY 29 Orázek 4.1: Změn tvru přechodu sekvenční digrm (resp. E). Velikost vektoru je poté ovlivněn prmetrem ncurv, který všk není v mnuálu k líku VuCnSon-G detilně popsán. Proto yl jeho význm stnoven experimentálně. Výsledná velikost oou vektorů odpovídá vzthu v = len ncurv, kde len je vzdálenost mezi ody S E. Výpočet tvru zkřivených přechodů je velmi podoný. To proto, že všechny přechody TrnsitionArc, TrnsitionLArc, TrnsitionVArc TrnsitionVCurve mjí stejný zákld. Liší se pouze v prmetrech, které ovlivňují jejich tvr. Nejoecnější je přechod \VCurve, u nějž je možné nstvit všechny prmetry. U přechodu TrnsitionVArc je možné zdt jen jeden úhel, tkže o úhly nglea ngleb udou shodné. Zylé dv přechody mjí zfixovány prmetry rcngle ncurv dle definice v líku VuCnSon-G. Z uvedeného popisu vyplývá, že y znčná část logiky v metodě djust() měl ýt shodná. Proto y ylo doré tuto logiku sdružovt v jedné smosttné metodě neopkovt zytečně stejný kód n více místech, což y znčně ztížilo přípdné oprvy. Vzhledem k tomu, že se nejedná o funkční změny, yl z čsovým důvodů refktoring metody djust() odložen. Dlší důležitou metodou je metod ssign(). S přechody je možné provádět operce mzání či editce, přičemž musí ýt možné tyto kce vrátit. Toto zjišťuje implementce Qt Undo Frmeworku. Jelikož kždý stv oshuje seznm přechodů, které k němu náleží, je tře tento seznm uprvovt spolu s kcemi prováděnými s přechody. Když je přechod smzán, musí se ze všech stvů, ke kterým náleží, odert ze seznmu. Při zrušení (Undo) této operce je nutné ho opět přidt. Jelikož přechody mohou náležet k různému počtu stvů, je zodpovědnost přidávání odeírání do tohoto seznmu přenechán n přechodech. Tuto metodu implementují dvě strktní třídy OneStteTrnsition Two- SttesTrnsition. Z zmínku stojí, že je-li při editci poždován změn typu přechodu, musí se ve skutečnosti vytvořit nová instnce odpovídjícího typu přechodu stávjící instnce musí ýt zálohován. Zároveň je původní instnce oderán ze seznmu přechodů u svých stvů nová instnce je nopk přidán. Toto prohození má n strosti odpovídjící QCommnd, konkrétně TrnsitionEditWithDelCommnd. Editce přechodů se řeší v metodě

42 30 KAPITOLA 4. REALIZACE Editor::editTrnsition(), která je přetížená pro dv ázové typy přechodů (jednostvové dvoustvové). Metodu n Editoru volá přímo odpovídjící přechod předá sám see, čímž se zjistí implicitní přetypování n správného předk. 4.4 Speciální symoly znčky Logiku strjící se o vykreslování speciálních symolů, znček různých modifikcí písm zhrnuje tříd StringProcessor. Je to tříd nvržená speciálně pro práci s textem zpsným ve formátu L A TEX. Úkolem StringProcessoru je npodoovt systém L A TEX umožnit tk zorzování textu zpsného kódem podoně, jko ho vygeneruje systém L A TEX. Vzhledem k tomu, že možnosti systému L A TEX jsou orovské, ude StringProcessor, lespoň z počátku, implementovt jen omezenou funkcionlitu. Z toho důvodu musí ýt zároveň nvržen dosttečně rozšiřitelně, y ylo přidávání dlší funkcionlity jednoduché hlvně y neovlivnilo klienty StringProcessoru Tříd StringProcessor Cílem StringProcessoru je identifikovt jednotlivá klíčová slov, která zčínjí znkem \. Kždé klíčové slovo může odpovídt jednomu speciálnímu znku či symolu, neo se může jednt o modifikátor fontu, který má rozsh pltnosti v loku uzvřeném do složených závorek. Zprcovávný znk tedy může ýt speciální symol zpsný kódem, který je zároveň ovlivněný modifikátorem fontu. StringProcessor proto předzprcuje vstupní kód vrátí seznm metdt, kde kždá položk popisuje jeden výsledný znk. Metdt tvoří jednoduchá struktur ChrcterInfo: struct ChrcterInfo { EChngeType chngetype; //!< type of chnge to e done int textidx; //!< idx to originl string QString chrcter; //!< chrcter to e used EFontSize fontsize; //!< font size chnger EModifier modifier; //!< symol modifier } StringProcessor dostává jko vstupní dt celý text, což může ýt npříkld kód popisku přechodu. Při předzprcování nplní seznm TChrcterList, kde kždá položk je typu ChrcterInfo odpovídá jednomu symolu. První záznm chngetype udává, zd má ýt vstupní text změněn. Pokud no, má hodnotu estringtochr. Druhý záznm je pozice v původním textu. Třetí položk chrcter je unifikovné klíčové slovo, které se má zorzit. Jedná se o klíč do mp, které uchovjí seznm podporovných symolů modifikátorů. Unifikovné musí ýt proto, že v L A TEXu lze zpst klíčové slovo ukončené uď mezerou, neo prázdným lokem. Zylé dvě položky jsou modifikátory. Položk fontsize ovlivňuje velikost fontu. Může oshovt hodnoty jko escriptstyle, edisplystyle td. Položk modifier oshuje modifikátor písm, npř. ndtržení či přeškrtnutí. Použité speciální symoly znky jsou definovné v mpě. Mp string2chrmp oshuje všechn klíčová slov, která se mjí převést n jeden znk. Klíčem do této mpy je

43 4.4. SPECIÁLNÍ SYMBOLY A ZNAČKY 31 řetězec, který y měl odpovídt klíčovému slovu. Hodnotou je dvojice udávjící, n který znk se má klíč přeložit jkým fontem se má znk vysázet. Npříkld klíčové slovo \lph odpovídá tomuto záznmu v mpě: string2chrmp["\lph"] = TChrPir(, esymolfont); Tto mp se všk používá ž při dlší práci s předzprcovným textem. Pro předzprcování se používá mp string2kwtypemp, která definuje, do jké skupiny dné klíčové slovo ptří. Npříkld \lph ptří do skupiny estring2chr \overline do skupiny emodifier. V doě implementce se toto řešení jevilo jko dostčující i pro dlší droná rozšíření, le je možné, že omezení, které z toho vyplývá, se v prxi ukáže jko příliš přísné. Z deklrce struktury ChrcterInfo je totiž zřejmé, že není možné spojovt více modifikátorů u jednoho znku. Npříkld nelze písmo ndtrhnout zároveň přeškrtnout. Způsoů, jk toto řešit, je několik. Místo dvou položek fontsize modifier y ylo možné použít pouze jeden zásoník (stck) modifikátorů kždý znk y tk měl plné informce o svém vzhledu. Otázkou je, jký vliv y to mělo n pměťové poždvky. Proto y možná ylo lepší oznčkovt vstupní text tk, y kždý modifikátor věděl, kde zčíná kde končí jeho pltnost. Poté y si ž klientský kód udržovl svůj seznm ktivních modifikátorů. Npříkld při sázení y se po kždém vysázeném znku zkontrolovlo, zd se změnil pltnost některého z modifikátorů podle toho y se uprvil seznm Předzprcování vstupního textu StringProcessor zprcovává text pomocí regulárních výrzů. Výhodou klíčových slov v L A TEXu je, že všechny splňují stejný vzor. Kždé klíčové slovo zčíná zpětným lomítkem poté oshuje řetězec znků. Končí uď mezerou, neo otvírcí složenou závorkou ( { ). Důležitým pozntkem je, že modifikátory mjí pltnost v loku, ve kterém jsou vyvolány. Kždý lok, mimo celého textu, je uzvřen do složených závorek loky je možné vnořovt. Jelikož není možné používt více modifikátorů n jeden znk, ylo zvoleno nejpřirozenější řešení, sice že se vždy použije nejližší z modifikátorů. Předzprcování textu má n strosti metod computechrcterlist(). V textu se pomocí regulárního výrzu specchrcter- Regex("(\\\\ \\{ \\})") njde jeden ze znků \, { }. Pokud je nlezen otvírcí složená závork, zvolá se metod computechrcterlistinblock(), která vyere text v odpovídjícím loku rekurzivně n něj zvolá znovu metodu computechrcterlist(). Tím je jednoduše zjištěno zprcovávání loků. V přípdě, že se odhlí chy v párování závorek, je vyhozen výjimk. Pokud je nlezeno zpětné lomítko, je zřejmé, že se jedná o nějké klíčové slovo či speciální znk. V tomto přípdě mohou nstt tři situce. Může se jednt o klíčové slovo, což se určí pomocí regulárního výrzu keywordregex("((\\\\\\w+)\\s*)"). Pokud tento regulární výrz neodpovídá klíčovému slovu, zkusí se použít výrz escpedchrcterregex pro všechny escpovné znky. Těmi jsou $, %, #, &, ~, _, ^ \. V přípdě, že ni tento regulární výrz neodpovídá, vypíše se vrovná hlášk dv následující znky se použijí eze změny. Pokud text odpovídá výrzu keywordregex, získá se část, která odpovídá skupině definovné v regulárním výrzu. Jelikož je možné v regulárním výrzu vytvářet skupiny, k nimž lze jednoduše přistupovt přes QRegExp::cp(int), není to prolém. Zjistí se, zd mp

44 32 KAPITOLA 4. REALIZACE string2kwtypemp oshuje nlezené klíčové slovo pokud no, záleží n skupině odpovídjící klíčovému slovu. Pro skupinu estring2chr se nplní struktur ChrcterInfo vloží se do chrcterlistu. Skupin efontsize odpovídá modifikátorům fontu, npř. escrpitstyle etextstyle. N tkové klíčové slovo se použije metod prsefontsize(), která nství lokální proměnnou fontsize v metodě computechrcterlist(), která se využívá pro nstvování položky fontsize ve struktuře ChrcterInfo. Odoně je tomu se skupinou emodifier, všk s tím rozdílem, že tento modifikátor má svůj rozsh pltnosti definovný ve vlstním loku, který následuje okmžitě z klíčovým slovem. Je tedy zvolán metod computechrcterlistinblock(). Jelikož se tyto dvě metody voljí vzájemně, tvoří rekurzi. Tím, že se modifikátory ukládjí do lokálních proměnných, zjistí rekurze sm, že je vždy pltný nejvíce vnořený modifikátor. Pokud mp string2kwtypemp klíčové slovo neoshuje, vypíše se vrovná hlášk klíčové slovo se použije jko ěžný text. Zývá dodt, že pro všechny znky, které nejsou součástí žádného klíčového slov, se vytvoří struktur ChrcterInfo s položkou chngetype nstvenou n hodnotu enochnge. Může všk oshovt některé z modifikátorů fontsize či modifier Sázení textu V první řdě je StringProcessor plánován právě n sázení textu pro grfické elementy. V přípdě stvů vlstní tříd Stte smosttnou instnci StringProcessoru. U stvů může ýt totiž jen jeden popisek. Díky elementu \LelX mohou mít přechody více popisků, proto potřeují mít jejich seznm TLelXList. Tento seznm oshuje instnce třídy LelX, což je grfický element nvržený právě pro olení třídy StringProcessor. Kždý grfický element je potomkem strktní třídy QGrphicsItem, kterou nízí Qt Grphics View Frmework, je n něm utomticky volán virtuální metod pint(), kterou musí kždý konkrétní element implementovt. Tříd LelX je důležitá hlvně proto, že není doré mícht funkce StringProcessoru, který slouží pro zprcování textu může ýt využit i jinými klienty pomocí sttických metod, s funkcemi grfických elementů. Rozhrní StringProcessoru poskytuje metodu drwtext(), kterou využívjí všechny elementy oshující nějký text k jeho vysázení. Metod drwtext() se volá vždy z metody pint() dného elementu, který jí předá ukztel n QPinter, který je potřený pro smotné kreslení. Dále metod dostne referenci n počáteční pozici. Pomocí této reference předá StringProcessor svému klientovi koncovou pozici po vysázení textu. Díky tomu může klient sndno npojovt více textů z see. Zákldní použití StringProcessoru zorzuje sekvenční digrm n orázku 4.2. Smotná metod drwtext() poté jednoduše iteruje přes seznm TChrcterList záznmy ve strukturách ChrcterInfo se využívjí pro sázení. Má-li položk chngetype hodnotu estring2chr, použije se mp string2chr- Mp. Klíčem do ní je položk chrcter. Mp vrátí dvojici TChrPir, která oshuje znk font, ve kterém se má znk vysázet. Zohlední se hodnoty modifikátorů pro dný znk podle nich se správně nství font QPinteru. Je-li položk chngetype, použije se vždy efontnorml záznm chrcter se vykreslí přímo, opět le se zohledněním modifikátorů. K smotnému kreslení se použije metod QPinter::drwText(). Jelikož může ýt kždý znk sázen jiným fontem kždý font má jiné proporce, je tře využít QFontMetrics, což je tříd umožňující získt informce o geometrii písm zdného fontu. Díky tomu je možné vykreslit jeden znk odpovídjícím fontem zjistit, jk je široký určit tk počáteční pozici pro vykreslování dlšího znku.

45 4.5. PODPORA OPERACÍ COPY/PASTE 33 Orázek 4.2: Sázení textu sekvenční digrm StringProcessor se le nemusí využívt pouze pro vykreslování textu. Npříkld v dilogu pro simulci KA se StringProcessor využívá pouze n předzprcování textu. K tomu slouží sttická metod StringProcessor::prseSymols(), která vrátí list unifikovných kódů znků. Klient již nemusí řešit rozpoznávání jednotlivých znků ví, že kždá položk v listu odpovídá jednomu znku. Dále se může pomocí metody isspecilsymol() dotzovt, zd je znk speciální. Pomocí metody getsymolprintinfo() si může vyžádt informce, jk má dný znk vysázet. Toho se využívá jk při exportování L A TEX tulky ve třídě TrnsitionTleImpl, tk i při výpisech v SimultionDilogu při simulci práce KA. 4.5 Podpor opercí copy/pste Podporu pro schránku (clipord) implementuje přímo Qt. Do schránky je možné ukládt QMimeDt, což je struktur, která oluje skutečná dt ukládná do schránky přidává k nim zákldní popis týkjící se podporovných formátů. Jedn instnce třídy QMimeDt může oshovt npříkld vektorový orázek ve více formátech zároveň. Díky tomu je možné vložit tkový orázek do grfické plikce přímo exportovný do itmpy zároveň do textového editoru v originálním vektorovém formátu. Do instnce třídy QMimeDt je možné vkládt dt různých stndrdních typů pomocí metod sethtml(), settext(), setimge- Dt(), seturls() setcolordt(). Díky strkci schránky, implementovné n různých systémech různě, mohou k těmto typickým formátům přistupovt i osttní plikce. V přípdě editoru y mohlo mít smysl ukládt exportovná dt do itmpy, le ztím tto funkcionlit neyl implementován. Editor ukládá dt do schránky ve vlstním formátu, k čemuž se využívá metod QMime- Dt::setDt(). T umožňuje nstvit jkákoli dt v podoě QByteArry. Do QByte- Arry se může zpst kždý typ, který Qt zná. V přípdě vlstních typů je nutné typ deklrovt pomocí Q_DECLARE_METATYPE přetížit opertor<< opertor>>. Tyto operátory je ještě tře registrovt pomocí qregistermettypestremopertors<t>(). Poté je

46 34 KAPITOLA 4. REALIZACE možné zpisovt do QByteArry pomocí QDtStrem, jk ukzuje mnásledující kód. QByteArry itemsdt; QDtStrem dtstrem{&itemsdt, QIODevice::WriteOnly}; dtstrem << QString("test") << QDteTime::currentDteTime(); Tkto je možné uložit veškeré prmetry kopírovných stvů přechodů. Nicméně ylo y nutné zřídit jejich zpsání do QByteArry z elementu, přečtení opětnou rekonstrukci kopírovného elementu. Ay ylo jednodušší udržet tyto kce konzistentní, yly nvrženy jednoduché třídy, které mjí z úkol zjistit serilizci deserilizci grfických elementů. StteSerilizer, resp. TrnsitionSerilizer serilizuje stvy, resp. přechody. V podsttě jen do QByteArry v dném pořdí zpíší všechny prmetry elementu potřené pro jeho rekonstrukci. Nvíc jsou k dipozici metody cretestte(), resp. cretetrnsition(), které zjišťují opětnou rekonstrukci grfického elementu z dt přečtených ze schránky. Tyto metody smozřejmě k instncici elementů používjí StteMnger(), resp. Trnsition- Mnger(). Pro sndnější udržení konzistence mezi serilizcí deserilizcí jsou k dispozici mkr SS_PARAMS TS_PARAMS. Díky nim se sndněji zjistí, y serilizer četl dt ve stejném pořdí, v jkém je zpsl. Pro ilustrci je zhrnuto mkro SS_PARAMS. Jde jen o to, že n místo prmetru xx se vloží vhodný operátor, pro čtení dt ze schránky >> pro zápis <<. #define SS_PARAMS(oj, xx) oj.m_sttenme xx \ oj.m_pos xx oj.m_typenme xx oj.m_lel xx \ oj.m_dimmed xx oj.m_sttelinestyle xx \ oj.m_sttelinewidth xx oj.m_sttelinecolor xx \ oj.m_sttelelcolor xx oj.m_sttelelscle xx \ oj.m_sttefillsttus xx oj.m_sttefillcolor xx \ oj.m_dimsttelinestyle xx oj.m_dimsttelinecolor xx \ oj.m_dimsttelinecoef xx oj.m_dimsttelelcolor xx \ oj.m_dimsttefillcolor xx oj.m_sttelinedoulecoef xx \ oj.m_sttelinedoulesep xx oj.m_sttelelsize Posledním prolémem je, jk zjistit ukládání výěru stvů přechodů. K tomu slouží tříd SelectionSerilizer. Tto tříd využívá jednotlivé serilizery přidává dlší funkcionlitu, npř. udržování hotspot odu, což je střed výěru. K dispozici je metod crete- Items(), která zrekonstruuje původní kopírovné elementy. K celé serilizci výěru v editoru je tře jen vytvořit SelectionSerilizer, předt mu všechny vyrné elementy uložit ho do schránky. Při nčítání je úloh podoně jednoduchá. Následující výřez kódu ukzuje, jk se nvržené třídy používjí v editoru. // kopirovni elementu do schrnky QByteArry itemsdt; QDtStrem dtstrem(&itemsdt, QIODevice::WriteOnly); dtstrem << SelectionSerilizer(scene()->selectedItems()); QMimeDt *mimedt = new QMimeDt();

47 4.6. ALGORITMY PRO OPERACE NAD KONEČNÝMI AUTOMATY 35 mimedt->setdt(clipboard_format, itemsdt); QAppliction::clipord()->setMimeDt(mimeDt); // vyer elementu ze schrnky QByteArry itemdt = mimedt->dt(clipboard_format); QDtStrem dtstrem(&itemdt, QIODevice::RedOnly); SelectionSerilizer serilizer; dtstrem >> serilizer; SelectionSerilizer::TItemsPir items = serilizer.creteitems(this, insertpoint); QList<Stte*> sttes = items.first; QList<Trnsition*> trnsitions = items.second; V součsné implementci mjí serilizční ojekty n strosti správnou serilizci všech typů grfických elementů. Vzhledem k tomu, že elementy mohou přiývt, neo se měnit, ylo y správnější delegovt serilizci smotných ojektů přímo do nich. Vyždovlo y to le rozsáhlejší refktoring, který všk není z pohledu funkčnosti nezytný. Nyní je všk nutné, jko dň z ne zcel správný design, myslet n tuto závislost při kždé změně týkjící se rozhrní grfických elementů. 4.6 Algoritmy pro operce nd konečnými utomty Implementce lgoritmů je postven n ázi pluginů. Zákldní sd lgoritmů je součástí sttického pluginu (sttické knihovny), který se linkuje s progrmem při kompilci. Tento plugin je implementován v podprojektu lgorithms.pro. Kždý lgoritmus implementuje rozhrní IAlgorithm všechny lgoritmy jsou poté sdruženy ve třídě implementující rozhrní IAlgorithmHolder. Tto tříd usndňuje exportování lgoritmů ze sttické knihovny do editoru. Zároveň je implementován i podpor pro dynmicky linkovné pluginy, které se předpokládjí v dresáři./plugins. Díky tomu ude možné lgoritmy volně rozšiřovt i ez záshu do kódu editoru Použití pluginů Díky podpoře pluginů přímo v knihovně Qt je jejich implementce sndná. Rozhrní IAlgorithmHolder je registrováno do Qt Met Type systému pomocí mkr Q_DECLARE_- INTERFACE. Dále je exportován implementce tohoto rozhrní, která musí dědit od třídy QOject, pomocí mkr Q_EXPORT_PLUGIN2. N strně editoru se nimportuje stejný plugin pomocí Q_IMPORT_PLUGIN poté již stčí pouze použít třídu QPluginLoder její sttickou metodu stticinstnces(), která vrátí seznm stticky linkovných pluginů typu QOjectList. Kždý z pluginů je možné přetypovt pomocí q_oject_cst n ukztel n poždovné rozhrní, v tomto přípdě IAlgorithmHolder. Pokud se přetypování podří, je k dispozici instnce lgorithmholder, pomocí níž je možné vrátit seznm lgoritmů. Tyto lgoritmy lze předt editoru vytvořit pro ně odpovídjící položky menu.

48 36 KAPITOLA 4. REALIZACE S dynmickými pluginy je to podoné, s tím rozdílem, že není možné je importovt pomocí mkr (tj. při kompilci), le je nutné je nčíst z ěhu progrmu. K tomu slouží opět tříd QPluginLoder. Pro kždý souor nlezený v dresáři./plugins se vytvoří instnce QPluginLoder, která se pokusí nhrát instnci pluginu pomocí metody instnce(), která vrcí ukztel n QOject. Ten je možné opět přetypovt n ukztel n dné rozhrní dále s ním prcovt stejně jko v přípdě sttického pluginu. O typy pluginů jsou nhrávány v metodě MinWindow::lodPlugins(). Dlší lgoritmy je tedy možné jednoduše implementovt do smosttných pluginů. Jestliže je v dresáři./plugins/ nlezen dynmický plugin, zřdí se v něm osžené lgoritmy do smosttného podmenu, jehož titulek je určen názvem pluginu metod IAlgorithm- Holder::getPluginNme(). Pro usndnění implementce prvního pluginu je k dispozici podprojekt plugin_howto, který slouží jko příkld pluginu. Pro kompilci tohoto příkldu je nutné jej přidt v projektovém souoru Automt_Editor.pro. SUBDIRS += plugin_howto Plugin lze smozřejmě překládt i smosttně, ez zdrojového kódu editoru. Ke kompilci pluginu je nutný pouze souor ilgorithm.h s deklrcí rozhrní IAlgorithm Komunikce editoru s lgoritmy Veškerá komunikce mezi editorem lgoritmy proíhá pouze n úrovni rozhrní IAutomton, určeného pro práci s utomty. Editor se zvoleného lgoritmu nejprve zeptá pomocí metody IAlgorithm::getInputCount(), kolik utomtů očekává podle toho zvolá metodu IAlgorithm::run() s příslušným počtem utomtů. Metod vrátí ukztel n IAutomton, což je výsledek lgoritmu. Protože jsou všechny ukztele typu QShred- Pointer, není tře se strt o to, kdo má kterou instnci utomtu destruovt. Jelikož lgoritmy musí čsto vytvářet nové instnce stvů, přechodů či utomtů, je možnost předt jim ukztel n ojekt typu IAutomtCretor, díky kterému udou lgoritmy schopné vytvářet instnce dle rozhrní IStte, ITrnsition IAutomton ez znlosti či nutnosti jejich implementce. Komunikci mezi editorem lgoritmy popisuje digrm n orázku 4.3. Po výěru lgoritmu z menu se spustí metod Editor::runAlgorithm(), která pro nčtení poždovných utomtů používá metodu lodautomt(). Dle poždovného počtu utomtů se zorzí dilog LodAutomtDilog, ve kterém uživtel může zdt názvy souorů (včetně součsného), ve kterých se utomty ncházejí. Detekce utomtu ze scény či souoru proíhá v metodě Editor::getAutomton(). Jk již ylo zmíněno, kždý souor smí oshovt jen jeden utomt. Pokud jsou všechny zprcovávné utomty korektně definovány, je spuštěn lgoritmus. Kontrol definice utomtu spočívá zejmén v kontrole správnosti popisků, což má n strosti metod Trnsition::getChrcters(), která využívá jednoduchý prser LelSyntxChecker, implementovný dle grmtiky popsné v kpitole Ay uživtel nemusel pokždé zdávt všechny prmetry utomtu, tj. ecedu, ε- symol symol pro celou ecedu, je v editoru implementován metod detectautomt- Settings, která se pokusí tyto prmetry určit utomticky.

49 4.6. ALGORITMY PRO OPERACE NAD KONEČNÝMI AUTOMATY 37 Orázek 4.3: Komunikce mezi editorem lgoritmy sekvenční digrm Kždý lgoritmus může mít ještě dodtečná nstvení. To určuje návrtová hodnot funkce IAlgorithm::hsSettingsDilog(). V tom přípdě je možné z dilogu spustit nstvení lgoritmu pomocí metody runsettingsdilog(). Ztím ohužel neyl implementován perzistence těchto nstvení, tkže jej uživtel musí provádět po kždém spuštění progrmu znovu. Jednou z možností je použít třídu QSettings, která je pro uchovávání nstvení přímo nvržen. Poslední možností je vol rozmisťovcího lgoritmu, která je tké umožněn v tomto dilogu. Možná y ylo rozumnější umožnit tento výěr ž po úspěšném ukončení lgoritmu, y si uživtel mohl vyrt vykreslovcí lgoritmus n zákldě jeho výsledků. N druhou strnu y se uživtel musel kvůli jedinému úkolu (spuštění lgoritmu) proklikt několik dilogy to y jistě nepůsoilo příjemně. V přípdě, že to ude poždováno, y ylo lepší implementovt lgoritmus, který nic nedělá pouze umožňuje překreslení součsného grfu jiným rozmisťovcím lgoritmem. Rozhrní IAutomton je připrveno n podporu lgoritmů, které udou pozice stvů tvry přechodů určovt smy. Prolém všk je, že do tříd IStte ITrnsition informce o pozici či typu elementu neptří. Vznikl proto nápd uchovávt tyto informce v smosttných mpách. Metod hspositions() udržuje informci o tom, zd utomt oshuje informce pro pozicování. Klíčem do mpy pozic stvů je jméno stvu, le prolém nstává při volě klíče do mpy typů přechodů. Jk rozlišit dv přechody, které náleží ke stejným stvům jsou definovány pro stejný symol? Jednou možností je tkové duplicitní přechody úplně zkázt. Tto funkcionlit není v součsné verzi editoru implementován je pouze připrven náznk řešení tohoto prolému. V udoucnu y všk ylo vhodné tuto funkcionlitu implementovt, neoť y poté ylo možné implementovt i generátory utomtů jko

50 38 KAPITOLA 4. REALIZACE smosttné pluginy Jednotlivé lgoritmy V podprojektu lgorithms yly implementovány zákldní lgoritmy nd konečnými utomty. Většin z nich yl převzt ze skript k předmětu Jzyky Překldy [9]. Jelikož lgoritmy jsou popsány ve zmiňovných mteriálech, následující popis lgoritmů se vzthuje pouze k jejich implementci v této práci vždy s odkzem n konkrétní lgoritmus. V digrmu n orázku 3.6 n strně 21 jsou jednotlivé lgoritmy zorzeny jednotně jko ConcreteAlgorithm, přípdně ConcreteAlgorithmWithSettings. Vstupním odem kždého lgoritmu je metod run(), která vrcí ool. V přípdě, že selže (tj. vrátí flse), může lgoritmus vrátit důvod svého selhání přes volitelný prmetr report. Odstrnění ε-přechodů RemoveEpsilonAlgorithm odpovídá lgoritmu 2.41 ze skript. Zákldem je výpočet ε- uzávěru pro kždý stv utomtu. Tento výpočet je implementován ve třídě BseAlgorithm v metodě getepsilonclosure(). Jkmile je k dispozici mp ε-closure oshující záznm pro kždý stv, je již úloh jednoduchá vytvoří se nová množin přechodů. Odstrnění nedosžitelných stvů RemoveInccessileAlgorithm je implementován dle lgoritmu Je zde použit jedn mlá změn. Jelikož se dosžitelné stvy uchovávjí v seznmu ccessilesttes, stčí si pro kždý dlší krok cyklu pmtovt pouze nově dosžené stvy, přičemž kždý nově dosžený stv je přidán do seznmu ccessilesttes. Tím se zredukuje počet nutných kroků cyklu. N zčátku jsou v množině Q 0 všechny počáteční stvy. Algoritmus končí, jestliže je seznm Q i + 1 prázdný, tj. všechny dosžitelné stvy yly již ojeveny. Odstrnění zytečných stvů Nlezení užitečných odstrnění zytečných stvů je implementováno ve třídě Remove- UselessAlgorithm. Algoritmus je velmi podoný předchozímu s tím rozdílem, že množin Q 0 oshuje všechny koncové stvy grfem se prochází proti směru přechodů. Odstrnění více počátečních stvů Převod konečného utomtu s více počátečními stvy n utomt s jedním počátečním stvem je implementován dle lgoritmu 2.46 ve třídě RemoveMultipleInitilsAlgorithm. Vytvoří se nový stv, jehož jméno vznikne spojením původních počátečních stvů. Ay yl zjištěn jedinečnost názvu nového stvu, použije se metod BseAlgorithm::mkeSure- NmeUnique(), která v přípdě, že stv se stejným jménem již v utomtu existuje, přidává ke jménu stvu znk * tk dlouho, dokud není jméno stvu unikátní. Poté se z nového stvu npojí nové přechody do stvů, do kterých vedly přechody z původních počátečních stvů. Nkonec mohou z původních počátečních stvů vzniknout nedosžitelné stvy, které jsou odstrněny.

51 4.6. ALGORITMY PRO OPERACE NAD KONEČNÝMI AUTOMATY 39 Determinizce konečného utomtu DeterminizeAlgorithm je tříd implementující převod nedeterministického konečného utomtu n deterministický dle lgoritmu 2.51 ve skriptech. Protože lgoritmus očekává n vstupu utomt s jedním počátečním stvem ez ε-přechodů, je utomt nejprve uprven do poždovného stvu pomocí již implementovných lgoritmů RemoveMultipleInitils- Algorithm RemoveEpsilonAlgorithm. Jediný prolém při implementci nstává při vytváření nových stvů. Jméno nového stvu je vždy odvozené od několik stvů je nutné si pmtovt, ze kterých stvů je nový stv odvozen. Proto je použit mp nmetonme- ListMp. Zároveň je nutné, y jméno stvu odvozené od stejných stvů ylo vždy stejné. Jink y totiž mohlo vznikt více stvů, které y ve skutečnosti měly ýt stejné. Proto je nutné řdit seznm uzlů vzniklý při výpočtu δ (q, ) podle názvu. K tomu je využit funkce qsort(). Tento lgoritmus je zástupce lgoritmů s nstvením. Nstvení umožňuje zvolit, zd se mjí zchovt názvy stvů, tj. kždý stv ude mít jméno odpovídjící stvům, ze kterých je odvozený. K tomu slouží metod preservenmes(). Stejně tk je možné nstvit zchovávání popisků, což určuje metod preservelels(). Jméno popisek stvu jsou poté určeny metodmi choosesttenme() choosesttelel(), které vrcí poždovné hodnoty dle nstvení. Všechny tyto metody jsou implementovány v ázové třídě BseAlgorithmWith- Settings. Minimlizce konečného utomtu Tento lgoritmus je převzt z volně dostupných mteriálů k předmětu Teoretická informtik z Technické univerzity Ostrv [3]. N vstupu je deterministický konečný utomt ez nedosžitelných stvů. Algoritmus proíhá tk, že n zčátku se všechny stvy rozdělí n dvě skupiny. V první skupině jsou koncové stvy ve druhé osttní. Kždá skupin má své číslo nzývá se množin ekvivlence. Pomocí čísel množin ekvivlence se vyplní přechodová tulk. Pokud nemjí stvy z jedné skupiny shodný záznm v přechodové tulce, znmená to, že nejsou ekvivlentní. Proto se skupin rozdělí tk, že všechny stvy se stejnými záznmy tvoří vždy jednu novou skupinu. Znovu se vyplní přechodová tulk celý postup se opkuje, dokud nemjí všechny stvy z jedné množiny ekvivlence shodný záznm v přechodové tulce. V krjním přípdě udou všechny množiny ekvivlence oshovt pouze jeden stv lgoritmus skončí. V přípdě, že některá množin oshuje více stvů, znmená to, že stvy v ní jsou ekvivlentní je možné je sjednotit. N konci lgoritmu pltí, že kždá skupin odpovídá jednomu stvu ve výsledném utomtu. Algoritmus je implementován ve třídě MinimizeAlgorithm. Pro jednodušší práci se skupinmi je k dispozici tříd Group. Stvy se do skupin ukládjí jko položky typu GroupItem, vytvořené n zákldě informcí získných ze stvů. Dle definice lgoritmu se vytvoří první dvě skupiny poté se spustí výpočet. Zákldem výpočtu je metod Group::computeAnd- Split(), která zjistí kontrolu, zd stvy z dné skupiny splňují podmínku ekvivlence. Pokud ne, je skupin rozdělen n skupiny se stejným záznmem v přechodové tulce. Toto se udělá pro všechny skupiny. Algoritmus skončí, nezmění-li se počet skupin. Kód

52 40 KAPITOLA 4. REALIZACE lgoritmu s využitím třídy Group je velmi jednoduchý: Group::TGroupList groups;... // nplni se prvni dve skupiny while (true) { Group::TGroupList newgroups; for (Group::TGroupList::ConstItertor groupit = groups.egin(); groupit!= groups.end(); ++groupit) { newgroups << (*groupit)->computeandsplit(groups); } if (newgroups.count() == groups.count()) rek; } groups = newgroups; Zývá jen odstrnit ekvivlentní stvy. Odstrnění se provede tk, že se vyere jeden stv z kždé skupiny ten se ponechá. Osttní stvy ze skupiny jsou smzány. Byl-li nějký stv ze skupiny počáteční, ude ponechný stv tké počáteční. Koncové skupiny jsou dné koncové stvy se při ěhu lgoritmu nemohou pomícht s nekoncovými. Přechody vedoucí do odstrněných stvů se přepojí do ponechného zástupce skupiny. Duplicitní přechody řeší v tomto přípdě implementce utomtu. Sjednocení konečných utomtů Algoritmus pro konstrukci utomtu pro sjednocení jzyků 2.71 je implementován ve třídě UnitePrllelAlgorithm. Jk název npovídá, jedná se o lgoritmus simulující prlelní činnost oou utomtů. Jednotlivé stvy výsledného utomtu vznikjí při prlelním průchodu konečnými utomty tk, že se odvodí od ktivních stvů v kždém kroku. Před spuštěním lgoritmu se z oou utomtů odstrní ε-přechody více počátečních stvů. K zjištění správného ěhu lgoritmu je nutné npřed uprvit jmén stvů v oou vstupních utomtech, y všechny stvy měly unikátní jméno. K tomu opět slouží metod mke- SureNmesUnique(). Podoně jko při determinizci se používá mp nmetonmelistmp seznm stvů v průěhu lgoritmu se musí řdit, než se z něj odvodí jméno stvu. Algoritmus ptří do skupiny lgoritmů s nstvením, je tedy možné zvolit, zd ude zchovávt jmén popisky stvů. Průnik konečných utomtů Konstrukce utomtu pro průnik jzyků je tké implementován pomocí simulce prlelní činnosti utomtů, to ve třídě IntersectionPrllelAlgorithm dle lgoritmu Implementce je velice podoná lgoritmu pro sjednocení konečných utomtů, jen je nutné dát pozor n to, kdy je vzniklý stv koncový. Nový stv ude koncový, pouze pokud se při prlelní činnosti ncházejí o vstupní utomty v koncovém stvu.

53 4.7. ROZMISŤOVACÍ ALGORITMY Rozmisťovcí lgoritmy Rozmisťování grfů, zvláště pk neplnárních, není vůec jednoduchá úloh. Proto se předpokládá, že ude snh rozmisťovcí lgoritmy dále vyvíjet vylepšovt. Z toho důvodu všechny vykreslovcí lgoritmy implementují stejné rozhrní, IDrwAlgorithm. Díky tomu je možné jednotlivé lgoritmy jednoduše změňovt. První implementovný lgoritmus je NiveDrwAlgorithm. Snží se pouze rozmístit kždý stv n jiné místo nejjednodušší způso, jk toho dosáhnout, je vykreslovt všechny stvy do jedné řdy. Nkonec se přidjí všechny přechody jko rovné čáry. Důvodem pro implementci tohoto lgoritmu yl potře mít rychle k dispozici nějký funkční převodník implementce IAutomton n grfické ojekty n scéně, y ylo možné testovt lgoritmy nd konečnými utomty. Není proto nutné se tímto lgoritmem dále zývt rozerány jsou již jen dv zákldní lgoritmy. Heuristik FrthestFinlStteDrwAlgorithm lgoritmus GrphVizDrwAlgorithm, který pro rozmisťování grfických elementů používá knihovnu GrphViz Heuristik Všechny rozmisťovcí lgoritmy mjí v součsné doě společného předk, třídu Bse- DrwAlgorithm, která sdružuje některé znovupoužitelné funkce. Vykreslovcí heuristik je implementován ve třídě FrthestFinlStteDrwAlgorithm. Myšlenk tohoto lgoritmu je odvozen z toho, jk se většin konečných utomtů kreslí ve skriptech. Hlvní linii utomtu většinou tvoří páteř, přičemž zývjící stvy jsou rozmístěny okolo ní. Heuristik se pokusí vhodně zvolit páteř, která se rozmístí jko první do řdy. Poté se vezmou všechny stvy ve vzdálenosti jedn od počátečního stvu vykreslí se, dále stvy ve vzdálenosti dv td. Až nkonec se vykreslí všechny přechody. Z uvedeného popisu vyplývá, že je potře znát vzdálenosti všech stvů od počátečního stvu. K tomu slouží Dijkstrův lgoritmus pro nlezení nejkrtších cest ze všech stvů do jednoho stvu, implementovný ve třídě BseDrwAlgorithm. Podsttou tohoto lgoritmu je prioritní front, jejíž implementce všk není jednoduchá. V STL je všk implementce priority_queue dostupná, i když má jednu podsttnou vdu neumí se přizpůsoovt při změnách hodnot svých položek. Položky (vzdálenosti stvů) se le mění v průěhu lgoritmu při relxci. Tento prolém možná neyl vyřešen příliš efektivně. V kždém kroku se před relxcí přesunou všechny stvy do zásoníku, poté se provede relxce nkonec se stvy ze zásoníku přesunou zpět do fronty. Stvy ve frontě jsou řzeny podle součsné vzdálenosti od počátečního stvu. K tomu je implementován jednoduchý funktor DistnceComprtor, který se předá v konstruktoru prioritní frontě. Algoritmus zároveň se vzdálenostmi njde i cesty do jednotlivých stvů, což se hodí při vykreslování. Vzdálenosti se ukládjí do mpy BsicDrwAlgorithm::TDistnceMp cesty jsou uloženy tk, že je ke kždému stvu znám jeho předchůdce. Tito předchůdci se ukládjí do mpy TPredecessorMp. Algoritmus se spouští metodou filldijkstrshortestpths(). Jkmile je k dispozici mp vzdáleností předchůdců, je možné přistoupit k nlezení vhodné páteře. Vyere se nejvzdálenější koncový stv pomocí mpy předchůdců se z něj zrekonstruuje cest do počátečního stvu. Tím je výěr páteře hotov může se rozmístit. Jelikož některý ze zývjících stvů může mít větší vzdálenost od počátečního stvu než nejvzdálenější koncový uzel, je poslední uzel n páteři umístěn tk, y yl vždy nejvíce vprvo v celém výsledném grfu, tj. jko y yl nejvzdálenější ze všech stvů.

54 42 KAPITOLA 4. REALIZACE V dlším kroku se vykreslí zývjící dostupné stvy, tk jk je to popsáno pseudokódem v kpitole Nejprve se vykreslí stvy ve vzdálenosti jedn, střídvě jeden nhoru, jeden dolů se zvětšujícím se krokem, tkže grf roste do výšky. Stejně se postupuje ž do mximální vzdálenosti. Může se stát, že některé stvy jsou nedostupné tudíž ještě nejsou v tomto kroku vykresleny. Tyto stvy se vykreslují nd vykreslený grf, to vedle see tk dlouho, dokud jejich počet nepřesáhne mximální vzdálenost od počátečního stvu. V tom přípdě jsou kresleny opět o jeden řádek výš. Rozteče mezi jednotlivými stvy jsou definovány sttickými konstntmi BseDrwAlgorithm::X_STEP BseDrwAlgorithm::Y_STEP. Když jsou vykresleny všechny stvy, přistoupí se k vykreslování přechodů. Přechody jsou vykreslovány v metodě BseDrwAlgorithm::drwTrnsitions(). Při vykreslování kždého přechodu se vždy spočítá počet přechodů, které již jsou mezi stvy, ke kterým se přechod přidává. Pokud ještě žádný přechod mezi stvy není, přidá se přechod typu \Edge. V přípdě, že je již zjištěn jeden přechod, přidá se přechod typu \VArcL s úhlem rcngle=30. V přípdě dvou přechodů se pro změnu přidá přechod opčným směrem \VArcR se stejným úhlem. Při více přechodech se vždy střídá směr zvětšuje úhel o definovný nglestep. Tím y se mělo zjistit, že se nikdy dv přechody neudou úplně překrývt ude vždy možné rozpoznt kždý vykreslený element. Největší neduh této heuristiky je v tom, že při rozmisťování stvů nejsou uvžovány přechody mezi nimi. To může způsoovt zytečné křížení hrn i tm, kde y k tomu nemuselo docházet. Nicméně heuristik yl nvržen jko velmi jednoduchá jejím hlvním cílem je rozmístit grf pokud možno tk, y ho uživtel dokázl jednoduše uprvit do esteticky přijtelné podoy. Počítá se, že ude využíván hlvně v přípdech, kdy neude možné použít GrphViz. Je tedy zárukou, že i ez GrphVizu ude k dispozici rozumné rozmisťování GrphViz wrpper GrphViz je silný nástroj, který implementuje poměrně kvlitní rozmisťovcí lgoritmy. Je schopný rozumně vykreslit i neplnární grfy, proto y yl škod jej nevyužít plýtvt čsem n implementci vlstního sofistikovného lgoritmu, u kterého y nvíc neyly zručeny lepší výsledky než při použití GrphVizu. Bylo všk tře splnit rozumný poždvek, y editor neyl n GrphVizu přímo závislý. Proto yl implementován plugin, který pomocí rozhrní IGrphViz odstiňuje knihovny GrphVizu od zytku editoru. Implementce pluginu tk zároveň převádí rozhrní GrphVizu z jzyk C do jzyk C++ zjednodušuje jeho použití n strně editoru. Neyl implementován celá funkcionlit GrphVizu, le pouze části nezytné pro vykreslovcí lgoritmus. Rozhrní IGrphViz spolu s jeho implementcí je znázorněno n digrmu 4.4. Rozhrní pluginu pro GrphViz je implementováno v podprojektu gvwrpper.pro. Výstupem je sdílená knihovn, kterou se editor pokusí nhrát pokud ji nenjde, rozmisťovcí lgoritmus využívjící GrphViz se nepoužije. Tím je zjištěn nezávislost editoru n knihovnách GrphVizu. Pokud není n počítči, kde je editor překládán, dostupný GrphViz, stčí jednoduše zkomentovt použití podprojektu gvwrpper v hlvním projektovém souoru Automt_editor.pro. Pokud se editoru podří nhrát plugin, získá od něj instnci implementce rozhrní IGrphViz. Tuto instnci editor předá rozmisťovcímu lgoritmu GrphVizDrwAlgorithm, který ji využívá k vytváření grfu IGVGrph. Rozhrní IGVGrph

55 4.7. ROZMISŤOVACÍ ALGORITMY 43 Orázek 4.4: Rozhrní pluginu pro GrphViz digrm tříd umožňuje přidávt uzly hrny do grfu tké rozmístit grf pomocí metody lyoutgrph- UsingDot(). Algoritmus si vyžádá pozice uzlů prmetry hrn použije tyto informce pro rozmístění stvů přechodů n scéně. Tím je práce tohoto rozmisťovcího lgoritmu hotov. Pro rozmístění grfu jko utomtu je potře provést následující nstvení GrphVizu: m_gvc = gvcontext(); // orientovny grf m_grph = gopen((chr*)"g", AGDIGRAPH); // rozmisteni zlev doprv grphttr(m_grph, (chr*)"rnkdir", (chr*)"lr"); // pouzivt ezierovy krivky grphttr(m_grph, (chr*)"splines", (chr*)"true"); // popisek muze mit lel gedgettr(m_grph, (chr*)"lel", (chr*)""); Třídy GVNode GVEdge jsou instnciovány, jen když se klient (v tomto přípdě editor) dožduje výsledků rozmisťovní. Všechny metody typu getnode(), getedge() vrcejí nové instnce těchto tříd, které pouze olují ukztele n skutečné uzly hrny v GrphVizu. V závislosti n tom, jk je nvržen práce s elementy grfu v GrphVizu, je pro iterování přes uzly nejlepší použít metody IGVGrph::getFirstNode() dále IGVNode::getNext- Node(). Pro iterce přes hrny je nutné si pro kždý uzel vyžádt první výstupní hrnu

56 44 KAPITOLA 4. REALIZACE pomocí IGVNode::getFirstOutEdge() poté přes dlší výstupní hrny dného uzlu iterovt metodou IGVEdge::getNextOutEdge(). Při získávání prmetrů z GrphVizu ylo prolémem, že hrny nejsou vykreslovány jen pomocí čtyř kontrolních odů, jko je tomu v editoru, le pomocí 3n + 1, n 1 kontrolních odů. Bylo tře nějk vhodně zvolit 4 kontrolní ody z nich spočítt úhly nglea ngleb pro přechod typu \VCurve. První poslední kontrolní od je nutné zchovt. Jsou to ody npojení n stv spočítjí se pomocí nich potřené úhly. Osttní ody nejsou v součsné implementci použity, le správně y se z nich měl nějk spočítt hodnot prmetru ncurv. Vzhledem k tomu, že i implementce s pevně nstveným prmetrem ncurv vykzuje doré výsledky, ylo řešení tohoto prolému odloženo. Je tké nutné dávt pozor n to, že všechny souřdnice získné z GrphVizu jsou vztžené k opčně orientovné ose y musí se proto přepočítávt vzhledem k výšce scény. GrphVizWrpper není ještě zcel dokonlý, le pro implementci kvlitního rozmisťování je dosttečný. V součsné doě není implementován detekce polohy popisku vůči křivce (vlevo či vprvo), což y v udoucnu mohlo ýt užitečné. Nyní jsou všechny popisky umístěny stejně může docházet k nepříjemnému překrývání. Přesná detekce z výstupu GrphVizu y to mohl vyřešit zmezit tk nutnosti dlšího záshu ze strny uživtele. Zývá dodt, že pro testovcí účely yl implementován i metod IGVGrph::renderTo- File(), která uloží grf vykreslený pomocí GrphVizu do souoru díky tomu je možné ho porovnávt s grfem, který vykreslil editor. Zjímvá y yl i možnost exportu přímo pomocí GrphVizu, le nevýhodou y ylo, že y uživtel dopředu nevěděl, jk ude výsledek vypdt. Pro tuto funkci y všk ylo tře GrphVizWrpper doplnit o dlší metody, které y umožňovly nstvení rozličných prmetrů, jko je rv tloušťk čáry jednotlivých elementů. 4.8 Přechodová tulk Jednou z metod rozhrní IAutomton je metod gettrnsitiontle(). Tto metod vrcí ukztel n ITrnstionTle, což je rozhrní pro přechodovou tulku. Přechodová tulk yl do rozhrní utomtu zhrnut zejmén proto, že y některé lgoritmy mohly pro efektivnější ěh vyždovt rději tulku než utomt jko ojekt. Jelikož tkový lgoritmus neyl implementován, je možné, že rozhrní tulky ude přípdně vyždovt dlší zásh. Stejně tk y ylo vhodné implementovt metodu n rozhrní IAutomtCretor pro vytvoření utomtu z přechodové tulky. Smotná tulk se skládá z řádků ITTRow. Kždý řádek je identifikován hlvičkou typu QStringList (seznm stvů ze kterých je stv odvozen). Přechody se vyplňují postupně pro kždý symol pomocí přetíženého operátoru opertor[]. Není-li pro symol definován přechod, není tře ho do tulky vyplňovt. Kždému řádku je možné nstvit příznk počátečního či koncového stvu pomocí metod setinitilflg(), resp. setfinlflg(). V implementci tulky ve třídě TrnsitionTleImpl je seznm přechodů (v podsttě sloupce tulky) implementován pomocí mpy, kde klíčem je symol typu QString hodnotou identifikátor řádku, n který se přechází. V progrmu je přechodová tulk využit zejmén pro export do L A TEXu. Proto přímo tulk umožňuje svůj vlstní export do formátu systému L A TEX. To zjišťuje metod

57 4.9. SIMULACE PRÁCE KONEČNÝCH AUTOMATŮ 45 toltextle(). Následující kód ukzuje, jk se z utomtu získá přechodová tulk: QShredPointer<IAutomton> utomton;... // ziskni utomtu QString ltextle = utomton->gettrnsitiontle()->toltextle();... // vytisknuti tulky ci ulozeni do souoru Pro smotný převod tulky do L A TEXu se používá i tříd StringProcessor. T je využit k rozpoznávání speciálních symolů, npříkld symolů řecké ecedy. V přípdě, že se jedná o speciální symol, je nutné ho uzvřít do mtemtického prostředí pomocí dvojice znků $. Pro přehlednější zorzování tulky přímo v editoru yl implementován metod to- StringTle(), která převede přechodovou tulku do jednoduché textové formy. Dlším rozšířením editoru y mohl ýt implementce interktivní tulky, npříkld s využitím třídy QTleWidget, kde y ylo možné tulku nejen zorzit, le tké editovt. Opět y se vypltilo mít metodu pro vytváření utomtu z přechodové tulky, což y uživteli umožnilo utomt zpst pouze tulkou ten y se sám vykreslil. V součsné doě je implementován jen jednoduchý dilog umožňující prohlížení exportovné tulky přípdně zkopírování do schránky. 4.9 Simulce práce konečných utomtů Simulci práce konečných utomtů zjišťuje tříd AutomtWorkSimultor spolu s dilogovým oknem SimultionDilog. Simulátor prcuje s instncí utomtu AutomtonImpl. Tedy ne s rozhrním IAutomton, které se předává v přípdě lgoritmů, le přímo s jeho implementcí. Díky tomu je možné nvázt elementy utomtu přímo n grfické ojekty n scéně umožnit tk grfickou simulci. Díky dilogu s podoným rozhrním, jké se využívá pro přehrávání médií, je ovládání simulce intuitivní nemělo y uživteli činit výrzné prolémy. Dilog je zorzen n orázku 4.5. Při simulci je omezen funkcionlit editoru tk, y neylo možné nijk editovt simulovný utomt. Je všk možné ndále exportovt či ukládt součsný stv grfu konečného utomtu. Pro spuštění simulce je nezytné zdt vstupní řetězec. Vstupní řetězec y měl ýt zdáván jko posloupnost symolů, to i s možností zdávání speciálních symolů, npříkld řecké ecedy. Zápis vstupního řetězce je shodný se syntxí používnou systémem L A TEX. K rozpoznávání korektnosti vstupního řetězce rozdělení n jednotlivé symoly se opět používá StringProcessor. Tto tříd se využívá i pro zápis konfigurce. V dilogu je možné zvolit, zd se má použít pretty printing, což znmená, že se kódy speciálních symolů převedou n odpovídjící znk v dném fontu. K veškeré funkcionlitě spojené s převodem kódů symolů n logické symoly nopk se používá právě StringProcessor. Při simulci již simulátor prcuje pouze s logickými symoly typu StringProcessor::ChrcterInfo. Simulátor po celou dou simulce komunikuje s dilogem, který pouze kopíruje jeho stv. K simulci se využívá struktur Configurtion, která uchovává informce o součsné konfigurci utomtu. V kždém kroku se tto struktur nplní uloží se do seznmu m_configurtionlist, který uchovává celý průěh simulce. Podle stvu poslední konfigurce se rozhodne, může-li simulce pokrčovt. V konfigurci jsou uchovány ktivní stvy, zprcovná část vstupního řetězce, zývjící část vstupního řetězce sttus, který může

58 46 KAPITOLA 4. REALIZACE Orázek 4.5: Dilog pro simulci práce konečného utomtu nývt hodnot enosttus, eerror eaccepted. V přípdě, že je konfigurce ve stvu eerror, není již možné provádět dlší kroky. Seznm konfigurcí se předává dilogu, který tk může zorzit kroky výpočtu. Vzhledem k tomu, že simulátor ovlivňuje stv grfických elementů editoru, je nutné, y všechny změny, které simulátor provádí, yly prováděny pomocí příkzů Undo Frmeworku, tedy pomocí potomků třídy QCommnd. Díky tomu se lze i po skončení simulce vrcet k jednotlivým konfigurcích utomtu pomocí kcí undo redo. Jelikož všechny příkzy jsou ukládány v zásoníku QUndoStck, je možné ho využít i pro krokování simulce není nutné pro kroky zpět vytvářet nové příkzy, což y v přípdě dlouhého krokování simulce tm zpět mohlo mít z následek nepřiměřené zvětšování velikosti zásoníku. Jednotlivé kroky simulce zjišťuje metod processstep(). V této metodě se spouští i nimce, pokud jsou vyždovány. K nimcím se vyžívá QTimer m_nimtiontimer. Pomocí Qt Signálů Slotů je signál z čsovče npojen n metodu nimte(), ve které se spustí jeden krok nimce. Pro utomtickou simulci se používá ještě druhý čsovč m_simultion- Timer. Jkmile se všk spustí jeden čsovč čeká se n jeho ukončení, události od druhého čsovče nejsou zprcovávány. Proto je využito čekání s voláním zprcování smyčky zpráv v Qt: while (m_nimtiontimer->isactive()) { QCoreAppliction::processEvents(QEventLoop::ExcludeUserInputEvents); }

59 4.10. PROBLÉMY PŘI IMPLEMENTACI 47 Není to nejelegntnější řešení, le splňuje účel. Simulce je v editoru zorzován pomocí orvování ktivních stvů při nimci jezdí po přechodech mlé kolečko. Toto kolečko je implementováno pomocí třídy SimultionMrker. Díky třídě QPinterPth, kterou umí kždý přechod vrátit, lze jednoduše získt pozici kolečk v jednotlivých krocích nimce. Oshuje totiž metodu pointatpercent(), která dokáže vrátit od v zdné části křivky přechodu. V dilogu se při simulci vypisují jednotlivé kroky výpočtu oznčuje se již přečtená část vstupního řetězce. SimultionMrker je potomek třídy QRuerBnd. Jk se le ukázlo, není to nejšťstnější řešení, neoť v některých konfigurcích knihovny Qt (npříkld při experimentálním vykreslování pomocí OpenGL) je prolém s jeho korektním vykreslováním. Lepším řešením y ylo implementovt kolečko jko potomk třídy QGrphicsItem. Znčk y se totiž vykreslovl pomocí stejných metod jko osttní grfické elementy přímo n scénu, ztímco při použití QRuerBnd se vykresluje jkoy nd scénu používá odlišné vykreslovcí metody, což je prvděpodoně zdrojem prolémů při vykreslování. Bohužel, ž po implementování simulátoru yl ojeven poměrně nový Qt Animtion Frmework, pomocí kterého y se grfická simulce implementovl mnohem sndněji. Odpdl y npříkld prolém se dvěm čsovči, neoť tuto funkcionlitu Animtion Frmework zpouzdřuje. Nvíc y díky němu ylo možné využít kinetické efekty, které používjí tkzvné esing křivky. Ty umožňují jednoduše implementovt npříkld přechod se zrychlením, přípdně s pružinovým efektem Generování slideshow Při simulci je sice možné ukládt jednotlivé kroky přímo pomocí funkcí editoru, le jeli potře uložit celou posloupnost kroků simulce, npříkld pro export do L A TEXu, může ýt tto činnost nepříjemně zdlouhvá. Proto vznikl nápd implementovt generování slideshow pomocí formátu VuCnSon-G. Díky tomu, že simulátor provádí změny přímo n grfických elementech editor smozřejmě umí exportovt svůj stv, neyl implementce této jistě využitelné funkce příliš náročná. Bylo jen potře provést neptrný refktoring funkcí pro export, y ylo možné ukládt více grfů do jednoho souoru ve formátu L A TEX. V součsné verzi všk není generování slideshow příliš konfigurovtelné může tk sloužit spíš jen jko kostr pro vytvoření prezentce Prolémy při implementci Qt komptiilit mezi verzemi Jelikož vývoj editoru trvl poměrně dlouho, jevilo se jko rozumné držet krok s vývojem knihovny Qt snžit se udržovt provozuschopnost vždy s ktuální verzí. Původní verze yl implementován s knihovnou Qt verze Před zčátkem práce n dlší verzi progrmu již yl dostupná knihovn Qt verze přechod n ni neyl tk jednoduchý, jk y se mohlo zdát. Většinu funkcí neylo nutné uprvovt, le především části Grphics View Frmeworku prodělly tkové změny, že z principu přestlo správně fungovt vykreslování elementů. Většin změn v Qt sice měl své důvody (především výkonnostní), le ohužel ne vždy yly změny, které se musely plikovt, dosttečně popsány v dokumentci. V původní

60 48 KAPITOLA 4. REALIZACE verzi npříkld stčilo k překreslení elementu zvolt funkci updte(). V nové verzi je všk při změnách proporcí elementu nutné zvolt funkci prepregeometrychnge(), y se oprvdu překreslil celý element. Jelikož knihovn Qt je stále ve vývoji, je logické, že se očs může ojevit i nějká chy přímo v knihovně. Při vývoji nděll nečekné prolémy chy ve třídě QFileDilog, která způsoovl to, že se neplikovl žádný filtr neylo tedy možné zvolit formát ukládání. Největší prolém při řešení chy v multipltformní knihovně je to, že se čsto projevují jen n některých systémech. Zmiňovná chy děll prolémy jen n linuxových systémech (testováno n Uuntu 9.04). Proto je nutné progrm průěžně testovt n všech vývojových pltformách. Součsná verze Qt vizuje dlší změny v grfickém frmeworku jelikož y přechod n ni zřejmě vyždovl neznedtelné úsilí, ylo vzhledem k čsovým možnostem rozhodnuto, že poslední podporovná testovná verze ude Qt Při jkémkoli podezření n nekorektní chování Qt je výorným pomocníkem online dokumentce diskuzní forum [20], které se specilizuje n řešení prolémů s Qt. Většin otázek prolémů je tu zodpovězen nhlédnutí do diskuze může čsto ušetřit spoustu čsu s řešením něčeho, co je již dávno vyřešeno. Právě výorná dokumentce přehledné fórum, kde odpovídjí i přímo vývojáři Qt, dělá z knihovny Qt velmi doře sndno použitelný nástroj Prolém s nčítáním knihovny Jedním z nejnepříjemnějších nejhůře odhlitelných prolémů yl prolém nzývný DLL hell [13]. Tento prolém spočívá v tom, že progrm zkompilovný s jednou verzí dynmické knihovny je spuštěn s verzí jinou. Pokud linkovná verze exportuje stejné symoly (npř. názvy všech funkcí), linker nic nepozná progrm se ez prolémů spustí. Prolém je le v tom, že některé funkce mohly ěhem vývoje prodělt změny týkjící se počtu či typu prmetrů. V přípdě, že progrm je zkompilován s knihovnou, překládá volání funkcí podle jejich deklrcí v hlvičkových souorech. Při linkování už le hlvičkové souory k dispozici nejsou progrm zjišťuje dresy funkcí volných z dynmické knihovny podle exportovných symolů. Když je le nějká funkce změněn tk, že knihovn exportuje stejné symoly, dojde při jejím nekorektním volání k pádu progrmu. Konkrétní prolém nstl po instlci progrmu MinGW n Windows XP. Progrm si totiž do proměnné prostředí PATH přidl vlstní cestu. Nneštěstí ve svém uživtelském rozhrní používá tké knihovnu Qt y si zjistil její dostupnost, má ve svém dresáři vlstní kopii knihovny. Kvůli tomu, že knihovn má v názvu jen mjoritní část z čísl verze, čili 4, jmenuje se knihovn verze stejně jko knihovn verze Po přeinstlci Qt se nvíc cest ke knihovnám Qt dostl z cestu k progrmu MinGW, to způsoilo velké prolémy. Při spuštění z vývojového prostředí fungovl progrm korektně, neoť cesty ke správným knihovnám yly nstveny přímo vývojovým prostředím. Avšk při spuštění plikce smosttně se nhrál první knihovn Qt, která se nšl v cestách nstvených v proměnné prostředí PATH. A to yl právě knihovn v dresáři progrmu MinGW. Progrm zčl ýt nestilní z neznámých důvodů nečekně pdl. Řešení tohoto prolému zrlo poměrně dost čsu ukázlo se, že oznčení DLL hell je velmi příhodné. K odhlení prolému ylo nutné spustit progrm smosttně, poté se k němu připojit deuggerem

61 4.11. DALŠÍ DOKUMENTACE 49 podívt se, které moduly progrm používá. Bohužel, již jen dostt tento nápd vyžduje lespoň tušení o tom, že se podoné prolémy mohou vyskytnout. Ay se předešlo podoným prolémům, yl implementován kontrol verze používné knihovny. V Qt je možné získt verzi knihovny, se kterou se progrm kompiluje, pomocí mkr QT_VERSION_STR. Dále je pomocí funkce qversion() možné získt verzi ktuálně používné knihovny. Tyto dvě verze se porovnjí pokud nesouhlsí, vypíše progrm lespoň vrovnou hlášku o možném neezpeční neočekávného chování. Zároveň je podoným způsoem omezen minimální podporovná verze Qt n verzi Dlší dokumentce Jk již ylo zmíněno, v poslední části vývoje yl kód dokumentován pomocí speciálních komentářů odpovídjících poždvkům nástroje DoxyGen. Proto je nyní možné vygenerovt poměrně kvlitní dokumentci, která může ýt dále vyvíjen. Zároveň je sndné udržovt dokumentci komptiilní s kódem, neoť je dokumentce přímo jeho součástí ve formě komentářů. Dokumentci je možné jednoduše vygenerovt pomocí nástroje doxygen. V dresáři./doc je uložen konfigurční souor Doxyfile, který oshuje zákldní nstvení týkjící se vzhledu oshu výsledné dokumentce. Použitelná dokumentce se získá velmi jednoduše: cd doc doxygen Doxyfile V přípdě, že je vyždováno vlstní nstvení, je nejjednodušší použít progrm doxywizrd, který implementuje grfické rozhrní pro konfigurci generování dokumentce. V součsné doě je povoleno generování grfů pomocí progrmu dot, který je součástí GrphVizu. V přípdě, že není ninstlován, je nutné tuto volu vypnout. Jelikož je zpnuté generování všech grfů, které DoxyGen umožňuje, trvá generování poměrně dlouho výstup je kvůli orázkům mnohem větší. Vzhledem k nedosttečné dokumentci některých původních částí se všk grfy jeví jko výhodné pro pochopení neznámého kódu. Třídní digrmy jsou jistě dorým zákldem před prvním pohledem do rozsáhlého kódu. Velmi užitečné jsou tké cller grfy, které u metod zorzují, kdo odkud dnou metodu volá. Opkem jsou cll grfy zorzující, které funkce dná metod používá. Nejpoužitelnější je dokumentce ve formátu HTML, zejmén díky propojení jednotlivých částí pomocí hypertextových odkzů. Dokumentce zároveň oshuje i smotný zdrojový kód, který je tké propojen přímo s dokumentcí, to podle čísel řádků, tkže nhlédnutí do zdrojového kódu dokumentovné části je velmi jednoduché. Výsledná dokumentce je doře konfigurovtelná je možné ji do znčné míry přizpůsoit jk oshově, tk i vzhledově.

62 50 KAPITOLA 4. REALIZACE

63 Kpitol 5 Testování Vzhledem k tomu, že ylo nutné udržet progrm funkční n všech vývojových pltformách, ylo testování prováděno průěžně. Pro testování různé funkcionlity yl vytvořen řd testovcích souorů, které se ncházejí v dresáři./tests. Je nutné přiznt, že se mnuální testování ukázlo jko nedosttečné. Jelikož není možné vždy po kždé změně v kódu spustit mnuálně všechny testy, očs se stávlo, že se chy ojevil ž po delším čse, protože zásh do kódu týkjícího se jedné funkcionlity ovlivnil úplně jinou část progrmu. V prvních fázích vývoje se zdálo, že utomtické testování není nutné. Avšk s rostoucím počtem řádků kódu funkcí editoru rostl i složitost testování možnost, že mnuální testování nepokryje všechny důsledky některých změn. V závěru již neyl čs n implementci jednotkových testů, všk pro dlší vývoj se doporučuje nějkou formu utomtického testování přinejmenším zvážit. Již při vývoji této verze editoru to mohlo ušetřit spoustu čsu. Testy v této kpitole se snží pokrýt veškerou nově implementovnou funkcionlitu, jejíž korektnost yl kontrolován především vizuálně. 5.1 Test 1 Speciální symoly mkr Tento test se změřuje n zorzování speciálních symolů. Jedná se v podsttě o test spojení funkcí StringProcessoru sázení fontu pomocí Grphics View Frmeworku. Hlvním důvodem implementce podpory symolů yl sence písmen řecké ecedy. Porovnání zorzení písmen řecké ecedy editorem oproti výstupu po zprcování systémem L A TEX je n orázku 5.1. N orázku 5.2 je test použití mker pro modifikce písm. Modifikcí ylo implementováno jen několik, zejmén pro potřey syntxe zápisu symolů u přechodů konečných utomtů. Zdrojové kódy oou utomtů jsou v souorech testsymols01.tex testsymols02.tex. O testy prokzují, že věrohodnost vykreslení grfů konečných utomtů s podporou speciálních symolů či modifikátorů písm je velmi dorá. Jediný výrznější rozdíl je ve stylu písm. Systém L A TEX sází písmo v mtemtickém prostředí stylem podoným kurzívě. Avšk sklon písm se od kurzívy liší. Nepodřilo se njít vhodné nstvení pro font v Qt, y odpovídl přesně stylu, jkým se sází popisky systémem L A TEX. Tento neduh všk není nijk omezující je možné konsttovt, že písmen řecké ecedy modifikátory pro změnu velikosti písm zprcovává editor korektně. 51

64 52 KAPITOLA 5. TESTOVÁNÍ 7 6 s e 5 4 α ε β ϕ 1 c 2 γ Orázek 5.1: Zorzení speciálních symolů test 1 6 A A {α,β} 5 αβ ᾱ, β stteok 4 3 α, β α, β 2 stteerr 1 A Orázek 5.2: Použití modifikátorů písm test 1