CN1126523A - 为语言请求产生指令的系统 - Google Patents

Abstract

用来产生可下载到一请求平台的指令的系统。这些指令由多个被叫做模块的与参数有关的操作定义，这些模块互相连接在一起以指定一个请求连接布局。输入参数前，先验证模块连接结构的正确性。当输入参数以定义了系统后，执行模拟操作。模拟操作可在开发平台或请求平台上执行。模块可定义对外部例程的调用。最初定义的系统被自动转换成可下载指令。可下载指令也含有对外部例程的调用，使可在操作过程中调用例程。可含有短句模块，以允许把C代码植入到可下载代码中。

Description

为语言请求产生指令的系统

本发明的领域

本发明涉及产生可下载的指令。本发明也涉及定义一个语言请求。本发明还涉及模拟一个语言请求。

本发明的背景

语言请求平台用于电话交换机，以提供诸如呼叫等待、呼叫转移、电话应答和消息记录等等的自动用户服务。在现代的电话交换机中，所用的计算机硬件可能是很复杂的，并且它有能力支持比实际上已经实现的要广泛得多的用户服务，产生这个差距的原因在于，要产生用户服务的软件是一个冗长的过程。而且，一种新的用户服务必须在投入使用之前经过严格的模拟操作，这样才能保证用户对这种服务有良好的反应，并且愿意较经常地而不是较少地使用它们。

历史上，语言请求是人工生成的。最初，一个服务设计员要用流程图或者其他的图形工具在纸面上定义一个服务。当以这种形式完成设计后，就要以“剧本”的形式写出这个服务，这种“剧本”和戏剧演出的剧本相似，但这里它定义出请求平台和呼叫用户之间的互相对话。该剧本可以包含一些分支，以供用户选择和平台决策。这样，这种以可识别的剧本语言所写出的剧本定义了该服务的所有可能的操作。然后，把该剧本提供给一个有经验的程序员，由他写出一个实现该服务的程序。这种程序可以用例如C或C⁺⁺语言那样的高级语言写出，以尽量减少为了使该程序能够移在各种各样类型的语言平台上运行而需进行的修改的数量。

这种方法的一个困难是，在流程图水平上修改服务的定义将要求修改相应的剧本和相应的C/C⁺⁺程序。所以对服务定义的微小修改将需要不成比例的工作量来产生一个修改的用户服务。

另一个问题是，在把服务定义翻译成剧本时，特别是在把剧本翻译成程序时，很容易出错，这种出错的程度使得通常要投入大量的时间来在程序中找错和进行改正。对于许多计算机软件来说，在完成的软件中容许残留一些小的错误，这种错误只有在该软件使用了一段时间之后才会被注意到。然而，由于两个原因，语言请求平台没有这种程度的容差能力。首先，用户将很快地被服务操作过程中可能发生的任何错误所吓退，要知道，留在应答服务上的消息的丢失，可能意味着丢失了一个利润丰厚的合同。其次，在某些用作语言请求平台的计算机上，软件编码的错误可能会干扰其他的平台操作。在最坏的情况下，这可能会完全破坏电话交换。

解决这些问题的方法是，使从服务定义到计算机程序的翻译过程自动化。这种系统叫做服务生成工具。在一种已知的服务生成工具中，利用图形用户界面在计算机上以流程图的形式定义一个服务。利用图形用户界面，各个动能模块被定位并互相连接起来，以形成该服务的整体定义。可以选择每个功能模块来进行参数调节，这能够影响到某个特定功能模块的操作方式，以及该功能模块在流程图中是如何与其他模块相连接的。

一旦完成定义之后，这种已知的服务生成工具将自动地把图形的服务定义直接转换成一个特定语言请求平台能够执行的代码。所以，这种已知的系统虽然解决了许多人工服务生成的缺点，但它不能产生适用于其他请求平台的程序。

本发明的概述

根据本发明的第一个方面，提供了一种为一个请求平台产生可下载的指令的方法，其中多个与参数有关的操作被联系在一起，来定义一个受逻辑控制的请求，该方法的特征在于以下的步骤：用图形表示备功能模块；用图形表示上述各功能模块之间的联系，这种联系又规定了该请求操作过程中上述各功能模块之间的逻辑流程；测试上述各功能模块之间的上述联系的联系正确性，由此测试上述逻辑流程的正确性；以及，在通过上述正确性测试之后，输入规定一个模块的功能的操作参数。

本发明特别适用于定义语言请求平台的请求。根据本发明的第二个方面，提供了一种产生可以向一个语言请求平台下载的指令的方法，该方法的特征在于下述步骤：用图形表示各功能模块；用图形表示上述各功能模块之间的联系，从而定义一个服务结构；以及，测试上述联系的正确性，从而检查各功能模块之间有无遗漏连接，有无重复连接，以及有无功能模块没有输入连接。

附图的简单说明

图1示出一个通信网络，它有一些与用户设备相连接的交换机，上述交换机含有语言请求平台；

图2详细示出一个图1所示类型的语言请求平台，它含有用来存储控制平台的实际操作的指令的存储装置；

图3示出一个用来产生用于图2所示平台的指令的系统，它含有一个处理单元、一些存储装置、和一个用来产生和识别语言信号的语言卡；

图4详细地示出图3所示的语言卡；

图5A示出在定义服务时，在图3所示的系统上执行的操作的全貌，它含有：在图形用户界面中定义一个服务结构，检验上述结构的正确性，输入一个功能模块的参数，以及在一个功能模块的文本文件中更新该功能模块的参数；

图5B示出在服务模拟和可下载代码产生过程中，在图3所示的系统上执行的操作的全貌；

图6详细示出在图5A所示的服务定义过程开始之前由软件自动执行的硬件初始化过程；

图7详细示出图5A中关于在图形用户界面中定义服务结构的过程；

图8详细示出图5A中关于流程图正确性检验的过程；

图9详细示出作为图7中定义一个服务结构的手段的图形用户界面；

图10详细示出图5A中关于在模块文本文件中更新参数的过程；

下面的附图给出用于定义一个服务结构的模块表格的细节和相应的剧本定义，后者定义了在图5A的过程中所输入的参数是如何映射到相应的文本文件中去的；

图11详细示出一个含有一个“OK”按钮的应答模块表格；

图11B详细示出在从输入到图11A的应答模块表格的参数产生一个文本文件时所使用的剧本的规范；

图12A和12B详细示出一个挂断模块表格及其相应的剧本定义；

图13A和13B详细示出一个拨号模块表格及其相应的剧本定义；

图14A和14B详细示出一个转移模块表格及其相应的剧本定义；

图15A和15B详细示出一个信息模块表格及其相应的剧本定义；

图16A和16B详细示出一个DTMF(双音多频模式)模块表格及其相应的剧本定义；

图17A、17B和17C详细示出一个询问模块表格及其相应的剧本定义；

图18A和18B详细示出一个是/否模块表格及其相应的剧本定义；

图19A和19B详细示出一个记录模块及其相应的剧本定义；

图20A和20B详细示出一个重放模块表格及其相应的剧本定义；

图21A和21B详细示出一个外部模块表格及其相应的剧本定义；

图22A和22B详细示出一个短句模块表格及其相应的剧本定义；

图23A图23B详细示出一个转换模块表格及其相应的剧本定义；

图24A和24B详细示出一个测试模块表格及其相应的剧本定义；

图25至38给出利用前面各附图中所示出的工具所实现的一个服务的具体工作例子；

图25详细示出一个图形用户界面，它包含一个应答模块、一个DTMF模块、一个第一信息模块、一个第二信息模块、和一个挂断模块；

图26A和26B详细示出图25所示的应答模块和结果的文本文件；

图27A和27B详细示出图25所示的DTMF模块和结果的文本文件；

图28A和28B详细示出图25所示的第一信息模块和结果的文本文件；

图29A和29B详细示出图25所示的外部模块和结果的文本文件；

图30A和30B详细示出图25所示的第二信息模块和结果的文本文件；

图31A和31B详细示出图25所示的挂断模块和结果的文本文件；

图32示出利用图26至31所示的文本文件来产生一个页文件和一个形式文件的过程；

图33示出根据图32所示过程所产生的页文件；

图34示出根据图32所示过程所产生的形式文件；

图35示出另一种实现图25所示服务的结构，包含一个短句模块；

图36A和36B详细示出图35所示的短句模块以及结果的文本文件；

图37示出又一种实现图25所示服务的结构，包含一个修改的信息模块；

图38A和38B详细示出图37所示的修改的信息模块表格以及结果的文本文件；

图39详细示出图5B所示的服务的模拟过程；

图40详细示出执行应答模块的模拟的控制过程；

图41详细示出执行挂断模块的模拟的控制过程；

图42详细示出执行拨号模块的模拟的控制过程；

图43详细示出执行转移模块的模拟的控制过程；

图44详细示出执行信息模块的模拟的控制过程；

图45A和45B详细示出执行DTMF模块的模拟的控制过程；

图46详细示出执行询问模块的模拟的控制过程；

图47详细示出执行记录模块的模拟的控制过程；

图48详细示出执行外部模块的模拟的控制过程；

图49详细示出图5B所示的过程，用以生成可下载的服务指令，包含变量提取和剧本文件处理；

图50详细示出图49所示的变量提取；以及

图51详细示出图49所示的剧本文件处理。

一个优选实施例的详细说明

该优选实施例涉及产生这样一些指令，它们可以下载到用于电话交换机或私人分支交换机这种类型的语言请求平台上去。然而，所描述的技术也适用于其他一些情形，在这些情形中多个由参数驱动的操作被连接起来以定义一个逻辑控制的请求。申请的环境

图1示出一个通信网络，它有多个干线交换机15，每个干线交换机都与多个当地交换机16相连接。每个当地交换机与多个当地线路17相连接，后者又连接到用户的终端设备18，例如一般的语言电话机上。

每个当地交换机16从/向用户终端18接收/发送模拟信号。在当地交换机中，模拟信号被编码以向干线交换机15进行数字发送，并且从干线接收到的数字信号被解码以向当地网络进行模拟发送。在干线19上，各交换机之间发送的是数字信号，其形式是每秒2兆比特的时分复用30路数字化语言通道加上两个数字化信号通道。

一个干线交换机15含有一些语言请求平台20，设计得以2兆比特复用的交换容量来进行通信。这样，提供给每个语言请求平台的硬件有能力处理30个电话通道。

图2示出了一个语言请求平台，它有一个线路接口电路21，一个语言处理器22，以及一些可编程处理器23。一个32路通道的多重化信号(30个语言通道加上2个信号通道)通过一个数字发送线路24被提供给线路接口电路21。线路接口电路响应于其中的信号命令识别出每一个语言通道，以供后面的处理。

语言请求通常由一个输入的呼叫启动。特别地，包含在信号通道上的信息将向线路接口电路21告知出现了一个输入呼叫。随之，线路接口电路将通过数据总线25与处理器23通信，先是确定哪个特定的通道想要使用语言服务，然后判明所请求的特定服务。

语言请求平台能够响应于用户所提出的要求而执行许多不同的操作。这些服务是根据存储在一个存储装置26，例如一个硬盘驱动器中的指令来执行的，只有当某个特定的服务被请求时，有关该被请求的服务的特定的指令才被装载到可编程处理器中。

用户的请求可以以音调的形式或者环路断开的形式来发送，结果使数据通过数据总线25被发送到可编程处理器23中。当关于一个特定的语言请求的指令已经从存储装置26装载到可编程处理器23中以后，可编程处理器23将按要求通过数据总线22向线路接口电路21和语言处理器22发出指令。这样，压缩的语言记录可以被发送给语言处理器22，它设计得能够对语言解压缩并通过语言总线27把解压缩的语言提供给线路接口电路27，后者接着又把该语言中继给通信通道24，其后该语言就象任何其他的语言信号那样被以基本相同的方式进行处理。

被线路接口电路21所接收的语言也通过语言总线27被发送给语言处理器。当有必要让语言处理器识别语言图形时，就在可编程处理器23的控制之下把语言样板(或者更为经常的是隐蔽马尔可夫模型)从存储装置26通过数据总线25下载到语言处理器22中。

通常，平台所能提供的服务的开发是一个进行性的过程，它需要给平台生成新的指令并装载到存储装置26中去。一般，为了给语言请求平台生成新的指令需要大量的时间和技术。

语言请求平台在一个操作系统(例如以商标UNIX提供的系统)的控制之下工作。可以对用例如C或C⁺⁺这样的高级语言所生成的请求程序进行编译，以产生与UNIX操作系统和包括有语言请求平台的硬件相兼容的指令。然后这些指令被存储到可以是一个硬盘驱动器的存储装置26中，以便当一个呼叫人请求某个特定服务时能根据命令来使用。

出现在指令中的任何错误都可能造成平台以不适合于用户的方式来执行该指令，这将导致用户的不满。在一个交换机中增添了语言请求平台将增加该交换机的成本，而这种成本增加只有在平台被安装上之后能够充分使用的情形下才能够平衡。所以，用户的满意是一个重要的要求。再有，错误有可能迫使该平台出现故障，在极端情形下这可能使整个交换机不能工作。

通常，错误是在用高级语言为一个服务编写程序的阶段引入的，这个程序接着将被下载到请求平台上并被编译成该平台的指令。编写一个用户服务的程序是一个耗时的过程，特别对一个要求没有错误的结果程序来说更是如此。因此存在着这样一个矛盾，即一方面为了要充分获得市场条件的优势而希望尽可能快地生成或修改用户服务，另一方面又同时要保证不出现错误。

也有可能在某一地理区域工作得非常完美的一个特定的请求需要修改得能够以可接受的形式在另一个地区工作；特别是当使用语言识别时，可能必须要考虑使用当地的语言、习惯用语、和方言。所以，有可能要构筑这样的服务指令，它们能够完全被接受和不出现任何错误，但为了在特定情况下工作还需要可以修改。例如，一个请求可能设计得能识别词汇“是”和“否”，但在许多地区，例如使用英语的地区，有可能用不同的词汇来传达同样的含义。

本实施例是针对一个为语言请求平台产生服务指令的改进的系统的。此外，本实施例还提供一个用来在这种指令被下载到实际的操作平台之前测试这些指令的系统。系统概述

一种用来产生和测试关于定义由一个语言请求平台所执行的服务的指令的系统称之为一个开发平台。图3示出一个基于普通用于个人计算机的结构的开发平台，它含有一个处理器31，例如由英特尔公司(Intel corporation)提供的80386微处理器，存取容量典型地为4兆字节的随机存取存储器(RAM)32和具有硬盘驱动器33形式的40兆字节的永久存储器。该硬件可以用PC(个人计算机)母板和增加在其上的附加卡来构成。

一个允许在处理器31和存储器32之间传递数据的数据总线34也连接在一个接口卡35和一个语言卡36上。该接口卡35又连接到一个监视器37、一个键盘38和一个鼠标39上，以允许与操作人员通信。语言卡36又连接到一个电话机40上，由此使得操作人员可以通过语言和电话信号来与系统通信。

图4详细示出了语言卡36，它含有一个电话线路接口电路41、一个控制处理器42、一个编码解码器43、一个比特率转换器44、以及一个语言提取和识别电路45。被电话机40接收的语言被提供给电话线路接口电路41，然后被编码器43以每秒64千比特的速率转换成数字形式。编码解码器43的输出被提供给语言识别电路45，后者设计得能够根据由主处理器31所提供的样板数据来识别一些特定的字词和短句。由识别电路45所探测到的代表出现了语言的一个特定项目的数据被提供给控制处理器42。

来自编码解码器43的语言也提供给比特率转换器44，后者压缩该语言信号，由此使它能够高效地存储到硬盘驱动器33中。类似地，语言消息也以压缩形式存储在硬盘33中，并被转换器44解压缩，以通过编码解码器43和接口41发送给电话机40。来自电话机40的信号被接口41按原意翻译，然后定义上述信号的数据被直接提供给控制处理器42。

在请求开发平台上运行的软件含有一个操作系统，如由微软公司(Miciosoft Corporation)提供的MS-DOS、一个图形操作系统，如也是由微软公司提供的WINDOWS(视窗)、以及一个服务生成工具，它可以是用象Visual Basic那样的高级语言编写的；虽然这个事实对于使用它的服务设计员来说并不重要。

图5A和5B示出了为图2所示类型的语言请求平台而设计一个服务的过程。

在步骤51中，通过把一些功能模块在一个流程图中连接在一起来定义一个服务结构。使用一个图形用户界面来执行选择、定位和连接各模块的操作。在步骤52中，检验步骤51中所定义的结构的正确性，也就是说，分析各模块之间连接的布局，以确定该结构是否正确。

如果该结构不正确，在步骤53中控制返回步骤51。这样可以重新定义和检验该服务结构，直到产生一个正确的结构，这时控制进入步骤54。在步骤54中询问是否可得到任何控制模块来做参数输入，如果答案是肯定的，则选择一个这样的模块。模块的参数使得可以定义出操作一个模块所需的数据，例如一个消息的文本，当接收到对该服务的呼乎叫时，它便将传递给呼叫人。

在步骤55中，输入关于所选模块的参数，在步骤56中，更新该块的一个有关文本文件中的参数值。这些模块参数是根据一个剧本语言的规则来写入的，所以这些文本文件可以被操作人员所理解。模块参数可以是任选的或者是指定的，只有当该服务中所用到的所有模块内的所有指定参数都已经输入之后，系统才会前进到下一阶段。参数输入将重复进行，直到步骤54确定一个模块不是选择来用于参数输入的，这时控制转向图5B中的步骤57。

当模块参数都已经输入后，该服务就定义好了。图5B的步骤57标志着服务生成的下一个阶段的开始，这个阶段即是服务模拟。在步骤57中，在服务生成平台上执行服务模拟，该平台是与执行步骤51至56所用的硬件相同的硬件。

在步骤58中，询问步骤57中所执行的服务模拟是否成功，如果答案是否定的，则控制返回到步骤51，以便可以重新实施服务定义步骤51至56，直到定义出一个成功的服务。

当步骤57中执行的服务模拟为成功时，从而对步骤58询问的答案为肯定时，则对每一个模块都含有一个剧本的文本文件便被装载到一个语言请求平台上，以使上述平台可以在步骤59中实行服务模拟。在步骤60中再次询问步骤59中在语言请求平台上所执行的模拟是否成功，如果答案是否定的，则控制再次返回步骤51，以便可以在服务生成平台上重新定义该服务。

这样，有两个模拟阶段：第一个是在生成服务的开发系统上执行的，而第二个是在一个分开的平台上执行的，该平台可以是一个语言请求平台，例如服务就是为之而设计的那个平台。当两个模拟阶段都已经成功地完成之后，步骤60就使控制转到服务生成的下一个阶段，也即代码产生阶段。

在步骤61中，定义该服务的剧本文件在服务生成平台上被翻译成可下载的C⁺⁺代码。C⁺⁺是一种传递性很强的语言，因此步骤61中所产生的代码适合于被下载到许多种语言请求平台上，这些平台可能具有不同的硬件、软件和操作系统结构。

在步骤62中，步骤61中所产生的可下载的C⁺⁺代码被装载到一个语言请求平台上，在步骤63中，当需要时，相关连的C⁺⁺程序也被装载到这个平台上。因此，可能做到的是，由服务生成工具所产生的指令将包括调用在该语言请求平台本身中执行的其他有关程序。

于是，在步骤64中，被装载的C⁺⁺程序被编译成可执行的平台特定代码，并且在步骤65中，使上述程序在语言请求平台上运行，由此使上述语言请求处于激话状态。服务生成和正确性检验

在步骤51之前，服务生成平台被初始化，以便为服务的产生提供一个起始点。初始化步骤由服务生成软件自动地执行，它们在图6中详细地示出。

在步骤66中，利用作为以商标“WINDOWS”提供的操作系统的一个部分的子程序来产生一个可滚动的流程图幕布(canvas)，并通过在占据了整个显示屏的第二窗口后面设置一个大于显示屏尺寸的窗口来产生一个滚动的窗口。这样，较大的窗口可以相对于较小的窗口移动，从而给人以这样的印象：一个大于显示屏面积的幕布在相对于显示屏滚动。

在步骤67中，生成一个功能性建筑模块的菜单，从该菜单中可以选择各个建筑模块，以放置在可滚动幕布上。在步骤68中，定义一些附加的下拉式菜单，它们可以提供参数输入所需的各种命令，并引导在服务生成平台上产生服务的过程，在步骤69中，由服务生成平台请求一个服务名称，当用户已经输入该名称后，它将被服务生成软件读出并显示在显示屏上。这样，在完成步骤69之后，为了产生定义一个服务的环境所需的全部指令都已经执行，然后操作员便可以进行服务的定义。

图5A中所示关于定义一个服务的步骤(步骤51-56)在图7中详经地示出。在步骤75中，通过操作鼠标39选出一个建筑模块。这需要移动鼠标使得所显示的游标处在模块菜单中的某个特定模块内。按下并保持鼠标上的一个按钮，使所选择的那个模块的颜色发生变化，在保持鼠标上的按钮被按下的状态下再移动鼠标就会使该模块在幕布上被“拖曳”。当拖曳到所需位置时，放开鼠标按钮就可以有效地释放该建筑模块，使该模块的一个功能表格留在幕布上，其后该模块将恢复它原先的颜色。

在步骤77中，询问是否需要另一个建筑模块，当答案为肯定时，控制返回到步骤75。应该看到，在空间容许的情形下，每个可能获得的建筑模块都可以被拷贝到幕布上任意次数。如果一个流程图非常大，以至幕布上不能给出足够的空间，则可以生成一些幕布，这也称作“页”。

当所有需要的建筑模块都已经放置到幕布上之后，从而对步骤77的询问的答案为否定时，便定义逻辑连接，以规定各个建筑模块之间的逻辑流程。

在步骤78中，通过鼠标把游标放置在一个模块上，以选出一个源建筑模块，其后该选出的模块改变其颜色，以表示它已被选出。

选出源建筑模块之后，在步骤79中通过再次操作鼠标而选出一个目的建筑模块。选出目的建筑模块后，在步骤80中，从源模块到目的模块画出一条连接线，这时源建筑模块的颜色恢复原先的颜色。在该图形上流程的方向也通过一个从源建筑模块指向目的建筑模块的箭头表示出来。

在步骤81中，从一个关于可能采用的连接名称的下拉式菜单中导出一个适用于该原始源建筑模块的名称，指定给上述连接。省缺名称可以是“OK”，表示该流程的工作正确，可以进入下一阶段。或者，也可以从一个建筑模块引出多条连接线，例如可以从建筑模块引出两条连接线，第一条代表答案“是”，第二条代表答案“否”。其他的选择也是可能的，例如某一范围内的一些数字，或者诸如“真”、“假”这样的逻辑条件。

在步骤82中，询问是否要生成另一个连接，如果答案是肯定的，则控制返回步骤79。当已经拷贝了所有需要的建筑模块，并且生成了所有必要的连接之后(对步骤82中询问的答案为否定的)，则进行正确性检验过程，如图5A的步骤52所示。

图8详细地示出了步骤52中的正确性检验过程。在步骤84中进行一个检查，以确认各建筑模块具有正确数目的输出连接。由于从一个建筑模块发出的输出连接的数目直接与该建筑模块所执行的操作有关，因此软件有可能探测出已定义的输出连接数目和由该块的逻辑功能所预言的数目之间的差别。然而应该注意，输入连接的数目不能用这种方法来预定。

在步骤85中进行一个检查，以确定是否有任何建筑模块的连接是重复的。这样，如果一个建筑模块可能需要两个输出并且在总体结构中可能确实出现了两个输出，则该结构将通过步骤84所做的测试。然而，举例来说，如果对两个输出的连接分别要求规定为“是”和“否”，但有可能上述两个连接都被指定成为“是”，这种情况即为重复，它将在步骤85中被识别出来。

在步骤86中进行一个检查，以确定是否有任何建筑模块没有输入连接，因为如果不存在输入连接，则控制永远不可能进入那个模块，所以必定存在有错误。

可以出现连接器模块，它将改善各连接的美学面貌。此外，连接器模块可以用来把两个或多个输出连接合并成一个单一的输入连接。不过，所有的连接器都应该具有一个输出和至少一个输入。在步骤87中进行一个检查，以确保所有的连接器都至少有一个输入和至少一个输出。

在步骤88中进行一个检查，以确保没有任何连接器有多于一个的输出。应该注意，如果规定从连接器的输出只能按一个方向传送，则一个连接器只能有一个输出。如图5A的步骤53所示，当正确性检验成功时，现在就可以把参数输入给各个模块。

图6所详细示出的初始化过程使得显示出一个图9所示形式的屏幕。该屏幕示出一个关于各种可获得的模块的菜单91，以及一个可滚动幕布92。该幕布通过把鼠标指针放置在所显示的箭头93、94、95或96上而被滚动。激励箭头93将令幕布向下滚动，使得幕布的上面区域可通过观察窗口显示出来。类似地，操作所显示的箭头94将令幕布向上滚动，使得其下面区域可以通过窗口显示出来。对箭头95和96的类似操作将令幕布分别向左和向右滚动。这样，通过操作这些箭头，便可以令幕布滚动，使得幕布的任何区域都可以通过观察窗口显示出来。

可以从模块菜单91中选择的建筑模块包括这样一些：“应答”、“挂断”、“拨号”、“转移”、“信息”、“DTMF”、“询问”、“是/否”、“记录”、“重放”、“外部”、“短句”、“转换”、“测试”、“连接器”、和“页”。

当一个含有一些模块的流程图已经被定义和通过正确性检验之后，可以通过选择页模块来在另一页上生成一些模块。当页模块被选择时，它将以与其他可以显示在幕布上的模块相似的形式显示在幕布上。不过，当通过在把鼠标对准上述页模块的同时轻按鼠标按钮而选出上述页模块时，将显示出另一个幕布页，由此可以在其上拷贝另外一些模块。这样，页模块代表一个较低水平上的整个幕布，它给可操作的模块提供了一个幕布，使它们可以在其上作描述。

建筑模块参数通过适当地操作鼠标选择一个特定模块来输入，选出特定模块将使它的模块表格被打开。模块表格提供可以用来给该模块指定一个名称的位置，其后各种模块参数可以写入到各自名称下的模块文本文件中去。

每个模块都显示出一个标志为“OK”的软按钮。通过鼠标对这个软按钮操作将执行一个程序，该程序把输入进模块中的参数写入到相应的具有剧本形式的文本文件中。

图10示出了一个关于把为一个模块定义的数据写入到一个文本文件中去的例子。在步骤101中，该程序响应于操作员选择相应模块上的“OK”按钮而被启动。在步骤102中进行一个检查，以确保那些必须要有的参数都已经存在。所以步骤102将检查该模块是否已经被赋予了名称，以及操作员是否已经输入了对于操作这个模块是重要的那些参数。很明显，这些参数应该是针对某个模块的，下面将对每一个上述的模块作详细说明。如果缺少任何必须的参数，则图10详细所示的过程便终止，并要求操作员通过适当的模块表格来定义这种参数。

在步骤103中进行一个检查，以确保输入到模块中的参数是有效的，这样，模块名称必须用字符来规定，该名称在适当的操作环境下可以用作一个文件名称。类似地，所定义的时间必须位在容许的、有意义的限制范围之内。

在步骤104中，一个文本文件被打开，它由模块名称加上扩展符号“·TXT”来标识。其后，在步骤105中，通过写出一个参数的名称和跟在其后的参数值，把文本写入到步骤104中所打开的文件中。在步骤106中询问是否存在有另一个参数，如果答案是肯定的，则控制返回到步骤105。

最终所有的参数都将被考虑到并在步骤105中被写入到适当的文本文件中，结果使得对步骤106询问的答案是否定的，由此将引导控制进到步骤107。在步骤107中，模块文本文件被闭合，然后控制返回到实现交互的图形用户界面的过程，如图9所示。模块表格的详细说明

现在将详细说明特定的模块表格以及在执行图10所详细示出的程序时所产生的文本文件。当参数名称和参数值被写入到相应的文本文件中时将参考在步骤105中所执行的过程。应该注意，对于放置在幕布上的一个模块的每一个拷贝，都产生一个包含有参数的剧本定义的文本文件。服务设计员对服务中所使用的每一个特定模块都定义了一个单独的模块名称。

给出图11B及后面附图中所示的行号只是为了便于说明的目的，在实际产生的剧本中不出现这些行号。为了描述剧本的这些行采用了类似于定义计算机语言时所用的约定。斜体文字表明依赖于上下文的名称或参数，所以不能在剧本的正式规范中指出。方括号内的文字是任选的，它可以包含在，也可以不包含在一个模块剧本的例定例子中。

图11A示出一个应答模块的表格。应答模块指令一个服务等待一个输入的呼叫。图11B示出可以从应答模块表格中所定义的参数导出的文本的完整清单。

当正在向图11A所示的表格输入信息时，可以选择一个帮助钮111，这将会使文本显示出来，以向缺乏经验的操作员提供帮助。类似地，当已经在某个位置上输入参数之后，可以选择撤消钮112，这将删除刚才在该位置上所作的修改。如后面各个图所示，对于每个模块表格都提供有一个帮助钮和一个撤消钮。

当数据已经输入到应答模块中之后，操作“OK”钮113将启动利用以例如图11B所示形式的数据来更新该剧本文件。这种“OK”钮在每个模块表格上都有，如前所述，其操作将造成执行图10所示类型的过程。

应答模块在位置114处被赋予一个单独的名称，如果在该服务中存在有多于一个的应答模块，则这些块必须被赋以不同的名称，使它们以后可以互相区分。模块名称插入在图11B所示文本文件第1行(行1)的模块名称标志的后面。该行的第一部分通过文字“te1-answer-block：”(“电话-应答-模块”)指明该文本文件关系到一个应答模块，如前所述，当操作“OK”钮时该第1行就用位置114处所指定的特定的模块名称写入到如图11B的行1所示的文本文件中。

在位置115处指定一个“模块时间用完”时间，这个时间可以分别用按钮116和117来增加或减少。或者，如果软开关118没有被操作，则系统将始终有效地等待于应答模块，直到接收到一个呼叫。这样，该时间用完时间指定了这样的时间，在其期间该系统将等待一个输入呼叫，这个时间写入到文本文件行2中的形式是：arg：“time to wait”(变量：“等待时间”)，其后跟随着在位置115处输入的数字。不过，如果软开关118没有被操作，则行2被从文本文件中删去，这一点用行2文字两端的方括号来表明。

类似地，在位置119处指定一个应答响铃时间，这将使数据写入到文本文件行3中，其形式为：arg：“ring to ans time”(变量：“应答前响铃时间”)，其后跟随一个数字，该数字代表这样的时间，其间该系统将允许输入呼叫在实际被应答之前产生响铃。这里也提供了一个软开关120，只有当对它操作后才会使数据写入到行3，否则将采用省缺值。

用户可能要为该服务付帐，所以当该服务应答用户的呼叫时，也即当一个应答模块答复一个输入呼叫时，计费时间就会开始。提供了一个软开关121，当操作它时就会使该呼叫计入到用户的帐号中去。这个位置使图11B行4中指定的数据被写入到文本文件中，其形式为：arg：“start billing”true(变量：“开始计费”真)或者，如果没有操作过软开关121，则词“true”(“真”)将被词“false”(“假”)所替代。

区域122包括位置123、124、125和126，分别用于短句前过程、算术前过程、算术后过程和短句后过程。这些过程使文本中从行6至行14的内容得到定义，对于该服务中所提供的所有模块，都装置有类似的结构。区域122的使用将在后面说明。

当从区域122所导出的表达式已经被写入到文本文件中之后，需指定继续到下一个模块的各项条件。这样文本文件的行16指明当应答模块的执行成功时下一个要执行的模块。类似地，行17指明当应答模块的执行失败时下一个要执行的模块。不过，重要的是要注意到这些被指定的模块名称不是在应答模块表格上定义的，而是从幕布上生成的连接布局图导出的。

最后该文本文件被指定“endblock”(“结束该模块”)的行18所限定。

图12A示出关于挂断模块的表格。挂断模块指令该服务切断呼叫的用户，因此它一般用于完成了呼叫用户和服务自身之间的通信之后的服务终结之处。图12B示出了可以从挂断模块表格中所定义的参数导出的文本的完整清单。如前所述，行号只是用于识别例子中的各个特定的行，它们并不代表文本中代码行的绝对位置。提供了一个单独的名称位置131，以及一个短句和算术区域132、一个OK钮133、一个撤消钮134、和一个帮助钮135，这些区域基本上等同于对图11A所说明的各个类似区域。在下面所有的模块中也都有这些区域，必须理解，它们的操作都基本上类似于对图11A所说明的操作。

在某些操作条件下，有可能在位置136处指明挂断原因，然后把它被指定在文本文件的行2上。提供了一个滚动标志137，对它操作将使系统按可以获得的各个挂断原因滚动，这些原因包括：正常、不可获得、占线、暂时故障、阻塞、或者网络故障。

在行16上指定服务的下一个模块，它还是从网络连接布局中导出的，模块限定标志“end block”被写在文本文件的行18上。

图13A示出关于拨号模块的表格。拨号模块让系统向另一个系电话机拨号，因此可以在从另一个统得到信息时或者在转移一个呼叫时等情形下使用。

要拨出的号码，或者一个指明能够得到拨出号码的地点的变量，在区域141中指定，结果使一个指令被写在行2上，其形式为：arg：“number to dial”(变量：“要拨的号码”)，其后跟随着准备拨出的号码或者一个变量的标志。

该模块能够以双音多频模式(DTMF)或者环内切断模式拨号。提供了一个软开关，其形式使得可以用鼠标选择区域142，或者也可以通过操作鼠标而选择区域143，不过两者之中只可选择一个。如图13A所示，已经选择了区域142，如果这时通过适当的鼠标操作而选择区域143，则将造成区域143被选出而区域142被释放。拨号模式的选择使得一个指令被写在行3上，其形式为：arg：“diallingmode”(变量：“拨号模式”)，其后跟随着标志“M”(代表多频率)或“L”(代表环路切断)。

在区域144上可以设定一个时间，以指定系统等待本呼号被应答的时间。如果不操作位置145，则不需要在位置144处输入数字，这时将采用响铃时间的省缺值。操作位置145将使得输入在位置144处的值被包括到行4的任选指令中，其形式为：arg：“ring tone cl time”(变量：“呼叫响铃时间”)，其后跟随着所选择的数字。该响铃时间选择是通过操作滚动标146来进行的，使得该时间只能够从一组有限的可供选择的值中来选定。

任选项下一个模块从网络连接布局中导出，被写入在文本文件的行16至行21，模块终结限定标写在行22上。

图14A示出了关于转移模块的表格。转移模块与另一个电话线路联系，如果成功，则把呼叫的用户转移到该线路上去。“需拨号码”位置151基本上类似于图13A的位置141，结果是一个类似的指令被写在文本文件的行2上。类似地，“应答时间”可以在位置152上指定，结果是一个类似的指令被写在文本文件的行3上。下一模块条件也再次被写于文本文件的行15至19，而终结模块限定标写在行20上。

图15A示出了信息模块的表格。信息模块向呼叫用户提供信息，它常常根据所做的一个选择来实现。图15B示出了一个可以从信息模块表格中所定义的参数导出的文本的完整清单。在位置153处指定一个单独的模块名称，结果在文本文件的行1上写上了一个指令，其形式为info-block：(信息-模块：)，其后跟随着上述名称。提供了一个软开关154，当它被操作时将清洗一个键前缓存器(key-aheadbuffer)，该缓存器可以含有由呼叫用户以前通过操作该用户的键盘所做的选择的指示。其结果是在文本文件的行2上写上了一个指令，其形式为：arg：“flush buffer”(变量：“清洗缓存器”)，其后跟随着真或假的指标，决取于是否操作了软开关154。

区域155用来包含消息的细节。可以定义两种类型的消息。当选择了软按钮156时将定义正常消息，类似地，当选择了软按钮157时将定义快速消息。快速消息属于这样一种类型，它允许对熟悉于该服务的用户或熟悉于这种类型服务的用户加速系统的操作。

含有消息数据或语言识别数据的文本文件被分成两部分，最后完成的剧本将由每个服务页的两个文件所指定，这两个文件由定义逻辑操作的页文件和含有消息和识别数据的形式文件所构成。

这样，下一模块的命令在行14至行20被指定，其后，在行21上指定终结模块限定标。

形式信息从行23开始指定。这样，行23通过指令：info-form：(信息-形式：)及其后跟随的模块名称来表明形式信息的开始。

在正常操作下，被传向呼叫用户的声音消息是在位置158处指定的，在位置159处可以指定系统错误消息。在位置158内指定的消息使指令写在行24上，其形式为：message：(消息：)，其后跟随着具体的消息数据，它们包含在倒逗号(引号)之间，对每个指定的消息以预先定义的次序排列。类似地，如果在位置159中指定了系统错误消息，则指令被写在行25上，其形式为：system error：(系统错误：)，其后跟随着位在倒逗号中间的系统错误的文字内容。这构成了该模块消息的结尾，因此在行26文本文件被一个指令end form所限定。

图16A示出了DTMF模块的表格。DTMF模块用来接收来自呼叫用户的DTMF信号，也即按钮音调信号，并在其后根据所接收到的信息作出决策。因此，在大多数请求中，下一个要处理的模块将取决于从呼叫用户接收到的具有键入形式的实际信息。图16B详细地示出了一个可以从DMTF模块表格中所定义的参数导出的文本的完整清单。

在位置161处指定模块名称，结果在行1上写上了一个指令：DTMF-block：(DTMF-模块：)，其后跟随着模块名称，在行37上写上了DTMF-form：(DTMF-形式：)，其后跟随着模块名称。这样，关于逻辑操作的指令将写在行1的下面，其后的消息信息将在行37的下面指定。

参数区域163中的一个软开关162使操作员可以选择是否要清洗键前缓存器，其结果是在行2中写上了一个指令，其形式为：arg：“flush buffer”(变量：“清洗缓存器”)，其后跟随着标志true(真)或false(假)。

DTMF模块能够响应于固定位数的数字，或者响应于可变位数的数字。于是当某个特定模块准备响应于可变位数的数字时就选择软按钮164，而当该模块准备响应于固定位数的数字时就选择软按钮165。当选择按钮165时，系统将响应的数字的实际位数应在位置166中指定。

这造成在行3中写入一个指令，其形式为：arg：“max digits”(变量“最大位数”)，其后跟随一个表明所期望的数字的最大位数。

操作软开关167将允许在位置168上指定一个静止时间，其结果是在行5中写入一个指令，其形式为：arg：“pre time out”(变量：“前时间完”)其后跟随着一个表明该时间的指示。这样，该模块将等待输入音调一个由静止时间所指定的时间。或者，如果不操作软开关167，则将采用静止时间的省缺值。

DTMF模块的一个重要的特点是在接收到了具体的DTMF音调之后才定义究竟发生了什么。这个信息是在系统的连接布局和对该布局的分折中定义的，其结果是在行18至34中写入了一些指令，其后是行35上的终结模块限定指标。

如前所述，行37指明了形式信息的开始。必须在位置169中指定第一个提示，结果在文本文件的行38上写入一个指令，其形式为p1：，其后跟随着第一个提示消息。还可以指定其后的提示、帮助消息、声音不清、静止无声和错误消息，其结果是在以下各行直至行47中写入一些指令。最后，行50上的限定志end form指明了该文件的终结。

图17A示出了询问模块的表格。该模块用来获得呼叫人对消息提示的语音应答。这使呼叫人得以用言语与服务通信，例如读出信用卡的号码。提供了一个软开关171，用来接通或关断一个蜂鸣声，它可以提示呼叫人什么时候该说话。当操作该软开关后，在所产生的形式文件中便包含了图17C中的行45。该能够影响到语言识别处理最优化的软开关用于数字最优化172和ZSML(零间隔媒体长度)最优化173。数字最优化表明所期望的应答将包含各个语言数字“零”至“9”，ZSML最优化表明用户说出的各数字之间可以不停顿。数字和ZSML最优化通过分别示出于图17B的行3和行4的命令来选择。

在位置174处指定一个语言识别样板，使得应答的可能范围有一个样板，以与输入的语言图案进行比较。例如，语言识别样板使得语言识别软件只需在十个不同的字(对于“零”至“9”的情形)之间进行区别。语言识别样板将造成一系列的有效应答行，例如图17C的行29至28所表明的这些行。当识别出一个字之后，该字将被放入一个由位置175处所输入的名称所指明的串变量中，该串变量在图17B的行5中指明。

可以用位置176处的软开关来选择对讲话人的依赖性(是否与讲话人有关)，若选择“与讲话人有关”，则可以对一个指定的个人识别比选择“与讲话人无关”时更为复杂的语音，而当选择识别处理为与讲话人无关时，则必须对付大范围的讲话人语音，但其复杂程度较低。对于“与讲话人有关”的情形，可以通过选择参数按钮177来指定详细的参数，其结果是向用户呈现一个附加的窗口，参数可以在其中指定。这些附加参数在图17B的行6至14中指明。

“记录语音”位置178可使实际的语音被数字化并存储在一个文件中，其后它可以被请求平台上的其他模块或程序使用。例如，它可以用作自动电话应答系统的一部分，其中记录了每一个消息，用来当以后用户要求重放他或她的消息时进行重放。记录语音数据在图17B的行15至18指明。在询问模块中提供了“声音不清”和“静止无声”消息位置，以分别定义对不清楚的语言和静止无声的适当的应答。

图18A所示的“是/否”模块提供了与上述询问模块相类似的功能。在该模块中只识别两个字：是和否，所以语言识别被简化了，免除了对识别的“与讲话人有关”模式和ZSML最优化。在所有其他方面，该模块的操作和询问模块相同。图18B示出了是/否模块的剧本规范。

图19A所示的记录模块用来在重放一个定义了的消息提示之后记录呼叫人的消息。其中存储有数字化的语言的文件的名称在位置179处指明。该数字化语言的比特率或PCM率(脉码调制率)在位置180处指定。提供了一个说明标志位置来说明语言文件的内容，例如“信用卡地址”，或者可以用来指明一个含有以前指定的说明标志串，例如“是你今天的第二次呼叫”。

可以指明“记录时间”和“最后时间用完”，以分别定义以秒为单位的消息最大长度和该模块失效之前后容许的静止无声的最大长度。提供了一个“接受长消息”开关，当它被操作时，它将在呼叫者的说话超过记录消息的最大长度时阻止产生模块失败情形(但超过时间限制的语言将被丢失)。图19B给出了由记录模块产生的剧本。

图20A详细示出了重放模块。该模块重放保持在特定文件，例如由执行记录模块时所产生的文件中的一个或多个过去记录的消息。在文件名称位置182处可以指定多个文件名称。图20B示出了由重放模块产生的剧本。

图21A示出了一个外部模块。该模块提供一个与外部可执行程序(即.EXE程序)之间的双向通信手段。例如，外部模块能够提供向一个公司的数据库程序的调用，它包括例如呼叫者名称和用户帐号的一些变量。然后该数据库可以查找该用户的一些详情，并返回包含一些是具体数据的信息，这些数据例如是用户与该公司交易帐目中的当前欠帐情况。图21B示出了由外部模块产生的剧本。

图22A示出了一个短句模块。该模块使得在图形用户界面这一水平上可以把ANSI C或C⁺⁺源码插入到请求之中。C或C⁺⁺源码可以处理变量和调用由该模块表格其他部分所指明的例行程序。然而，这个水平上的操作可能要求操作者十分精通于请求开发平台所产生的C或C⁺⁺操作环境。引头文件、程序库文件和预先编译的目标文件都可以被指定，以供在该短句模块中所提供的C或C⁺⁺代码调用。所以C或C⁺⁺代码可以用来访问全面的应用的应用软件，例如外部模块中关于数据库的例子。

通过提供C或C⁺⁺水平上的对这些类型功能的访问，用户定义的C或C⁺⁺代码、应用软件、以及系统软件都可以有效地互相引用，并且同时被编译。这使得可以用编译之前的C或C⁺⁺代码来实现人工和自动的最优化，结果可以得到较快速的、具有更有效的运行时间的软件。

再有，对于希望通过修改C或C⁺⁺代码来修改服务的服务提供者来说，将得到十分大的灵活性，其原因在于整个系统可以用C或C⁺⁺来指定，并且以后又在C或C⁺⁺水平上进行修改。图22B示出由短句模块产生的剧本。

图23A示出了一个转换模块。该模块提供一个条件测试，以选出哪一个可能的后继模块将是该服务中的下一个。位置183中的一个表达式将根据类似于C语言的表达术语来估值。如果该估值的输出为零，则它被赋予布尔标志“真”；如果输出不为零，则被赋予“假”。流程的控制可以根据一个用户定义的连接标签的特定值来转换，在该情形下对于变量可能取的每一个值都要求有一个用户定义的连接标签。图23B示出了由转换模块产生的剧本。

图24A示出了一个测试模块。该模块类似于上述的转换模块，其差别仅在于这里的输出只能被评为“是”(零)或(非零)。相应地，流程的控制将按照标有“是”或“否”的连接方向转移。图24B示出了由测试模块产生的剧本。一个具体服务的工作例子

现在将针对一个实际工作的服务，说明图5A中所指明的服务生成过程。将要说明的这个服务允许一个呼叫的用户呼叫一个特定的号码，以获得关于一个演出，例如一个音乐会等的信息。该服务首先表明自己的身分，，并邀请呼叫用户按下按钮1以获得关于表明演出的性质的信息，或者按下按钮2以获得表明是否可得到座位的信息。在提供了任一种类型的信息之后，系统将挂机。所以应该理解，这里所说明的服务，仅仅是一个表明服务是如何生成的例子。在一个这种类型的实际工作的服务中，还可以包括一些环路，例如从一次呼叫就可得到上述两种类型的信息，并且还可以包括一些更复杂的方面，使呼叫用户可以预定座位或者获得关于将来演出的信息。

如图5A的步骤51中所指明的，该第一步由在图形用户界内定义服务结构所组成。这样，如图6所示，在初始化过程已经生成了一个可滚动幕布以及一个建筑模块菜单和下拉式茶菜单之后，定义一个服务名称，然后将显示图9所示形式的幕布。

为了生成上面所说的服务，需要从菜单91中选择应答模块，它将应答输入的呼叫。其后，需要选择DTMF模块，它将邀请用户进行键盘选择，并在其后将响应于代表数字1的输入信号和代表数字2的输入信号。为了回答输入数字1需要一个信息模块，它将向呼叫用户传递表明在某个具体日期所进行的演出的类型的信息。其后系统将挂机，所以还需要含有一个挂断模块。为了回答代表数字2的输入信号，需要获得关于是否可获得座位的信息。很明显，这个数据要求在常规的基础上来更新，因此可以看到该系统应与一个跟踪定座情况的数据库相通信。调用外部数据库将需要开发附加的编码，可以借助于一个外部模块或一个独立的短句模块或者借助含于某一个其他模块内的短句前或短句后模块来把该编码包含在整个系统中，当接收到信息之后，需要第二个信息模块来把该信息传送给呼叫用户，其后系统仍要挂机。因为一个挂断模块可以接收许多个输入连接，所以只需要指定一个挂断模块。

实现上述服务的连接布局如图25详细所示。该服务由系统自动呈现一个开始模块191启动，它有一个向应答模块192的OK连接，后一模块已被赋予了单独的名称ans1。一个OK连接把应答模块192连接到DTMF模块193，后者已赋予名称dtmf1。

在DTMF模块中，当响应于用户所选择的“1”时，控制即从DTMF模块193被导向第一信息模块195，其名称为info1。这样，DTMF模块193和信息模块195之间的连接边上有一个连接名称“1”。

类似地，DTMF模块193和外部模块194之间的连接被赋予连接名称“2”，上述外部模块194被赋予的名称是extnl。一个OK连接将模块194连接到第二信息模块，后者的名称为“info2”，它又把从外部模块194中所执行的外部调用时所得到的信息转递给呼叫用户。当把该信息传递给用户之后，系统即挂机，这一点由把信息模块196连接到挂断模块197上去的“OK”连接反映出来。

DTMF模块193通过一个“失败”连接也连接到挂断模块197上。这样，如果一个用户没有能提供数字“1”或数字“2”，则DTMF模块193将探测到一个“失败”条件，于是系统将在挂断模块197的控制之下挂机。挂断模块197被赋予的单独名称是hangl，其后控制被导向结束模块198。

指定了图25所示的服务连接布局全貌之后，便如图5A的步骤52所说明的那样检验该结构的正确性，以确保它的内部是自洽的，并可以由此开发完整面貌的服务。该结构应该导致对步骤53中的询问的回答是肯定的，其后可以选择各个模块来输入参数并在步骤56中更新文本文件。

可以用任何顺序来选择各个模块以输入参数。再有，当调出一个模块表格后，可以用任何顺序来把各参数输入到该模块中。操作相应的“OK”按钮，例如图11A中的按钮113，将使各参数被写入到一个包含有象图11B中所定义的那种按剧本编码的参数的文本文件中。然而，通过再次操作该OK按钮，模块参数和相应的文本文件都是可以修改的。不过，在本例子中，各模块的参数化(即把各参数输入到各模块中去)将按一个特定的顺序来说明，一个完成该服务生成的操作员可能实际上就是这样来执行的。

选择应答模块192，结果将显示出如图11A所示那样的的应答模块表格。关于这个特定例子的应答模块表格如图26A所示。已往在模块名称位置上写入了模块名称ansl，结果在图26B所示的文本文件的第一行中写上了一个指令：tel-answer-block：ansl(电话-应答-模块：ansl)。“模块时间用完”软开关没有被操作，因此该服务将持续在应答模块上等待，直到一个呼叫。结果，不需要有相应的代码写入到文本文件上。

在模块表格中已经指定了应答前的响铃时间，结果使文本文件的下一行上含有指令：arg：“ringto ans time”3(变量“应答前响铃时间”3)。类似地，“开始计费”软开关已被操作，结果使文本文件的下一行上含有指令arg：“start billing”true(变量：“开始计费”真)。

因为没有定义算术或短句功能，因此下一行含有下一个模块的指向，最后接着终结模块限定标志。

在选择了应答模块的OK钮后，使文本文件被修改，并选出DTMF模块193，以对该模块加入参数，如图27A所示。指定模块名称dt mf l造成相应文本文件的第一个指令dtmf block：dt mf l(DTMF模块：dt mf l)。

设定了关于清洗键前缓存器的软开关，因此文本文件的下一行指明arg：“flush buffer”true(变量：“清洗缓存器”真)。类似地，数字串已被设定为“固定选择”，并且已指定最大位数是1。于是，图27B的文本文件的下一行含有指令arg：“max digts”1(变量：“最大位数”1)。

已经设定了“静止时间完”，并指令了静止时间为8秒。所以，文本文件的下一行含有指令arg：“pri-time out”8(变量：“静止时间”8)。

DTMF模块沿着多个编号的流程路线中的一个转换流程的控制。于是，如果呼叫人在键盘上按下“1”，则流程将被转换到标有“1”的流程路线上。类似地，流程也可以转换到标有“2”的流程路线上。这两种可能性的剧本都已经示出。

提示信息的开始由一个指令行dtmf-form：dt mf l(DTMF-形式：dt mf l)指明，文本文件的下一行含有在第一提示消息位置处输入的提示消息。这样，在选择了(操作了)第一提示信息位置之后，就输入了一个适当的消息，例如“要了解今晚音乐会的细节请按按钮1，要了解定座情况请按按钮2”。这造成了P1：dt mf-form：dt mf l (P1：DTMF-形式：dt mf l)后面行上的指令。在系统错误位置上还含有一个系统错误消息，其形式为“抱歉，出现了技术故障。”这造成了文本中的一个行，其形式为“system error：sorrythere is a technical fault”(“系统错误：抱歉，出现了技术故障)。然后文本文件的终结，特别是形式信息的终结，由指令”end form”指明。

然后可以选择信息模块195，结果将显示出信息模块表格，以便在其上加入数据，如图28A所示。这使得产生一个特定的文本文件，如图28B所示。

可以选择外部模块194，结果将显示出外部模块表格，以向它输入特定的命令，如图29A所示，其结果是产生一个如图29B所示类型的文本文件。

可以选择信息模块196，结果将显示出信息模块表格，以向它输入各参数，如图30A所示，其结果是产生一个如图30B所示的文本文件。

可以选择挂断模块197，结果将显示出挂断模块表格。各参数被输入该挂断模块表格，如图31A所示，结果产生了一个如图31B所示的文本文件。

按照常规，特定的语言请求是用写出的剧本来定义的，由此可以人工地用程序语法写出可操作的语言。这样，一个程序员将根据剧本在语言请求平台上以直接可执行的形式产生代码，或者，也可以用一种中间语言，例如C或C⁺⁺，来产生代码，以使上述代码得以下载到不同种类的请求平台上。由现在的系统产生的页文件的形式对一个操作人员来说是有意义的(可懂的)，并且相似于已知的剧本语言。所以，可以认为本系统第一阶段的主要特点是，把在图形用户界面中定义的各个指令转换成剧本文件，这里把它们称作页文件和形式文件，这种文件是人类可读的，同时也是机器的可读的。

如前所述，一旦一个服务已往完全被定义成一个流程图，并且各个参数已经被输入到所有的模块表格中时，服务生成的下一步将是把多个文本文件(每个文件是在参数输入时对一个特定模块产生的)翻译成为一些页文件和形式文件。在本例子中，为了定义整个服务将只产生一个页文件和一个形式文件。然而，应该指出，在较复杂的流程图中，那里的页模块是用来在较低级的水平上定义一个附加的流程图的，则对每一个水平上的一个流程图都要产生单一个页文件和单一个形式文件。这可以设想为，对所使用的幕布的每一“页”都有一个页文件，而且页文件和形式文件总是成对地产生的。对于产生多个页文件和形式文件的情况，其中有一个页文件是主页文件，这将通过使服务的名称作为它的文件称的一个组成部分来表明，例如THEATRE.PGE(剧院.页)。

带有扩展名.PGE的页文件将包含所有.TXT文件(.文本文件)的模块功能剧本的拷贝。模块功能剧本是剧本中的这样一些部分，它们包含在文本文件中例如query-block：(询问模块：)和endblock(模块结束)限定标志之间。这样，页文件将以剧本语言提供整个服务的功能说明，这种剧本语言可以被服务设计人员读出，    并且也适合于直接翻译成C⁺⁺代码。

带有扩展名.FRM的形式文件将包含所有.TXT文件的模块形式剧本的拷贝。模块形式剧本是剧本中的这样一些部分，它们包含在例如query-form：(询问一形式：)和ehd block限定标志之间。作为操作页文件相应部分的一个部分，形式文件将提供可以用合成语言的形式向呼叫人重放的文本数据。应该指出，并不是所有的模块都产生形式数据。

这样，页文件和形式文件共同定义了构成服务的一个完整页所需要的操作和数据。在本例中，由于只使用了一个流程图页，所以页文件和形式文件共同定义了整个服务。

图32详细地未出了产生页文件和形式文件的过程。在步骤303中询问是否需要定义另一个流程图页。如果答案是否定的，则不需要再产生.PGE或.FRM文件，于是控制流程转换到图5B(服务模拟)的步骤57。如果需要定义一个新页，则控制转换到步骤304，在那里对各模块之间的连接进行分析，以产生一个逻辑模块次序，它大致地代表了C⁺⁺程序的等级结构，该C⁺⁺程序最终将从含在页文件中的剧本来产生。

在步骤305中检查清单中是否还剩余有另一个建筑模块要拷贝到页文件和形式文件中去。如果答案是否定的，则控制返回步骤303。如果答案是肯定的，则控制转换到步骤306。在步骤306中，含有指定模块的文本文件被打开，使其内容可被读出。在步骤306中，含在××××-block：和end block限定标志之间(包括这两者)的文本被拷贝到当前的页文件中。在步骤307中，含在××××-form：和end form限定标志之间(包括这两者)的文本被拷贝到当前的形式文件中。这样，就从模块参数输入时所产生的各文本文件构筑出了一个页文件和一个形式文件。图33示出了以这种方法从现在的剧票例子中构筑出的页文件，图34示出了相应的形式文件。利用短句代码扩展模块功能

可以利用短句模块或模块前短句和模块后短句附加区，在流程图上把短句代码择入到系统设计中去。短句代码是一种用C或C⁺⁺写出的代码，用来扩展由程序前功能模块所提供的功能范围，使服务设计员不再受到作为服务生成工具的一部分而提供的程序前功能模块范围的限制。当一个服务被自动地从剧本文件翻译成C或C⁺⁺指令时，可以在得到的C或C⁺⁺程序的适当位置中插入短句代码。

这样，该服务生成工具提供了人工编程的灵活性，同时又能自动地执行把剧本翻译成C或C⁺⁺的艰难工作。

由图25所示的外部模块194可以用含有一些C或C⁺⁺代码行的短句模块来取代。

这样做有几个可能的原因。有可能用以C或C⁺⁺写出的一些子程序来完全替代由外部模块所调用的外部程序。这样该服务就可以在很大程度上被定义成一个自足的整体，而不必调用其他软件。这将能够在速度方面、改进找错的容易性方面、以及可以实现的操作的更大灵活性等方面有好处。

图35示出一个与图25所示的服务相同的例子，但其中的外部模块已被一个短句模块351所代替。这样，该短句模块利用当地的C或C⁺⁺指令执行着与原来外部模块所提供的相同的功能，后者执行完全分开的程序中的指令。

图36A示出短句模块表格和执行从一个数据库提取关于剧院定票情况的操作的一些C或C⁺⁺代码的例子。该短句模块使程序员可以定义引头文件和程序库文件，以把它们包含在服务中的整个C或C⁺⁺程序中。这样，由软件开发员以前生成的功能的指定程序库可以被包含进来，以为指定的操作提供必要的子程序。在本例的情形中，选择了一个数据库引头文件，它定义了对各功能的程序库的访问，以产生、访问和操作数据库。在所示的短句模块例子中，程序行#include<database.h>(#包含<数据库.h>)定义了对称之为database.h(数据库.h)和database.lib(数据库.程序库)的例行程序的程序库访问。

该C或C⁺⁺代码含有变量说明：

theatre^*Index；(剧院^*指针；)

它说明指针^*Index被用作一个关于一个用来存储剧院记录的数据库中的变量的指针。功能：

Lookup Record(^*THEATRES，“MADISON”Current Date，^*Index)查找记录(^*剧院，“MADISON，”当前日期，^*指针)；

在一个由恒定串变量THEATRES(剧院)所定义的数据库中查找一个记录，在记录的名称位置上寻找一个叫做“MADISON”的剧院的一个特定记录，并在与系统变量Current Date(当前日期)有相同值的位置上寻找出存储在该记录中的信息。通过更新^*Index的值，然后它便指向含在关于日期的位置的子组中的信息，于是该信息便被传送回来。操作：

seat＝Index.availability；(座位＝指针.可获得性；)指定了关于座位变量的Index(指针)的可获得情况单元中的值，于是这个值就可以被服务中的其他模块访问。

图36B示出了由短句模块例子所产生的剧本。可以将它与图22B所详示的短句模块的的剧本定义相比较。

实现数据库操作第二种可另供选择的方法是在信息模块info2的模块前短句中包含C或C⁺⁺代码，该inof2模块再次在图37中示出。在图37中，由于服务的功能在流程图中表示得很清楚，其中info2模块196不仅提供关于提取信息的实际操作，而且还把该信息向呼叫人重放，所以短句前模块的优点变得很清楚。

图38A再次示出了信息模块。通过操作短句前按钮361便可把C或C⁺⁺代码输入到短句前模块中。该按钮的操作结果将出现一个次级窗口，该窗口提供了一个与由短句模块表格所提供的相类似形式的表格，以供把C代码作为文本输入进去。类似于图36A的短句模块中所示的、并且给出相同功能的C或C⁺⁺代码示于图38B的修改的info2的剧本文件中。

短句前C或C⁺⁺代码，正如其名称所表示的，是在模块操作之前执行的。可以利用图38A中所示的算术前按钮363来在模块操作之前定义简单的算术操作，以对系统变量进行操作。类似地，模块表格上的算术后按钮362和短句按钮364提供了用来定义模块后算术功能和模块后C或C⁺⁺代码的手段。任何模块都可以提供有多达4组的附加功能代码部分，它们可以用来增强或修改那个模块的操作。功能模块的定义前程序库就以这种方式被赋予了增大的灵活性。

显然，以C或C⁺⁺在这种前后文件编程超出了缺少经验的程序员的能力范围。然而应该指出，值得向同时具有C或C⁺⁺编程和服务结构的人员投入大量的专门知识。这样，一个在高效率的图形用户界面上结合了这两种设计方法的系统将可以比其他一些系统有巨大的优点，这些其他系统是仅仅为新手们设计的，而且缺乏C或C⁺⁺扩展所能提供的巨大的灵活性。离线服务模拟

正如图5B的步骤57所指明的，在步骤61中产生可下载代码之前，有可能模拟一个服务的操作。这使得下述工作变得容易：在产生可下载代码之前，对系统进行修改，然后再次进行模拟。

虽然产生可以在真实的语言请求平台上执行的代码是通过一次性的编译处理来实现的，但服务的模拟是通过对页文件和形式文件的逐行翻译来完成的。模拟可以在图3所示的用来设计和生成该服务的开发系统上来执行，这叫做远模拟。或者，模拟也可以在图2所示类型的设备，也即实际的语言请求平台上执行。当模拟在请求平台上执行时，该平台应该已经为此目的而编程，以方便于系统开发。所执行的过程基本上与远模拟所进行的过程相类似。在实际的请求平台上进行模拟提供了真实的运行环境，编译后的可执行代码即在该环境下真正地运行。然而，在远处的开发系统中进行模拟可以采取一些可节省时间的捷径，例如在模拟语言识别时即可如此，而且，这还可以对系统的操作进行统计分析。图39详细地示出了图5中步骤57所指明的过程。

参见图39，步骤402至408仅仅涉及到在远处开发系统上所执行的模拟。步骤409至412涉及到在实际请求平台上所执行的模拟，同时也涉及到在远处开发系统上所执行的模拟。开发系统可以用类似于在语言请求平台上所能执行的方式来执行语言识别，或者，也可以由执行识别处理并给出适当应答的操作人员来模拟识别过程。在步骤402中询问是否要执行自动识别，如果答案是肯定的，则在步骤403中指定一些识别样板并在步骤404中打开含有被指定样板细节的文件。其后，控制被导向步骤408。

或者，如果对步骤402询问的答案是否定的，则控制被导向步骤405，在那里询问是否要以百分比来引入模拟错误，或者上述错误是否要从关于平台的统计性质来导出(这里可以把“关于平台的统计性质”叫做SAP)。如果选择了平台统计性质，则控制被导向步骤406，在那里安装上述的统计性质，然后控制导向步骤408。

或者，如果对步骤405中询问的回答是要引入百分比错误，则控制被导向步骤407，在那里记录这个选择，并安装百分比错误的例行程序。

在执行了步骤406或407之后，控制被导向步骤408。在步骤408中，用户被要求定义一些操作数据，其中包括，关于模拟是要连续地运行还是要以适合找错的分立步骤运行的决定，关于是否要产生可听到的蜂鸣声的决定，以及关于是否要记录用户的模糊不清的语言等。

当用户已经定义了这些在模拟内务例行程序中主要使用的操作数据之后，控制被导向步骤409，其后，不论这后面的过程是在开发系统上还是在语言请求平台上执行，它们基本上都是相似的。

在步骤409中，通过审查页文件和形式文件来确定该服务的结构并定义操作的状态。其后，当执行模拟时，由剧本所定义的指令被翻译。这样，在步骤410中读出下一个模块。在步骤411中执行该模块的指令，然后在步骤412中询问是否要处理另一个模块。如果对此询问的答案是肯定的，则控制返回到步骤410，否则控制返回到图5B的步骤58。

图40详细示出应答模块的模拟过程。由于在页文件中，在每个模块定义中都含有剧本的一些特定行，它们指明了一个模块是如何与其他模块相连接的，以及在什么条件下与其他模块相连接，所以该页文件将指明在应答模块之后应执行哪些模块。

应该注意，图40的步骤415实际上是图39的步骤410的一个指定的实现。在步骤416中执行模块前操作，其中可以含有算述前说明和短句前说明，关于这两个说明将在以后描述。

在步骤417中询问是否接收到了一个呼叫。该系统将在步骤417上等待一段时间，这个时间是由图11A中所标明的“模块时间用完时间”来确定的。如图26A中所示，该模块时间用完时间软开关可以不予操作，结果使系统将总是在步骤417上等待，直到接收到一个呼叫。或者，如果给模块时间用完时间设定了一个特定的时间，便有可能对步骤417的询问得到否定的答案，其结果是控制被导向步骤420，得到关于失败信息的反馈。

另一方面，如果接收到一个呼叫，对步骤17中询问的答案是肯定的，则结果将在步骤418中应答该呼叫，应答响铃时间应如图26A所示，已作为模块参数设定，对呼叫的应答将在此预先设定的时间之后进行。应答了呼叫之后，将在步骤419中产生一个系统“OK”消息，然后控制转到步骤421。

模拟内务在步骤421中执行。与请求平台相比，在开发系统上执行模拟时其模拟内务的水平要高得多。例如，可以在模块产生系统“OK”消息时发生蜂鸣声，并且说明一个呼叫是否被应答了的数据可以被记入模拟日志文件。其后，在步骤422中执行模块后操作，然后控制返回到图39以步骤412。

图41示出模拟挂断模块的步骤。在步骤425中从页文件读出挂断模块数据，在步骤426中执行模块前操作。在步骤427中该呼叫被清除。在步骤428中反馈系统“OK”消息。模拟内务在步骤429中执行，模块后操作在步骤430中执行，其后控制返回到图39的步骤412。

图42详细示出了拨号模块的模拟步骤。在步骤431中从页文件读出拨号模块剧本，在步骤432中执行模块前操作。

在步骤433中用为拨号模块记录的预定号码进行拨号，在步骤434中询问该呼叫是否已被应答。页文件的剧本定义了在步骤434作出决策之前系统应该等待多久来得到呼叫的应答。如果后来该呼叫得到了应答，则控制被导向步骤435，并且有一个“OK”标志反馈给系统。或者，如果对步骤434询问的答案是否定的，则将产生一个“FAIL”失败标志。不论是哪种情形，都在步骤437中执行模拟内务和在步骤438中执行模块后操作，接着，控制返回到系统的步骤412。

当信息已经反馈给系统之后，在步骤437中执行模拟内务操作过程，其后在步骤438中执行模块后处理，再后控制被导向步骤412，以进行另一模块的模拟。

图43详细示出了转移模块的模拟过程。在步骤441中读出关于转移的模块的数据，在步骤442中执行模块前操作。

当连接上了一个当前的呼叫，并且上述呼叫需要重新连接到另一个线路上，以有效地使请求平台和外部用户切断联系时，就应包含一个转移模块。这样，在步骤443中保持当前呼叫的状态，并在步骤444中用指定的转移号码进行拨号。

在步骤445中询问所拨的号码是否得到了应答，经过了指定的“时间用完时间”后，上述询问的答案将可能是否定的，结果使控制被导向步骤449，或者，当上述问题的答案为肯定时，则控制被导向步骤446。

如果对步骤445询问的答案为肯定时，则在步骤446中把该呼叫连接到该有应答的线路上，接着在步骤447中有效地挂断请求平台或其模拟设备。其后，在步骤448中反馈一个“OK”标志，接着控制被导向步骤451。

另一方面，当被呼叫的线路没有应答时，则对步骤445询问的答案为否定的。其后，控制被导向步骤449，在那里重新连接上原来的呼叫，并在步骤450中反馈一个“FAIL”(“失败”)标志。

在步骤451中执行模拟内务的过程，产生蜂鸣声和登记日志数据等等，然后在步骤452中执行指定的模块后操作，其后，控制被导向步骤412。

图44详细示出了信息模块的模拟过程。在步骤456中执行模块前操作，其后控制被导向步骤457，在那里读出该信息模块文件的内容。在步骤458中，向电话线路重放信息，在步骤459中执行适当的模拟内务。模块后操作在步骤460中执行，其后控制被导向步骤412。

图45A和45B详细示出了DTMF模块的模拟过程。在步骤461中读出该DTMF模块的数据，在步骤462中执行有关的模块前操作。DTMF模块将提示呼叫用户通过按下用户电话机上的按钮来输入由此产生的音调，这种电话机必须是DTMF类型的。该系统的设计使得，在把该模块操作处理为失败之前，可以发出3个提示消息。

在第一个循环的步骤463中，安装第一个提示文件，并在步骤464中把上述文件以语言的形式向呼叫用户重放。在步骤465中，询问是否接收到了一个音调，如果答案是否定的，则在步骤466中询问是否已经重放了3个提示消息。如果对步骤466中的询问的答案是否定的，则控制返回到步骤463，在那里安装第二个提示文件并在步骤464中将它重放。在步骤465中再次询问是否接收到了一个音调，对此的答案仍可能是否定的，结果造成重放第三个提示。如果对步骤465询问的答案是肯定的，则表示已接收到了一个音调，于是控制被导向步骤468。

如果产生了3个提示消息之后对步骤465询问的答案仍是否定的，则意味着没有接收到任何音调，于是在步骤467中给出一个关于模块失败的标志，其后控制被导向步骤479。

当对步骤465的询问得到肯定的答案，从而控制被导向步骤468时，在该步骤中询问是否期待着一个固定位数的数字。如果答案为肯定的，则控制被导向步骤469，在那里收集上述指定数目的音调，然后控制被导向步骤472 。

如果对步骤468询问的答案是否定的，这意味着没有定义过音调的指定数目，则控制被导向步骤470，在那里收集一个音调。其后，在步骤471中询问所接收到的音调是否代表一个方块音调(通过按下电话键盘上的“#”键所产生的DTMF音调)，该音调表示消息的结束。如果接收到的是方块以外的一个音调，则对步骤471询问的答案是否定的，于是控制返回到步骤470，在那里再收集一个音调。这样，步骤470重复地执行，结果收集到一些音调，直到接收到一个方块音调。

接收到方块音调之后，对步骤471中询问的答案是肯定的，控制被导向步骤472，该步骤也出现在成功地执行了步骤469之后，在步骤472中，询问这些音调是否有效。如果对该询问的答案是否定的，这意味着这些音调被认为是无效的，则在步骤473中从形式文件安装一个“TONES INVALID”(“音调无效”)消息，关在步骤474中重放该消息。然后在步骤475中询问这是否是第三次获得音调的尝试，如果答案是肯定的，则控制被导向步骤476，在那里反馈一个模块失败标志。

如果对步骤472询问的答案是肯定的，则控制被导向步骤477，在那里保留数据，并且于步骤478反馈关于该模块已成功地执行了的标志。

在步骤476和478之后，在步骤479中执行模拟内务，包括登录日志数据等等，在步骤480中执行模块后操作，其后控制被导向步骤412，以允许模拟下一个模块。

图46示出了询问模块的模拟过程。该询问模块设计得让用户可以用语音来和语言请求平台通信。平台上提供有语言识别设施，输入的语言被与一些样板式模型(HMM隐蔽马尔科夫模型意义上的)进行比较，以确定该输入的语言是否属于可识别的种类。当作出了一个识别时，就有相应的信息被返回，以后的决策就可以据此来做出。

在步骤490中，安装指定的询问模块数据，在步骤491中，执行模块前操作。在步骤492中，从形式文件读出提示消息，该消息在其后的步骤493中被重放。

该提示消息提示用户对系统讲话，在步骤494中记录输入的语言。在步骤495中询问是否探测到了语言，如果答案是肯定的，则控制被导向步骤497。或者，如果没有探测到语言，则控制被导向步骤496，在那里询问这是否是第三次试图获得语言。如果答案是否定的，则控制返回到步骤492，读出另外的提示消息，并在后面的步骤493中重放该消息。

如果对步骤496询问的答案是肯定的，这意味着已经进行了三次获得语言的试探，则控制被导向步骤499，在那里反馈一个关于模块失败的标志，然后控制被导向步骤502。

如果对步骤497询问的答案是肯定的，这意味着该语言可识别的，则控制被导向步骤500，在那里选出适当的答案，并在步骤501中反馈关于该答案的标志，其后控制被导向步骤502。

在步骤502中执行模拟内务，如把结果登记在日志上等等，在步骤503中执行模块后操作，然后控制被导向步骤412中的提问。

步骤497负责语言识别操作，该操作可以按照几种可能的技术来实现。可以用一个基本的开发系统来实现模拟，在那里该识别是由操作人员来执行的。以这种最简单的形式，该识别将是十分准确的，但不能反映语言请求平台所能达到的准确度水平。为了克服这个问题，有可能将百分比错误引入到语言识别系统中，使得尽管操作人员可以正确地识别输入语言，但是这种识别中一个预定的百分比被变成是错误的，从而系统的开发员可以估计这种错误识别的产生率。

应该看到，采用简单的百分比错误技术，实际的错误发生率将不能代表一个真实的语言请求平台的典型错误分布。在一种加强的系统中，虽然语言识别由操作人员执行，但将提供一个确认矩阵，它详细地表示了做出正确选择的概率和作出每一个可能的错误选择的概率。确认矩阵通过产生一个随机数来使用，并且对所有可能的随机选择都提供有确认矩阵中的一个有效位置，只是对于特定的输出，这种数的分配应该能反映由一个真实的语言请求平台所选择的输出的概率。这样，在产生了一个随机数之后，它在确认矩阵中的位置便被确定了。于是，对于一个出错十分稀少的特定短句，将有许多可能的数被放置在这里，使得能够保持正确的识别，只是偶而会产生错误的输出。另一方面，某些正确的答案处可能只有很少的上述随机数被分配在那里，这反映了一个特定的字或短语经常被真实操作系统错误地识别。这样，错误分布就可以按这种方法以反映真实请求平台中的已知分布水平被导入到该系统中。再有，不同的请求平台可能有不同的响应，而这些响应可以反映在特定的确认矩阵之中，每个这种矩阵可以用于同一种服务的不同模拟中。

在另一种加强系统中提供了自动语言识别，其方法类似于提供给一个真实语言请求平台的语言识别方法。采用语言识别样板是本技术领域所熟知的方法。样板是产生来代表一个特定字或短语的平均特征的。然后对输入数据进行采样，并与样板相比较，使得设备能够确定是否已出现了一个特定语言的语音。然而，现在利用基于语言识别的真正的样板要比利用称之为隐蔽马尔科夫模型(HMM)方法的那种有竞争力的、基于统计学的技术不利得多。因为本专利申请的主题不是语言识别自身，而是服务生成工具和方法，所以这里不适宜于详细解释HMM和其他识别技术是如何工作的。向读者推荐一本由L.Rabiner和B.H.Juang所著的极优秀的教科书“Fundamentals ofSpeech Recognition”(“语音识别基础”)，由Prentice Hall于1993年出版(特别是第6章)，同时推荐这两位作者的许多其他出版物。

由于对同样的短语可能需要有大量的语言语音来构成这些语音的平均特征，产生语言样板或分立的字模型(在HMM系统中)可能要牵涉到大量的工作。图39中所指明的模拟过程使一个操作人员能够执行这样的语言识别功能，该功能允许模拟在构筑样板之前进行。

识别词汇可以利用子字建模技术来快速地产生，该技术假定一种语言中的所有字都可以用一小组声音单元或声元来描述。为了在词汇中添加一个新字，操作员需指定一组代表该字的声元。通常这是从一本词典获得的，词典包含了许多字的一个清单以及与它们相联系的声元序列。当不能从字典中找到某一个字时，便利用一组规则猜测这个字是如何发音的。这种子字建模系统最好能基于统计方法，例如HMM。用户简单地利用例如键盘打印在一个文本空格中输入一个字或字的序列作为文本。然后这个字可以进行拼法检查(虽然可以用子字建模对拼法检查器中没有的字，例如对新发明的字或实际的人名等，来建立识别模型(或模型序列))。一旦用户满意于该字的拼法，请求平台就可以通过按按钮来生成适当的子字模型序列。该系统还可以包括例如较普通的命令字、数字等等的全部字模型。然后，可以根据一个文本产生出服务对话，该文本是通过组合各个子字模型和必要时的全部字模型而输入的。

对于这种类型的语言识别系统，识别器需要语言中每一个声元的模型(例如隐蔽马尔科夫模型)。这种模型是根据几百个人所讲的富有各种语音的句子的数据库制备出来的，而且假定环境条件，例如电话线路和电话听筒的质量没有很大的差异，这种数据库对每一种语言只需要收集一次。与这种系统相关的主要成本在于最初收集和制备数据库和词曲时的费用。

应该承认，由于子字模型不象全部字模型那样精确地代表词汇，所以当使用子字语言识别时，系统的性能将较差。然而，它可以非常快地产生新词汇，从而能快速地产生请求。再有，如果需要改善系统的精度，可以在运行请求的同时收集数据，并离线地处理这些数据，以产生完全字模型供以后使用。

子字模型的产生和使用在下述文章中有所说明：“Subword-Based Large-Vocabulary Speech-Recognition”(“基于子字的大词汇量语言识别”)作者Lee、Gauvin、Pieraccini和Rabiner，发表于AT&T Technical Journal(美国电话电报公司技术期刊)，1993年9-10月期。和前面一样，推荐读者参阅Rabiner等人在子字建模方面的其他论文，以获得进一步的细节。

图47详细示出记录模块的模拟指令。在步骤511中安装指定的记录模块数据，在步骤512中执行模块前操作。

记录模块使得可以记录来自用户的语音消息。在步骤513中安装提示数据，在步骤514中上述数据被提供给用户，提示该用户要记录一个消息。在步骤515中启动记录，在步骤516中询问是否接收到任何消息。如果答案是否定的，则在步骤517中询问这是否是第三次尝试，如果答案是否定的，则控制返回到步骤513，在那里安装下一级的提示并在步骤514中重放。

如果已往做了三次要记录信息的尝试，并且每次都没有成功，从而对步骤517询问的答案将是肯定的，结果造成向系统反馈一个“FAIL”标志，其后控制被导向步骤521。

如果对步骤516询问的答案是肯定的，这意味着已往接收到了语言，则控制被导向步骤519，在那里询问该消息是否太长。如果答案是肯定的，则控制返回到步骤513，再次进行要记录消息的尝试。

如果该消息不是太长，如果对步骤519询问的答案是否定的，则在步骤520中反馈一个“OK”标志，肯定该记录过程已经成功，其后控制被导向步骤521。

在步骤521中，执行模拟内务过程，在步骤522中，执行模块后操作，然后控制被导向步骤412，使下一个模块得以被模拟。

图48详细示出外部模块的模拟过程。在步骤525中安装指定的外部模块数据，在步骤526中执行模块前操作。在步骤527中，系统调用指定的外部例行程序，并在步骤528中询问是否已经从上述调用接收到了数据。

如果对步骤528询问的答案是否定的，则控制被导向步骤529，在那里反馈一个“FAIL”标志，然后控制被导向步骤531。如果对步骤528询问的答案是肯定的，这意味着已经从调用中得到了数据，则控制被导向步骤530，在那里反馈一个“0K”标志。其后，控制被导向步骤531，在其中进行模拟内务过程，接着在步骤532中执行模块后操作，其后控制被导向步骤412。可下载指令的生成

可下载C或C⁺⁺指令的产生由本优选实施例的系统自动地执行。尽管这些指令(以下称作程序)可以自动地产生，但可以得到一些高级的任选项供有经验的服务设计员和程序员使用，以便能够由C或C⁺⁺引头文件来调用C/C⁺⁺程序库、目标代码程序库和有关的其他程序库。这些任选项的形式是附加的图形输入手段，它叠加在两个分别叫做系统总体文件和服务总体文件的文件中的省缺剧本参数上。这两个文件提供了在把页文件(及其相应的形式文件)翻译成C或C⁺⁺程序时所需的信息。

图49详细示出了系统在产生可下载指令时所执行的过程。在步骤701中，从页文件提取出各个变量，并构筑成一个代表该服务的结构。页文件中包含了一个系统总体文件和一个服务总体文件。系统总体文件指明一些对整个服务公用的参数，而服务总体文件以各个页的排列来指明该服务的结构。然后，通过对每一个页加入各自的文件、定义该页中的各个模块、以及定义这些模块的连接方式，来完全地定义一个服务的说明。

在步骤702中，处理页文件以产生可下载的指令这些指令最好具有可与C⁺⁺编程语言相兼容的形式。这些指令将对每一个页包括一个子程序和一个定义了有限数目的可能状态(即有限态机器)的控制程序。在步骤703中，产生一个代表可下载指令的人类可读的指令，使得操作人员在线操作地能够跟随系统的进程。

为了符合C⁺⁺的要求，有必要在C⁺⁺指令(一个功能)的开始区进行变量说明，这些变量将在这些指令中应用。因此，产生C⁺⁺程序的第一步是确定剧本文件中存在有哪些变量，并根据变量所在的上下文来确定它们的类型(整数或数串等等)。

图50详细示出了图49的步骤701中所指明的提取变量的过程。在步712中，通过对有关的剧本关键词，例如“arg”、“pre-do”等进行搜索，确定各个变量，由此使得各变量的类型可以根据其上下文来确定。当确定某些变量不能定类时，便报告这个结果。

在步骤713中，通过分析提供给一个页的变量，对确定变量类型作进一步的衡量。为了容易确定每一个变量的类型，产生一些“same type as”(“相同类型”)清单，使得当确定了清单内多个变量中的一个变量的类型时，便能确定该清单中所有变量的类型。

如果有变量不能够定类型，便在步骤步骤714中把它们显示出来，由此操作员可以提供所需的信息，或者向服务生成者寻找答案。

图51详细示出了步骤702所指明的对每一个页处理页文件的过程。对服务的每一个页都存在有一个独立的页文件，对C⁺⁺代码也是这样。产生一个C⁺⁺主程序，它设计来调用每一个页的子程序，由此把各个页文件连接在一起，并定义出它们的次序。于是，在步骤721中，打开下一个页文件，并产生一个相应的C⁺⁺输出文件。

在步骤722中，把剧本文件的说明转变成C⁺⁺说明，直到确定出页名称。在步骤723中，把该页所用的总体变量拷贝到C⁺⁺文件中。在步骤724中，确定该页在服务等级层次中的位置，拷贝传递给页文件的变量，并把当地变量传递给C⁺⁺文件。

在步骤725中，把该页翻译成C⁺⁺，直到发现页终结的标志。翻译开始阶段是确定该页内的每一个模块，并调用各自相应的翻译子程序来翻译各个模块。

当各个模块都翻译完之后，在步骤726中把页功能标准写入到C⁺⁺文件中。在步骤727中写入控制逻辑，该控制逻辑控制在页内调用模块子程序，并为该页有效地定义一个有限态机器。

在步骤728中使各变量复原，在步骤729中，询问是否还有需要处理的页。如果答案是肯定的，则控制返回到步骤721，然后处理文本文件的下一页。最后，所有文本文件的各个页都将被处理过，从而对步骤729询问的答案将否定的。当得到这种答案的后，控制被导向步骤730，在其中根据构成整个服务的各个页的等级来生产主调用指令。

当以这种形式完成之后，该服务即被一些C⁺⁺文件所定义。这些C⁺⁺文件是操作人员可读的，还可以制作出涉及到这些文件的详细编码的文件编集。然后把这些C⁺⁺文件下载给一个服务提供者，该该服务提供者应具有能把C⁺⁺文件编译成一个特定语言请求平台所能执行的代码的设施。文件编集可以给出一些关于各种细小变动的细节，为了使该C⁺⁺代码适合于在一个特定的操作系统或平台环境下编译，有可能会需要这些细节。而且，C⁺⁺是一种普及的编程语言，以这种形式所提供的软件还可以被具有必要的编程技术的服务供者来进行一些有用的修改，以给出附加的功能或者另外的功能。

Claims (45)

1.一种为请求平台产生可下载指令的方法，其中多个与参数有关的操作被连接起来，以定义一个受逻辑控制的请求，该方法的特征在于以下步骤：

用图形代表各功能模块；

用图形代表上述各功能模块之间的连接，这又指定了在该请求的操作过程中上述各模块之间的逻辑流程；

测试上述各模块之间的上述连接的连接正确性，由此测试上述逻辑流程的正确性；以及

在通过上述正确性测试后输入指定模块功能的操作参数。

2.根据权利要求1的方法，其中上述请求平台是一个语言请求评台，并且上述可下载指令是用高级语言的形式来表示的。

3.根据权利要求1的方法，其中上述测试上述连接的正确性的步骤包括检查是否有遗漏的连接。

4.根据权利要求1的方法，其中上述测试上述连接的正确性的步骤包括检查是否有重复连接。

5.根据权利要求1的方法，其中上述测试上述连接的正确性的步骤包括检查是否有没有没有输入连接的模块。

6.一种产生可下载到一个语言请求平台的指令的方法，其特征在于以下步骤：

用图形代表各功能模块；

用图形代表上述各模块间的连接，以定义一个服务结构；以及

测试上述连接的正确性，以检查是否有模块间的遗漏的连接、模块间的重复连接、和没有输入连接的模块。

7.根据权利要求6的方法，其中上述可下载指令以C或C⁺⁺指令产生。

8.根据权利要求6的方法，其中对模块的操作参数的输入在上述正确性测试之后进行。

9.一种定义一个语言请求的方法，其特征在于以下步骤：

用图形代表各功能模块和上述各模块间的连接；

产生定义上述语言请求的功能的剧本文件；以及

通过逐行翻译上述剧本文件来进行上述请求的模拟操作。

10.根据权利要求9的方法，其中对每一个上述模块产生一个文本文件，并且上述剧本文件是通过结合上述文本文件中的各指令行来产生的。

11.根据权利要求10的方法，它包括以下步骤：在表示出各功能模块和它们间的连接之后进行正确性测试，在正确性测试成功之后输入操作参数，以及在对一个模块输入参数之后对该模块产生一个文本文件。

12.一种模拟一个语言请求的方法，其特征在于：

翻译代表上述请求的剧本文件；

把来自一个设想的呼叫人的语音提供给一个操作人员；

从上述操作人员接收识别数据；以及

在上述识别数据中引进一些错误。

13.根据权利要求12的方法，其中上述错误被引进到预定百分比的上述识别数据中。

14.根据权利要求12的方法，其中被引进错误的概率是从在实际语言请求平台上发生这样一个错误的概率导出的。

15.根据权利要求14的方法，其中各错误是通过参照一个确认矩阵来引进的。

16.一种在语言请求平台上模拟一个语言请求的方法，其特征为：

翻译代表上述请求的剧本文件；以及

执行自动语言识别，其中语言识别样板是借助一个子字单元的字集来构筑的。

17.一种模拟一个语言请求的方法，其中上述请求由各功能模块的图形表示之间的逻辑连接来定义，其特征在于：

对每个上述模块产生一个文本文件；

通过结合文本文件的数据产生一个定义该请求的剧本文件；以及

通过翻译上述剧本文件实现模拟。

18.根据权利要求17的方法，它包括：向操作人员提供来自一个设想呼叫人的语音；从上述操作人员接收识别数据；以及，在上述识别数据中引进错误。

19.根据权利要求17的方法，它包括以下步骤：翻译代表上述请求的剧本文件；以及执行自动语言识别，其中语言识别样板根据一些子字单元的字表来构筑。

20.根据权利要求17的方法，它包括下述步骤：测试各功能模块间的连接的连接正确性，以测试上述各模块间的逻辑流程的正确性。

21.一种产生可下载到一个语言请求平台的指令的方法，其特征在于以下步骤：

用图形代表一个语言请求；

上述图形代表包含用来接收可直接兼容的代码的手段；以及

把上述可直接兼容的代码植入到从上述图形代表导出的文本中。

22.根据权利要求21的方法，其中上述可直接兼容的代码是C或C⁺⁺。

23.根据权利要求21的方法，其中上述图形代表通过布置各功能模块和上述各模块间的逻辑连接来定义，并产生一个文本文件来代表一个模块的功能。

24.根据权利要求23的方法，其中上述可直接兼容的代码是可以植入到每个上述被布置的功能模块中的。

25.根据权利要求23的方法，其中剧本文件是从多个上述文本文件产生的。

26.根据权利要求25的方法，其中的模拟通过翻译上述剧本文件来实现。

27.根据权利要求21的方法，它包括下述步骤：从上述文本导出可下载代码，其中被下载的代码和上述被植入的可兼容代码一起编译。

28.一种为语言请求平台产生指令的方法，其特征在于：

一个请求用各功能模块和上述模块间的逻辑流程来定义；

至少一个上述模块含有调用外部例行程序的功能；以及

可执行的指令是从上述所定义的请求产生的，使得上述例行程序可被上述可执行的指令调用。

29.根据权利要求28的方法，其中上述外部例行程序访问一个外部数据库。

30.根据权利要求29的方法，其中的变量是可以向所调用的外部例行程序提供的，并且数据可以从上述被调用的例行程序返回。

31.一种产生可下载到一个语言请求平台并在那里编译的指令的方法，其特征在于：

用图形代表一个作为按逻辑连接在一起的一些功能模块的请求；

测试上述各模块间的上述连接的连接正确性；

对每个上述模块产生一个文本文件；

从上述文本文件产生一个剧本文件；以及

从上述剧本文件产生可下载的指令。

32.根据权利要求31的方法，其中可下载的指令是C或C⁺⁺指令。

33.根据权利要求31的方法，其中上述请求基本上通过翻译上述剧本文件来模拟。

34.用于为请求平台产生可下载指令的设备，其中多个与参数有关的操作被连接起来；以定义一个受逻辑控制的请求，其特征在于：

设计成用图形代表功能模块和上述模块间的连接的图形显示装置，这种连接又指定在操作该请求时上述各模块间的逻辑流程；

设计来测试上述各模块间的上述连接的连接正确性，由此测试上述逻辑流程的正确性，并在通过了上述正确性测试之后接收指明模块功能的操作参数的处理装置。

35.根据权利要求34的设备，其中上述请求平台是一个语言请求平台，并且可下载指令是以高级语言来表示的。

36.用来产生可下载到一个语言请求平台的指令的设备，其特征在于：

用来代表各功能模块和上述各模块间的连接，以定义一个服务结构的图形装置；以及

设计来测试上述连接的正确性以检查是否有各模块间连接的遗漏、各模块间的重复连接和没有输入连接的模块的处理装置。

37.用来定义一个语言请求的设备，其特征在于：

设计来代表各功能模块和上述各模块间的连接的图形装置；

设计来产生定义上述语言请求的功能的剧本文件的处理装置；以及

设计来通过逐行翻译上述剧本文件来模拟上述请求的操作的处理装置。

38.根据权利要求37的设备，其中上述第一个处理装置对每个上述模块产生一个文本文件，并且上述剧本文件是通过结合上述文本文件的指令的各个行来产生的。

39.用来模拟一个语言请求的设备，其特征在于：

用来翻译代表上述请求的剧本文件的处理装置；

用来向操作人员提供来自一个设想呼叫人的语音的通信装置；以及

用来从上述操作人员接收识别数据并将一些错误引进上述识别数据的处理装置。

40.一种语言请求平台，其特征在于：

设计来翻译代表一个请求的剧本文件的处理装置；以及

用来存储子字单元的字组的装置，其中用于上述语言请求的语言识别样板是根据上述一些子字单元来构筑的。

41.用来模拟一个语言请求的设备，其中上述请求由各功能模块的图形表示之间的逻辑连接来定义，其特征在于用来为每一个上述模块产生一个文本文件、通过结合文本文件数据产生一个定义该请求的剧本文件、以及通过翻译上述剧本文件实现模拟的处理装置。

42.用来产生可下载到语言请求平台的指令的设备，其特征在于：

用来代表一个语言请求的图形装置，包括用来接收可直接兼容代码的装置；以及

设计来把上述可直接兼容代码植入到从上述图形表示导出的文本中的处理装置。

43.用来为语言请求平台产生指令的装置，其特征在于：

用来以各个功能模块和上述各模块间的逻辑流程来定义一个请求的装置，其中至少一个上述模块含有向外部例行程序的调用功能；以及

处理上述所定义的请求以产生可执行的指令，使得上述例行程序可以被上述可执行的指令所调用的装置。

44.用来产生可下载到一个语言请求平台并在那里编译的指令的设备，其特征在于：

用来以图形把一个请求表示成一些按逻辑连接的功能模块的图形装置，以及

设计来测试上述各模块间的上述连接的连接正确性，为每一个上述模块产生一个文本文件，从上述文本文件产生一个剧本文件，以及从上述剧本文件产生可下载指令的处理装置。

45.根据权利要求44的设备，它含有用来通过翻译上述剧本文件对一个请求进行模拟操作的装置。

Images