Základní vstupní a výstupní moduly pro VoiceXML interpreter JVoiceXML

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Základní vstupní a výstupní moduly pro VoiceXML interpreter JVoiceXML BAKALÁŘSKÁ PRÁCE Matěj Klocek Brno 2009

2 Prohlášení Prohlašuji tímto, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Veškeré zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: Mgr. Luděk Bártek, Ph.D ii

3 Poděkování Děkuji vedoucímu práce Mgr. Luďkovi Bártkovi, Ph.D za vstřícnost a ochotu v průběhu zpracování Bakalářské práce. Dále také děkuji za podporu a trpělivost své rodině, která mi umožnila studovat. iii

4 Shrnutí Tato bakalářská práce se zabývá VoiceXML interpretem JVoiceXML. Představuje technologie použité JVoiceXML a jejich využití při návrhu a implementaci vstupních a výstupních modulů. Tématem práce je navržení a implementace modulů pro simulaci hlasového vstupu pomocí klávesnice a výstup na obrazovku včetně české dokumentace JVoiceXML API ve formátu JavaDoc. iv

5 Klíčová slova Dialogové systémy, VoiceXML, JVoiceXML, Goto, implementace, architektura v

6 Obsah ÚVOD... 1 DIALOGOVÉ SYSTÉMY HISTORIE ZPRACOVÁNÍ LIDSKÉ ŘEČI Rozpoznávání lidské řeči Skryté Markovovy modely Syntéza řeči KOMPONENTY SYSTÉMŮ Dialogový manažer Porozumění přirozeného jazyka Vstupní dekodér/rozpoznávač Výstupní generátor TYPY SYSTÉMŮ DIALOGOVÉ STRATEGIE ZPĚTNÁ VAZBA DIALOGOVÉ SYSTÉMY V PRAXI PŘÍKLADY IMPLEMENTACÍ... 8 VOICEXML HISTORIE CÍLE VOICEXML ARCHITEKTURA VOICEXML ARCHITEKTURA VOICEXML KONCEPTY UDÁLOSTI APLIKACE Aplikační struktura VoiceXML dokumentů Struktura jednotlivých VoiceXML dokumentů GRAMATIKY Hlasové gramatiky DALŠÍ TECHNOLOGIE POUŽÍVANÉ VOICEXML SISR PLS CCXML SCXML ECMAScript JVOICEXML CÍLE COPYRIGHT ARCHITEKTURA PBX JNDI Servlet kontejner Apache Tomcat Komponenta JVoiceXML POUŽITÉ TECHNOLOGIE Java Log4J ANT IMPLEMENTAČNÍ PLATFORMY vi

7 4.5.1 JSAPI JTAPI POROVNÁNÍ S KONKURENCÍ NÁVRH A IMPLEMENTACE TEXTOVÝCH MODULŮ NÁVRH TEXTOVÝCH MODULŮ SVN repository JVoiceXML Textová implementační platforma JVoiceXML IMPLEMENTACE TEXTOVÉHO MODULU SE STANDARDNÍM ROZHRANÍM Spuštění textového serveru a ustavení sezení Obsluha dialogové komunikace Spuštění standardního textového modulu Shrnutí IMPLEMENTACE MODULU S GRAFICKÝM UŽIVATELSKÝM ROZHRANÍM Dialogová komunikace uživatele se systémem Shrnutí KAPITOLA PŘEKLAD DOKUMENTACE JVOICEXML CORE API CLASS GOTO ZÁVĚR LITERATURA vii

8 Kapitola 1 Úvod Přirozeným způsobem lidské komunikace jsou dialogy vedené v jazyce participujících osob. V době moderních technologií je ovšem čím dál častěji upřednostňována komunikace pomocí posílání různých zpráv, ať už ve formě ů nebo ve formě SMS. Ve většině případů je tato komunikace dostačující a není potřeba jiných prostředků pro výměnu informací. Pokud je však potřeba vést dialog s dalšími osobami, existují technologie, které umožňují zajistit tuto komunikaci na vysoké úrovni, protože se jedná především o zaznamenání a přenesení těchto dat po síti a jejich následné přehrání. Nezřídka však potřebujeme komunikovat s automatizovanými systémy, jako je například bankovní nebo objednávkový systém. Interakce s uživatelem je prováděna nejčastěji formou grafického rozhraní, která není v mnoha případech dostatečně intuitivní a vyžaduje, aby bylo uživatelské rozhraní dobře navržené i pro nezkušené uživatele. Pro tyto uživatele je mimo jiné důležitá jednoduchost ovládání a dostupnost dané služby systému. Jelikož nejpřirozenější způsob komunikace je ten nejjednodušší, je použití dialogových systémů na místě [1]. Dialogové systémy jsou schopny převzít uživatelský vstup, zpracovat a podle vnitřního algoritmu vytvořit odpověď. Jako uživatelský vstup berou nejčastěji jeho samotný hlas a jako výstup k uživateli syntetizovanou řeč. Tyto systémy vedou dialog podle předem vytvořeného modelu nebo se mohou podle vedeného dialogu adaptovat na danou situaci. Vstupní modul dialogového systému může tím pádem být schopen rozpoznat hlasový vstup uživatele, především jeho syntaxi. Jeho výstupní modul může být schopen vytvořit z dat, poskytnutých tomuto modulu, syntetizovaný hlasový výstup. Existuje mnoho druhů dialogových systémů, například dialogové systémy o dopravních spojeních, dialogové systémy pro zdravotně postižené, navigační dialogové systémy. Jejich návrhy a implementace se mohou lišit především použitými technologiemi a cílovou uživatelskou skupinou. Jednou z technologií používanou dialogovými systémy je VoiceXML [2] [3]. VoiceXML je značkovací jazyk vyvinutý přispěním IBM, AT&T, Lucentu a Motoroly, kteří tvoří organizaci VoiceXML forum [4]. Byl vytvořen k převedení výhod zpřístupňování obsahu Internetu a informací pomocí hlasu a vytváření dialogových systémů. Naříkal OptimTalk je interpretem jazyka VoiceXML vyvinutý společností OptimSys [5]. Dalším a hlavním pojednávaným interpretem v této bakalářské práci je JVoiceXML [6]. JVoiceXML je interpretem jazyka VoiceXML, postaveným na platformě Java. Byl navržen jako interpret kombinující současné technologie v síťových a telefonních systémech a je vyvíjen jako open source software pod licencí GNU Literal General Public Licence. Projektovým manažerem JVoiceXML je Dirk Schnelle-Walka. Hlavním cílem této práce je představení architektury JVoiceXML API, jeho funkcí a vývoje, přeložená dokumentace základního API interpretu z balíčku org.jvoicexml, dále navržení a implementace textových vstupních a výstupních modulů JVoiceXML. Tyto moduly byly navrženy a implementovány dva, jeden slouží pouze pro komunikaci s interpretem pomocí systémového vstupu a výstupu, kdežto druhý zpracovává uživatelský vstup pomocí grafického uživatelského 1

9 1. ÚVOD rozhraní. Tyto moduly jsou navrženy především jako alternativní komunikace s dialogovým systémem jakým je JVoiceXML, interpret jazyka VoiceXML. Především bylo potřeba získat funkční verzi interpretu z projektového repository a nastavit překládací dokumenty ANT tak, aby správně nastavily interpret k použití textové implementační platformy, která vytváří síťové spojení s textovým modulem pro přenášení textových zpráv. 2

10 Kapitola 2 Dialogové systémy Dialogové systémy umožňují přirozenou komunikaci mezi uživatelem a automatizovaným počítačovým systémem. Poskytují textové, hlasové, grafické, hmatové, gestikulační a jiné moduly pro komunikaci s uživatelem. Jejich hlavní výhodou je samotný způsob komunikace, který je přirozený uživateli. Uživatel je dotazován nejrůznějšími otázkami a nápovědami, aby poskytl žádaný vstup. Komunikace uživatele se systémem je vedena volně se snadným ovládáním. Výhodou dialogových systému je to, že eliminují chyby, které vznikají v klasických modulech při porušení pravidel. 2.1 Historie První dialogové systémy poskytovaly pouze textový vstup a výstup. Jedním z prvních byla ELIZA, napsaná mezi lety 1964 a 1966 autorem J. Weizenbaumem. ELIZA byl program, který imitoval psychoterapeuta. Vedl dialog pomocí anglicky psaného textu s uživatelem. Jelikož nebylo v té době možné uchovávat velké množství slov a dat o skutečném světě, byl způsob, kterým odpovídal na otázky typu Jaký je váš oblíbený herec?, pro které by byla potřeba nutná velká databáze znalostí, odpovědí A jaký je váš oblíbený herec?. Program se tímto snažil obejít svá omezení a pokračovat v dialogu s uživatelem. ELIZA se stala jedním z milníků v komunikaci uživatele s počítačem. Stal se především inspirací pro počítačové hry založené na dialogu [7]. Dalším známým programem byl PARRY, který sloužil pro simulaci chování paranoidního schizofrenika. Program implementoval hrubý model paranoidního schizofrenika, založený na znalostech a předpokladech psychologů. Při provedení několika simulací nebyli psychologové v mnoha případech schopni rozpoznat výstup ze simulace s chováním skutečného pacienta. Na začátku sedmdesátých let dvacátého století nebyla takováto podobnost vůbec obvyklá a tím PARRY předvedl svůj pokročilý návrh. V následujících letech mnoho expertů a nadšenců propadlo výzkumu technologií, které umožňují komunikaci s počítači. Jejich počet narůstal spolu s rozšířením osobních počítačů. Jelikož se vývoj neustále zrychloval, přinesl mnoho úspěchů a nových poznatků v této oblasti, které umožnily pochopit jakým způsobem se formuje lidský hlas a jak se zpracovává a pochopit mnoho problémů souvisejících s komplexním procesem jako je lidská komunikace [8]. 2.2 Zpracování lidské řeči Rozpoznávání lidské řeči Rozpoznávání lidské řeči je komplexní záležitost, která vyžaduje použití sofistikovaných technologií. Hlavním cílem je vytvoření systému, který bude nejenom schopen převést lidskou řeč do textové podoby, ale bude také schopen porozumět převedenému textu. Vývoj počítačového sys- 3

11 2. DIALOGOVÉ SYSTÉMY tému schopného porozumět sémantice lidské řeči je veden už dlouhá desetiletí a čím dál je člověk ve vývoji, tím častěji se setkává s množstvím problémů a s omezeními dnešních programových a hardwarových komponent. Pro pochopení postupu rozpoznání souvislé řeči je především potřeba nastínit problémy, se kterými se musí takovýto systém vypořádat. První problém se vyskytuje při zaznamenávání hlasového vstupu, jelikož se také s hlasem zaznamenávají ruchy a šumy, které mohou vznikat i v nedokonalých zařízeních pro vstup. Po odfiltrování šumů se musí rozpoznat začátek a konec promluvy. Nalezení těchto bodů v čase se zprvu může zdát relativně jednoduché, ale rozhodnutí, co je relevantní vstup a co není, může být velmi obtížné. Například rozlišení mezi šumem pozadí a sykavkami. Pokud máme určeny základní časové body, můžeme tuto nahrávku rozdělit a poté analyzovat pomocí metod krátkodobé analýzy, rozdělené na analýzu v časové a frekvenční doméně. Jelikož je analyzován mikrosegment dané velikost, je předpokládáno, že je tento mikrosegment periodický. Obecně nahraný mikrosegment však periodický není a je proto potřeba použít váhové okénko, které definovaným způsobem změní hodnoty mikrosegmentu. Takovým okénkem může být Hammingovo okénko, které hodnoty z krajní části tohoto mikrosegmentu násobí číslem blížícím se nule a střední hodnoty násobí číslem blížícím se jedničce. Tím je dosažena přibližná periodicita signálu v mikrosegmentu. Krátkodobá analýza v časové doméně se zabývá pouze hodnotami vzorku. Používají se průměrové funkce, funkce rozhodující lokální maxima a minima a další operace nad hodnotami vzorku. Na rozdíl od toho analýza ve frekvenční doméně nejprve rozloží daný signál na základní komponenty. Nejpoužívanější funkcí rozkladu signálového spektra je furierova transformace. Pro použití v počítačových systémech se používá diskrétní furierova transformace, která rozkládá digitální signál na dílčí sinusoidy v reálné a imaginární doméně. Tyto složky jsou následně analyzovány a zapsány do akustického vektoru. Tento vektor je porovnán pro shodu s gramatickým předpisem. Detekovaná slova můžeme porovnávat pomocí metody Dynamic Time Warping (DTW), která bere posloupnosti akustických vektorů vzorku a předloh a porovnává jejich hodnoty Skryté Markovovy modely Hidden Markov Model (HMM) je statistický stavový automat používaný pro modelování sekvencí. Skryté Markovovy modely nalezly využití v mnoha oblastech zpracování signálu. Jelikož se hlasové ústrojí během časového intervalu nachází v určitém stavu, je možno tento model také použít pro rozpoznávání hlasového vstupu. Model je určen stavy s pravděpodobností výstupů a přechody mezi těmito stavy s pravděpodobností určenou číslem z intervalu od nuly do jedničky. Stavy nejsou viditelné vně systému, ale pouze výstup, který je závislý na těchto stavech. Protože se jedná o konečně stavový model, je potřeba dosáhnout konečnosti parametrů. Tohoto požadavku lze dosáhnout kvantizací akustických vektorů [9] [10]. Markovův proces je pětice G = (Q,V,N,M,π) Q je množina stavů. V je abeceda výstupních symbolů. N je matice určující přechody s jejich pravděpodobností. 4

12 2. DIALOGOVÉ SYSTÉMY M je matice určující pravděpodobnosti generování výstupního symbolu z množiny V ve stavech Q. π vektor určující pravděpodobnosti počátečního stavu. Musí platit: Součet pravděpodobností počátečního stavu musí být roven jedné: π = 1 Součet pravděpodobností vycházející z jednoho stavu musí být roven jedné: i, n i, j = 1 j Součet pravděpodobností generování výstupu jednoho stavu musí být roven jedné: i, q i ( k) = 1 k λ = (N, M, π) je soubor parametrů HMM, určující například model slova. Určení pravděpodobnosti promluvy je provedeno nalezením nejpravděpodobnější cesty modelem s generovaným výstupem. Tato cesta lze určit pomocí Viterbiova algoritmu. Pro detekci příkazů se používá skrytý Markovův model s jednotkami stavů. Parametry tohoto modelu jsou trénovány pro nalezení λ maximalizující pravděpodobnost promluvy P(O λ). Pro trénování parametrů je nejpoužívanější Baumův-Welchův algoritmus. Celý proces rozpoznání syntaxe a sémantiky souvislé řeči je velmi složitý, a proto je často rozpoznávaný uživatelský vstup omezen na délku krátké věty s omezenou velikostí abecedy nebo je omezen na seznam rozpoznávaných slov. i i Syntéza řeči Syntéza řeči se může zdát poměrně jednoduchá proti rozpoznávání řeči, jenomže opak je pravdou. U sofistikované syntézy řeči je potřeba nejenom stroze vyslovit daný text, ale také zahrnout personifikační vlastnosti řečníka. Z historického hlediska se lidé snažili napodobovat formování hlasu pomocí mechanických nástrojů, jako je například systém rezonátorů vytvořený ruským profesorem Christianem Kratzensteinem. Tyto rezonátory byly schopné modelovat pouze samohlásky, jelikož souhlásky jsou charakterizovány dynamickým procesem změny zvuku. Wolfgang von Kempelen rozvinul myšlenku mluvícího mechanického stroje, který by byl schopen nejenom vyslovovat samohlásky nebo souhlásky, ale také celé slova. Celý mechanismus byl velmi složitý k ovládání a to především při použití jazyka jiného než angličtiny. Sesbírané poznatky z minulých let byly použity při tvorbě prvních počítačových systémů ve dvacátém století. Dokonalou syntézu řečí, srovnatelnou s lidskou, bude možno vytvářet až při existenci umělé inteligence, jelikož se tak jako rozpoznání lidské řeči jedná o takzvaný problém AI complete. Podobně jako krátkodobá analýza signálu, je i syntéza řeči rozdělena na syntézu ve frekvenční a časové oblasti. Frekvenční syntéza používá způsob modelování lidského řečového ústrojí pomoci frekvenčních generátorů, filtrů a zesilovačů. Naopak časová syntéza vytváří slova, věty, větná spojení z dílčích částí. Nejjednodušším rozdělením je rozdělení na rámce a sloty, které se například používá pro hlášení příjezdů a odjezdů na vlakových nádražích. Syntéza pomocí rámců je 5

13 2. DIALOGOVÉ SYSTÉMY však použitelná pouze v některých aplikací, protože se především intonace může v jedné větě neustále měnit. Strukturu můžeme dělit také na alofóny, difóny a trifóny. Kde alofóny pouze definují pozici fonému, difóny jsou umístěny se středem mezi dvěma fonémy, které oba obsahují a trifóny, které obsahují tři sousední fonémy se středem v prostředním fonému. Před samotným spojením fonetických částí se provádí fonetická transkripce, která převádí výstupní text do fonetické abecedy pomocí fonologických pravidel. Celá syntéza závisí na prozodii, která ovlivňuje mnoho faktorů v globálním kontextu syntetizované řeči. 2.3 Komponenty systémů Jelikož existuje mnoho dialogových systémů s různou architekturou, nelze přesně určit komponenty, které každý z těchto systémů obsahuje. Dialogové systémy se totiž mohou řídit standardy jako je VoiceXml nebo vytvářet vlastní návrhy a implementace. Obecně nejdůležitějším pro dialogový systém je dialogový manažer, který spravuje stavy dialogu a jeho strategii Dialogový manažer Dialogový manažer je hlavní komponentou dialogového systému. Získává obsah uložený v souborech, databázích nebo dokumentových serverech, spravuje dialogovou strategii a historii dialogu a rozhoduje o odezvě na základě uživatelského vstupu a stavu, ve kterém se dialog nachází Porozumění přirozeného jazyka Proces porozumění vstupního jazyka je mnohem složitější než jenom pouhé přeložení syntaxe do textové podoby z důvodu neznámých rysů ve vstupu. Tato komponenta jako jeho hlavní náplní vytváří syntaktické a sémantické schéma. Obsahuje jmennou identifikaci, značkování slovních druhů a syntaktickou analýzu Vstupní dekodér/rozpoznávač Rozpoznává hlasový vstup pomocí technologií zpracování lidské řeči nebo detekuje gesta nebo rozpoznávat ručně psaný textu. Rozpoznávání gest nebo ručně psaného textu spadá do kategorie zpracování obrazu. Osobu komunikující s dialogovým systémem snímá obvykle kamera a obdržené snímky dále zpracovává vstupní dekodér. Například snímání pohybů uživatelových rtů, které může být použito pro detekci jeho emocí Výstupní generátor Výstup může být poskytnut jako čistý text nebo jako generovaný hlas pomocí TTS. Další možností výstupu může být robot, popřípadě vizuální projekce. 6

14 2. DIALOGOVÉ SYSTÉMY 2.4 Typy systémů Mohou být rozděleny podle více kritérií, nejčastějším je dělení podle typu vstupních a výstupních dat na: Textové systémy, které jako vstup a výstup používají textové řetězce. Mluvené dialogové systémy, které používají rozpoznávače hlasu na vstupu a syntézu řeči na svém výstupu. Grafická uživatelská rozhraní používající grafické zobrazení dat a kontrolních prvků na monitoru. Umožňuje ovládání myší nebo v případě dotykového displeje ovládání tužkou nebo konečky prstů. Systémy se mohou dále dělit podle typu používaného zařízení na telefonní, PDA, automobilová, robotická a zařízení s pracovní plochou. Existují ještě dělení podle stylu, iniciativy a aplikace systému. 2.5 Dialogové strategie Dialogová strategie určuje směr vedení dialogu. Dělí se na kooperativní a nekooperativní. Principy komunikace kooperativního dialogového systému jsou, na rozdíl od nekooperativního, aspekt informovanosti- být dostatečně informativní, aspekt přesvědčivosti- neuvádět nepravdivé informace nebo informace, které nelze dokázat, aspekt způsobu- vyhýbat se nejednoznačnostem a usilovat o stručnost. Dále aspekty zdvořilosti, empatie a etiky, aspekt asymetrie, znalostí a schopností uživatele, vyjasňování a odstraňování chyb. Dialogové strategie mají možnost přerušit systém, mohou spustit korekce při špatném rozpoznání uživatelova vstupu. Pokročilejší strategie mohou mít prostředky k detekci emocí uživatele a také jeho znalostí a dovedností. Tyto aspekty jsou důležité pro správnou a očekávanou funkčnost systému, aby nedocházelo k chybám a nedorozuměním při vedení dialogu. 2.6 Zpětná vazba Zpětná vazba v dialogových systémech určuje odpověď systému na uživatelský vstup, především jeho formu. Dělí se na: Sumarizující zpětnou vazbu, která souhrnně rekapituluje informace až v momentě kdy vytvářejí souhrnný celek. Zpětnou vazbu echo, která opakuje uživatelský vstup a až poté vlastní odpověď. Implicitní zpětnou vazbu, která neopakuje žádným způsobem poskytnutý vstup od uživatele, jenom poskytuje vlastní odpověď uživateli. Explicitní zpětnou vazbu, při které dialogový systém odpovídá uživatelským vstupem, ve formě oznamovací věty, následovaný kontrolou, zda uživatel souhlasí s rozpoznaným vstupem. 7

15 2. DIALOGOVÉ SYSTÉMY 2.7 Dialogové systémy v praxi Jednou z mnoha aplikací dialogových systémů jsou objednávkové systémy. Uživatel si prostřednictvím tohoto systému objednává služby, což je zajištěno pomocí hlasového dialogu. Může se například jednat o objednávku jídel nebo letenek. Uživatel zavolá na číslo objednávkového systému, který s ním naváže dialog. Pomocí dotazů a pomocných informací získá od uživatele potřebná data pro vytvoření objednávky. Data o objednávce pošle dál do systému, například do databázového systému, který data uloží do příslušné struktury. 2.8 Příklady implementací Olympus- open source systém. ATOM Spoken Dialogue SDK SALT- dialogový značkovací jazyk s více režimy vyvíjený společností Microsoft. VoiceXML- Voxeo Prophecy, Tellme Studio volné vývojové prostředí od společnosti Microsoft, Quack.com QXML vývojové prostředí od společnosti AOL, open source interpret JVoiceXML. 8

16 Kapitola 3 VoiceXML VoiceXML (Voice extensible Markup Language) je jazyk vyvinutý na bázi značkování XML, který v současné době vyvíjí konsorcium W3C jako součást projektu Voice Browser. VoiceXML je navrženo pro hlasové dialogy s rozpoznáváním vstupní uživatelovy promluvy a syntetizací výstupu, umožňuje také rozpoznávat DTMF vstup a vytvářet telefonní spojení. Hlavním cílem VoiceXML je přinesení výhody vývoje webových aplikací a zpřístupnění webového obsahu do dialogových systémů. Obsahuje také výstup zvukových souborů, které mohou nahradit syntetizovaný výstup, který je vytvořen pomocí text-to-speech [13]. 3.1 Historie Vývoj VoiceXML začal v roce 1995 jako XML jazyk, vytvořený pro zjednodušení vývoje aplikací rozpoznávající hlas v AT&T projektu PML. Společnosti IBM, Motorola, AT&T a Lucent dále vyvíjely své vlastní jazyky, založené na podobném základě. Tyto společnosti nakonec založily VoiceXML Forum pro spojení jejich úsilí a vybudování standardního dialogového jazyka, který budou vývojáři moci použít při tvorbě svých aplikací. První verze jazyka VoiceXML 0.9 byla vydaná 17. srpna 1999 pro testovací účely. Pro veřejnost byla vydána o rok později jako VoiceXML 1.0. Vývoj samozřejmě pokračoval dál a v roce 2004 VoiceXML dosáhl své druhé verze. JVoiceXML verze 0.6 používá VoiceXML verze 2.1 z roku 2005, která obsahuje pouze malé změny oproti předchozí verzi. VoiceXML se dále vyvíjí pod konsorciem W3C a má ambice se stát rozšířeným jazykem pro modelování dialogů. 3.2 Cíle VoiceXML Hlavním cílem je zjednodušit vývoj aplikací odstraněním nízko úrovňového programování a správy zdrojů. Dokumentový server bývá často externí vůči zbytku systému a přístup k jeho obsahu je řízen požadavky. Spravuje veškerou servisní logiku a podle uživatelského vstupu, který ovlivňuje interpretaci dialogu, získá požadavky na dokumenty VoiceXML. Jako dokumentový server lze použít HTTP server obsahující dokumenty aplikací. VoiceXML má za cíle: Odstínit vývojáře aplikací od nízko úrovňového programování a platformě specifických detailů. Oddělit servisní logiku od uživatelského kódu. Minimalizovat interakce mezi klientem a serverem. Podporovat přenosnost služeb mezi implementačními platformami. Být jednoduchý pro použití v základních interakcích, ale mít nástroje pro komplexní dialogy. 9

17 3. VOICEXML 3.3 Architektura VoiceXML Už z názvu vyplívá, že se jedná o značkovací jazyk založený na bázi XML. XML je metajazyk, vyvinutý konsorciem W3C, který je standardem jak vytvářet značkovací jazyky. Z důvodu existence mnoha různých počítačových systémů, aplikací a vyměňovaných dat byla potřeba vytvořit volně přístupný, jednoduchý a standardizovaný formát. Obsah všech XML dokumentů je proto textový, nezávislý na kódování, rozdělený značkami. Každý XML dokument obsahuje hlavičku a jeden kořenový element [12]. Prvky XML dokumentů se dělí na elementy, které jsou hlavní stavební konstrukcí, na atributy, které obsahují dodatečné informace elementů, dále na textové uzly, instrukce pro zpracování, notace a komentáře. Každý definovaný element musí být také ukončen: <person name= Jan > </person>. Jelikož je struktura dokumentů stromová a existují nástroje, které převádějí vstupní textové XML dokumenty do objektů se stromovou strukturou, je možné XML dokumenty jednoduše vytvářet a zpracovávat. 3.4 Architektura VoiceXML Architektura VoiceXML je rozdělena do komponent. První komponentou je dokumentový server, který spravuje VoiceXML dokumenty a poskytuje je VoiceXML Interpretu přes Kontext VoiceXML Interpretu. V některých případech může kontext zároveň s interpretem monitorovat uživatelský vstup a reagovat pouze na určitou podmnožinu tohoto vstupu. Kromě obsluhy vstupu ustanovuje kontext interpretu spojení s uživatelem a získává kořenový aplikační dokument od dokumentového serveru pro VoiceXML interpret, který dále řídí dialog. Poslední komponentou je implementační platforma, která má za úkol generovat události podle uživatelských nebo systémových akcí. Například implementační platforma implementující textové rozhraní může podle událostí, které přijímá, vytvářet textové odpovědi a posílat je uživateli nebo je zapisovat do logů. Obrázek 3.1: Základní komponenty VoiceXML 10

18 3. VOICEXML 3.5 Koncepty Vstupním bodem uživatele s VoiceXML interpretem je sezení. Sezení je ustavováno na začátku interakce uživatele s VoiceXML interpret kontextem, je udržováno po celou dobu načítání a zpracovávání dokumentů a je možné jej ukončit požadavkem od uživatele, dokumentu nebo kontextem interpretu. Jelikož je sezení hlavním spojením s uživatelem, identifikuje současnou komunikaci mezi ním a systémem. Vstup přijatý od uživatele může nabývat mnoha podob, je proto nutné odlišit nedůležitý uživatelský vstup od toho důležitého. Takovýmto nástrojem jsou gramatiky specifikující sadu promluv, které může uživatel vyslovit k provedení akce nebo k poskytnutí informací. Gramatiky jsou obsaženy v každém dialogu a jsou aktivní pouze v době kdy je uživatel uvnitř tohoto dialogu. Gramatiky mohou být aktivní i mimo rozsah dialogu pro potřeby aplikací, ve kterých se uživatel se systémem střídají v určování pokračování interpretace. Aktivitu gramatiky určuje spojení (link), které drží informace o rozsahu gramatiky a určuje cíl přechodu pomocí URI. 3.6 Události VoiceXML podporuje použití událostí pro řízení chodu aplikace. Události mohou být různého původu a účelu, například události generované v závislosti na uživatelský vstup, mezi které patří událost noinput, která je vygenerovaná pokud uživatel, ve specifikovaném čase, nepromluvil. Uživatel může vytvořit požadavek na nápovědu klíčovým slovem help, který vyvolá vygenerování události. Mezi události také patří vyhození chyb Interpretem při zjištění sémantických chyb v dokumentech. 3.7 Aplikace Aplikace je sada sdílející stejný aplikační kořenový dokument. Kdykoli uživatel pracuje s dokumentem v aplikaci, jeho aplikační kořenový dokument je také načten. Aplikační kořenový dokument zůstává načtený, zatímco uživatel přechází mezi jinými dokumenty ve stejné aplikaci, a je uvolněn z paměti, když uživatel přejde k dokumentu, který není v aplikaci. Zatímco je načten, proměnné dokumentu jsou k dispozici pro jiné dokumenty jako aplikační proměnné, a jeho gramatiky zůstanou aktivní po dobu chodu aplikace Aplikační struktura VoiceXML dokumentů Jak už bylo řečeno, VoiceXML dokumenty jedné aplikace sdílejí jeden a pouze jeden kořenový dokument aplikace. Pokud dialog v kořenovém dokumentu nespecifikuje následující dialog, je interpretace zastavena. V aplikacích s více dokumenty je nejdříve vybrán kořenový aplikační dokument a ostatní dokumenty jsou listové. Listové dokumenty mají ve svém <vxml> elementu vyjmenovaný sdílený kořenový dokument. Mohou nastat dva stavy během interpretace: Buď je načten kořenový dokument aplikace a není zde žádný listový dokument anebo je načten listový dokument zároveň s kořenovým, v tomto případě je interpretován listový dokument. 11

19 Výhody aplikací s více dokumenty: 3. VOICEXML Listové dokumenty mohou používat proměnné kořenového dokumentu pro sdílení a uchování informací. Catch elementy kořenového dokumentu určují standardní obsluhování událostí v listových dokumentech. Například pomocí elementu <catch event= nomatch count= 2 >, definovaném v kořenovém dokumentu, je v celé aplikaci zachycena událost nomatch, která se objevila podruhé v řadě za sebou. Gramatiky, které jsou platné v celém kořenovém dokumentu, jsou také platné v listových dokumentech pro umožnění interakce s hlavními formuláři a nabídkami aplikace. Například: <link next= stop.vxml > <grammar type= application/srgs+xml root= root version= 1.0 > <rule id= root scope= public >stop</rule> </grammar> </link> Definuje přechod, který je platný v celé aplikaci, a který spuštěn při vyslovení slova stop. Script elementy kořenového dokumentu definují ECMAScript kód, který lze použít v listových dokumentech. Property elementy v kořenovém dokumentu specifikují standardní hodnoty vlastností v listových dokumentech. Pokaždé když je uživatel v listovém dokumentu, interpret si drží načtený kořenový dokument. Ovšem ne vždy je načten listový dokument aplikace, například pokud aplikace obsahuje jediný dokument. Jméno současné aplikace je dané absolutním URI kořenového dokumentu. Pokud se jméno aplikace změní, interpret zinicializuje nový kořenový kontext. Inicializace kořenového kontextu je podmíněna typem přechodu mezi dokumenty, který je vyvolán jedním z následujících elementů: goto, link, choice, subdialog a submit. Pokud element specifikuje přechod na neexistující dokument, vyhodí se událost error.badfetch. Přechody se dělí na: Přechod z kořenového do listového dokumentu uvnitř aplikace- pokud je současný dokument kořenový a hodnota aplikačního atributu cílového dokumentu má stejné absolutní URI jako jméno současné aplikace. Je v tomto případě kořenový dokument a jeho kontext zachován. Přechod z listového do listového dokumentu uvnitř aplikace- pokud je současný dokument listový a hodnota aplikačního atributu cílového dokumentu má stejné absolutní URI jako jméno současné aplikace. Je v tomto případě kořenový dokument a jeho kontext také zachován. Přechod z listového do kořenového dokumentu uvnitř aplikace- pokud je současný dokument listový a absolutní URI cílového dokumentu je stejné jako jméno současné aplikace. Kořenový kontext je inicializován pokud přechod způsobil element submit. 12

20 3. VOICEXML Přechod z kořenového do kořenového dokumentu- v případě přechodu z kořenového do dokumentu, který například nemá atribut aplikace. Kontext je inicializován s kořenovým aplikačním dokumentem. Dialog uvnitř stávajícího dialogu- vytvoření nového dialogu je zapříčiněno elementem subdialog. Je vytvořen nový kontext a předchozí kontext je zachován pro použití při návratu nového dialogu. Přechody mezi aplikacemi- všechny zbývající přechody mezi aplikacemi zapříčiní vytvoření nového aplikačního kořenového kontextu. Obrázek 3.2: Přecházení mezi dokumenty v aplikaci Struktura jednotlivých VoiceXML dokumentů Jelikož se jedná o VoiceXML dokumenty, musí být validní vůči DTD VoiceXML. Každý dokument proto začíná značkou <vxml> a končí značkou </vxml>. Potomky vxml elementu jsou elementy nejvyšší úrovně- dialogy. Existují dva druhy dialogů: formuláře a nabídky. Formuláře jsou základním stavebním prvkem při vytváření dialogu s uživatelem a mohou obsahovat deklaraci proměnných, zpracování událostí a množinu prvků formuláře. Formulář dále deklaruje rozsah platnosti gramatik definovaných uvnitř formuláře pomocí atributu scope. Pokud je rozsah nastaven na dokument, jsou dvě možnosti rozsahu platnosti gramatik. Pokud se jedná o kořenový aplikační dokument, jsou gramatiky platné v celé aplikaci. V opačném případě je platnost gramatik omezena na listový dokument. Druhou možnou hodnotou atributu scope je dialog, který aktivuje gramatiky pouze uvnitř formuláře. Kromě elementů nejvyšší úrovně mohou dokumenty obsahovat také elementy var, script, property, catch, link, meta a metadata. Prvky formuláře jsou elementy, které mohou být navštíveny v hlavním cyklu formulářového interpretačního algoritmu (FIA). Dělí se podle funkce na kontrolní prvky a prvky pole. Prvky pole definují vstupní proměnnou, která ukládá vstup od uživatele. Vstup je uložen pokud odpovídá gramatikám definujícím povolený vstup. Prvky pole jsou: Field - hodnota tohoto elementu se získá pomocí ASR nebo DTMF gramatik. Record - hodnota tohoto elementu je zvuková nahrávka poskytnuta uživatelem. Transfer - přesměruje uživatele na jiné telefonní číslo a jeho hodnotu nastaví na výsledek přesměrování. Object - platformě specifický objekt, jehož výsledkem je ECMAScript objekt. 13

21 3. VOICEXML Subdialog - vyvolává spuštění jiného dialogu, tento dialog vrací ECMAScript objekt. Kontrolní prvky sloužící především k informování uživatele o požadovaném vstupu. Jsou dva typy kontrolních prvků: block a initial. Příklad VoiceXML dokumentu: <?xml version="1.0"?> <vxml version="2.0"> <form id="basic"> <field name="jidlo"> <grammar type="application/srgs+xml" src="jidla.grxml"/> <prompt> Ktere jidlo si prejete objednat? </prompt> <nomatch><prompt>mate na vyber polevku, smazeny syr nebo salat </prompt></nomatch> <noinput><prompt>vyberte si jidlo prosim.</prompt></noinput> <filled> <prompt>dekujeme za vyuziti nasich sluzeb.</prompt> </filled> </field> </form> </vxml> Tento dokument obsahuje jeden formulářový dialog, jedná se o jednoduchý objednávkový systém, který umožňuje objednat uživateli polévku, smažený sýr nebo salát. Jako první obdrží uživatel výzvu k výběru jídla- Které jidlo si prejete objednat?, následuje čekání systému na uživatelský vstup. Poté mohou nastat tři případy. V prvním případě není v časovém intervalu od uživatele obdržen žádný vstup. Následkem toho interpret vytvoří událost noinput a jako odezvu na tuto událost vytvoří výstup Vyberte si jidlo prosim.. Nebo systém obdrží od uživatele vstup, který neodpovídá srgs gramatice uložené v souboru jidla.grxml a jako následek vytvoří výzvu Mate na vyber polevku, smazeny syr nebo salat a pošle ji uživateli pomocí svého výstupu. V posledním případě uživatel vyslovil jedno z odpovídajících jídel, toto jídlo je uloženo do proměnné jidlo a interpret vytvoří výstup Dekujeme za vyuziti nasich sluzeb.. Tímto končí interpretace formuláře a také celé aplikace. Algoritmus interpretace formulářových položek dokumentů (FIA- Form Interpretation Algorithm) navštěvuje v cyklu postupně všechny formulářové položky. První navštívenou položkou je ta, jejíž strážní podmínka není uspokojená. Například strážní podmínka elementu field testuje, zda obsahuje jeho proměnná hodnotu. 3.8 Gramatiky Gramatiky popisují povolené vstupy od uživatele, získávané během interpretace VoiceXML dokumentů. Pro specifikaci gramatik ve VoiceXML je použit element grammar. Gramatiky mohou být popsány uvnitř VoiceXML dokumentu, potom jsou to takzvané inline gramatiky. Mohou být také externí, jejichž popis je ve vlastním souboru. Jelikož VoiceXML podporuje jak hlasový vstup, tak i DTMF vstup, používá dva druhy gramatik příslušné danému vstupu. Specifikaci módu 14

22 3. VOICEXML gramatiky vytváříme atributem mode elementu grammar, který určuje jestli má být použita hlasová nebo DTMF gramatika. DTMF gramatiky specifikují možné stisknutí telefonních kláves jako jejich seznam pomocí elementů item, které definují přípustné hodnoty pravidla. Pravidla v DTMF gramatikách se zapisují pomocí elementu rule, který nese identifikátor pravidla a jeho rozsah platnosti Hlasové gramatiky Každá z VoiceXML platforem musí podporovat alespoň jeden formát SRGS a může podporovat i formáty gramatik jiné než SRGS [14]. SRGS elementy jsou: Grammar- Kořenový element XML gramatiky. Meta- Deklarace HTTP meta obsahu. Metadata- Deklarace XML metadata obsahu. Lexicon- Deklarace slovníku výslovnosti. Rule- Deklarace pravidla gramatiky. Token- Definuje slovo nebo jiný vstupní objekt. Ruleref- Odkazuje na pravidlo definované lokálně nebo externě. Item- Definuje položky s atributy opakování a pravděpodobností. one-of- Definuje alternativy pravidla. example- Element obsahující příklad vstupu, který odpovídá pravidlu ve kterém je obsažen. tag- Definuje libovolný řetězec pro sémantickou interpretaci. Kořenový element XML gramatiky může obsahovat atribut weight specifikující váhu gramatiky. Váha je specifikovaná pozitivním číslem v plovoucí čárce. Hodnota 1.0 je rovna váze nulové. Hodnota větší než 1.0 pozitivně ovlivňuje vliv gramatiky a naopak hodnota menší než 1.0 ovlivňuje vliv gramatiky negativně. Příklad části externí XML SRGS gramatiky: <?xml version= 1.0 > <grammar xmlns=" xmlns:xsi=" xsi:schemalocation=" xml:lang="en-us" version="1.0"> <rule id= polevka > <one-of> <item>polevka</item> <item>soup</item> </one-of> </rule> 15

23 3. VOICEXML Tato gramatika povoluje pouze dvě vstupní slova a to polevka a soup, které patří pravidlu s identifikátorem polevka. Systémový TTS a zvukový souborový výstup je řízen elementem prompt, který vyvolá okamžité zařazení výstupu do fronty pro přehrání. Jakmile systém přehraje výstupy, čeká na vstup od uživatele a po obdržení pokračuje v interpretaci. Prompt element má tyto atributy: Bargein a bargeintype- pokud je tento atribut nastaven na true, má uživatel možnost přerušit přehrávání výstupu tím, že poskytne systému hlasový nebo DTMF vstup. Ovšem pokud je bargeintype atribut nastaven na hotword, je výstup zastaven pouze v případě, že vstup odpovídal jedné nebo více gramatikám. Pokud je potřeba přehrát všechny důležité výzvy, je doporučeno tento atribut nastavit na false. Cond- Přehrání výstupu definovaném elementem prompt můžeme podmínit výrazem, který je zapsán v cond atributu. Count- Nastavuje maximální počet opakování výzvy. VoiceXML tímto umožňuje vyvolávat různé výstupy pokud uživatel provádí něco opakovaně. Timeout- Definuje dobu čekání na uživatelský vstup. Hodnoty jsou v sekundách nebo milisekundách. Xml:lang- Identifikátor jazyka. Xml:base- Deklaruje základní URI ze kterého jsou odvozeny všechny relativní URI. Obsah prompt elementu určuje Speech Synthesis Markup Language (SSML), značkovací jazyk vyvinutý pro kontrolu syntetizačního procesu. Tento jazyk je také používán samostatně nebo v kombinaci s jinými systémy pro syntézu řeči a jeho interpretace není striktně daná. 3.9 Další technologie používané VoiceXML SISR SISR(Semantic Interpretation for Speech Recognition) definuje sémantický význam rozpoznaného vstupu. SRGS gramatiky se používají pro kontrolu syntaxe vstupu, který není někdy pro pochopení obsahu dostatečný. Sémantika je zapsána značkou <tag>, jehož obsah je řetězec nebo EC- MAScript kód [15] PLS PLS(Pronuncation Lexicon Specification) poskytuje prostředky k popisu výslovnosti v syntetizačním procesu. Vytváří spojení mezi zapsanými slovy a jeho výslovností použitím fonetické abecedy. Používá se v případech kdy výstupní text obsahuje znaky nebo slova, které standardně může TTS zařízení špatně syntetizovat nebo pokud se výslovnost slov liší podle jeho pozice ve větě. Jako většina značkovacích jazyků spojených s VoiceXML je PLS iniciativou konsorcia W3C [16]. 16

24 3. VOICEXML CCXML CCXML (Call Control XML) je W3C standardní značkovací jazyk používaný pro kontrolu telefonních hovorů. Umožňuje vytvářet konference s více účastníky a zpracovávat události. Byl navržen primárně pro použití s VoiceXML, který doplňuje o funkce kontroly hovorů. Ale používá se také v systémech interaktivní hlasové odezvy IVR (Interactive Voice Response) [17] SCXML SCXML (State Chart XML) je značkovací XML jazyk pro popis stavů systémů kombinující koncepty CCXML a Harelových automatů. Tento jazyk modeluje přechody mezi dokumenty a částmi aplikace [18] ECMAScript Skriptovací jazyk ECMAScript, neboli JavaScript, je dynamický, slabě typovaný jazyk používaný ve webových a jiných aplikacích. ECMAScript podporuje v nových verzích regulární výrazy, zachytávání výjimek. Pro zpracování s XML dokumenty se používá rozšíření ECMAScript E4X [19]. 17

25 Kapitola 4 JVoiceXML JVoiceXML je volná implementace interpretu jazyka VoiceXML, vyvíjeného na platformě Java. Hlavním projektovým manažerem je Dirk Schnelle-Walka a za projektem dále stojí hlavní vývojáři Renato Cassaca, David Rodrigues, Aurelian Maga a Hugo Monteiro. JVoiceXML umožňuje jednoduché vytvoření a zpracování VoiceXML dokumentů a jejich následnou Interpretaci. Jedná se o open source projekt, do kterého se může zapojit kdokoliv se znalostí jazyků Java a VoiceXML. Stačí navštívit stránky projektu na adrese a pomocí dokumentace JVoiceXML API a základních implementačních platforem, které jsou ve formátu javadoc, začít vytvářet IVR aplikace. Součástí této bakalářské práce je také překlad dokumentace JVoiceXML API a to balíčku org.jvoicexml, kterou mohou použít vývojáři méně zdatní v anglickém jazyce. JVoiceXML implementuje VoiceXML verze 2.1. V poslední vydané verzi interpretu (0.6) je plně podporovaná pouze část VoiceXML 2.1 značek. Informace ohledně této podpory lze nalézt na stránkách projektu. Jelikož je interpret naprogramován v jazyce Java, umožňuje spuštění pod jakýmkoliv systémem se spuštěnou Java virtuální mašinou. Soustředí se především na implementaci hlasového vstupu a výstupu pomocí standardních Java API, jako jsou JSAPI a JTAPI [21] [22] [23]. 4.1 Cíle Hlavním cílem JVoiceXML je vytvořit otevřený, volně přístupný interpret VoiceXML, který by používal moderní, levné technologie pro použití v IVR systémech. Jelikož se snaží být co nejvíce rozšířeným, není programován pro jednu platformu. Pro zajištění nezávislosti na operačním systému je použit programovací jazyk Java. Struktura interpretu musí být jednoduchá, dobře testovatelná a musí se jednoduše udržovat. Také, aby se stal úspěšným, musí plně podporovat standardy VoiceXML a dalších jazyků Voice Browser aktivity. 4.2 Copyright JVoiceXML je vydáván pod licencí GNU LGPL, což umožňuje použít zdrojové kódy interpretu i pro komerční využití. Každý zdrojový soubor obsahuje JavaDoc hlavičku, která obsahuje informace a upozornění pro použití zdrojových kódů aplikace. Je však doporučeno, aby se změny provedené v kódu interpretu určitým způsobem sdíleli v komunitě lidí zabývajících se JVoiceXML. Může se jednat o malé opravy chyb, vzniklých při programování nebo o doplnění nových funkcí nebo modulů. Projekt sídlí na stránkách SourceForge.net s vlastní úschovnou kódu, fórem a s dalšími užitečnými nástroji pro vývoj aplikací. 18

26 4. JVOICEXML 4.3 Architektura Jelikož se jedná o implementaci VoiceXML je základní struktura systému rozdělena do tří komponent PBX První komponentou je PBX. Většinou se jedná o naprogramovanou aplikaci, která zajišťují komunikaci s JVoiceXML Interpretem. Spojení aplikace s hlavní třídou JVoiceXML je navázáno pomocí JNDI JNDI Java Naming and Directory Interface je nástroj, který umožňuje přistupovat k Java objektům nebo adresářovým službám pomocí jejich jmen. Tyto jména Java objektů lze strukturovat do hierarchické podoby, která je vytvářena pomocí dělení tečkami. JVoiceXML poskytuje pomocí JNDI objekt implementující rozhraní org.jvoicexml.jvoicexml pod standardním názvem JVoiceXml a to přes RMI. RMI poskytuje své metody přes síťovou vrstvu, umožňuje tímto komunikovat mezi různými virtuálními mašinami obsahujícími RMI Server, který své metody objektů poskytuje a RMI Klient, který volá metody Serveru. Adresa Serveru je specifikována URL, které udává TCP/IP adresu, port a protokol komunikace, který je v tomto případě RMI. Výhodou tohoto způsobu komunikace je centralizovaný přístup k Interpretu JVoiceXml, který se může nacházet na jiné adrese v počítačové síti [24] [25] Servlet kontejner Druhou komponentou je servlet kontejner, který uchovává a poskytuje VoiceXML dokumenty interpretu pomocí protokolu HTTP. Tyto dokumenty jsou uloženy podle aplikace ve které působí. Pro každou z těchto aplikací musí existovat jeden aplikační kořenový dokument, který klient udává jako parametr při volání sezení. Servlet kontejnery podporují adresování a zpracování URL adres a překládají je na požadavky pro jednotlivé Servlety, které spravuje. Hlavním úkolem Java Servletů je tyto požadavky zpracovat a vytvořit na ně odpověď. Používají se především pro poskytování interaktivního webového obsahu a webových aplikací naprogramovaných v jazyce Java. Specifikace Java Servletů byla vytvořena společností Sun Microsystems v roce Volně dostupným Servlet kontejnerem použitelným v kombinaci s JVoiceXML je rozšířená implementace Java Servlet a JavaServer Pages, Apache Tomcat Apache Tomcat Servlet kontejner vyvinutý Apache Software Foundtaion je hojně využíván při vývoji aplikací v jazyce Java. Jeho záběr je široký s podporou vývoje webových aplikací. Jedná se o jednoduchý kontejner s jednoduchou konfigurací a správou. Pro testování aplikací s JVoiceXml je Tomcat dostačující. Implementací Java Servlet v Tomcatu se jmenuje Catalina, která běží standardně na 19

27 4. JVOICEXML portu Současná verze Tomcatu implementuje specifikaci Servlet 2.5 a JSP 2.1 [26] [27] Komponenta JVoiceXML Komponenta JVoiceXML je hlavní částí, která ustavuje spojení s uživatelem, spravuje sezení, které vytváří PBX pomocí volání metody JVoiceXml.createsession(client). Je možné ji dále rozdělit na další části. Hlavní komponentou jádra JVoiceXML je interpret VoiceXML, který implementuje funkci dialogového manažeru. Především řídí dialog s uživatelem se kterým komunikuje přes implementační platformu poskytující vstupní/výstupní spojení a přes Call Manager kontrolující hovor. 4.4 Použité technologie Java Objektově orientovaný programovací jazyk Java byl vyvinut společností Sun Microsystems. Jeho největší výhodou je přenositelnost mezi systémy, jelikož výstupem kompilace Java kódu je mezikód, který je předložen virtuální mašině implementované pro různé platformy. Oproti jiným programovacím jazykům, jako je například C nebo C++, je Java odstíněna od programování správy paměti a jiných nízko úrovňových prostředků [28]. Vlastnosti Javy: Robustnost: používá silnou typovou kontrolu, která zamezuje tvorbě některých nechtěných chyb. Programátor nemusí vytvářet kusy kódů pro správu paměti, ta je totiž zajištěna pomocí Garbage collectoru, který vyhledává objekty pro uvolnění z paměti. Z tohoto důvodu se v Javě nepoužívá destruktor jako v některých procedurálních jazycích. Podporuje více-vláknové aplikace: poskytuje prostředky pro tvorbu programů, které mohou mít více spuštěných vláken v jednom procesu. Jednoduchost: Jazyková syntaxe Javy je zjednodušena pro rychlejší pochopení principů jazyka. OOP: moderní procedurální programovací jazyky preferují objektový model vývoje aplikací. Byl vytvořen pro přiblížení návrhu aplikací skutečnosti, která obsahuje objekty, s jejich vlastnostmi a schopnostmi. Je distribuovaný: Platforma Java EE slouží pro tvorbu distribuovaných systémů. Je interpretovaný: Zkompilovaný mezikód je spouštěn ve virtuální mašině, která interpretuje tento mezikód. Je bezpečný: implementuje prostředky, které zabezpečují systém při komunikaci s počítačovou sítí. Podporuje standardy: Tento moderní jazyk se objevuje stále častěji v nových oblastech informačních technologií s implementací různých standardů. Dokumentace: Definuje přesný způsob dokumentování aplikací uvnitř zdrojových kódů aplikace, nazvaným javadoc. 20

28 4. JVOICEXML Je vyvíjený: V době psaní této práce byla vydána Java verze 6 update 13, kdy uplynulo už skoro čtrnáct let od vydání první verze Log4J Jelikož se při vývoji větších aplikací může objevit mnoho chyb, které se těžce hledají, je důležité tyto chyby umět nalézt a odstranit. Pro účely dohledání těchto chyb slouží logovací API. Je vhodné při návrhu zvolit některý z dostupných balíčků, aby se mohl programátor soustředit na důležité části vývoje a ne na vytváření infrastruktury pro zapisování událostí a chyb do souborů a pro jejich následné čtení. Na rozdíl od debuggerů, které kontrolují syntaxi kódu, logování umožňuje nacházet chyby v běhu programu pomocí zapisování zpráv, událostí, chyb a jiných relevantních informací. JVoiceXML používá ke kontrole běhu logovací API Log4J od společností Apache. Log4J se stal standardem v oblasti logování napříč různými programovacími jazyky. Jeho hlavní výhodou je rychlost i na pomalejším hardwaru a také jednoduchost instalace a použití uvnitř aplikací. K použití v aplikacích je potřeba soubor s příponou jar obsahující všechny třídy Log4J, například log4j jar obsahující třídy ve verzi Hlavními třídami Log4J jsou: Logger: je třída zařizující vytváření logovacích zpráv v určitém okamžiku definovaném vývojářem aplikace Appender: je třída určující úložiště logovacích zpráv, například HTML soubor, standardní výstup nebo databáze. Layout: tato třída definuje formát dat, kterým se mají zprávy ze třídy Logger do třídy Appender ukládat. Log4J rozděluje logovací zprávy do několika úrovní: DEBUG: Detailní informace o toku aplikace. Pouze zprávy nízké úrovně vypisované pouze v DEBUG módu. INFO: Informace o zajímavých běhových událostech. WARN: Používá se v případech, kdy ještě nenastala chyba, ale použití API nebo jiných prostředků není doporučeno nebo očekáváno. ERROR: Pro běhové chyby, které mají vliv na chod aplikace. FATAL: Nejvyšší úroveň, která se používá v případech kdy už není možno pokračovat ve zpracování aplikace. Například při porušení bezpečnosti nebo ztráty systémových zdrojů. Od verze existuje ještě jedna úroveň a to TRACE, která poskytuje detailnější informace o běhu aplikace a nikdy nebude zobrazena na konzoly. Tyto úrovně se filtrují podle nastaveného logování. Pokud je logování vypnuto, žádná ze zpráv ve všech úrovních nebude zapsána a naopak v plném režimu se zapíší všechny zprávy napříč úrovněmi. Pokud je nastaveno na jednu z úrovní vyjmenovaných výše, zapíší se zprávy z této a vyšší úrovně. 21

29 4. JVOICEXML Apache poskytuje také nástroj pro prohlížení těchto logů pod názvem Log4View. Obsahuje prostředky pro vyhledávání různých typů událostí v grafickém rozhraní, statistiky systému a další užitečné prostředky pro prohledávání dat vytvořených logováním Log4J ANT Pouhá kompilace kódu pomocí překladu v příkazovém řádku nebo utilitou make není dostatečná a je potřeba použít kompilační a distribuční nástroj, který všechny zdrojové kódy zkompiluje a vytvoří instalaci distribuce s zahrnutými jar soubory, javadoc dokumentací a spouštěcími soubory aplikace. Apache ANT tyto uvedené vlastnosti splňuje. Jelikož je naprogramován v jazyce Java, umožňuje tím pádem přenositelnost svých kompilačních a distribučních souborů mezi operačními systémy. Pro použití v systémech je proto potřeba mít nainstalovanou platformu Java. Soubory, které definují proces kompilace jsou ve formátu XML, na rozdíl od utility make, která používá svůj vlastní Makefile formát. Standardním názvem použitým pro hlavní ANT soubor je build.xml. Kořenovým elementem ANT souborů je <project>, který musí být tím pádem pouze jeden v celém dokumentu. Obsahuje jméno projektu, které není příliš důležité, ale především atributy default určující cíl, který ANT provádí a atribut basedir, který je zápisem základní složky v adresářové struktuře. Element target logicky odděluje sestavování projektu. Obsahuje elementy spouštějící překlad zdrojových souborů v jazyce Java. Například <javac srcdir= src destdir= bin />, který zapříčiní přeložení souborů z adresáře src do adresáře bin. Tyto cíle dále definují mezi sebou závislosti, podle kterých určují posloupnost, kterou ANT vytváří kompilaci a následnou distribuci. Například následující dokument: <project name= Priklad default= distribute > <target name= init /> <target name= javadocinit /> <target name= compile depends= init /> <target name= javadoc depends= init, javadocinit /> <target name= distribute depends= compile, javadoc /> </project> Při spuštění tohoto projektu se nejdřív provede inicializace pro kompilaci kódu, následně samotná kompilace. Poté se pro vytvoření javadoc dokumentace znovu provede inicializace s následným generováním HTML dokumentů. Jako poslední se provedou akce definované v těle cíle distribute. ANT umožňuje dále: Používat vlastnosti (proměnné) pomocí značky <property> s atributy name definující jméno vlastnosti a value definující hodnotu této vlastnosti. Importování jiných dokumentů ANTu pomocí značky <import>. Tento dokumentový soubor je okamžitě proveden s použitím definovaných proměnných dokumentu, který obsahuje definici tohoto importu. Vyhodnocovat podmínky elementem condition, v jehož těle se přiřazují hodnoty proměnným v závislosti na vyhodnocení definované podmínky. 22

30 4. JVOICEXML Provádět operace souborového systému, jako je například kopírování souborů, vytváření adresářů a jejich mazání. Generování javadoc dokumentace. JVoiceXML používá kromě základních prostředků ANT ještě jeho rozšíření pro tvorbu instalačního balíčku pomocí JSmooth. Celý proces kompilace může být strukturovaný do mnoha dílčích částí s vlastní logickou strukturou. Umožňuje tímto jednoduchou správu kompilačního procesu. 4.5 Implementační platformy Implementační platforma se v JVoiceXml stará o zpracování hlasového vstupu, syntetizovaného výstupu a o kontrolu telefonie. Pokud chce klientský program použít některou z ne standardně používaných platforem, musí tuto implementační platformu specifikovat při vytváření sezení s interpretem. Každá platforma musí implementovat vzdálený klient popsaný rozhraním org.jvoicexml.remoteclient. Tento klient obsahuje všechny potřebné informace pro zajištění systémových zdrojů používaných konkrétní platformou. Zdroje jsou identifikovány textovými řetězci. Například identifikátor pro použití zdrojů textové implementační platformy obsahuje řetězec text. Kromě rozhraní RemoteClient je potřeba naimplementovat vlastní zdroje: SpokenInput, SynthetizedOutput a Telephony JSAPI Java Speech API rozhraní pro rozpoznávání a syntézu řeči. Syntéza řeči v JSAPI je vytvářena v několika fázích: Vstupní text je analyzován pro zjištění jeho formátování, především začátku a konce větných spojení. V další fázi je text prohledáván pro zjištění různých forem speciálních entit, například zkratek, čísel a je převeden do vyslovitelného textu. Provedení této fáze se liší mezi použitými jazyky ve kterých je text napsán. Text je převeden do fonetické abecedy pro upřesnění výslovnosti. Poslední úpravou před samotnou produkcí výstupu je zavedení prosodických vlastností zlepšujících přirozenost výslovnosti. Z informací získaných v předchozích krocích je vytvořen digitální signál. Implementací, kterou používá JVoiceXml je volně přístupný FreeTTS JTAPI Java Telephony API (JTAPI) je objektově orientované programové rozhraní pro obsluhu příchozích a ochozích hovorů. Slouží jako rozhraní mezi Java aplikací a telefonním systémem. Kontrolu aplikace nad telefonií určuje pozice rozhraní v systému. V případě JVoiceXml je rozhraní umístěno uvnitř telefonního systému, což umožňuje lepší kontrolu aplikace nad telefonní komunikací. 23

31 4. JVOICEXML JTAPI dále podporuje vytváření několika současných hovorů na stejném terminálu nebo vytvářet a spravovat konferenční hovory. Oproti TAPI a TSAPI není JTAPI závislé na platformě díky jeho implementaci v programovacím jazyce Java. 4.6 Porovnání s konkurencí Výhodou oproti jiným implementacím VoiceXml, JVoiceXML plně využívá pouze volně dostupné technologie bez nutnosti platit za interpret ať už pro osobní nebo komerční použití. Také jeho nezávislost na platformě ho staví před konkurenci. Největší nevýhodou JVoiceXML tkví v jeho nedokončeném vývoji. Obsluha vstupu a výstupu je pouze částečně implementovaná, se standardní podporou především JSAPI. Částečná je také podpora VoiceXML 2.1 oproti Voxeo Prophecy, který plně podporuje VoiceXML 2.0. Až dosáhne vývoj fáze, kdy bude interpret podporovat valnou většinu specifikace VoiceXML, bude možné jeho nasazení ve větších projektech. Do té doby je pro uživatele zatím zajímavý pouze jako testovací aplikace. 24

32 Kapitola 5 Návrh a implementace textových modulů 5.1 Návrh textových modulů JVoiceXml ve verzi 0.6 obsahuje prostředky pro získání systémových zdrojů hlasové komunikace s uživatelem. Ve standardním modelu tyto zdroje deklaruje PBX, které obsluhuje telefonní hovor s uživatelem. Tento model není dostačující v případech, kdy je komunikace mezi uživatelem a interpretem jiná než hlasová. Pokud má celý systém podporovat dialogy vedené textovou formou, musí být navrhnut a naimplementován modul, který bude umístěn mezi uživatelem a zbytkem systému. Tento modul lze nazvat textovým uživatelským rozhraním systému. Pro uživatele s malou zkušeností se systémy primárně ovládanými pomocí příkazového řádku, je také vhodné implementovat uživatelsky přívětivé rozhraní. Grafické uživatelské rozhraní je v moderních aplikacích standardem obsahujícím ovládací prvky jako jsou například tlačítka, formuláře nebo různé nabídky. Stanovené cíle textových modulů: Vytvořit prostředky zajišťující komunikaci uživatele s interpretem pomocí vstupu z klávesnice a výstupu na monitor. Schopnost modulu připojit se k interpretu spuštěném v jiné Java virtuální mašině nebo lokálně interpret spouštět v odděleném vlákně, pokud se jedná o grafickou implementaci. Při spuštěném interpretu v jiné virtuální mašině, musí umět modul navázat spojení přes vzdálené volání metod RMI. Schopnost modulu spouštět dialogy s kořenovým aplikačním dokumentem specifikovaným URI. Kontrolovat vstupní dokumenty, jestli jsou validní a obsahují pouze podporované VoiceXML značky definované v externím souboru. Přijímat zprávy od textové implementační platformy a poskytovat relevantní zprávy uživateli. Přijímat vstup z klávesnice a posílat ho přes implementační platformu interpretu. Pro dosažení stanovených cílu bylo nejdříve potřeba získat funkční a nakonfigurovanou verzi interpretu JVoiceXML: Existují dvě možnosti jak získat JVoiceXml. Tou první je stažení zkompilované nebo binární verze přímo ze stránek projektu. Ke stažení jsou verze od po 0.6, která je současně poslední vydanou verzí interpretu. Verze stažitelná ze stránek projektu obsahuje instalační balíček vytvořený utilitou JSmooth. Je možné nainstalovat interpret kdekoliv do adresářové struktury s povoleným přístupem. Druhou možností získání zdrojových kódů interpretu je připojení k subversion projektu a stažení nejnovější revize. Výhodou tohoto přístupu je to, že v úschovně se nachází vždy poslední 25

33 5. NÁVRH A IPMLEMENTACE TEXTOVÝCH MODULŮ verze interpretu. Může se ovšem stát, že revize obsahuje chyby v aplikačním kódu, nebo také v dokumentech řídících kompilaci. Pro řešení práce byly použity kódy interpretu uložené v subversion repository projektu JVoiceXML SVN repository JVoiceXML Už podle názvu je subversion (SVN) systém pro správu verzí aplikace. Jedná se o rozšířený open source systém a lze ho provozovat na různých platformách. Jako repository podporuje FSFS(Fast Secure File System), používající souborový systém pro ukládání dat [29]. Struktura SVN repository JVoiceXml se občas mění, ale její základní rozdělení zůstává stejné. Je rozděleno na adresářovou strukturu s obsahem: org.jvoicexml: balíček obsahující hlavní část interpretu, který je vždy potřeba pro spuštění celého systému. org.jvoicexml.implementation.jsapi10: balíček obsahující implementaci JSAPI1.0. Součástí repository je také demo implementace JSAPI2.0. org.jvoicexml.implementation.jtapi: JTAPI je standardní používanou Java implementací kontroly hovorů. org.jvoicexml.implementation.text: Textová implementační platforma pro textovou komunikaci s uživatelem. V práci navrhované textové moduly používají balíčky org.jvoicexml a org.jvoicexml.implementation.text. Pomocí nástrojů subversion zakomponovaných do vývojových IDE, jako je NetBeans, lze kontrolovat změny provedené lokálně proti změnám v repository. Ukládá historii zapsaných změn podle času ve kterém byly provedeny a umožňuje se k těmto změnám vrátit. Adresa kořenového adresáře SVN repository JVoiceXml je Pro připojení není potřeba zadat uživatelské jméno ani heslo, ale přístup k souborům bude omezen pouze na operace čtení. Před spuštěním kompilace pomocí ANTu bylo potřeba jeho konfigurační a kompilační XML dokumenty upravit především pro nastavení seznamu podporovaných implementačních platforem. Adresář org.jvoicexml obsahuje následující ANT dokumenty: 3rdparty-libs.xml: Obsahuje definici proměnných, jejichž hodnoty odkazují na adresáře s použitými knihovnami volně dostupných Java aplikací třetích stran. Build.xml: Hlavní kompilační dokument. Configuration.xml: Dokument používaný pro vytvoření vlastní konfigurace. Distributation.xml: Dokument, pomocí kterého se vytváří distribuce interpretu jako instalační balíček. Run.xml: Umožňuje spuštění Interpretu s nastavením nutných knihoven. Test.xml: Pro spuštění testů jednotek. 26

34 5. NÁVRH A IPMLEMENTACE TEXTOVÝCH MODULŮ Soubor ant.properties v adresáři config-props obsahuje možnost vlastního nastavení generování konfiguračních souborů ANT, dokumentem configuration.xml. Pro navrhované textové moduly byla zvolena textová implementační platforma, která umožňuje textovou komunikaci modulu s interpretem. Bylo proto potřeba nastavit použití této platformy uvnitř souboru ant.properties změnou asociace jvxml.text = false na jvxml.text = true. Po instalaci nebo vytvoření aplikace přes SVN repository je možno provést pár úprav interpretu, především použití portů pro JNDI. Standardním portem používaným JVoiceXml pro JNDI je Pokud je z nějakého důvodu port 1099 blokováno nebo je číslo portu už obsazeno, je potřeba tento port změnit. Základní úpravy konfigurace interpretu lze provést modifikací souboru jvoicexml.xml v adresáři config. Tento adresář také obsahuje konfigurační soubory potřebné pro použití aplikací třetích stran. Revize stažená ze subversion obsahovala staré konfigurační soubory, které popisovaly jiné verze knihoven. Z tohoto důvodu byly změněny pro podporu nových verzí aplikací třetích stran Textová implementační platforma JVoiceXML Jelikož jsou v JVoiceXml implementační platformy zodpovědné především za systémové zdroje, obsahuje textová platforma prostředky pro textovou komunikaci s uživatelskými aplikacemi. Tato platforma ve verzi 0.6 obsahuje pouze základní prostředky pro textovou komunikaci s klientem. Byla proto použita novější verze, která je dostupná z projektového SVN repository. Obsahuje větší množství zpráv, které posílá textový server naslouchači (ontex.text.textlistener). Nejdůležitější třídy a rozhraní platformy pro implementaci textových modulů: Rozhraní Textlistener: Objekty třídy implementující toto rozhraní mohou přijímat zprávy od třídy TextServer. Obecně se jedná o moduly, které na jedné straně přijímají od uživatele vstup a posílají ho textovému serveru. Na druhé straně přijímají od textového serveru zprávy o stavu a výstupu ve formě SSML dokumentu nebo textového řetězce, který dále poskytují uživateli. Třída TextServer: Hlavní prostředek poskytující textový vstup a výstup od interpretu. Třída TextRemoteClient: Implementace RemoteClient rozhraní pro TCP/IP komunikaci mezi VoiceXML interpretem a klientem. Obsahuje také identifikátor textové implementační platformy, která bude použita při komunikaci s daným klientem. Třída TextMessage: Jedná se o kontejner zprávy, která je posílána po síti a musí tím pádem implementovat rozhraní Serializable. Zprávy posílané objekty třídy TextServer Textlisteneru started Oznámení o spuštění vlákna TextServeru connected Oznámení o připojení TextServeru, součástí oznámení je také TCP/IP adresa outputtext Obsahem této zprávy je textový řetězec obdržený od VoiceXML interpretu outputssml Obsahem této zprávy je Ssml dokument obdržený od interpretu disconnected Oznámení o odpojení TextServeru (Například při ukončení interpretace dialogu aplikace) 27

35 5. NÁVRH A IPMLEMENTACE TEXTOVÝCH MODULŮ Posílání textového vstupu TextServeru se provádí voláním metody TextServer.sendinput, což je jediný způsob vstupní komunikace s textovou implementační platformou. Samotný textový server je spouštěn klientskou částí a to v novém vlákně. Každý textový server může obsahovat více textových naslouchačů, kterým posílá všechny zprávy. 5.2 Implementace textového modulu se standardním rozhraním Jedná se o Implementace komunikující s uživatelem pomocí standardního vstupu a výstupu. Tento modul obsahuje dvě třídy, VxmlChecker.java a StdTextClient.java. VxmlChecker slouží pro kontrolu vstupních VoiceXML dokumentů jestli obsahují pouze podporované značky. Obsahuje metodu init(), která získá soubor obsahující informace o úrovni implementace VoiceXML značek ze systémového zdroje pod jménem support.xml a tento soubor syntakticky zanalyzuje a vytvoří jeho DOM reprezentaci. Dokument obsahuje deklaraci tří úrovní podpory VoiceXML značek interpretem. Od úplné podpory přes částečnou až po žádnou. Struktura support.xml je následující: Kořenovým elementem dokumentu je jvoicexmlimpl, může obsahovat tři typy elementůfullsupport, started a noimpl. Fullsupport může obsahovat pouze elementy fs, started pouze st a noimpl pouze ni elementy. Fs element obsahuje atribut id se jménem VoiceXML značky, která je plně podporována JvoiceXml interpretem. St- tento element obsahuje id se jménem VoiceXML značky, jehož podpora je částečná. Ni element jehož atribut id obsahuje jméno VoiceXML značky, která není podporovaná současnou verzí interpretu. Metoda check s parametrem URI zkontroluje značky použité v dokumentu odkazovaném pomocí daného URI a vrátí číselnou hodnotu udávající úroveň podporovaných značek. Pokud dokument obsahuje elementy, které jsou definované v souboru support.xml pod značkou <ni>, je vrácena hodnota -1 znamenající nemožnost zpracování dokumentu interpretem JVoiceXML. Celočíselná hodnota 1 nebo 2 je vrácena, pokud dokument neobsahuje žádnou z nepodporovaných značek. V tomto případě je možné pokračovat v běhu aplikace. Třída StdTextClient je implementací rozhraní TextListener a je exekutivní částí textového modulu. Třída ustavuje spojení s VoiceXML interpretem pomocí vzdáleného volání metod. Jako první získá objekt JvoiceXml, který je hlavním vstupním bodem s interpretem. Tento objekt je prezentován v prostředí JNDI pomocí řetězce JvoiceXml. K umožnění použití JNDI je potřeba nastavit soubor jndi.properties, který musí být obsažen v CLASSPATH. Pro zajištění správné funkčnosti musí tento soubor obsahovat minimálně následující řádky: java.naming.factory.initial=com.sun.jndi.rmi.registry.registrycontextfactory pro definici jmenné továrny. V případě JvoiceXml se jedná o továrnu z RMI. 28

36 5. NÁVRH A IPMLEMENTACE TEXTOVÝCH MODULŮ java.naming.provider.url=rmi://localhost:1099 pro definici URL použitého protokolu a umístění poskytovatele jmen. Localhost je synonymum pro IP adresu lokálního počítače JNDI implementace JVoiceXML je založena na RMI a implementace pro použité rozhraní jsou získávány dynamickým stahováním kódu. Je proto potřeba především poskytnout soubor bezpečnostní politiky a knihovny obsahující implementace. Jvoicexml.policy soubor uložen v konfiguračním adresáři distribuce obsahuje definici povolení všem objektům volat metody JvoiceXml. Je vytvořeno řádkem grant permission java.security.allpermission;, který povoluje všechny operace vzdáleného volání metod. Tento soubor je poskytován Java virtuální mašině nastavením vlastnosti prostředí Djava.security.policy. Při správně nastaveném JNDI a RMI získá modul JvoiceXml objekt vytvořením kontextu javax.naming.context a zavoláním metody noctext.lookup( JvoiceXml ). Obrázek 5.1: UML diagram textového modulu se standardním rozhraním Spuštění textového serveru a ustavení sezení Po získání odkazu na JVoiceXml, spouští modul textový server se specifikovaným portem (standardně 4242), jako nové vlákno aplikace. Třída StdTextClient je poté přidána mezi naslouchače textového serveru pro zajištění příjmu výstupu a kontrolních událostí. Textový server při svém spuštění vytvoří TCP/IP spojení na lokální adrese s definovaným portem a čeká na spojení 29

37 5. NÁVRH A IPMLEMENTACE TEXTOVÝCH MODULŮ s interpretem. Tento server také poskytuje metodu getremoteclient(), která vrací textového vzdáleného klienta pro spojení modulu s interpretem. Port vráceného klienta je stejný jako port spojení textového serveru s interpretem. To znamená, že se textový server naváže mezi ustanovené spojení a pomocí metody readoutput() čte výstup od VoiceXML interpretu. Pokud je textový serveru úspěšně spuštěn a modul obsahuje odkaz na vzdáleného klienta, je možné vytvořit sezení s JVoiceXml zavoláním metody createsession(client), která vrací objekt třídy Session. Tímto je inicializace hotova a sezení je zavoláno na získaném objektu metodou call(uri document) s parametrem URI odkazujícím na první dokument aplikace. Úspěšné spuštění a spojení textového serveru je oznámeno všem naslouchačům definovaných v kolekci pomocí metod firestarted() a fireconnected() Obsluha dialogové komunikace Při použití standardních hlasových rozhraní pro komunikaci uživatele s VoiceXML interpretem není možné po zavolání sezení obsluhovat dialog klientskou částí systému, jelikož veškerou komunikaci s VoiceXML interpretem řídí implementační platforma pomocí získaných systémových zdrojů. Standardní hlasový klient, během vedení dialogu, čeká na ukončení sezení metodou waitsessionend(). V případě vedení textové komunikace s interpretem by tento přístup zapříčinil nemožnost příjmu výstupu od interpretu a posílání vstupu od uživatele. Modul proto nečeká na ukončení dialogu a přechází do stavu, ve kterém obsluhuje vstup a výstup. V tomto stavu má modul spuštěné dvě vlákna běžící souběžně vedle sebe. Hlavní vlákno obsluhuje textový uživatelský vstup, kdežto vlákno, ve kterém běží textový server obsluhuje výstup na obrazovku. Textový server je v hlavním cyklu uvnitř metody readoutput(), ve kterém přijímá objekty zpráv třídy Text- Message. Přijímané objekty od implementační platformy obsahují dva druhy zpráv, kterými jsou: Zpráva s kódovým označením DATA, která obsahuje buď textový řetězec poslaný implementační platformou anebo SsmlDokument taktéž poslaný platformou. Zpráva BYE je poslána textovou platformou při ukončení dialogu s uživatelem. Dialog může být ukončen uživatelem, VoiceXML interpretem nebo při zachycení závažné chyby. Textový server posílá dva druhy zpráv: Zprávy s kódovým označením ACK jsou posílány implementační platformě poté, co textový server obdržel datovou zprávu. Jedná se o pozitivní potvrzování příjmu zpráv v síťovém prostředí. Pro identifikaci jednotlivých objektů je použito sekvenční číslo, které musí obsahovat každý objekt implementující rozhraní Serializable. Zprávy USER posílané metodou sendinput(final String input) slouží jako vstup pro interpret VoiceXML. Tato metoda je deklarovaná ve třídě TextServer, ale je volána hlavním vláknem modulu. Textový řetězec výstupu obsažený ve zprávách DATA je vytažen z tohoto objektu a je poslán všem naslouchačům metodou outputtext(string text). Tento text je podle definice v třídě StdTextClient prezentován na standardním výstupu. Textový server může být zastaven dvěma způsoby. Obdržením zprávy BYE nebo zavoláním jeho metody stopserver(). V obou případech je zastaveno síťové spojení s interpretem, ukončen vzdálený textový klient a poté zrušeno celé vlákno metodou interrupt(). Pokud byl textový server 30

38 5. NÁVRH A IPMLEMENTACE TEXTOVÝCH MODULŮ zastaven obdržením zprávy BYE, je posláno oznámení o odpojení textového serveru všem definovaným naslouchačům v kolekci se jménem listener. Hlavní vlákno je uvnitř cyklu v metodě sendinput() třídy StdTextClient. V každé iteraci cyklu je sesbírán uživatelský vstup ve formě řetězce s obsahem jednoho řádku. Cyklus je opuštěn při odpojení textového serveru, který znamená konec dialogu. V tento okamžik je ukončena celá aplikace Spuštění standardního textového modulu Textový modul se spouští pomocí příkazového řádku s jedním argumentem, který obsahuje URI dokumentu použité při volání sezení. Například příkaz StdClient /home/hello.vxml, který spustí textový klient s dokumentem URI prvního dokumentu /home/hello.vxml. Pokud je z nějakého důvodu volán klient špatným způsobem, například pokud příkaz obsahuje jiný počet argumentů než který je povolen, je aplikace přerušena s vypsáním nápovědy na standardní výstup. Další krokem před spuštěním inicializační fáze je kontrola dokumentu pomocí třídy VxmlChecker. Pokud třída vrátí celočíselnou hodnotu -1 je aplikace ukončena s vypsáním informace ohledně nepodporovaných značek. Pokud vrátí hodnotu 2, vypíše na standardní výstup informaci ohledně obsahu částečně podporovaných značek. V tomto případě není aplikace přerušena a je spuštěna inicializační fáze Shrnutí Naimplementovaný textový modul se standardním rozhraním splňuje všechny stanovené cíle. Vytváří prostředky zajišťující komunikaci uživatele s interpretem pomocí vstupu z klávesnice. Jako zdroj vstupu slouží standardní systémový vstup. Jako výstup na obrazovku používá tato implementace standardní systémový výstup. Obsahuje implementaci prostředků pro komunikaci s VoiceXML interpretem pomocí vzdáleného volání metod. Pomocí třídy VxmlChecker kontroluje dokumenty, zda obsahují pouze podporované značky VoiceXML. S předloženými dokumenty vytváří interpretem sezení a obsluhuje vstupní a výstupní komunikaci uživatele se systémem. Modul používá především prostředky textové implementační platformy a základních tříd JVoiceXml. Následující seznam shrnuje použité třídy a rozhraní z JVoiceXml: rozhraní JVoiceXml- objekt třídy implementující toto rozhraní je použit pro vytvoření nového sezení. třída Session- sezení, které identifikuje dialog uživatele se systémem. třída TextServer- instance této třídy je použita pro textovou komunikaci s textovou implementační platformou JVoiceXml. třída RemoteClient- klient, který identifikuje použitou implementační platformu. rozhraní TextListener- objekty třídy implementující toto rozhraní mohou přijímat zprávy od textových serverů. Tato implementace je vytvořena především pro použití v systémech řízených příkazovým řádkem. Pro uživatele, kteří preferují grafické rozhraní je naimplementován modul založený na sadě utilit Swing. 31

39 5. NÁVRH A IPMLEMENTACE TEXTOVÝCH MODULŮ 5.3 Implementace modulu s grafickým uživatelským rozhraním Jelikož se jedná o nadstavbu základní implementace textového modulu, je jeho inicializační fáze totožná. Odlišný je způsob poskytování dat a ovládacích prostředků uživateli. Uživatelské rozhraní je založeno na platformě Swing, která umožňuje efektivní implementaci GUI. Swing poskytuje nástroje k vytváření okenních aplikací se standardními ovládacími prvky, mezi které například patří nabídky, tlačítka, formuláře nebo složitější objekty, kterými jsou tabulky nebo textové editory. Implementace zahrnuje třídu JvoiceXMLGUI, která je exekutivní částí modulu a třídu Vxml- Checker pro kontrolu VoiceXML dokumentů. Při spuštění sezení třída JvoiceXMLGUI přijímá výstup od interpretu a zapisuje jej do grafické komponenty outputtext. Také se stará o odesílání uživatelského vstupu přes komponentu textinput. Jelikož je rozhraní řízeno událostmi, je pořadí ve kterém jsou prováděny části algoritmu závislé na akcích uživatele pracujícího s klientem. Obrázek 5.1: GUI JVoiceXml klienta Oproti základní implementaci obsahuje ta grafická jednoduchý editor umožňující vytvářet a modifikovat VoiceXML dokumenty. Hlavní komponentou editoru je editorarea, která je instancí třídy JTextArea. Ovládací prvky jsou rozděleny do dvou skupin. První skupina prvků ovládající textový editor: Položka New nabídky File, která slouží pro smazání obsahu textové oblasti a zrušení odkazu na dokument. Tlačítko a položka Open nabídky File otevírající dokumenty pomocí komponenty JFile- Chooser. Obsah textové oblasti je vyplněn obsahem souboru, který byl vrácen komponentou JFileChooser. Pokud uživatel nespecifikoval žádný soubor, není obsah textové oblasti změněn. 32

40 5. NÁVRH A IPMLEMENTACE TEXTOVÝCH MODULŮ Tlačítko nebo položka Save nabídky File slouží pro uložení změn provedených v textové oblasti. Položka SaveAs nabídky File slouží pro vynucení vyvolání komponenty JFileChooser pro výběr souboru, do kterého bude uložen obsah textové oblasti. Druhá skupina grafických prvků slouží pro spouštění interpretu a sezení s interpretem: Tlačítko Start Interpret, které při stisknutí zapříčiní spuštění interpretu JVoiceXml v samostatném vlákně Tlačítko Run spouští dialog s dokumentem v textovém editoru. Pokud textový editor neobsahuje žádný dokument, je uživatel vyzván k volbě dokumentového souboru Dialogová komunikace uživatele se systémem Při úspěšném spuštění dialogu je uživatelské rozhraní přepnuto do panelu Run, kde jsou umístěny grafické prvky pro příjem výstupu a pro poskytování vstupu interpretu. Algoritmus připojení k Interpretu a řízení dialogu je stejný v obou textových implementacích. Obrázek 5.2: Příklad dialogu Shrnutí Na rozdíl od implementace textového modulu se standardním rozhraním obsahuje grafická implementace uživatelsky přívětivé prostředí s rychlým a jednoduchým ovládáním. Umožňuje vytvářet vlastní instanci JVoiceXml interpretu a splňuje všechny stanovené cíle. 33