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

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

上海易谷網絡科技有限公司 查瑋 2009/12/29

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

圖3.1 IVR系統(tǒng)整體結構圖

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

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

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

　　它已經由基本代碼編寫發(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í)行過程中，通過讀取表格內容，調用相應的函數(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.2 IVR系統(tǒng)流程開發(fā)工具的輸入和輸出

其功能可以細分為：

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



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



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

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

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



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



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



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



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



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

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



• 結束節(jié)點：這類節(jié)點定義了流程的結束，即對應的掛機操作；



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



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



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



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



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



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



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



• 表3.1給出了相關圖元的具體樣式。

式(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.6 目標文件基本框架圖

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

圖3.7 目標文件生成類圖

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

CreateVXMLTree
　　調用標準的XML類生成VoiceXML樹；

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

OutPutFile
　　輸出目標文件。

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

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

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

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

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


2. Telephony Service：驅動語音卡語音動作進行相關的操作。

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

3.6.2 VoiceXML解析器的設計

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

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

1．對象樹生成模塊

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

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

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

　　SAX[28]的誕生是在XML-DEV討論組上，提出他的原因是有一些情況不適用DOM接口，而且DOM實現(xiàn)太大而且比較慢。SAX接口規(guī)范是XML分析器和XML處理器提供的較XML更底層的接口。它能提供應用以較大的靈活性。SAX是一種事件驅動的接口，它的基本原理是，由接口的用戶提供符合定義的處理器，XML分析時遇到特定的事件，就去調用處理器中特定事件的處理函數(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:Form Interpretation Algorithm)

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

　　(1)初始化階段：完成Form內各種變量的初始化操作，包括計數(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的解釋，跳轉到新的Dialog；如果事件被拋出，選擇正確的Catch元素來處理，并執(zhí)行相應的事件處理過程。在處理完成后，重新進入選擇階段。

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

3.6.2 Telephoney Service的設計

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

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

　　調用的過程相對簡單，只需按照標簽的定義調用相應的API即可，如當解析到