基于VoiceXML技術的可視化IVR系統(tǒng)設計和實

------------------------------------------------------------------------基于VoiceXML技術的可視化IVR系統(tǒng)設計和實...基于VoiceXML技術的可視化IVR系統(tǒng)設計和實現(xiàn)(一)上海易谷網(wǎng)絡科技有限公司查瑋2009/09/22摘要

為了縮短交互式語音應答(IVR:InteractionVoiceResponse)系統(tǒng)流程開發(fā)周期，克服傳統(tǒng)IVR系統(tǒng)業(yè)務流程編寫復雜的困難，同時與VoiceXML技術相結合，本文設計并實現(xiàn)了基于VoiceXML技術的可視化IVR系統(tǒng)。

本文設計的IVR系統(tǒng)，將整個系統(tǒng)分為流程編輯工具、含有VoiceXML標簽的Web頁面和執(zhí)行引擎三個部分，完成了總體框架及其核心部分的設計與實現(xiàn)。本文研究了可視化技術的現(xiàn)狀和理論，并對傳統(tǒng)IVR系統(tǒng)流程編輯工具做了分析與對比，并在此基礎上，從靈活、方便以及友好的用戶界面的設計原則出發(fā)，對IVR系統(tǒng)的流程工具進行了詳細的設計與實現(xiàn)。然后，在分析當前Web技術發(fā)展的情況下,本文與企業(yè)數(shù)據(jù)業(yè)務緊密結合，提出了將業(yè)務流程類比成企業(yè)門戶網(wǎng)站的解決方案。該方案結合OpenVXI開源項目，使用VoiceXML技術，設計并實現(xiàn)了IVR系統(tǒng)的執(zhí)行引擎。

關鍵詞：交互式語音應答可視化系統(tǒng)VoiceXML

第一章緒論

1.1研究背景

呼叫中心(CallCenter，又稱客戶服務中心)起源于發(fā)達國家對服務質(zhì)量的需求，其主旨是通過電話、傳真等形式為客戶提供迅速、準確的咨詢信息以及業(yè)務受理和投訴等服務，通過程控交換機的智能呼叫分配、計算機電話集成、自動應答系統(tǒng)等高效的手段和有經(jīng)驗的人工坐席，最大限度地提高客戶的滿意度，同時自然也使企業(yè)與客戶的關系更加緊密，是提高企業(yè)競爭力的重要手段[1]。

IVR(InteractionVoiceResponse，交互式語音應答)系統(tǒng)是整個呼叫中心的系統(tǒng)的最前端，它的質(zhì)量直接影響到整個系統(tǒng)的穩(wěn)定性。在整個呼叫中心運行過程中，IVR系統(tǒng)的業(yè)務流程也在隨著客戶體驗和業(yè)務功能需求發(fā)生著改變，因此，如何對業(yè)務流程方便快捷的修改成了IVR系統(tǒng)必不可少的功能顯得尤為重要。相對于傳統(tǒng)的腳本式的編輯方法顯然不能很好的適應這樣的變化，所以可視化的配置方式呼之欲出，應用可視化的業(yè)務流程編輯界面可以很好與用戶交互，減輕了用戶的工作量，同時達到方便快鍵的目的。

同時，隨著IVR系統(tǒng)的發(fā)展，其與企業(yè)的數(shù)據(jù)業(yè)務結合的越來越緊密。而傳統(tǒng)的IVR系統(tǒng)相對于企業(yè)后臺數(shù)據(jù)業(yè)務服務相對隔離，而且大多數(shù)的IVR產(chǎn)品都不能很好的與企業(yè)的業(yè)務系統(tǒng)對接，或者是使用了比較繁冗復雜的方法，既浪費了資源，又影響了系統(tǒng)的穩(wěn)定性。VoiceXML技術的出現(xiàn)，使語音業(yè)務與數(shù)據(jù)業(yè)務得到了統(tǒng)一，節(jié)省了資源，用戶在訪問語音業(yè)務的時候也可以方便的訪問到數(shù)據(jù)業(yè)務。

1.2國內(nèi)外研究現(xiàn)狀與應用前景

1.2.1可視化技術的發(fā)展現(xiàn)狀和應用前景

可視化語言技術比一維文本語言在描述軟件組成方面具有優(yōu)越性．由于圖表和圖形概念在系統(tǒng)建模中的廣泛使用，可視化語言可以應用于需求分析、設計、測試和維護等軟件開發(fā)的各個階段[2]。

可視化建模語言簡稱可視化語言，是采用圖形方式對系統(tǒng)/軟件進行描述的語言，如目前廣為流行的統(tǒng)一建模語言UML、傳統(tǒng)的數(shù)據(jù)流語言和工作流建模語言等，它具有直觀、便于理解的優(yōu)點?？梢暬９ぞ邽榭梢暬ＵZ言的使用提供了工具支持，目前可分為兩大類：自由編輯型和語法制導型。自由編輯型允許用戶隨意建模，相當也圖形編輯器，如Microsoft(微軟)公司的Visio；語法制導的可視化建模工具在編輯過程中自動引導用戶建立語法正確的可視化模型，有利于用戶對可視化建模語言的掌握和使用，有著廣泛的使用范圍。

對于自由編輯型可視化建模工具，在國際市場上，Microsoft公司的Visio和Rational公司的Rose的產(chǎn)品比較有影響和代表性。

Visio是當今最優(yōu)秀的辦公繪圖軟件之一，它將強大的功能和簡單的操作完美地結合在一起。使用Visio，可以繪制業(yè)務流程圖、組織結構圖、項目管理圖、營銷圖表、辦公室布局圖、網(wǎng)絡圖、電子線路圖、數(shù)據(jù)庫模型圖、工藝管道圖、因果圖、方向圖等，因而，Visio被廣泛地應用于軟件設計、辦公自動化、項目管理、廣告、企業(yè)管理、建筑、電子、機械、通信、科研和日常生活等眾多領域。

RationalRose[3]是一個完全的，具有能滿足所有建模環(huán)境(Web開發(fā)，數(shù)據(jù)建模，VisualStudio和C++)需求能力和靈活性的一套解決方案。Rose允許開發(fā)人員，項目經(jīng)理，系統(tǒng)工程師和分析人員在軟件開發(fā)周期內(nèi)在將需求和系統(tǒng)的體系架構轉(zhuǎn)換成代碼，消除浪費的消耗，對需求和系統(tǒng)的體系架構進行可視化，理解和精練。通過在軟件開發(fā)周期內(nèi)使用同一種建模工具可以確保更快更好的創(chuàng)建滿足客戶需求的可擴展的、靈活的并且可靠的應用系統(tǒng)。

語法制導型的編輯器自動生成技術的研究成果主要有GENGED[4]、PROGRES[5]、MetaEdit+[6]；國內(nèi)的研究相對較少，從目前所發(fā)表的研究成果看，只有北航軟件工程研究所研制的SGEG系統(tǒng)[7]。以上研究主要基于自動生成器的思想，由于在不同程度上缺乏對語言描述能力、語言解析效率、生成的目標編輯器的靈活性和可擴展性等方面的綜合考慮，所以實用性較弱。

1.2.2VoiceXML技術的發(fā)展現(xiàn)狀與應用前景

VoiceXML(語音可擴展標記語言)的出現(xiàn)最早可以追溯到1995在AT&T公司開發(fā)的基于XML的電話標記語言(PML)。隨后，AT&T、LucentTechnologies以及Motorola公司分別各自著手開發(fā)自己的類似于PML的語音標記語言。到了1998年，W3C(worldwidewebconsortium)組織的“語音瀏覽器”會議上，AT&T和LucentTechnologies分別展現(xiàn)了他們各自的類同PML的標記語言、Motorola和IBM公司分別推出VoxML[8]和SpeechML[9]、HP和PipeBeach公司也分別推出TalkML[10]和VoiceHTML[11]。AT&T、IBM、LucentTechnoglies、以及Motorola隨后成立了VoiceXML論壇，其目的是為了建立一個語音對話應用系統(tǒng)的國際標準。到了2000年，AT&T、IBM、LucentTechnologies、以及Motorola通過W3C協(xié)會聯(lián)合推出語音可擴展標記語言VoiceXML1.0。該標準一經(jīng)推出，便得到相關行業(yè)眾多公司的響應。經(jīng)過兩年多的論證和實際系統(tǒng)驗證，VoiceXML2.0最終草案在2003年推出。用VoiceXML開發(fā)的語音應用系統(tǒng)，不僅可以完全代替?zhèn)鹘y(tǒng)CTI(計算機電話集成)系統(tǒng)所能提供的功能，而且還可以使應用系統(tǒng)開發(fā)過程極其簡單快捷、系統(tǒng)有極高的可擴展性、可維護性、可移植性、可重用性和開放性。其定義了如何使用語音識別、語音合成、互聯(lián)網(wǎng)訪問、數(shù)據(jù)庫訪問、語音文件播放、DTMF輸入等功能開發(fā)一個完整的語音應用系統(tǒng)。

1.3論文研究內(nèi)容

隨著現(xiàn)代呼叫中心的發(fā)展，IVR系統(tǒng)的業(yè)務流程也愈趨復雜，在設計過程定義工具的時候簡化操作的復雜性，提高產(chǎn)品的易用性是首先應當考慮的。所以圖形化的過程定義工具顯得尤為必要。同時，人們在呼叫中心業(yè)務中，對于語音和數(shù)據(jù)業(yè)務相結合有了強烈的愿望，VoiceXML很好的解決了這個難題，其技術也在這幾年有了長足的發(fā)展，使得語音和數(shù)據(jù)業(yè)務有了一個良好的耦合。

為了實現(xiàn)簡單、易用能和數(shù)據(jù)業(yè)務良好整合的IVR系統(tǒng)，本課題圍繞以下幾項主要工作展開研究：

1．可視化的基本概念的研究。具體的研究內(nèi)容包括:可視化技術的定義，可視化建模語言的描述方法，閱讀并分析了大量有關可視化技術的資料及學術論文，對可視化技術的概念、特點進行詳細的討論和分析；

2．可視化的過程定義工具的研究。具體的研究內(nèi)容包括可視化過程定義工具的體系結構和過程定義工具的詳細設計和實現(xiàn)；

3．VoiceXML技術的基本概念的研究。具體的研究內(nèi)容包括：VoiceXML的概述,VoiceXML的基本體系結構和其在IVR系統(tǒng)中的簡單應用；

4．基于VoiceXML的執(zhí)行引擎的研究。具體的研究內(nèi)容包括：執(zhí)行引擎的體系結構的總體分析以及基于OpenVXI開源項目的執(zhí)行引擎的設計和實現(xiàn)。

1.4本文結構

本文共分六部分，具體的內(nèi)容組織如下：

第一章：緒論。給出課題的研究背景，提出論文的目標、意義和主要研究內(nèi)容；

第二章：相關技術研究。第一部分，可視化技術概述。介紹了可視化技術的定義和建模語言描述方法等。第二部分，VoiceXML技術。介紹了VoiceXML技術的原理和在IVR系統(tǒng)的應用；

第三章：基于VoiceXML技術的可視化IVR系統(tǒng)分析和設計。首先分析了IVR系統(tǒng)的具體需求，提出了系統(tǒng)總體架構，分別論述了流程定義工具和執(zhí)行引擎的詳細設計；

第四章：基于VoiceXML技術的可視化IVR系統(tǒng)實現(xiàn)。重點介紹了過程定義工具及執(zhí)行引擎的實現(xiàn)；

第五章：IVR系統(tǒng)的應用及測試。給出了本問設計的系統(tǒng)的一個具體應用，并且給出了測試結果；

第六章：結束語。總結了本文工作所取得的成果，并對下一步工作提出了展望。

第二章相關技術研究

由于IVR系統(tǒng)在呼叫中心系統(tǒng)中的前置性和必要性地位，同時IVR系統(tǒng)相關技術也引起了很高的關注。近年來，隨著軟件開發(fā)技術的日新月異，IVR系統(tǒng)相關技術也在不斷發(fā)展和完善，下面扼要的介紹一下IVR系統(tǒng)相關的可視化技術和VoiceXML技術的研究現(xiàn)狀和進展。

2.1可視化技術綜述

2.1.1可視化技術的研究

可視化建模工具的開發(fā)，其總體思路是利用模型驅(qū)動的方法，通過模型到代碼、模型到語言配置文件的自動映射，同時通過配置目標編輯器，實現(xiàn)可視化語言編輯器的自動生成。自動生成結合配置技術不僅使可視化語言編輯器的開發(fā)效率更高，而且更具靈活性。

總體框架分為三個部分(見圖2.1)：

1.模型，主要包括對目標語言(即可視化語言)的描述；

2.轉(zhuǎn)化模塊，將模型描述的信息轉(zhuǎn)化為代碼和語言配置文件；

3.目標編輯器的配置和自動生成，其基本設計思想是將所有可視化語言編輯器都共有的部分和變化的部分分離，由基礎框架實現(xiàn)共有部分，而變化部分采用自動生成和系統(tǒng)配置的方法實現(xiàn)。

因此目標編輯器由“可視化語言編輯器框架+語言構件+編輯器配置項”構成?？梢暬Z言編輯器框架是目標編輯器的核心驅(qū)動部分，不涉及與任何目標可視化語言相關的代碼；語言構件包含了與目標可視化語言相關的目標代碼；配置項描述了對可視化語言和編輯器的定制。圖2.1可視化建模工具總體框架圖根據(jù)總體框架，可視化建模工具開發(fā)環(huán)境主要包括以下兩個方面的研究：

(1)可視化建模語言的描述方法；

(2)目標編輯器的配置和實現(xiàn)。

2.1.2可視化建模語言描述方法

可視化建模語言的描述方法是總體框架的基礎。分為三個部分：

1.語素—語素是最小的語法單位，可視化語言的語素表現(xiàn)為圖元符號(本文中不再區(qū)分語素和圖元)。

2.語法—語法定義了圖元符號之間的關系，包括兩個部分：抽象語法和具體語法。抽象語法定義圖元之間邏輯連接關系；具體語法定義圖元外觀的類型以及圖元之間幾何位置關系。

3.語義—語義表明了圖元符號和連接關系的含義，是模型的具體含義。

目前，大多數(shù)可視化建模語言描述的研究主要是針對語法描述研究，描述方法主要有基于文法的形式化描述、基于邏輯的形式化描述、基于代數(shù)的形式化描述和基于規(guī)則的半形式化描述方法[12]。一般分為兩大部分：基于規(guī)則的語法形式化描述和基于元模型技術的靜態(tài)語義描述。

(1)基于規(guī)則的語法描述方法(RGVL，Rule-basedGrammarVisualLanguage)

基于規(guī)則的可視化建模語言描述方法(RGVL)具有如下優(yōu)點：規(guī)則的解析效率高；規(guī)則容易理解和書寫；描述能滿足當前大多數(shù)的可視化建模語言需求。

RGVL采用一組規(guī)則來定義圖元與圖元之間的邏輯關系，并利用一組規(guī)則來描述圖元的位置關系等幾何信息。該描述方法形式上可以定義為一個三元組：

G={p,AG,CG}式(2-1)

G為可視化建模語言的語法，其中，

p：為一個有窮的圖元集合。形式表示為：

P={P/P為可視化建模語言中的基本圖元類型}例如，UML類圖中的類和關聯(lián)類可以表示為：

P{Class,Assiciaion}式(2-2)AG：抽象語法規(guī)則集合。形式表示為：

AG={r/r(p1,p2,n)p1€p,p2€p,n為自然數(shù)}式(2-3)

r為圖元之間的連接關系，r可以為Connection_from和Connection_to兩種類型的關系，n表示連接的勢(多重性)；*表示無窮；Connection_from表示從p2連接到p1，p1為當前圖元；Connection_to表示從p1連接到p2，p1為當前圖元。例如，在UML關聯(lián)關系的定義中，為了表示關聯(lián)關系與類之間的抽象語法關系，可以書寫如下的規(guī)則：

AG={Connection_to(Class,Associalion,*),

Connection_from(Class,Associalion,1)}式(2-4)

表示類圖元可以連接多個關聯(lián)關系，每個關聯(lián)關系必須連接到一個類圖元。

CG：具體語法規(guī)則集合。形式表示為:

CG={(p,render,lsyout)/p€P,render€R.layout€C}式(2-5)

R是圖元外觀類型的集合，L是圖元位置關系的集合。例如，

CG={Class.MutiTextViz,AtLocationLayout}式(2-6)

公式(2-6)表示類圖元具有帶有多個文本框的外觀類型和指定位置放置圖元的位置關系定義時，為了增強可擴展行,定義了用戶自定義類型(在實現(xiàn)時，定義了相關的編程接口使得用戶可以自定義外觀和圖元位置關系)。

(2)基于元模型的靜態(tài)語義描述方法(MSS)

將傳統(tǒng)的語義分為兩個部分：靜態(tài)語義和動態(tài)語義。靜態(tài)語義表示圖元符號的屬性信息，是可視化建模語言中一個重要組成部分。通過擴展元模型MOF(MetaObjectFacility)技術對靜態(tài)語義進行定義。MOF是對象管理組織定義的一個用于在平臺無關方式下，定義、使用和集成元數(shù)據(jù)以及數(shù)據(jù)的模型驅(qū)動框架[13]。

利用MOF元模型對可視化建模語言的靜態(tài)語義進行描述時，MOF的表達能力還不足以滿足完整地描述可視化建模語言的語素(圖元)的靜態(tài)關系和操作關系，擴展了MOF中的關聯(lián)關系，在關聯(lián)中增加標簽值來專門說明該關聯(lián)與其它關聯(lián)之間的關系，提出了基于MOF的靜態(tài)語義描述方法稱為MSS(MOF-basedStaticSematic)。該方法可以定義為一個三元組：

MSS={m,Rs,Rop}式(2-7)

MSS為可視化建模語言的靜態(tài)語義，其中，M：為擴展的MOF的靜態(tài)語義模型?？杀硎緸?/p>

M=CssURss式(2-8)

Css表示元類的集合，Rss表示元類之間的關系集合。在Rss中使用的是擴展后的關聯(lián)關系，可以定義關聯(lián)之間的關系。

Rs：為圖元與靜態(tài)語義模型中元類的靜態(tài)關系?？杀硎緸?/p>

Rs={(p,c)/p€P,C€Css}式(2-9)

公式(2-9)中p為語素集合，Css為元類集合。

對于目標編輯器的配置和實現(xiàn)，主要是對可視化建模語言研究和分析后，根據(jù)實現(xiàn)的需要，同時考慮了解析能力和描述能力，定義了一套支持語義定義的可視化建模語言描述方法。

2.2基于VoiceXML的交互式語音應答

2.2.1VoiceXML概述

VoiceXML是W3C用來制定通過對話訪問Web的內(nèi)容及其交互語音應答的傳遞標準。VoiceXML使公共電話網(wǎng)、語音處理技術以及互聯(lián)網(wǎng)有機地結合為一體。它是一種域?qū)Ｓ谜Z言，定義了一系列的語音應用概念、元素及其對應的操作，能根據(jù)播放的音頻文件、輸出的文本語音、要錄制和識別的語音以及所接收的按鍵音，連定義人和計算機之間的語音交互過程。

VoiceXML希望通過交互式語音界面應用Web上已經(jīng)存在的大量信息，同時希望能夠?qū)㈤_發(fā)人員從最低級的編程和資源處理工作中解放出來。VoiceXML還能夠利用人們已經(jīng)非常熟悉的C/S,將語音服務和數(shù)據(jù)服務融合起來[14][15]。

2.2.2VoiceXML基本體系結構

VoiceXML系統(tǒng)的基本結構如圖2.2所示[16]。其中，文檔服務器充當?shù)氖荳eb服務器的角色，他負責處理執(zhí)行平臺發(fā)送的請求文檔，并與后臺數(shù)據(jù)庫進行交互，組織VoiceXML文檔對該請求進行響應。

VoiceXML解析器上下文和VoiceXML解釋器負責解析VoiceXML文件，控制執(zhí)行平臺。執(zhí)行平臺提供合成語音的輸出(texttospeech，TTS)、音頻文件的輸出、話音輸入的識別(automatedspeechrecognition，ASR)、DTMF輸入識別、語音輸入的錄音、電話功能等[17]。圖2.2VoiceXML的基本體系結構圖VoiceXML語言規(guī)范的層次結構如圖2.3[18]所示，層次從底向上依次升高。圖2.3VoiceXML層次結構(1)Session。用戶開始和VoiceXML解析器進行交互式標志一次會話(Session)開始，繼續(xù)完成文檔獲取和處理，當用戶、文檔或者解釋器要求退出時，這次Session結束。

(2)Application。一個應用(Application)是指一系列文檔共享一個相同的應用文檔。當用戶和一個應用中的文檔交互時，它的應用根文檔同時被加載；當文檔跳轉(zhuǎn)到的另一個文檔也存在于同一個應用中，這時根文檔不被釋放當根文檔被加載后它的變量可以被其他子文檔使用。

(3)Dialog和SubDialog。每個VoiceXML文檔都是一個交談的有限狀態(tài)自動機用戶某時只能在一個會話狀態(tài)Dialog，它決定了下一個要執(zhí)行的Dialog執(zhí)行時就是在Dialog之間跳轉(zhuǎn)。

Dialog分為兩種Form和Menu。Form定義了一系列Field項目用于交互，每一個Field可以使用Grammar語法指定允許輸入的內(nèi)容。Menu提供給用戶選擇然后根據(jù)用戶的選擇跳轉(zhuǎn)到指定的Dialog中。

SubDialog類似于函數(shù)調(diào)用，它提供一種機制允許激活一個新的交互，等交互完成后返回到原先的交互中去。使用SubDialog可以實現(xiàn)一個特定模塊以便重復使用。

(4)Grammar。每個Dialog都有至少一個語法(Grammar)。語法包括兩種：DTMF語法和語音語法。在機器導引方式中，只有當用戶處于這個Dialog中，該Dialog的Grammar才是有效的；在混合方式中，有些Dialog可以標記為即使當前用戶不處于該Dialog中，這個語法也是有效的。

(5)Event。VoiceXML提供了一種Form-Filling機制來處理通常的輸入，另外還需要處理一些事件。在有些情況下平臺會拋出一些事件，例如用戶無響應、超時或沒有正確響應、請求幫助等。如果解釋器發(fā)現(xiàn)語義錯誤，也會拋出事件。事件由Catch元素來捕獲并作相應的處理。

2.2.3在IVR系統(tǒng)中運用VoiceXML技術

VoiceXML的推出給電話語音系統(tǒng)帶來全新的應用和開發(fā)概念，使傳統(tǒng)的CTI技術從繁瑣、封閉的模式中走了出來，使廣大的語音系統(tǒng)開發(fā)人員可以用極其簡單的方法實現(xiàn)復雜系統(tǒng)的開發(fā)。同時VoiceXML技術突破地實現(xiàn)了互聯(lián)網(wǎng)與電話網(wǎng)的融合，在以語音為核心的電話網(wǎng)絡與以數(shù)據(jù)為核心的互聯(lián)網(wǎng)絡之間建立了良好的溝通“橋梁”。

到目前為止，人們從Internet獲取各種資源時，還只能是借助計算機來實現(xiàn)。而實際上，電話具有比計算機更高的普及率，如果允許人們通過電話來訪問Internet的資源，那么這對于Internet的應用發(fā)展必將是一次質(zhì)的飛躍。在這類應用前景的驅(qū)動下，VoiceXML1.0標準被提出來了，目前最新版本為2.1[19]。

VoiceXML使得用戶可以通過電話按鍵或語音來訪問Internet上的各種資源，它是語音瀏覽技術以及語音互聯(lián)網(wǎng)的核心。VoiceXML為語音應用領域展現(xiàn)了一個廣闊的未來，用VoiceXML開發(fā)的語音應用系統(tǒng)，不僅可以完全代替?zhèn)鹘y(tǒng)CTI(計算機電話集成)系統(tǒng)所能提供的功能，而且還可以使應用系統(tǒng)開發(fā)過程極其簡單快捷、系統(tǒng)有極高的可擴展性、可維護性、可移植性、可重用性和開放性，在語音門戶、語音呼叫中心(CallCenter)、語音信息服務、語音電子商務等領域有著廣泛的應用。

下面給出兩個簡單的例子說明VoiceXML在IVR系統(tǒng)的應用：

第一個是“Helloworld”：

所有VoiceXML命令都封裝在……之間。VoiceXML對話框用戶描述腳本對用戶輸出的各種提示、定義和收集用戶的響應，并且描述程序控制的流程。對話框分兩種，分別是窗體(forms)和菜單(menus)。窗體輸出信息并且收集輸入，菜單提供下一步做什么選擇。這個例子有一個單一的窗體，它包括一個快(block)，該塊合成并輸出“HelloWorld！”。由于這個窗體沒有后繼的對話框，所以輸出完“HelloWorld！”后，腳本結束。

第二個例子要求用戶選擇一種飲料，并把用戶的選擇提交到服務器：

域(field)用于輸入。用戶在處理窗體中下一個元素之前，必須為一個域提供相應的信息。以上腳本的一個交互例子如下：

C(computer)：Wouldyoulikecoffee,tea,milk,ornothing?

H(human)：Orangejuice。

C：Ididnotunderstandwhatyousaid.

C：Wouldyoulikecoffee,tea,milk,ornothing?

H：Tea

C：(continuesindocumentdrink2.jsp)

通過這兩個例子可以看到，VoiceXML使用非常簡單。哪怕只是看幾個例子，就可以掌握一些基本的使用方法；而且它的特點正好符合用戶通過語音交互的業(yè)務特性，對聲訊業(yè)務支持近乎完美。

VoiceXML2.0中共預定義了43個元素，按照功能可以分為文檔對話有關、資源功能類、事件處理類。文檔對話相關的元素主要實現(xiàn)信息表達、數(shù)據(jù)采集、變量賦值、條件控制、函數(shù)調(diào)用等功能；時間處理類元素主要實現(xiàn)產(chǎn)生、捕獲時間的功能，可進行錯誤處理、超時處理、幫助處理等；資源功能類元素主要實現(xiàn)錄、放音，TTS，ASR等與語音資源控制相關的功能，是對語音資源能提供功能的描述。

2.3本章小結

本章首先闡述了可視化建模語言的總體框架，論述了可視化建模語言的描述方法。其次，介紹了VoiceXML技術的概念和基本體系結構，隨后描述了在IVR系統(tǒng)中VoiceXML技術的簡單應用。本章的內(nèi)容將為基于VoiceXML的IVR系統(tǒng)圖形化開發(fā)環(huán)境與執(zhí)行引擎設計和實現(xiàn)提供理論基礎。第三章交互式語音應答(IVR)系統(tǒng)是電話銀行呼叫中心系統(tǒng)的最前端，它的質(zhì)量直接影響整個系統(tǒng)的穩(wěn)定性和可擴展性。本文設計的IVR系統(tǒng)主要分為兩個模塊：可視化過程定義工具(用戶交互接口)、流程執(zhí)行引擎。由于過程定義工具主要是面向用戶，它的設計規(guī)范首先要符合流程的定義規(guī)則，反應到本文中即流程工具涉及到的節(jié)點類型均符合IVR的操作動作和相關的業(yè)務動作，同時還要生成符合流程執(zhí)行引擎能處理的文件格式。在流程執(zhí)行引擎方面，符合VoiceXML的設計框架，將Web應用和語音應用相結合。

3.1IVR系統(tǒng)結構的總體分析與設計

IVR系統(tǒng)流程工具是通過使用圖形化的編輯界面，將工作流程以圖形的方式展現(xiàn)給用戶，使用者也可以通過次編輯器根據(jù)具體的業(yè)務需求將特定的IVR流程反應在圖形當中，因此，對于使用者來說，根本不需要知道底層的工作模式就可以很輕松的完整定制工作流程的制作。在這部分中，主要通過使用自定義的節(jié)點，以及在節(jié)點的屬性窗體中進行相應屬性的設置來完成工作流程的制作。

隨著IVR技術的發(fā)展，與企業(yè)級后臺數(shù)據(jù)系統(tǒng)聯(lián)系越來越緊密。傳統(tǒng)的IVR系統(tǒng)已經(jīng)不能適應Web技術的發(fā)展了，本文設計的IVR系統(tǒng)，將用戶通過電話操作的過程類比成用戶登陸網(wǎng)頁的過程，整個業(yè)務流程相當于用戶所登陸的網(wǎng)站，構成網(wǎng)站的每一個網(wǎng)頁可以看成是業(yè)務流程中的每一個節(jié)點。業(yè)務流程交給WebService來驅(qū)動，只要增加對語音操作的解釋就可以完成整個語音系統(tǒng)的驅(qū)動。而定義的語音操作，本文是通過使用標準的VoiceXML語言來定義，所以流程定義工具所交給執(zhí)勤引擎驅(qū)動的中間文件就是標準的Web頁面與VoiceXML標簽的集合。

而IVR系統(tǒng)執(zhí)行引擎是根據(jù)IVR系統(tǒng)的特點，基于VoiceXML技術的設計所實現(xiàn)的流程解釋器，主要針對解釋執(zhí)行通過IVR系統(tǒng)流程定義工具所設計的中間文件，并控制硬件交換機及板卡按照工作流程的內(nèi)容完成相應的功能。

圖3.1給出了IVR系統(tǒng)詳細的總體結構圖。IVR系統(tǒng)總共分為兩大部分：軟件平臺和硬件平臺。其中硬件平臺主要是硬件廠商提供，本文所設計的系統(tǒng)主要是軟件平臺的設計和實現(xiàn)。從圖中可以看出，整個系統(tǒng)分為三個部分：IVR系統(tǒng)可視化流程定義工具、含有VoiceXML標簽的Web頁面和執(zhí)行引擎。圖3.1IVR系統(tǒng)整體結構圖3.2可視化過程化定義工具的分析

可視化建模語言的模型必須具備足夠豐富的描述能力來表達所需的流程的實體及相互關系，它必須易于實現(xiàn)且有著良好的用戶的交互性。一種模型描述方式是使用類過程語言的邏輯和實體描述語言，將IVR工作流程寫為一段語言程序，活動、數(shù)據(jù)和邏輯關系等在內(nèi)部加以界定；另外一種方式是將活動或邏輯從過程邏輯中抽象出來，形成獨立的對象(邏輯關系可以作為活動對象的內(nèi)部屬性，也可以作為獨立的對象)。

傳統(tǒng)的實現(xiàn)IVR系統(tǒng)的方法[20]，經(jīng)歷了一個由復雜到簡單的發(fā)展歷程。

它已經(jīng)由基本代碼編寫發(fā)展到現(xiàn)在的高度抽象的計算機模型的實現(xiàn)方法。在這個過程中主要出現(xiàn)了以下幾種方法：

代碼生成：此種方法主要是根據(jù)工作流程的要求，由技術人員手工編寫代碼實現(xiàn)。這增加了開發(fā)的難度和系統(tǒng)的復雜度，可擴展性較差，不利于系統(tǒng)的復用，從圖2.1所示的可視化建模工具總體框架可以看出，這種方法將過程建模和業(yè)務流程以及相關數(shù)據(jù)和工作流程處理集成在一起，通過代碼生成的方式實現(xiàn)工作流過程。

表格方式：此種方法在過程建模部分由表格方式實現(xiàn)，通過手動添加業(yè)務流程執(zhí)行過程狀態(tài)；同時將工作流過程中的每一個狀態(tài)封裝成函數(shù)或類。在工作流引擎執(zhí)行過程中，通過讀取表格內(nèi)容，調(diào)用相應的函數(shù)實現(xiàn)功能。這種方法雖然在一定程度上降低了業(yè)務流程引擎部分的復雜，但增加了過程建模的復雜度，導致用戶接口人性化程度降低，應用程序交互的接口定義的靈活度受到的限制。

圖和鏈表方式：這種方法在過程建模部分相對于表格方式做了改進，取消了表格，代之以圖和鏈表，使用戶接口部分體現(xiàn)了圖形化和人性化的特點。但由于圖的結構復雜，用戶在使用容易出錯，同時業(yè)務流程引擎在執(zhí)行過程中圖的結構增加了流程解釋執(zhí)行的復雜度。

樹型方式：樹型方式是目前常用的方法，采用的是父-子關系模式。這一模式的指樹中的任何節(jié)點(狀態(tài))的下一個狀態(tài)節(jié)點都以此節(jié)點的子節(jié)點方式出現(xiàn)。雖然這種方法使用戶界面更加清晰，但樹的深度加大會給實現(xiàn)業(yè)務流程引擎和過程建模工具增加了難度。

根據(jù)上述對傳統(tǒng)的IVR系統(tǒng)的分析和實現(xiàn)方法的比較，本文提出VoiceXML應用于可視化建模工具中，在用戶接口部分沿用的樹型方式，但根據(jù)VoiceXML的規(guī)范性和靈活性，相鄰節(jié)點之間的關系由原來的父子關系變?yōu)樾值荜P系。這樣無論過程建模還是在工作流程引擎的實現(xiàn)難度都被極大降低。

過程定義模型向用戶提供的用于抽象描述業(yè)務過程的設計元素會通過工作流過程定義工具表達出來，用戶使用過程定義工具提供的輸入界面，通過將各中設計控件加以組合來完成對實際業(yè)務流程的抽象描述[21]。在設計過程定義工具時，本文采用了圖形化的用戶界面，從而簡化了建模操作的復雜行，提高了易用性，有效降低了使用難度。

3.2.1過程定義建模語言的描述

根據(jù)可視化建模語言描述的方法，語言和編輯器配置項體現(xiàn)了系統(tǒng)的可配置性。它包括三個部分：圖元庫、編輯器定義文件、界面描述文件。

圖元庫是對可視化建模語言語素的定義。編輯器定義文件中包含了可視化語言語法(抽象語法和具體語法)、圖元操作定義、靜態(tài)語義元類與圖元的靜態(tài)關系，采用RGVL的方式來描述。界面描述文件定義可視化語言編輯器的主界面，包括對菜單、各種工具條、各種視圖、狀態(tài)條。

3.2.2基于可視化技術的過程定義工具的功能

IVR系統(tǒng)的過程定義工具是一個可視化的軟件工具，它主要用于定義工作流模型中各個活動之間的關系[22]。工作流程過程定義向用戶提供對實際業(yè)務處理過程分析、建模的手段。其輸入輸出可以用圖3.2表達：圖3.2IVR系統(tǒng)流程開發(fā)工具的輸入和輸出其功能可以細分為：向用戶提供定義工作流的操作界面；根據(jù)用戶的輸入自動生成以文本形式表達的IVR系統(tǒng)流程抽象描述；將以文本形式表達的工作流抽象描述發(fā)送給格式化工具組件。

本文設計的IVR系統(tǒng)的流程定義工具遵循以上規(guī)則，它被流程定義者使用，其所有的動作都是由流程設計人員發(fā)起的，通過對定義工具進行了統(tǒng)一建模分析，其使用用例圖如圖3.3所示。圖3.3IVR系統(tǒng)流程定義工具用例圖新建流程：用戶通過選擇“新建工作流模型”菜單或單擊工具欄上相應按鈕新建一個空的模型文件。繪制流程：用戶使用定義工具提供的各種建模組件繪制模型。主要包括：IVR系統(tǒng)流程中涉及到各個節(jié)點繪制、各個連接點的連線的繪制。編輯流程：用戶可以用直接操作節(jié)點元素，包括選擇、刪除、平移等功能。設置節(jié)點屬性：用戶通過設置節(jié)點屬性對話框來設置節(jié)點的屬性。保存流程：用戶將所建流程以文件的形式保存起來。打開模型：用戶通過給出的文件列表打開流程文件。

3.2.3IVR系統(tǒng)流程工具的用戶交互方式

在IVR系統(tǒng)過程定義工具過程中，同用戶的交互方式的選擇是主要考慮的一個方面。而一般的工作流過程定義工具可以通過兩種方式同用戶進行交互，一種是基于文本的方式，一種是基于圖形的方式。基于文本的方式易于實現(xiàn)，在目前的辦公工作流系統(tǒng)中應用比較廣泛。但對用戶來說，這種定義方法使用比較復雜，不直觀，難于創(chuàng)建復雜的流程。而圖形化的定義方式具有直觀、易于使用的特點，能夠方便的定義復雜的流程。由于IVR系統(tǒng)菜單的調(diào)整、播放音頻文件的更換、業(yè)務處理過程的變化等原因，用戶的工作流程可能會經(jīng)常發(fā)生變化，直觀的圖形化定義界面可以使得流程的定義變成一種簡單而高效的工作。用戶可以相當方便的根據(jù)實際變化情況對流程作出修改，而無須修改程序的源代碼，從而大大提高工作效率和系統(tǒng)的應變能力，將系統(tǒng)的控制權真正交給用戶，而不是掌握在開發(fā)者手中。因此，在設計中選擇采用圖形化的工作流方式來定義IVR系統(tǒng)的流程。

3.2.4IVR系統(tǒng)流程的節(jié)點抽象和定義

在用戶界面采用了圖形化的過程方式來定義IVR系統(tǒng)的流程，那么流程定義工具就需要向用戶提供一組抽象描述流程的基本設計控件，用戶通過使用這些基本控件來可視化的搭建IVR系統(tǒng)的流程。而基本設計控件的選擇就同整個系統(tǒng)所選擇的過程定義模型密切相關，過程定義模型的一個重要的功能就是為建模用戶提供抽象描述實際業(yè)務處理過程所必須的設計元素。在設計本文所描述的IVR系統(tǒng)流程定義工具是，采用的是基于流程節(jié)點的過程定義模型，流程節(jié)點是整個IVR系統(tǒng)流程定義工具定義的唯一設計元素。因此，在用戶界面中，向用戶提供的是流程中所涉及到的各種流程節(jié)點控件，用戶通過在設計界面中添加以圖形表示的各種流程節(jié)點控件，填寫相應的流程節(jié)點相關屬性信息，之后通過使用帶箭頭的連線來連接不同的流程節(jié)點來可視化的定義流轉(zhuǎn)順序。

根據(jù)IVR系統(tǒng)的流程和本文系統(tǒng)應用的具體項目需求，定義出在大多數(shù)IVR系統(tǒng)常用的流程9種節(jié)點類型。開始節(jié)點：這類節(jié)點定義了流程的開始，以及設置整個流程的全局變量；結束節(jié)點：這類節(jié)點定義了流程的結束，即對應的掛機操作；放音節(jié)點：這類節(jié)點定義了流程中所涉及到的放音或者放音取鍵操作，其屬性有放音的文件名稱；人工輸入節(jié)點：這類節(jié)點定義了流程中需要人工輸入按鍵的操作，其屬性有最少輸入鍵位、最大輸入鍵位、結束按鍵、重試放音文件名、非法輸入放音文件名；菜單節(jié)點：這類節(jié)點定義了流程中需要播放菜單的操作，其屬性有菜單語音文件、播放次數(shù)、菜單出口(多個)；轉(zhuǎn)接節(jié)點：這類節(jié)點定義了流程中需要轉(zhuǎn)接的操作，其屬性有轉(zhuǎn)接的目標號碼；錄音節(jié)點：這類節(jié)點定義了流程中需要錄音的操作，其屬性有錄音文件存放的位置、錄音格式、錄音時常、錄音結束DTMF碼；自定義節(jié)點：這類節(jié)點定義了流程中涉及到的其它操作，例如查詢、插入數(shù)據(jù)庫等。分支節(jié)點：這類節(jié)點定義了流程中涉及到分支操作，例如根據(jù)系統(tǒng)變量值進入不同的分支流程等。表3.1給出了相關圖元的具體樣式。

表3.1流程定義工具中的相關圖元

3.3可視化過程定義工具的設計

作為流程工具，它的設計原則就是，使用最簡單易懂的方式，適合各層次的開發(fā)人員最快速的開發(fā)業(yè)務流程。本工具采用的是圖形開發(fā)的方法，但是最終配置的視圖數(shù)據(jù)是要轉(zhuǎn)化IVR系統(tǒng)執(zhí)行引擎可解析的模型數(shù)據(jù)(含有VoiceXML的Web頁面)。

在設計上，首先是定義主框架類，這些類的作用是提供一個通用的可視化流程定義類包，為后面的設計帶來便利，以便對界面組件的實現(xiàn)提供便利。

3.3.1主框架類包的定義

主框架類包CDiagramEditor是整個流程定義工具的骨架。它是由一個從CWnd類(MFC基礎類)繼承而來editor類、一個data類、一個畫圖對象類和一些幫助類所組成的。在設計的時候，考慮到程序的可復用性和可擴展性，將editor和data類分開，使其既可以在dialog應用程序中使用，也可以在doc/view應用程序中使用，如圖3.4所示。

3.3.2主框架類描述

下面給出各個類的詳細描述：

CDiagramEditor類

CDiagramEditor類繼承于CWnd類，它是處理窗口詳細的相關操作，所封裝的是一個基礎的矢量編輯器，它所生成的是圖(diagrams)而不是圖片(graphics)。所以它支持小于和大于正常窗口的虛擬屏幕(virtualscreen)、網(wǎng)格抓取(snaptogrid)、拷貝/復制、“無限制”(所謂無限制，只是在設置撤銷棧的大小時取值較大，讓使用者感覺上是無限制，其實是有限的)的撤銷、放大等等，由于它使用了與之“隔離”的數(shù)據(jù)容器，所以它既可以被加入對話框(dialog)和文檔/視圖(doc/view)程序里面去。通常，這個類僅僅在繪圖函數(shù)不足以滿足需要的時候來繼承使用的。

CDiagramEntityContainer類

CDiagramEntityContainer類包含了CDiagramEditor類里的數(shù)據(jù)。它管理了如拷貝、粘貼、和撤銷這類的操作集合。同樣為了能在文檔/視圖使用，它與CDiagramEditor類分成兩個類來實現(xiàn)。這也是一些函數(shù)功能在這兩個類里面同時存在的原因。

CDiagramEntityContainer類包含了一個CObArray對象，它是由一組繼承CDiagramEntity類的實例，用來為編輯器存放實時的數(shù)據(jù)。同時，也包含了一個CDiagramClipboardhandler指針(作為一個或者多個編輯器間的剪切板)。它還包含了一組CUndoItem用來實現(xiàn)撤銷棧。

通常，CDiagramEntityContainer類是不用繼承的，一個CDiagramEditor需要一個CDiagramEntityContainer的實例來保存住對象的數(shù)據(jù)。在文檔/視圖應用程序中它作為外部實例，而在對話框應用程序中是作為內(nèi)部的實例來管理所有的數(shù)據(jù)。對于前者，需要在document類中申明CDiagramEntityContainer成員，并且需要調(diào)用CDiagramEditor::SetCDiagramEntityContainer來創(chuàng)建；對于后者，則任何特別的操作都不需要去操作，因為在CDiagramEditor::Create被調(diào)用的時候CDiagramEntityContainer將會被自動創(chuàng)建。

CDiagramClipboardHandler類

CDiagramClipboardHandler類為一個或者多個編輯器管理剪切板。它保持著所有CDiagramEntity類實例的拷貝。

CUndoItem類

CUndoItem類表示CDiagramEntityContainer類中撤銷棧的單點入口。

CDiagramEntity類

CDiagramEntity類所有繪圖對象的基類，并由CDiagramEditor類控制和管理。它是繼承CObject類，同時允許其實例的集合以CObArrays方式存儲。通常，在實現(xiàn)所有繪圖類的時候，只要繼承CDiagramEntity類，覆蓋(overridden)Clone和Draw方法，返回該類指針的拷貝即可。

為了滿足IVR系統(tǒng)執(zhí)行引擎所需要的文件，CDiagramEntity類支持基本的存儲功能，可以存儲成.txt文件。在生成符合具體業(yè)務流程所產(chǎn)生的文件格式的時候可以通過覆蓋FromString和GetString來實現(xiàn)。針對第三章對流程節(jié)點抽象，9種流程節(jié)點的屬性各不相同，因此，每一個流程節(jié)點類都應該擁有自己的屬性對話框，這些對話框類繼承了CDiagramPropertyDlg類。實現(xiàn)的時候只要這些流程節(jié)點類擁有一個繼承CDiagramPropertyDlg類的實例作為成員變量就可以完成。

CDiagramLine類

CDiagramLine類主要是完成IVR系統(tǒng)流程中各個節(jié)點的連接。在連接線的設計過程中，首先，使用者不需要強制的設置線的大小，應該由其成員函數(shù)來設置(SetRect)完成；其次，相應點擊事件的區(qū)域應該不是矩形，它是一條線；這些都需要在這個類中實現(xiàn)，這樣才能有很好的繼承性。

CDiagramMenu類

CDiagramMenu類是一個很簡單的類，它的作用是可以方便的定義出彈出(popup)菜單，所完成的功能是在右鍵單擊各個流程節(jié)點的時候彈出菜單。

CDiagramPropertyDlg類

CDiagramPropertyDlg類所展現(xiàn)的是CDiagramEntity對象的屬性對話框。在IVR系統(tǒng)流程中反應出來的是對應各個流程節(jié)點的屬性設置對話框。

CTokenizer類

CTokenizer類的作用也很簡單，它是用來對CString和CStringArray的做stringtoken的。

CGroupFactory類

CGroupFactory類為CDiagramEntity組產(chǎn)生唯一的標識符。它采用了MFC中定義“組機制”[23]技術，即可以在屏幕上類似于移動單個實體那樣移動整個組的實體集合。

3.3.3Link類的設計

在業(yè)務流程編輯過程中，流程控制非常重要。流程的走向表現(xiàn)為節(jié)點圖元之間的關聯(lián)關系。根據(jù)公式2-3，它的抽象語法規(guī)則可以描述為式(3-1)表示節(jié)點圖元可以連接多個關聯(lián)關系，每個關聯(lián)關系必須連接到一個節(jié)點圖元。

每一個節(jié)點保存自己的唯一的節(jié)點名稱，由CArrowLine類來保存其關聯(lián)關系，因為兩個節(jié)點之間的關聯(lián)關系只有二向性，所以只需要保存一個節(jié)點名稱和一個節(jié)點名稱。類圖如圖3.5所示，CLinkFactory類的作用是一個獲取當前節(jié)點名稱，CNodeMenu類是菜單(Menu)節(jié)點類，繼承CDiagramEntity類。圖中只是以CNodeMenu類未代表來表示所有的節(jié)點類。

3.4目標文件的描述與分析

3.4.1文件基本框架描述

本文設計的IVR系統(tǒng)的流程文件是含有VoiceXML標簽的Web文件，因此，首先，文件的基本框架必須符合HTML文件框架。而對語音節(jié)點的具體描述是通過某個VoiceXML標簽或者某些具體標簽的集合，其語法符合VoiceXML語音規(guī)范。與此同時，有編程經(jīng)驗的用戶可以添加自定義代碼來定制一些具體Web數(shù)據(jù)操作，譬如，jsp或者asp的代碼。如圖3.6所示。圖3.6目標文件基本框架圖例如，放音節(jié)點的完整文件描述如下：

3.4.2目標文件的生成

目標文件的基本框架已經(jīng)確定，所有的流程節(jié)點文件都應該滿足這個基本框架。不同點就在于語音節(jié)點的描述有所不同，而語音節(jié)點的描述就是標準的VoiceXML語言?？梢钥吹剑聦嵣蟅oiceXML文件和普通的html文件并沒有實質(zhì)的不同，可以完全使用相同的思維方式去理解，唯一不同的是針對特殊的語音VoiceXML應用了相應特別的標簽，具體可以參考w3上有關VoiceXML的規(guī)范(詳見參考資源)。所以，在VoiceXML生成上完全可以調(diào)用標準的XML文件生成類來生成。目標文件生成的類圖如圖3.7所示。圖3.7目標文件生成類圖MainFramwork

文件的主框架，主要是標準html標簽的生成；

CreateVXMLTree

調(diào)用標準的XML類生成VoiceXML樹；

UserAddContent

插入用戶輸入的自定義代碼；

OutPutFile

輸出目標文件。

3.5IVR系統(tǒng)執(zhí)行引擎的分析

IVR系統(tǒng)執(zhí)行引擎作為IVR系統(tǒng)的核心，是整個系統(tǒng)的控制中樞。它所完成的功能是對IVR系統(tǒng)業(yè)務流程的解釋和驅(qū)動。

3.5.1基于VoiceXML的執(zhí)行引擎

隨著Internet和Web技術的迅速發(fā)展，越來的企業(yè)開始建立自己的門戶網(wǎng)站，同時又擁有自己的IVR系統(tǒng)(如圖3.8所示)，但是兩套系統(tǒng)完全獨立，語音系統(tǒng)和數(shù)據(jù)系統(tǒng)沒有任何交互或者只有很少的交互。而建立IVR系統(tǒng)的目標就是給客戶更好的體驗，使客戶能方便的通過電話完成更多以前需要登陸企業(yè)門戶網(wǎng)站，或者親自去企業(yè)或其網(wǎng)點去辦理的業(yè)務，這就需要IVR系統(tǒng)能跟后臺數(shù)據(jù)系統(tǒng)有更多更好的交互?！罢Z音門戶”的概念出現(xiàn)也愈發(fā)的證明這一點。

通過3.1節(jié)的分析，可以看出傳統(tǒng)的IVR系統(tǒng)的執(zhí)行引擎雖然完成了對流程的解釋和驅(qū)動，但是為了獲得更多的客戶的資料和配合企業(yè)的業(yè)務邏輯，就得需要再去和后臺的企業(yè)數(shù)據(jù)系統(tǒng)去交互，這勢必增加了整個系統(tǒng)的負擔，相應的運營風險也就隨之加大。

從另外一個方面，到目前為止，人們從Internet獲取各種資源時，還只能是借助計算機來實現(xiàn)[24]。而實際上，電話具有比計算機更高的普及率，如果允許人們通過電話來訪問Internet的資源，那么這對于Internet的應用發(fā)展必將是一次質(zhì)的飛躍。在這類應用前景的驅(qū)動下，VoiceXML使得用戶可以通過電話按鍵或語音來訪問Internet上的各種資源，它是語音瀏覽技術以及語音互聯(lián)網(wǎng)的核心。圖3.9描述了一個基于VoiceXML的現(xiàn)代企業(yè)語音門戶的系統(tǒng)結構。

人們在Internet上瀏覽的網(wǎng)站是程序員們使用HTML(HypertextMarkupLanguage)開發(fā)的Web應用程序，在這些網(wǎng)站上可以瀏覽到人們所需要的文字、圖片、視頻等信息。與這種方式類似，程序員可以開發(fā)基于VoiceXML的語音應用程序，從而把用戶需要的信息以語音的方式提供給用戶。用戶可以通過手機或者電話等呼叫終端來訪問這類應用程序得到他們想獲得信息。圖3.10顯示[25]了基于VoiceXML的語音應用和基于HTML的Web應用的相似和不同。

3.5.2基于VoiceXML執(zhí)行引擎的結構分析

執(zhí)行引擎的目的是為了解釋和驅(qū)動業(yè)務流程，本文設計的IVR系統(tǒng)的流程系統(tǒng)中，語音節(jié)點的類型都符合VoiceXML的基本標簽。按照本文2.2.2中描述的VoiceXML基本體系結構，基本的執(zhí)行引擎應該要包含3個部分：文檔服務器、VoiceXML解析器和電話平臺。因此執(zhí)行引擎的基本架構如下圖(圖3.11)描述。

WebServer模塊：用來執(zhí)行和發(fā)送Web相關的請求和文檔；

VoiceXMLparser模塊：解析VoiceXML頁面，同時協(xié)調(diào)與WebServer和TelephonyAPI之間的聯(lián)系；

TelephonyService模塊：調(diào)用放音、收鍵等統(tǒng)一的接口。

3.6IVR系統(tǒng)執(zhí)行引擎的設計

IVR系統(tǒng)執(zhí)行引擎驅(qū)動著整個IVR系統(tǒng)的業(yè)務流程，本文設計的IVR系統(tǒng)是基于VoiceXML技術，如節(jié)3.2里描述的系統(tǒng)架構，執(zhí)行引擎主要分為兩大塊：VoiceXMLParser：負責提供VoiceXML的解析、同WebServer的交互和TelephonyService的交互。TelephonyService：驅(qū)動語音卡語音動作進行相關的操作。

3.6.1執(zhí)行引擎的總體架構設計

系統(tǒng)的架構符合VoiceXML標準技術，與傳統(tǒng)的IVR執(zhí)行引擎相比較，除了支持相關的語音業(yè)務，對于數(shù)據(jù)業(yè)務的操作則完全交給DoucumentServer(Webserver)來處理。語音平臺完全不用關心怎樣去操作數(shù)據(jù)業(yè)務，大大降低了開發(fā)的風險和難度。譬如，銀行用戶在使用電話在訪問IVR系統(tǒng)的時候，需要查詢自己賬戶的余額，語音平臺只要處理播報余額的工作，在向WebServer提交文檔(Web頁面)請求后，WebServer便會處理相關的數(shù)據(jù)操作，查詢數(shù)據(jù)庫獲得余額，只要將結果返回給VoiceXML解析器，再由VoiceXML解析器通知語音平臺完成播報余額的操作。

系統(tǒng)交互序列圖[26]如圖3.12所示。當一通呼叫呼入的時候，語音平臺會自動檢測到有呼叫到達。隨后，語音平臺(TelephoneService)會將呼叫進入的事件發(fā)送給VoiceXML解析器，VoiceXML解析器通過分析URL的內(nèi)容去裝載初始的文檔。隨后，VoiceXML解析器就會發(fā)送一個請求給DocumentServer(WebServer)，獲取初始的文檔，相當于用戶剛剛登陸到一個網(wǎng)站的主頁。WebServer在解析完相關的數(shù)據(jù)業(yè)務(例如：查詢數(shù)據(jù)庫判斷來電是否為黑名單)后，就會向VoiceXML解釋器回復一個文檔，同時告訴VoiceXML解析器需要解析執(zhí)行的語音操作，而VoiceXML解釋器在解析完所收到返回的文檔后會引導語音平臺來實現(xiàn)語音系統(tǒng)的相關操作。在這個過程之后VoiceXML解釋器會收到語音平臺發(fā)送過來的結果，根據(jù)結構VoiceXML解釋器收到的結果不同，觸發(fā)其向WebServer發(fā)送的請求的不同，直到整個一通呼叫結束。這就如同用戶在登陸網(wǎng)站的時候，根據(jù)自己的喜好選擇了不同的頁面瀏覽，直到退出瀏覽器，完成瀏覽。圖3.12IVR系統(tǒng)執(zhí)行引擎系統(tǒng)交互序列圖3.6.2VoiceXML解析器的設計

作為VoiceXML語言的解釋工具，文檔解析是VoiceXML解析器主要任務，也是執(zhí)行引擎的重要組成部分，文檔解析的內(nèi)容決定了執(zhí)行平臺的下一步操作，也是整個系統(tǒng)運行的核心。因為VoiceXML文檔首先是一個XML文檔，所以主要包含對象樹生成模塊和語義解釋模塊兩個部分。其中對象樹生成模塊是對VoiceXML文檔進行XML方式的解析，解釋模塊使用FIA算法對生成的對象進行解析。圖3.13描述了VoiceXML解析器文檔解析的模型。圖3.13VoiceXML解析器文檔解析模型圖1．對象樹生成模塊

計算機無法直接對VoiceXML文檔操作來實現(xiàn)解釋功能，必須把VoiceXML文檔轉(zhuǎn)換成易識別、易操作的數(shù)據(jù)結構。所以，在進行VoiceXML語義分析之前，首先要按照對XML文件的處理方式，用接口程序?qū)ξ臋n進行分析，生成一棵VoiceXML對象樹。該樹包含了從文檔中獲取的數(shù)據(jù)和處理數(shù)據(jù)的方法，并完成部分的初始化，構建索引等輔助工作。這棵樹是后面解釋模塊的核心基礎。對象樹生成模塊負責讀取從文檔獲取模塊傳來的VoiceXML文檔，調(diào)用接口程序?qū)ξ臋n分析，生成對象樹，并把此對象樹的指針傳給解釋器。

目前最通用的接口為DOM(DocumentObjectModel)和SAX(SimpleAPIforXML)。

DOM[27]即文檔對象模型，是W3C開發(fā)的一組獨立于語言和平臺的結構化文檔編程接口，它定義了文檔的邏輯結構以及訪問和操縱文檔的方法。使用DOM模型，程序所面對的XML文檔不是一個文本流，而是一棵對象樹。程序員可以方便的創(chuàng)建文檔、導航其結構，或增加、修改、刪除、移動文檔的任何部分。

SAX[28]的誕生是在XML-DEV討論組上，提出他的原因是有一些情況不適用DOM接口，而且DOM實現(xiàn)太大而且比較慢。SAX接口規(guī)范是XML分析器和XML處理器提供的較XML更底層的接口。它能提供應用以較大的靈活性。SAX是一種事件驅(qū)動的接口，它的基本原理是，由接口的用戶提供符合定義的處理器，XML分析時遇到特定的事件，就去調(diào)用處理器中特定事件的處理函數(shù)。SAX的主要限制是它無法向后瀏覽文檔。實際上，激發(fā)一個事件后，語法分析器就將其忘記。

在本文設計的系統(tǒng)中，采用了DOM接口和SAX相結合的方式：使用SAX構建DOM樹，主要是因為對VoiceXML語言解釋的過程中，需要反復瀏覽不同的接點元素，采用DOM樹結構會方便許多。結合DOM和SAX的優(yōu)點，用SAX建立一棵仿DOM的樹，樹的數(shù)據(jù)結構的定義更加符合自身的要求，不僅簡練，而且在定義節(jié)點的同時實現(xiàn)了操作。圖3.14顯示了用SAX解析方法模擬DOM樹的過程。圖3.14用SAX解析方法模擬DOM樹的過程2．語義解釋模塊

語義解釋模塊的主要功能是實現(xiàn)流程文檔的解釋工作，控制整個的會話過程和與輸入輸出功能模塊實現(xiàn)交互操作。該模塊處理的數(shù)據(jù)結構是對象樹生成模塊提供的對象樹。模塊功能的實現(xiàn)依賴于對象樹提供的結構及樹節(jié)點上相應的操作，對象樹表述了文檔的全部信息以及處理方法，語義解釋模塊依照這棵樹上的信息完成所有控制操作。

VoiceXML文檔結構和執(zhí)行過程

每個VoiceXML文檔都構成一個有限狀態(tài)自動機，主要是由Dialog組成，主要分為單文檔和多文檔地執(zhí)行過程。

(1)單個文檔的執(zhí)行過程。文檔默認的從第一個Dialog開始執(zhí)行，Dialog沒有指定后繼的Dialog時，文檔解釋結束。

(2)多文檔的應用的執(zhí)行。如果在會話過程中希望使用多個文檔來共同完成一個工作，這時就需要采用多文檔方式。多文檔方式的優(yōu)點是：應用根文檔的變量可以為其他子文檔所共享，信息可以被共享和獲取，可以從一個文檔跳到另一個；應用根文檔的語法可以一直保持激活的狀態(tài)，可以保證用戶總是和通用的Form或Menu的交互，例如提示給用戶的一些具有普遍性的幫助信息等。

Form解釋算法[29](FIA:FormInterpretationAlgorithm)

Form解釋算法對VoiceXML文檔進行了語義分析和解釋，驅(qū)動Form、Menu和用戶的交互。FIA算法主要分為兩個階段：初始化階段和主循環(huán)階段。

(1)初始化階段：完成Form內(nèi)各種變量的初始化操作，包括計數(shù)器置為1，初始化一般變量和Item變量等操作。

(2)主循環(huán)階段又被分為三個子階段：選擇階段、收集階段和處理階段。這三個子階段循環(huán)運行，直到解釋完成為止。

選擇階段:選擇要執(zhí)行的Item，一般情況是順序選擇沒有執(zhí)行的Item。當沒有發(fā)現(xiàn)要執(zhí)行的Item時，解釋操作完成。

收集階段:完成對用戶輸入信息和事件的收集。首先訪問選定的Item來播放提示音，可以根據(jù)提示次數(shù)選擇提示音，激活語音或DTMF的Grammar，然后等待收集用戶輸入或事件。

處理階段：對收集到的用戶輸入信息和事件進行處理。如果用戶輸入后，對用戶輸入信息進行語法匹配，執(zhí)行相應的Filled元素來執(zhí)行輸入處理。如果用戶輸入匹配的是另一個不同Dialog中的Grammar，則完成當前Dialog的解釋，跳轉(zhuǎn)到新的Dialog；如果事件被拋出，選擇正確的Catch元素來處理，并執(zhí)行相應的事件處理過程。在處理完成后，重新進入選擇階段。

解釋器完成文檔的語義功能。它獲得對象生成模塊生成的VoiceXML對象樹。按照算法FIA(表單解釋算法)搜索VoiceXML對象樹、讀取樹節(jié)點的節(jié)點屬性、調(diào)用資源代理模塊，通過輸入輸出模塊接口與客戶進行語音交互，完成整個交互流程。

3.6.2TelephoneyService的設計

當VoiceXML解析器做完解析工作之后，遇到需要語音操作時，就得依靠調(diào)用TelephoneyAPI來完成，同時TelephonyService需要向VoiceXML解析器去返回相應的語音操作結果事件。圖3.15描述了這一過程。圖3.15VoiceXML解析器與TelephonyService交互圖調(diào)用的過程相對簡單，只需按照標簽的定義調(diào)用相應的API即可，如當解析到標簽的時候直接調(diào)用播放語音文件接口。需要向TelephoneyService調(diào)用API所涉及到的VoiceXML標簽如表3.2所示。

表3.2涉及到IVR系統(tǒng)語音操作的VoiceXML標簽表標簽名稱說明<prompt>播放語音文件或者隊列<transfer>呼叫轉(zhuǎn)移<record>錄音<disconnect>斷開語音當TelephonyService處理完相應的語音操作的時候，需要向VoiceXML解析器返回操作結果事件，由VoiceXML解析器重的接收線程來獲取，返回事件分為兩類：正常事件和掛斷事件。正常事件指的是語音卡執(zhí)行完動作后返回的結果，分為執(zhí)行成功和失敗事件；掛斷事件表示語音卡在收到用戶掛機事件后發(fā)送給解析器的事件。同時，在VoiceXML解析器向語音平臺調(diào)用TelephoneyAPI的同時，會啟動一個計時器來進行超時判斷，來處理如果語音平臺沒有回消息的情況。

3.7本章小結

本章首先分析了傳統(tǒng)IVR系統(tǒng)的優(yōu)缺點，并基于可視化建模語言設計了IVR系統(tǒng)的總體結構。其次在對過程化定義工具的使用上才采用圖形化的方式來實現(xiàn)和用戶交互，滿足簡單易用的特點。最后，分析了傳統(tǒng)的IVR系統(tǒng)執(zhí)行引擎的特性，引入了VoiceXML技術，設計出基于VoiceXML的IVR系統(tǒng)執(zhí)行引擎的基本框架。第四章在系統(tǒng)分析和系統(tǒng)總體設計之后，就進入了系統(tǒng)實現(xiàn)階段。該階段主要是對IVR系統(tǒng)業(yè)務編輯工具和執(zhí)行引擎部分進行實現(xiàn)。

4.1可視化流程定義工具實現(xiàn)

Windows操作系統(tǒng)具有友好的圖形界面，越來越被國內(nèi)外眾多的用戶所喜歡[30]，因而開發(fā)Windows應用程序?qū)⒕哂袕V泛的市場?？捎糜陂_發(fā)Windows應用程序的語言較多，其中VisualC++是眾多軟件開發(fā)人員所喜歡的語言之一，它是一種可視化的面向?qū)ο蟪绦蛘Z言，其MFC基類封裝了WindowsAPI函數(shù)，提供了許多功能模塊，使得開發(fā)人員可以利用MFC快速、高效地開發(fā)Windows應用程序，減少了許多重復勞動，提高了代碼利用率和程序開發(fā)效率，縮短了軟件開發(fā)周期，使開發(fā)人員有更多的時間去研究新的問題。

完成了基礎類的設計之后，整個IVR系統(tǒng)的流程工具都是基于這個基礎類包來完成的。作為流程編輯工具，流程編輯器的設計應當遵循如下原則：方便簡便，便于開發(fā)人員掌握，適合與不同的業(yè)務不同行業(yè)IVR系統(tǒng)的工作流程。所以在設計中，以樹形結構反映工作流程的概念，如圖4.1所示。

從圖4.4所示結構中，通過主窗體可以訪問其它窗體操作，同時控制窗體與類模塊的信息交互。系統(tǒng)中的各個窗口的實現(xiàn)均是基于基礎類包的。下面詳細介紹IVR系統(tǒng)流程工具各個部分的實現(xiàn)。其實現(xiàn)工具的內(nèi)容詳見文獻[31]。

主程序是IVR系統(tǒng)流程定義工具的主體，它包括各個窗口的定義、流程類的定義、節(jié)點類定義等。主程序通過主窗體類定義將其它各個類窗體組織在一起，同時負責各子窗體之間的信息交互。主窗體類則定義了流程間的組織結構，它通過用戶界面操作協(xié)助用戶完成流程制作，同時生成含有VoiceXML標簽的Web頁面交給執(zhí)行引擎進行解釋執(zhí)行。

主窗體主要負責各個窗體和類模塊之間的信息交互和訪問控制。圖4.2描述IVR系統(tǒng)業(yè)務流程定義工具的主窗體界面。分為工具箱窗體、菜單窗體、流程編輯(畫布)窗體、屬性窗體，同時包括流程節(jié)點的訪問控制。圖4.2IVR系統(tǒng)流程定義工具主窗體工具箱窗體：工具箱窗體提供系統(tǒng)支持節(jié)點類型控件的選擇，用戶通過拖拽方式添加節(jié)點以制作流程。工具箱窗體類主要包括工具箱窗體的事件響應和主窗體交互部分，提供每種實現(xiàn)方法。

菜單窗體：菜單窗體是提供關于整個系統(tǒng)流程的打開、編輯等操作。

屬性設置窗體：屬性窗體為每一類節(jié)點提供屬性設置功能，其中包括屬性窗體操作、與主窗體信息交互兩大類，提供各個節(jié)點所涉及到的每種屬性窗體的實現(xiàn)方法。

流程編輯(畫布)窗體：此窗體類提供了制作流程的畫布操作。在此窗口定義了一個畫布控件;流程編輯窗體接收畫布對象的事件，提交給主窗體，同時通過與主窗體的信息交互控制在畫布上確保正確制作流程。

主程序除了上述4種主要的模塊定義之外，還有一些窗體類和類模塊定義，主要負責各種屬性的設置和操作:同時為使流程制作更加人性化，主程序增加了一些通用編輯功能。

以上為主程序的設計及其部分實現(xiàn)。在實現(xiàn)中通過引用窗體控件和畫布窗體類定義，集成了對畫布控件和節(jié)點控件的訪問操作。

4.2IVR系統(tǒng)執(zhí)行引擎的實現(xiàn)

IVR系統(tǒng)執(zhí)行引擎是整個IVR系統(tǒng)的核心系統(tǒng)，它負責對之前由IVR系統(tǒng)流程定義工具生成的中間文件(含有VoiceXML標簽的Web頁面)解釋和驅(qū)動。本文設計的IVR系統(tǒng)是基于VoiceXML技術，以開源OpenVXI項目為基礎，設計并實現(xiàn)的IVR系統(tǒng)執(zhí)行引擎部分。

OpenVXI[32]是一種簡便的開源庫，用來解釋VoiceXML對話標記語言(dialogmarkuplanguage)。為了避免其它私有的標準，它嚴格支持VoiceXML2.0草案(現(xiàn)在已經(jīng)支持部分3.0的標準),同時OpenVXI是一個跨平臺的開發(fā)系統(tǒng)。

OpenVXI本身只是VoiceXML平臺的一個組件[32]，它只是提供了簡單的語音識別、語音提示和TTS(text-to-speech)功能。而對于電話功能，由于語音卡的種類繁多，同時VoIP(VoiceoverIP)技術的快速發(fā)展，就需要使用者自己提供實際的組件和函數(shù)進行整合。既便如此，OpenVXI還是提供一個強大的基本框架讓使用者構建自己的語音平臺。

4.4.1OpenVXI的系統(tǒng)架構

根據(jù)圖2.3描述的VoiceXML平臺的基本體系結構分析，OpenVXI符合基本架構，具體的系統(tǒng)架構圖如圖4.3所示。整個平臺執(zhí)行VoiceXML頁面，并提供與電話網(wǎng)絡連接的服務，平臺總共分4個部分：

1．主進程、操作管理和維護系統(tǒng)：一個收集系統(tǒng)管理和錯誤報告的工具。這個核心組件通過創(chuàng)建線程的方式來喚醒VoiceXML瀏覽器。

2．OpenVXI：負責解釋VoiceXML標記語言和語音平臺返回的呼叫標志信息(通過返回相應的事件信息)。

3．OpenSpeechBrowserPIK：提供了為系統(tǒng)運行所必要的高層次(high-level)服務，包括識別引擎、語音引導引擎、Internetfetch庫(提供通過URL對web服務器訪問的庫)、ECMAScript[32]引擎。OpenVXI通過系統(tǒng)提供的函數(shù)接口來訪問這些組件，這些接口不需要定義和實現(xiàn)各種機制來滿足與底層電話系統(tǒng)軟件系統(tǒng)之間的通訊，而是通過使用支持Client/Server模式的TCP/IP協(xié)議來實現(xiàn)。

4．Telephonyandbaseservices:需要能接收到電話的基本操作系統(tǒng)服務和電話服務。

圖4.3OpenVXI系統(tǒng)架構圖4.4.2OpenSpeechBrowserPIK組件結構

圖4.4描述了OpenSpeechBrowserPIK的架構和組件構成，包括為完成語音識別和TTS功能整合的產(chǎn)品SpeechWorks。所有的組件都被設計成很容易的去訪問。這個語音瀏覽器(SpeechBrowser)包括：

1．VXI：解析所有的VoiceXML標記，并且擔當程序中的主控作用。VXI實現(xiàn)了VoiceXML1.0中所有必需(mandatory)的部分和大部分的可選功能。

2．XMLParserInterface：提供對XMLDOM解析器的訪問，現(xiàn)在的實現(xiàn)方式是通過直接調(diào)用開源的ApacheXercesSAXandDOMparse解析接口。

3．InternetInterface：通過http://和file://的方式訪問應用文檔(即URL的方式訪問Web頁面)，同時也支持POST的方式給應用服務器返回數(shù)據(jù)。這方面的實現(xiàn)是整合了開源W3CLibwww開發(fā)庫。

4．ECMAScript(JavaScript)Interface：提供了對ECMAScript執(zhí)行服務的訪問。相關的實現(xiàn)整合了MozillaSpiderMonkey開源引擎。

5．LoggingInterface：用來報告系統(tǒng)級別的錯誤、事件和診斷信息。它是將日志存儲成日志文件，并且可以選擇進行標準的輸出。

核心瀏覽器中與語音平臺相關的API主要包括：

1．RecognizerInterface：提供語法管理和由VoiceXML指定的識別服務(例如：收取DTMF碼)，包括動態(tài)語法創(chuàng)建和語法構建。它通過TelephonyService來獲取呼叫信息，并且已經(jīng)在OpenSpeechBrowser中整合。

2．PromptingInterface：提供完整的放音服務，包括播放可變語音。它必須處理語音文件并且提供語音服務。OpenSpeechBrowserPIK已經(jīng)整合了支持幾種語言的TTS。

3．TelephonyInterface：提供呼叫控制服務，包括發(fā)送語音平臺的時間、轉(zhuǎn)接和掛斷電話。OpenSpeechBrowserPIK已經(jīng)實現(xiàn)了與底層的語音平臺交互，并抽象了API來提供呼叫控制服務。

4．ObjectInterface：提供了對對象的訪問。通過對象元素，平臺可以訪問定義的那些對VoiceXML語音的擴展。對象可以很容易的被定義成適合語音平臺需要的呼叫控制擴展、CTI系統(tǒng)的彈屏顯示或者其它一些需求。圖4.4OpenSpeechBrowserPIK組件構成圖通過對OpenVXI的描述，可以看出：模塊化和分層次的設計使得在平臺里的各個組件之間即相對獨立，又相互聯(lián)系、互相協(xié)作來完成整個平臺的功能。使用者可以通過實現(xiàn)平臺提供的各種接口來實現(xiàn)對基于各種硬件或者軟件的語音系統(tǒng)的整合。本文設計的IVR系統(tǒng)所涉及到的是模擬語音卡，所以對與錄音、放音、取鍵都由語音卡所提供的API來完成即可。

4.4.3接口實現(xiàn)（取鍵、錄音、放音、轉(zhuǎn)接）

OpenSpeechBrowserPIK自身就是支持標準的VoiceXML2.0的標準，同時對VoiceXML的解析能力比較強大，又同時整合了Apache的XML解析器、W3C的LIBWWW進行Web訪問和MozillaSpiderMonkey作為ECMAScript的執(zhí)行器，本文主要是通過實現(xiàn)相應的語音平臺接口來實現(xiàn)IVR系統(tǒng)的執(zhí)行引擎。沒有對VoiceXML解析功能做過多的修改。

RecognizerInterface(識別接口)的實現(xiàn)

對應Recognizer的接口,OpenVXI分別針對收取用戶按鍵(DTMF碼)和語音識別(speechrecogni