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

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

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

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

  交互式語音應(yīng)答(IVR)系統(tǒng)是電話銀行呼叫中心系統(tǒng)的最前端,它的質(zhì)量直接影響整個系統(tǒng)的穩(wěn)定性和可擴(kuò)展性。本文設(shè)計的IVR系統(tǒng)主要分為兩個模塊:可視化過程定義工具(用戶交互接口)、流程執(zhí)行引擎。由于過程定義工具主要是面向用戶,它的設(shè)計規(guī)范首先要符合流程的定義規(guī)則,反應(yīng)到本文中即流程工具涉及到的節(jié)點類型均符合IVR的操作動作和相關(guān)的業(yè)務(wù)動作,同時還要生成符合流程執(zhí)行引擎能處理的文件格式。在流程執(zhí)行引擎方面,符合VoiceXML的設(shè)計框架,將Web應(yīng)用和語音應(yīng)用相結(jié)合。

3.1 IVR系統(tǒng)結(jié)構(gòu)的總體分析與設(shè)計

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

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

  而IVR系統(tǒng)執(zhí)行引擎是根據(jù)IVR系統(tǒng)的特點,基于VoiceXML技術(shù)的設(shè)計所實現(xiàn)的流程解釋器,主要針對解釋執(zhí)行通過IVR系統(tǒng)流程定義工具所設(shè)計的中間文件,并控制硬件交換機(jī)及板卡按照工作流程的內(nèi)容完成相應(yīng)的功能。
圖3.1給出了IVR系統(tǒng)詳細(xì)的總體結(jié)構(gòu)圖。IVR系統(tǒng)總共分為兩大部分:軟件平臺和硬件平臺。其中硬件平臺主要是硬件廠商提供,本文所設(shè)計的系統(tǒng)主要是軟件平臺的設(shè)計和實現(xiàn)。從圖中可以看出,整個系統(tǒng)分為三個部分:IVR系統(tǒng)可視化流程定義工具、含有VoiceXML標(biāo)簽的Web頁面和執(zhí)行引擎。

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

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

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

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

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

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

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

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

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

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

  過程定義模型向用戶提供的用于抽象描述業(yè)務(wù)過程的設(shè)計元素會通過工作流過程定義工具表達(dá)出來,用戶使用過程定義工具提供的輸入界面,通過將各中設(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]。工作流程過程定義向用戶提供對實際業(yè)務(wù)處理過程分析、建模的手段。其輸入輸出可以用圖3.2表達(dá):

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

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

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


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


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

  本文設(shè)計的IVR系統(tǒng)的流程定義工具遵循以上規(guī)則,它被流程定義者使用,其所有的動作都是由流程設(shè)計人員發(fā)起的,通過對定義工具進(jìn)行了統(tǒng)一建模分析,其使用用例圖如圖3.3所示。

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

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


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


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


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


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


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

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

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

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

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

  根據(jù)IVR系統(tǒng)的流程和本文系統(tǒng)應(yīng)用的具體項目需求,定義出在大多數(shù)IVR系統(tǒng)常用的流程9種節(jié)點類型。


表3.1 流程定義工具中的相關(guān)圖元


3.3 可視化過程定義工具的設(shè)計

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

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

3.3.1主框架類包的定義

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


3.3.2 主框架類描述

下面給出各個類的詳細(xì)描述:

CDiagramEditor類

  CDiagramEditor類繼承于CWnd類,它是處理窗口詳細(xì)的相關(guān)操作,所封裝的是一個基礎(chǔ)的矢量編輯器,它所生成的是圖(diagrams)而不是圖片(graphics)。所以它支持小于和大于正常窗口的虛擬屏幕(virtual screen)、網(wǎng)格抓取(snap to grid)、拷貝/復(fù)制、“無限制”(所謂無限制,只是在設(shè)置撤銷棧的大小時取值較大,讓使用者感覺上是無限制,其實是有限的)的撤銷、放大等等,由于它使用了與之“隔離”的數(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ù)。在文檔/視圖應(yīng)用程序中它作為外部實例,而在對話框應(yīng)用程序中是作為內(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è)務(wù)流程所產(chǎn)生的文件格式的時候可以通過覆蓋FromString和GetString來實現(xiàn)。針對第三章對流程節(jié)點抽象,9種流程節(jié)點的屬性各不相同,因此,每一個流程節(jié)點類都應(yīng)該擁有自己的屬性對話框,這些對話框類繼承了CDiagramPropertyDlg類。實現(xiàn)的時候只要這些流程節(jié)點類擁有一個繼承CDiagramPropertyDlg類的實例作為成員變量就可以完成。

CDiagramLine類

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

CDiagramMenu類

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

CDiagramPropertyDlg類

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

CTokenizer類

  CTokenizer類的作用也很簡單,它是用來對CString和CStringArray的做string token的。

CGroupFactory類

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

3.3.3 Link類的設(shè)計

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

式(3-1)

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

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


3.4 目標(biāo)文件的描述與分析

3.4.1 文件基本框架描述

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

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

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


3.4.2 目標(biāo)文件的生成

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

圖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)完全獨立,語音系統(tǒng)和數(shù)據(jù)系統(tǒng)沒有任何交互或者只有很少的交互。而建立IVR系統(tǒng)的目標(biāo)就是給客戶更好的體驗,使客戶能方便的通過電話完成更多以前需要登陸企業(yè)門戶網(wǎng)站,或者親自去企業(yè)或其網(wǎng)點去辦理的業(yè)務(wù),這就需要IVR系統(tǒng)能跟后臺數(shù)據(jù)系統(tǒng)有更多更好的交互!罢Z音門戶”的概念出現(xiàn)也愈發(fā)的證明這一點。


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

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


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


3.5.2基于VoiceXML執(zhí)行引擎的結(jié)構(gòu)分析

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

  Web Server模塊:用來執(zhí)行和發(fā)送Web相關(guān)的請求和文檔;

  VoiceXML parser模塊:解析VoiceXML頁面,同時協(xié)調(diào)與Web Server和Telephony API之間的聯(lián)系;

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


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

  IVR系統(tǒng)執(zhí)行引擎驅(qū)動著整個IVR系統(tǒng)的業(yè)務(wù)流程,本文設(shè)計的IVR系統(tǒng)是基于VoiceXML技術(shù),如節(jié)3.2里描述的系統(tǒng)架構(gòu),執(zhí)行引擎主要分為兩大塊:

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

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

3.6.1執(zhí)行引擎的總體架構(gòu)設(shè)計

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

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

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

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

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

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

1.對象樹生成模塊

  計算機(jī)無法直接對VoiceXML文檔操作來實現(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ā)的一組獨立于語言和平臺的結(jié)構(gòu)化文檔編程接口,它定義了文檔的邏輯結(jié)構(gòu)以及訪問和操縱文檔的方法。使用DOM模型,程序所面對的XML文檔不是一個文本流,而是一棵對象樹。程序員可以方便的創(chuàng)建文檔、導(dǎo)航其結(jié)構(gòu),或增加、修改、刪除、移動文檔的任何部分。

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

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

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

2.語義解釋模塊

  語義解釋模塊的主要功能是實現(xiàn)流程文檔的解釋工作,控制整個的會話過程和與輸入輸出功能模塊實現(xiàn)交互操作。該模塊處理的數(shù)據(jù)結(jié)構(gòu)是對象樹生成模塊提供的對象樹。模塊功能的實現(xiàn)依賴于對象樹提供的結(jié)構(gòu)及樹節(jié)點上相應(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)點是:應(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)運行,直到解釋完成為止。

  選擇階段:選擇要執(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é)點的節(jié)點屬性、調(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)解析到

標(biāo)簽的時候直接調(diào)用播放語音文件接口。需要向Telephoney Service調(diào)用API所涉及到的VoiceXML標(biāo)簽如表3.2所示。

表3.2 涉及到IVR系統(tǒng)語音操作的VoiceXML標(biāo)簽表

  當(dāng)Telephony Service處理完相應(yīng)的語音操作的時候,需要向VoiceXML解析器返回操作結(jié)果事件,由VoiceXML解析器重的接收線程來獲取,返回事件分為兩類:正常事件和掛斷事件。正常事件指的是語音卡執(zhí)行完動作后返回的結(jié)果,分為執(zhí)行成功和失敗事件;掛斷事件表示語音卡在收到用戶掛機(jī)事件后發(fā)送給解析器的事件。同時,在VoiceXML解析器向語音平臺調(diào)用Telephoney API的同時,會啟動一個計時器來進(jìn)行超時判斷,來處理如果語音平臺沒有回消息的情況。

3.7本章小結(jié)

  本章首先分析了傳統(tǒng)IVR系統(tǒng)的優(yōu)缺點,并基于可視化建模語言設(shè)計了IVR系統(tǒng)的總體結(jié)構(gòu)。其次在對過程化定義工具的使用上才采用圖形化的方式來實現(xiàn)和用戶交互,滿足簡單易用的特點。最后,分析了傳統(tǒng)的IVR系統(tǒng)執(zhí)行引擎的特性,引入了VoiceXML技術(shù),設(shè)計出基于VoiceXML的IVR系統(tǒng)執(zhí)行引擎的基本框架。

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

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

作者獨家提供CTI論壇稿件,其它媒體謝絕轉(zhuǎn)載

CTI論壇報道



相關(guān)閱讀:
基于VoiceXML技術(shù)可視化IVR設(shè)計和實現(xiàn)(三) 2009-12-29
基于VoiceXML的可視化IVR系統(tǒng)設(shè)計和實現(xiàn)(一) 2009-09-22
上海易谷與Genesys達(dá)成大中華區(qū)長期合作伙伴關(guān)系 2009-04-17
聯(lián)絡(luò)中心與3G應(yīng)用 2009-04-09

熱點專題:  呼叫中心  
分類信息:  IVR技術(shù)_與_VoiceXML技術(shù)