Poděkování Během svého studia jsem měl to štěstí být v kontaktu s mnoha lidmi, výjimečnými po lidské i odborné stránce. Těmto lidem bych rád poděkoval. Z Katedry počítačů děkuji zejména Ing. Komárkovi za to, že mě přitáhl k softwarovému inženýrství, a Ing. Macejkovi zato, že mi pomohl se zlepšit v oblasti distribuovaných výpočtů. Z Katedry kybernetiky děkuji především Ing. Košnarovi, který mě přivedl k problematice hlasových aplikací v rámci mé bakalářské práce. Hlasovým aplikacím jsem se mohl věnovat při svém působení v laboratoři RDC za výborného vedení Dr. Kencla a Ing. Rudinského, Ph.D. Děkuji těmto dvěma a dalším kolegyním a kolegům za cennou podporu a rady, během mého úsilí. Přístup k moderním hlasovým technologiím byl umožněn podporou společnosti IBM, za cenné rady děkuji zejména Ing. Kleindienstovi a Ing. Mackovi. Společnosti IBM rovněž děkuji za finanční podporu a možnost pracovat s pokročilým softwarem IBM WebSphere VoiceServer. Nakonec děkuji mamince za podporu během celého měho studia.
vii
viii
ix
x
Prohlášení Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
Abstract This diploma thesis is dedicated to human-machine voice interaction, that augments conventional visual-based interaction. The two kinds of interaction are expected to converge in near future in order to provide next-gen user experience, that mimic human-human interaction. Voice driven apps are friendly to visual inpaired users and claim minimal hardware requirements to a client device – a mobile phone is fully sufficient. Tomorrow’s mobile phones offer many advanced features such as GPS receiver, 3G Internet and large displays offering clear view. Mobile phones are about to become cheap, gifted and highly mobile next-gen services enabled terminal. They will become everyone’s gateway to information handled by both speech and visual. Next-gen services will dominate future markets, claiming users’s attention by offering smart functions based on user’s location, preferences. These services will reach human-like interaction soon and redesign today’s user interaction guidelines. Unfotunately, voice apps design & development is still rare in Europe. Therefore, voice enabled applications are slowly adopted by users. Todays user-computer design guidlines are visual oriented, visual and voice design have few in common. This thesis proposes a unique architecture to enable voice interaction to any third party’s application without explicit knowledge of voice design. The aim to accelerate adoption of voice interaction by software developers to make it widely available.
xiii
xiv
Abstrakt Tato diplomová práce se zabývá problematikou hlasové interakce člověka s počítačem, která představuje doplnění současně nejrozšířenější vizuální interakce. V budoucnu se v multimodálních službách budou hlasová a vizuální interakce doplňovat pro co nejvěrnější napodobení interakce lidí. Hlasové aplikace představují rovněž alternativu k vizuálním z důvodu přístupnosti zrakově postižených uživatelů a nízkými nároky na klientské zařízení, kterým může být obyčejný mobilní telefon. Mobilní telefony budoucnosti budou představovat dostupné mobilní klienty s všudypřítomnou konektivitou, velkými barevnými displeji, GPS přijímačem a rychlým připojením na Internet. Právě tyto vlastnosti učiní z mobilních telefonů přenosné a levné terminály pro přístup k multimodálním službám. V budoucnu lze proto očekávat razantní nástup nové generace služeb, založených na multimodální interakci s uživatelem. Tyto služby, dostupné kdekoliv a kdykoliv, budou pružně reagovat na polohu uživatele, poskytovat relevantní obsah a přizpůsobovat se kulturním zvyklostem uživatelů. Interakce s nimi bude snadná a příjemná, podobající se interakce dvou lidských bytostí. Nicméně znalosti problematiky vývoje hlasových aplikací nejsou příliš rozšířené, kvůli čemuž nejsou hlasové aplikace dostatečně rozšířené. Důvodem jsou specifika, vyplývající z rozdílů mezi vizuálním a hlasovým vnímáním člověka, kdy většina postupů pro tvorbu aplikací je orientována vizuálně. Přínosem této práce je návrh a implementace platformy, která umožní vývojářům zpřístupnit jejich vlastní aplikace pomocí hlasu, a tím rozšířit množinu uživatelů. Platforma neklade na vývojáře žádné nároky na znalosti hlasových aplikací, přitom však umožňuje snadno využít některých jejich silných stránek.
xv
xvi
Klíčová slova mobilní služby, hlasové aplikace, rozpoznávání řeči, syntéza řeči, webové služby
Architektura přístupu k hlasovým aplikacím, realizovaná v rámci RDC. . . . . . . Webové prostředí pro vývoj VoiceXML aplikací, vyvinuté v RDC. . . . . . . . . .
3 4
2.1 2.2
Rozdíly architektury mezi webovou a hlasovou aplikací. . . . . . . . . . . . . . . . Protokoly použité v hlasových aplikacích. . . . . . . . . . . . . . . . . . . . . . .
Úvod V současné době je většina softwarových aplikací založena na vizuální interakci a to i přesto, že primitivní hlasový syntetizér byl zkonstruován na konci 18. století a první rozpoznávač v roce 1952 [10]. Pro uživatele je však přirozenější multimodální interakce, kombinující hlasové a vizuální vjemy. Cílem multimodální interakce člověka s počítačem je nápodoba interakce člověka s člověkem, která využívá více smyslů. Ideálním klientem multimodálních služeb je mobilní telefon, zařízení s celosvětovou penetrací 60% [40], celkem 4 600 000 000 kusů. V některých rozvinutých zemích Evropy dosahuje penetrace nad 100%. V ČR se jedná o penetraci 130%, mobilní telefon má téměř každý student a každý druhý důchodce. V rozvojových zemích je penetrace menší, avšak mobilní telefony představují nejdostupnější cestu k informacím. Celkový počet počítačů dosáhl v roce 2008 jedné miliardy [30], přitom 58% počítačů je používaných ve vyspělých zemích v EU, USA a Japonsku, ve kterých žije 15% světové populace [1]. Uživatelé mají mobilní telefon, na rozdíl od osobních počítačů, většinou stále při sobě. Nové generace mobilních telefonů disponují rychlejším procesorem, větší paměti, kvalitnějším displayem, rychlým připojením na Internet a GPS přijímačem. Tyto a další funkce učiní v budoucnu z mobilních telefonů všudypřítomné klienty s konektivitou, zajišťující přístup k multimodálním službám. Současné dělení na vizuální a hlasové služby padne a přijde nová generace služeb, využívajících nejlepších vlastností z vizuální i hlasové interakcí [12]. Služby se stanou vůči uživatelů přátelštější a efektivnější díky zapojení více smyslů. Uživatel bude komunikovat ze softwarem, který bude mluvit jako člověk a možná tak i vypadat [13]. Informace pro uživatele budou pocházet z Internetu, role lidského operátora bude potlačena. Změní se způsob jejich prezentaci uživateli, založený na spolupráci webové stránky, vykreslené v prohlížeči telefonu, s rozpoznáváním a syntézou řeči. Uživatelé budou moci zapojit zrak i sluch pro rychlé pochopení informací, používání služby se stane přirozenější a zábavnější. Díky tomu, že mobilní telefony doprovázejí své majitele po celém světě, bude možné vytvořit služby, nabízející správné informace ve správný čas. Znalost polohy uživatele umožní předložit mu jen ty informace, které se vztahují k jeho aktuální poloze. Díky zapojení hlasu se práce s informacemi přiblíží rozhovoru dvou lidí. Tento vývoj umožní většímu počtu lidí přístup k informacím a efektivní práci s nimi.
1
2
1.1
KAPITOLA 1. ÚVOD
Výsledky laboratoře RDC
V rámci laboratoře RDC [28] byl zvolen přístup tvorby speciálních hlasových aplikací, jenž s uživatelem komunikují pomocí rozpoznávání s syntézy řeči a vlastní data získávají ze sítě Internet. Tento přístup klade minimální nároky na mobilní telefon i technické znalosti uživatele. Aplikační logika vlastních aplikací je zapsána v jazyce VoiceXML, jenž je W3C standardem pro tvorbu hlasových aplikací a je popsán v kapitole 2. Architektura RDC, která zajišťuje fungování hlasových aplikací, je znázorněna na obrázku 1.1 a skládá z těchto částí:
Pobočková ústředna Asterisk spojující síť RDC s mobilní sítí.
Interpret VoiceXML jenž vykonává logiku VoiceXML aplikací.
Rozpoznávač a syntetizér zajišťující rozpoznávání uživatelovy řeči a syntézu řeči, pomocí níž aplikace předává uživateli informace. Rozpoznávání a syntéza jsou prováděny na pokyn interpretru dle kódu VoiceXML aplikace.
WebProxy je služba, vyvinutá v rámci RDC pro snadné získání informací z webových stránek a předání VoiceXML aplikaci k dalšímu zpracování a syntéze uživateli [35].
VoiceXML IDE je vývojové prostřední pro textovou nebo vizuální tvorbu VoiceXML aplikací. VoiceXML IDE, které má podobu volně dostupné webové aplikace a bylo vyvinuto v rámci RDC, je zobrazené na obrázku 1.1. Součástí je automatické nasazení aplikace, která při prvním uložení obdrží telefonní číslo, na nějž je možné zavolat [34].
RDC používá software IBM WebSphere VoiceServer k interpretaci VoiceXML, rozpoznávání a syntéze. Tento software je darem společnosti IBM jako součást dlouhodobé podpory a vzájemné spolupráce. Členové RDC spolupracují s odborníky ze společnosti IBM při řešení inovativních projektů, které sledují aktuální světové trendy ve výzkumu a vývoji. Dosud bylo pro vývoj hlasových aplikací použito VoiceXML IDE, obsahující statický kód vlastní hlasové aplikace. Tento kód byl napsán a interpretován s omezenou možností přizpůsobení dle uživatelského vstupu či získaných informací. Jazyk VoiceXML sice podporuje skriptování a definuje elementy pro podmíněné vykonání instrukcí a větvení, avšak možnosti přizpůsobení jsou limitované. Dalším limitem je nutnost obsáhnout veškerý kód v jednom souboru, editovaném pomocí VoiceXML IDE ve webovém prohlížeči. Tento přístup je vhodný pro rychlou tvorbu hlasových aplikací menšího rozsahu. Z pohledu adaptace Servisně orientové architektury, popsané v sekci 3.2, se laboratoř RDC nachází v první fázi, vývoje webových aplikací. Cílem OSP je posun na druhý stupeň, vývoj kompozitních aplikací, využívajících informací z více služeb.
1.2. PŘÍNOS OPENSPEECHPLATFORM
3
Obrázek 1.1: Architektura přístupu k hlasovým aplikacím, realizovaná v rámci RDC. Klient uskuteční telefonní hovor z mobilního telefonu nebo s použitím internetové telefonie. Pobočková ústředna Astrisk slouží ke sjednocení přístupu různých klientských zařízení. VoiceEnabler interpretuje VoiceXML aplikaci, uloženou ve vývojové prostředí VoiceXML IDE. Aplikace může použít službu WebProxy k získání informací z webové stránky. Vlastní rozpoznávání a syntézy zajišťuje VoiceServer, který pracuje dle pokynů na základě interpretace VoiceXML.
1.2
Přínos OpenSpeechPlatform
Přínosem OpenSpeechPlatform (OSP) je návrh architektury a implementace platformy pro snadný vývoj jednoduchých až středně složitých hlasových aplikací bez nutnosti znalosti jazyka VoiceXML. Architektura je založena na paradigmatu Servisně orientované architektury pro dosažení distribuovatelnosti a modularity. OSP implementuje často používané a vyzkoušené postupy tvorby hlasových dialogů společně s autorizací, internacionalizací a podporou služeb využívajících znalost polohy uživatele pro odpovídající nabídku služeb. Vývojář hlasové aplikace poskytne pouze informace o obsahu hlasových dialogů, které může doplnit snadno pochopitelnými parametry formy dialogů. Díky těmto parametrům lze jednoduše získat přístup k některým mocným vlastnostem VoiceXML. Informace, popisující obsah a formu dialogů, jsou OSP předány protokolem SOAP, používaným pro komunikaci webových služeb. Tím je zajištěna interoperabilita s nejrůznějšími programovacími jazyky. OSP představuje primární přínos pro vývojáře aplikací, které zatím nedisponovaly hlasovou interakcí s uživatelem. S využitím OSP je možné původní aplikaci o tuto interakci doplnit, a tím zvýšit okruh uživatelů aplikace mimo dosah osobního počítače. Vývojáři nových aplikací, využívajících hlasové interakce, se nemusí zabývat implementací hlasových dialogů, podporou více jazyků, autorizací ani dalšími obecnými funkcemi. OSP tyto funkce implementuje automaticky.
4
KAPITOLA 1. ÚVOD
Obrázek 1.2: Webové prostředí pro vývoj VoiceXML aplikací, vyvinuté v RDC. Hlavní část vlevo umožňuje editovat kód aplikace. Ve spodní části se nachází panely pro kontrolu syntaxe, uložení, zobrazení logu a automatický překlad do jiného jazyka (angličtina, němčina, francouzština a španělština). V pravé části je umístěna správa aplikací, zobrazujících vlastníka a přiřazené telefonní číslo. Vývojář se tak může soustředit výhradně na získání informací, s nimiž bude uživatel pracovat, a nikoliv na tvorbu hlasové interakce. Sekundární OSP je pro uživatele, kteří získají snáze přístup ke hlasovým aplikacím, jejich vývoj na zelené louce by jinak byl velmi komplikovaný a zdlouhavý. Kapitola 2 seznamuje s tvorbou hlasových aplikací v jazyce VoiceXML. Kapitola 3 uvádí čtenáře do problematiky servisně orientované architektury a současného stavu řešení. Kapitola 4 popisuje architekturu OSP. Kapitoly 5 a 6 obsahují softwarovou analýzu v jazyce UML. Kapitola 7 popisuje implementaci samotné OSP včetně použitých technologií a knihoven, zatímco kapitola 8 popisuje funkci Hlasové navigace pro MHD, která je postavena na platformě OSP a demonstruje některé její možnosti. Příloha A obsahuje dotazník pro testování použitelnosti Hlasové navigace pro MHD, příloha B popisuje obsah přiloženého DVD.
Kapitola 2
Vývoj hlasových aplikací v jazyku VoiceXML Tato kapitola je koncipována jako úvod do tvorby hlasových aplikací. Sekce 2.1 popisuje architekturu hlasových aplikací a jejich rozdíly oproti aplikacím webovým. Sekce 2.2 seznamuje s hlavními koncepty značkovacího jazyka VoiceXML, který je standardem W3C pro tvorbu hlasových aplikací. A nakonec sekce 2.3 uvádí některé doporučované postupy pro tvorbu hlasových dialogů, snadno přístupných uživateli.
2.1
Architektura
Vstupem hlasové aplikace je uživatelova řeč, na základě jejíhož rozpoznání je stanoveno další chování aplikace. Výstupem je syntetizovaná pak řeč. Hlasové aplikace jsou obvykle zamýšleny pro uživatele používající telefonní přístroje a slouží jako podpora call center nebo asistivní technologie pro zrakově postižené uživatele. Z toho důvodu je rovněž podporování rozpoznávání tónové volby v podobě stisknutých tlačítek na klávesnici telefonu. Rovněž existují hlasové aplikace provozované na desktopu uživatele, avšak ty jsou mimo záběr této kapitoly, která pojednává o architektuře klient-server. V současné době nejčastějším případem architektury klient-server jsou webové aplikace, kdysi klient od serveru vyžádá dokument ve formátu HTML a ten následně interpretuje – vykreslí na obrazovku uživatele a zpracuje jeho akce v podobě klepnutí na odkaz nebo odeslání formuláře. Hlasové aplikace jsou vyvíjeny v jazyce VoiceXML, který stejně jako (X)HTML vychází ze syntaxe XML. Hlavním rozdílem je interpretace VoiceXML na straně serveru, klientské zařízení v podobě mobilního telefonu odesílá řeč uživatele a přijímá syntetizovanou řeč. Jedná se tedy o super tenkého klienta, na nějž jsou kladeny minimální nároky. Vlastní rozpoznávání a syntéza jsou interpretrem delegovány na speciální software, jak znázorňuje obrázek 2.1. Komunikace mezi jednotlivými prvky architektury hlasových aplikací je zajištěna množinou standardizovaných protokolů, které umožňují libovolný prvek nahradit, jedná se tedy o distribuovanou a modulární architekturu. Vztah protokolů k architektuře je uveden na obrázku 2.1. Hlas je mezi mobilním telefonem a sítí přenášen zakódovaný kodekem G.711. Alternativně je možné použít internetovou telefonii. Pobočková ústředna představuje bránu spojující mobilní síť a počítačovou síť s HW a SW prostředky pro podporu hlasových aplikací. 5
6
KAPITOLA 2. VÝVOJ HLASOVÝCH APLIKACÍ V JAZYKU VOICEXML
Web Klient: Interpretuje a vykresluje HTML
Serverová strana Server: Poskytuje obsah
Hlas Klient: Posílá a přijímá zvuk
VoiceBrowser: Interpretuje VoiceXML
Rozpoznávač
Syntetizér
Server: Poskytuje obsah
Obrázek 2.1: Obrázek znázorňuje rozdíly mezi zpracováním HTML stránky a hlasové aplikace v jazyce VoiceXML. Hlavní rozdíl spočívá ve vykreslování HTML prohlížečem na straně klienta, zatímco VoiceXML je zpracováno na straně serveru.
VoiceBrowser interpretuje kód hlasové aplikace a dle jejích požadavků spouští rozpoznávání a syntézu. VoiceBrowser je o příchozím hovoru upozorněn pomocí protokolu SIP pro internetovou telefonii, který jej odstiňuje od sítě, z níž klient volá. VoiceBrowser komunikuje s rozpoznávačem a syntetizérem pomocí protokolu MRCP, VoiceBrowser v tomto případě vždy vystupuje jako klient. MRCP je syntaktický podobný protokolu HTTP. Hlavním rozdílem je možnost upozornění zaslaného serverem klientovi, které se používá např. pro upozornění na konec syntézy nebo rozpoznání. Důvodem jsou vysoké výpočetní nároky a čekání na skončení uživatelovy řeči. Samotná řeč, ať již pocházející od uživatele nebo syntetizovaná, je přenášena mezi pobočkovou ústřednou a rozpoznávačem/syntetizérem pomocí protokolu RTP, používaném na Internetu pro streamování audia a videa.
2.2
Základy VoiceXML
Jazyk VoiceXML je standardem W3C pro tvorbu hlasových aplikací nezávislých na dodavateli technologie. Syntakticky vychází z XML a opírá se o princip stavových automatů s definovanými přechody. Takový automat je představován elementem form, který obvykle obsahuje definici syntézy výzvy uživateli, gramatiku definující množinu přípustných odpovědí a zpracování událostí. Událost představuje situaci, kdy uživatel nic neřekl, nebylo nic rozpoznáno, rozpoznání bylo úspěšné nebo jiná, aplikačně specifická událost. Tato sekce si neklade za cíl obsáhnout celý standard VoiceXML, neboť již existují kvalitní zdroje [37] [31] [23] [36]. Následující podsekce obsahují tutoriál založený na komentovaných příkladech pro rychlé seznámení s tvorbou hlasových aplikací. Jednotlivé příklady tvoří jako celek jednoduchou, avšak plně funkční, aplikace pro získání informací o vybraných korporacích – CorpInfo.
2.2. ZÁKLADY VOICEXML
G.711
7
VODAFONE
G. 71 1
PBX
SIP
RT P M R C
MR
P
TTS
RTP
Voice Browser
CP
ASR
Obrázek 2.2: Schema znázorňuje prvky architektury hlasových aplikací a protokoly, pomocí kterých probíhá komunikace.
2.2.1
Syntéza řeči
VoiceXML obsahuje elementy umožňující ovlivnit syntézu řeči. Následující výpis obsahuje formulář z identifikátorem welcome, obsahující pouze syntézu v elementu prompt. Po syntéze úvodní hlášky následuje krátká pomlka, jejíž trvání je možné zadat v sekundách nebo milisekundách. Formulář uzavírá přechod do jiného formuláře s identifikátorem IBM. Identifikátoru formuláře v elementu goto musí vždy předcházet znak #. ... Následující výpis obsahuje formulář, který uživatele seznámí s informacemi o IBM. Text je syntetizován ženským hlasem, akronym IBM pomalu. VoiceXML umožňuje specifikovat několik atributů prozódie, např. hlasitost, rychlost a výšku hlasu. Na slovo largest je kladen velký důraz. Název společnosti Coca-Cola syntetizován velmi potichu. Nakonec se přejde do uvítacího formuláře, jehož výpis je uveden výše.
8
KAPITOLA 2. VÝVOJ HLASOVÝCH APLIKACÍ V JAZYKU VOICEXML ... ...
Následující formulář popisující společnost RedHat vyžívá mužský hlas pro syntézu a demonstruje použití elementu say-as pro normalizaci textu. Při normalizaci je syntezátoru poskytnuta informace o sémantice textu, který je pak syntetizován dle konvencí. Ve výpisu níže je textu 5/23/1993 dodána sémantika data určeného formátu. ... ... Předchozí syntéza probíhala v anglickém jazyce. Následující výpis ukazuje použití němčiny, která je specifikována atributem xml:lang. Pro zajištění správné výslovnosti názvu společnosti Google je použit element phoneme, který specifikuje výslovnost pomocí abecedy IPA. ... ...
2.2.2
Rozpoznávání řeči
V předchozí sekci jsou uvedeny tři formuláře, každý obsahuje informaci o jedné společnosti. Zbývá doplnit formulář pro uživatelský výběr konkrétní společnosti. Výpis níže obsahuje formulář, obsahující element field, který představuje uživatelskou interakci výběru položky. Jeden formulář může obsahovat několik fieldů, které jsou procházeny postupně. Každý field se skládá z výzvy uživateli v podobě elementu prompt, gramatiky popisující přípustné odpovědi uživatele (element grammar) a zpracování událostí v elementech catch a filled.
... ...
10
KAPITOLA 2. VÝVOJ HLASOVÝCH APLIKACÍ V JAZYKU VOICEXML
Pro úspěch rozpoznání musí uživatel odpovědět název jedné z uvedených společností. V případě, že uživatel řekne JBoss, bude výsledkem RedHat 1 . Toho je dosaženo příkazem v jazyce ECMAScript [5], který je obsahem elementu tag. Pomocí ECMAScriptu je možné doplnit gramatiky o pokročilou sémantiku včetně vracení objektů, polí a volání funkcí. Ve výpisu výše je výsledku rozpoznání, reprezentovaného symbolem dolaru, přiřazen literál RedHat. Element catch zachytává události, když uživatel nic neřekne nebo když bylo rozpoznání neúspěšné. V takovém případě je dobré poskytnout uživateli nápovědu. Element filled je jen zkratkou pro , zachytávající událost úspěšného rozpoznání. Existujíc rovněž elementy nomatch a noinput. Pak se přejde do formuláře s identifikátorem názvu vybrané společnosti, který je dostupný v ECMAScript proměnné company, která byla deklarována elementem .
2.2.3
Řízení dialogu a skriptování
VoiceXML obsahuje elementy pro dynamické řízení dialogu na základě vstupu uživatele. Stávající aplikaci informací o společnostech doplníme funkcí zopakování poslední společnosti a upozorněním v případě výběru společností JBoss a Google, jak ukazuje výpis níže. Byla deklarována nová ECMAScript proměnná last_company. Gramatika obsahuje novou volbu pro zopakování společnosti repeat it. Slovo it má v gramatice nastaveno opakování repeat="0-1", je tedy nepovinné. Uživatel může říct repeat it nebo jen repeat, v obou případech bude výsledkem rozpoznání repeat, neboť je použit element tag. V elementu filled zpracován výsledek rozpoznání. V případě volby Google je uživatel upozorněn na němčinu, případě společnosti JBoss pak na její příslušnost k RedHat. Důvodem je zabránění zmatení uživatele. Následně je do proměnné last_company uložen název vybrané spolčenosti a následuje přechod do formuláře s informacemi. V případě volby opakování se přejde na formulář s informacemi o naposledy vybrané společnosti.
2.2.4
Získání externích informací
V závěrečné části úvodu do VoiceXML je demonstrována možnost získávat během hlasové interakce s uživatelem informace z externího zdroje. To demonstrujeme na funkci získání akciového kurzu společnosti, který se nachází v XML souboru dostupném na Internetu: IBM <price>122.10 +1.82 Soubor může být generovaný např. PHP skriptem nebo převzatý z některé webové služby přehledu akcií. VoiceXML využívá skriptování v jazyce ECMAScript, který obsahuje podporu XML v podobě Document Object Modelu. Výpis níže uvádí získání DOM modelu, jeho zpracování a syntézu výsledků. ... ... <script> 0) { quote.action = "price rise"; } return quote; } ]]> Základem je element data, který načte XML dokument ze specifikované URL a výsledný DOM model přiřadí proměnné company_data. Model je dále zpracován funkcí GetCompanyQuote, která je definována v elementu script. Funkce získá skrze rozhraní DOM cenu akcie a její změnu, na základě jejíž hodnoty stanoví popis změny – fall nebo rise. Výsledný objekt, navrácený funkcí, je dále použit při syntéze doplněný o elementy say-as, které specifikují sémantiku finanční částky v dolarech.
2.3
Pokročilé VoiceXML
Tato sekce navazuje na sekci předchozí, v rámci níž byla uvedena vzorová aplikace CorpInfo pro získání informací o společnostech. Vzorová aplikace je v následujícím výkladu doplňěna o pokročilejší témata.
2.3.1
Univerzální hlasové povely
Jak je uvedeno v předchozí sekci, každá VoiceXML aplikace se skládá z nejméně jednoho formuláře, v rámci něhož uživatel provádí výběr. Obvykle je však formulářů mnohem více. Každý však představuje jinou nabídku s odlišnými volbami, avšak některé univerzální volby by měly být uživateli k dispozici ve všech formulářích. Jedná se např. o příkazy pro získání nápovědy, návrat zpět, zopakování výzvy a další. Tento přístup podporuje předvídatelnost a univerzálnost ovládání, a tím snižuje kognitivní zátěž kladenou na uživatele [21]. Následující výpis obsahuje elementy link, které definují gramatiky platné pro celou aplikace a přiřazují jim událost. V případě úspěšného rozpoznání jedné z těchto gramatik bude vyvolána událost. Jejím zachycením v elementu catch je množné událost zpracovat.
2.3. POKROČILÉ VOICEXML
13
replay repeat itbackundohelpI don’t know ...
S univerzálními příkazy je dobré uživatele seznámit hned zpočátku a v případě potřeby je zopakovat. Úvodní dialog aplikace byl ve výpisu níže doplněn o informaci o příkazu pro získání nápovědu, v rámci která je uživatel seznámen i s ostatními příkazy. Události je možné zachytit na úrovni fieldu, formu nebo celého dokumentu. Událost je zachycena prvním nejbližším elementem catch dle pravidla košile je bližší než kabát. Díky tomu je možné zachycení události přizpůsobit formuláři, v němž se uživatel nachází. Následující výpis obsahuje zachycení událostí na úrovni dokumentu a na úrovni formuláře výběru společnosti:
14
KAPITOLA 2. VÝVOJ HLASOVÝCH APLIKACÍ V JAZYKU VOICEXML <prompt> The <emphasis>CorpName aplication provides information about desired corporation. Available commands are <emphasis>help<emphasis>, <emphasis>repeat it<emphasis> and <emphasis>back<emphasis>.
...
2.3. POKROČILÉ VOICEXML
2.3.2
15
Vyzvání uživatele k výběru
V případě neúspěšného rozpoznání je vykonán element catch, zachytávající příslušnou událost nomatch nebo noinput. V případě, že má uživatel obtíže s rozpoznáváním, však zní neustálé opakování téže hlášky agresivně. Proto je možné definovat několik elementů catch a prompt s různou celočíselnou hodnotou atributu count, udávající kdy se má daný element vykonat. Pokud se tato hodnota shoduje s tím, po kolikáté byla už vyvolána událost nebo výzva uživateli, je element vykonán. Pokud není definován element s dostatečnou hodnotou atributu count, je ten s nejvyšší. Následující výpis obsahuje dvě postupné výzvy prompt a tři nápovědy v případě neúspěšného rozpoznávání: Element reprompt slouží k zopakování výzvy uživateli. S dalšími a dalšími chybami při rozpoznávání jsou uživateli předkládány čím dál podrobnější instrukce, neboť uživatel má zřejmě rozpoznáváním problém. Je rovněž dobré jej uklidnit, neboť chyby rozpoznávání mají na některé uživatele frustrující účinky. Naopak další výzvy jsou kratší, neboť uživatel je s ovládáním již seznámen. Tvorba výzev představuje kompromis mezi popisem detailním, vhodným pro nové uživatele, a krátkým pro zkušené uživatele. Způsobem, jak vyhovět oběma skupinám, je použití bargein, což je funkce založená na spolupráce rozpoznávače a syntetizéru. Jestliže uživatel promluví během syntézy, je tato přerušena a na řeč uživatele je aplikováno rozpoznávání dle aktuální gramatiky. Následující výpis obsahuje zapnutí bargein a nastavení typu na hotword. V takovém případě je syntéza přerušena jen v případě úspěšného rozpoznání. Tento typ je vhodný do rušného prostředí a exteriéru, neboť zabraňuje nechtěnému přerušení syntézy.
16
KAPITOLA 2. VÝVOJ HLASOVÝCH APLIKACÍ V JAZYKU VOICEXML
<property name="bargein" value="true"/> <property name="bargeintype" value="hotword"/> Na výpisu výše je uveden postup, nazývaný zpožděná nápověda (delayed help): uživateli je nejprve syntetizována krátká výzva. Následuje pomlka a detailní výzva. Pomlka slouží k separaci nových a zkušených uživatelů: noví budou vyčkávat na pokračování výzvy, zatímco zkušení provedou výběr během pomlky. Výběr během pomlky je výhodný, neboť řeč uživatele nekoliduje se syntetizovanou řečí, což platí zejména při použití typu bargein hotword, kdy se syntéza přeruší až po úspěšném rozpoznání. Původní krátká výzva má ve výpisu bargein vypnutý jako ochranu proti hlučnému prostředí – v jeho případě máme jistotu že uživatel uslyší alespoň tuto krátkou výzvu.
2.3.3
Zotavení se z chyby
V případě chyby při vykonávání VoiceXML aplikace je interpretrem vyvolána událost error, kterou je možné zachytit standardním způsobem. V takovém případě je vhodné uživatele na chybu upozornit a zapsat podrobnosti do logu, jak ukazuje následující výpis: <prompt> Sorry. An error has occured. Uvnitř každého elementu catch jsou interpretrem definovány proměnné _event a _message, popisující událost. Jejich obsah je odvozen z objektu události, v tomto případě se jedná o kvalifikovaný název chyby a detailní popis.
2.3. POKROČILÉ VOICEXML
2.3.4
17
Ověření výsledku rozpoznání
Každé rozpoznávání s sebou nese dva velké problémy: nerozpoznání řeči uživatele, se kterým se dá bojovat vhodnou nápovědou v elementu catch, a špatné rozpoznání, kdy je výsledek odlišný od uživatelovy řeči. V takovém případě by měl mít uživatel k dispozici univerzální příkaz pro návrat do předchozího formu. Nicméně i tak je rizikem, že se špatné rozpoznání bude opakovat, což se stává zejména v rozsáhlých gramatikách nebo při výskytu několika podobných voleb v gramatice. Nejlepší možností je požití funkce N-Best-List rozpoznávače, který pak vrátí obecně N nejpravděpodobnějších výsledků, s nimiž je možné dále pracovat. Výpis níže ukazuje nastavení N-Best-List pro až pět kandidátů a deklaraci proměnné candidates pro uložení kandidátů. Do této proměnné je uložen obsah aplikační proměnné application.lastresult$, která obsahuje pole kandidátů navrácené rozpoznávačem. Každý kandidát má podobu objektu s těmito vlastnostmi: inputmode udává způsob vstupu uživatele. Možné hodnoty jsou voice a dtmf. confidence je celé číslo v intervalu h0; 1i udávající pravděpodobnost shody kandidáta se vstupem uživatele. utterance představuje posloupnost literálů, které byly rozpoznány. intepretation představuje sémantický výsledek rozpoznání, zpracovaný ECMAScriptem v gramatice. Kandidáti v poli jsou seřazeni dle vlastnosti confidence. V případě rozpoznání vstupu uživatele je provedena kontrola nejpravděpodobnějšího kandidáta. Jestliže je pravděpodobnost shody dostatečně vysoká (alespoň 80%), považujeme rozpoznání za úspěšné. V opačném případě přejdeme do speciálního potvrzovacího formuláře. <property name="maxnbest" value="5"/> ... Potvrzovací form obsahuje dva fieldy, jejichž vykonání je podmíněno počtem kandidátů. Jestliže se jedná o pouze jednoho, následuje výzva potvrzení s odpovědí ano/ne. Elementy option slouží pro snadnou tvorbu jednoduchých gramatik typu výběr jedné volby z několika. V případě kladné následuje přechod do formu dané společnosti, v opačném případě do formu výběru společnosti.
18
KAPITOLA 2. VÝVOJ HLASOVÝCH APLIKACÍ V JAZYKU VOICEXML ... ...
Druhý field potvrzovacího formu se vykoná v případě více kandidátů. V takovém případě je uživatel se všemi seznámen a má možnost zvolit pomocí tónové volby. Tónová volba je použita, neboť je pravděpodobné, že mezi kandidáty je několik velmi podobných voleb, jejichž rozlišení pomocí rozpoznání řeči by bylo jen velmi obtížné. Při zápisu voleb tónové volby v gramatikách je nutné dodržovat konvenci mezery před a za volbou. Po zadání volby uživatelem proběhne kontrola na znak hvězdičky pro návrat k výběru. Tato volba je užitečná, pokud uživateli nevyhovuje žádný kandidát. ... ...
20
KAPITOLA 2. VÝVOJ HLASOVÝCH APLIKACÍ V JAZYKU VOICEXML
Kapitola 3
Současný stav řešené problematiky Myšlenka síťové komunikace typu klient-server je ve světě výpočetní techniky dobře etablovaná. Mezi klasické distribuované architektury patří cluster a grid computing [2]. Cluster se skládá z množiny strojů, komunikujících po sítí a pracujících na stejném problému. Stroje v clusteru jsou homogenní, často vykonávají stejný algoritmus. Význam clusteru spočívá v redundanci jako ochraně proti výpadku a škálovatelnosti pro zvládání velké zátěže a snadné navyšování výkonu přidáváním nových strojů do clusteru. Naopak grid se skládá z heterogenní množiny strojů, kdy nějaký stroj přistupuje k prostředkům strojů ostatních. Grid je tedy založen na síťovém sdílení prostředků v sítích. Společným jmenovatelem obou architektur je lokální charakter. V praxi obě architektury konvergují do jedné, zajišťující jak sdílení prostředků, tak i škálovatelnost a redundanci. Provozovatel síťové architektury má obvykle všechny hardwarové i softwarové prostředky plně pod kontrolou. Problémy nastávají, pokud je třeba provozovat velké sítě napříč větším vzdálenostmi mezi městy, zeměmi nebo kontinenty. Jedná se typicky o celonárodní a nadnárodní organizace. V takovém případě se původní síť dělí na jednotlivé podsítě, spravované místními úřady nebo pobočkami firmy. Problémy spočívají průběžným vývojem dílčích podsítí. V případě centrálního plánování a schvalování je vývoj těžkopádný a pomalu reagující na požadavky lokálních poboček organizace. V případě autonomie poboček mohou nastávají problémy s interoperabilitou jednotlivých podsítí [3]. Řešením je Servisně orientovaná architektura. Jinou situací je model Software as a service, založený na pronájmu softwaru od poskytovatele, který se označuje jako Application Service Provider (ASP). Jedná se vlastně o outsourcing, kdy ASP zodpovídá za provoz určité služby plně včetně konektivity, správy hardwaru a vývoj softwaru. Model ASP úzce souvisí s pojmem Cloud computing. Obě situace konvergují v případě, že organizace zpřístupňuje své prostředky kromě různým oddělením a pobočkám rovněž obchodním partnerům, vůči kterým pak vystupuje jako ASP.
3.1
Cloud computing
Myšlenka cloud computingu je založena na sdílení hardwarových a softwarových prostředků, jejich pronájmu a škálování dle aktuální potřeby. Cloud, skládající se z pronajatých prostředků, se nazývá public cloud. Opakem je private cloud, který je spravován interně vlastnickou organizací a není veřejně přístupný. Software as a Service (SaS) je model dostupnosti služeb, založených na cloud computingu [20]. 21
22
KAPITOLA 3. SOUČASNÝ STAV ŘEŠENÉ PROBLEMATIKY
Teoreticky neomezený výkon. Škálování dle aktuální potřeby bez nutnosti dlouhodobého plánování. Placení po malých kvantech jen za skutečně vyžadovaný a využitý výkon. Distribuce dat mezi několika úložuštěmi, představující ochranu před ztrátou lokálních dat (přírodní katastrofa, požár, teroristický útok na sídlo společnosti), avšak za cenu ztráty soukromí. Použití virtualizace pro logické sdílení zdrojů bez ohledu na jejich fyzické dispozice. Virtualizace poskytuje logický pohled na persistenci dat, výpočetní výkon (procesorový čas a paměť) a síťovou komunikaci. Úroveň abstrakce logického pohledu je specifická pro použití cloudu. Může se jednat o nízkou úroveň, vizualizující samotný hardware (např. Amazon Eclastic Cloud), nebo virtualizaci úzce zaměřenou na vývoj webových služeb (např. Google AppEngine). Řešením mezi je virtualizace Microsoft Azure, postavená na platformě .NET. Následující sekce se zaměřují na otácky provozovatele cloudu.
3.1.1
Výzvy úspěšného nasazení a provozování
Článek [20] uvádí seznam deseti hlavních oblastí, jejichž úspěšné zvládnutí je důležité pro úspěšné nasazení cloud computingu. Týká se nasazení, růstu a vývoje i otázek licencí a obchodu. Dostupnost služby může být ohrožena v případě výpadku poskytovatele. Řešením je možnost redundance, možnost přesměrovat komunikaci na jiného poskytovatele, nabízející alternativní službu. Závislost na poskytovateli, použití proprietárních technologií. Řešením je použít otevřené standardy, např. ty definované SOA (viz. sekce 3.2). Ochrana dat před zcizením a ztrátou obsahuje použití šifrování, VPN, firewally a použití datových center, rozmístěných v různých lokalitách (na úrovni států nebo světa). Úzká hrdla při přístupu k datům mohou být vyřešena použitím vhodného RAID pole, dostupného skrze rychlou konektivitu. Nepředvídatelné výpadky a problémy s výpadky mohou být vyřešeny dostatečnou redundancí a zajištěním kvality služeb, např. vhodnou správou virtuálních strojů. Snadné škálování řízené systémem, který sleduje aktuální zatížení a upravuje priority jednotlivých virtuálních strojů. Reputace založená na rychlé a odpovědné technické podpoře. Licence nabízející různé způsoby placení dle skutečně využitém výkonu.
3.1.2
Principy provozování
Přínosem cloud computingu pro uživatele-klienta jsou nízké (vlastně nulové) pořizovací náklady, snadné škálování, žádná instalace, snadná centrální správa. Virtualizace na úrovni hardwaru je jeho sdílení mezi množstvím zákazníků, aniž by ti o sobě věděli nebo se jakkoliv ovlivňovali. Článek [20] popisuje mnoho aspektů vývoje vlastního cloud řešení. Zajímavé jsou zejména body, týkající se zpětné kompatibility zákazníkem provozovaných systémů, škálovatelnost, spolupráci s některou z vedoucích společností, poskytujících technickou podporu a nabídnutí platformy jako uceleného řešení, nabízející pro zákazníka zajímavé funkce.
3.2. SERVISNĚ ORIENTOVANÁ ARCHITEKTURA
3.1.3
23
Současné a budoucí trendy
Cloud computing je technologie pro vytváření a podporu trendů moderních služeb. Role cloud computingu jako poskytovatele služeb se osvědčila např. na službách pro placení na Internetu nebo prodej reklamy. Zákazník nakupuje službu od provozovatele cloudu, který je prostředníkem a vlastní službu deleguje na poskytovatele. Budoucí trendy budou zahrnovat mobilní služby, pružně reagující na polohu uživatele, jak je nastíněno v kapitole 1. V takovém případě je použití cloudu nezbytné z důvodu nutnosti práce s rozsáhlými objemy dat, požadovanými dle potřeb uživatele. Práce s takovým objemem dat pro početnou skupinu uživatelů si přirozeně vyžádá nároky na výpočetní výkon, který může opět poskytnout právě cloud.
3.2 3.2.1
Servisně orientovaná architektura Předchůdci SOA
V klasické síťové architektuře jsou na vzdálených strojích volány funkce a procedury, výsledky jsou však dostupné lokálně. Za tímto účelem byla vyvinuta technologie Remote Procedure Call (RPC). Výhodou RPC je pro vývojáře transparentní chování, kdy je na straně volajícího klienta vytvořen zástupný stub, na němž jsou volýny vzdálené metody a který volání přeposílá na vzdálený server [2]. Stub je zodpovědný za navázání komunikace se serverem, kódování a dekódování volaných procedur včetně parametrů a navrácených výsledků. RPC byla určena k interakci stroje se strojem. Jiná technologie WWW, založená na značkovacím jazyce HTML a protokolu HTTP, byla určena k interakci stroje s člověkem. Později byla vyvinuta varianta XML-RPC, založená na standardizovaném formátu pro výměnu informací – značkovacím jazyce XML, podporujícím univerzální kódování Unicode. Přitom jazyk XML vznikl na základě zjednodušení SGML, z něhož bylo odvozeno HTML, a Unicode vznikl pro podporu různých jazyků na jedné HTML stránce. Technologie pro komunikaci strojů a lidí tedy začaly konvergovat. jako Tento krok usnadnil interoperabilitu strojů, pracujících na různých platformách a využívajících např. různý formát pro uložení čísel (little versus big endian). Interoperabilitu architektury klient-server rovněž přinesla technologie CORBA zavedením Interface Definition Language (IDL). IDL definuje komunikační rozhraní včetně přenášených datových struktur, signatury vzdálených metod a návratových typů. Kompilací IDL vzniká stub v daném programovacím jazyce, který zastupuje vzdálenou proceduru. CORBA se však pro svou přílišnou složitost v praxi neujala.
3.2.2
Principy SOA
Servisně orientovaná architektura (SOA) se opírá o dva principy: jedním je interoperabilita garantovaná použitím XML, druhým pak paradigma Design by contract, používané při návrhu softwaru. Principem tohoto paradigmatu je popis chování softwaru, nikoliv jeho implementace. Na software je tak pohlíženo jako na black box s definovaným rozhraním, jehož obsah je neznámý. Popis chování (kontrakt) tedy musí být dostatečně obecný, aby bylo možné implementaci dle potřeby změnit [22]. Toho může být dosaženo, jestliže software bude chápán jako integrální část náplně organizace. Důraz při návrhu softwaru pak není kladen např. na třídy ani metody, nýbrž na business procesy jako např. rezervace letenky, kontrola zůstatku konta či počasí v dané lokalitě. Business procesy jsou přímou součástí činnosti organizace a jejich změna je pro všechna oddělení srozumitelná.
24
KAPITOLA 3. SOUČASNÝ STAV ŘEŠENÉ PROBLEMATIKY
Reprezentací business procesu na úrovni SOA je služba (service). Služba představuje metodu, jejímž zavoláním klient provede příslušný business proces. Kontrakt služby je definován, obsahuje popis metod, jejich parametrů a návratových hodnot. Kontrakt neklade žádné nároky na platformu ani programovací jazyk. Služba je nezávislá (self contained), nevyžaduje zavolání jiných služeb klientem. Jestliže služba požaduje dílčí výsledky jiných služeb, může je sama zavolat. V případě volání jiné služby je veškerá komunikace vedena dle kontraktu, služby na sobě nejsou implementačně závislé. Služby rovněž podporují kompozici, tedy vytvoření nového procesu použitím stávajících služeb. Uvedené vlastnosti služeb garantují jejich distribuovatelnost a modularitu, kdy je možné nahradit jednu službu jinou, pokud je dodržen specifikovaný kontrakt. Další vlastností služeb je možnost asynchronní komunikace, kdy odpověď služby může dorazit po delší době z důvodu přetížení nebo odložení zpracování odpovědi jako ochrany před přetížením. SOA tedy podporuje škálovatelnost rozsáhlých systémů. SOA je paradigma pro vývoj distribuovaných systémů, pracujících s nejvyšší úrovní abstrakce, kdy jednotlivé služby mohou zahrnovat celé aplikace. SOA se nezabývá transakcemi, bezpečností ani řízením služeb. Některé články uvádějí jako nutnou součást SOA rovněž repositář služeb. Registr slouží jako prostředník mezi klientem, konzumujícím službu, a serverem, poskytujícím službu. klient nejprve kontaktuje registr pro vyhledání požadovaných služeb. Z nich vybere a následně kontaktuje příslušný server. Použití registru tedy umožňuje vytvořit dynamickou architekturu, kdy se vztahy mezi klienty a servery, vytvářejí dynamicky dle potřeb klientů a možností serverů.
3.2.3
Vývoj aplikací dle SOA
Vývoj systému, založeného na paradigmatu SOA, lze pojmout směrem shora-dolů nebo zdolanahoru [11]. V případě směru shora-dolů lze použít standardní Model Driven Methodology pro postupnou transformaci abstraktních modelů na konkrétní, která je vhodná pro návrh nového systému. V případě použití SOA v prostředí s již zavedenými komponentami je vhodný směr zdola-nahoru, vycházející ze stávajícího prostředí a jeho možností. Při vývoji nového systému, založeného na SOA, uvádí [29] tři stupně vyzrálosti:
1. Vývoj webových aplikací pro správu obsahu, vyhledávání, diskuse, blogy a další.
2. Vývoj kompozitních aplikací, využívajících informací z více služeb. Cílem je poskytnout uživatelům správné informace s využitím znovupoužitelných a zaměnitelných služeb.
3. Automatizace business procesů mezi jednotlivými systémy.
Aplikace, založená na SOA, se skládá z prezentační vrstvy, klientské strany vrstvy kontaktující službu, vrstvy implementující samotnou službu dle kontraktu a doménové vrstvy, obsahující persistentní data např. v databázi, adresářové službě nebo získané pomocí adaptéru z legacy zdroje. Implementace SOA architektury by měla rovněž obsahovat monitorování, konfiguraci, deployment, autorizaci & autentizaci, přístup k perzistentním datům a registr služeb.
3.3. WEBOVÉ SLUŽBY
3.2.4
25
Registry SOA
Registry služeb představují katalog, popisující vyvinuté nebo outsourcované služby jako stavení kameny systémy, založeného na architektuře SOA. Uživatelé registru se dělí na tři role dle svých záměrů: Producent publikuje službu zanesením do registru a poskytnutím popisu. Konzument vyhledává služby dle kritérií. Správce spravuje účty producentů, nastavuje pravidla pro používání registrů a zopovídá za replikaci informací. Registry poskytují mechanismy pro popis služby – obvykle se jedná o názvy, popisy, způsoby kontaktu a taxonomii. Taxonomie slouží k popisu funkcí, nabízených službou. Službu by mělo být možné kontaktovat několika způsoby – buď redundantními, jako ochranu před výpadkem, nebo komplementárními, poskytující různá rozhraní pro různé klienty. Každý druh kontaktu musí mít definovaný typ svého rozhraní pomocí otevřených standardů. Registr představuje v podstatě databázi. Měl by tedy zajišťovat persistenci dat a jejich replikaci, zabezpečení, validaci formátu dat a životní cyklus služeb, skládající se z managementu schvalování, upozorňování na změny, vyhledávání a zajištění kvality (QoS). Registr by měl rovněž nabídnout webové administrační nástroje. Registr obsahuje pouze popis služeb na úrovni katalogu – neobsahuje definici rozhraní služby. Rozšířením konceptu registrů o metadata, specifická ke službě, vzniká repositář služeb.
3.3
Webové služby
Webové služby představují implementaci služeb dle paradigmatu SOA. Každá služba je jednoznačně identifikována svým URL, kontrakt i samotná komunikace využívají otevřených standardů: služba je popsána standardem WSDL, volání služeb je realizováno protokolem SOAP a vyhledávání služeb je založeno na registru UDDI. Následující podsekce se věnují každému ze zmíněných standardů.
3.3.1
Popis služeb pomocí WSDL
Web Services Description Language (WSDL) je jazyk, založený na XML, určený k popisu webových služeb. Je standardem W3C a obsahuje tyto části [18]: types definuje datové typy, použité ve zprávách, pomocí metajazyku XMLSchema pro popis značkovacích jazyků, vycházejících ze syntaxe a pravidel XML. XMLSchema je sám jazykem XML, což usnadňuje jeho strojové generování a zpracování. V popisu jazyků lze použít typovost. XMLSchema definuje množinu základních datových typů (např. int, double, string, datetime) a polí, je možné doplnit definici vlastních složených typů. Dokument zapsaný v jazyce, popsaný pomocí XMLSchema, je možné snadno strojově zpracovávat. Zpracováním se zabývá program zvaný parser, který načte dokument, ověří jeho správnost dle definice XMLSchema, a obsah zpřístupní pomocí volání API. Výhodou XMLSchema je tedy snadné zpracování pomocí již existujících parserů. Nevýhodou XMLSchema je problematické mapování typů na objekty z důvodu absence detailního popisu chování výsledných objektů.
26
KAPITOLA 3. SOUČASNÝ STAV ŘEŠENÉ PROBLEMATIKY
messages vychází z definovaných typů, které sdružuje do zpráv služby. Zprávou rozumíme parametr, předávaný volání vzdálené metodě služby, návratový typ s výsledkem volání metody a chybový typ, obsahující popis selhání metody. portTypes definuje vzdálené metody služby, na něž mapuje zprávy. binding popisuje způsob zavolání vzdálené metody služby pomocí protokolů a způsob kódování zpráv. service definuje URL služby, které lze použít k zavolání vzdálené metody. Uvedené části oddělují definice přenášených zpráv, volaných metod, kódování zpráv a URL ke kontaktování dané služby. WSDL dokument může obsahovat několik URL, čímž dává klientovi možnost provést výběr např. dle použitého kódování.
3.3.2
Protokol SOAP
Simple Object Access Protocol (SOAP) definuje komunikaci s webovou službou skrze síť Internet pomocí formátu zasílaných zpráv a jejich kódováním [6]. SOAP byl původně vytvořen společnostmi IBM a Microsoft, nyní je standardem W3C. Přenášené zprávy jsou ve formátu XML přenášeny nejčastěji přes HTTP. Je však možné použití i jiných protokolů, např. SMTP pro asynchronní komunikaci. Důvodem použití HTTP je mj. snadný průchod skrze firewally ve firmách bez nutnosti přidávat speciální pravidla a použití již existujících technologií, pracujících s HTTP. Obsah zasílaných práv je definován pomocí XMLSchema, které je součástí WSDL popisu služby.
3.3.3
Interoperabilita
Dle paradigmatu SOA mají být různé služby naspané v různých jazycích spolu interoperabilní. Původní verze standardů WSDL a SOAP však byly v některých ohledech vágní, což vedlo k rozdílným implementacím webových služeb. Proto vznikla organizace Web Services Interoperability (WS-I), jejíž standard WS-I Basic Profile původní standardy doplňuje [38].
3.3.4
UDDI registry
Universal Description, Discovery, and Integration (UDDI) je standard registru webových služeb podporující publikaci a vyhledávání. UDDI lze chápat jako hierarchickou databázi obsahující následující typy záznamů [24]: Bílé stránky obsahující adresy a kontakty provozovatelů služeb. Žluté stránky poskytující popis služeb dle taxonomie. Zelené stránky popisující technické informace, jak komunikovat se službou. UDDI úzce spolupracuje s protokolem SOAP, vystupuje jako webová služba poskytující rozhraní pro publikaci a vyhledávání webových služeb, replikaci, notifikaci a autorizaci. Rozhraní UDDI pracuje s těmito pojmy:
3.4. REST
27
Business entity odpovídá záznamu v bílých stránkách a slouží jako hlavní záznam, k němuž se vztahují jednotlivé služby nebo další business entity. Slouží ke konceptuálnímu modelování organizací, jejich poboček i oddělení, a tím vyjadřuje zodpovědnost za provoz konkrétní služby.
Business service poskytuje informace o množině služeb, které plní stejnou úlohu. Jedná se o názvy a popisy služeb v různých jazycích a taxonomie služeb, popsaná pomocí TModelů. Díky taxonomii je možné vyhledat služby, poskytující požadované funkce.
Template binding představuje technické informace o službě (Technical fingerprint). Jedná se typicky o adresu, na níž je služba dostupná, popis podporovaného rozhraní, informace o zabezpečení a další. Informace jsou popsány pomocí TModelů
TModel představuje metainformaci, popisující jiné informace. Určitý TModel je chápán jako reference informace, která je k němu vztažena. Registr UDDI obvykle obsahuje množinu TModelů, které mohou být známé napříč celou společností nebo celým oborem, a informace, které TModel referencují a vztahují se k nějaké službě.
UDDI je možné rovněž použít k sémantickému vyhledávání služeb [19].
3.4
REST
Složitost webových služeb vede některé společnosti k migraci na REST, který byl vytvořen jako technologie SOA, využívající stávající funkcionality protokolu HTTP. Tím se liší od webových služeb, které abstrahují od HTTP a definují vlastní mechanismy volání metod, předávání parametrů a vracení chybových stavů. REST používá HTTP metody GET, POST, PUT a DELETE pro manipulaci s daty, specifikovanými parametry předanými jako součást URL v případě GET nebo v těle zasílané zprávy v případě POST. Hlavní výhodou RESTu jsou snadné generování i zpracování výsledků a výborná škálovatelnost, neboť práce se samotným protokolem HTTP je nenáročná na výkon. REST je vhodný pro přístup k webovým zdrojům, které lze specifikovat pomocí URL, jejichž metody lze snadno namapovat na metody protokolu HTTP a struktura jejichž obsahu je jednoduchá. Naopak není vhodný pro služby, obsahující metody se složitými parametry, které nesouvisí s metodami protokolu HTTP. REST je možné doplnit definicí formátu výsledného obsahu podobnou WSDL, avšak původní záměr RESTu spočíval v přístupu, který by žádný popis formátu nepotřeboval. Podobně je možné použít registr UDDI pro katalogizaci RESTových aplikací. REST byl zamýšlen jako protipól webových služeb s množstvím souviseních standardů a technologií. Jestliže je pro implementaci systémy důležitý přínos UDDI nebo WSDL, pak je vhodné použít webové služby.
28
3.5
KAPITOLA 3. SOUČASNÝ STAV ŘEŠENÉ PROBLEMATIKY
Současná řešení SOA
Tato sekce obsahuje popis cloud řešení významných softwarových společností, všímá si zejména technologií pro popis a výměnu dat. V současné době existují dvě široce používané technologie, vycházející z paradigmatu SOA: WebServices a REST, obě popsané výše.
3.5.1 3.5.1.1
Google Google data API
V portfoliu společnosti Google se nachází řada zdrojů informací: Analytics, Apps Provisioning, Base, Blogger, Booksearch,Calendar, Code Search, Contacts, Documents List, Finance, Health, Maps, Picasa Web Albums, Project Hosting, Sites, Sidewiki, Spreadsheets, Translator Toolkit, Webmaster Tools, YouTube Přístup je zastřešen projektem Google data API, což je klient podporující řadu programovacích jazyků (např. Java, .NET, Python) a využívající RESTové rozhraní založené na Google Data Protocol, který rozšiřuje standard AtomPub o dotazy, autorizaci a dávkové požadavky. Atom Publishing Protocol, který informace popisuje jako kolekci položek standardu Atom, je definován standardem RFC 5023. Spoléhá na metody protokolu HTTP pro vytváření, upravování a mazání položek. Jedná se o nadstavbu protokolu Atom Syndication Format pro získání strukturovaných informací v podobě sekvence položek, který je definován standardem RFC 4287:
Example Feed2003-12-13T18:30:02ZJohn Doeurn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 <entry> Atom-Powered Robots Run Amokurn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a2003-12-13T18:30:02Z <summary>Some text.
[Update: The Atom draft is finished.]
3.5. SOUČASNÁ ŘEŠENÍ SOA
29
Atom Syndication Format disponuje možností vložení kódu v XHTML formátu a strukturované informace o času publikace, autorovi, právech, kategoriích a odkazu na související informace. Specifikace uvádí možnost uvedení bezpečnostní signatury ověřující pravost zprávy. Obsah každé položky je možné uvést v jakémkoliv značkovacím jazyce, který musí být uveden svým jmenným prostorem. Chybí členění do abstraktnějších úloh, popisujících požadované informace, bezpečnost založená na identitě či rolích uživatele a strukturovaný obsah nezávislý na znalosti formátu.
3.5.1.2
Google Wave API
Google Wave API představuje koncept konverzace lidí a robotů, členěné do vláken. Základním stavebním kamenem je wavelet, který slouží jako kontejner pro dokumenty a zprávy. Rozšiřitelnost spočívá v možnosti zapojit do konverzace své vlastní programy, v terminologii Google Wawe označované jako roboty. Ty je možné vyvinout pomocí Google Wave Robots API s klienty podporujícími např. Javu nebo Python. Podkladovou technologií je REST.
3.5.1.3
Google Maps API
Google Maps poskytují rozhraní založené na RESTu pro vyhledávání adres, lokací a letišť dle zadaných kritérií GSP souřadnic nebo adresy. Komponenty adresy se skládají z ulice, města, země, ale třeba i podlaží. Je podporován průnik několika lokací.
3.5.2 3.5.2.1
Yahoo Yahoo Mail
Pro přístup k Yahoo Mail je použit protokol SOAP. V rámci API je možné měnit např. preference uživatelů pro psaní a prohlížení emailů:
<userUIPref> 0 <defaultSortOrder>down ... Preference jsou ve strukturovaném a programově snadno zpracovatelném formátu. SOAP je možné použít rovněž pro příjem a odeslání emailů, k čemuž jsou však vhodnější standardy SMTP a IMAP, které fungují se všemi poštovními poskytovateli.
3.5.2.2
Yahoo Maps
Mapy Yahoo jsou dostupné skrze RESTového rozhraní, podporujícího geocoding i reverzní geocoding. Jsou podporovány informace o PSČ, městu, ulici, avšak chybí azimut a rychlost. Přesnost je specifikována logicky např. precision="address" namísto číselné hodnoty v metrech.
30 3.5.2.3
KAPITOLA 3. SOUČASNÝ STAV ŘEŠENÉ PROBLEMATIKY Yahoo Social APIs
Yahoo Social APIs je množina RESTových rozhraní pro přístup a ke komunitním službám Yahoo:
Social Directory API pro přístup k profilům uživatele a jeho přátel. Profil obsahuje informace o kontaktech, poloze, zájmech, práci, škole, výročích atd. API je zaměřené na kontakt mezi uživateli. Contacts API představuje přístup k adresáři kontaktů přátel. Kontakty jsou rozděleny do různých kategorií: ICQ, JABBER, MOBILE, SKYPE, WORK, . . . Updates API pro aktualizace událostí a aktivit, vztahujících se k uživateli. Jedná se typicky o nový článek na blogu, nahrání obrázku na server nebo příspěvek v diskusi Status API slouží k nahrání krátké zprávy na server, v níž uživatel popisuje své aktuální dojmy nebo myšlenky.
3.5.2.4
Yahoo! Application Platform
Yahoo poskytuje Yahoo! Application Platform (YAP) pro vývoj webových aplikací, provázaných s výše uvedenými API. základem je depersonalizace založená na znalosti informací o uživateli, získaných skrze rozhraní Yahoo. Životní cyklus aplikace, založené na YAP, se dělí na Small View, v němž má podobu modulu cizí webové stránky, a Canvas View, poskytující plné zobrazení na samostatné stránce a nabízející plnou funkčnost. Uživatel začne pracovat se Small View, v rámci kterého má možnost provázání se svým profilem na Yahoo, následně získá přístup k plné funkčnosti na základě informací z jeho profilu. Životní cyklus aplikace zajišťuje YAP, samotná aplikace je však nasazena na serveru provozovatele. Yahoo poskytuje vlastní sady SDK pro vývoj, jehož součástí je Yahoo! Markup Language (YML), jazyk vyzházející syntakticky z XML pro snadný přístup k pokročilým funkcím Yahoo APIs (např. yml:friend-selector pro zobrazení seznamu přátel nebo yml:profile-pic pro fotografii uživatele). Aplikace založené na YAP mohou rovněž využít technologii Yahoo! Query Language.
3.5.2.5
Yahoo! Query Language
Yahoo! Query Language (YQL) je technologie, dostupná skrze rozhraní SOAP, pro získávání informací pokládáním dotazů, které syntakticky vycházejí z SQL. Jedná se o otevřenou technologii, která podporuje i služby nesouvisející s Yahoo (např. Facebook).
SELECT * FROM flickr.photos.search WHERE text="cat"
Je možné hledat v různých zdrojích dle bohaté nabídky kritérií, např. blízké služby. Nalezené výsledky jsou však použitelné jen pro USA.
3.5. SOUČASNÁ ŘEŠENÍ SOA 3.5.2.6
31
Yahoo! OAuth
Yahoo! podporuje otevřenou architekturu pro autorizaci OAuth. Ta umožňuje třetí straně ověřit identitu uživatele, kterou uchovává správce identit. OAuth cílí na přístup k osobním informacím, jako jsou obrázky, videa nebo kontakty, spravované některou z komunitních služeb. OAuth používá standard SOAP pro komunikaci, k dispozici jsou klienti pro Javu a .NET. Třetí strana pošle žádost správci identit a přesměruje uživatele na přihlašovací stránku, provozovanou správcem. Po ověření identity uživatele proběhne přesměrování zpět na stránku třetí strany, která je informována o uživatelově identitě. výhodou tohoto řešení je, že třetí strana se nedozví heslo uživatele ani žádné informace, jejichž sdílení není povolené. OAuth postrádá rozlišení uživatelských rolí, kdy je přesná identita uživatele irelevantní. Důvodem je cílení na komunitní služby a obsah, zatímco bezpečnost založená na rolích je typická spíše pro podnikové aplikace.
32
KAPITOLA 3. SOUČASNÝ STAV ŘEŠENÉ PROBLEMATIKY
Kapitola 4
Architektura OpenSpeechPlatform Otevřená hlasová platforma (OSP) si klade za cíl zjednodušit hlasovou interakci mezi uživatelem a aplikaci, jenž implementuje nějakou funkci. Předpokládaným klientským zařízením je mobilní telefon, jenž může být vybaven GPS přijímačem. Žádné další požadavky nejsou definovány. Veškerá uživatelská interakce s OSP probíhá pomocí syntéze řeči, rozpoznávání řeči a tónové volby na klávesnici telefonu. OSP klade velký důraz na lokalizaci, tj. podporu vícejazyčných aplikací. Podpora jazyků je silně závislá na použitém rozpoznávači a syntetizéru. OSP využívá infrastrukturu laboratoře RDC, jenž poskytuje podporu pro anglický, německý, francouzský, španělský a český jazyk. OSP je založena na Servisně orientované architektuře, popsané v sekci 3.2, a skládá se z těchto částí:
• Definice architektury, jenž abstraktně popisuje chování OSP. • Definice rozhraní zpřístupněného aplikaci, pomocí nějž lze ovlivňovat obsah i formu hlasové interakce. Rozhraní je založeno na webových službách (viz. sekce 4.3). • Referenční implementace, jenž obsahuje mj. tvorbu hlasových dialogů a komunikaci s aplikací pomocí definovaného rozhraní. Viz. kapitola 5.
Jediným nárokem na samotnou aplikaci je podpora rozhraní OSP. Díky interoperabilitě webových služeb (viz. sekce 3.3) jsou fyzické umístění aplikace a použitý programovací jazyk irelevantní. Aplikace může obsahovat i jiné způsoby interakce (např. GUI) a spravovat vlastní databázi. V takovém případě aplikace využívá OSP jako alternativní interakci pro oslovení svých uživatelů, jenž momentálně nejsou v dosahu počítače. Příkladem může být plánovač spojení Dopravního podniku hl. města Prahy, jenž pracuje s databází linek a jízdních řádů, kterou zpřístupňuje pomocí webu. OSP pak může nabídnout alternativní hlasovou interakci. Pro návrh hlasové aplikace ve VoiceXML je vyžadována jistá odbornost, týkající se nejen znalosti vlastního jazyka VoiceXML, nýbrž i dialogového designu, jenž se řídí jistými návrhovými vzory podobně jako běžné programování. Kapitola 2 je pojata jako úvod do VoiceXML. OSP proto vývojáře odstiňuje před specifiky hlasových aplikací a dovoluje popsat chování aplikace deklarativním způsobem ve formátu XML. OSP definuje jednotné workflow pro každou aplikaci, která tudíž musí respektovat konvence. Ty se týkají uživatelského scénáře výběru úlohy a následné prezentace sekvence položek, jenž obsahují informace. 33
34
KAPITOLA 4. ARCHITEKTURA OPENSPEECHPLATFORM
Aplikace tedy musí rezignovat na scénáře vytváření nových či rozsáhlou úpravu stávajících položek. Hlavním důvodem je limitace gramatik VoiceXML, jenž jsou typu LL(k), a tedy nelze rozpoznávat přirozenou řeč. Rozpoznávání přirozené řeči vyžaduje N-gramovou gramatiku, jenž popisuje pravděpodobnostní strukturu daného jazyka [10]. OSP cílí na aplikace typu výběr položky - zjištění informací, které bude uživatel používat převážně v exteriérech. Předpokládaná využití jsou např. Hlasový průvodce po Praze, jenž za pomoci GPS detekuje památky v blízkosti uživatele a sdělí relevantní informace, a Hlasová navigace pro MHD, jenž je cílen na zrakově postižené uživatele poskytuje informace o dopravním spojení na základě výběru nástupní a výstupní zastávky. Funkční prototyp Hlasové navigace pro MHD byl implementován na podzim 2010 a myšlenka OSP vznikla na základě plánů jeho dalšího vývoje. Kapitola 8 popisuje prototyp, vuyžívající OSP.
4.1
Uživatelský kontext
Uživatelský kontext označuje množinu objektů, jenž jsou spjaté s uživatelem a obsahují informace, které umožňují přizpůsobit interakci s uživatelem. Právě informace uložené v kontextu mají sloužit k pokročilým funkcím, nastíněným v kapitole 1. Při komunikaci mezi OSP a aplikací je uživatelský kontext aplikaci opakovaně zasílán. Aplikace proto může poskytnout data dialogu v závislosti na informacích o uživateli:
4.1.1
Jazyk dialogu
V momentě zahájení dialogu s uživatelem je k dispozici pouze informace o jeho telefonním čísle. Z prefixu mezinárodního formátu čísla lze na základě normy E.164 [9] zjistit zemi uživatele, a tedy preferovaný jazyk. Zvolený jazyk je použit nejen v aplikaci, nýbrž i v hlasových dialozích, které realizují základní funkce OSP (např. autorizace, viz. sekce 4.1.3). OSP obsahuje lokalizaci těchto dialogů do několika jazyků, lze snadno přidat další. V případě selhání detekce jazyka na základě telefonního čísla je použita detekce na základě polohy uživatele.
4.1.2
Poloha uživatele
Znalost polohy uživatele umožňuje cílenou nabídku blízkých bodů zájmu. Uživatelovu polohu je možné určit pomocí GPS přijímače, jenž je součástí mobilního telefonu nebo pomocí funkce SS7Tracker, poskytované mobilní sítí. Technologie GPS vyžaduje mobilní telefon vybavený GPS přijímačem a programem, jenž získanou polohu s přesností jednotek metrů odešle na server. Technologie SS7Tracker neklade na uživatele žádné nároky, avšak musí být podporována mobilním operátorem [26]. V tomto případě je získána poloha základnové stanice, s níž mobilní telefon komunikuje. Jedná se tedy o přesnost na 100 až 200 metrů Obě technologie mají své přínosy a limity. Konkrétní použití záleží na doméně řešeného problému. Infrastrutura laboratoře RDC obsahuje přímé propojení se sítí mobilního operátora Vodafone, a tedy přístup k technologii SS7Tracker. významným problémem je ochrana soukromí uživatele, jenž je řešen protokolem Mobile Location Protocol (MLP), jenž je založen na XML a obsahuje podporu ověření identity klienta, jenž se dotazuje na polohu daného mobilního čísla. OSP implementuje MLP klienta, server může vracet informace o poloze získané nejen pomocí SS7Trackeru, nýbrž i pomocí GPS.
4.1. UŽIVATELSKÝ KONTEXT
4.1.3
35
Autorizace
Funkcionalita některých aplikací může klást nároky na ověření identity uživatele, kdy je třeba doložit, že volající je tím, za koho se vydává. Aplikace vznést požadavek na autorizaci buď ihned po zahájení interakce nebo při výběru chráněných úloh. OSP v při zahájení interakce zjistí bezpečnostní politiku aplikace, která je dána konfigurací. Možné politiky jsou:
REQUIRED Uživatel se musí autorizovat. SUPPORTED Rozhodnutí o autorizaci daného uživatele je ponecháno na aplikaci, která se může rozhodnout na základě uživatelského kontextu. DISABLED Uživatel se při zahájení interakce nemusí autorizovat. V případě výběru chráněné úlohy nutnost autorizace zůstává.
V případě autorizace je spuštěn dialog přihlášení a uživatel je vyzván ke vložení čísla PIN. Loginem je implicitně telefonní číslo, z něhož uživatel volá. Na PIN je posléze aplikována hash funkce jako ochrana před odposlechem, neboť login a hash PINu jsou zaslány aplikaci k ověření identity. OSP podporuje hašovací algoritmy MD5 a SHA-256. V případě úspěšné autorizace aplikace definuje seznam rolí, jenž byly uživateli přiřazeny. Bezpečnost v rámci OSP je založena na rolích, v nichž uživatelé vystupují. Výběr úloh je možné podmínit rolí, která musí být uživateli přiřazena. V případě několikanásobného zadání chybného PINu je interakce ukončena. Uživatelský scénář autorizace předpokládá, že aplikace zpřístupňuje i jiný způsob uživatelské interakce, pomocí něhož byl uživateli vytvořen účet a přidělen PIN.
4.1.4
Obecné preference uživatele
Aplikace může poskytnout repozitář uživatelských preferencí. Ten obsahuje ve strukturované podobě preference uživatele, které mohou být později použity jak OSP, tak i samotnou aplikací. Preference se skládají z položek a vzájemně vnořených skupin. Každá položka může mít více hodnot. Identifikátory skupin a položek se skládají z tečkami oddělených názvů rodičovských skupin. Např. preference jazyků má identifikátor osp.vxml.lang. Položka lang je vnořena do skupiny vxml, jenž je vnořena do skupiny osp. Hodnotami položky mohou být např. cs a en. Další preference se týkají např. k přístupu k poloze uživatele. Preference jsou určeny ke čtení, nicméně v některých případech mohou být OSP změněny. Typickým případem je změna jazyka interakce uživatelem v dialogu na začátku interakce. Tato změna se zaznamená do preferencí, po ukončení interakce je zašle aplikaci a příští interakce bude již automaticky zahájena preferovaným jazykem.
4.1.5
Vybrané úlohy
Následující sekce popisuje uživatelské scénáře. V rámci jednoho z nich je uživatel postaven před volbu úloh, o jejichž výsledky se zajímá. Výsledek volby je uložen v jeho kontextu a může být použit ostatními scénáři.
36
KAPITOLA 4. ARCHITEKTURA OPENSPEECHPLATFORM
4.2
Uživatelské scénáře
Uživatelské scénáře OSP zachycené na obrázku 4.2 představují konvenci jednotné interakce. Každý scénář představuje jeden modul OSP. Jednotlivé moduly si předávají informace pomocí sdíleného uživatelského kontextu. Kontaktování aplikace a následné zpracování výsledků včetně vytvoření dialogů může trvat až několik vteřin, čímž může být narušeno tzv. pravidlo tří vteřin. Toto pravidlo říká, že pokud je uživatel hlasové aplikace ponechán bez odezvy po dobu delší než tři vteřiny, je zmaten ohledně stavu aplikace a může zavěsit, neboť jej považuje za chybný. Z toho důvodu delší zpracování každého uživatelského scénáře uživateli zpříjemní hudba.
Obrázek 4.1: Vzájemně navazující uživatelské scénáře OpenSpeechPlatform. Inicializace shromáždí informace o uživateli a spustí uvítací dialog, jehož součástí je přihlášení uživatele, jestliže tak požaduje aplikace. Uživatel vybere požadované úlohy v několika krocích z kaskádových menu. Rovněž je možné vybrat úlohu z historie nebo uživatelských záložek. V případě vývěru chráněné úlohy je nutné přihlášení. Výsledky úloh je možné následně procházet. Souvislosti prezentují informace, které mohou souviset s informacemi o uživateli nebo vybranými úlohami.
4.2.1
Inicializace
Po zahájení interakce proběhne inicializace uživatelského kontextu, popsaného v předchozí sekci. Iniciace kromě toho obsahuje v pořadí tyto dialogy: 1. Přivítání, oznámení lokalizovaného názvu aplikace (viz. sekce 4.4). 2. Nabídka změny jazyka. Jazyk detekovaný na základě mezinárodního formátu čísla nebo polohy uživatele je nabídnut jako první. 3. Nabídka možnosti seznámit se s nápovědou aplikace na nejvyšší úrovni, tj. obecným popisem. Oznámení univerzálních příkazů platných pro celou interakci. 4. V případě požadavku aplikace autorizace uživatele. Uživatel bude moci pokračovat k výběru úlohy až po úspěšné autorizaci.
4.2. UŽIVATELSKÉ SCÉNÁŘE
37
Po dokončení inicializace je OSP spuštěn scénář výběru úloh.
4.2.2
Výběr úlohy
Výběr úloh má podobu průvodce o jednom a více krocích. V každém kroku uživatel vybere jednu úlohu ze vzájemně zanořených menu. Každé menu představuje hlasový dialog a skládá se z těchto částí: 1. Kontrola uživatelské role, jenž je vyžadována pro výběr daného menu. V případě, že uživatel není autorizován, je spuštěn přihlašovací dialog. V případě přihlášení, ale chybějícího oprávnění, je uživatel informován a vrácen do předchozího menu. 2. Výzva, vysvětlující nabídku. Jestliže tak aplikace specifikuje, může výzva rovněž obsahovat automaticky generovaný výčet všech voleb. 3. Vlastní gramatika, jenž obsahuje různé volby. Ty mohou představovat přechod do dalšího menu nebo úlohu. Aplikace může specifikovat použití hlasové nebo DTMF gramatiky, v případě hlasové pak mód rozpoznávání: exact pro rozpoznání přesně dle názvu volby nebo approximate pro částečnou shodu. Gramatika rovněž obsahuje tzv. universals, povely dostupné v různých dialozích pro získání nápovědy, návrat do předchozího kroku nebo menu, zopakování výzvy atd. 4. Zpracování chybových stavů, vzniklých absencí uživatelského vstupu nebo žádným výsledkem rozpoznání. V takovém případě je třeba uživatele požádat o zřetelnou výslovnost, případně poskytnout nápovědu. Dobrým postupem je použití praktického příkladu očekávaného vstupu uživatele. Rovněž je důležité při opakovaných chybách pozměnit nápovědu, neboť opakování stále stejné hlášky působí na uživatele agresivně. Aplikace může definovat seznam vlastních hlášek při chybě, nebo se spolehnout na OSP, jenž použije hlášky obecné doplněné o příklady několika voleb. 5. Zpracování výběru. V případě výběru vnořeného menu proběhne přechod na něj. V případě výběru položky, je aktivován další krok. V případě univerzálního povelu je tento vyhodnocen a proveden odpovídající přechod (např. do předchozího menu nebo zopakování posledního kroku). Po dokončení výběru úlohy v aktuálním kroku je zahájen další krok a uživatel informován o jeho cílech. Po dokončení posledního kroku je OSP spuštěn scénář získání výsledků. Uživatel se může rovněž rozhodnout pro dříve vybrané úlohy, jenž mohou být přítomny v historii, nebo uloženy v záložkách. V obou případech se jedná o výběr z příslušného menu, generovaného OSP na základě úloh uložených v preferencích uživatele.
4.2.3
Získání výsledků
Po vybrání úloh je uživatel seznámen s výsledky v podobě sekvence datových položek. Všechny položky v sekvenci mají stejnou strukturu a je možné mezi nimi přecházet pomocí univerzálních hlasových povelů předchozí položka, další položka, první položka a předchozí sekvence. Rovněž jsou k dispozici povely zopakuj to, zopakuj to pomaleji a zopakuj to rychleji. Přípustná je rovněž sekvence obsahující pouze jednu položku. Položka může obsahovat přílohy. Příloha je popis mediálního souboru, jenž je dostupný externě pomocí daného URL. Přílohou může být např. zvukový soubor, jenž se váže k položce. Součástí přílohy je rovněž textový popis, na jehož základě je uživatel informován o povaze přílohy.
38
KAPITOLA 4. ARCHITEKTURA OPENSPEECHPLATFORM
Z výkonnostního hlediska je důležitá možnost postupného načítání položek v sekvenci ze služby. Počet položek může být vysoký a zájem uživatele je nejistý. Proto může aplikace při žádosti o výsledky poskytnout pro každou sekvenci jen několik položek a další dodat na žádost OSP. Tato žádost je učiněna, pokud se uživatel při procházení přiblížil na konec načtené sekvence. Pak mohou být další položky načteny dříve, než si je uživatel explicitně vyžádá, čímž odpadne z uživatelského hlediska nepříjemná prodleva.
Obrázek 4.2: Možnosti přechodu sekvencemi obsahující různé položky. Výsledek může obsahovat několik sekvencí, mezi nimiž uživatel může přecházet způsoby uvedenými na obrázku 4.2.3. Jedná se o tyto přechody, které je možné kombinovat zanořováním:
Sekvenční Uživatel je po seznámení se všemi položkami v sekvenci dotázán na přechod do další sekvence. Paralelní Uživatel je dotázán na výběr z několika dostupných sekvencí.
Spojením těchto základních přechodů je možné vytvořit komplexní strukturování výsledků úlohy, díky němuž bude mít uživatel pod kontrolou, které informace jsou mu předávány. To je v hlasových aplikacích významné, neboť činí uživatelskou interakci efektivnější. Dialog pracuje ve smyčce, tudíž je možné se postupně dotazovat na různé sekvence. Pro ukončení scénáře výsledků a přechodu do do scénáře souvislostí použije uživatel hlasový příkaz. Z hlediska stavby dialogů, zejména výběru požadované sekvence, jsou převzaty konvence zavedené ve scénáři výběru úloh.
4.2.4
Získání souvislostí
Scénář seznámení uživatele s výsledky úloh předkládá deterministicky určené informace na základě vybraných úloh. Naopak scénář seznámení uživatele se souvislostmi operuje na pravděpodobnostní bázi a informací, u nichž existuje jistá pravděpodobnost souvislosti s uživatelským kontextem. OSP rozlišuje následující typy souvislostí:
4.3. MODULARITA A DISTRIBUOVATELNOST
39
Datum a čas Místo Osoba Vybrané úlohy Obecný předmět V případě Hlasového průvodce po Praze mohou pro volbu úlohy židovského hřbitova souvislosti nabídnout další židovské památky v Praze. V případě Hlasového průvodce pro MHD může pro volbu úlohy příjezdu do cílové zastávky v 11:00 být nabídnuta souvislost plánovaného oběda s přáteli, jenž je uveden v Google kalendáři uživatele.
4.3
Modularita a distribuovatelnost
V předchozích sekcích jej zmíněna komunikace OSP s aplikací pomocí definovaných rozhraní webových služeb, popsaných v sekci 3.3. Jedním z důvodů použití právě webových sližeb a nikoliv RESTu je podpora jazyku pro definici rozhraní WSDL. Lokalizace – zjištění aktuální polohy uživatele. Autorizace – zjištění nutnosti autorizace uživatele a ověření správnosti přihlašovacích údajů. Preference – načtení a uložení preferencí uživatele. Dostupné úlohy – načtení úloh dostupných pro uživatele. Výsledky – načtení informací dostupných uživateli pro vybrané úlohy. Souvislosti – zjištění informací souvisejících s vybranými úlohami a uživatelem. Každé rozhraní se skládá z jedné a více vzdálených metod, jež jako parametr vždy přijímají vstupní kontext (informace o uživateli včetně preferovaných jazyků, seznamu navštívených lokací a přiřazených rolí), v případech Výsledků a Souvislostí pak i vybraných úloh. Jednotlivá rozhraní jsou definována pomocí WSDL souboru popsaného v kapitole 3.3.1. Rozhraní poskytují jednoduchý způsob popisu informací, s nimiž pracuje OSP. Vzhledem k povaze webových služeb nejsou kladeny žádné nároky na fyzické umístění, použitý programovací jazyk ani proces vývoje. Dílčí výsledky, poskytované jednotlivými službami, jsou součástí uživatelského kontextu. Za životní cyklus uživatelského kontextu odpovídá OSP, jedná se o jeho inicializaci při zahájení interakce, aktualizaci v závislosti na volbách uživatele a zrušení po ukončení interakce. Z toho vyplývá, že jednotlivé služby mohou být bezstavové za použití návrhového vzorů muší váha. Díky bezstavovosti a jasnému vymezení jednotlivých služeb pak tuto spolu vlastně nemusí přímo komunikovat, mohou být dokonce zcela nezávislé. Jednou vyvinuté služby mohou být opakované použity různými aplikacemi nebo naopak vyměněny bez negativního dopadu na dostupnost funkcí, což je základní předpoklad modularity softwaru. V tom případě se mění význam termínu aplikace. Spíše než o homogenní kód se jedná o množinu služeb, které, ač samy o sobě zcela nezávislé, svými výstupy tvoří aplikaci. Pak se vlastní aplikace může skládat pouze z definice znovupoužitelných služeb aniž by sama obsahovala jakýkoliv kód. Aplikace je tedy logický popis použití fyzicky nezávislých služeb.
40
4.4
KAPITOLA 4. ARCHITEKTURA OPENSPEECHPLATFORM
Dynamická architektura
V předchozí sekci je zmíněna zaměnitelnost jednotlivých implementací služby, jež je umožněna jednotnou definicí rozhraní. Jedná se tedy o syntaktickou zaměnitelnost, neboť signatury vzdálených metod a typy návratových hodnot budou vždy stejné. Rozdílný však bude obsah a význam navrácených informací, tedy sémantika. Dynamická architektura, musí přitom umožnit zaměnitelnost syntakticky i sémanticky ekvivalentních služeb. Sémantika každé služby je popsána pomocí následující taxonomie: Druh služby udává druh podporovaného rozhraní. Např. Dostupné úlohy. Internacionalizace specifikuje jazyky, které služba podporuje. Např. čeština, angličtina. Lokalizace upřesňuje, ke kterým místům služba poskytuje informace. Např. Praha, Londýn. Funkce říkají, které úlohy služba nabízí. Např. informace o památkách, plánovač tras. Předměty uvádějí, k čemu s vlastní funkce vztahují. Např. památky, restaurace. Každá taxonomie s výjimkou druhu služby může obsahovat více hodnot. Je zavedena konvence použití anglického jazyka pro vyjádření hodnot, v případě internacionalizace pak použití dvoupísmenných kódů jazyků dle standardu ISO 639-1. Popis aplikace je založen na stejné taxonomii, která vyjadřuje konzumované služby. Aplikace tedy vystupuje v roli konzumenta, zatímco služba vystupuje v roli producenta. Pro nasazení dané služby v dynamické architektuře OSP je nutné vložení jejího popisu do registru služeb, hledání služby je založeno na nalezení požadované a nabízené taxonomie. OSP používá k nalezení požadovaných služeb vlastní API nezávislé na použití konkrétního registru. Toto API je nyní implementováno pro registr UDDI, popsaný v kapitole 3.3.4. Při registraci je možné zadat více způsobů přístupu ke službě. V případě výpadku tak bude moci být použit jiný způsob, čímž se zvyšuje odolnost vůči chybám a nespolehlivosti sítě.
4.5
Možnosti vyrovnávací paměti
Vzhledem k náročnosti kontaktování vzdálené služby, parsování odpovědi a následné transformace do VoiceXML je možné použít uložení výsledného VoiceXML dokumentu do vyrovnávací paměti. Služba specifikuje zvolenou strategii práce s pamětí jako součást poskytnutých informací. Strategie je určena rozsahem a maximálním stářím. OSP definuje tyto rozsahy: REQUEST – dokument je použit pouze pro aktuální požadavek. SESSION – dokument je použit pro všechny požadavky během současné interakce. APPLICATION – dokument je použit pro každý požadavek uskutečněný v rámci této aplikace. Rozsah lze doplnit maximálním stářím dokumentu, po jehož dosažení se stává nevyhovujícím a OSP provede jeho aktualizaci. Toto stáří lze uvést ve formátu stáří jednotka, kde stáří je celým kladným číslem a jednotka jedním z písmen s (sekunda), m (minuta), h (hodina), d (den). Výhoda specifikace maximálního stáří se projevuje zejména při rozsahu SESSION a APPLICATION, kdy je možné uložený obsah aktualizovat po přesně dané době. Při použití vyrovnávací paměti je třeba ze strany vývojářů obezřetnosti z důvodu zamezení přístupu k citlivým informacím.
4.6. KOMPONENTY OSP
4.6
41
Komponenty OSP
Na obrázku 4.6 je diagram komponent, které tvoří OSP. VoiceBrowser volá jeden ze servletů pomocí protokolu HTTP. Každý ze servletů má jasný účel odpovídající jednomu uživatelskému scénáři. Dalších několik servletů slouží k předávání některých dialogových povelů OSP aniž by bylo třeba přerušit hlasovou interakci. Servlety jsou velmi jednoduché, volají metody komponenty StateController, která funguje jako návrhový vzor fasáda, odstiňující servlety před množstvím poskytovatelů. V terminologii OSP rozumíme poskytovatelem třídu, jež zprostředkovává přístup k informaci, poskytnuté vzdálenou službou. Každý poskytovatel komunikuje jen s určitým typem služby tak, jak byly definovány v sekci 4.3. Z pohledu poskytovatele není podstatné, kde je služba umístěna ani jak je implementována, neboť každý typ služby je definován svým rozhraním. Služby vyhovující spuštěné aplikaci jsou získány z registru služeb způsobem popsaným v sekci 4.4. Jedna skupina poskytovatelů získává informace pro uživatelský kontext. Jedná se o poskytovatele nastavení/preferencí, polohy a autorizace. Poskytovatel polohy na rozdíl od ostatních komunikuje se vzdálenou službou pomocí protokolu MLP, jenž je průmyslovým standardem pro zjištění polohy mobilního telefonu. Dílčí výsledky těchto bezstavových poskytovatelů jsou po dobu uživatelské interakce uloženy v poskytovateli kontextu, jenž zodpovídá za správu všech aktuálně používaných kontextů. Výjimku tvoří poskytovatelé autorizace a inicializace, kteří se zapojují do interakce s uživatelem generováním dialogů v jazyce VoiceXML. Druhou skupinou jsou poskytovatelé, jejichž výstupem je VoiceXML dokument, který je navrácen servletem VoiceBrowseru a jeho interpretací probíhá interakce pomocí hlasových dialogů. Tito poskytovatelé si vyžádají informace popisující obsah a formu dialogů rovněž od vzdálených služeb. Výsledný VoiceXML dokument je možné uložit do vyrovnávací paměti, a tím při příštím požadavku ušetřit množství času.
4.7
Nasazení OSP
Diagram nasazení na obrázku 4.7 znázorňuje spolupráci OSP s ostatními prvky infrastruktury laboratoře RDC. Diagram obsahuje tři cloudy, každý sdružuje související entity, jenž se přímo či nepřímo účastní komunikace s OSP: Klientský cloud sdružuje klientská zařízení, jenž komunikují hlasem s VoiceXML dialogy, vygenerovanými OSP. Jsou podporována zařízení, přenášející hlas mobilní sítí (kodek G.711) i internetovou telefonií (protokol SIP). Zařízení mohou být rovněž vybavena GPS přijímačem a informovat o své poloze. Privátní cloud se skládá z hardwarových a softwarových prostředků, jimiž disponuje RDC: Asterisk – pobočková telefonní ústředna, jenž umožňuje přístup k hlasovým službám. Tomcat – servlet container, na němž je nasazena OSP. VoiceBrowser – interpret dialogů, napsaných v jazyce VoiceXML. Jedná se o dialogy, vygenerované OSP. MRCP server – zapouzdřuje přístup k funkcím rozpoznávání a syntéze řeči pomocí standardů VoiceXML a MRCP. Veřejný cloud obsahuje služby, jenž mohou být vyvinuty kýmkoliv s jedinou podmínkou podpory standardizovaného rozhraní OSP, zmíněného v sekci 4.3 a detailně popsaného v kapitole 7, a vložení taxonomického popisu do registru služeb.
42
KAPITOLA 4. ARCHITEKTURA OPENSPEECHPLATFORM
Obrázek 4.3: Diagram komponent zobrazující vztahy mezi oranžovými poskytovateli kontextu, kteří přistupují ke vzdáleným službám a jejich odpověď buď ukládají do uživatelského kontextu, a žlutými poskytovateli obsahu, kteří generují VoiceXML kód, který je možné uložit do vyrovnávací paměti. Vhodné služby jsou nalezeny pomocí šedého registru. K poskytovatelům přistupují servlety skrze fasádu, označené červeně.
4.7. NASAZENÍ OSP
43
Obrázek 4.4: Diagram nasazeni, popisující vztah privátního cloudu RDC ke cloudu klientském a veřejném. Žluté jsou jednotlivé cloudy, oranžové fyzické servery a růžové běhová prostředí, která obsahují spustitelný kód. Vztahy jsou popsány vyžadovanými protokoly: v případě klientského se jedná o síť GSM nebo internetovou telefonii, v případě veřejného pak rozhraní OSP, popsané v sekci 4.3. Privátní cloud se skládá ze HW a SW vybavení pro příjem telefonních hovorů, interpretaci VoiceXML aplikací, rozpoznávání a syntézu řeči. OSP generuje VoiceXML kód dle informací, pocházejících z veřejného cloudu.
44
KAPITOLA 4. ARCHITEKTURA OPENSPEECHPLATFORM
Kapitola 5
Softwarová analýza Softwarová analýza v jazyce UML obsahuje konceptuální popis chování jednotlivých modulů OSP, uvedených v popisu architektury v kapitole 4. Součástí této kapitoly jsou diagramy aktivit, stavu, sekvence a komponent. Každý z uvedených typů obsahuje poněkud odlišný pohled na OSP, a tím přispívá ke snazšímu odhalení konceptuálních chyb brzkém stádiu vývoje. Diagramy tříd jsou z důvodu přehlednosti uvedeny zvlášť v kapitole 6 – Návrh implementace. Popisy diagramů jsou v anglickém jazyce z důvodu možnosti prezentace co nejširšímu okruhu odborné veřejnosti.
5.1
Diagramy aktivit
Diagramy aktivit umožňují modelovat interakci s uživatelem rozdělením na dílčí aktivity a akce. Zatímco aktivita je dále dělitelná na další aktivity či akce, akce představuje konceptuálně atomický prvek. Diagramy vycházejí z uživatelských scénářům definovaných v sekci 4.2.
5.1.1
Základní diagram aktivit
Na obrázku 5.1.1 je znázorněn základní interakce. Ta je zahájena aktivitou inicializace, jejímž výstupem je uživatelský kontext (detail viz. 5.1.2). Dále interakce vstupuje do hlavní smyčky, v níž uživatel postupně vybírá úlohy, získává jejich výsledky a je seznamován se souvisejícími informacemi. Na konci každé smyčky je aktualizována poloha uživatele. V momentě ukončení interakce jsou uloženy změněné preference uživatele a následně ukončen uživatelský kontext. Vstupem jednotlivých kroků hlavní smyčky je vždy uživatelský kontext, v případě výsledků a souvislostí rovněž uživatelem vybrané úlohy. Aktivita každého kroku se skládá z aktivity vygenerování VoiceXML kódu, za níž zodpovídá OSP, a následné akce jeho interpretace VoiceBrowserem, která zajišťuje vlastní interakci s uživatelem (detail viz. 5.1.4). 45
46
KAPITOLA 5. SOFTWAROVÁ ANALÝZA
Obrázek 5.1: Základní diagram aktivit zobrazující žluté moduly, zajišťující uživatelské scénáře, oranžové akce, tvořící hlavní smyčku uživatelské interakce, a růžové akce vytvoření, uložení a uzavření uživatelkého kontextu.
5.1.2
Inicializace uživatelského kontextu
Inicializace uživatelského kontextu, zachycená na obrázku 5.1.2, se skládá z aktivit jeho vytvoření a jeho následného potvrzení uživatelem spojeném s uvítacím dialogem. Všechny informace, získané během těchto aktivit se stanou součástí uživatelského kontextu. Vytváření dialogu nevyžaduje přímou interakci s uživatelem. Nejprve jsou v registru služeb nalezeny služby adekvátní k volané aplikaci, které poslouží jako zdroj dalších dat. Poté je kontaktována služba pro získání uživatelských preferencí a polohy. Pokud preference neobsahují jazyk interakce, je tento odvozen na základě mezinárodního formátu telefonního čísla volajícího dle specifikace E.164. Pokud tato metoda selže, je jazyk odvozen dle polohy uživatele. Pokud selže i tato metoda, je použita výchozí angličtina.
5.1. DIAGRAMY AKTIVIT
47
Aktivita potvrzení kontextu vyžaduje přímou interakci s uživatelem. Nejprve je přivítán a je mu oznámen název volané aplikace. Následně má uživatel možnost změnit jazyk, pokud mu nevyhovuje ten výchozí. Dále je uživateli nabídnuta nápověda a popis aplikace. Pokud je tak aplikací vyžadováno, musí se nakonec uživatel autorizovat, aby mohl pokračovat do hlavní smyčky.
Obrázek 5.2: Diagram aktivity inicializace uživatelského kontextu. Růžová značí vstupní a výstupní parametry oranžových aktivit.
48
5.1.3
KAPITOLA 5. SOFTWAROVÁ ANALÝZA
Přihlášení uživatele
Aktivita přihlášení, znázorněná na obrázku 5.1.3, považuje za login telefonní číslo uživatele. Ten musí dodat číselný PIN, aby mohla proběhnout autorizace. Ta představuje zaslání přihlašovacích informací příslušné službě. V případě odmítnutí může uživatel zkusit jiný PIN. V případě tří neúspěšných pokusů je interakce s uživatelem ukončena. V případě úspěchu služba vrátí množinu rolí, přiřazených uživateli, jenž budou uloženy do uživatelského kontextu.
Obrázek 5.3: Diagram aktivity přihlášení uživatele. V případě přerušení je vyvolána událost storno, v případě třetího neúspěšného pokusu je uživatel odpojen. Výstupem je množina rolí, přiřazených autorizační službou.
5.1. DIAGRAMY AKTIVIT
5.1.4
49
Poskytovatel obsahu
OSP rozlišuje poskytovatele výběru úloh, výsledků úloh a souvislostí. Všichni poskytovatelé získávají svůj obsah stejným způsobem popsaným na obrázku 5.1.4. Vstupem je uživatelský kontext, případě doplněný o vybrané úlohy. Výstupem je kód VoiceXML, jenž je interpretován VoiceBrowserem. Nejprve proběhne kontrola na přítomnost obsahu ve vyrovnávací paměti. V případě absence je kontaktována vzdálená služba, jenž poskytne informace popisující obsah a formát obsahu, jenž jsou transformovány do VoiceXML. Výsledek je uložen do vyrovnávací paměti v závislosti na strategii vyrovnávací paměti, specifikované službou. V případě výskytu chyb služby nebo při zpracování je vrácen kód VoiceXML, informující uživatele o chybě.
Obrázek 5.4: Diagram aktivity poskytovatele obsahu. Růžová značí vstupní a výstupní parametry aktivity, oranžová dílčí akce. Pokud nelze načíst obsah z vyrovnávací paměťi, jetřeba kontaktovat vzdálenou službu a zpracovat její výsledek. V případě výskytu chyby je třeba vytvořit chybový dialog.
50
5.1.5
KAPITOLA 5. SOFTWAROVÁ ANALÝZA
Výběr úloh
Uživatelský výběr úlohy se skládá, jak je zřejmé z obrázku 5.1.5, z kontroly oprávnění a následného uložené výběru do uživatelského kontextu. V případě nedostatečných práv je uživatel nucen se přihlásit.
Obrázek 5.5: Diagram aktivity výběru úloh. V případě výběru úlohy s omezeným přístupem se musí uživatel přihlásit před tím, než je jeho výběr akceptován a uložen do uživatelského kontextu.
5.2. STAVOVÉ DIAGRAMY
5.2
51
Stavové diagramy
Stavové diagramy modelují stav interakce měnící se během interakce.
5.2.1
Hlavní stavový diagram
Diagram stavu interakce s uživatelem je zachycen na obrázku 5.2.1. Je doplňkem k dříve uvedeným diagramům aktivit a zobrazuje stavy vytvoření uživatelského kontextu, výběru jazyka, přihlášení uživatele a hlavní smyčku skládající se z výběru úloh, zjištění jejich výsledků a nalezení souvislosti. V případě další iterace ve smyčce je aktualizována poloha uživatele, V případě ukončení interakce jsou uloženy preference a uzavřen uživatelský kontext.
Obrázek 5.6: Hlavní stavový diagram. Oranžové stavy představují stavy hlavní smyčky uživatelské interakce. Žluté stavy představují stavy inicializace uživatelského kontextu, zatímco červený stav kontext uzavírá.
52
5.3
KAPITOLA 5. SOFTWAROVÁ ANALÝZA
Sekvenční diagramy
Sekvenční diagramy poskytují jiný pohled na modelované interakce díky explicitnímu znázornění časově podmíněných zpráv, zasílaných mezi zúčastněnými prvky. Diagramy vycházejí z uživatelských scénářů definovaných v sekci 4.2. Důraz je kladen na znázornění komunikace a zpráv mezi uživatelem, interpretrem VoiceXML, OSP a vzdálenou službou.
5.3.1
Hlavní sekvence
Hlavní sekvence, znázorněná na obrázku 5.3.1, představuje kostru, odkazující na specializované sekvence. Uživatel zahájí interakci s VoiceXML dokumentem. Ten požádá OSP o inicializaci uživatelského kontextu. Následuje hlavní smyčka, v níž uživatel vybírá úlohy, seznamuje se s jejich výsledky a souvislostmi. Před každým výběrem úloh je aktualizována poloha uživatele. Po skončení interakce jsou uloženy změněné preference uživatele a kontext uzavřen.
Obrázek 5.7: Diagram hlavní sekvence zobrazuje hlavní komunikaci mezi uživatelem VoiceBrowserem, který interpretuje VoiceXML, OSP, a vzdálenými službami. Inicializace uživatelského kontextu a poskytovatelé obsahu jsou uvedeni na samostatných diagramech.
5.3. SEKVENČNÍ DIAGRAMY
5.3.2
53
Inicializace uživatelského kontextu
Diagram na obrázku 5.3.2 popisuje dvoufázovou inicializaci uživatelského kontextu. První fáze proběhne po zahájení interakce a nevyžaduje uživatelský vstup. Skládá se z načtení preferencí, polohy a strategie autorizace ze vzdálených služeb. V případě chybějící preference jazyka se jazyk interakce odvodí dle mezinárodního formátu telefonního čísla nebo zjištěné polohy. Druhá fáze již vyžaduje interakci s uživatelem v podobě dialogu. Uživatel je přivítán, dostane možnost změnit jazyk interakce a je obeznámen s nápovědou a univerzálně platnými hlasovými příkazy. V případě nutnosti se musí uživatel autorizovat, aby mohl pokračovat hlavní smyčkou interakce.
Obrázek 5.8: Diagram sekvence inicializace uživatelského kontextu zobrazuje, jak jsou získány informace, z nichž se skládá uživatelský kontext. Informace pocházejí od čtyř různých vzdálených služeb a jsou spravovány OSP.
54
5.3.3
KAPITOLA 5. SOFTWAROVÁ ANALÝZA
Přihlášení uživatele
Diagram přihlášení uživatele na obrázku 5.3.3 popisuje výměnu mezi uživatelem, interpretovaným kódem VoiceXML, vlastní OSP a vzdálenou autorizační službou. Heslo je zadáno uživatelem na klávesnici telefonu odesláno OSP, aniž by byla interakce přerušena. OSP aplikuje na heslo hašovací funkci a spolu telefonním číslem (loginem) a uživatelským kontextem pošle autorizační službě. V případě úspěchu služba vrátí množinu rolí, přiřazených uživateli. Tyto role uživatele opravňují k přístupu ke chráněným úlohám. V případě selhání má uživatel celkem tři pokusy, po jejichž vyčerpání je interakce ukončena.
Obrázek 5.9: Diagram sekvence loginu uživatele zobrazuje interakci mezi uživatelem a OSP. VoiceBrowser, který interpretuje VoiceXML je jen prostředníkem. Vlastní ověření identity uživatele je delegováno na vzdálenou službu.
5.3. SEKVENČNÍ DIAGRAMY
5.3.4
55
Poskytovatelé obsahu
Na obrázku 5.3.4 zobrazuje diagram komunikaci OSP a vzdálené služby, která je společná pro všechny poskytovatele obsahu: úloh, výsledků a souvislostí. Pokud není obsah ve vyrovnávací paměti, OSP požádá službu o informace, které následně transformuje do podoby VoiceXML dokumentu, který je poté uložen do paměti dle službou specifikované strategie. Nakonec je obsah předán k interpretaci VoiceBrowseru.
Obrázek 5.10: Diagram sekvence obecného poskytovatele obsahu zobrazuje načtení obsahu buď z vyrovnávací paměti nebo ze vzdálené služby s následnou transformaci do VoiceXML a uložení do vyrovnávací paměti.
56
5.3.5
KAPITOLA 5. SOFTWAROVÁ ANALÝZA
Poskytovatel výběru úloh
Poskytovatel výběru úloh poskytuje výběr dle způsobu, popsaného u obecného poskytovatele obsahu. Specifickým chováním je uživatelský výběr úloh. V takovém případě proběhne kontrola oprávnění uživatele, tj. zda má uživatel přiřazenu vyžadovanou roli. V případě, že uživatel není přihlášen, dojde k vyvolání přihlašovacího dialogu, popsaného na obrázku 5.3.3. V případě, že uživatel je přihlášen, avšak nemá požadované oprávněni, není mu dovoleno úlohu vybrat.
Obrázek 5.11: Diagram sekvence poskytovatele výběru úloh se chová stejně jako obecný poskytovatel obsahu a navíc kontroluje oprávnění uživatele k výběru daných úloh.
5.3. SEKVENČNÍ DIAGRAMY
5.3.6
57
Poskytovatel výsledků úloh
Diagram na obrázku 5.3.6 ilustruje uživatelské procházení nalezenými výsledky úloh v podobě sekvencí položek. Vlastní dialog procházení je získán a vytvořen způsobem uvedeným v obecném poskytovateli obsahu. OSP dovoluje žádat o položky po částech v momentě, kdy o ně uživatel projeví zájem. V takovém případě OSP požádá vzdálenou službu výsledků úloh o další položky dané sekvence, která následně zpracuje a zpřístupní dialogu procházení. Načtení dalších položek se děje bez nutnosti přerušit stávající interakci.
Obrázek 5.12: Diagram sekvence poskytovatele výsledků úloh, který načte výsledky úloh ze vzdálené služby a umožní uživateli s nimi pracovat navigací v hlasových dialozích.
58
5.3.7
KAPITOLA 5. SOFTWAROVÁ ANALÝZA
Poskytovatel souvislostí
Obrázek 5.3.7 obsahuje diagram zjištění souvislostí, jenž využívá obecného poskytovatele obsahu. Souvislosti mají podobu jednoduchého dialogu, jenž nabízí související informace a neobsahuje žádnou další komunikaci s OSP.
Obrázek 5.13: Diagram sekvence poskytovatele souvislostí načte ze vzdálené služby a předloží uživateli souvislosti k uživatelskému kontextu nebo vybraným.
Kapitola 6
Návrh implementace Návrh implementace obsahuje popis tříd tvořící OSP, jejich vztahů, dědičnosti a metod. Slouží jako návod k vlastní implementaci ve zvoleném programovacím jazyce.
6.1
Třídy uživatelského kontextu
Na obrázku 6.1 jsou uvedeny třídy tvořící uživatelský kontext (viz. sekce 4.1). Třída User obsahuje seznam preferovaných jazyků a slouží jako kontejner pro další informace: identitu uživatele s množinou přiřazených rolí a seznam zjištěných poloh uživatele. Každá poloha je označena časem zjištění a dekomponována na GPS souřadnici a adresu ve formátu použitelném pro lidi. Třída User je vytvořena a zaplněna při inicializaci kontextu. Informace o poloze jsou dodány poskytovatelem polohy, informace o rolích pocházejí od poskytovatele autorizace.
Obrázek 6.1: Diagram tříd uživatelského kontextu: oranžové třídy popisují identitu a polohu uživatele, žluté jeho preference a nastavení. Červená třída popisuje selhání vzdálené aplikace, která je popsána šedou třídou.
59
60
KAPITOLA 6. NÁVRH IMPLEMENTACE
Třída aplikace popisuje aplikaci spuštěnou v rámci OSP a jako součást kontextu je zaslána vzdálené službě při každém požadavku. Třída selhání obsahuje informace vrácené službou v případě výskytu chyby. Každá třída SettingGroup představuje skupinu nastavení, je identifikována jménem a může obsahovat vnořené skupiny a položky. Položka nastavení (třída SettingItem) je rovněž identifikována svým jménem a má přiřazen seznam hodnot. Nastavení pro daného uživatele je získáno od poskytovatele nastavení ve fázi inicializace uživatelského kontextu. V nastavení jsou uchovány uživatelem preferované jazyky, historie vybraných úloh a uživatelem zazáložkované úlohy. Uživatel může v inicializačním dialogu změnit preferenci jazyka. Tato změna je uložena do nastavení a poskytovatelem zaslána vzdálené službě. Pro navigaci skrze vnořené skupiny je použita tečková notace, oddělující názvy všech rodičovských skupin.
6.2
Třídy výběru úloh
Poskytovatel výběru úloh vrátí množinu kroků, v rámci kterých uživatel vybírá úlohu z nabídky kaskádových menu. Každé menu popisuje obsah a formu vygenerovaného dialogu uživatelského výběru. Scénář výběru úloh je popsán v sekci 4.2.2. Seznam informací představuje výzvy uživateli, které mohou být různé v závislosti na tom, po kolikáté uživatel výzvu slyší. Rady představují nápovědy použité v případě neúspěšného rozpoznání nebo explicitní žádosti uživatele o nápovědu. Stejně jako informace, i nápovědy se mohou různit dle počtu opakování. Název je použit při tvorbě gramatik u vložených menu, jazyk menu se vztahuje na jeho název i vnořené úlohy. Díky tomu je možné tvořit menu v různých jazycích a ty vzájemně kombinovat. Přístup k menu je možné omezit na uživatele vystupující v jedné z definovaných rolí.
Obrázek 6.2: Diagram tříd vztahujících se k výběru úloh: žlutá představuje krok výběru, při němž uživatel vybírá z oranžových menu konkrétní položky, též oranžovou. Šedá třída představuje popis formy dialogu ve formátu, specifickém pro implementaci. Červená třída představuje uživatelský výběr, vztahující se k danému kroku a úloze.
6.3. TŘÍDY VÝSLEDKŮ ÚLOH
61
Úloha definuje stejné vlastnosti jako menu. Její hodnota je po výběru asociována s aktuálním krokem ve třídě vybrané úlohy, která je uložena do uživatelského kontextu a použita poskytovatelem výsledků úloh. Formu vytvořeného dialogu je možné ovlivnit pomocí tzv. objektů, páru název, hodnota. Název určuje OSP podporovanou funkci, kterou může vývojář služby použít. Tento flexibilní mechanizmus umožňuje snadné přidávání funkcí nezávisle na standardu OSP. Pro tvorbu dialogů jsou podporovány tyto objekty: vxml.mode udává mód gramatik, hodnoty voice pro hlasovou a dtmf pro tónovou volbu. Výchozí voice. vxml.accept určuje způsob rozpoznávání gramatik, hodnoty exact pro přesnou shodu jména menu či položky a approximate pro částečnou shodu. V případě volby vxml.mode=dtmf nemá smysl a je ignorována. Výchozí exact. vxml.enum zapíná vyjmenování všech voleb menu jako součást výzvy. Hodnoty true a false. V případě volby vxml.mode=dtmf je automaticky zapnuta. V případě příliš vysokého počtu položek je ignorována.. Výchozí false. vxml.bargein zapíná přerušení syntézy výzvy v případě volby uživatele. Hodnoty true a false. V případě volby vxml.mode=dtmf je automaticky zapnuta. Výchozí false. vxml.smartdialogs zapíná automatické generování chytrých dialogů na základě voleb dostupných z menu. Tato volbaje dostupná, pokud vývojář nechce definovat vlastní výzvy a nápovědy uživateli, dialogy jsou generovány dle principů popsaných v sekci 2.3.2. Hodnoty true a false. Výchozí true.
6.3
Třídy výsledků úloh
Poskytovatel výsledků úloh obdrží od vzdálené služby vzájemně zanořené skupiny obsahu, jak je uvedeno na obrázku 6.3. Scénář seznámení uživatele s výsledky úloh je popsán v sekci 4.2.3. Každá skupina se skládá z úlohy a obsahového modelu. Použité úloh, jak definovaných v předchozí sekci, umožňuje vytvořit dialog výběru následující obsahové skupiny s pravidly navigace konzistentními s výběrem úlohy. Struktura obsahového modelu, uvedeného na obrázku 6.3, zobrazuje dva potomky: Model invokace umožňuje spustit jinou aplikaci s definovanými vstupními parametry v podobě výběru úloh. Datový model obsahuje sekvenci položek, které jsou složeny z logických skupin seskupujících jednotlivé vlastností, které obsahují informace prezentované uživateli. Skupiny jsou navzájem odděleny pomlkou. Každou vlastnost je možné doplnit sémantikou obsažené informace, která je důležitá pro správnou řečovou syntézu: emphasis pro zdůraznění informace. Výsledkem je VoiceXML element emphasis. more pro zvětšení důležitosti na úkor ostatních informací. Výsledkem je VoiceXML element prosody specifikující syntézu pomalejší řeči. less pro zmenšení důležitosti na úkor ostatních informací. Výsledkem je VoiceXML element prosody specifikující syntézu rychlejší řeči.
62
KAPITOLA 6. NÁVRH IMPLEMENTACE
Obrázek 6.3: Základní diagram tříd výsledků úloh. Ty jsou organizovány ve vzájemně zanořených růžových skupinách, které obsahují vlastní obsah, označený žlutě. Navigace do různých skupin je realizována pomocí oranžových úloh, které reprezentují volbu uživatele pro danou skupinu. time pro sémantiku času. Výsledkem je VoiceXML element say-as s atributem interpret-as specifikující formát čas. date pro sémantiku datum. Výsledkem je VoiceXML element say-as s atributem interpret-as specifikující formát datum. measure pro sémantiku vzdálenosti. Výsledkem je VoiceXML element say-as s atributem interpret-as specifikující formát délku. currency pro sémantiku finanční částky. Výsledkem je VoiceXML element say-as s atributem interpret-as specifikující formát měny. phone pro sémantiku telefonního čísla. Výsledkem je VoiceXML element say-as s atributem interpret-as specifikující formát telefonu a možnost na dané číslo zavolat. Každou skupinu je možné dále doplnit tzv. přílohou s mediálním obsahem, např. s hudbou nebo namluveným textem. Příloha je specifikována URL vlastního média a zprávami, jež ji popisují. OSP podporuje streamování položek v závislosti na zájmu, projeveném uživatelem. Položky se se proto nestahují naráz, nýbrž po částech.
6.4
Třídy nalezených souvislostí
Poskytovatel souvislostí obdrží od vzdálené služby seznam souvislosti, vztahujících se k části uživatelského kontextu, umístěné na obrázku 6.4 v pravé části. Scénář seznámění uživatele se souvislostmi je popsán v sekci 4.2.4. Souvislost se kromě výběru úloh, času a místa může rovněž vztahovat k osobě nebo obecnému předmětu, určeného textovým řetězcem. Součástí souvislosti je vždy zpráva a popis zdroje, možná je rovněž mediální příloha, např. zpráva z hlasového záznamníku.
6.5. TŘÍDY POSKYTOVATELŮ
63
Obrázek 6.4: Detailní diagram tříd výsledku úlohy, který může obsahovat buď vyvolání externí aplikace (růžové třídy) nebo datové položky, kterými může uživatel procházet (oranžové třídy). Jednotlivé datové položky se skládají ze strukturovaných vlastností a multimediálních příloh.
6.5
Třídy poskytovatelů
V terminologii OSP představuje poskytovatel třídu, zodpovědnou za kontaktování vzdálené služby a zpracování její odpovědi. Poskytovatelé se dělí na obsahové a kontextové a jejich vztah je definován v sekci 4.6.
6.5.1
Poskytovatelé obsahu
Společným předkem poskytovatelů výběru úloh, jejich výsledků a souvislostí je poskytovatel obsahu, jak ukazuje obrázek 6.5.1. Všichni poskytovatelé obsahu generují na základě informací od vzdálené služby VoiceXML kód, který je možné uložit do vyrovnávací paměti. Práce s vyrovnávací pamětí je společná pro všechny obsahové poskytovatele, a proto je implementována v jejich společném předkovi dle popisu v kapitole 4.5. Každý rozsah ukládání do vyrovnávací paměti je implementován jiným potomkem abstraktní společné třídy, jak je uvedeno na obrázku 6.5.1. Třída Cache deklaruje metody pro získání obsahu, dotazu na jeho validitu v závislosti na strategii vyrovnávací paměti, odstranění obsahu a jeho aktualizaci. Aktualizace změny rozsahu ukládání do vyrovnávací paměti je vyřešena návrhovým vzorem strategie, kdy je vyměněn potomek třídy Cache za jiný, který implementuje požadovaný rozsah.
64
KAPITOLA 6. NÁVRH IMPLEMENTACE
Obrázek 6.5: Diagram tříd, vztahujících se k souvislosti, která je označena červenou. OSP definuje příslušnost souvislosti k oranžovým třídám vybrané úloze, času, místu nebo osobě. Žluté třídy mají podpůrný charakter, obsahují multimediální přílohu souvislosti nebo kontakty osoby.
Každý poskytovatel obsahu rovněž definuje své vlastní metody pro generování fragmentů VoiceXML. V těchto metodách jsou volány metody společných předků VxmlMenuRenderer a VxmlBaseRenderer, kteří definují univerzální metody pro generování často používaných fragmentů VoiceXML.
Obrázek 6.6: Diagram tříd poskytovatelů obsahu. Základní žlutá abstraktní třída slouží jako společný předek poskytovatelů obsahu: výběru úloh, jejich výsledků a souvislostí, kteří jsou oranžoví.
6.5. TŘÍDY POSKYTOVATELŮ
65
Hierarchie těchto základních poskytovatelů je znázorněna na obrázku 6.5.1.
VxmlBaseRenderer definuje metody pro generování výzev uživateli, hlasových a DTMF gramatik. Dále definuje metody pro generování zprávy o chybě a detekce objektů používaných pro ovlivnění tvorby dialogu ze strany aplikace. VxmlMenuRenderer definuje skupinu souvisejících metod pro generování dialogů, ověřujících přístupová práva uživatele, vlastní výběr a přechod do následujícího dialogu.
Obrázek 6.7: Diagram tříd základních poskytovatelů. Růžová třída představuje společného předka pro všechny poskytovatele, kteří interagují s uživatelem pomocí VoiceXML. Oranžové třídy představují takové poskytovatel, kteří však nepracují s obsahem, nýbrž pomocí hlasového dialogu doplňují uživatelský kontext. Žluté třídy představují společné předky poskytovatelů obsahu a využívají třídy vyrovnávací paměti, která je šedá.
66
KAPITOLA 6. NÁVRH IMPLEMENTACE
Obrázek 6.8: Diagram tříd vyrovnávací paměti. Společný abstraktní předek, reprezentovaný růžovou třídou, deklaruje metody, implementované oranžovými potomky. Na obrázku je uveden kontextový poskytovatel autorizace, jehož výstupem je rovněž VoiceXML kód obsahující dialog přihlášení uživatele. Tento dialog může být spuštěn dialogem inicializace nebo při výběru menu či úlohy, k němuž uživatel nemá oprávnění. Poskytovatel inicializace zodpovídá za uvítací dialog a uživatelské potvrzení kontextu.
6.5.2
Poskytovatelé kontextu
Poskytovatelé kontextu se podílejí na vytvoření uživatelského kontextu během inicializace. Uživatelský kontext uchovává informace o identitě, poloze a preferencích uživatele společně s vybranými úlohami. Třída ContextProvider po dobu interakce s uživatelem udržuje v paměti kontext a slouží pro zbytek OSP jako fasáda zjednodušující přístup ke specializovaným poskytovatelům autorizace a polohy, jak je znázorněno na obrázku 6.5.2.3. Rovněž implementuje funkci automatické detekce jazyku interakce na základě mezinárodního formátu telefonního čísla uživatele nebo zjištěné polohy. 6.5.2.1
Poskytovatel nastavení
Poskytovatel nastavení/preferencí zajišťuje životní cyklus preferencí uživatele: 1. Během vytvoření uživatelského kontextu získá od vzdálené služby preference uživatele. Preference obsahují seznam preferovaných jazyků, historii vybraných úloh, zazáložkované úlohy, povolení lokalizace uživatele a další. 2. Během interakce jsou preference upraveny změnou volby jazyka, zazáložkováním či doplněním historie vybraných úloh. 3. Po ukončení interakce jsou změněné preference poslány vzdálené službě. 6.5.2.2
Poskytovatel autorizace
Třídy AuthProvider a LoginProvider vystupují společně jako poskytovatel autorizace. Důvodem jejich oddělení je pravidlo říkající, že jedna třída by měla mít zodpovědnost jen za jednu
6.5. TŘÍDY POSKYTOVATELŮ
67
funkci – třída AuthProvider generuje VoiceXML dialog pro přihlášení uživatele a vložené údaje posílá třídě LoginProvider, implementující komunikaci se vzdálenou autorizační službou včetně aplikace hashovací funkce na heslo a doplnění uživatelského kontextu o přidělené role. Díky komunikace těchto svou tříd skrze servlet není třeba pro validaci přihlašovacích údajů přerušit interakci.
6.5.2.3
Poskytovatel polohy
Poskytovatel polohy při vytvoření uživatelského kontextu a před každým novým výběrem úloh kontaktuje vzdálenou službu a zjistí aktuální polohu uživatele v podobě GPS souřadnic. Poskytovatel komunikuje se službou pomocí protokolu MLP (Mobile Location Protocol), který je průmyslovým standardem pro zjištění polohy mobilního telefonu a klade důraz na ochranu osobních údajů uživatele – je podporováno oprávnění klientské strany pomocí hesla pro dané mobilní číslo. Po obdržení souřadnic je procesem reverzního geokódování zjištěno místo uživatele ve formátu užitečném pro další hledání souvislostí: kód země, název města a místa.
Obrázek 6.9: Diagram tříd poskytovatele uživatelského kontextu, reprezentovaného žlutou třídou. Ten k získání konkrétních informací deleguje specializované poskytovatele, sám jen udržuje kontext v paměti. Dvojice růžových tříd vystupuje jako poskytovatel autorizace. Oranžové třídy představují poskytovatele polohy a nastavení uživatele.
68
6.5.3
KAPITOLA 6. NÁVRH IMPLEMENTACE
Přístup k poskytovatelům
Přístup ke poskytovatelům obsahu a kontextu je realizován skrze fasádu reprezentovanou třídou StateController, uvedené na obrázku 6.5.3. Třída navíc definuje metody pro vytvoření a uzavření uživatelského kontextu, které deleguje na vlastní poskytovatele. Další důležitou funkcí třídy je přístup k lokalizacím dialogů, zajišťujícím specifické funkce OSP jako volba jazyka, autorizace, univerzální povely pro navigaci v nabídce úloh a jejich výsledků, chybové i jiné zprávy. OSP podporuje různé lokalizace, jež jsou zvoleny při vytváření dialogů dle uživatelem preferovaných jazyků. Lokalizace je zcela transparentní, vlastní text je získán voláním statické metody třídy, které je předán identifikátor uživatelského kontextu a identifikátor požadovaného textu. Třída si udržuje ve vyrovnávací paměti načtené lokalizace dialogů. Třída obsahuje logování a zachytávání chyb na nejvyšší úrovni. Je vhodným místem pro studium implementace z důvodu rychlé orientace v poskytovatelích a komentářích.
Obrázek 6.10: Diagram tříd růžové fasády StateController, zapouzdrujíci funkce OSP, reprezentované dílčími poskytovateli obsahu (oranžové třídy) a kontextu (žlutá třída).
6.6. TŘÍDY REGISTRU SLUŽEB
6.6
69
Třídy registru služeb
Registry služeb zajišťují podporu dynamické architektury, popsané v sekci 4.4.
6.6.1
Třídy služeb
Obrázek 6.6.2 obsahuje třídu ServiceCollection, která slouží jako přepravka pro všechny služby poskytující relevantní informace ke spuštěné aplikaci. Každá služba je popsána třídou Service, obsahující název a popis v různých jazycích. Taxonomie služby je vyjádřena jejím typem (viz. 4.3) a množinou podporovaných jazyků, relevantních lokací a funkcí nabízených pro dané předměty. Mezi služby se počítá rovněž specifikace spuštěné aplikace. Každá služba zveřejňuje seznam přístupových bodů, pomocí kterých je možné ji kontaktovat. Přístupový bod má definován svůj typ a hodnotu. OSP rozlišuje typy WSDL a SOAP pro webové služby, HTTP pro RESTové služby, telefonní a SIP číslo pro vlastní aplikace.
6.6.2
Třídy registru
Abstraktní třída ServiceRegister deklaruje metody pro vyhledávání služeb publikování organizací a služeb. Cílem registru služeb OSP je odstínění od specifik použitého registru, který lze vyměnit bez negativních dopadů na zbytek OSP. Implementace UddiRegister využívá registr webových služeb UDDI, popsaný v sekci 3.3.4 a z důvodu snazší údržby implementuje pouze společné metody manipulující s objekty specifickými pro standard UDDI. Vlastní funkce registrace organizací a služeb je implementována ve třídě UddiPublisher, zatímco třída UddiLocator implementuje funkci vyhledávání
70
KAPITOLA 6. NÁVRH IMPLEMENTACE
Obrázek 6.11: Diagram tříd registru služeb. Žluté třídy popisují služby a způsoby jejich kontaktu, zatímco červená abstraktní třída deklaruje metody pro práci s registry služeb. Oranžové třídy představují třídy, implementující přístup k registrům UDDI.
Kapitola 7
Popis implementace OSP vyžaduje implementaci na straně linuxového serveru, podstatná je přenositelnost kódu. Na syntaktické úrovni je důležitá silná typovost. Po stránce vlastního vývoje a životního cyklu OSP je kladen důraz na standardizaci, zpětnou kompatibilitu, dostatek nástrojů pro vývoj, správu a testování softwaru a nabídku knihoven pro speciální účely, jež jsou popsány v následujících sekcích. Jedná se o požadavky zabraňující závislosti na jednom dodavateli a zajišťující snadný další vývoj a přidávání dalších funkcí. Na základě těchto požadavků byla zvolena Java, která serverovým řešením nabízí bohaté možnosti. Vlastní implementace je založena na servletech, které předávají řízení speciálním poskytovatelům, popsaným v sekci 6.5. Komunikace se vzdálenými službami je založena na architektuře SOA, popsané v sekci 3.2. SOA je implementována webovými služebnami z důvodu použití standardů WSDL a UDDI. Z WSDL je možné pomocí specializovaných nástrojů vygenerovat zdrojové kódy tříd v požadovaném programovacím jazyce, a ty použít jako základ pro implementaci vzdálené služby. Obsah souborů WSDL pro různé typy služeb vychází ze softwarové analýzy, představené v kapitole 5. Registr webových služeb UDDI pak slouží jako základ dynamické architektury – webové služby jsou nalezeny a následně kontaktovány dle specifikace aplikace. Registr UDDI podporuje znovupoužitelnost a zaměnitelnost stávajících webových služeb. REST nebyl použit právě z těchto důvodů. Dále se při volání metody webové služby přenáší jako parametr část uživatelského kontextu, jehož serializace pomocí RESTu by byla obtížná. Na obrázku 7 jsou znázorněny jednotlivé vrstvy OSP.
7.1
Škálovatelnost
Škálovatelnost softwaru je schopnost se zvyšující se zátěží udržet stejné výkonnostní parametry. OSP je implementována s použitím klasických tříd a servletů, které mají minimální režii. Stav na úrovni objektů je držen jen poskytovatelem kontextu a vyrovnávací pamětí poskytovatele obsahu. Metody, kontaktující vzdálenou službu, generující VoiceXML [37] a zajišťující podpůrné funkce, získávají stav pomocí návrhového vzoru muší váha, tj. v podobě vstupních parametrů. Implementace tedy umožňuje masivní a bezpečný souběh více vláken. Škálovatelnost je tedy zarušena podporou paralelního zpracování požadavků více klientů. Úzkým hrdlem je práce s kontextem, která je synchronizovaná. Nicméně většina práce s kontextem spočívá ve vracení reference na objekt, uložený v haš-mapě na základě poskytnutého klíče. Výkonově nejnáročnější je kontaktování vzdálené služby a zpracování odpovědi, které se intenzivně provádí po zahájení interakce. 71
72
KAPITOLA 7. POPIS IMPLEMENTACE
VoiceXML OpenSpeechPlatform WSDL
UDDI
Java Servlet API
XML SOAP HTTP TCP/IP Obrázek 7.1: Žlutě jsou označeny standarní protokoly používané na webu, oranžově standardy webových služeb a červeně OSP, generující VoiceXML pomocí Java Servlet API. Odpověď vzdálené služby je uložena do kontextu, přitom je synchronizovaná jen samotná akce vložení do haš-mapy. Podpora vyrovnávací paměti s možností specifikace maximálního stáří výsledného VoiceXML dokumentu výrazně přispívá ke snížení výpočetní zátěže. Vyrovnávací paměť rovněž snižuje nároky na konektivitu serveru, není třeba tak často kontaktovat vzdálenou službu. V případě řádově tisíců paralelně připojených uživatelů dostačuje výkon jednoho stroje. Tento předpoklad je opřen o synchronizaci pouze na nutných místech a použití vyrovnávací paměti. Pokud výkon jednoho stroje při příliš velkém počtu cca stovek tisíc uživatelů nedostačuje, je možné použití clusteru. V takovém případě jsou navrženy dvě strategie pro vyřizování požadavků: 1. Uživateli je v rámci interakce přiřazen jeden stroj z clusteru, který po celou dobu interakce spravuje uživatelský kontext. V případě jeho výpadku musí být interakce restartována. Výběr stroje může být realizovaný pomocí algoritmu Round Robin nebo dle informací o zatížení jednotlivých strojů v clusteru. 2. Uživatel během interakce komunikuje s různými stroji v clusteru. Toto řešení je odolné vůči výpadkům, avšak požaduje replikaci kontextu a vyrovnávací paměti mezi jednotlivými stroji. Toho lze dosáhnout použitím nástrojů pro replikaci heap virtuálního stroje Javy za běhu [14].
7.2. MODULARITA
7.2
73
Modularita
OSP podporuje modularitu na úrovni standardizovaného rozhraní vzdálených služeb (viz. sekce 4.3). V případě ekvivalentní taxonomie služeb je možná jejich zaměnitelnost, jak je uvedeno v sekci 4.4. Vlastní implementace OSP podporuje modularitu hierarchií dědičnosti, kdy společní předci deklarují abstraktní metody, které potomci musí implementovat dle konkrétní funkcionality. Jedná se o nahrazení konvence implementace proti rozhraní, neboť potomci vyžadují přístup k rodičovským metodám pro generování obecných fragmentů VoiceXML. Pro získání reference na objekt konkrétního potomka slouží tovární metody.
7.3
Registr UDDI
Registr služeb OSP je obecné rozhraní podporující taxonomii služeb, jejich publikaci a vyhledávání. Tyto funkce jsou delegovány na skutečný registr standardu UDDI, popsaného v sekci 3.3.4. Byla vybrána implementace jUDDI od Apache Software Foundation, šířená pod The Apache Software License, Version 2.0 [33]. jUDDI představuje implementaci serverové i klientské části včetně jednoduchého webového rozhraní. Výhodou knihovny jUDDI je aktivní vývoj a výborná dokumentace. Klientskou funkcionalitu zajišťuje podpora vlastního i JAXR rozhraní pro publikaci a dotazování. K publikaci webové služby lze rovněž využít anotace, kterými se doplní metoda služby. jUDDI je rovněž použita v produktu IBM FileNet P8 pro online správu dokumentů [8]. jUDDI je podporována systémem JaxView pro správu SOA [17]. Nevýhodou je slabší webové rozhraní, které nepodporuje publikování a pro dotaz je třena napsat vlastní SOAP požadavek ve webovém formuláři. OSP dokáže publikovat vlastní TModely, zajišťující na úrovni UDDI taxonomii, i organizaci RDC, která je zatím považována za provozovatele všech publikovaných služeb. Střednědobým cílem je zpřístupnit registr služeb vývojovému prostředí laboratoře RDC, které je otevřeno pro technologické partnery a podporuje autorizaci. V tom případě by byla nová služba při publikaci přiřazena organizaci, jejímž členem je autor. Publikování služeb se zatím provádí pomocí provizorního formuláře, uvedeného na obrázku 7.3.
7.4
Generování VoiceXML
OSP využívá pro generování VoiceXML [37] kódu knihovny Element Construction Kit, vyvinutou pány Stephanem Nagym a Jonem S. Stevensnem v rámci projektu The Apache Jakarta Project ke generování HTML a XML dokumentů [32]. Oproti jiným knihovnám pro generování HTML jako Struts nebo JSF jsou elementy konstruovány pomocí objektů a jejich atributy nastavovány pomocí volání metod setXZY. Je použita konvence, kdy každá setXZY metoda vrací referenci na objekt, nad nímž je vykonána. Tato konvence umožňuje elegantní řetězení většího počtu metod. Výsledný dokument je možné snadno serializovat do podoby textového řetězce. Výhodou knihovny ECS je ovlivnění tvorby dokumentu přímo z kódu Javy v měřítky vyšším než u např. u knihoven JSF nebo Struts. Serializovaný dokument lze snadno uložit do vyrovnávací paměti a při opakované žádosti prostě předat servletu k zaslání klientovi. Element Construction Kit rovněž obsahuje podporu pro VoiceXML 1.0 implementovanou paní Carol Jones ze společnosti IBM. Bohužel se jedná o velmi starou verzi, v níž navíc chybí elementy pro tvorbu gramatik. Proto byla původní implementace aktualizována na kompletní podporu celého standardu VoiceXML 2.1, do dokumentace k jednotlivým elementům byly vloženy odkazy na relevantní online dokumentaci dodavatelů hlasových systémů Voxeo [36], Tellme [31] a
74
KAPITOLA 7. POPIS IMPLEMENTACE
Obrázek 7.2: Webový formulář pro publikování služby. Rozhraní v budoucnu umožní přidávat libovolný počet jmen, popisů, přístupových bodů a objektů. Klíčová slova taxonomie je možné oddělit čárkou, mezerou nebo novým řádkem. Nuance [23]. Rovněž byla doplněna typovost těch atributů, jejichž formát musí splňovat jisté konvence. Níže je uveden příklad kódu generujícího v OSP výzvu pro hlasový výběr v menu, dostupné volby jsou přitom vyjmenovány: 01 protected VxmlElement createSelectionVoicePrompt (final Locale locale, final List items) { 02 03 final String text = StateController .getLocalizedMessage(locale, "menu.select.prompt"); 04 final Prompt prompt = new Prompt(text).setLang(locale).setBargeIn(true); 05 for (Integer i = 0; i < items.size(); i++) { 06 final GrammarItem item = items.get(i); 07 prompt.addElement(item.getName()); 08 prompt.addElement(new Break(Break.Strength.WEAK)); 09 if (items.size() > 1 && i == items.size() - 2) { 10 prompt.addElement(StateController .getLocalizedMessage(locale, "menu.select.or")); 12 } 13 } 14 return prompt; 15 }
7.5. GENEROVÁNÍ ECMASCRIPTU
75
Na řádce 01 je signatura metody definující parametry jazyku výběru a seznam položek výběru. Na řádce 03 je do proměnné text uložena lokalizovaná výzva k výběru z dostupné nabídky. Na řádku 03 je vytvořen element prompt s výzvou v daném jazyce a možností přerušení v momentě volby uživatele. Smyčka na řádcích 05 až 13 prochází položkami výběru, název každé z nich přidá do výzvy. Z důvodu přirozeně znějící výzvy následuje po zmínění každé položky slabá pauza, v případě předposlední položky pak spojka nebo v příslušném jazyce.
7.5
Generování ECMAScriptu
Vlastní kód VoiceXML je možné doplnit ECMAScriptem [5], který je rovněž interpretovaný VoiceBrowserem. VoiceXML obsahuje elementy pro skriptování a podmíněného řízení dialogu. Díky tomu je možné jednoduchou logiku vykonávat za běhu na základě informací poskytnutých uživatelem, které v době generování VoiceXML nebyly známé. Toho OSP využívá např. při řízení přístupu ke chráněným úlohám, kdy po přihlášení uživatel pokračuje v předchozí interakci s původním VoiceXML dokumentem, aniž by bylo třeba jej aktualizovat. Pro generování ECMAScriptu není použita žádná knihovna. VoiceXML obsahuje definice funkcí, které jsou použity v celém v dokumentu k řízení dialogů. Přístupem, opírající se o prosté textové řetězce by však došlo ke ztrátě typové kontroly, a následné chyby by byly odhaleny až při testování dialogů. Proto je volání těchto funkcí ve VoiceXML generováno pomocí statických metod, které vygenerují textovou konstantu představující název funkce společně s případnými parametry, jejich identifikátory přijímá metoda jako své vlastní parametry. Těmito parametry jsou ECMAScript proměnné, jejichž názvy jsou opět konstantami. Následující výpis obsahuje životní cyklus funkce pro uložení naposledy navštíveného menu/dialogu do paměti historie: 01 public static final String FN_PUSH_LAST_FORM = "pushLastForm"; ... 10 private VxmlElement createScript() { 11 final StringBuilder stringBuilder = new StringBuilder(); ... 20 stringBuilder.append("function " + FN_PUSH_LAST_FORM + "(last) {"); 21 stringBuilder.append(" var index = last_forms.size();"); 22 stringBuilder.append(" last_forms[index] = last;"); 23 stringBuilder.append("}"); ... 28 return new Script(stringBuilder.toString()); 29 } ... 40 public static final String FN_PUSH_LAST_FORM(final String form) { 41 return FN_PUSH_LAST_FORM + "(’" + form + "’);"; 42 } ... 70 private VxmlElement createConfirmFilled(final Menu activeMenu) { 71 final Filled filled = new Filled(); ... 75 filled.addElement(new Script(FN_PUSH_LAST_FORM(activeMenu.getId()))); ... 78 return filled; 79 }
76
KAPITOLA 7. POPIS IMPLEMENTACE
Na řádce 01 je deklarována konstanta názvu funkce FN_PUSH_LAST_FORM. Definice ECMAScript kódu těla funkce je generována metodou createScript na řádcích 10 až 29. Pro generování volání funkce v kódu VoiceXML se používá statická metoda definovaná na řádcích 40 až 42, jmenující se stejně jako konstanta názvu. Tato metoda přijímá textový řetězec parametru funkce a generuje volání funkce včetně parametru a ukončení středníkem. Použitá metoda generování volání funkce je demonstrována na příkladu metody createConfirmFilled na řádcích 70 až 79. Názvy funkcí začínají prefixem FN, názvy proměnných VAR a konstanty identifikátorů OSP. Metody generující volání funkcí jako např.FN_PUSH_LAST_FORM záměrně porušují konvence pojmenování metod v Javě, aby se odlišily od ostatních metod, jež nesouvisí s generováním ECMAScriptu.
7.6
Hašovací algoritmy
Heslo, zadané uživatelem během dialogu přihlášení, je zasláno společně s uživatelským kontextem vzdálené autorizační službě pro ověření identity uživatele. Je nebezpečné přenášet nechráněné heslo po jakékoliv sítí, tím méně pak po Internetu. Samozřejmě lze dostatečné zabezpečení zajistit šifrováním na úrovni přenosového protokolu HTTP s využitím SSL nebo TLS. Nicméně šifrování je pomalé a druhou stranou nemusí být podporované. Z toho důvodu odesílá OSP službě jen otisk hesla dle příslušného hašovacího algoritmu – MD5 a SHA-256. Algoritmus MD5 je rozšířený a všeobecně používaný, avšak byl již prolomen, a proto jej nelze považovat za příliš bezpečný. Algoritmus SHA-256 je pro účely OSP dostačující. Následující výpis uvádí použití hašovacích funkcí v poskytovateli autorizace:
private synchronized String getHash(final String pin) { String hashedPin; if (this.digest == null) { hashedPin = pin; } else { this.digest.reset(); this.digest.update(pin.getBytes()); final BigInteger hash = new BigInteger(1, this.digest.digest()); final StringBuffer buffer = new StringBuffer(hash.toString(16)); while (buffer.length() < 32) { buffer.insert(0, "0"); //MD5 workaround } hashedPin = buffer.toString(); } return hashedPin; }
Konstruktor třídy se nejprve pokusí získat algoritmus SHA-256, implementovaný v knihovnách platformy Java. V případě selhání se pokusí získat algoritmus MD5. Pokud selže i tento pokus, nebude na heslo použita žádná hašovací funkce. V případě úspěchu je implementace uložena do proměnné digest a do proměnné hashAlgorithm je uložena informace o získaném algoritmu. Java obsahuje velké množství různých hašovacích algoritmů, mj. různé verze SHA [15]. Bylo by rovněž možné postupně zkoušet varianty SHA-224, SHA-256, SHA-384, SHA-512 . . . Varianta SHA-1 je se svou délkou 160 bitů zhruba na úrovni MD5. Vlastní použití hašovacího algoritmu probíhá v synchronizované metodě getHash, která rovněž implementuje převod výsledku do hexadecimálního formátu. Popsaný kód lze snadno doplnit o podporu dalších algoritmů, např. konfiguračním souborem s prioritním seznamem algoritmů, jejichž dostupnost by se ověřovala v cyklu.
7.7
Zpracování MLP
Mobile Location Protocol (MLP) je standard navržený organizací Open Mobile Alliance a používaný mobilními operátory ke zjištění polohy mobilního telefonu [25]. MLP syntakticky vychází z XML a komunikace mezi klientem a serverem probíhá pomocí protokolu HTTP. Klient specifikuje telefonní číslo, o jehož polohu má zájem. Důraz je kladen na ochranu osobních údajů uživatelů – svou identitu klient prokáže uvedením svého identifikátoru a hesla. Dále je pro každé dotazované telefonní číslo třeba uvést tzv. klíčové slovo, kterým klient prokáže své oprávnění získat polohu uživatele. Celou komunikaci je možné zabezpečit pomocí SSL či TLS. Odpovědí je GPS poloha s definovanou přesností a časem zjištění, jak ukazuje výpis níže:
Laboratoř RDC v současné době disponuje experimentálním propojením s mobilní sítí operátora Vodafone, díky kterému je možné získat GPS polohu základnové stanice, s níž je mobilní telefon ve spojení [26]. Nevýhodou tohoto řešení je podpora pouze operátora Vodafone a přesnost zhruba 100 až 200 metrů. Výhodou je možnost zjištění přibližné polohy bez nutnosti cokoliv stahovat a konfigurovat na mobilním telefonu uživatele. Alternativním řešením je vyvinout vlastní software nebo použít stávající, který po spuštění uživatelem na mobilním telefonu zjistí polohu pomocí GPS a odešle ji na server, z něhož bude načtena právě pomocí MLP. Řešení založené na MLP je zcela univerzální, neboť definuje pouze formát výměny dat, která mohou pocházet z různých zdrojů. OSP vystupuje jako MLP klient, který požádá službu nalezenou v registru o polohu uživatele. Vlastní způsob zjištění polohy je tak ponechán na autorech aplikací služeb. V rámci RDC paralelně s vývojem OSP probíhá práce na multimediálním softwaru pro mobilní telefon, který hlasovou interakci uskutečňuje pomocí internetové telefonie (protokol SIP), zjišťuje polohu, odesílá ji na server a podporuje rovněž vizuální interakci s uživatelem. Požadavek MLP je generován pomocí knihovny Element Construction Set (ECS), popsané v sekci 7.4. V rámci vývoje OSP byla do ECS doplněna částečná podpora pro MLP. Výsledný požadavek je poté serializován do textové podoby a zaslán MLP serveru, nalezeném pomocí registru služeb. K tomuto účelu byla použita knihovna Apache HttpComponents, která obsahuje mj. implementaci HTTP klienta s podporou šifrování a HTTP autentizací. Odpověď serveru je analyzována pomocí rozhraní DOM, které je standardně obsaženo v Javě jako součást Java API for XML processing.
7.8. REVERZNÍ GEOCODING
7.8
79
Reverzní geocoding
Geocoding označuje techniku převodu adresy na GPS souřadnici. Reverzní geocoding označuje převod GPS souřadnice na adresu s danou přesností (země, město, čtvrť, ulice). Obě techniky se opírají o geografickou databázi zpřístupněnou pomocí rozhraní [39]. OSP používá reverzní geocoding ke zjištění místa, na němž se uživatel nachází. Na základě toho lze uživateli nabídnout vhodný jazyk interakce a služby specifické pro dané místo. OSP k tomuto účelu používá službu GeoNames.org, jež funguje na komunitním principu. Databáze a kód klientů pro mnoho programovacích jazyků jsou šířeny pod Creative Commons Attributions Licence. Je možné se připojit ke komunitě a lepšit kvalitu databáze zasláním souřadnicových podkladů. Následující výpis uvádí, jak OSP přistupuje k reverznímu geocodingu pomocí GeoNames.org:
01 private Address gpsToAddress (final Double lattitude, final Double longitude) throws LocationException { 02 try { 03 final PostalCodeSearchCriteria criteria = new PostalCodeSearchCriteria(); 04 criteria.setLatitude(lattitude); 05 criteria.setLongitude(longitude); 06 criteria.setMaxRows(1); 07 final List found = WebService.findNearbyPostalCodes(criteria); 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 }
final Address address = new Address(); if (!found.isEmpty()) { final PostalCode postal = found.get(0); address.setCountry(postal.getCountryCode()); address.setCity(postal.getAdminName1()); address.setPlace(postal.getPlaceName()); } return address; } catch (InvalidParameterException invalidException) { throw new LocationException( "Bad location for reverse geocoding", invalidException); } catch (Exception genericException) { throw new LocationException( "Could not find nearby postal codes", genericException); }
Na řádcích 03 až 06 jsou specifikována kritéria hledání, která jsou na řádku 07 předána vyhledávací metodě. Služba zpřístupňuje řadu metod pro hledání blízkých objektů zadané kategorie, počasí nebo článků na Wikipedii, vztahujících se k danému místu. V našem případě se jedná o jednoduchou metodu vracející mj. kód země dle standardu ISO 3166-1, název města a místa, z nichž je na řádcích 11 až 13 vytvořena adresa, popisující polohu uživatele.
80
KAPITOLA 7. POPIS IMPLEMENTACE
Pro souřadnice v USA je možné získat rovněž blízké ulice. Pro Evropu je tato funkce bohužel placená. Její potenciál by se projevil ve spojení s technologií MLP, vracející polohu základnové stanice mobilního přijímače. Popis MLP je náplní předchozí sekce. Takto získaná poloha je dosti nepřesná, avšak s použitím služby GeoNames.org by šlo zjistit blízké ulice a z nich nechat uživatele vybrat během inicializačního dialogu. Tímto způsobem by se přesnost určení polohy výrazně zvýšila. Služba má velký potenciál právě díky své možnosti získání blízkých objektů různých tříd, a proto by se jí měla věnovat další pozornost. Nevýhodou je chudší databáze pro ČR, kterou by však bylo možné doplnit. Alternativou jsou Google Maps, které však postrádají komunitní charakter a možnost hledání objektů dle tříd.
7.9
Kvalita kódu
Implementace OSP klade důraz na další vývoj a přidávání nových funkcí. Z toho důvodu se návrh všech tříd řídí pravidlem jedné zodpovědnosti na jednu třídu, metody jsou krátké, o délce cca 10 až 20 řádků. Některé úzce zaměřené metody mají méně než 10 řádků. Některé metody mají až 30 i více řádků, což je však způsobeno generováním VoiceXML kódu nebo prací s rozhraním UDDI. Tyto metody neobsahují výkonný kód, nýbrž vytváření jednoduchých objektů a nastavování jejich vlastností. Navíc rozhraní UDDI je poněkud těžkopádné, nevyužívá např. přetížení konstruktorů. téměř všechny metody mají nejvýše tři parametry, což zjednodušuje jejich používání. Velký důraz je kladen na dokumentaci – všechny metody a konstanty jsou pečlivě zdokumentovány včetně tech privátních. Kód byl rovněž zkontrolován nástrojem pro statickou analýzu PMD a nalezené problémy byly odstraněny [27].
Kapitola 8
Hlasová navigace pro MHD Tato kapitola popisuje návrh a implementaci asistivní aplikace založené na OpenSpeechPlatform, která je popsána v kapitole 4. Aplikace cílí primárně na slabozraké a nevidomé uživatele. Cílem je usnadnit těmto uživatelům navigaci v městské hromadné dopravě. Současná implementace slouží jako proof-of-concept pro ověření dalšího možného směrování projektu.
8.1
Uživatelský scénář
Cílem aplikace je pomoci zrakově postiženým s orientací v hromadné dopravě za použití mobilního telefonu. Uživatel si přeje dopravit se do cílově stanice. Důraz je kladen na určení nástupní stanice a pěší přesun k ní – uživatel se může nacházet v neznámém prostředí nebo být dezorientován. Aplikace proto na základě polohy uživatele určí nejbližší stanice, z nichž si uživatel vybere. Uživatel samozřejmě může doporučení ignorovat a zadat jinou nástupní stanici. K vybrané stanici je poté uživatel naveden pěšky pomocí hlasových instrukcí. Aplikace dále zjistí možné plány spojení z nástupní do cílové stanice, které uživateli sdělí. Uživatelský scénář je znázorněn na obrázku 8.1. V současné době je podporována pouze Praha. I. Výběr nástupní zastávky
Cíl
II. Navigace
Zastávka 1
120m
?
100m
Zastávka 2
80m
Zastávka 3
Pěší navigace
Dopravní navigace
Obrázek 8.1: Schéma uživatelského použití. V prvním kroku je detekována uživatelova poloha a jsou mu nabídnuty blízké stanice dle eukleidovské vzdálenosti. Uživatel zadá vybranou nástupní a výstupní stanici. Ve druhém kroku je uživatel nejprve hlasově naveden do nástupní stanice a poté je mu sděleno několik navržených plánů spojení, včetně přestupů.
81
82
8.2
KAPITOLA 8. HLASOVÁ NAVIGACE PRO MHD
Architektura
Aplikace využívá architekturu klient–server. Klientem je mobilní telefon, který slouží pouze jako terminál odesílající a přijímající data. Vlastní logika aplikace je umístěna na serveru a využívá OpenSpeechPlatform (viz. kapitola 4) pro tvorbu a řízení hlasových dialogů. Aplikace k interakci s uživatelem využívá rozpoznávání a syntézu českého jazyka, vyvinuté na ZČU v Plzni [16]. Pěší navigace je založena na Google Maps [7], dopravní spojení je získáno z webového plánovače Dopravního podniku hlavního města Prahy [4]. Přístup k oběma webovým zdrojům je realizován pomocí služby WebProxy [35], vyvinuté v RDC [28]. Informace získané z WebProxy jsou v XML formátu. Architektura je znázorněna na obrázku 8.2. Uživatelský scénář OSP výběru úlohy je realizován výběrem nástupní a výstupní zastávky, prezentovanými výsledky jsou nalezené plány spojení a popis pěší cesty k nástupní zastávce. Scénář hledání souvislostí není použit, plánované použití spočívá v přístupu např. k emailu či kalendáři uživatele pro hledání schůzek, vztahujících se k určité lokalitě nebo času. Ke zjištění polohy uživatele je použit přijímač GPS, zabudovaný do mobilního telefonu. Technologie GPS vyžaduje softwarového klienta, který po spuštění uživatelem zjistí polohu s přesností na jednotky metrů a vyvolá odchozí hovor k vlastní hlasové aplikaci. Alternativní použití technologie SS7Tracker by nevyžadovalo žádnou podporu na straně klienta, avšak umožňuje zjistit pouze polohu základnové stanice, se kterou mobilní telefon komunikuje. Jedná se tedy o přesnost v řádu stovek metrů, s jejímž využitím není možné pěší navigaci použít. Lokalizace blízkých zastávek je realizována servletem, jenž provede parametrizovaný dotaz nad databází. Data s GPS souřadnicemi jsou importována z externího zdroje (viz. sekce 8.4.2). Bylo by tedy teoreticky možné dotázat se přímo zdroje. Data jsou poskytována v XML formátu – tedy by bylo třeba při každém uživatelově požadavku stáhnout necelých 800 kB dat, provést parsování, normalizaci a nad všemi instancemi nakonec provést náročný výpočet eukleidovské vzdálenosti. Z důvodu úspor bylo proto rozhodnuto použít relační databázi jako určitou formu vyrovnávací paměti, která obsahuje již načtená data a vlastní výpočet je realizován během několika stovek milisekund. RDC Vodafone
OpenSpeechPlatform WebProxy
Google Maps
Voice Browser
Internet ZČU Rozpoznávání
Dopravní podnik
Poi.cz
Syntéza
Obrázek 8.2: Architektura aplikace zobrazuje mobilní telefon, jenž ke klientským zařízením přistupujícím k serveru RDC. Na něm je nasazena OpenSpeechPlatform, která tvoří dialogy hlasové interakce v jazyce VoiceXML, jež interpretuje VoiceBrowser. Vlastní rozpoznávání a syntéze je zajištěna servery na ZČU. Plány spojení jsou získány ze stránek dopravního podniku, popis pěší cesty k nástupní zastávce z Google Maps. Přístup k těmto webových zdrojům je realizován pomocí služby WebProxy. Databáze zastávek je získána ze serveru http://poi.cz.
8.3. PŘÍBUZNÉ PROJEKTY
8.3
83
Příbuzné projekty
Výše nastíněný problém se v minulosti pokoušely vyřešit různé projekty. Tato sekce popisuje a porovává projekty realizované v rámci iniciativy IBM CVUT Student Research Projects, založené na úzké spolupráci studentů ČVUT FEL s odborníky společnosti IBM za účelem vývoje a výzkumu pokročilých technologií.
8.3.1
Point-of-Interest GPS Tracker
Projekt implementuje lokalizaci blízkých bodů zájmu (POI) na mapě, zobrazené na mobilním telefonu. Dokumentace je dostupná na http://ibm-cvut.felk.cvut.cz/~2009/projekt1/. Hlavní výhody a zápory projektu oproti MHD/OSP: - Projekt je nasazen na klientském zařízení s OS Android. MHD/OSP bude nasazen na serverech RDC, k lokalizaci polohy bude využit softwarový klient pro mobilní zařízení. - Projekt je uzavřený, bez možnosti přidávat nové POI. Naopak MHD/OSP bude spíše komunitní – uživatelé budou moci pokrývat zajímavými POI svá města a obce. - Projekt postrádá plán přepravy do cílového POI. Naopak myšlenka MHD/OSP spočívá v doporučení přepravy: pěšky na stanici → MHD → pěšky k cíli. Koncept MHD/OSP tedy je v tomto ohledu zcela unikátní. N/A Projekt využívá GUI, MHD/OSP využívá hlas. + Projekt podporuje fulltext vyhledávání. Na to by MHD/OSP potřeboval rozpoznávání přirozené řeči. + Projekt dokáže přejít na WWW stránky vybraného POI, avšak tato funkce je mimo rámec MHD/OSP. Samotná myšlenka blízkých POI, založených na uživatelově poloze, je shodná. Projekt dokáže zavolat na číslo zvoleného POI, což by bylo možné v MHD/OSP s využitím CCXML rovněž implementovat. OSP oproti projektu nabízí využití hlasu a integraci jednotlivých internetových služeb (lokalizace POI, pěší navigace, plány MHD).
8.3.2
Public Transportation Timetables
Projekt realizovaný na architektuře klient–server se skládá z klienta, jenž dle uživatelovy GPS polohy stáhne ze serveru jízdní řády blízkých zastávek. Dokumentace je dostupná na adrese http://ibm-cvut.felk.cvut.cz/~apmpws08/projekt1/. Hlavní výhody a zápory projektu oproti MHD/OSP: - Server projektu stahuje na požádání jízdní řády. MHD/OSP stahuje plán spojení a způsob pěšího přesunu ke stanici. V případě projektu se jedná dle autorů o stovky kB, v případě MHD/OSP o necelých 100 kB. Klient projektu stahuje ze serveru dle autorů jednotky kB až desítky kB. Klient OSP posílá na server data v řádu stovek B (prostý požadavek HTTP POST), odpověď serveru je ještě kratší (stavový kód operace nastavení polohy uživatele). - Projekt informuje o všech linkách zastávky bez ohledu na uživatelovu potřebu. Chybí plánovač spojení do zvolené destinace. OSP využívá plánovač spojení MHD.
84
KAPITOLA 8. HLASOVÁ NAVIGACE PRO MHD
- Projekt se nezabývá hledáním blízkých POI dle uživatelských kritérií. N/A Projekt navádí uživatele pomocí GUI. MHD/OSP pomocí hlasu. V obou případech jsou použity Google Maps. + Jízdní řády projektu jsou importovány ze stránek http://jizdnirady.idnes.cz, zpracovány a uloženy do vyrovnávací paměti. Uvedené stránky poskytují jízdní řády pro celou ČR, avšak je třeba vyřešit časté přečíslování stanic. MHD/OSP data získává seznamy zastávek a plány spojení přímo ze stránek Dopravního podniku hlavního města Prahy s využitím WebProxy – v RDC vyvinuté službě pro snadnou extrakci dat z WWW stránek s podporou vyrovnávací paměti. + Projekt dokáže poslat SMS zprávu pro zakoupení jízdenky. Tuto funkci je možné do klienta MHD/OSP rovněž implementovat. Klient projektu je implementován v mobilní verzi Javy stejně jako vyvíjený klient MHD/OSP. Projekt komunikuje s uživatelem pomocí klienta, zatímco MHD/OSP pomocí hlasu.
8.4
Import zastávek MHD
K fungování aplikace je třeba znát názvy všech zastávek na území Prahy, jejich GPS souřadnice a číselné kódy, které jsou požadovány plánovačem spojení. Výsledná gramatika, čítající necelých 1200 zastávek, je tak největší dosud použitou gramatikou v rámci RDC. Aplikace využívá poloautomatických nástrojů pro import zastávek – po spuštění správcem provedou automatické načtení všech požadovaných informací z internetu. Plánovaná automatická detekce změny informací (zejména kódů zastávek) bude realizována v rámci OSP.
8.4.1
Načtení názvů a kódů
Z webu Dopravního podniku jsou načteny HTML stránky s názvy zastávek a ty získány pomocí regulárních výrazů. Bohužel neexistuje žádný volně dostupný seznam kódů zastávek, a proto bylo jejich získání realizováno pomocí reverzního inženýrství z webového plánovače Dopravního podniku. Použitý algoritmus je založen na postupném dotazování pro různé kódy. Z výsledku hledání je poté extrahován název vlastní stanice a provedena kontrola, zda je přítomen v seznamu stanic na území Prahy. Důvodem je možnost hledání spojení i do destinací mimo Prahu. Číslování zastávek se mění zhruba každé dva týdny a je patrně způsobeno přidáváním nových stanic, neboť kódy odpovídají abecednímu pořadí stanic. Načtené názvy tvoří gramatiku pro hlasový vstup uživatele. Množina dvojic název–kód tvoří konfiguraci WebProxy, jenž definuje dotaz na plánovač spojení Dopravního podniku.
8.4.2
Načtení GPS souřadnic
Souřadnice zastávek jsou získány z webu http://poi.cz/ v podobě samostatných XML souborů pro různé dopravní prostředky. Data jsou volně k dispozici v mnoha kategoriích a s početnou komunitou. Data jsou stažena, normalizována a transformována pomocí XSLT do SQL. Normalizace obnáší sloučení zastávek téhož názvu pro různé prostředky a převedení do 3. normální formy návrhu databáze. DML příkazy ve formátu SQL jsou poté vykonány nad databází.
8.5. INTERAKCE S UŽIVATELEM
8.5
85
Interakce s uživatelem
Vlastní hlasová aplikace, která obsahuje logiku a interakci s uživatelem, je generována OpenSpeechPlatform do jazyka VoiceXML a vykonávána aplikačním serverem IBM WebSphere VoiceServer. Aplikace představuje stavový automat – přechody mezi stavy jsou definovány gramatikou a výstupy textem k syntéze. Jsou použity gramatiky pro hlasovou i tónovou volbu pokrývající množinu stanic MHD, uživatelské volby a potvrzení volby. Hlavní funkce syntézy spočívá v seznámení uživatele s cestou k nástupní zastávce a dopravním spojením. Tyto informace jsou získány aplikační logikou od poskytovatelů dat. Dne 26. listopadu proběhla prezentace aplikace před Poradním sborem Nadace Vodafone, které se účastnili rovněž dva nevidomí uživatelé. Oba byli aplikací nadšeni a zároveň poskytli řadu užitečných rad a nápadů na vylepšení, které byly zaneseny do systému správy požadavků a budou realizovány v rámci dalšího vývoje MHD/OSP.
8.6
Navržené testování
Hlasová navigace pro MHD neprošla testy použitelnosti z důvodu náročnosti přípravy takového testu. Je třeba zapojení různých skupin uživatelů a objektivní posouzení výsledků. Nicméně tato sekce uvádí návrh testů.
8.6.1
Metodika testu
Základem je výběr uživatelů, rozdělených do tří skupin dle zkušeností: Velmi zkušení uživatelé, kteří již intenzivně pracují s hlasovými aplikacemi nebo je sami vyvíjejí. Možnými kandidáty jsou členové laboratoře RDC, znalí jazyka VoiceXML. Středně zkušení uživatelé, kteří mají zkušenosti s hlasovými aplikacemi. V této skupině by měli být zastoupeni nevidomí uživatelé, kteří používají hlasové asistivní technologie. Nezkušení uživatelé, kteří se setkali např. s telefonními aplikacemi operátorů,založenými na tónové volbě. Tito uživatelé nemají zkušenosti s rozpoznáváním ani syntézou řeči. Zatímco prostředím pro 1. a 2. skupinu bude např. odpočinková místnost v RDC, osoby 3. skupiny je vodné navštívit u nich doma. Důvodem je realizace testu ve známém prostředí. Jediným nutným technickým vybavením bude mobilní telefon pro uskutečnění vlastního hovoru a papír s tužkou pro poznámky a vyplnění dotazníku. Uživatelský test bude probíhat dle harmonogramu: Počáteční pohovor s uživatelem – popis aplikace a průběhu testu. Vlastní úloha – zjištění spoje do uživatelem zvolené netriviální destinace, tj. alespoň s jedním přestupem. V případě skupin 1, 2 a poloviny skupiny 3 bude uživatel ponechán o samotě, v případě zbytku skupiny 3 pod dohledem. Důvodem u skupin 1 a 2 je potlačit rušivé pozorování, uživatelé jsou technicky dost zdatní, aby své názory srozumitelně sdělili. V případě skupiny 3 bude rozdělením dosaženo kompromisu mezi ponecháním větší volnosti uživatelům a přesnějším zachycením všech informací, problémů a výrazů tváře.
86
KAPITOLA 8. HLASOVÁ NAVIGACE PRO MHD
Vyplnění dotazníku s otázkami na spokojenost s rozpoznáváním a instrukcí k přepravě (viz. příloha A). Výsledky dotazníku budu bodově ohodnoceny: odpověď ano ohodnocena 5 body, spíše ano 4 body, nevím 3 body, spíše ne 2 body, ne 1 bodem. Uživatelé pod dohledem budou označeni. Výsledky budou zpracovány formou tabulky se střední hodnotou a odchylkou. Závěrečná diskuse s uživateli představuje prostor pro názory a nápady na vylepšení.
8.6.2
Hypotézy
Současná verze aplikace je plně funkční proof-of-concept. Technická realizovatelnost byla dokázána, je třeba se zaměřit na přístupnost a kvalitu samotného uživatelského rozhraní. Expertní analýza identifikovala následující hypotézy: 1. Rozsáhlá gramatika představuje problém s úspěšností rozpoznávání. Situace je zkomplikována navíc tím, že rozpoznávač češtiny nepodporuje N-Best-List. To znamená, že z rozpoznávače je navrácen vždy jen jeden výsledek. Nelze tak bohužel použít časté řešení práce s rozsáhlými gramatikami, kdy je z rozpoznávače vyžádáno několik nejpravděpodobnějších (N-Best) kandidátů, mezi kterými si pak uživatel vybere typicky pomocí tónové volby. Hypotézou je průměrné hodnocení otázky 2 méně než 3,5 body. 2. Aplikace je určena pro běžné ovládání na ulici. Jsou proto kladeny nároky na jasné a přehledné ovládání a snadnou orientaci v navrácených výsledcích (cesta ke stanici, plán spojení). Zejména plán spojení zahrne uživatele množstvím informací, které není naráz snadné pochopit. Hypotézou je proto hodnocení otázek 5 a 6 méně než 3.75 body.
8.7
Závěr
Tato kapitola popisuje návrh, implementaci a budoucnost Hlasové navigace pro MHD. Navržená architektura byla kompletně realizována s výjimkou klienta pro mobilní verzi Javy, který je nyní jen částečně funkční. Avšak rozhraní pro komunikaci klienta se serverem je plně funkční a dostupné k testovacím účelům na webové stránce http://bolek.feld.cvut.cz/MHD/location. jsp. Informace, zadané na stránce, jsou odeslány na server ve formátu používaném klientem. GPS polohu lze zadat ve formátu stupňů, minut a sekund, například zkopírováním ze serveru http://mapy.cz/. Další vývoj bude silně ovlivněn vývojem OSP. Dlouhodobým cílem je nabídnout navigaci ke konkrétním bodům zájmu – jak uživatelsky definovaným (např. domov, práce, oblíbené restaurace), tak obecným pro různé lokality (např. restaurace v Ostravě, úřady v Plzni, památky v Brně). Zajímavá by mohla být rovněž integrace s některými internetovými službami, např. kalendářem nebo emailem, které často obsahují informace o plánovaných schůzkách. Aplikace Hlasová navigace pro MHD je perspektivní a mnohým postiženým uživatelům může usnadnit život. Přestože je primárně určena pro slabozraké a nevidomé uživatele, mohly by jí rovněž využít další postižené osoby s horší orientací v prostoru (např. mentálně postižení) nebo senioři, pro něž by hlasová interakce mohla být přístupnější než ostatní techniky uživatelské interakce.
Kapitola 9
Závěr a další vývoj Tato diplomová práce obsahuje návrh architektury, navazující analýzu v UML a popis výsledné implementace OpenSpeechPlatform (OSP). Servisně orientovaná architektura, založená na distribuovatelnosti a modularitě založené na webových službách, přestavuje klíčový prvek pro všestranné použití OSP jako základu různých aplikací, při jejichž vývoji nehrají roli vzdálenosti ani použité programovací jazyky (viz. sekce 4.3). Prvek registru služeb, které společně tvoří funkci dané aplikace, je krokem směrem ke cloud computingu, v němž lze dílčí problémy delegovat do vzdálených sítí a v případě výpadku je nahrazovat. Registr obsahuje katalog služeb a popis různých způsobů jejich kontaktu. Nahraditelnost jednotlivých služeb, poskytujících ekvivalentní obsah, je realizována zavedením taxonomie. OSP nabízí snadnou tvorbu hlasových aplikací bez nutnosti znát specifika jejich vývoje. Vývojář se díky tomu může zcela zaměřit na získání informací, jež pomohou uživateli a přinesou mu užitek. Kvalifikované hodnocení úspěšnosti OSP bude možné po realizaci několika aplikací různých typů různými vývojáři a následném testu použitelnosti na odpovídajícím vzorku uživatelů. Popsaná aplikace Hlasová navigace pro MHD funguje dle předpokladů. Možným použitím OSP je doplnění hlasové interakce již vyvinuté komerční aplikace jako alternativního kanálu, zvyšujícího přístupnost pro uživatele-zákazníky. Toto doplnění je nejsnáze realizovatelné v případě, že původní aplikace je postavena na paradigmatu SOA, realizovaném webovými službami. V případě úspěchu by OSP mohla posloužit jako základ mnoha aplikací, a tím přispět k jejich rozšíření. Ač byla OSP zamýšlena jako základ pro hlasové aplikace, architektura umožňuje doplnění podpory vizuálních způsobů interakce, založených především na XHTML pro zobrazení v prohlížečích mobilních telefonů. V takovém případě je nutné implementovat vykreslování XHTML, k čemuž lze použít knihovnu zajišťující nyní vykreslování VoiceXML (viz. sekce 7.4). Rovněž je nutné upravit kontrolu autorizace uživatele, neboť XHTML je na rozdíl od VoiceXML interpretováno na straně klienta. Ostatní funkce OSP mohou být použity beze změny. Další vývoj by měl směřovat k podpoře multimodální aplikací, spojujících hlasovou a vizuální interakci. Aplikace založené na tomto konceptu se mohou přiblížit k přirozenému způsobu komunikace lidí, a tím nabídnout efektivnější a příjemnější způsoby ovládaní software. Takový vývoj by měl být podložen dostatkem testů použitelnosti, dokazujících jasné výhody pro uživatele oproti klasickým způsobům interakce člověka s počítačem. Problematika multimediálních aplikací, včetně jejich vývoje, testování a oblastí vhodného nasazení, by měla být náplní dalšího výzkumného záměru.
87
88
KAPITOLA 9. ZÁVĚR A DALŠÍ VÝVOJ
Literatura [1] ComputerWorld. Gartner: Počet počítačů se do roku 2014 zdvojnásobí, 2008. [Online; accessed 8-May-2010. [2] Coulouris., Delimore J., Kindberg T. Distributed Systems: Concept and Design. AddisonWesley , 1995. [3] Daniel Nurmi, Rich Wolski, Chris Grzegorczyk, Graziano Obertelli, Sunil Soman, Lamia Youseff, Dmitrii Zagorodnov. The Eucalyptus Open-source Cloud-computing System. Computer Science Department, University of California, 2009. [4] Dopravní podnik hlavního města Prahy. Vyhledání spojení, 2010. [Online; accessed 9-May2010]. [5] Ecma International. Standard ECMA-262 – ECMAScript Language Specification, 2009. [Online; accessed 9-May-2010]. [6] F. Leymann, D. Roller, M.-T. Schmidt. Web services and business process management. IBM SYSTEMS JOURNAL, VOL 41, NO 2, , 2002. [7] Google. Google Maps – Hledání pro mobilní telefony, 2010. [Online; accessed 9-May-2010]. [8] IBM developerWorks. Develop FileNet P8 BPM 4.0 custom components using Eclipse, 2008. [Online; accessed 9-May-2010]. [9] International Telecommunication Union. List of ITU-T Recommendation E.164 Assigned Country Codes, 2005. [Online; accessed 9-May-2010]. [10] Jakub Dolezal. Speech interface for robot planning modul. Faculty of Electrical Engineering, Czech Technical University in Prague, 2008. https://dip.felk.cvut.cz/browse/ details.php?f=F3&d=K13133&y=2008&a=dolezj8&t=bach. [11] Jan Ricken. Top-down Modeling Methodology for Model-Driven SOA Construction. University of Namur, Computer Science Department, 2007. [12] Jan Rudinsky, Tomas Mikula, Lukas Kencl, Jakub Dolezal, Xavi Garcia. Voice2Web: Architecture for Managing Voice-Application Access to Web Resources. IFIP/IEEE International Conference on Management of Multimedia and Mobile Networks and Services, 2009. [13] Jiří Danihelka, Lukáš Kencl, Jiří Žára. Reduction of Animated Models for Embedded Devices. International Conference on Computer Graphics, Visualization and Computer Vision, 2010. [14] Jonas Bonér, Eugene Kuleshov. Clustering the Java Virtual Machine using Aspect-Oriented Programming. Terracotta Inc., 2007. 89
90
LITERATURA
[15] Jonathan B. Knudsen. Java Cryptography. O’Reilly Media, 1998. http://oreilly.com/ catalog/javacrypt/chapter/ch06.html. [16] Katedra kybernetiky Fakulty aplikovaných věd. Výzkumné oblasti řešené na oddělení umělé inteligence, 2010. [Online; accessed 9-May-2010]. [17] ManagedMethods. JaxView and jUDDI Integration, 2010. [Online; accessed 9-May-2010]. [18] Martin Kuba. Web Services. Ústav výpočetní techniky, Masarykova univerzita, 2007. [19] Massimo Paolucci, Takahiro Kawamura, Terry R. Payne and Katia Sycara. Semantic Matching of Web Services Capabilities, 2002. [20] Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and Matei Zaharia. Above the Clouds: A Berkeley View of Cloud Computing. UC Berkeley Reliable Adaptive Distributed Systems Laboratory, 2009. [21] Michael H. Cohen, James P. Giangola, Jennifer Balogh. Voice User Interface Design. Addison-Wesley Professional, 2004. http://www.amazon.com/ Voice-Interface-Design-Michael-Cohen/dp/0321185765. [22] Mike P. Papazoglou. Service-Oriented Computing: Concepts, Characteristics and Directions. Tilburg University INFOLAB, Dept. of Information Systems and Management, 2003. [23] Nuance. VoiceXML Programmer’s Guide, 2007. [Online; accessed 9-May-2010]. [24] OASIS UDDI Specification Technical Committee. UDDI Technical WhitePaper, 2000. [Online; accessed 12-May-2010]. [25] Open Mobile Alliance. Mobile Location Protocol, 2010. [Online; accessed 9-May-2010]. [26] Petr Vláčil, Robert Bešťák. Implementing Mobile Location Protocol. 5th International Wireless Communications and Mobile Computing Conference (IWCMC), 2009. http: //www.rdc.cz/en/publications/. [27] PMD. PMD – Programming Mistake Detector, 2009. [Online; accessed 9-May-2010]. [28] RDC. Research and Development Centre for Mobile Applications, 2010. [Online; accessed 8-May-2010]. [29] Surekha Durvasula, Martin Guttmann, Ashok Kumar, Jeffery Lamb, Tom Mitchell, Burc Oral, Yogish Pai, Yogish Pai, Tom Sedlack, Dr Harsh Sharma, Sankar Ram Sundaresan. SOA Practitioners’ Guide – Part 2: SOA Reference Architecture. 2006. [30] TechWorld. PC numbers set to hit 1 billion, 2007. [Online; accessed 8-May-2010]. [31] Tellme. VoiceXML 2.0 and 2.1 Element Reference, 2008. [Online; accessed 9-May-2010]. [32] The Apache Jakarta Project. Element Construction Set, 2004. [Online; accessed 9-May2010]. [33] The Apache Software Foundation. Apache jUDDI, 2010. [Online; accessed 9-May-2010]. [34] Tomáš Mikula (RDC). VoiceXML Integrated Development Environment (VXML IDE), 2010. [Online; accessed 9-May-2010]. [35] Tomáš Mikula (RDC). Web Proxy, 2010. [Online; accessed 9-May-2010].
LITERATURA
91
[36] Voxeo. VoiceXML Development Guide, 2008. [Online; accessed 9-May-2010]. [37] W3C. Voice Extensible Markup Language (VoiceXML) 2.1, 2007. [Online; accessed 9-May2010]. [38] Web Services Interoperability Organization (WS-I). Basic Profile, 2010. [Online; accessed 12-May-2010]. [39] Wikipedia. Reverse geocoding — Wikipedia, The Free Encyclopedia, 2009. [Online; accessed 9-May-2010]. [40] Wikipedia. List of countries by number of mobile phones in use — Wikipedia, The Free Encyclopedia, 2010. [Online; accessed 8-May-2010].
92
LITERATURA
Příloha A
Dotazník pro testy použitelnosti Následující dotazník je určen pro testy použitelnosti aplikace Hlasová navigace pro MHD: 1. Považujete nabídku blízkých zastávek za užitečnou? (a) Ano (b) Spíše ano (c) Nevím (d) Spíše ne (e) Ne 2. Jste spokojen/a s úspěšností rozpoznání zastávek? (a) Ano (b) Spíše ano (c) Nevím (d) Spíše ne (e) Ne 3. Považujete instrukce pro pěší přesun k nástupní zastávce za pochopitelné? (a) Ano (b) Spíše ano (c) Nevím (d) Spíše ne (e) Ne 4. Považujete instrukce pro pěší přesun k nástupní zastávce za přehledné? (a) Ano (b) Spíše ano (c) Nevím (d) Spíše ne (e) Ne 93
94
PŘÍLOHA A. PŘÍLOHA A 5. Považujete popis dopravního spojení za pochopitelný? (a) Ano (b) Spíše ano (c) Nevím (d) Spíše ne (e) Ne 6. Považujete popis dopravního spojení za přehledný? (a) Ano (b) Spíše ano (c) Nevím (d) Spíše ne (e) Ne
Příloha B
Obsah doprovodného DVD Doprovodný disk DVD obsahuje tyto adresáře: text s tuto bakalářskou práci včetně zadání ve formátu PDF. latex se zdrojovými soubory této práce ve formátu LATEX. media v němž se nalézají obrázky a schémata použitá v práci. src obsahuje zdrojové soubory OSP. lib obsahuje knihovny, které OSP používá. Popis požitých knihoven je kapitole 7.
