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

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

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

基于VoiceXML技術(shù)的可視化IVR系統設計和實(shí)現(一)

圖3.1 IVR系統整體結構圖

3.2可視化過(guò)程化定義工具的分析

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

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

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

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

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

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

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

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

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

3.2.1 過(guò)程定義建模語(yǔ)言的描述

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

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

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

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

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

其功能可以細分為：

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



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



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

圖3.3 IVR系統流程定義工具用例圖

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



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



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



4. 設置節點(diǎn)屬性：用戶(hù)通過(guò)設置節點(diǎn)屬性對話(huà)框來(lái)設置節點(diǎn)的屬性。



5. 保存流程：用戶(hù)將所建流程以文件的形式保存起來(lái)。



6. 打開(kāi)模型：用戶(hù)通過(guò)給出的文件列表打開(kāi)流程文件。

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



• 結束節點(diǎn)：這類(lèi)節點(diǎn)定義了流程的結束，即對應的掛機操作；



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



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



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



• 轉接節點(diǎn)：這類(lèi)節點(diǎn)定義了流程中需要轉接的操作，其屬性有轉接的目標號碼；



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



• 自定義節點(diǎn)：這類(lèi)節點(diǎn)定義了流程中涉及到的其它操作，例如查詢(xún)、插入數據庫等。



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



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

式(3-1)

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

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

圖3.6 目標文件基本框架圖

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

圖3.7 目標文件生成類(lèi)圖

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

CreateVXMLTree
　　調用標準的XML類(lèi)生成VoiceXML樹(shù)；

UserAddContent
　　插入用戶(hù)輸入的自定義代碼；

OutPutFile
　　輸出目標文件。

3.5 IVR系統執行引擎的分析

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

3.5.1基于VoiceXML的執行引擎

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

1. VoiceXML Parser：負責提供VoiceXML的解析、同Web Server的交互和Telephony Service的交互。


2. Telephony Service：驅動(dòng)語(yǔ)音卡語(yǔ)音動(dòng)作進(jìn)行相關(guān)的操作。

圖3.12 IVR系統執行引擎系統交互序列圖

3.6.2 VoiceXML解析器的設計

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

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

1．對象樹(shù)生成模塊

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

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

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

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

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

圖3.14用SAX解析方法模擬DOM樹(shù)的過(guò)程

2．語(yǔ)義解釋模塊

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

VoiceXML文檔結構和執行過(guò)程

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

　　(1)單個(gè)文檔的執行過(guò)程。文檔默認的從第一個(gè)Dialog開(kāi)始執行，Dialog沒(méi)有指定后繼的Dialog時(shí)，文檔解釋結束。

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

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

　　Form 解釋算法對VoiceXML文檔進(jìn)行了語(yǔ)義分析和解釋?zhuān)�驅�?dòng)Form、Menu 和用戶(hù)的交互。FIA 算法主要分為兩個(gè)階段：初始化階段和主循環(huán)階段。

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

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

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

　　收集階段: 完成對用戶(hù)輸入信息和事件的收集。首先訪(fǎng)問(wèn)選定的Item 來(lái)播放提示音，可以根據提示次數選擇提示音，激活語(yǔ)音或DTMF 的Grammar，然后等待收集用戶(hù)輸入或事件。

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

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

3.6.2 Telephoney Service的設計

　　當VoiceXML解析器做完解析工作之后，遇到需要語(yǔ)音操作時(shí)，就得依靠調用Telephoney API來(lái)完成，同時(shí)Telephony Service需要向VoiceXML解析器去返回相應的語(yǔ)音操作結果事件。圖3.15描述了這一過(guò)程。

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

　　調用的過(guò)程相對簡(jiǎn)單，只需按照標簽的定義調用相應的API即可，如當解析到