CN103218288B - 信息验证 - Google Patents

Abstract

一种用于知识验证的计算机实现的方法包括标识用于验证的事实。可以创建表示用于验证的事实的语义模型。可以标识与事实关联的上下文，并且可以至少部分地基于标识的上下文来创建自动机。可以使用自动机验证事实。

Description

信息验证

技术领域

本发明涉及信息验证，更具体地，例如，涉及使用确定性有限自动机的、基于内容的知识验证。

背景技术

结构化数据可以用于向用户图形化地显示信息或用于编程地进行处理。可能来自于不同源的无效信息会损害结构化数据的质量。信息的验证可以根据结构化数据的模型（例如，业务交易网域（business trading network domain）中的统一的模型（consolidated model））来保护结构化数据的质量。

发明内容

一般说来，本公开属于知识(结构化数据)的基于内容的验证。它包括对检测到的和插入的知识的内容的验证，以及所述知识符合给定模型（例如，统一模型）的验证。所述验证包括知识的(用户定义的)依赖性的验证。本公开描述一种根据统一的模型的、对于企业的交易网络示出的知识进行验证的系统、方法和计算机程序产品的设计和实现。

在特定实施例中，一种用于知识验证的计算机实现的方法可以包括标识用于验证的事实。可以创建语义模型，该语义模型表示用于验证的事实。可以标识与事实关联的上下文，并且可以至少部分地基于标识的上下文来创建自动机。可以使用自动机验证所述事实。

在特定实施例中，可以将用于知识验证的计算机程序产品存储在有形的、非临时的介质上，可操作该计算机程序产品来运行可以包括标识用于验证的事实的指令。可以创建语义模型，该语义模型表示用于验证的事实。可以标识与事实关联的上下文，并且可以至少部分地基于标识的上下文来创建自动机。可以使用自动机验证所述事实。

实施例的特定实现也可以包括标识统一的模型。该统一的模型可以包括关于公司之内以及公司之间的业务交易网络的信息。所述用于验证的事实可以与统一的模型关联。

在实施例的特定实现中，所述自动机是确定性有限自动机。所述确定性有限自动机可以从ε（epsilon）非确定性有限自动机导出。可以通过状态、输入符号、转移函数、开始状态以及终止状态中的一个或多个来定义确定性有限自动机。终止状态可以是接受状态，并且自动机可以在成功地验证事实之后进入接受状态。

在实施例的特定实现中至少部分地基于语义模型来创建自动机。

在实施例的特定实现中，语义模型还表示与事实关联的事实依赖性。

在实施例的特定实现中，将要验证的事实可以是上下文的子集。

在实施例的特定实现中，至少部分地基于标识的上下文来创建自动机可以包括对于模型实体的每个实例创建自动机。

在实施例的特定实现中，所述将要验证的事实可以是数据记录（Datalog）事实。

在实施例的特定实现中，所述事实可以是事实、知识或数据中的一个或多个。

实施例的特定实现还可以包括提供标识错误状态的运行时图形输出。

实施例的特定实现还可以包括提供标识错误的运行时文本记录输出。

在实施例的特定实现中，使用自动机验证事实可以包括验证结构化数据的结构或内容中的一个或多个。

在实施例的特定实现中，域特定语言可以用于编程模型以指定验证程序。

在实施例的特定实现中，可以从语义模型生成验证程序。语义模型可以以域特定语言，并且从语义模型在运行时生成自动机。可以通过智能算法自动地生成所述自动机。

在实施例的特定实现中，所述事实是统一模型中的事实，该统一模型通过自动机经受验证。

此处描述的系统、方法和计算机程序产品适用于不同维数(结构，内容等等)的结构化数据的质量。本公开提供一种自动的但是可配置的结构化数据的结构验证和内容验证。域特定语言(DSL)或流畅应用编程接口(fluent API)可以用于编程模型以指定验证程序。例如，从DSL生成验证程序，并且验证程序被称为语义模型。例如，从语义模型生成运行时模型作为自动机。在特定实现中，通过智能算法自动地生成自动机。运行时模型能够运行诸如验证程序的自顶向下、自底向上或随机评价的不同评价过程。

此处描述的方法被设计用于数据的有效存储和加载、验证程序的并行处理，以及共享存储器计算(例如，对于定义的验证程序并发)。

所述方法适用于可以是数据记录程序的一部分的事实的验证。数据记录事实被结构化从而可应用于本公开。此处描述的技术也可应用于复杂事实模型，例如，此处描述的统一模型，并且此处描述的技术可以用于对于验证域的事实(例如，基于模型的验证)。

可调试验证程序以产生可作为任何其他程序语言的可用的验证编程模型。为了实时调试，可以通过图形和文本输出来便于调试。

本公开提供定义可配置但是自动的验证方案作为规则和上下文敏感语言范围中的编程模型。它允许域特定数据质量并且允许多个类型的检查，诸如值列表、结构等等。可以由在编程方面具有不同程度知识的人员编写验证程序。

状态适用于验证程序的操作符。这些状态可以是自定义的从而可以通过定制验证操作扩展此处描述的技术，定制验证操作是诸如过滤器状态、长度检查、检查串的开始或结束、对于数字类型的边界检查等等。

在附图和下面的描述中阐述本发明的一个或多个实施例的细节。本发明的其他特征、目的和优点将从说明书、附图和权利要求书中变得清楚。

附图说明

图1是业务图形引擎（Business Graph Engine）的活动图。

图2是示例交易网络全景（landscape）的示意性表示。

图3是示例业务交易网络全景的示意。

图4是统一网络模型的示意性表示。

图5是示例统一算法的处理流程图。

图6是用于系统的呼出调用图形的示意性表示。

图7是用于系统的扩展调用图形的示意性表示。

图8是通过添加系统的调用图形的扩展的示意性表示。

图9是作为图5的步骤2、步骤3和步骤4结果的用于系统S₁的合并图形的示意性表示。

图10是确定性有限自动机的转移图的示意性表示。

图11是示出事实的依赖性的摘录的图形。

图12是解决message_flow(消息流)事实的依赖性的示例的摘录。

图13是两种类型的变元验证的图形表示。

图14是事实验证的图形表示。

图15是用于验证事实的完整结构的εNFA的图形表示。

图16是用于子集构造的事实验证ε-NFA的图形表示。

图17是通过子集构造创建的事实验证DFA的图形表示。

图18是语义模型的图形说明。

图19是共享存储器的示例实现的示意性表示。

图20是用于自动机的示例编程模型的图形表示。

图21是用于示例数据（data）事实的图形输出。

图22是用于runs_on（运行）事实的示例自动机的图形输出，该runs_on事实的相应系统（system）事实没有相应的数据事实。

图23是用于runs_on事实的示例自动机的图形输出，该runs_on事实的主URI（hostURI）没有指定。

图24是用于有效runs_on事实的示例自动机的图形输出。

图25是用于知识的基于内容的验证的示例系统级环境的示意性表示。

图26是用于验证事实的处理流程图。

表格说明

表1是用于图5的统一算法中的已发现的事实的示例的提取。

表2是在示例扩展的统一模型中的已发现的事实的提取。

算法说明

算法1是用于确定事实的状态列表的示例算法。

算法2是用于确定事实模型的级别的示例算法。

算法3是用于事实验证的预处理的示例算法。

算法4是用于确定自动机的下一状态的示例算法。

算法5是用于事实的验证的示例算法。

算法6是用于事实验证后处理的示例算法。

算法7是用于事实验证转移函数的示例算法。

算法8是用于确定变元的依赖性事实的示例算法。

算法9是用于确定事实验证转移函数的返回状态的示例算法。

列表说明

列表1是来自定义文件的示例摘录。

列表2是用于有效数据事实的自动机的示例文本输出。

列表3是用于有效数据事实的点图的示例描述。

列表4是用于利用无效系统事实的runs_on事实的示例定义文件。

列表5是用于利用无效的系统事实的runs_on事实的自动机的示例文本输出。

列表6是用于利用相应的系统事实和无数据事实的runs_on事实的示例定义文件。

列表7是用于利用无效的系统事实的runs_on事实的自动机的示例文本输出。

列表8是用于无效的runs_on事实的自动机的示例文本输出。

列表9是用于有效runs_on事实的示例定义文件。

列表10是用于有效runs_on事实的自动机的示例文本输出。

各个附图中相似的参考符号和标示指示相似的元件。本公开中描述的算法和代码列表意味着示出示例。此处未示出的其他算法和代码也可适用。

算法和列表

算法1是用于确定事实的状态列表的示例算法。

算法2是用于确定事实模型的级别的示例算法。

算法3是用于事实验证的预处理的示例算法。

算法4是用于确定自动机的下一状态的示例算法。

算法5是用于事实的验证的示例算法。

算法6是用于事实验证后处理的示例算法。

算法7是用于事实验证转移函数的示例算法。

算法8是用于确定变元的依赖性事实的示例算法。

算法9是用于确定事实验证转移函数的返回状态的示例算法。

列表1是来自定义文件的示例摘录。

列表2是用于有效数据事实的自动机的示例文本输出。

列表3是用于有效数据事实的点图的示例描述。

列表4是用于利用无效系统事实的runs_on事实的示例定义文件。

列表5是用于利用无效的系统事实的runs_on事实的自动机的示例文本输出。

列表6是用于利用相应的系统事实和无数据事实的runs_on事实的示例定义文件。

列表7是用于利用无效的系统事实的runs_on事实的自动机的示例文本输出。

列表8是用于无效的runs_on事实的自动机的示例文本输出。

列表9是用于有效runs_on事实的示例定义文件。

列表10是用于有效runs_on事实的自动机的示例文本输出

具体实施方式

随后讨论此处公开的主题可以应用的示例领域(业务交易网络)。然而，应该理解，主题没有仅仅限制为该领域。例如，此处描述的主题可以用于任何结构化数据，包括下面描述的与统一模型关联的结构化数据。此外，此处描述的主题适用于其他领域，诸如演绎系统的输入、用于链接的数据社区的数据质量验证、过程挖掘等等。

业务交易网络是由SAPAG开发的软件，其图形化地给出企业的交易网络的中心概况。为此，将关于用户全景的信息收集、合并和存储在模型中，该模型的逻辑知识表达以数据记录（Datalog）实现。因为用户可以通过开发他们自己的数据分离器和处理器来影响事实的插入（injection），所以必须依照事实的内容和相互依赖来验证事实以保证一致的知识库（knowledgebase）。为了处理这个问题，已经开发了基于确定性有限自动机的编程模型。它允许一般地处理数据记录中编码的知识并且它准许对验证逻辑的定制扩展。

本公开讨论基于内容的事实验证的不同的方法，并且给出关于使用确定性有限自动机的事实验证的概念、实现和编程模型的详细描述。实现的事实验证自动机(FVA)便利了使用不同的验证策略在给定上下文中分布的事实的验证。可以通过使用域专用语言定义事实的结构来操纵验证。此外，对于FVA，可以实现包含验证逻辑的定制状态。此外，本公开描述在业务交易网络的上下文中的开发的FVA的应用。它评价在此上下文中的不同的根原因（root causes）并且示出用于不同的验证策略的性能测量。附加地，存在关于调试的一些指导,即,分析事实无效的理由。

企业管理他们的知识，该知识不仅包括雇员的技能和资格，而且关于企业参与的业务网络的种类的信息。然而，与收集和管理的知识量无关，知识的益处仅仅和它的质量一样好。知识必须一致，从而它需要被验证。

业务交易网络是收集关于公司之内和公司之间的业务交易网络的信息并且将它们存储在模型(称作统一模型)中以便为用户图形化显示它们的软件。然而，因为存在不同原因的无效信息(例如，用户手动地插入事实的可能性)，必须验证信息以便保护关于业务交易网络的知识的质量。因此，本论文的主要主题是基于内容的知识验证。它包括检测到的和插入的知识的内容的验证，以及该知识的内容与预定义统一模型的符合的验证。这包括知识的可能依赖性的验证。然而，此研究不包括统一模型自身在完整性或一致性方面的验证。

企业具有以非中心控制方式运行他们的业务过程的大业务交易网络。业务交易网由合同、虚拟组织、转包合同、特许、合营企业、支持组织等等产生的各种业务网络形成。到目前为止，在企业之内和企业之间都没有获得中心概况的办法。概述由商业机构之间的企业对企业(B2B)过程产生的网络很复杂，B2B处理是向另一商业机构出售商品或服务的过程。

那意味着，如果必须管理不同的信息技术、中间件和应用，则只得付出大量努力。例如，如果领域专家或文档可用，则必须从领域专家或文档收集关于“as-is（现状）”网络的知识。中间件可以被认为是使能应用系统和数据源之间的跨平台通信而不考虑使用的程序语言和通信协议的抽象软件层。

因此，正在开发企业交易网络。它的目标是准确地和明确地表示公司的业务交易网络。从而，它使得联网企业的B2B关系可见，并且在整合开发以及应用之后减少端对端的生命周期，并且允许关于用于更快速运行的不同的互相联结的信息的协作。为此，业务交易网络便于从公司、社会的和合成的人工制品（social and integration artifacts）的真实实例自动生成“as-is”网络。它也使得不同的人能够合作以定义关于推断网络的“to-be（将要）”方面。这可以基于例如事件驱动流程链(EPC)或白板图（white-board drawing）的设计图完成，其意味着“to-be”网络是新创建的，而不使用已经存在的“as-is”方面。此外，它们可以利用业务语义(例如，业务标签或文档实体)将推断的网络置于上下文中并使其丰富。除那之外，可以定义策略和服务等级协议(SLA)，其是关于成本、价格和目标、如果没有满足协议则关于运行系统的服务等级和质量以及过程策略的合约也可以写回改变成为原始数据源。网络可以对可以随时合作地解决的业务和整合例外或事件进行监控。

业务交易网络的益处包括交易网络可见性、合伙者上岗、业务例外管理和合约确定。全部特征可以在用户自己的交易网络的上下文中完成。

通过不同层便于图1中示出的业务网络图形的创建。图1是业务图形引擎的活动图100。在业务网络图形的创建中涉及不同层。在右侧是最低层，网络/客户全景层102，在其中提取关于业务交易网络的信息。在图1的左侧是最高层，业务图形用户界面/应用112，在其中显示图形。网络源层104搜索网络/客户全景102中的源。特定域分析组件使用连接器基础结构获得来自源系统的数据，该特定域分析组件是网络源层104的部分并且包含用于从系统读取并处理信息的域专用知识。例如，连接器通过超文本传输协议(HTTP)或企业服务与此全景中的系统通信，并且加载关于它们的信息。例如，发现数据组件114通过安全信道连接到提取数据组件116。提取数据组件116连接到对事实的处理数据分析（Process DataAnalysis to Facts）118，在其中以事实的形式存储信息。下一步是通过导出的文件或发布的原子提要（atomfeed）(发布分析事实120)向网络统一层108提供事实。这在隔离区(Demilitarized Zone,DMZ)106中完成，DMZ一般是计算机网络中的子网，其允许从内部网外部访问需要从外部到达的服务器，而不允许访问内部网。在业务图形引擎100的上下文中，可以从网络统一层108访问事实，网络统一层108可以在云中，这意味着它没有安装在客户的计算机上。然而，事实是从网络/客户全景层102提取的。为了分离这两层，存在DMZ106。由网络整合模型层110和网络统一层108构成的链接的数据引擎109使用出自DMZ 106的预处理的事实和相应的规则以使用推理算法124来统一事实。

推理算法124包括统一处理。该统一包括发现的数据以及已经存储在知识库中的信息。在统一期间，关于系统的信息被转移(例如，像统一模型那样的)为公共格式。下面还将解释此模型。在统一之后，统一模型持续。下一步是将统一模型变换成为网络整合元模型(Network Integration Meta-Model，NIMM)资源图形121。NIMM模型122是业务过程模型表示法(BPMN)2.0的扩展和专门化，BPMN是用于公司之内和公司之间的模型业务过程的图形标准。因此，NIMM 122描述公司之内和公司之间的不同实体和他们的关系。这在网络整合模型层110中完成。最终，在业务图形用户界面/应用112中，可以解决业务图形并在用户界面130上显示业务图形。

业务图形是由不同的企业和人、以及彼此合作的系统的网络和应用构成的图形。通常，大企业的业务图形由两个网络组成：用于内部处理的应用和中间件的一个网络，以及用于外部处理的另一个网络，该外部处理用于与业务伙伴(例如，供应商、承运人或经销商)的交互。即使它可能不明显，企业资源计划(ERP)系统中的巨大量的数据来自于联网的企业外部。实际上，这个的原因是企业对企业(B2B)处理经常实现为与业务伙伴的文档的事务性交换以便更合作地完成业务。这导致在伙伴网络的上下文和关系中的链接的数据结构风格。因此，强烈需要多个企业之间的协调（orch estrating）处理。协调是对可运行的业务过程以及它们与内部和外部网络服务的交互、以及它们的交互的描述。组合连接、业务和社会方面的综合视图可以被描述为链接的业务图形。

典型的传统技术网络在图2中示出。图2是示例交易网络全景200的示意性表示。图2示出由内部网络和互联网中的系统构成的更多面向整合的业务交易网络的摘录。在这些系统上，存在运行和彼此交互的不同应用和中间件。例如，系统A202包括应用A和企业服务总线(ESB)-A，该ESB-A可以是企业服务(ES)代理，ES代理是基于网络服务的应用代理，该代理具有系统嵌入集成的类别。在内部网中连接的系统可以彼此通信，或者可以与DMZ中的系统通信或跨越互联网通信。例如，系统D 204跨越隔火墙与系统206通信，该系统206在这种情况下是B2B网关。此客户全景可以通过整合顾问和设计师来实现并且可以通过IT操作和管理人员来管理。在这一时间点上，完整的网络的总体视图仅能通过收集企业中的整合知识来实现。此外，此业务交易网络是隐式的，这意味着它仅示出系统、以及系统之间的关系。然而，业务交易网络中的企业取决于业务伙伴交互的类型而扮演不同角色(例如，顾客或厂家)。此信息和相应的语义隐藏在主数据、业务过程和域专用配置中。

图3是示例业务交易网络全景300的示意。此网络包括企业302和它的业务伙伴(零售商304和厂家306)。商品可以保存在仓库中，并且ERP后勤系统308连接不同的配送中心310。配送中心310通过诸如ERP系统零售312和后勤314之类的其他ERP系统与业务伙伴连接。图3中的业务交易网络全景300由保持它们自己之内以及企业之间的关系和依赖性的业务和高级（power）用户构成。为了完成他们的每日工作，他们需要不同业务领域中的专用知识以及与其它领域的频繁通信。在这种情况下，它们将能获得关于业务关系的概要。

用户在他的屏幕上注视的链接的业务图形（Linked Business Graph）基于模型：统一模型。如上所述，通过采用由网络分析收集的领域专用信息形成的第一原始形式。使用此原始数据，由统一机制确定统一网络，该统一网络是关于跨越不同应用和综合系统以及业务方面的网络的视图。该机制仅仅包含用于满足此任务的信息量。

统一模型的结构在图4中示出。图4是统一网络模型400的示意性表示。此模型示出业务交易网络的主要参与者以及关系。图4示出业务网络之内的特定参与者。主要参与者是系统(例如，系统402和主机404)。系统是可以使用runsOn语义分配给物理实体(即，主机)的逻辑实体。两个系统之间的关系可以由MessageFlow（消息流）408或SystemLink（系统链路）406定义。此外，表示两个参与者之间的消息交换的MessageFlow 408还可以存在于系统和配置或者两个配置之间。配置属于系统并且描述技术或关于系统之间的关系的业务信息。存在两种类型的配置：指示流入的MessageFlow的流入配置和表示流出的MessageFlow的流出配置。

统一模型的一个重要特征是除语义runsOn 420、sameSystem 422、sameHost 424和systemProperties 426事实之外的全部实体链接到数据实体，该数据实体包含关于实体的技术信息，例如，它们的URI。因此，必须存在匹配相应实体的一个数据实体。

通常，构思是将物理主机表示为参与者，并且然后找到由此主机提供或调用的接口，而且系统运行该接口。不同种类的系统具有在它们之上运行的不同应用和整合逻辑。对于统一，通过术语系统使整合逻辑和业务实体成一体。图4中的括号[]指示数据的分析和发现的类型：[user]（[用户]）意味着由用户插入的信息，而[bus]或[disc]意味着业务或整合相关数据。

使用事实(诸如数据记录事实)形式化统一模型处理的已发现的信息。数据记录是使用一阶逻辑的一种知识表示类型。即，它是使用霍恩子句（Hornclause）表示关于关系的操作的语言。通常，子句是大量文字的总和。文字是原子公式或否定原子公式。原子公式的一部分是谓词符号p。因为每个原子公式具有一个谓词，所以一阶逻辑还称作谓词逻辑。原子公式的其它部分是变元(qi)的列表。因此，它可以用下列方式标注：

p(q1,q2,...，qi).

通常，霍恩子句是具有最多一个肯定文字的子句。存在各种霍恩子句：

·如果霍恩子句仅由一个单肯定文字构成，则它被称为事实（fact）。事实不仅由谓词和变元的列表构成，它们还具有元数（arity）k。表达式p^k意味着k是具有谓词p的事实的元数。例如，统一模型中的系统通过以下事实描述：

system_discx (name；description；systemURI）

因为此事实具有三个变元，所以它的元数是k=3或system3。当事实存储在数据库中时，这被称为扩展的数据库(EDB)。这是表示统一模型的方式。

·由一个或多个否定文字构成的霍恩子句被定义为完整性约束(integrityconstraint)。

·如果存在一个肯定文字和一个或多个否定文字，则霍恩子句称作规则(rule)。规则由首标h和主体构成，主体看起来类似于表达式p₁Λp₂Λ...Λp_i。每个p_i被称为子目标。完整的规则是：

h:-p₁Λp₂Λ...Λp_i.

此规则意味着如果p1和p2以及…和p_i是真，则h是真。在知识库中的规则的存储器称作内涵数据库(Intentional Database，IDB)。

此外，霍恩子句的集合称作逻辑程序。此程序通过在事实和规则上应用逻辑推理的数据记录引擎来运行。业务交易网络引擎使用专用的统一算法来完成。它被统一器（consolidator）标定和运行，统一程序代表对与专用源模型交互的专用浏览器（Explore）和分析组件的大部分分析。因此，统一程序能够坚持与不同系统的源模型无关。

如前所述，统一算法被描述为用于从发现的事实导出新事实的一组规则（例如，数据记录规则)。通过统一算法处理的全部事实在表1和表2中解释。表1是用于图5的统一算法中的已发现的事实的示例的提取。该表示出已发现的事实的选择、它们的含义以及它们被发现的统一算法的步骤。

表1.用于统一算法的发现的事实的提取

表2是在示例扩展的统一模型中的发现的事实的提取。该表示出在扩展的统一模型中的发现事实的选择和他们的含义。

表2.扩展的统一模型中的发现的事实的提取

在图5中示出统一算法的概要。图5是示例统一算法的处理流程图。算法的步骤可以以特定次序执行以保证发现相关信息。统一算法的第一步是唯一的主机和系统502的标识。如上所述，网络基于在用户全景中运行的主机。主机通常由名称、互联网协议(IP)地址等等标识。系统（其是在主机上运行的逻辑标识）仅具有依赖上下文的标识符。相比主机，不存在用于系统普遍适用的标识方案。作为结果，关于主机和系统的信息从不同的源收集并且首先存储在源专用的源模型中。这在网络源层中发生。为了创建单个统一化模型(统一模型)，必须编辑唯一的系统和主机的列表。

如上所述，问题是不存在通用的标识方案。例如，随时间，不同的域名系统(DNS)名称可能用于具有专用IP地址的主机，反之亦然。为了解决这个问题，在全部可能标识符的集合上创建等价类。一个等价类包含为标识相同系统或主机所知的全部标识符。因为当其它改变时等价类的至少一个元素不改变，所以主机和系统的标识符可以在长时间内保持恒定但是逐渐改变。添加新信息并除去过时信息的处理持续。因此，通过向每片已发现的信息添加时间戳来完成确定哪个信息相关并且哪个信息过时的方法。

然后，执行来自系统的流入和流出调用的确定504。使用该源模型，可以确定不同的系统之间的流入和流出调用。假定另一方面存在用于到系统的大部分（但是可能不用于全部）流入调用的流入调用配置。另一方面，将有用于系统的大部分流出调用的流出调用配置。然而，对于诸如其中由另一系统调用系统的功能的远程功能调用(RFC)的一些情况，不存在除正在被远程使用的功能以外的需要的流入调用配置。因此，没有配置会被检测到。此步骤的结果应该是用于具有特定标识符的系统的流出和流入调用图形，诸如图6中示出。图6是用于系统600的流出调用图形的示意性表示。唯一地标识的系统S₁602具有不同的流出调用配置(例如，OCx 604、OCa 606)，其将S₁602直接或间接地连接到其他系统。

下一步是基于流出调用确定来自系统的消息流506。因为流出调用朝向特定系统，所以相应的调用配置经常包含接收该调用的系统的标识符。在这种情况下，该标识符将与在第一步骤中发现的系统的标识符相配。此步骤将导致用于具有专用标识符的系统的扩展调用图，如图7所示。这通过添加存在流出调用配置的系统发生。图7是用于系统700的示例扩展调用图的示意性表示。唯一地标识的系统S₁702具有经由消息流连接到用于其他唯一的系统(例如，S₂708)的流出调用配置(例如，OCb 710)的不同的流入调用配置(例如，ICz704和ICy 706)。

然后，基于流入调用确定到系统的消息流508。对于特定系统的每个流入调用配置，调用系统的标识符与在步骤502中找到的系统相配。这类似于步骤506，但是在这种情况下算法搜索向正在被检查的系统发送的系统，而在步骤506中，它寻找从被检验的系统接收到调用的系统。然而，即使在流出调用配置中找到接收器是常见的，在流入调用配置中找到发送器不是非常常见的。这个的理由非常简单。例如，人A会向另一个人B传送明信片。为了明信片到达B，A需要在明信片上书写B的地址，否则邮局不会知道B在哪住。然而，对于邮局，它与知道A在住哪无关。因此，为了将明信片带到B，不强制A在明信片上书写他的或她的地址。对于系统和调用配置同样如此。根据那个道理，将发现比流入/发送器对多更多的流出/接收器对。总的说来，此步骤还将扩展由步骤506形成的图形，因为它将添加从其接收流入调用的系统。在图8中示出对于结果图形的示例。图8是通过添加系统的调用图的示例扩展的示意性图800。系统S₁802经由它的流入调用配置(例如，ICa 806)和其它系统的流出调用配置(例如，OC1808)与其它系统(例如，S₂804)直接或间接地通信。系统（通信来自于该系统）的添加进一步扩展调用图。

在下一步中，用于系统的调用图被合并并且形成网络510。在此步骤中，算法将试图通过匹配来自不同的标识系统的已经发现的流入和流出调用配置来确定更多消息流。这通过匹配兼容的消息类型或协议完成。可能的是，一些流入调用配置可能不匹配已经标识的流出调用配置或其他方式。然而，这些配置仍然保留在统一模型中。在此步骤成功地完成之后，会在已经创建的图形之间存在一些附加的链路。图9是作为（图5的）步骤504、步骤506和步骤508结果的用于系统S₁的合并图形900的示意性表示。此图形900示出经由消息流与系统S₁902直接或间接地通信的全部系统(例如，S₂904)和配置(例如，OCa 906和ICz 908)。

下一步链接具有应用和整合内容的消息流512。此步骤的理由是前一步骤的结果是关于网络的视图，但是发现的消息流仅表示主机和系统之间的通信。然而，流出调用配置还可以具有到在系统上布置并运行的应用和整合内容的链接。对于应用主机或系统以及专用流出或流入调用配置，确定到特定应用代理或到系统自身的链接。这很重要，因为可能存在同时在一个主机上运行的很多应用。对于整合总线、企业服务总线或B2B网关以及特定流入调用配置，此步骤确定一个或一组流出调用配置。这稍后被称为整合处理。

最后步骤是用户富集（enrichment）514。因为算法从不同的数据源收集信息，所以统一模型的质量将随时间改善。此外，它可以从直接用户输入学习，也被称作“用户富集”。这些事实通过后缀用户来标记以突出显示与发现的事实相比的不同来源，其通过postfix_discx指示。

即使它们不在统一算法的步骤中提及，也存在统一模型管理的更多信息，例如关于系统的接口或在系统上运行的应用。这些类型的信息(仍)不在统一期间处理。然而，它们应该显示在链接的业务图形上。

为了保证统一模型一致，必须验证事实。在业务交易网络(参见图4)的上下文中，知识验证是保证事实集中的全部事实一致的处理。这暗示每个事实属于业务交易网络的模型,即,它的结构如期待的并且它包含创建业务图形所需的基本信息。因此，有效性包括

1.存在全部需要的变元;

2.符合可以已经对于变元(例如，系统的名称的长度或模式)定义的任何限制；以及

3.解决事实(例如，对于每个runsOn事实的有效系统和主机事实)之间的全部依赖性的可能性。

当解决事实之间的依赖性时，必须存在唯一地标识事实的一个关关键字字变元。这个变元是事实的URI。通常，“通用资源识别码(URI)是标识抽象或物理资源的字符的紧序列”。因为URI标识资源，所以它保证找到事实依赖的相应事实。作为结果，大部分事实具有包含他们的URI作为主关键字字的一个变元，该URI用于唯一地确认所述事实。其他事实也包含其他事实的URI，但是这些URI被用作参照它们依赖的事实。例如，系统事实的验证涉及以下调查：

1.系统是否具有名称和URI？名称将显示在图形用户界面上并且URI需要确认事实并解决依赖性。

2.变元的名称是否是至少一个字符但不超过255字符长?

3.是否存在具有与系统事实相同URI的有效数据事实?

作为结果，当且仅当全部三个要求满足时系统事实有效。

对于知识验证的动机是防止知识库由于不同原因而变得不一致。在来自源系统的数据发现和提取中可能存在实现误差。例如，当存在这些组件的源代码方面的改变时，发现可能不再正确地工作从而使相当正确的事实失真。为了通知这些实现误差，知识验证可以是有用的。此外，也允许用户插入事实。这也是不正确的和不一致的事实的潜在源。最终，顾客或伙伴可能构造它们自己的“事实提供者”，其从源系统提取事实从而可能导致不正确的事实。不管存储在知识库中的事实的源，它们不应该导致整个知识库变得不一致。为此，验证是至关重要。

如在前面提及的，知识库应该是一致的。因此，在事实的存留（persist）之前的验证似乎是合理的。最好的时间点是在事实的导入处理期间或在事实的导入处理之后，因为如果恰好在存留处理之前完成验证，则整个统一处理已经完成。如果存在一个无效的事实，则在一致处理启动之前检测它是合理的。另一方面，因为数据记录事实还可以被导出成为标准“事实提供者”或由伙伴或顾客编译的“事实提供者”，所以另一合理的时间点是在导出事实之前。这保证仅导出有效事实。

确定性有限自动机可以用于事实验证。技术系统可以基于事件进行行为。即，它们停留在一个状态直到指定事件发生。取决于他们的状态和事件，它们利用指定动作发生反应。从而，状态是系统的“存储器”。因此，事件具有两个效果。一方面，它使得机器显著地发生反应，另一方面，它可以导致机器的内状态的改变。

这种构思可以应用于事实验证的问题。事实的输入使得事实集合变得一致或不一致。此外，更精细地考虑问题，变元的验证可以使得事实变得有效或无效。因此，可以使用有限自动机的构思解决这个问题，有限自动机是具有状态的有限集合的自动机。存在两个种类的有限自动机：接受器，其接受或拒绝输入，或转换器，其读取输入并使用它以生成输出。

因为事实验证的情况要么接受有效事实要么拒绝无效的事实，所以事实验证的情况必须由接受器自动机完成。然而，在可以进一步引入有限自动机之前，必须提出自动机理论的一些主要概念。存在字母表，其是符号的有限的非空集。例如，字母表

∑={a,b,c,...，z}

表示全部小写字母。此外，一个串（string）是一些字母表的符号的有限序列。如果一个串由零个符号构成，则它称作空串(ε)。形成串w符号的数量称作串的长度，其是|w|。例如，空串的长度|ε|=0。对于任何字母表∑，某一长度k的全部串的集合可以表示为∑^k。对于任何字母表∑，具有长度0的全部串的集合是∑⁰={ε}。这意味着仅长度是0的串是空串ε。将具有小写字符、具有长度2的串集合作为示例字母表，∑²={aa,ab,ac，...,zz}。字母表∑内的全部串集合由∑*表示，其被定义为

∑*=∑0V∑1V....

从用于特定字母表∑的一些∑*中选择的全部串的集合还称作语言。对于一些字母表∑，L是∑内的语言，如果

语言的仅有约束是全部字母表是有限的。即使它们可以具有无穷大数目的串，语言仅只限于包含在一个固定的、有限字母表中的串。给定串是否是给定语言的成员的决定被称为问题（problem）。对于事实验证，问题是决定事实是否有效,即,它是否是仅由有效事实构成的语言的成员。

如上面已经提及的，存在不同类型的自动机。存在有限自动机和无限自动机。一种类型的有限自动机是确定性有限自动机(DFA)，其是同时仅处于一个状态中的有限自动机。响应于一些输入，存在到出自DFA的状态集合的一个状态的转移。与可以同时处于多于一个状态的不确定性有限自动机(NFA)相反，DFA可以直接在计算机上运行。NFA首先必须编译成为DFA以便运行它，但是作为回报，它允许使用“高级语言"。

正式定义的，DFA具有以下特征：

·有限的状态集合(Q)；

·有限的输入符号集合(∑)；

·转移函数(δ)，其具有状态q和输入符号a作为变元并且返回状态p。因此，δ(q,a)描述从q到p的标记为a的拱(arch)；

·起始状态(q₀)，以便q₀∈Q；以及

·最终或接受状态(F)的集合，以便F

描述DFA的一个方法是使用5元组标记：

DFA=(Q,∑，δ,q₀,F).

存在其他方法来表示自动机。一个标记是转移图，其是包含用于Q中的每个状态的一个节点。此外，存在对于Q中的每个状态q以及∑中的每个输入符号a的从节点q到节点p的标记为a的拱。此外，存在到自动机的起始状态q₀中的、不来源于任何状态的一个箭头。表示接受状态的节点由双圆形标记，而不在F中的全部状态(因此是非接受状态)由单圆形做标明。在图10中示出转移图的示例。图10是确定性有限自动机(DFA)的转移图1000的示意性表示。DFA具有三个状态。取决于输入，它使用可用的转移来要么去到它的接受状态要么去到非接受状态。

对于三个状态q₀1002、q₁1004和q₂1006的每个，图形中存在一个节点。因为没有来源的箭头进入q₀，所以起始状态是q₀。状态q₂是由双圆形标记的唯一的节点，因此它是DFA的唯一终止状态。此外，状态之间存在拱。例如，存在从q₀到q₂的标记为a的拱，其表示转移函数δ(q₀,a)=q₂。图10中的自动机还由以下5元组表示法表示：

DFA=({q₀,q₁,q₂},∑,δ,q₀,{q₂}).

DFA的字母表是∑={a,a}，对于此示例其意味着输入通过a或者非区分。注意在用于DFA的转移图中，存在用于出自字母表∑的每个输入符号的一个拱，其从此状态出去。

如上所述，自动机可以要么是接受器要么是转移器。仅谈论接受器，不是通过接受器自动机对于单个输入符号处于的状态来确定接受的动作，而是对于被称为串的输入符号的列表确定。问题是在处理整个输入串w之后确定自动机处于的状态。为了确定自动机的最后一个状态，必须定义扩展的转移函数。不同于确定给定状态和给定输入符号的下一状态的转移，扩展的转移函数确定输入串的最后一个状态。可以通过关于输入串的长度的归纳来定义DFA的扩展的转移函数

当不存在输入符号时，自动机停留在状态q，其是它的当前状态：

如果存在由子串x和它的最后符号a构成的串w，则：

这意味着，为了确定首先确定在处理子串x(其是)之后自动机处于的状态。假定此状态称作p，则因此，描述在利用输入符号a从p转移之后自动机处于的状态。这导致 使用关于DFA的信息、它的状态和转移，接受器的构思现在可以应用于知识验证。

可以使用数据记录事实或其他事实模型描述将要验证的知识。根据统一模型，事实可以取决于其他事实。在图11中示出业务交易网络的一些事实和他们的依赖性。图11是示出事实的依赖性的摘录1100的图形。此图形示出依赖其他事实的事实的摘录。例如，为了system_discx事实1104有效，必须存在具有相同关键字(例如，URI)的data_discx事实1102。另一示例是operation_discx 1108，其依赖具有它的configURI的incoming_discx1110和/或outgoing_discx 1112并且依赖具有它的操作URI的有效data_discx。此外，有可能的是，一个事实依赖两个事实中的一个，例如，message_flow_discx，它的发送者URI和接收者URI依赖有效incoming_discx1110／outgoing_discx 1112或者有效system_discx1104。

如图11示出，存在可以独立于其他事实被验证的事实的一些“簇（cluster）”。例如，当验证message_flow_discx 1114时，host_discx 1116事实是不相关的。然而，因为发送者URI和接收者URI依赖incoming_discx1110/outgoing_discx或者system_discx 1104，所以system_discx 1104事实全部相关。如果它依赖两个配置事实，则这些事实还依赖system_discx1104事实等等。在图12中示出这个问题。

图12是解决message_flow_discx事实1202的依赖性的示例的摘录1200。图12示出message_flow_discx事实1202的验证可能相关的事实(其中箭头意味着“依赖”）。事实依赖一个事实或另一事实是可能的。

例如，级21204或更高级别的事实不一定依赖全部更低级别的事实。作为结果，当且仅当共享事实重复时可以将要验证的事实的集合分割成为子集。例如，一个集合由operation_discx、binding_discx(如图11所示)、以及message_flow_discx 1202、incoming_discx 1206、outgoing_discx1208、system_discx(例如，1210)、host_discx(例如，如图11所示)以及data_discx(例如，1212)事实构成，分配这些事实的一种可能性是使用以下子集S_i(由于易读性省略事实谓词的_discx)：

·S₁=S_operation□S_binding□S_incoming□S_outgoing□S_system□S_data

·S₂=S_{message_flow}□S_incoming□S_outgoing□S_system□S_data

·S₃=S_host□S_data

作为结果，只要仅包括具有相同谓词的事实的全部事实集合在之前重复，S1、S2和S3就可以彼此独立地验证。

为了能够验证事实，解决它的依赖性。通过确定性有限验证自动机(DFVA)便于此解决。可以正如上面描述的有限自动机一样描述用于事实验证(FVA)的自动机。它也具有状态的集合(Q’)、输入符号的集合(∑’)、转移函数(δ’)、起始状态(q₀’)和接受状态的集合(F’)。此自动机的5元组描述显示如下：

FVA=(Q’;∑’;δ’;q₀’;F’).

然而，可以以与接受正则语言的标准确定性有限自动机不同的方式解释此定义的一些部分：

·Q’：状态集合。在变元验证之前自动机处于那些状态中的一个。然后自动机可以处于出自Q’的和以前一样的状态或者另一状态。

·∑’:输入符号的集合是可能有效或者无效的事实的变元的集合。因此，∑’可以被解释为一个事实具有这样的限制：它的变元处于有序集合中或者更精确地处于列表中。

·δ’:该转移函数表示一个变元的验证,即,它确定输入变元有效与否。

·q₀’:对于事实验证自动机，起始状态是在自动机开始验证第一变元之前处于的状态。

·F’:接受状态的集合仅包括一个状态，其是在成功地验证全部变元之后自动机去到的状态。因此，可以通过调查在验证事实之后自动机是否处于它的接受状态来确定验证的成功。令q_n是在事实验证之后自动机处于的状态，则

q_n∈F’→事实有效

以及

对自动机使用正则表达式(从而正则语言)的转移的归纳证明来完成自动机的构造。将要验证的知识不必是文本串。而是，它可以由(例如，数据记录中编码的)复杂事实表示，该事实的有效性通过可以由人指定的模型定义。因此，此方法可能必须扩展到更强大的语言。

语言的生成能力可以被分类为形成语法和语言，它们被描述为四个类别。语法G被定义为四元组(V，∑，P;S)：

·V是非终结符集合(即，可以使用某种规则以终结符代替的变量)。

·∑是不能再被替换的终点或终结符的字母表。它们是语言的基础。

·P是由左部和右部构成的生产规则的有限集合。左部由非终结符构成而右部可以由终点或非终结符或两者组合构成。产生规则类似于数学等式，其中等式的右部分配给左部。通常，它表示为l→r。

·S是语法的起始符号。语法的定义从此符号开始。因为越来越多非终结符可以使用产生规则通过终结符替换，所以通过遍历到达全部其他符号。

如上所述，存在四个语法类型：

·类型-0：非限制性语法：这类语法包括通过上面的定义覆盖的全部语法。

·类型-1：上下文有关语法：此类型的语法也是类型0语法。然而，每个产生规则l→r必须满足以下条件：|l|≤|r|。作为结果，在应用产生规则之后，导出串不能比之前更短。

·类型-2：上下文无关语法：类型2的语法是上下文相关的，但是任一产生规则的左部必须仅由一个非终结符构成。因此，对于全部产生l→r，它应用：l∈V。类型1和类型2的语法用于编译器设计和构造。此外，大部分编程语言的语法可以通过上下文无关语法描述。

·类型-3：正则语法：每个正则语法是上下文无关的。此外，每个产生规则的左部由非终结符构成。然而，任一产生规则的右部必须由空串∈或出自∑的终结符构成，任一产生规则的右部的后面可以跟随或者可以不跟随出自V的非终结符。因此，右线性正则语法的每个产生规则l→r的形式利用下式正式表示：

l∈Vandr∈{∈}U∑U∑V

通常，可以使用类型-3语法定义编程语言的词汇结构。作为结果，当Ln描述通过类型n的语法构成的语言时，四个语法类型的关系可以被描述为

语言的能力从类型0到类型3降低。因此，类型2语言(具有上下文无关语法)是具有类型3语法的正则语言的扩展。然而，对于自动机的构造，假定它仅接受正则语言，因为变元的内容是简单的串。然而，构成的自动机可以具有一些更高级别特征以便解决事实的依赖性。

不确定性有限自动机(NFA)是可以一次处于多于一个状态的有限自动机。这使它能“猜测”关于它的输入的某些事情。例如，它可以“猜测”事实具有更多变元或不具有更多变元。关于NFA的感兴趣的事是它们可以接受与DFA相同的语言，即使它们可以比相应DFA更容易地设计。NFA的定义类似于DFA的定义：

NFA=(Q;∑;δ;q₀;F).

此外，处理正则表达式的NFA的语言被定义为

那意味着，L(NFA)是∑*中的串w的集合以使得扩展的转移函数包含至少一个最终状态而最终状态的集合不是空的。NFA和DFA之间的主要区别是转移函数δ返回的值的类型。DFA返回一个状态而NFA返回状态的集合。此外，不必从每个状态中转移，其意味着，状态的序列可以“消失（die）”。然而，除了通过跟随出自标有最后一个输入符号的这个状态的全部拱确定一个状态的下一状态之外，扩展的转移函数类似于DFA的转移函数。

考虑NFA和DFA的区别，现在问题是它们两者如何可以接受相同语言。如上所述，通过NFA描述的每个语言也可以通过一些DFA描述，即使在最坏情况中，DFA将具有比相应的NFA更多的状态。通常，DFA具有与NFA的状态大约同样多的状态，虽然它可以具有多得多的转移。为了对于给定NFA找到相应的DFA，必须使用过程调用子集构造。子集构造的基础是NFAN=(Q_N;∑;δ_N;q₀;F_N)。目标是当两个自动机的字母表(∑)相同时构成DFA D=(Q_D;∑;δ_D;{q₀};F_D)以使得L(D)=L(N)。子集构造的主要构思是DFA的构成状态是NFA的状态的集合。例如，D的起始状态是仅包括在表示起始状态N的集合中的状态。D的其它分量的构造如下完成：

·DFA的状态集合Q_D是Q_N的子集的集合。如果Q_N具有n个状态，则Q_D将具有2ⁿ个状态。然而，Q_D中存在不能从它的起始状态到达的状态，因为不可达状态可以被“废弃（trashed）”。这意味着它们不在转移图中示出。

作为结果，Q_D中的状态的数量可以比2ⁿ小得多。

·接受状态的集合F_D是包括DFA的一个或多个终止状态的NFA的子集的集合，而不是包括更少终止状态。因此，F_D是QN的子集S的集合以使得

·为了从Q_N的子集和给定变元a计算δ_D，使用全部状态的联合，其中出自子集的一个状态去到标记为a的弧。更正式地,对于每个子集S_QN和∑中的每个输入符号，确定

通常使用转移表完成子集构造。然而，因为这似乎是非常耗时的，所以存在称作“懒惰估算法（lazy evaluation）”的可以在子集上执行的方法：

1.存在仅由NFA的起始状态构成并且在开始阶段可访问的单元素（singleton）集合。

2.在确定可访问状态的集合S之后，对于每个输入符号a，计算状态δ_D(S;

a)的集合。全部这些状态也是可访问的。

类似于如上所述的NFA定义ε不确定性有限自动机(∈-NFA)：

∈-NFA=(Q;∑;δ;q₀;F).

除现在使用两个变元的函数的δ之外，可以与NFA相同地解释定义的全部分量。首先，它使用出自Q的一个状态，其是自动机“来自”的状态。第二，它使用S U {∈}的成员，其要么是出自字母表的输入符号要么是符号∈。注意在此定义中，空串∈不是字母表∑的成员。

所谓的∈-转移使∈-NFA能自发地,即,没有任何输入地去到下一状态。此可能性不改变由自动机接受的语言，但是它提供关于自动机构造的一些“方便”。例如，可以用这种方法建模可选的输入符号。

然而，利用新输入符号，还存在用于管理它们的新过程。因此，需要引入∈-closure（∈-闭包）以便定义扩展的转移函数。正式地，通过递推定义∈-closure：

基础：状态q处于ENCLOSE(q)中。

归纳：如果状态p处于ENCLOSE(q)并且存在从p到另一状态r的标记为∈的弧,则r是ENCLOSE(q)。因此，ENCLOSE(q)也包含δ(p,∈)中的全部状态。

这意味着状态的ε闭包包含从此状态利用专有地标记为∈的弧到达的全部状态。类似标准NFA，∈-NFA的扩展的转移函数反映自动机在由出自字母表∑的符号构成的串w的输入上做什么。因此，是沿路径到达的状态集合，该路径的标签形成w，其中∈的标签不对w贡献。

用于事实验证的∈-NFA的构造可以使用关于DFA、NFA和∈-NFA的知识，并且可以设计验证事实的自动机。以下归纳证明将构成能够验证事实的∈-NFA。

定理：存在一些验证事实的∈-NFA。

证明：此证明将示出存在能够验证事实的一些∈-NFA。此∈-NFA具有以下特征：

1.刚好一个接受状态。

2.没有到初始状态中的弧。

3.没有出自接受状态的弧。

假定每个事实具有至少一个变元并且存在具有不依赖其他事实的变元的至少一个事实，通过在自动机的输入上的结构归纳完成该证明。

存在两个变元类型：标准变元或依赖事实的变元，该事实的级别低于正在验证的事实的级别。这两个变元类型在图13中示出。图13是两种类型的变元验证的图形表示1300。存在两种类型的变元验证：第一种类型是标准变元而第二种类型是依赖另一事实的变元。假定自动机的基础输入是将要验证的变元。

如果输入是标准变元，则当且仅当变元有效时自动机从第一状态1302去到下一状态1304。另一方面，当且仅当更低级别的事实有效时依赖其他事实的变元才有效。如果无效，则变元也无效。因此，更低级别的事实必须在转移函数中验证。通过图13中的用于有效事实的从状态1308到状态1310的转移的点状边缘示出此事实验证。被打点的边缘的理由是自动机中可能存在多于一个初始状态和多于一个最终状态。

取决于事实的变元的量n存在两个不同情况。图14是事实验证的图形表示1400。对于事实的每个变元存在一个变元验证。

·n=1:如果事实仅具有一个变元，则这个变元被验证。图14中的点状边缘表示在有效变元的输入上的从状态1402到状态1404的转移。因为这是仅有的变元，所以自动机使用∈-转移自发地去到它的终止状态1406。另一方面，如果变元是无效的，则自动机停留在变元验证框的第一状态1402。

·n>1:对于第一变元，自动机表现为第一情况。然而，在验证第一变元之后，自动机使用∈-转移以返回到变元验证框中的第一状态1402以便验证下一变元。

在两个情况中，一旦一个变元是无效的，自动机就卡在非终止状态中的任何一个。随后的变元有效与否没关系，自动机再不能到达它的终止状态。因此，接受状态可以解释为事实验证的成功的指示符。

因为事实由变元的列表构成，所以事实的验证包括此列表的验证。变元可以是必要的或者可选的。在变元可选的情况中，∈-转移跳过该验证。然而，如果需要变元，则存在标准事实(标准转移)的验证或者依赖另一事实的事实的验证(小“事实的验证”框)。一旦一个变元无效，自动机卡在它的状态并且永不再到达终止状态。上面的归纳中构造的完整的∈-NFA在图15中示出。图15是用于验证事实的完全构造的εNFA的图形表示1500。此图示出将事实框的验证1502嵌入变元框1504的列表的验证中。事实框的验证1502包括两个状态1506和1508。虚线表示多于一个初始状态和一个最终状态的可能性。自动机使用∈-转移以返回到状态1510以便验证下一变元。

为了利用给定事实作为自动机的输入来确定自动机的终止状态1512，构造的∈-NFA必须首先转移到相应的DFA。这通过子集构造完成。被假定为子集构造的基础的自动机在图16中示出。图16是用于子集构造的事实验证NFA的图形表示1600。这是与图14中的相同自动机，但是它的状态按字母顺序命名以便唯一地标识它们。

应用子集构造，相应DFA的第一状态是包括∈-NFA的起始状态的状态以及可以从此状态通过∈-转移到达的全部状态的集合。因此，DFA的启动状态的集合包括状态a 1602和状态b 1604。如果输入是有效变元，则∈-NFA从状态b 1604去到状态c 1606。状态b 1604和状态d 1608可以从c 1606通过∈-转移到达。因此，DFA的下一状态包括状态b 1604、c1606和d 1608。从此状态，自动机去到关于任一其他有效变元的输入的相同状态。如果仅存在有效变元，则在验证的结束时，∈-NFA使用最后一个转移去到它的接受状态。因此，DFA的状态{b，c,d}是接受状态。

如果第一变元是无效的，∈-NFA使用它的∈-转移去到状态b。然后，因为如果输入是有效变元则它只得去到状态c，所以它停留在此状态。因此，相应DFA去到作为非接受状态的状态{b}。它停留在此状态，不管以下变元有效与否。如果全部先前的变元已经有效而下一变元无效，则∈-NFA停留在状态b。因此，DFA再次从{a,b}1706去到状态{b}1704。从而，在无效变元的输入上事实变得无效，不管它是第一变元还是任何其他变元。构造的DFA在图17中示出。图17是通过子集构造创建的事实验证DFA的图形表示1700。如果事实仅由有效变元构成则自动机完成在{b,c,d}1702中的事实验证，或者如果存在至少一个无效的变元，则在{b}1704中完成。

在构造出自∈-NFA的DFA之后的扩展的转移函数，问题是两个自动机在事实验证方面是否等效。验证DFA接受具有至少一个变元的事实，正如∈-NFA一样。两个自动机的事实验证的成功由它们在其中完成它们的验证的状态表示。然而哪个状态是给定变元的这个最后的状态？为了确定自动机在其中完成验证的状态，必须使用扩展的转移函数。不同于处理串的通常的DFA，验证DFA处理数据记录事实。然而，通过使用一个事实而不是使用串以及使用变元而不是符号来类似地定义扩展的转移函数

基础：当自动机没有启动验证时,即,不存在将要验证的事实时，它停留在状态q，状态q是它此时处于的状态：

归纳：如果存在事实f(a₁，.::,a_n-1,,a_n)，其中a₁，:::,a_n-1,a_n是事实的变元，其中n≥1，则：

这意味着，为了确定首先确定在处理全部变元直到a_n-1之后自动机处于的状态

假定此状态称作p，则：

因此，描述在利用变元a_n从p转移之后自动机处于的状态。这导致

从而，扩展的转移函数被定义为

其意味着为了确定验证事实的自动机的最后一个状态，必须首先确定在事实的倒数第二个变元的验证之后自动机处于的状态。

在扩展的转移函数的定义之后的验证DFA和∈-NFA等效，现在可以证明DFA和∈-NFA的等效。因此，它必须示出两个自动机接受相同语言。

证明。令E=(Q_E;f，δ_E;a;F_E)是∈-NFA并且D=(Q_D;f，δ_D;a;F_D)是DFA，Q_D是通过子集构造产生的DFA的起始状态。假定对于DFA，L=L(D)而且对于∈-NFA，L=L(E)，可以示出

L(D)=L(E).

这通过示出两个自动机的扩展的转移函数对于事实f(a1,a2,...，a_n)的输入是相同的来完成：

注意符号a表示∈-NFA的起始状态。假定由至少一个变元a_i构成f并且此变元可以是有效(其表示为a_valid)或者无效的(a_invalid)，通过关于变元的数量的归纳示出自动机的等效。

基础：首先，假定输入具有一个单变量的事实。取决于变元的有效性，验证将成功或不成功：

1.如果变元有效，则∈-NFA从b(使用∈-转移从a去到b)去到c。从那里，∈-NFA也可以使用它的∈转移去到b和d。因为假定仅存在一个输入变元，所以∈-NFA将在d完成有效事实的验证。DFA关于有效变元的输入去到{b，c，d}。两个自动机在其中完成验证的两个状态二者都是接受状态，因此验证成功。

2.然而，如果输入变元无效，则停留在它的非接受状态b，它使用∈-转移从a去到b。DFA去到{b}。两个自动机在非接受状态完成验证，从而验证不成功并且事实无效。

在两个情况中，两个自动机的验证结果相同。因此，对于具有单个变元的事实的输入，自动机等效。

归纳：假定输入具有多于一个变量的事实。可能发生事实的有效变元和无效变元的不同星座图：

1.第一变元无效，后面是多个有效变元或无效变元：在这种情况下，后面的变元有效与否没关系。∈-NFA卡住并且停止事实的验证，同时DFA停留在{b}。

2.第一变元有效，后面是一个或多个有效变元：如果事实的全部变元有效，则∈-NFA将始终使用用于变元验证的从b到c的转移。只要存在将要验证的更多变元，它使用从c回到b的∈-转移。如果不存在更多变元，则它自发地去到它的接受状态d。关于在任何数量的有效变元的输入，DFA停留在它的接受状态{b，c，d}。

3.第一变元有效，后面是无效变元：在这种情况下，∈-NFA停留在非接受状态b而DFA停留在它的非接受状态{b}。

4.第一变元有效，第二变元无效，后面得的变元有效或者无效：

如果这个发生，则两个自动机的行为如3所述。

因为在包含多于一个变元的事实的全部情况中，两个自动机以同样的方式行为，所以它们等效。因此，DFA可以用于事实验证。

下面描述实现选择。自动机的实现包括结构方法和面向对象的方法。在结构方法中，自动机的状态实现为整型变量。变量用于保存实际状态。当验证事实时，首先查出实际状态并且取决于实际状态，完成验证。例如，以下示出使用结构验证数据事实的自动机的种类图：

对于每个变元(即，状态)，存在整型常数。实际状态保存在actualState（实际状态）变量中。在goToNextState（去到下一状态）方法中，实现转移函数。

对于数据事实的每个变元，存在通过整型常数表示的一个状态。此刻自动机处于的状态保存在actualState整型变量中。在goToNextState方法中实现转移函数，该goToNextState方法查找实际状态并且取决于该实际状态(和各自的变元)进行相应的转移。如果仅存在具有相同结构(即，谓词)的事实，则此方法工作正常。然而，随着谓词的数目增加，将要保持的自动机的数量也增加。此外，如果事实的变元结构改变，则必须也调节goToNextState方法以便保证正确的变元验证。例如，令不同地验证变元数据和数据事实的来源。如果这两个变元在依赖性的模型中交换，则整个类(包括它的整型常数和转移函数)必须也改变。此外，可以以同样的方式验证许多变元。例如，数据事实的数据、内容类型和来源变元全部是可选的变元而没有特别的限制。然而，因为转移函数依赖变元所以转移函数必须实现三次(每个变元一次)。作为结果，用于此方法的维护工作量非常大。

现在问题是是否存在可以重复使用状态的任何技术以便减少维护工作量和提高易读性。解决这些问题的一个方法是将转移封装到状态中，这是面向对象的方法的主旨。此外，状态可以具有与用于验证的自动机相同的公用接口。因此，当变元应该被验证时，自动机将验证委派给实际状态。就设计模式的术语而言，上下文是FVA并且具体的状态是需要建模验证的全部状态。每个状态的转移函数返回自动机将去到的下一状态。然而，自动机具有去到下一状态的控制，该下一状态可以是或可以不是实际状态“建议”的状态。设计模式的实现的主要优点是提高了可维护性和复用性。特别是对于具有多个具有类似特征(例如，它们的选择性)的变元的依赖性的模型的事实，一个状态实现可以对于具有相同特征的全部变元重复使用，不管它们属于哪个事实。因为面向对象的方法的可维护性和复用性胜过结构方法，所以从现在开始把面向对象的方法作为基础。作为结果，转移函数附属于专用状态。此外，自动机不仅能够验证一个事实类型(即，具有相同谓词的事实)，它还能够验证具有不同谓词的许多事实。

如上所述，每个变元具有告知变元是可选的还是必要的的基数（cardinality）。因此，一个状态的转移函数必须跳过变元的验证。然而，如果变元是必要的，则必须验证它。

如果它是简单的变元，则转移函数仅仅必须检查它是否被指定(即，非空串)。然而，如果变元是指更低级别的事实的URI，则必须也验证此事实。因此，已经实现以下状态：

变元验证：在此状态的转移函数中，根据检查它是否被指定来验证变元。如果变元包含空串，则转移函数返回自动机此刻处于的状态。否则它返回下一状态。

跳过变元验证：此转移函数简单地认识到存在变元但是不验证它。变元是否是空串没关系。因此，此转移函数始终返回下一状态。

特定事实的专用变元的验证：在此转移函数中，存在实现的事实-专用和变元-专用验证。例如，存在仅验证系统事实的名称的一个转移函数，将该系统事实的名称定义为小于255字符长的非空串。

错误状态：此状态表示任何种类的未预料到的输入。例如，当不能找到用于给定事实的事实模型时，自动机的起始状态将是这个状态。如果事实具有比相应的模型更多的变元，则这个状态是自动机的最后的状态。在任何情况下，一旦自动机处于这个状态，事实不能再变得有效。因此，这个状态的转移函数关于任一输入都返回相同状态。

事实验证：这个转移函数是最高级的一个，因为它必须验证实际事实所依赖的全部事实。将在下面更详细地解释这个功能。然而，提到自动机的转移函数时，存在与标准DFA的一些区别，因为验证自动机具有更强大的转移函数。这是自动机接受的语言从正则语言到类型2语言扩展的结果。作为结果，验证自动机的转移函数是必须进行以下步骤的复杂函数：

1.检查变元是否是非空串；

2.跳过变元的验证而什么也不做；

3.完成一些事实-专用和变元-专用验证(例如，检查系统名是否是由不超过255个字符构成的非空串)；

4.验证事实的URI,即,检查相应的更低级别的事实是否存在；以及

5.就一切情况而论，如果验证成功则返回验证自动机的下一状态(参见下面的算法4)，或者如果上述的验证中的任何一个失败则返回错误状态。

虽然转移1到转移3是对变元串的长度的简单的测试，但是转移4是更复杂的因为它包括调用另一FVA。通常，在Java中实现转移函数和它的状态。因此，不只是可以使用各种Java构造，诸如变量说明、条件和循环，并且可以调用其他FVA、RFC或访问SAP系统。这一点以及Java是上下文无关语言的事实导致具有上下文无关特征的自动机。然而，它仍然是接受正则语言的DFA，因为将被使用的Java构造的数目受限于变量说明、条件和有限循环以便保证验证的终止。不应该使用其他构造，因为它们可能不终止。例如，RFC可能卡在远程位置上。从而，将没有答案，并且自动机停留在转移函数中因此停留在它的实际状态中。正是由于RFC失败，所以事实可能被拒绝，即使它可能是正确的。因此，在这个实现中不存在这种“不安全”构造。这个限制保证每个自动机的调用终止。因此，在转移函数中调用另一自动机也不是危险的，只要正确地构造事实模型,即,不存在不同事实模型之间的循环引用。

在一旦被构造就表示事实的依赖性的语义模型中建模全部事实。在图18中示出抽象事实和变元模型。图18是语义模型1800的图解说明。这个类图示出语义模型1800。事实模型由多个变元模型构成。通常，语义模型是域模型的子集，域模型是如上所述的统一模型。更精确地，语义模型是统一模型的EDB(即，外部数据库)表现。

事实模型包含关于事实的谓词和元数的信息。变元模型的列表由变元模型组成，变元模型由名字标识。基数告知变元是可选的(通过值0表示)还是必要的(通过值1表示)。isRef变量告知变元是否依赖包括在参考集合(refSet)中的其他事实。此外，每个事实模型具有指定唯一地标识事实的变元的关键字值。最后，每个事实具有FVA经历的状态的列表(stateList)。

信息是验证专用的，并且因此，想要验证事实的用户必须指定它们。因此，已经开发了外部域特定语言(DSL)。通常，DSL是集中于特定领域的有限表达的计算机程序语言。此外，外部DSL和主程序的语言分离。外部DSL可以具有定制语法或是任一其他语言(经常是XML)。在这种情况下，定制语言被定义。定义文件必须写入DSL以描述语义模型。创建、修改和使用定义文件的处理如上所述。

通常，验证自动机不仅能够验证一个事实；它还能够验证事实的集合。事实上，标准用户还需要除单个事实的验证外的事实的集合的验证，因为需要事实验证的主要理由是事实的依赖性。单个事实的验证主要由自动机自身使用。因此，验证处理被定义为验证自动机验证给定事实集合的处理。

考虑某些准备。例如验证框架的许多组件需要语义模型的创建。因此，当启动验证框架时，解析定义文件并且创建语义模型。如上所述，事实模型不仅包括关于变元的信息，它们还包括自动机将需要的状态列表以便验证特定事实。在算法1中示出状态列表的创建，该创建需要相应的事实模型作为输入以便解决事实的依赖性。算法1是用于确定事实的状态列表的示例算法。

对于全部变元模型，第一步是检查变元是否是可选的(参见行2)。在这种情况下，需要跳过变元的验证。如果变元是必要的，则下一步是检查变元是否涉及其他事实模型(参见行5)。如果没有涉及其他事实，则算法搜索具有专用名称的事实-专用和变元-专用状态。如果存在这种状态，则算法将使用它(行7)。否则，算法将使用用于变元验证的缺省状态(行9)。然而，如果存在对更低级别的事实的依赖性，则添加用于事实验证的状态(行12)。最后，将先前确定和接受的状态添加到状态列表(行15和行17)并且返回该状态列表(行18)。

然后，必须准备自动机。这意味着，在它能够验证事实之前它需要一些的信息。它需要事实将在其中被验证的上下文。通常，事实集合包括可能具有或可能不具有相同谓词的多个事实。如果事实不具有相同谓词，则它们可能彼此依赖。稍后将验证的事实集合是上下文的子集或上下文自身：

例如，令上下文C是由runs_on事实R构成的事实集合，该runs_on事实R具有每个具有相应的数据事实(D_S和D_H)的系统和主事实(S和H)：

C={R,S,H，D_S,D_H}

作为这个上下文的子集的事实集合S₁可以是

S₁={S}

如果全部事实的变元有效，则事实集合S₁也将有效，因为对于系统事实，上下文中存在相应的数据事实。现在，令另一子集S₂是

S₂={R,I}

其中I是流入的配置事实。即使全部事实的变元将是有效的，事实集合S₂也将不是有效的，因为不存在与流入的配置的configURI匹配的数据事实DI。令最后的事实集合S₃是

S₃={R,S,H，D_S,D_H}=C

事实集合S₃将是有效的，因为在事实集合自身中存在相应的更低级别的事实。因此，自动机不仅能够在上下文中验证事实的集合，而且它还能够验证整个上下文。

在验证事实集合中，可能存在依赖上下文中的其他事实的大量事实。作为结果，存在不同策略来验证事实。第一可能方法是随机算法，在该随机算法中当事实从将要验证的事实的集合取出之时验证事实。然而，存在两种其他方法，这两种其他方法使用事实在依赖性层级中的级别来确定验证次序。级别的计算是应用在事实模型上的递归函数(参见算法2)。算法2是用于确定事实模型的级别的示例算法。

默认级别是0(行1)。为了计算事实模型的级别，将实际事实模型依赖的每个事实模型的级别加1(行9)。然后，总和与到目前为止找到的最高级别相比。如果总和高于找到的最高级别，则它被认为是新级别(行11)。在迭代通过全部事实模型之后，返回计算的级别(行18)。计算的级别可以用于两种不同的验证方法。可以首先验证更高级别的事实。这称作自顶向下方法。

当验证更高级别的事实时，在依赖的事实的期间，验证更高级别的事实所依赖的事实。例如，在系统事实的验证期间，必须检查是否存在相应的数据事实。在这个测试期间，调用验证数据事实的自动机。它验证相应的数据事实，并且如果数据事实有效则向父(系统)自动机返回下一状态。因此，在更高级别的事实的验证期间，大部分更低级别的事实被验证。与此相反，存在首先验证更低级别的的事实的自底向上法。因此，当验证更高级别的事实时，不必再次验证它们依赖的事实。更高级别的事实所依赖的事实将被跳过。

如果预期自顶向下和自底向上法被有效地使用，则必须使用共享存储器。图19是共享存储器1902的示例实现1900示意性表示。除放置无效事实的局部存储器1906之外，每个FVA(例如，FVA1 1904)使用共享存储器1902的一部分以在其中放置有效事实。这些地点也可以由多于一个自动机使用。实现的共享存储器便于存储已经被验证的全部事实。因此，每个FVA需要它预期使用的共享存储器1902的部分的ID。这使它能将全部有效事实放置到共享存储器1902的这个部分中。当预期更低级别的、已经验证的事实中的任何一个被再次验证时，自动机可以跳过这个验证。因此，任何调用子自动机的时候，子自动机都得到共享存储器1902部分的ID作为输入。作为结果，它还将全部有效事实置于父自动机使用的共享存储器1902的相同部分中。这便于不同自动机之间分配的事实验证。此外，每个自动机具有局部存储器1906，自动机将没有被成功地验证的全部事实放置在局部存储器1906中。作为结果，当预期再次验证无效事实时，自动机可以跳过验证，因为它已经“知道”这个事实是无效的。

一旦自动机已经获得它需要的全部信息，它可以开始验证事实的集合。如上所述，它使用给定方法完成验证。该方法确定用于验证的次序，并且自动机将按该方法定义的次序一个接一个地验证事实。然而，在可以启动实际验证之前，必须完成一些预处理(参见算法3)，其检查是否满足需要验证事实的全部条件。

算法3是用于事实验证的预处理的示例算法。在开始时，自动机检查是否因为实际事实包含在共享存储器中从而已经在之前被验证而可以跳过实际事实的验证(行2)。如果情况不是这样，则自动机确保：

·之前事实没有被标记为无效；

·存在与该事实具有相同谓词的事实模型；

·该事实具有至少一个变元；以及

·事实的数量等于它的变元的数目。

在算法3的行5中示出这个错误检查。最后的步骤是确定(行8)和设置(行9)自动机的起始状态。起始状态的确定在算法4中示出。

算法4是确定用于自动机的下一状态的示例算法。通常，对于变元列表中具有索引i的每个变元a_i，存在包括相应转移函数的、状态列表中的状态S_j，以使得i=j。这意味着为了获得包括验证下一变元的转移函数的状态，返回状态S_j=I+1(行3)，其索引比实际变元的索引高一个。如果不存在用于变元a_i的最终状态状态S_j以使得i=j，则这意味着事实具有比相应的事实模型更多的变元或者自动机已经处于它的最终状态从而不期待更多的变元。因此，返回错误状态(行5)。对于特定事实的起始状态的确定，假定，只要没有变元仍未验证，实际变元的索引就是-1。在这种情况下，“下一”状态是自动机的起始状态。

在确定起始状态之后，可以启动实际事实验证。它在算法5中示出。算法5是用于事实的验证的示例算法。对于事实的每个变元，调用实际状态的转移函数(行3)。它将依赖验证成功而返回状态。如果这个返回状态是自动机此刻处于的相同状态，则变元的验证不成功。然后，因为如果一个变元无效则事实不能再变得有效，所以变元上的循环停止(行5)。否则，实际状态被设置为通过实际状态返回的状态(行7)。

在验证事实之后(其意味着要么全部变元有效要么因为一个变元无效而停止验证)，存在一些后处理。它主要包括设置变量，该变量跟踪事实集合的验证的成功。在算法6中示出后处理。

算法6是用于事实验证后处理的示例算法。如果自动机的实际状态是它的接受状态，则事实的验证成功。如果是的话，并且如果该有效事实是已经验证的第一事实，则成功变量被设置为真(行3)。注意仅对第一事实这样做，因为成功变量的缺省值是假。这样做的理由是如果仍没有事实已经验证，则验证不能成功。此外，当且仅当验证成功时事实添加到包含全部有效事实的共享存储器(行5)。然而，如果事实无效，则成功变量被设置为假(行7)并且事实添加到无效事实的局部集合(行8)。

到目前为止讨论的是FVA的分级调用，负责实际事实依赖的更低级别的事实的验证的转移函数还没有讨论。然而，如上所述，当其他自动机被调用之时这个转移函数不同于其他转移函数。在算法7中示出事实验证转移函数。

算法7是用于事实验证转移函数的示例算法。首先，用于局部FVA的上下文被定义为父FVA验证的事实集合、父FVA的上下文和共享存储器的联合(行1)，该共享存储器包含已经通过父FVA验证的全部事实。父FVA是自动机，该自动机的转移函数调用另一自动机(在这种情况下局部FVA)。然后，确定实际变元依赖的全部更低级别的事实(行2)，其在算法8中示出。

算法8是用于确定变元的依赖性事实的示例算法。在实际变元模型的确定(行1)之后，对于变元模型依赖的全部事实模型，具有相同谓词的上下文中的全部事实添加到预期依赖性事实的集合(行3)。这意味着，稍后验证实际事实可能依赖的全部事实(算法7，行3)。

因为如果事实已经被验证则验证被跳过，所以现在的过程类似于通用的事实验证(算法5)。在这种情况下，父自动机的下一状态添加到返回状态列表(算法7，行5)，其收集全部局部FVA的返回状态以便确定最终的返回状态。

如果事实仍没有验证，则调用局部FVA以执行验证(行7)。如果验证成功，则事实添加到共享存储器并且下一状态添加到返回状态集合(行9和行10)。然而，如果更低级别的事实无效，则它添加到局部FVA的无效事实集合并且实际事实添加到父FVA的无效事实集合(行12)。此外，实际状态添加到预期返回状态的集合(行13)。最后，确定出自预期返回状态集合的返回状态(行17)。这在算法9中示出。

算法9是确定用于事实验证转移函数的返回状态的示例算法。如果返回状态集合仅包含一个状态，则返回此状态(行2)。如果在预期返回状态的集合中存在更多的状态，则如果在集合中存在一个错误状态则返回错误状态(行4)，因为如果发生在集合中存在一个错误，则在局部FVA的验证期间发生错误。然而，如果集合包含实际状态，则返回实际状态(行6)因为这意味着更低级别的事实无效。如果没有发生提到的情况，则返回任一状态(行8)。然后，父FVA可以继续它的验证处理。

可以描述编程模型的定义，该编程模型具有用于可以在自动机上运行的验证程序的语义模型。编程模型在图20中示出。图20是用于自动机2002的示例编程模型2000的图形表示。自动机2002得到事实2008和定义文件2006作为输入。使用定义文件2006建立语义模型2004。使用这个模型，自动机2002能够验证事实的集合。输出实现为文本记录2010和点图2012。

首先，存在可能通过或可能不通过验证框架预处理的输入的集合。定义文件用于创建语义模型。它由验证给定事实的自动机使用。在验证的结束，存在可以用于诊断（diagnose）验证的结果的一些输出。

如上所述，写入外部域专用语言的定义文件用于创建语义模型。因此，必须在设计时在定义文件中描述该模型。这意味着用户指定事实、事实的谓词、变元和它们之间的关系。通过以下语法定义编写定义文件的语言：

<fact predicate>[<key index>]:<argument list>.

（<事实谓词>[<关键字索引>]:<变元列表>.）关键字索引是指示唯一地标识事实的变元列表中的变元的索引的整数值。因此，大多数情况下，这将是URI。关键字索引是可选的值，因为存在不具有单关键字变元的事实，例如runs_on事实，其仅可以由两个变元（systemURI和hostURI）唯一的标识。事实的关键字索引写入方括弧中([])。此外，变元列表中的变元通过逗号(，)分离。一个变元的定义显示如下：

<argument name>({<fact predicates that the argument depends on>},<cardinality>)

（<变元名称>({<变元依赖的事实谓词>},<基数>）

如果变元依赖多于一个事实，则更低级别的事实的谓词通过逗号(，)分离。在一个事实的定义之后，存在标记事实定义的结束的点(.)。然后可以在下一行中定义下一事实。可以使用序数符号(#)包括注解。在列表1中示出来自定义文件的摘录。

列表1是来自定义文件的示例摘录。列表1示出data_discx和system_discx事实的定义，以及两个注解。在第一行中，存在注解，该注解示出将跟随的一些级别0事实的定义。在第二行中，定义data_discx事实。它的关键字变元是URI，其它三个变元是可选的。此外，没有变元依赖其他事实。在下一行中，存在另一注解，跟随该注解的是最后行中的system_discx事实的定义。这个事实的名称不是可选的，因为基数是1，而描述是可选的。作为变元列表的索引2处的systemURI的最后一个变元是必要的变元，其依赖有效的和匹配的data_discx事实。

在事实和变元模型的定义期间，可能存在需要还没有被实现的专用的验证过程的变元。例如，用户可能不仅想要系统名为非空串，他可能还想要它小于255个字符长。因此，必须实现新转移函数(并且从而实现新状态)。这种新状态必须遵循严格的名称方案以便被找到并且由验证框架使用。一个状态是使用以下方案命名的Java类：

Validate<fact predicate><argument name>（验证<事实谓词><变元名称>）名称利用文字“Validate（验证）”开始，Validate后面是事实谓词以及此状态用于的变元的名称。例如，用于验证系统名的状态的名称应该是

ValidateSystem_discxName很重要的是事实谓词和变元名称是在定义文件中定义的那些。在上面的示例中，事实谓词和变元名称的第一字母是大写的。理由是更好的易读性。然而，验证框架还将标识小写字母谓词和名称。

验证程序可以被记录并且用于(在特定实施例中，实时的)调试目的。当完成验证时，验证的结果是成功或不成功。为了分析验证结果，自动机便于记录它做了什么。可以记录以下事件：

1.事实的集合的验证的开始；

2.事实的验证的开始；

3.变元的验证的开始；

4.变元的验证的结束；

5.事实的验证的结束；

6.事实的集合的验证的结束；以及

7.例外的发生。

如果上述的事件中的任何一个发生，则自动机调用它的记录器，其是访客设计模式的实现并且记录事件。因为记录器具有到自动机的参考，所以它可以访问需要的全部信息而以用户想要输出的方式产生有用的记录。

存在两个类型的记录输出：文本和图形。文本输出是自动机此刻做什么的描述,即,它刚完成的验证的部分。例如，当自动机验证一个数据事实时，输出将看起来像在列表2中示出的输出。

列表2是用于有效数据事实的自动机的示例文本输出。记录器记录自动机的启动、数据事实的验证、变元的验证的启动以及事实和自动机的结束。它还记录一个事实以及全部事实的验证成功与否。

首先，记录器记录自动机的启动以及多少事实处于将要验证的事实集合中。然后它记录数据事实的验证的启动。接下来，它记录变元的验证以及它们的成功。此后，它记录数据事实的验证的结束以及它是否有效。在验证全部事实之后，它记录自动机的结束以及整体验证的状态,即,全部事实是否有效。

记录的第二方式是图形输出，其使用点图实现。通常，点用于“按层级绘画有向图”。因此，它读取包含以特定格式的图形的描述的文本文件，并且以不同的图形格式创建图。列表3示出包含用于有效数据事实的点图的示例描述的文本文件。

列表3是用于有效数据事实的点图的示例描述。列表3包括以点描述的FVA的状态和转移。在行1中的有向图G（digraph G）是指图形G被认为是有向图。大括弧正如任一程序语言中一样，用于标记图形的哪个部分合成整体。在行2中，rankdir=LR;期望图形从左至右绘画。分号用于结束指令，其也类似于一些编程语言(例如，Java)。行3中的子图（subgraph）表示主图形之内的节点和边的新子集的创建。为了命名子图，使用命令标签=“[...]“;。作为结果，实体不标有它的唯一的名称，而是标有指定的标签。不同于图、子图或节点的唯一名称，标签不必是唯一的。例如，子图的标签定义在行4中。为了向子图分配节点，节点的唯一的名称必须写入子图的主体中。类似于子图，节点也可以被标记。在列表3中，存在分配给子图的五个节点。对于记录，每个节点表示自动机处于的一个状态。边表示自动机的转移。在点图的文本描述中，边定义在主图的末尾。为了定义两个节点之间的有向边，第一节点必须在行开始时写下，后面是箭头符号(→)。在行的末尾，存在有向边去到的节点，后面是用于完结命令的分号。例如，自动机的第一状态和第二状态之间的边在行12中定义。在验证数据事实的变元之后，自动机去到下一状态(SkipArgumentValidation)，因此这两个状态通过箭头连接。

为了查看图形而不仅仅是图形的描述，必须使用图形可视化软件，例如dotty，其是包括在开源软件Graphviz 1中的点图视图。出自定义在列表3中的点图的图形示出在图21中。图21是用于示例数据事实的图形输出2100。对于数据事实的验证，自动机首先必须验证dataURI然后跳过三个可选的变元的验证。如果在这些验证期间没有错误发生，则利用重叠正方形表示最终状态。

用于点图的文本描述(列表3)的行3中的数据事实的子图的标签是图的顶部的标签。它包含已经验证的事实。在验证期间自动机经过的状态通过点图的节点表示。当数据事实具有URI、数据变元、内容类型和来源时，URI已经被首先验证。因此，第一节点称作ValidateArgument（有效变元）。在自动机已经完成URI的验证之后通过记录器记录这个状态。自动机的接下来三个变元是可选的，因此可以跳过验证。在跳过变元的验证之后，记录相应状态。一旦自动机已经完成事实的验证，它调用记录这个事件的记录器。图形记录器分析自动机是否已经成功地验证事实。如果是的话，利用重叠正方形表示最终状态。如果在验证事实之后自动机处于的状态不是它的接受状态，则利用重叠三角形表示状态。因此便于使用点图来确定验证是否成功。如果将要验证的事实是级别高于零的事实，则可能在验证变元的转移函数中存在自动机的调用，该变元是另一事实的关键字。在这种情况下，利用实线箭头示出自动机走的“路径”。利用虚线箭头给出如果不存在另一自动机的调用则自动机将走的路径。例如，令存在runs_on事实和相应的系统和主事实，每个具有相应的数据事实。通常，在这种情况下，点图还示出被调用的自动机。如果预期再次验证有效的更低级别的事实，则自动机将跳过验证并且点图将示出仅具有一个状态的自动机：接受状态(AllArgumentsValidated（所有变元被验证）)。

不仅自动机在事实的集合中找到无效事实是重要的，找出事实无效的原因也是有意义的。因此，每当自动机验证事实的集合时，它记录单个事实或变元。到目前为止，验证自动机具有两个不同的可能性来记录它做了什么：记录的一个方式是通过写入它此刻完成什么的简短描述的文本，另一个是通过输出点图的图形。为了调试自动机，两个输出可以组合以便找到关于将要验证的事实的问题。为了创建有用的图形输出，在全部情况中，使用自顶向下方法。

假设存在试图创建将要插入到知识库中的runs_on事实的用户。用户通过键入谓词和systemURI变元来启动创建runs_on事实。然后他认识到也必须创建系统事实；因此，他停止对runs_on事实的工作并且代之以启动对系统事实的工作。他已经从另一个地方复制系统名“HXPCLNT001”并且将它粘贴到他的文本编辑器中。然而，用户可能“意外地”击中粘贴按钮47次。这就是为什么系统名变元包括系统名47次。用户还键入系统的描述和URI。在列表4中示出最终的文件。注意，由于易读性，仅示出系统名的一部分。

列表4是用于利用无效的系统事实的runs_on事实的示例定义文件。存在具有名称太长的相应的系统的runs_on事实。从而，它无效，这使得runs_on事实也无效。用户然后启动文件的验证。自动机已经记录了显示在图21中的点图。在图21中示出三个事实。首先，存在具有单个状态的runs_on事实2102，该状态是验证自动机的起始状态。出自这个状态，存在朝向被调用的自动机的起始状态的有向边，调用该自动机以便验证相应的系统事实2104。这意味着自动机找到相应的系统事实。然而，在这个示例中，当它试图验证系统的名称时，出现错误。因为用户没有意识到无效的系统名是验证失败的理由，所以用户查看对于这个验证的文本输出(参见列表5)。

列表5是用于利用无效的系统事实的runs_on事实的自动机的示例文本输出。自动机意识到系统的名称无效，从而事实无效。因此，runs_on事实也无效。根据记录说明，验证失败的理由是系统的名称超过允许长度。

因此，也已经分析了自动机的输出的用户通过改变系统名来在描述文件中改正他的错误。用户还可能忘记添加用于改正的系统事实的数据事实，他或她将校正该数据事实。改正的描述文件在列表6中示出。列表6是用于具有相应的系统事实而没有数据事实的runs_on事实的示例定义文件。

然而，这次，当他添加data_disc的URI时出错,因为他意外地键入2而不是1作为URI的最后一个字符。

这个定义文件的验证的图形输出在图22中示出。图22是用于runs_on事实的示例自动机的图形输出2200，该runs_on事实的相应系统事实2204没有相应的数据事实。即使存在有效数据事实2206，验证系统事实2204的自动机也不能找到匹配的数据事实。然而，这个数据事实的URI不同于systemURI，从而验证不成功。对图21类似，自动机从runs_on事实2202的验证开始。在这个验证期间，它调用负责相应的系统事实的验证的另一自动机。这个自动机成功地通过验证系统名的状态，从而系统名的改正成功。然而，这次，自动机不能找到与系统事实2204具有相同URI的数据事实，这被显示为自动机被卡在ValidateFact状态2208。

事实上，这个事实集合中存在数据事实并且它也已经(成功地)验证；然而，它的URI不同于系统事实的URI。因此，自动机找不到两个事实之间的关系。这也通过文本记录指示。这还通过列表7中所示的文本记录指示。

列表7是用于利用无效的系统事实的runs_on事实的自动机的示例文本输出。问题是相应的系统事实没有匹配的数据事实。仅存在一个数据事实，但是它具有与系统不同的URI，因为URI的最后一个字符不同。文本输出的一个相关的部分是以下中的一个(列表7中的行6)：

system_discx:Could not find a valid data_discx with the samekeysystemURI（不能找到具有相同的关键字systemURI的有效的data_discx）:com.sap.bnm.nd.discovery.ale.facts.internal.AleFactsProviderHXPCLNT001).

它示出自动机不能找到具有相同URI的数据事实。这是验证失败的原因。再次，用户意识到他的错误并且改变数据事实的URI以匹配系统事实。再次，他让自动机验证事实。在图23中示出图形输出。图23是用于runs_on事实2302的示例自动机的图形输出2300，该runs_on事实2302的hostURI没有被指定。在成功地验证匹配runs_on事实2302的systemURI的系统事实2304之后，自动机不能验证实际上未指定的hostURI。因此，自动机停留在(非最终的)状态ValidateFact（验证事实）。跟随图形中的有向边，自动机启动runs_on事实2302的验证。接下来，它调用另一自动机以验证系统事实和它的相应的数据事实。因为这些验证成功，所以控制返回到主自动机，该主自动机最终试着去验证hostURI。显然，自动机卡在这个状态。文本输出可以告知问题与hostURI有关。在列表8中示出完整的输出。

列表8是用于无效的runs_on事实的自动机的示例文本输出。问题是未指定hostURI。自动机能够验证匹配的系统事实。当自动机试图验证runs_on事实的hostURI时，自动机意识到hostURI包含空串。因此，验证失败。记录的最重要的部分显示如下(列表8中的行17)：

runs_on_discx:No hostURI specified（未指定hostURI）.

使用这个输出，用户通过将hostURI添加到runs_on事实中来改变他的定义文件。当他这样做时，他意识到他仍没有创建主事实。为了防止他自己再次做出相同错误，他还创建主事实和它的相应的数据事实。然后定义文件看起来如列表9所示。列表9是用于有效的runs_on事实的示例定义文件。存在具有每个具有匹配的数据事实的相应的系统和主事实的runs_on事实。

通过自动机的记录器产生的点图在图24中示出。图24是用于有效runs_on事实2402的示例自动机的图形输出2400。runs_on 2402、系统2404和数据2406事实的验证全部成功，从而利用重叠正方形表示全部最终状态。在这个图形中，利用重叠正方形表示全部自动机的最终状态，其意味着全部事实有效。列表10是用于有效runs_on事实的自动机的示例文本输出。文本输出的最终消息(列表10中的行45)如下：

Validation Successful(验证成功）

因为全部事实有效，所以事实集合的验证成功。因此，用户能够插入他创建的事实。

通常，如果事实集合非常小(如在上面的示例中)，一个好主意是首先查看点图以便得到验证的概要。如果存在标记为红色的任一状态，则因为文本记录给出错误的更详细描述所以文本记录是有用的。如果存在更大的事实集合，则最好首先查看文本输出的最后的行。它将告知事实集合的验证是否成功。如果不成功，则图形输出帮助找到验证自动机卡在的状态。如果这个信息也没有帮助，则还存在包含每个变元的验证的成功的信息的详细的文本记录。因此，图形和文本输出的组合可以用于调试自动机并因此找到验证的可能失败的理由。

图25是用于知识的基于内容的验证的示例系统级系统2500的示意性表示。图25示出示例交易环境系统2500。系统2500可以包括市场管理环境。在一个实施例中，系统2500可以包括耦接到诸如零售商、供应商、顾客、银行等等的一个或多个客户端2502的服务器2504，所述客户端中的至少一些通过网络2530通信。客户端2502包括可操作以接收、发送、处理和存储与系统2500关联的数据的电子计算设备。将理解，图25仅提供可以使用本公开的计算机的一个示例，因而，每个示出的计算机通常预期包含任一合适的处理设备。例如，虽然图25示出一个服务器2504，但是系统2500可以使用除服务器，以及服务器池以外的计算机实现。实际上，系统2500可以是任一计算机或处理设备，诸如，例如，刀片服务器、通用个人计算机(PC)、Macintosh，工作站、基于Unix的计算机或任何其他合适的设备。换句话说，除了通用计算机以外，本公开还设想包括没有传统操作系统的计算机的计算机。系统2500可以被适配为运行包括Linux、UNIX、Windows服务器或任何其他合适的操作系统的任何操作系统。根据一个实施例，系统2500还可以包括网络服务器和/或邮件服务器、或可通信地与网络服务器和/或邮件服务器耦接。

如所示，系统2500可以可通信地与远程储存库2506耦接。储存库2506可以包括形成用于系统2500的存储中枢（backbone）的一个或多个永久存储设备(例如，硬盘驱动器等等)。储存库2506可以包括任何企业内、企业间、地区、全国性的或实质上全国的电子存储设备、数据处理中心或档案。在另一实施例中，储存库2506可以包括经由直接连接来内部地或外部地耦接到系统2500的一个或多个硬盘驱动器、半导体存储器等等，所述直接连接是诸如集成驱动器电子电路(IDE)连接、小型计算机系统接口(SCSI)连接、串行ATA(SATA)连接或其他合适的可通信的连接。

储存库2506可以是经由虚拟专用网络(VPN)、安全(SSH)隧道或其他安全网络连接通信地耦接到系统2500的中央数据库。储存库2506可以物理地或逻辑地位于包括在示例企业或离岸（off–shore）中的一个的任何合适的位置，只要该位置保持可操作以存储与系统2500关联的信息并且向系统2500通信诸如数据。例如，储存库2506可以包括数据存储器或仓库。

储存库2506允许系统2500和/或一个或多个交易参与者动态地存储指令2505或事实2507并从储存库2506检索指令2505或事实2507。例如，指令2505可以包括当由系统2500运行时从语义模型2512生成验证程序的代码。指令2505可以包括通过网络2530可在网络上运行的代码(例如，java代码)。例如，客户端系统2502可以通过网络2530运行来自指令2505的代码。可以生成可以经历验证的事实2507。储存库2506可以是基于云的存储器。它可以是在网络2530上访问的分布式存储器。储存库2506可以是共享存储器，像图19中示出的那样。

视情况而定，指令2505可以包括软件、固件、有线或编程的硬件、或其任何组合。实际上，可以以任何合适的计算机语言编写或描述指令140，所述计算机语言包括C、C++、Java、J#、Visual Basic、汇编程序、Perl、4GL的任何合适版本，以及其他。例如，指令140可以实现为可以具有在不同的平台中生成运行时实现的能力的企业Java Beans(“EJB”)或设计时组件，不同的平台是诸如J2EE(Java 2平台，企业版本)、ABAP(高级企业应用程序)对象或微软的.NET等。此外，虽然与指令关联的一个或多个处理示出为处于储存库2506和/或系统2500的内部，但是它们可以远程地存储、参考或运行。例如，指令2505的一部分可以创建(例如，由零售商系统)远程调用的网络服务，而指令2505的另一部分可以是用于在客户端(例如，交易参与者之一)处进行处理的打包的接口对象。在另一示例中，大部分指令还可以驻留（或它们的处理发生）在交易参与者之一上。此外，指令2505可以是另一软件模块或企业应用(未示出)的子模块或次模块而不脱离此公开的范围。

储存库2506还可以存储事实2510。事实2510可以包括涉及交易参与者的任何业务、企业、应用或其他交易数据和元数据。例如，如上所述，事实2510可以包括购买历史、购买倾向信息、主目录中的条目、业务简档、其他业务属性和/或业务率，以及其他合适的市场相关数据。因而，系统2500可以在储存库2506中挖掘交易参与者之间使用的标识匹配(即，新潜在关系)所需要的信息。

系统2500还可以包括处理器2508。处理器2508运行指令并操纵数据以执行系统2500的操作。在各自个配置中，例如，处理器2508可以是中央处理单元(“CPU”)、刀片服务器（blade）、专用集成电路(“ASIC”)、现场可编程逻辑门阵列(“FPGA”)、或其他合适的逻辑装置。虽然图25示出系统2500中的单个处理器2508，但是可以根据特定需要使用多处理器并且参照处理器2508意味着包括可应用的多处理器。

系统2500还包括本地存储器2511。如所示，存储器2511可以包括指令2512和事实2510，每个可以是指令2505和事实2507的子集。如本领域技术人员理解地，在由处理器2508运行或操纵之前，指令2512和事实2510可以被复制到存储器。存储器2511可以包括任何存储器或其他计算机可读存储模块，并且可以采取易失性或非易失性存储器的形式，包括，但不限于，磁介质、光学介质、随机存取存储器(“RAM”)、只读存储器(“ROM”)、可移除的介质或任何其他合适的本地或远程存储器组件。存储器2511可以内部地或从外部耦接到系统2500。

系统2500还可以包括用于通过网络2530与诸如其他交易参与者的其他计算机系统通信的接口2514。在特定实施例中，系统2500通过接口2514从内部或外部发送器接收数据，用于存储在存储器2511中、用于存储在储存库2506中和/或用于由处理器2508处理。通常，接口2514包括在软件和/或硬件的合适组合中编码的逻辑，并且可操作以与网络2530通信。更具体地，接口2514可以包括支持与网络2530关联的一个或多个通信协议的软件或可操作以通信传递物理的信号的硬件。

网络2530简化系统2500和诸如交易参与者的任何其他本地或远程计算机之间的无线或有线通信。网络2530可以是企业或安全网络的全部或一部分。在另一示例中，网络2530可以是通过线路或无线链路仅在一个或多个交易参与者之间的VPN。这样的示例无线链路可以是通过802.11a、802.11b、802.11g、802.11n、802.20、WiMax和许多其他的无线链路。虽然示出为单个或连续网络，但是网络2530可以在逻辑上被划分成多个子网或虚拟网络而不脱离此公开的范围，只要至少部分网络2530可以便于系统2500和至少一个交易参与者之间的通信。

网络2530包含可操作以便于系统2500中的多个计算组件之间的通信的任何内部或外部网络、网络、子网络或其组合。例如，网络2530可以在网络地址之间传递互联网协议(“IP”)分组、帧中继帧、异步传输模式(“ATM”)信元、语音、视频、数据、和其它合适的信息。网络2530可以包括一个或多个局域网(“LANs”)、射频接入网络(“RAN”)、城域网(“MAN”)、广域网(“WAN”)、被称为互联网的全局计算机网络的全部或一部分、和/或在一个或多个位置的任何其他通信系统或多个系统。在特定实施例中，网络2530可以是与企业和特定本地或远程客户端关联的安全网络。

客户端2502可以包括可操作以使用任何通信链路连接或与系统2500或网络2530通信的任何计算设备。在高级别中，每个交易参与者可以包括或运行至少图形用户界面(“GUI”)2516并包括可操作以接收、发送、处理和存储与系统2500关联的任何合适的数据的电子计算设备。为了便于说明，按照由一个用户使用来描述每个交易参与者。但是此公开设想许多用户可以使用一个计算机或一个用户可以使用多个计算机。在特定情境中，用户可以包括自己、会计员，以及第三方或外部会计师。

GUI 2516包括可操作以允许客户端2502的用户与至少一部分系统2500接口连接的图形用户界面，用于任何合适的目的，诸如查看应用或其他交易数据。通常，GUI 2516向特定用户提供由系统2500提供的或在系统之内传递的数据的有效的和用户友好的呈现。GUI 2516可以包括多个可定制的帧或具有交互的字段、下拉列表和由用户操作的按钮的视图。例如，GUI 2516可被操作以显示某些元素，诸如验证处理的图形和/或文本输出。GUI2516还可以呈现多个端口或仪表盘。例如，GUI 2516可以显示允许用户查看、创建和管理验证程序建模和验证调试的端口。然而，将理解，GUI 2516设想任何图形用户界面，诸如在系统2500中处理信息并向用户有效地呈现结果的通用网络浏览器或触摸屏。GUI 2516可以经由网络浏览器(例如，微软因特网浏览器或网景Navigator)从系统2500或交易参与者接受数据并使用网络2530返回合适的HTML或XML响应。

图26是用于验证事实的处理流程图2600。可以标识用于验证的事实(2602)。可以创建表示事实的语义模型(2604)。可以标识与事实关联的上下文(2606)。可以从语义模型生成验证程序，语义模型以领域专用语言(2608)。在运行时从语义模型便于自动机的生成的验证程序验证事实(2610)。可以输出验证的图形和/或文本记录(2612)。图形和/或文本记录可以用于实时调试(2614)。

已经描述了本发明的大量实施例。然而，应当理解，在不脱离本发明的精神和范围的情况下可以做出各种修改。例如，可以使用不同于统一的模型的目标模型。可以使用其它运行时/验证程序实体。即，可以使用SAT解算器或其他基于非自动机的实现。此外，设想定义自动机的其他方式。例如，自动机可以是非嵌入的，诸如链路自动机。不同的输出方法可以用于调试处理。还设想与外部DSL不同的表示验证程序的方式，诸如内部DSL和流畅API。此外，本公开设想单独拥有的语义模型。因此，其它实施例也在以下权利要求的范围之内。

Claims (19)

1.一种用于知识验证的计算机实现的方法，所述方法包括：

标识用于验证的事实；

创建语义模型，该语义模型表示用于验证的事实；

标识与事实关联的上下文；

至少部分地基于标识的上下文创建自动机；以及

使用自动机验证事实。

2.如权利要求1所述的计算机实现的方法，还包括标识统一的模型，该统一的模型包括关于公司之内和公司之间的业务交易网络的信息，用于验证的事实与统一的模型相关联。

3.如权利要求1所述的计算机实现的方法，其中所述自动机是确定性有限自动机。

4.如权利要求3所述的计算机实现的方法，其中所述确定性有限自动机源自于ε非确定性有限自动机ε-NFA，所述ε-NFA为：

ε-NFA＝(Q；∑；δ；q₀；F)。

5.如权利要求3所述的计算机实现的方法，其中所述确定性有限自动机通过状态、输入符号、转移函数、启动状态和最终状态中的一个或多个定义。

6.如权利要求5所述的计算机实现的方法，其中所述最终状态是接受状态，所述自动机在成功地验证事实之后进入接受状态。

7.如权利要求1所述的计算机实现的方法，其中所述自动机至少部分地基于语义模型创建。

8.如权利要求1所述的计算机实现的方法，其中所述语义模型还表示与事实相关联的事实依赖性。

9.如权利要求1所述的计算机实现的方法，其中将要验证的事实是上下文的子集。

10.如权利要求1所述的计算机实现的方法，其中至少部分地基于标识的上下文创建自动机包括创建用于模型实体的每个实例的自动机。

11.如权利要求1所述的计算机实现的方法，其中所述事实是数据记录事实。

12.如权利要求1所述的计算机实现的方法，其中所述事实还包括知识或数据中的一个或多个。

13.如权利要求1所述的计算机实现的方法，还包括提供标识错误状态的运行时图形输出。

14.如权利要求1所述的计算机实现的方法，还包括提供标识错误的运行时文本记录输出。

15.如权利要求1所述的计算机实现的方法，其中使用自动机验证事实包括验证结构化数据的结构或内容中的一个或多个。

16.如权利要求1所述的计算机实现的方法，还包括将域专用语言用于编程模型以指定验证程序。

17.如权利要求1所述的计算机实现的方法，其中验证程序从语义模型生成，所述语义模型以域专用语言编写，而且所述自动机在运行时从语义模型生成。

18.如权利要求17所述的计算机实现的方法，其中所述自动机通过智能算法自动地生成。

19.如权利要求1所述的计算机实现的方法，其中所述事实是统一模型中的事实，所述统一模型通过自动机经受验证。