首頁>>廠商>>CTI系統(tǒng)平臺廠商>>易谷網(wǎng)絡(luò)

基于VoiceXML技術(shù)可視化IVR設(shè)計和實(shí)現(xiàn)(二)

上海易谷網(wǎng)絡(luò)科技有限公司 查瑋 2009/12/29

基于VoiceXML技術(shù)的可視化IVR系統(tǒng)設(shè)計和實(shí)現(xiàn)(一)

圖3.1 IVR系統(tǒng)整體結(jié)構(gòu)圖

3.2可視化過程化定義工具的分析

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

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

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

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

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

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

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

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

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

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

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

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

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

　　IVR系統(tǒng)的過程定義工具是一個可視化的軟件工具，它主要用于定義工作流模型中各個活動之間的關(guān)系[22]。工作流程過程定義向用戶提供對實(shí)際業(yè)務(wù)處理過程分析、建模的手段。其輸入輸出可以用圖3.2表達(dá)：

圖3.2 IVR系統(tǒng)流程開發(fā)工具的輸入和輸出

其功能可以細(xì)分為：

1. 向用戶提供定義工作流的操作界面；



2. 根據(jù)用戶的輸入自動生成以文本形式表達(dá)的IVR系統(tǒng)流程抽象描述；



3. 將以文本形式表達(dá)的工作流抽象描述發(fā)送給格式化工具組件。

圖3.3 IVR系統(tǒng)流程定義工具用例圖

1. 新建流程：用戶通過選擇“新建工作流模型”菜單或單擊工具欄上相應(yīng)按鈕新建一個空的模型文件。



2. 繪制流程：用戶使用定義工具提供的各種建模組件繪制模型。主要包括：IVR系統(tǒng)流程中涉及到各個節(jié)點(diǎn)繪制、各個連接點(diǎn)的連線的繪制。



3. 編輯流程：用戶可以用直接操作節(jié)點(diǎn)元素，包括選擇、刪除、平移等功能。



4. 設(shè)置節(jié)點(diǎn)屬性：用戶通過設(shè)置節(jié)點(diǎn)屬性對話框來設(shè)置節(jié)點(diǎn)的屬性。



5. 保存流程：用戶將所建流程以文件的形式保存起來。



6. 打開模型：用戶通過給出的文件列表打開流程文件。

• 開始節(jié)點(diǎn)：這類節(jié)點(diǎn)定義了流程的開始，以及設(shè)置整個流程的全局變量；



• 結(jié)束節(jié)點(diǎn)：這類節(jié)點(diǎn)定義了流程的結(jié)束，即對應(yīng)的掛機(jī)操作；



• 放音節(jié)點(diǎn)：這類節(jié)點(diǎn)定義了流程中所涉及到的放音或者放音取鍵操作，其屬性有放音的文件名稱；



• 人工輸入節(jié)點(diǎn)：這類節(jié)點(diǎn)定義了流程中需要人工輸入按鍵的操作，其屬性有最少輸入鍵位、最大輸入鍵位、結(jié)束按鍵、重試放音文件名、非法輸入放音文件名；



• 菜單節(jié)點(diǎn)：這類節(jié)點(diǎn)定義了流程中需要播放菜單的操作，其屬性有菜單語音文件、播放次數(shù)、菜單出口(多個)；



• 轉(zhuǎn)接節(jié)點(diǎn)：這類節(jié)點(diǎn)定義了流程中需要轉(zhuǎn)接的操作，其屬性有轉(zhuǎn)接的目標(biāo)號碼；



• 錄音節(jié)點(diǎn)：這類節(jié)點(diǎn)定義了流程中需要錄音的操作，其屬性有錄音文件存放的位置、錄音格式、錄音時常、錄音結(jié)束DTMF碼；



• 自定義節(jié)點(diǎn)：這類節(jié)點(diǎn)定義了流程中涉及到的其它操作，例如查詢、插入數(shù)據(jù)庫等。



• 分支節(jié)點(diǎn)：這類節(jié)點(diǎn)定義了流程中涉及到分支操作，例如根據(jù)系統(tǒng)變量值進(jìn)入不同的分支流程等。



• 表3.1給出了相關(guān)圖元的具體樣式。

式(3-1)

　　表示節(jié)點(diǎn)圖元可以連接多個關(guān)聯(lián)關(guān)系，每個關(guān)聯(lián)關(guān)系必須連接到一個節(jié)點(diǎn)圖元。

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

圖3.6 目標(biāo)文件基本框架圖

例如，放音節(jié)點(diǎn)的完整文件描述如下：

圖3.7 目標(biāo)文件生成類圖

MainFramwork
　　文件的主框架，主要是標(biāo)準(zhǔn)html標(biāo)簽的生成；

CreateVXMLTree
　　調(diào)用標(biāo)準(zhǔn)的XML類生成VoiceXML樹；

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

OutPutFile
　　輸出目標(biāo)文件。

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

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

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

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

1. VoiceXML Parser：負(fù)責(zé)提供VoiceXML的解析、同Web Server的交互和Telephony Service的交互。


2. Telephony Service：驅(qū)動語音卡語音動作進(jìn)行相關(guān)的操作。

圖3.12 IVR系統(tǒng)執(zhí)行引擎系統(tǒng)交互序列圖

3.6.2 VoiceXML解析器的設(shè)計

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

圖3.13 VoiceXML解析器文檔解析模型圖

1．對象樹生成模塊

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

　　目前最通用的接口為DOM(Document Object Model)和SAX(Simple API for XML)。

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

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

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

圖3.14用SAX解析方法模擬DOM樹的過程

2．語義解釋模塊

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

VoiceXML文檔結(jié)構(gòu)和執(zhí)行過程

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

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

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

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

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

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

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

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

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

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

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

3.6.2 Telephoney Service的設(shè)計

　　當(dāng)VoiceXML解析器做完解析工作之后，遇到需要語音操作時，就得依靠調(diào)用Telephoney API來完成，同時Telephony Service需要向VoiceXML解析器去返回相應(yīng)的語音操作結(jié)果事件。圖3.15描述了這一過程。

圖3.15 VoiceXML解析器與Telephony Service交互圖

　　調(diào)用的過程相對簡單，只需按照標(biāo)簽的定義調(diào)用相應(yīng)的API即可，如當(dāng)解析到