[发明专利]基于约束模式进行约束故障分析的方法和装置

说明书

技术领域

本发明涉及模型验证中使用的一种约束违背(故障)分析方法及装置，更具体地，涉及一种基于模式(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