CN101377757A - 基于约束模式进行约束故障分析的方法和装置 - Google Patents

Abstract

本发明提供了一种用于对实例模型进行约束故障分析的方法和装置，所述方法包括步骤：为标准模型的约束定义多个模式，所述多个模式包含导航模式和逻辑模式；判断由实例模型生成的约束评价树中是否存在空节点；和如果存在空节点，则基于导航模式对约束评价树进行故障分析，否则基于逻辑模式对约束评价树进行故障分析。本发明提供了一种便利的工具，以在模型－约束设计者和模型用户之间建立良好的衔接，减轻模型/约束的使用负担，简化学习曲线，并帮助模型用户进行模型校正。

Description

基于约束模式进行约束故障分析的方法和装置

技术领域

本发明涉及模型验证中使用的一种约束违背(故障)分析方法及装置，更具体地，涉及一种基于模式(pattern)进行约束违背分析、以识别主域级根本原因的方法和装置。

背景技术

当今，在软件开发和系统管理中，已经广泛使用了模型驱动方法，其中，模型的完整性是保证该方法能被正确实施的关键。

为了保证模型的完整性，在模型的完整性验证中使用了约束(constrain)。以模型驱动部署为例，为了保证在IT环境中正确地实现部署模型，需要以下的约束:端口唯一约束，表示部署在相同操作系统(OS)上的网络模型应该具有唯一的端口值；配置(collocation)约束，数据库实例及其依赖的用户应该直接或间接地驻留(host)在相同的OS上；等等。

另外，对象约束语言(OCL)是能够描述对象导向模型和其它对象建模产品的表达式和约束的语言。在现有技术中，广泛使用OCL来表达关于统一建模语言(UML)的细节，而这些细节用图标的方式很难、甚至不可能来表达。所述表达式是值的表示或说明，而约束是对对象导向模型或系统(的一部分)的一个或多个值的限制。

下面说明现有技术中模型-约束设计者利用UML语言建立的标准模型。

图1(a)、(b)、(c)是利用UML语言建立的模型级表示，其中在图1(a)左侧的Class(类)A是对某一主域所建立的模型，其包括Class A的属性例如foo。右侧的Class B是Class A的子类，即在Class A下面所划分的更细致的类别，Class B也具有其相应的属性例如fool。可以用例如b的标识来表示Class B，然后通过对Class A施加标识b的操作，可以唯一地到达ClassB。也就是说，在系统中通过进行“Class A.b”的操作，可以从Class A通过唯一的路径定位到Class B。即，表达式“Class A.b”可以看作是从Class A到达Class B的路径。

Class B可以是一个集合，其中包括若干元素。这里举一个例子，如图1(b)所示，其表示汽车系统的主域，Class A表示某种汽车，而其子类，即Class B表示该种汽车的轮子，其中包括4个元素，可以表示为右前轮FR-W、左前轮FL-W、右后轮BR-W和左后轮BL-W，并且每个元素均具有自己的属性。

在上述系统中，可以对所建立的标准模型施加约束条件，例如该约束条件可以是“车轮的数目为4”，该约束利用OCL语言的表达式表示为“self.b→size()＝4”，如图1(c)所示。这个表达式的含义是:在从Class A唯一地定位到Class B后，对Class B进行逻辑运算，对该集合求大小，即算出其中的元素的数目，其中“self.b”代表“Class A.b”，而“→size()”表示对Class B，即对“Class A.b”求大小的逻辑运算。在这个示例中，其大小为4，即该汽车应该有4个轮子。

这样就建立了一个标准模型，并且其具有如上所述的约束条件。

在实际中，模型用户根据上述标准模型来建立适合自己的实例模型，并使用上述标准模型的约束条件对其所建立的实例模型进行验证，以检查所建立的实例模型是否正确，即是否符合上述标准模型。如果在验证中出错，则需要对所建立的实例模型进行校正。

模型问题分析是模型校正的关键所在。在现有技术中，许多工具包支持用OCL语言对UML或EMF模型的确认，但是没有任何工具支持当发生OCL约束违背(即实例模型不符合标准模型所规定的约束条件)时的模型问题分析，即没有任何工具来分析OCL表达式来帮助进行模型校正。

因此，在现有技术中，当模型用户，例如某一汽车制造商，在建立了自己的实例模型并使用上述标准模型的约束条件进行验证时，如果该制造商所建立的实例模型出现错误，即所建立的实例模型违背了标准模型的约束条件，则利用上述标准模型进行的验证只能向该模型用户给出“True(真)”或“False(假)”的验证结果，而没有更详细的信息。下面结合图2进行详细的说明。

图2是现有技术中建立标准模型的过程的图示。

如图2所示，左侧的图表示要建立的模型的类型，其具体为软件单元“Unit”，属性为“version”，并且要求不同的软件单元之间要具有一定的关系，例如各单元之间的驻留者和被驻留者的关系。根据图2左侧的模型类型，建立了如图2右侧所示的软件单元WAS、JDBC和OS(操作系统)，并给出了约束条件:WAS和JDBC应该运行在同一个OS上。该约束条件被表示为:

Context WAS

inv:selfhost＝self.resolve(“/JDBC”).host。

这里，“Context WAS”表示从软件单元WAS开始施加该约束，而“self”表示软件单元WAS本身，“host”表示WAS所要安装在其上的软件单元“OS”，“self.host”表示从WAS到OS的路径，“self.resolve(‘/JDBC’)”表示从WAS找到JDBC，而“self.resolve(“/JDBC”).host”表示从JDBC到OS的路径。

下面结合图3和图4来说明现有技术中对实例模型的验证。

图3是实例模型的一个示例。

假设存在如图3所示的实例模型，在验证所建立的实例模型是否正确时，计算上述约束表达式self.host＝self.resolve(“/JDBC”).host，该表达式限定WAS和JDBC应该运行在同一个OS上。由于其中未建立JDBC和WAS与OS1和OS2之间的关系，因此模型验证会出错。上述验证所返回的结果是:“self.”遇到空点以及“self.resolve(‘/JDBC’).”遇到空点，即不能分别从WAS和JDBC到达OS1和OS2，不能从上一级类别得到其子类。而这时期望的结果是:应该已经在操作系统上安装了“JDBC”和“WAS”。上述现有技术中的验证不能得到上述结果。

图4是实例模型的另一个示例。

在如图4所示的实例模型中，将“JDBC”和“WAS”安装在不同的操作系统OS1和OS2上，即，建立了“JDBC”到“OS1”的关系和“WAS”到“OS2”的关系。这时，运算约束表达式self.host＝self.resolve(“/JDBC”).host，该表达式限定WAS和JDBC应该运行在同一个OS上，而运算该表达式所返回的结果是:假。即软件单元WAS和JDBC实际上并没有被安装在同一个操作系统上，而这时所期望的结果是:“JDBC”和“WAS”应该安装在同一个操作系统上。因此，上述现有技术中的验证也不能得到上述结果。

实际上，在通过将约束施加给模型而对实例模型进行验证的过程中，当该实例模型有错误时，则施加在其上的约束会出现故障。可以将所出现的约束故障分为两种类型，一种是空节点故障，即所施加的约束的某个节点的返回值为零，这说明该节点是个空节点(例如未定义)，另一种是逻辑故障，即所施加的约束的某个节点的返回值是错误的值，这说明产生该节点值的逻辑发生了错误。

但是，现有技术中对实例模型的验证只能向该模型用户给出“真”或“假”的验证结果，而不能提供用户需要了解的模型故障的根本原因。

如果该用户想要查出该故障出现的具体原因，则其需要详细了解上述标准模型的细节及其中的各个表达式，而这对于模型用户来说是非常困难的。

发明内容

针对现有技术中存在的上述问题，本发明提出了一种基于模式进行约束违背分析、以识别主域级根本原因的方法和设备。

根据本发明的一个方面，提供一种用于对实例模型进行约束故障分析的方法，包括步骤:为标准模型的约束定义多个模式，所述多个模式包含导航模式和逻辑模式；判断由实例模型生成的约束评价树中是否存在空节点；和如果存在空节点，则基于导航模式对约束评价树进行故障分析，否则基于逻辑模式对约束评价树进行故障分析。

在本发明的一个实施例中，还包括步骤:将所述模式分解为模式解析树，按照相同顺序依次比较所述约束评价树中的各个节点与所述模式解析树中的全部节点，以查找一个或多个匹配模式。

在本发明的一个实施例中，用模式标识符来注释约束评价树中的节点，并且所述方法还包括:根据所述模式标识符，在所述模式中选择一个或多个匹配模式。

在本发明的一个实施例中，所述匹配是指约束评价树中的节点的类型或数值与模式解析树中的相应节点的类型或数值一致。

在本发明的一个实施例中，还包括步骤:从所匹配的多个模式中选取最接近的匹配模式，所述最接近的匹配模式是具有最多与所述约束评价树匹配的节点的模式。

在本发明的一个实施例中，还包括步骤:从最接近的匹配模式中提取用于描述约束违背根本原因的参数项和/或描述项，以生成问题原因报告。

在本发明的一个实施例中，所述逻辑模式具有多个层级，所述方法还包括:获取当前可用层级的逻辑模式，并将所获取的当前可用层级的逻辑模式及其低层级的逻辑模式中的全部节点依次与所述约束评价树中的各个节点进行比较。

在本发明的一个实施例中，所述导航模式用来限定标准模型中各单元之间的路径，逻辑模式用来限定导航模式之间的逻辑关系。

根据本发明的另一个方面，还提供一种用于对实例模型进行约束故障分析的装置，包括:分析判定器，用于判断由实例模型生成的约束评价树中是否存在空节点；以及故障分析器，用于如果存在空节点，则基于导航模式对约束评价树进行故障分析，否则基于逻辑模式对约束评价树进行故障分析。

在本发明的一个实施例中，还包括:约束模式定义器，用于为模型的约束定义多个模式，所述多个模式包括导航模式和逻辑模式，其中所述导航模式用来限定模型中各单元之间的路径，逻辑模式用来限定导航模式之间的逻辑关系。

在本发明的一个实施例中，还包括:模式解析器，用于将所述模式分解为模式解析树，其中所述故障分析器按照相同顺序依次比较所述约束评价树中的各个节点与所述模式解析树中的全部节点，以查找一个或多个匹配模式。

在本发明的一个实施例中，用模式标识符来注释约束评价树中的节点，并且所述分析判定器根据所述模式标识符，在所述模式中选择一个或多个匹配模式。

在本发明的一个实施例中，所述匹配是指约束评价树中的节点的类型或数值与模式解析树中的相应节点的类型或数值一致。

在本发明的一个实施例中，所述故障分析器从所匹配的多个模式中选取最接近的匹配模式，所述最接近的匹配模式是具有最多与所述约束评价树匹配的节点的模式。

在本发明的一个实施例中，还包括:问题原因报告器，用于从最接近的匹配模式中提取用于描述约束违背根本原因的参数项和/或描述项，以生成问题原因报告。

在本发明的一个实施例中，所述逻辑模式具有多个层级，所述故障分析器获取当前可用层级的逻辑模式，并将所获取的当前可用层级的逻辑模式及其低层级的逻辑模式中的全部节点依次与所述约束评价树中的各个节点进行比较。

根据本发明的另一个方面，还提供一种用于定义约束模式的方法，包括:为模型的约束定义多个模式；以及将所述多个模式分解为逻辑模式和/或导航模式，其中所述导航模式用来表示所述模型中各单元之间的路径，而所述逻辑模式用来表示导航模式之间的逻辑关系。

在本发明的一个实施例中，所述逻辑模式引用多个导航模式。

在本发明的一个实施例中，所述逻辑模式具有多个层级，不同层级的逻辑模式包含不同详细程度的基本信息。

在本发明的一个实施例中，所述模式中包含用于描述约束违背根本原因的参数项和/或描述项。

本发明提供了一种便利的工具，以在模型-约束设计者和模型用户之间建立良好的衔接，减轻模型/约束的使用负担，简化学习曲线，并帮助模型用户进行模型校正。本发明还使手动模型整体性分析过程得以自动实现。

附图说明

从下面结合附图对本发明实施例的详细描述中，本发明的这些和/或其它方面和优点将变得更加清楚并且更容易理解，其中:

图1(a)、(b)、(c)是标准模型的图形表示。

图2是现有技术中建立标准模型的过程的示例。

图3是建立的实例模型的例子。

图4是建立的实例模型的另一个例子。

图5是本发明一般概念的示例。

图6是示出本发明一般概念的另一个示例。

图7是示出现有技术中约束评价器的功能以及约束评价树的结构的例子的图示。

图8是示出现有技术中模式解析器的功能以及模式解析器的结构的例子的图示。

图9是示出现有技术中的问题原因报告器的功能的一个例子的图示。

图10是示出用于定义本发明实施例中的导航模式的图示。

图11是示出用于定义本发明实施例中的逻辑模式的图示。

图12是示出本发明实施例中的配置约束模式的例子。

图13是根据本发明实施例的约束违背分析器的框图。

图14是在根据本发明实施例的约束违背分析器中执行操作的流程图。

图15和16是示出本发明实施例中的约束违背分析器516的操作的图示。

图17(a)、(b)和(c)是说明通过遍历的方式寻找与故障节点匹配的导航模式(或逻辑模式)的示例，其中采用逆向遍历的方式。

具体实施方式

下面将结合附图详细描述本发明的具体实施例。如果考虑到对某些相关现有技术的详细描述可能会混淆本发明的要点，则将不会在这里提供其详细描述。在同一实施方式中，相同的附图标记用于表示执行相同功能的相同元件或元素。

图5是示出本发明一般概念的图示。

在图5中，包括已经由模型-约束设计者设计完成的标准模型502和要附加在其上的约束504，以及由模型用户在标准模型502的基础上建立的实例模型506。上述标准模型502、约束504和实例模型506作为约束评价输入而被输入到约束评价器512中。在约束评价器512中，根据标准模型502和约束条件504对实例模型506进行分解，形成约束评价树(其中以树结构表示约束中的基本元素)，然后将结果发送给约束违背分析器516。

模型-约束设计者构建约束模式定义器508，在其中为各个约束定义多个模式(后面将对这些模式进行详细的说明)510。具体地，约束模式定义器508将标准模型的约束表示为逻辑表达式，并将所述逻辑表达式定义为多个约束模式，其中所述约束模式可以分为逻辑模式和导航模式两大类，所述导航模式用来限定所述标准模型中各单元之间的路径，而所述逻辑模式用来限定导航模式之间的逻辑关系。

然后，约束模式定义器508将所定义的各个模式发送给模式解析器514。在模式解析器514中，对各个模式进行分解，形成模式解析树，其中以树结构表示各个模式中的基本元素。然后将结果发送给约束违背分析器516。

在约束违背(故障)分析器516中，基于所提供的模式解析树和约束评价树，进行导航(navigation)故障分析和/或逻辑故障分析，以查找故障在约束评价树中的位置，并找到对应于该故障的模式(导航模式或逻辑模式)，提取相应的模式参数，并将所找到的对应故障模式和所提取的模式参数发送给问题原因报告器518。

在问题原因报告器518中，利用所获得的故障模式和模式参数等数据形成问题原因的报告，并将该报告通过例如视频、音频、图像、图形等方式提供给模型用户。

图6是示出本发明一般概念的另一个示例。

图6所示的实施例与图5所示的实施例的区别在于，从图5中取消了模式解析器514，将其中的约束504更换为带有模式注释的约束604，并增加了基于模式的约束描述器603。

在图6的约束模式定义器508中，为各个约束定义多个模式510，并将所定义的各个模式510发送给基于模式的约束描述器603，也直接发送给约束违背分析器516。

在基于模式的约束描述器603中，根据所接收的各个模式510以及所建立的标准模型502，如下定义所述约束:首先使用逻辑模式指示(Denotation)来描述所述约束的纲要，然后用导航模式来定义其参数，每个参数是由导航模式所构成的路径。利用这种基于模式的约束描述机制，可以用结构化的模式ID来注释所述约束，即利用结构化的模式ID对所述约束进行注释，使该约束对应于特定的模式。即，基于模式的约束描述器603基于标准模型502和从约束模式定义器508接收的约束模式，生成带有模式注释的约束604，其中在所述带有模式注释的约束604中，用结构化的模式标识符(ID)来注释所述约束，使所述约束对应于特定的模式。即利用模式ID在约束和模式之间建立对应关系，使得可以通过所述模式ID从特定的约束找到相应的模式。

这样，附图标记604所表示的约束与图5中的附图标记504所表示的约束产生了差别。附图标记604所表示的约束是附加了模式注释的约束，即通过对该约束的注释可以找到对应的模式。

由此，在图6所示的实施例中，将标准模型502、带有模式注释的约束604和实例模型506作为约束评价输入而输入到约束评价器512中。在约束评价器512中，根据标准模型502和带有模式注释的约束对实例模型506进行分解，形成带有模式注释的约束评价树，该约束评价树中的各单元(节点)具有模式ID，使其对应于相应的模式。然后将结果发送给约束违背分析器516。

在约束违背分析器516中，基于所提供的模式510和从约束评价器512提供的带有注释的约束评价树，进行故障分析，即通过(分析判定部件，见图13)在约束评价树中遍历各个节点，在其中查找故障所在的节点(位置)，根据所找到的故障节点和故障节点的模式ID，在模式510中找到对应于该故障的模式(导航模式或逻辑模式)，然后从所找到的对应于该故障的模式中提取相应的模式参数，并将所找到的故障模式和所提取的模式参数发送给问题原因报告器518。

在问题原因报告器518中，利用所获得的故障模式和模式参数等数据形成问题原因的报告，并将该报告通过例如视频、音频、图像、图形等方式提供给模型用户。

上述约束评价器512、模式解析器514和问题原因报告器518均是能够采用本领域技术人员所熟知的现有技术实现的。

图7是示出现有技术中的约束评价器512的功能及约束评价树结构的例子的图示。

如图7所示，附图标记703表示一个实例模型，其含义为:数据库实例706是数据库系统708的一个实例，其运行在操作系统Windows XP1上，而对数据库实例706操作的用户应用程序712运行在操作系统Windows XP2上。附图标记702表示对实例模型703的约束，其含义为:数据库实例706和对其进行操作的用户应用程序712应该运行(安装)在同一个操作系统上。

约束评价器512对约束702进行编译，并按照约束702而将该实例模型703分解为图7右侧的约束评价树704，其中包括约束702中的各个元素。通过对逻辑运算符“<>”两侧的各个节点分别进行运算，得出逻辑运算值为“false(假)”，即由于数据库实例706运行在操作系统Windows XP1上，而对数据库实例706操作的用户应用程序712运行在操作系统Windows XP2上，这与该约束702的要求(数据库实例706和对其进行操作的用户应用程序712应该运行(安装)在同一个操作系统上)不一致，因此，其逻辑运算值为假。

由于上述约束评价器512的功能主要是采用现有的编译技术通过对约束进行词法，语法以及语义分析而计算一个约束的评价结果。由于编译技术为本领域的技术人员所熟知，本发明中将不再对其进行更详细描述。

图8是示出现有技术中的模式解析器514的功能以及模式解析树的结构的示例。

如图8所示，模式解析器514对配置模式802进行编译，将其分解为图8右侧的模式解析树804，其中包括模式802中的各个元素。模式解析树804中包括导航模式和/或逻辑模式。由于上述模式解析器514主要是采用现有的编译技术对约束模式进行词法，语法分析而建立模式解析树的，为了不使本发明的思想被混淆，本发明中将省略对其的详细描述。

图9是示出现有技术中的问题原因报告器518的功能的一个例子的图示。

如图9所示，问题原因报告器518中包括问题原因生成器902和904，它们从约束违背分析器516中接收所获得的故障模式和所提取的模式参数，形成关于所述问题原因的报告，并将该报告呈现给模型用户。

由于上述问题原因报告器518是采用参数填充技术根据约束违背分析的结果构造约束违背的问题原因，它是一种简单的直接的现有技术，为本领域的技术人员熟知，为了不使本发明的思想被混淆，本发明中将省略对其的详细描述。

下面，将描述本发明中用于定义约束模式的方法和装置。

如上所述，在本发明的实施例中，约束模式定义器508将标准模型的约束表示为逻辑表达式，并将所述逻辑表达式定义为多个约束模式，其中所述多个约束模式包括逻辑模式和导航模式两大类，所述导航模式用来限定所述标准模型中各单元之间的路径，而所述逻辑模式用来限定导航模式之间的逻辑关系。

图10是示出用于定义本发明实施例中的导航模式的图示。

建立如图10所示的模型，其包括Class A、Class B、Class C和Class D。为了从Class A定位到Class D，用约束表达式“A.B.D”来表示从Class A经过Class B到Class D的路径。“A.B.D”作为一个语意单元，用来代表从ClassA到Class D的路径，将这样的约束表达式定义为导航模式。在约束违背分析中，可以将上述导航模式作为一个整体来处理。

图11是示出用于定义本发明实施例中的逻辑模式的图示。

在本发明的实施例中，将如图11所示的例如约束条件表达式“self.host＝self.resolve(“/JDBC”).host”定义为逻辑模式，其中的符号“＝”表示逻辑运算符，“self.host”(即上面定义的导航模式)表示一个操作数。本发明的一个实施例中，一个模式解析树中可以包括多个逻辑模式，一个逻辑模式中可以包括多个操作数，而一个操作数中可以引用多个导航模式。用逻辑运算符来实现所述逻辑关系，并且用对象约束语言(OCL)来表述逻辑表达式。

在本发明的实施例中，对于每个约束模式(包括导航模式和逻辑模式)，可以如下定义它的基本信息:

ID(标识)，是用于识别该模式的唯一信息；

Name(名称)，对所述模式的一般性概要描述；

Description(说明)，对所述模式的一般性描述；

Context(环境)，对一些参数的定义，用来记录所述模式的评价环境；

Denotation(指示)，用于模式的正式表示，是带有参数的字符串信息；

Problem Cause Template(问题原因模板)，使用以下各项来定义具体的问题原因模板:

Parameters(参数)，用于对问题原因进行描述，将在进行评价时获得这些参数的值；和

Description(描述)，带有参数的字符串，用来描述具体问题的原因。

图12是示出本发明实施例中的配置(collocation)约束模式的例子。

如图12所示，附图标记1202表示该约束模式包括的基本信息:环境(Context)、指示(Denotation)和问题原因模板(Problem-cause-template)。可以将该约束模式表示为不同的层级，不同层级中的信息量可以不同。例如，附图标记1204表示第一层级，其示出的信息量最少，其“问题原因模板”项可以是“两个单元不能被配置在相同的结果类型(ResultType)上”；附图标记1206表示第二层级，其示出的信息量比第一层级多，其“问题原因模板”项可以是“Unit(单元)1和Unit2不能被配置在相同的ResultType上”；附图标记1208表示第三层级，其示出的信息量比第二层级还多，其“问题原因模板”项可以是“Unit(单元)1与其从属Unit2不能被配置在相同的ResultType上”。

上述约束模式中包含的信息量越多，在进行约束违背分析时所能提供的信息量就越多，所进行的分析就越详细，所获得的约束违背的原因就越明确和具体。因此，在下面要进行说明的约束违背分析中，将会逐级地分析到含有最多信息量的最低层级。

下面将参照附图说明本发明的约束违背分析器516及其操作。

图13是根据本发明实施例的约束违背分析器的框图。

根据图13，本发明的约束违背分析器516包括导航故障分析器1302、逻辑故障分析器1304、分析判定器1306、和控制器1308。

如前所述，在对实例模型进行验证的过程中，可以将所出现的约束故障分为两种类型，一种是空节点故障，即所施加的约束的某个节点的返回值为零，这说明该节点是个空节点，而另一种是逻辑故障，即所施加的约束的某个节点的返回值是错误的值，这说明产生该节点值的逻辑发生了错误。

因此，在本发明中，在通过将约束施加给模型而对实例模型进行验证时，如果返回的验证值不正确，则可以利用如图13所示的本发明的约束违背分析器来进行故障分析。

在本发明的一个实施例中，约束违背分析器516中的分析判定器1306通过接口(未示出)从约束评价器512中接收约束评价信息，即在其中所生成的约束评价树。

在本发明的一个实施例中，约束违背分析器516中的分析判定器1306通过接口(未示出)从模式解析器514中接收模式解析信息，即在其中所解析生成的模式解析树。

在约束违背分析器516中，分析判定器1306对所述约束评价树中的各个节点进行遍历，并判断是否找到空节点(例如返回值为零)。例如，在如图10所示的模型中，判断是否能够从节点Class A找到节点Class B，即判断表达式“A.B”是否正确。如果在所述约束评价树中找到了空节点，例如不能从节点Class A找到节点Class B，即Class B为空节点(例如可以是节点Class B未被定义)，则判断表达式“A.B”出现错误。这时，由于表达式“A.B”对应于导航模式，因此，约束违背分析器516中的控制器1308将指示导航故障分析器1302进行导航故障分析。

如果在所述约束评价树中未找到空节点，即能够从节点Class A找到节点Class B，即判断表达式“A.B”正确，则表示与表达式“A.B”对应的导航模式没有错误。当然，上述分析过程还包括判断表达式“A.C”和“A.B.D”等都正确。在这种情况下，所出现的故障应为逻辑故障，约束违背分析器516中的控制器1308将指示逻辑故障分析器1304进行逻辑故障分析。

导航故障分析器1302和逻辑故障分析器1304中的操作将在后面进行详细的描述。

导航故障分析器1302和逻辑故障分析器1304将各自的分析结果(包含所获得的故障模式和相应的参数值)提供给问题原因报告器518，在问题原因报告器518中形成向模型用户报告问题原因的报告。

本发明中的导航故障分析器1302和逻辑故障分析器1304不对本发明的范围构成限制，它们也可以被合并在同一个装置中，例如被合并为一个故障分析器来执行上述导航故障分析器1302和逻辑故障分析器1304两者的功能。

图14是在根据本发明实施例的约束违背分析器中执行操作的流程图。

如图14所示，在步骤S1中，约束违背分析器516中的分析判定器1306遍历所述约束评价树的各个节点。

然后，在步骤S2中，分析判定器1306判断是否找到空节点。

如果从所述约束评价树中找到了空节点，则在步骤S3中，约束违背分析器516中的导航故障分析器1302从控制器1308接收进行导航故障分析的指示，并进行导航故障分析。

如果从所述约束评价树中未找到空节点，则在步骤S4中，逻辑故障分析器1304从约束违背分析器516中的控制器1308接收进行逻辑故障分析的指示，并进行逻辑故障分析。

然后，在步骤S5中，问题原因报告器518从导航故障分析器1302和/或逻辑故障分析器1304接收各自的分析结果，例如故障模式和模式的参数值，并形成向模型用户报告问题原因的报告。

下面将详细说明本发明实施例中的约束违背分析器516、其中的导航故障分析器1302和逻辑故障分析器1304等各自的操作。

图15和16是示出本发明实施例中的约束违背分析器516的详细操作的流程图。

如图15所示，在步骤S1502，约束违背分析器516首先对从约束评价器512接收的约束评价树进行故障代码检测，以检测其中是否具有模式注释。约束违背分析器516中可以包括独立的故障代码检测器(未示出)。然后，在步骤S1503，故障代码检测器(未示出)判断约束评价树中是否具有模式注释。

如果在步骤S1503中判断所述约束评价树中没有模式注释，则约束违背分析器516从模式解析器514接收模式解析树，并基于从约束评价器512所提供的约束评价树和从模式解析器514所提供的模式解析树，进行导航故障分析和/或逻辑故障分析。

接下来，在步骤S1504中，如上面参照图13和14所述，约束违背分析器516中的分析判定器1306遍历所述约束评价树中的各个节点，并判断是否找到空节点。如果从所述约束评价树中找到了空节点，表明在导航环节出现了错误(故障)，因此约束违背分析器516中的控制器1308将指示导航故障分析器1302进行导航故障分析。

接下来，结合图15以及图17(a)、(b)和(c)对所述导航故障分析进行描述。

如图15中的步骤S1506所示，导航故障分析器1302对所述约束评价树中的各个节点进行遍历，以查找与该故障节点匹配的导航模式。对约束评价树中的各个节点进行遍历的方式，可以是正向遍历或是逆向遍历等。正向遍历或是逆向遍历是本领域技术人员所熟知的，这里以逆向遍历为例进行适当的描述。

图17(a)、(b)和(c)是说明通过遍历的方式寻找与故障节点匹配的导航模式的示例，其中采用逆向遍历的方式。如图17(a)所示，表达式getTarget().getParent().getHost()中的各个节点是所述约束评价树的一部分，其中的一个或几个是故障节点。为了简洁，在本实施例中用上述几个节点作为示例，代表约束评价树来进行匹配，其中节点getHost()是该约束评价树的最后一个节点。

表达式unit1.unit2.unit3中的各个节点(单元)则是模式解析树的一部分，本实施例中将其用作一个模式来进行匹配，其中unit3是该模式的最后一个节点。

在上述实施例中，导航故障分析器1302从约束评价树的最后一个节点，即getHost()开始，按照从后到前的顺序，依次将其中的节点的例如类型与上述模式(解析树)中按照相同顺序的各个节点的类型进行比较，来查找与其匹配的导航模式。

即，导航故障分析器遍历所述约束评价树中的各个节点，按照从后向前或者从前向后的顺序，依次将其中的节点与所述模式解析树中的全部节点按照相同顺序进行比较，来查找与其匹配的一个或多个导航模式。

本发明对导航模式所定义的术语“匹配”，是指约束评价树中的节点的类型与该模式中的相应节点的类型一致，例如，如果约束评价树中的节点getHost()的类型与该模式中的节点unit3的类型一致，则判定这两个节点互相匹配。如果类型不一致，则为不匹配。当然，上述的“类型”并不对本发明的范围构成限制，还可以定义其它的属性来判定是否匹配。

如图17(a)所示，在判断了节点getHost()与节点unit3的类型一致后，再判断节点getParent()与节点unit2的类型是否一致，依此类推，接着再判断节点getTarget()与节点unit1的类型是否一致。在上述实施例中，如果判断这三对节点的类型分别匹配，则就找到了与约束评价树getTarget().getParent().getHost()相匹配的一个模式unit1.unit2.unit3。如果其中有任何一对节点不匹配，则判定为不匹配。

如图17(b)所示，在模式解析树有例如两个节点unit2.Unit3的情况下，首先判断节点getHost()的类型是否与节点unit3的类型一致，然后再判断节点getParent()的类型与节点unit2的类型是否一致。在这个实施例中，如果判断这两对节点的类型分别匹配，则就找到了与约束评价树getTarget().getParent().getHost()相匹配的一个模式unit2.unit3。如果其中有任何一对节点不匹配，则判定为不匹配。

如图17(c)所示，在模式解析树有例如三个节点unit2.Unit3.Requirement的情况下，首先判断节点getHost()的类型是否与节点Requirement的类型一致。在这个实施例中，如果判断这对节点的类型不一致，则判断模式unit2.Unit3.Requirement不是与约束评价树getTarget().getParent().getHost()相匹配的模式。

在本发明中，对同一个约束评价树，可能匹配出多个模式，例如在上例中，可以匹配出两个模式。在本发明中，按照逆向或者正向遍历的方式，对约束评价树中的各个节点与模式解析树中各个模式的全部节点进行顺序对比，如果模式解析树中某个模式的全部节点的类型从后向前或者从前向后依次与约束评价树中从后向前或者从前向后的各个节点的类型相匹配，则判定该模式是与该约束评价树相匹配的模式。在本发明中，约束评价树中的节点可能多于用于进行匹配的该模式中的节点。

接下来，在图15的步骤S1508中，导航故障分析器1302从所匹配出的所有模式中，选择最接近的匹配模式。在本发明中，可以设定例如其中匹配的元素(节点)最多的模式为最接近的匹配模式。在上述实施例中，所匹配的模式分别为unit1.unit2.unit3和unit2.unit3，根据上面设定的标准，由于模式unit1.unit2.unit3中含有三个元素，都与约束评价树中的相应节点匹配，且其中元素的数目(3)多于模式unit2.unit3中的元素数目(2)，因此，选择模式unit1.unit2.unit3为最接近的匹配模式。即，所述导航故障分析器从所匹配的多个导航模式中选取的最接近的匹配模式中具有最多的与所述约束评价树匹配的节点。

接下来，在步骤S1510中，导航故障分析器1302(其中的或与其相连接的模式信息提取器(未示出))提取所选择的最接近的匹配模式中的相关信息，即模式参数。如上所述，在本发明中为模式定义了如下的基本信息:ID，Name，Description，Context，Denotation，Problem-Cause-Template等，其中Problem-Cause-Template具有用于对问题原因进行描述的Parameters和Description。在本实施例中，导航故障分析器1302所提取的相关信息可以是上述Problem-Cause-Template中的Parameters的值，也可以包括其它基本信息的值。

在完成上述操作后，如前所述，导航故障分析器1302(其中的或与其相连接的模式信息提取器)将所获得故障模式和所提取的相关信息提供给问题原因报告器518。在问题原因报告器518中，根据所提供的故障模式和相关信息来形成关于所出现的问题的原因的报告，并将其呈现给模型用户。

接下来，将参照图15、16和图17(a)、(b)和(c)对逻辑故障分析进行描述。

如上所述，在图15的步骤S1504中，约束违背分析器516中的分析判定器1306遍历所述约束评价树的各个节点，并判断是否找到空节点。如果从所述约束评价树中未找到空节点，则表明在导航环节未出现故障，因此发生的故障应为逻辑故障，约束违背分析器516中的控制器1308将指示逻辑故障分析器1304进行逻辑故障分析，过程进行到图16中的步骤S1605。

在图16中的步骤S1605中，逻辑故障分析器1304对约束评价树中的各个节点进行合成与分解，例如将其中的两个或多个元素合成一个元素或将其中的一个元素分解为两个或多个元素，以便能够得出相应节点的数值，并算出根节点的逻辑值。例如，在图7所示的约束评价树中，可以将元素“getHost()”和“getParent()”合成为一个元素“getParent()”，也可以将元素“getParent()”分解为两个元素“getHost()”和“getParent()”，即元素“getParent()”中可以包含元素“getHost()”。

然后，如图16中的步骤S1606所示，逻辑故障分析器1304判断约束评价树的根节点的逻辑值是“真”还是“假”，如果是“真”，则表示没有故障，可以在相关操作后，结束该过程。而存在约束故障的情况下，该判断结果一定为“假”。

如果该逻辑值是“假”，则过程进行到步骤S1607。

在步骤S1607中，逻辑故障分析器1304获取针对所合成或分解的约束评价树的当前可用层级的逻辑模式，其例如可以是图12所示的第一至第四层级中的一个层级的逻辑模式。然后，过程进行到步骤S1608。

在步骤S1608中，逻辑故障分析器1304根据所获取的当前可用层级的逻辑模式，对合成或分解后的约束评价树中的各个节点进行遍历，来查找与其匹配的逻辑模式。

例如，如果当前可用层级的逻辑模式是如图12中的1204所示的第二层级的逻辑模式，则逻辑故障分析器1304对约束评价树中的各个节点进行遍历，来查找与其匹配的第二层级1204中的逻辑模式。即，如果该根节点的逻辑值是“假”，则逻辑故障分析器遍历所述约束评价树中的各个节点，按照从后向前或者从前向后的顺序，依次将其中的节点与所述当前可用层级的逻辑模式中的全部节点按照相同顺序进行比较，来查找与其匹配的一个或多个逻辑模式。

本发明对逻辑模式所定义的术语“匹配”，可以是指约束评价树中的各个节点的数值与模式解析树中的相应节点的数值一致。如果数值一致，则判定该约束评价树与该逻辑模式相匹配。如果它们的数值不同，则为不匹配。当然，上述的“数值”并不对本发明的范围构成限制，还可以定义其它属性来判定是否匹配。

在逻辑故障分析器1304中，对约束评价树进行遍历和与逻辑模式的匹配判断的操作与在导航故障分析器1302中的操作相同。为了说明逻辑故障分析器1304中的匹配操作，可以将图17(a)、(b)、(c)中的导航节点的类型替换为对应节点的数值，其成立匹配的方式是类似的，即，只要约束评价树中的节点的数值与逻辑模式中的相应节点的数值一致，就判断为相互匹配。具体来说，在逻辑故障分析器1304中，按照逆向或者正向遍历的方式，对约束评价树中的各个节点与模式解析树中相应层级的各个逻辑模式的全部节点进行顺序对比，如果模式解析树中某个逻辑模式的全部节点从后向前或者从前向后依次与约束评价树中从后向前或者从前向后的各个节点的数值相一致，则判定该逻辑模式是与该约束评价树相匹配的逻辑模式。

在本发明中，约束评价树中的节点数目可能多于用于进行匹配的逻辑模式中的节点的数目。另外，与导航模式同样，对同一个约束评价树，也可能匹配出多个逻辑模式。

接下来，在图16的步骤S1609中，所述逻辑故障分析器1304判断是否存在低一级逻辑模式，例如第三级逻辑模式、第四级逻辑模式等。如果存在低一级逻辑模式，则过程返回到步骤S1607，在其中通过与上述相同的过程来对该低一级逻辑模式进行匹配，找出其中可能存在的多个匹配逻辑模式。

在步骤S1609的判断中，如果所述逻辑故障分析器1304判断不存在低一级的逻辑模式，则过程进行到步骤S1610。

接下来，在图16的步骤S1610中，逻辑故障分析器1304从所匹配出的所有逻辑模式中，选择最接近的匹配逻辑模式。在本发明中，可以设定例如其中匹配的节点(元素)最多的逻辑模式为最接近的匹配逻辑模式，这与在导航故障分析器1302中选择最接近的匹配模式的方式是相同的。

接下来，在步骤S1612中，逻辑故障分析器1304(其中的或与其相连接的模式信息提取器(未示出))提取所选择的最接近的匹配逻辑模式中的模式信息，即模式参数。如上所述，在本发明中为模式定义了如下的基本信息:ID，Name，Description，Context，Denotation，Problem-Cause-Template等，其中Problem-Cause-Template具有用于对问题原因进行描述的Parameters和Description。本实施例中，逻辑故障分析器1304所提取的相关信息可以是上述Problem-Cause-Template中的Parameters的值，也可以包括其它的基本信息。

在完成上述操作后，如前所述，逻辑故障分析器1304(其中的或与其相连接的模式信息提取器(未示出))将所获得的故障模式以及所提取的模式信息提供给问题原因报告器518。在问题原因报告器518中，根据所提供的故障模式和模式信息来形成关于所出现的问题的原因的报告，并将其呈现给模型用户，然后过程结束。

现在，再返回到图15中的步骤S1503。

如果在步骤S1503中判断所述约束评价树中有模式注释，则过程进行到步骤S1509。在步骤S1509中，约束违背分析器516中的分析判定器1306直接对约束评价树的各个节点进行遍历，以判断是否出现故障。如果分析判定器1306判定约束评价树中的节点出现了故障，则其对该故障进行定位。

上述对故障的判断和定位方式不对本发明的技术范围设置限制，其可以是本领域技术人员所知道的任何方法。

由于在带有模式注释的约束评价树中，利用结构化的模式ID对所述约束进行了注释，因此该约束对应于特定的模式。因此，在步骤S1509中，约束违背分析器516中的分析判定器1306根据所定位的故障和约束评价树中的模式ID，识别与该故障节点相对应的模式(导航模式或逻辑模式)，并将其作为与所述故障相匹配的模式。

即，当检测到所述约束评价树中含有所述模式注释(模式标识符)时，所述约束违背分析器516中的分析判定器1306从约束模式定义器508接收所定义的约束模式510，并在所述约束评价树中遍历各个节点，查找故障所在的节点，根据所找到的故障节点和与其对应的模式标识符，在所述约束模式中选择对应于该故障的一个或多个匹配模式。

接下来，在步骤S1510中，约束违背分析器516中的模式信息提取器(未示出)提取所确定的匹配模式中的相关信息，即模式参数。如上所述，在本发明中为模式定义了如下的基本信息:ID，Name，Description，Context，Denotation，Problem-Cause-Template等，其中Problem-Cause-Template具有用于对问题原因进行描述的Parameters和Description。本实施例中，模式信息提取器所提取的相关信息可以是上述Problem-Cause-Template中的Parameters的值，也可以包括其它基本信息。

在完成上述操作后，如前所述，模式信息提取器(未示出)将所获得的故障模式和所提取的相关信息提供给问题原因报告器518。在问题原因报告期518中，根据所提供的故障模式和相关信息来形成关于所出现的问题的原因的报告，并将其呈现给模型用户。

需要说明的是，本发明的实施例可以通过硬件、软件或硬件和软件结合的方式来实现，其实现方式不对本发明的范围构成限制。

另外，本发明实施例中的各个功能元件(单元)相互之间的连接关系不对本发明的技术范围构成限制，其中的一个或多个功能元件可以包括或连接于其它任意的功能元件。例如，图15中的分析判定器1306可以分别包含于导航故障分析器1302和逻辑故障分析器1304中，也可以独立它们之外而与它们分别连接。

虽然上面已经结合附图示出并描述了本发明的一些实施例，本领域地技术人员应当理解，在不偏离本发明的原则和精神的情况下，可以对这些实施例可做变化和改变，其范围仍然落在所附的权利要求及其等价物中。

Claims (20)

1.一种用于对实例模型进行约束故障分析的方法，包括步骤:

为标准模型的约束定义多个模式，所述多个模式包含导航模式和逻辑模式；

判断由实例模型生成的约束评价树中是否存在空节点；和

如果存在空节点，则基于导航模式对约束评价树进行故障分析，如果不存在空节点，则基于逻辑模式对约束评价树进行故障分析。

2.如权利要求1所述的方法，还包括步骤:将所述模式分解为模式解析树，按照相同顺序依次比较所述约束评价树中的各个节点与所述模式解析树中的全部节点，以查找一个或多个匹配模式。

3.如权利要求1所述的方法，其中用模式标识符来注释约束评价树中的节点，并且所述方法还包括:根据所述模式标识符，在所述模式中选择一个或多个匹配模式。

4.如权利要求2或3所述的方法，其中所述匹配是指约束评价树中的节点的类型或数值与模式解析树中的相应节点的类型或数值一致。

5.如权利要求2或3所述的方法，还包括步骤:从所匹配的多个模式中选取最接近的匹配模式，所述最接近的匹配模式是具有最多与所述约束评价树匹配的节点的模式。

6.如权利要求5所述的方法，还包括步骤:从最接近的匹配模式中提取用于描述约束违背根本原因的参数项和/或描述项，以生成问题原因报告。

7.如权利要求1所述的方法，其中所述逻辑模式具有多个层级，所述方法还包括:获取当前可用层级的逻辑模式，并将所获取的当前可用层级的逻辑模式及其低层级的逻辑模式中的全部节点依次与所述约束评价树中的各个节点进行比较。

8.如权利要求1所述的方法，其中所述导航模式用来限定标准模型中各单元之间的路径，逻辑模式用来限定导航模式之间的逻辑关系。

9.一种用于对实例模型进行约束故障分析的装置，包括:

分析判定器，用于判断由实例模型生成的约束评价树中是否存在空节点；以及

故障分析器，用于如果存在空节点，则基于导航模式对约束评价树进行故障分析，如果不存在空节点，则基于逻辑模式对约束评价树进行故障分析。

10.如权利要求9所述的装置，还包括:

约束模式定义器，用于为模型的约束定义多个模式，所述多个模式包括导航模式和逻辑模式，其中所述导航模式用来限定模型中各单元之间的路径，逻辑模式用来限定导航模式之间的逻辑关系。

11.如权利要求10所述的装置，还包括:

模式解析器，用于将所述模式分解为模式解析树，

其中所述故障分析器按照相同顺序依次比较所述约束评价树中的各个节点与所述模式解析树中的全部节点，以查找一个或多个匹配模式。

12.如权利要求10所述的装置，其中用模式标识符来注释约束评价树中的节点，并且所述分析判定器根据所述模式标识符，在所述模式中选择一个或多个匹配模式。

13.如权利要求11或12所述的装置，其中所述匹配是指约束评价树中的节点的类型或数值与模式解析树中的相应节点的类型或数值一致。

14.如权利要求11或12所述的装置，其中所述故障分析器从所匹配的多个模式中选取最接近的匹配模式，所述最接近的匹配模式是具有最多与所述约束评价树匹配的节点的模式。

15.如权利要求14所述的装置，还包括:

问题原因报告器，用于从最接近的匹配模式中提取用于描述约束故障根本原因的参数项和/或描述项，以生成问题原因报告。

16.如权利要求11所述的装置，其中所述逻辑模式具有多个层级，所述故障分析器获取当前可用层级的逻辑模式，并将所获取的当前可用层级的逻辑模式及其低层级的逻辑模式中的全部节点依次与所述约束评价树中的各个节点进行比较。

17.一种用于定义约束模式的方法，包括:

为模型的约束定义多个模式；以及

将所述多个模式分解为逻辑模式和/或导航模式，

其中所述导航模式用来表示所述模型中各单元之间的路径，而所述逻辑模式用来表示导航模式之间的逻辑关系。

18.如权利要求17所述的方法，其中所述逻辑模式引用多个导航模式。

19.如权利要求17所述的方法，其中所述逻辑模式具有多个层级，不同层级的逻辑模式包含不同详细程度的基本信息。

20.如权利要求17所述的方法，其中所述模式中包含用于描述约束违背根本原因的参数项和/或描述项。

Images