CN101263459A

CN101263459A - 图形xml编程系统和引擎

Info

Publication number: CN101263459A
Application number: CNA2005800407661A
Authority: CN
Inventors: M·D·马丁; G·P·勒布勒
Original assignee: Brixlogic Inc
Current assignee: Brixlogic Inc
Priority date: 2004-10-01
Filing date: 2005-09-30
Publication date: 2008-09-10

Abstract

提供一种系统和方法，用以用图解方式运行和构造XML处理程序、在程序开发时引导用户、在设计程序时防止和检测开发错误、保证程序是有效的。该系统包括一个图形XML编程系统，其中以图形方式构建和描绘XML处理程序，提供引导编程、防止和检测错误和分析改变的影响和对改变进行管理的可视程序中每一个选定执行点用的实时元数据计算和可视化方法，和自动化的执行路径探测方法，它启动总体的程序确认和错误识别。

Description

图形XML编程系统和引擎

相关申请

本申请要求2004年10月1日提交的美国临时申请No.60/615172的优先权。

背景技术

国家标准和技术协会(“NIST”)在2002年发布一份报告，指出软件错误每年消耗美国经济595亿美元。随着“环球网业务(WebService)”，亦即接收XML消息、对其进行处理和返回XML消息的软件，也可以称为(活动业务、实体业务、处理业务、企业业务等)迅速变为实际的标准软件组件模型，并将由成千上万建立，这项开销的一个急剧上涨的部分将涉及环球网业务和XML处理软件。该NIST研究发现，这项开销的三分之一以上可以通过改善测试，能够较早地和更有效地识别和去除缺陷而加以消除。但是，要能够做到这一点，就要求一个全新的方法，使用不同的编程技术和语言。环球网业务的大规模开展要求一种在开发时就保证环球网业务正确性并能够对那些业务的改变进行自动化管理的技术。

今天，应用程序开发用的开发范式是面向对象的，而不是为建立这种无数称为环球网业务的在结构上定义为XML实体的小应用程序而设计来的。目前该产业将其面向对象的语言应用于环球网业务。这是不相匹配的。

诸如Java或.NET C#等语言是面向对象的。对象包含数据和方法。该对象的行为作为方法编码在该对象内。在一个对象内表达的约束水平，就数据而言是简单的，但就方法而言却可能是极其复杂的。在某种程度上，这是因为Java和.NET C#是满足一般需要的一般语言，而不是针对所有需要的。

MS VS[Microsoft Visual Studio]和Eclipse两个都提供“Intellisense”或“类似于Intellisense”的特征，来帮助开发者用面向对象的语言进行工作。例如，若开发者键入“custlnfo.”，而且若custlnfo是一个Customerlnfo类型的对象，则这两个环境都显示弹出式菜单，列出Customerlnfo类的字段和方法。这种类型查阅是基于静态类型，而最后只不过是一个字典查阅算法而已。

MS VS和Eclipse(利用相关的编译器，例如，Javac)还提供开发者从这样的工作室(studio)预计的最小检查(语法分析错误，报警，…)。这种检查可以在编译时或背景下完成，视所使用的产品和机器速度而定。

但是，MS VS和Eclipse没有能力验证一个程序在逻辑上有效、它遵循各种约束以及它不会有运行时错误。其结果是，一个程序的质量完全取决于人的因素，这意味着程序在很大程度上是不可靠的。例如，开发者不得不检查空引用、没有利用的变量、输入参数的正确性及其他致命错误。对于所有这些方面和许多其他方面，该程序的质量有赖于该开发者的质量和经验，而且失察是极其频繁发生的。换句话说，采用基于对象的语言，在设计时无法知道一个程序将不会产生不受控制的例外和/或由于运行时错误而崩溃。

因而，采用面向对象的语言时必须解决以下问题：

-在编写代码的同时编写测试代码(极端编程)。

-遵循良好的QA过程，以测试该程序。

-有效地使用调试工具。

-使用良好的技术和用户服务来对付在QA阶段过程中没有检测出来的问题。

作为示例性例子，考察一个环球网业务的开发，它处理遵循IFX1.4.0规格(BalInqRq消息)的账户平衡查询请求，并返回一个账户平衡查询响应(BalInqRs)。该BalInqRq和BalInqRs是基于XML的消息并在形式上在IFX 1.4.0 XML Schema中定义。该Schema的片段如下：

<xsd:element name＝″BalInqRq″type＝″BalInqRq_Type″>

</xsd:element>

<xsd:complexType name＝″BalInqRq_Type″>

<xsd:sequence>

<xsd:element ref＝″RqUID″/>

<xsd:element ref＝″MsgRqHdr″minOccurs＝″0″/>

<xsd:element ref＝″AsyncRqUID″minOccurs＝″0″/>

<xsd:element ref＝″CustId″minOccurs＝″0″/>

<xsd:choice>

<xsd:element ref＝″DepAcctId″/>

<xsd:element ref＝″CardAcctId″/>

<xsd:element ref＝″LoanAcctId″/>

</xsd:choice>

<xsd:element ref＝″IncExtBal″minOccurs＝″0″/>

<xsd:element ref＝″DellveryMethod″minOccurs＝″0″/>

</xsd:sequence>

</xsd:complexType>

这意味着，任何BaJInqRq消息都将以BalInqRq标签开始，它将包含：

-强制性的RqUED元素，

-任选的MsgRqHdr元素(2个可能的案例)，

-任选的AsyncRqUDD元素(2个可能的案例)，

-任选的CustId元素(2个可能的案例)，

-然后是DepAcctId元素或CardAcctId元素或LoanAcctId，但不同时是任何两个(3个可能的案例)，

-和然后是任选的IncExtBal元素(2个可能的案例)，

-和最后是任选的DeliveryMethod元素(2个可能的案例)。

给定该接口的定义，而且甚至不涉及元素出现时特定的值，或不表示像CardAcctId这样的元素本身可能包含任选的元素、选择等的定义，在理论上我们就已经要求2×2×2×3×2×2＝96个测试案例来覆盖不同的可能性。

这是一个有效的BalInqRq的一个示例：

<Addr1>93Dalma Drive</Addr1>

<City>Mountain View</City>

</PostAddr>

</NetworkTmInfo>

</MsgAuthCode>

</MsgRqHdr>

</CardMagData>

</CardAcctId>

</BalInqRq>

采用这一个示例，测试其中有MsgRqHdr、CardAcctId，但是没有AsyncRqUID、CustId、IncExtBal或DeliveryMethod的案例。在理论上，开发者会需要95个以上的测试案例。

另外，因为环球网业务不只是由输入的XML Schema片段定义的，而且是由输出XML Schema片段定义的，所以还必须测试所得到的任何XML输出是否遵循输出XML Schema片段。

当测试案例产生运行时错误或产生不遵循该XML Schema的XML输出时，该程序都必须修改。任何这样的修改都可能造成新的问题。

之所以采用这种费时的方法，主要的原因是像Java，C或C#等这样的语言不能够在编译时根据符合该XML Schema规格的类型系统完成静态类型检查。例如，在一个处理上面的XML Schema示例的XML实例的Java程序中，尽管CardAcctId和LoanAcctId是互斥标记，但在技术上无法防止开发者做出诸如试图拷贝CardAcctId的内容等错误，尽管LoanAcctId已经测试正确。

因此，需要这样一种系统和方法：它们用来防止开发者犯这样的错误、检测改变该程序时造成的错误和保证整个程序的正确性，而又不依赖基于案例的广泛测试。正如将要看出的，本发明以一种优雅的方式启动这样的一个系统和方法。

发明内容

这些挑战可以用这里描述的方法和系统加以避免。这些方法和系统是面向文档的，而不是面向对象的。

面向文档的环球网业务是指其方法是隐含地假定的并且不是在该XML Schema中表达的环球网业务。例如，诸如IFX、ACORD或OTA等产业标准Schema的目的是用一组通过典型请求/响应交换而交换的丰富的约束来表达复杂的数据结构。

面向文档的环球网业务与RPC风格的环球网业务形成对照，在后一种情况下XML仅仅用来表达方法和它们的参数，一般利用映射到存在于所使用的语言(例如Java或C#)中的数据类型的简单的XML类型。

正如今天，Java或C#用的开发环境提供诸如Microsoft XSD.EXE等允许开发者从来自XML Schema的一个或多个类建立XML Schema的工具。这些工具用在RPC-风格的环球网业务还行，用在面向文档的环球网业务就不幸地失败了，因为在该XML Schema中表达的大部分约束在XML片断和对象之间来回转换的过程中在翻译中丢失了。

通过采用面向文档的环球网业务方法，XML的作用要翻转过来(和XML使用的基于PRC的方法对比)，而且最后变成它原来设想的作用。不是仅仅利用XML作为两个面向对象的作为环球网业务交换(RPC)的一部分的端点之间的数据参数传输，这里描述的系统和方法由基于过程的语言构成，它在XML Schema上执行，而且受制于这些Schema中所表达的所有约束。因而该XML Schema变成环球网业务交换的中央智能。该中央智能是由这里描述的系统和方法表达和强制实行的。

采用这里描述的方法和系统，设计环球网业务的过程就根本不同了。首先，正如前面指出的，该语言受限于项目所用的Schema。例如，若一个序列元素可以包含0至5个元素，这里描述的方法和系统将自动地强制实施该约束。利用Java或.NET C#，开发者必须明确地编写代码来强制实施和检查该数据的这样一个特性。

其次，诸如Java和.NET C#等一般语言内的类型检查是动态的，而不是静态的。采用诸如Java或C#等语言，要保证所产生的XML消息对于XML Schema内定义的XML类型是正确的，唯一的途径是使用一个验证分析器。验证分析器是一个程序，它采取XML文档和XML Schema作为输入。一旦一个样本XML文档可用，验证分析器便只可以在运行时被调用。这种仅在运行时才进行的类型检查称为动态类型检查。这里描述的系统和方法在设计时完成静态类型检查，保证该XML数据，不论输入还是输出，都与该环球网业务使用的XMLSchema片段所表达的约束一致，而不论在输入的接收和输出的发送之间所执行的操作的数目和类型。尽管对于Java或C#的类(对象)确实也有静态类型检查可用，但是它对XML类型(XML Schema片段)是不可用的。采用这里描述的系统和方法，开发者隐含地受到限制，要尊重Schema中表达的约束并与之一致。采用Java、C#或其它一般的语言时，开发者不得不明确地编写定制代码，以便达到同一结果。因此，这里描述的系统和方法提供不仅100％保证环球网业务就输入和输出而言没有接口错误，而且大大加速环球网业务根据复杂XML Schema的建立。

第三，与其中可能性的范围“无穷”的一般语言相反，这里描述的系统和方法提供一种专用语言和环境，它允许自动探测一个程序所有的执行路径。

用这样的方法：

-类型是推算出来，而不是声明的。

-类型层次结构(子分类)是基于该类型的描述，而不是它的名字。换句话说，我们知道，类型<a>String[0..1]</a>是<a>String[1]</a>的子类型，不是因为它具有相同的名字，而是因为第一个是第二个的子案例。利用数学集合，我们会说，String[0..1]的任何实例都是String[1]的子集(因为空集和String[1]集合都包括在该String[1]集合中)。

-类型是作为约束集合，而不是作为名字定义的。这样便有可能捕捉与给定变量可以保存的值的类型有关的许多更多的信息。

-类型是指XML类型，而不是对象类型(类)。

因而，采用这里描述的系统和方法，开发者在设计时便知道，她或他的程序在运行时不会失效或崩溃，因为该工作室(这里描述的系统和方法的GUI应用程序部分)在设计过程中就已经进行了完整的执行路径分析，并帮助开发者在设计时修正错误。大部分设计错误甚至在环球网业务首次运行以前就已经排除了。

附图说明

图1是一个流程图，举例说明XML处理程序的可视描绘和编辑，它提供XML类型推理以避免编程错误，以便检测错误，并按照它们预期的XML输出类型来验证程序。

图2举例说明XML处理程序在一个给定的执行点上XML类型推理用的流程图；

图3举例说明根据XML类型推理检测XML处理程序中的指令配置错误用的流程图；

图4举例说明XML类型作为标识节点树的描绘；

图5举例说明XML子分类算法用的流程图；

图6举例说明基于XML确认的处理程序用的流程图；

图7举例说明本发明的系统和方法的输出消息；而

图8举例说明元数据检查器的输出。

具体实施方式

本发明广泛利用可从诸如环球网业务等处理程序的接口定义获得的元数据，在开发处理逻辑的同时防止和检测许多错误。它还无论何时无论由于何种原因(内部逻辑、在该环球网业务使用的任何数据源或在支持该环球网业务的Schema中的改变)在该环球网业务作出任何修改，而使改变管理自动化。这里描述的系统和方法在开发时通过在每一个执行路径上和在该处理逻辑的每一个执行点上，动态地计算所消耗和产生消息的元数据来做到这一点。

相应地，系统和方法是为建立和保持可视XML编程环境而设置的，其中该程序的XML处理逻辑是自动地计算和用图解方式可视化的，而且其中实时针对该程序中的每一个执行点计算在运行时处理的XML实例的元数据，以便提供引导编程、错误防止、错误检测和程序确认。该系统和方法使所配置的系统能够通过动态执行路径分析来降低消息处理应用的开发和维护成本。

这里描述的方法和系统是面向文档的。Schema包含包括非常丰富的约束集合的数据结构(与对象相比)。基于我们的发明的环球网业务的行为驻留在基于过程语言的其将方法和系统放置在Schema上的语言中。因此，该语言受Schema约束，相比之下，Java和.NET C#语言几乎不受约束而，而在环球网业务的句法和语义确认方面根本就没有约束。

采用这里描述的方法和系统，设计环球网业务的过程就根本不同了。首先，正如前面指出的，该语言受项目所用的Schema约束。例如，若一个序列元素可以包含0至5个元素，则这里描述的方法和系统自动地强制实施该约束。采用Java或.NET C#时开发者必须明确地编写代码进行约束并检查该特征。其次，正如这里描述的，类型检查是动态的，而不是静态的。

采用诸如Java或C#等语言，要保证所产生的XML消息对于XMLSchema内定义的XML类型是正确的，唯一的途径是使用验证分析器。验证分析器是一个程序，它以XML文档和XML Schema作为输入。一旦样本XML文档可用，验证分析器便只可以在运行时被调用。这种类型的仅在运行时才进行的类型检查称为动态类型检查。这里描述的系统和方法在设计时完成动态类型检查，保证该XML数据，不论输入还是输出，都与该环球网业务所使用的XML Schema片段所表达的约束一致，而不论在输入的接收和输出的发送之间将执行的操作的数目和类型。当然，采用Java或C#对于类(对象)也有静态类型检查可用，但不是针对XML类型(XML Schema片段)。采用这里描述的系统和方法，开发者隐含地受到约束，要尊重该Schema中所表达的限制，并与之一致。采用Java，C#或其它一般的语言，开发者不得不明确地编写定制代码，以便达到同一结果。因此，这里描述的系统和方法不仅提供一个100％的保证，就输入和输出而言该环球网业务没有接口错误，而且大大加速基于复杂的XML Schema的环球网业务的建立。

第三，与其中可能性的范围固有地是无限的一般的语言相反，这里描述的方法和系统已经设计一种专用语言和环境，它允许自动探测一个程序的所有执行路径。

正如这里描述的：

-类型是推算出来的，而不是声明的。

-类型层次结构(子分类)是基于该类型的描述，而不是它的名字。换句话说，我们知道，类型<a>String[0..1]</a>是<a>String[1]</a>的子类型，不是因为它们具有同一名字，而是因为第一个是该第二个的子案例。利用数学集合，我们会说，String[0..1]的任何实例都是String[1]的子集(因为空集和String[1]集合两个都包括在String[1]集合中)。

-类型是作为约束集合而不是作为名字定义的。这样便可能捕捉有关给定变量可以保持的值的类型的许多更多信息。

-类型是指XML类型，而不是对象类型(类)。

因而，采用这里描述的系统和方法，开发者在设计时便知道，她或他的程序在运行时不会失效或崩溃，因为该工作室(这里描述的系统和方法的GUI应用程序部分)在设计过程中就已经进行了完整的执行路径分析，并帮助开发者在设计时修正错误。甚至在该环球网业务首次运行以前，大部分设计错误就已经排除了。

在操作上，该输入和输出的元数据是用一个标准化的语言定义的。该系统能够在开发过程中进行动态的执行路径分析，帮助开发者知道该开发中的程序的实时表现。在开发过程中，该系统计算场景处理逻辑的每一个执行路径上更新的输入和输出元数据，并防止用户产生错误。在每一个阶段，从操作开始，在输入以及输出上分析该元数据的状态。

例如，该系统可以防止开发者试图操作或拷贝一个在特定的执行路径上运行时不可用的元素。本发明提供一个举例说明该输出元数据的用户界面。若被高亮度显示，则该给定的执行路径和执行点可以被认为是存在的。这在防止错误上是特别有用的，其中用户能够针对每一个执行路径准确地使输入和输出的构造状态可视化，并确定是否满足预定的约束。该操作向开发者提供一个能引导编程、错误防止、错误检测和程序确认的系统。

图1是一个流程图，举例说明一个XML处理程序的可视描绘和编辑，它提供XML类型推理，以便按照它们的预期XML输出类型，来避免编程错误、来检测错误和验证程序。该过程在“开始”101处以“操作1”103开始，进到“操作2”105处的判定点，持续到“操作3”107，在“结束”109处结束处理。

图2举例说明XML处理程序的一个给定执行点上进行XML类型推理用的流程图。该过程在“开始”201处开始，第一步骤是在该XML处理程序的可视描绘中选择一个执行点203、205。这是通过在两个指令之间的点上选择一条指令完成的。确定由一条指令清单构成的执行路径。该执行路径在该XML处理程序的可视描绘中是高亮度显示的207。

在下两个框中，把该程序的输入的XML类型传送到与该执行路径中的第一条指令相联系的类型推理子程序209，而与第一操作相关的类型推理子程序根据指令的配置计算所得的XML类型211。若所选定的执行点已经达到213，则显示215算出的XML类型，而且该程序结束217。否则，把先前计算的XML类型传送到该执行路径中的下一条指令，而与下一条指令相联系的类型推理子程序219计算所得的XML类型221。若因为该操作所要求的XML类型在该输入XML 223中不存在而计算失败，则确定225一个错误。否则，控制退回227。

若所选定的执行点尚未达到，则把XML类型传送到下一条指令，并且该类型推理子程序计算所得的XML类型。

图3举例说明一个流程图，用以根据XML类型推理，检测XML处理程序中指令配置的错误。该流程图举例说明用户修改源程序301的情况，识别受修改影响的执行路径303，并推算出所得的XML类型305。若全部执行点均已处理307，而且没有错误309，则程序退出311。否则，继续执行，直到确定321该计算点为止。若有计算错误323，则高亮度显示出现错误的指令，显示计算错误325，而且程序退出327。

图4举例说明XML类型作为标识的节点树的XML类型描绘，例如，根元素401、子元素411和413，由基本类型发生约束、枚举及其他类型的信息而限定。表示子元素413还产生子元素421、423和425。

图5举例说明XML子分类算法用的流程图。如图5所示，该过程以XML类型的描绘1和XML类型描绘2开始501，其中代表类型1和2的节点树中的第一节点被选定503。该节点测试兼容性505，而若不兼容，则程序退出511。若该节点是兼容的，而且所有节点均已处理509，则该程序结束513。若尚未处理全部节点，则处理513下一个节点，并测试该节点的兼容性515。控制返回，以便返回至该节点是否最后的节点的判定519。

图6举例说明基于XML确认的处理程序用的流程图。处理以用户触发确认601开始，识别603该XML处理程序中的所有可能的路径。针对第一执行路径605推算所得的XML类型。

若推算出来的XML类型不是预期的XML类型607的一个子类型，则识别和显示609产生出错消息的XML类型的部分。否则，没有确认错误，而且所有执行路径均已处理611，该程序被认为没有确认错误613。

若尚未处理611所有执行路径，则针对下一个执行点推算所得的XML类型615。若该推算出来的XML类型是该预期的XML类型617的一个子类型，则对下一个节点进行类型检查。否则，检测并显示619产生该子分类错误的XML类型部分。

本发明的另一个实施例提供计算机编程系统，它包括编程语言和它的作为图形流程图的交互式可视描绘。与该程序特定执行路径和点对应的图形边缘可以按可视方式选定来加入新的处理节点，或在给定路径的给定点上显示该程序变量的元数据。该系统包括一个元数据计算模块，配置成在给定该语言程序、该程序的输入和输出的元数据和该程序中执行路径和点时，计算在程序的任何给定点和路径上可用的和/或预期的变量的元数据，从而启用引导开发。该系统还包括一组配置面板，用以处理节点的每一个可能的类型。该面板利用算出的元数据和它在其中增加节点的执行点处的可视描绘，以便启动该处理节点的指向和点击配置，并防止用户把不存在的或其类型与处理节点的参数类型不兼容的变量选择为处理节点的参数，从而防止错误。

该系统还包括处理节点配置错误可视通知模块。操作时，若处理节点的配置是或变得不正确，该模块使处理节点能够立即以可视方式高亮度显示。这可能是因为它的参数使用不存在的变量，或者在给定的执行路径上没有要求的类型，因而，在该程序设计时启动错误检测。该系统还包括一个程序确认模块，它探测所有的执行路径，针对每一个可能的执行路径计算所得的元数据，并验证它是否与程序的输出的元数据一致，若非如此，则通过一个发现错误的执行路径和点清单来通知用户，因而，启动整个程序的确认并加速问题查找。

XML的优点之一是它使标准化的语言能够用于元数据：XMLSchema。大部分XML数据交换规格在该语言(甚至WSDL，环球网业务接口描述语言也是基于该语言)中是或将是可用的。

在一个按照本发明的系统配置中，开发任何XML处理逻辑以前的第一步骤是要定义该程序输入的元数据和该输出的元数据，在技术专门术语中称为场景。输入和输出的定义是通过以可视方式从以前装入的XML Schema或WSDL中选择一个节点来完成的。在我们的示例中，我们装入IFX1.4.0XML Schema和用指向与点击接口配置我们的处理场景所消耗的输入消息和所产生的输出消息，如图7所示。

完成配置之后，该系统产生如图8所示的描绘，表示一个元数据检查器(Metadata Inspector)的描绘。

首先，这无疑是一个比以前显示的原XML Schema可读得多的版本。我们实际上取得甚至更多的信息：我们现在知道，元素RqUID是UUID类型，CardAcctId实际上是一个复杂的元素，可能包含AcctId或CardMagData元素等。

我们可以发现的是，该场景具有一个起点、一个终点、一个执行路径和在该执行路径上的一个执行点。该执行路径实际上是深蓝色的，意味着它已经被用户选定，而我们已经显示的输入元数据实际上是该特定的执行路径和点上输入的元数据的状态。我们还可以考察该特定的执行路径中输出的元数据的状态：

该元数据可着以对比颜色或色调。这表明，这是所产生的消息的预期的元数据，然而在该输入的情况下，它是所收到的消息的实际的元数据。

在一个按照本发明配置的系统中，XML处理程序，亦称“场景”，是通过向一个执行点加入处理操作而设计的。

通过实施例和例证，我们准备向我们的场景加入3个简单的操作，并看到在不同的执行路径上在元数据上造成的后果：

●在该输出中建立BalInqRs元素的操作。

●测试该MsgRqHdr元素是否存在于该BalInqRq请求消息的操作，若是如此，则把MsgRqHdr的内容拷贝到输出。

●根据AcctId(Card，Dep或Loan)的什么类型用在该MsgRqHdr中进行切换的操作。

这样的一个场景中，我们可以看到，我们现在有六个执行路径(两个带有存在/不存在开关和三个处于该Id/CardAcctId/LoanAcctId开关中)和八个执行点。对于每一个执行点，都有可能使该元数据可视化。

按照本发明，用三个可以配置的不同颜色来区分未被选择的执行路径(例如，浅灰色)、被选定的执行路径(例如，蓝色)和该执行路径内的执行点(例如，深蓝色)。

看该箭头，我们可以看到，我们还已经选定主要的执行路径，但是在该路径内，我们已经选定观看在该输出中建立该BalInqRs元素的“建立BalInqRq”操作之后元数据的状态。图6表示此操作之后输出的元数据的状态：

我们可以看到，在该输出元数据中，该BalInqRs元素已经改变颜色，这意味着，对于这个给定的执行路径和执行点，用户可以认为它在“那里”。这是特别有用的，因为用户能够准确地对该输出构造中他所处的每一个执行路径进行可视化，并看到该约束是否得到满足。在帮助用户避免错误方面，这是强有力的。

防止错误

若我们选择“MsgRqHdr是否存在”操作的“存在”分支，则我们可以看到，该MsgRqHdr元素的实际基数已经从[0..1](亦即，存在或不存在)变为[1](存在)。若我们选择“MsgRqHdr是否存在”操作的“不存在”分支，则我们看到，我们在该输入元数据中再无法看到MsgRqHdr元素。好了，这可能是预期的，因为我们只宣称它不存在。

通过在该场景处理逻辑的每一个执行路径上和点上计算更新后的输入和输出元数据，本发明防止用户产生诸如尝试操作或拷贝一个运行时在一个特定的执行路径上将是不可用的元素的错误。

类似地，我们可以看到，在“开关”操作的每一个分支上，选择图标已经消失，而只有相关的AcctId类型可用：

按照本发明，诸如，例如，拷贝、移动、数学表达及其他操作等的配置，是利用在增加该操作的执行点上所算出的元数据配置的。

例如，若用户想要在一个特定的执行点上加上一个拷贝操作，他首先要右点击该执行点，然后选择要加上的操作(例如拷贝操作)。

然后配置面板弹出。所有配置面板都是专用于该操作功能的，但是它们全都利用所算出的指向和点击配置用的元数据。例如，对于拷贝操作，用户可以在该操作配置面板(见下图)的“原点”标签下面选择拷贝什么，并在配置面板的“目的地”标签下面选择把它拷贝到哪里去，只需指向和点击即可。

这使用户基本上不可能由于搞错而选择运行时不在“那里”的元素。在这种情况下，用户不能够拷贝CartAcctId或LoanAcctId)。这是一个减少潜错误的风险和相关的所要求测试的强有力的途径。这里是一个我们要在该CardAcctId分支上加上一个操作的配置面板的示例，正如你可以看到的，不可能用类似于运行时可能不在那里的CardAcctId或DepAcctId的元素来配置该“原点”(亦即，拷贝什么)。

通过自动化错误检测进行改变管理

在它的整个开发环境中实时计算的元数据的许多其它优点之一是，在对XML处理逻辑、环球网业务定义或所访问的资源的定义作出改变时检测错误的能力。

考察我们改变我们的示例场景来支持另一个IFX版本的示例场景，例如IFX1.3.0XML Schema的情况。我们可能迅速地改变场景的配置来使用IFX 1.3.0提供的、而不是IFX 1.4.0提供的BalInqRq/Rs定义。我们实施改变之后我们得到以下几点：

图8表示，该“若MsgRqHdr”操作以对比颜色高亮度显示，指示对Schema的新版本的升级使该操作无效。原因是，在该IFX 1.3.0XML Schema中该MsgRqHdr元素不存在，但是在该场景中的操作之一利用它，其结果是，这新的上下文中操作没有适当配置。本发明能够自动地检测配置错误，并利用另一个颜色、例如红色对它们进行高亮度显示。按照本发明，所配置的系统能够识别哪些操作利用这个元素并例如用红色高亮度显示它。若我们考察“若MsgRqHdr存在”操作的配置，我们得到以下出错消息：

然后我们能够采取必要的动作(在这种情况下，抑制该“若MsgRqHdr存在”操作)，修改我们的场景来支持该IFX 1.3.0IFXSchema。抑制来自一个场景的操作，就像选择它们并在该计算机的键盘上按下“删除”按钮那么简单。

若我们已经直接用一个像Java、C#或C的技术来实现我们的场景，这会花费长得多的时间来识别哪些部分的代码将受到该输入和输出接口的改变所影响。

业务确认

业务确认超出元数据的实时计算的范围。它在每一个可能的执行路径上探测所得的元数据，以便检查它是否遵循该输出的约束。

在形式上，一个XML处理程序的输入，诸如环球网业务，可以看作是有效的一组实例XML文档(输入元数据)。输出(输出元数据)也一样。业务确认由下面构成：

1)探测该程序的每一个单个分支，

2)计算每一个分支所产生的一组有效的XML文档(针对该分支算出的元数据)，和

3)验证它[“它”＝XML文档组]是否“包括”(在集合理论的意义上)在该输出中的预期的XML文档的集合中。

若它包括在该输出的元数据中，则该XML处理程序被认为是有效的，因为对于每一个符合该输入元数据的XML实例，都保证产生一个符合输出元数据的XML输出。该业务确认并非实时功能性，因为它要求数量较大的计算能力。它是由用户从该系统中的菜单项目调用的。当业务/XML处理程序无效时，该系统列出(见下图)所有检测出来的错误。

由此用户能够选择该清单中的一个错误，而该系统将自动用蓝色高亮度显示该执行路径，其即为该问题的源，并用红色高亮度显示该操作，有的话，其即为该问题的源。

在广泛使用从XML Schema衍生的元数据以便在设计时直接防止和检测XML处理程序中的错误的系统和方法的实施例中，已经对本发明进行了描述。该独特的特征能够在开发时而不是在测试时识别问题，并减少所要求的测试案例数量。最后，这急剧降低开发和维护消息处理应用程序的成本。应该明白，这些实施例只是示例而已，而且本专业的技术人员将会认可，给出上述公开，其它的实施例和明显的改善是可能的，而且本发明的范围是由后附的权利要求书及其等效物定义的。

Claims

1. 一种用于约束驱动建立程序的计算机编程系统，包括：

编程语言及其作为图形流程图的交互式可视描绘，其中处理节点之间的链接对应于该程序的特定执行点，并能够以可视方式加以选择，以便加入新的处理节点，或在给定路径的给定点上立即显示在该点和路径上可用和/或预期已知的有关该数据或亦称作元数据的信息；

元数据计算引擎，配置成在给定该语言给的程序、该程序的输入和输出的元数据和该程序中的执行路径和点时计算该程序中任何给定点和路径上操作和/或预期的数据的元数据；

方法和装置，它采用在选定的执行点上可用和预期的数据的元数据作为输入，并根据它们的输入和输出的元数据建议一个处理节点的清单，当已知时，便启动约束驱动的开发，亦称作引导开发；和

处理节点的每一个可能的类型用的一组配置面板，它利用所操作和/或预期的数据算出的元数据和它在该加入所述处理节点的执行点处的可视描绘，以便启动处理节点的指向和点击配置，并防止用户把其已知约束不满足所述处理模式的一个或多个参数的约束的数据来选择作为所述处理节点的参数，因而，进一步启动约束驱动的开发，亦称引导开发；和

处理节点配置错误可视通知方法，其中若处理节点的配置是或变得不正确，则该处理节点立即以可视方式高亮度显示，因为该处理节点使用的数据的更新后算出的约束不再与处理节点的约束兼容，因而，启动在设计程序时的错误检测，亦称用于改变管理的实时错误检测；和

程序确认引擎，它探测所有的执行路径，为每一个可能的执行路径计算所得的约束，并验证它们是否与程序的输出约束一致，若非如此，则通过列出算出的约束不匹配输出约束的执行路径和点通知用户，因而，启动总体程序确认和加速问题查找；和

2. 按照权利要求1的系统，其中所述处理程序是网络业务程序。

3. 按照权利要求1的系统，其中所述处理程序是互联网业务程序。

4. 按照权利要求1的系统，其中所述程序的输入或输出约束由形式语法、即描述形式语言的抽象结构所定义。

5. 按照权利要求4的系统，其中所述形式语法是由XML Schema或Schema定义的，而且所述元数据计算引擎被称作XML Schema处理引擎。

6. 按照权利要求5的系统，其中所述XML语法是利用下列XML语法语言之一定义的：

1)W3C XML Schema语言，

2)文档类型定义(DTD)语言，

3)Relax NG Schema语言

4)Schematron或ISO Schematron

A7.按照权利要求4的系统，其中所述形式语法是利用对象管理组的接口定义语言(IDL)定义的。

7. 按照权利要求4的系统，其中所述形式语法是由ontology语言定义的。

8. 按照权利要求7的系统，其中所述ontology语言是W3C WebOntology语言(OWL)。

9. 按照权利要求7的系统，其中所述XML Schema处理引擎是在所述平台引擎上实现的。

10. 按照权利要求7的系统，其中所述XML Schema处理引擎使用现存的平台业务。

11. 按照权利要求7的系统，其中所述XML Schema处理引擎本来就处理XML分类信息。

13. 按照权利要求7的系统，其中所述XML Schema处理引擎完成改变管理。