基于扩展UML模型的安全苛求系统的故障树生成方法与流程

本发明涉及安全苛求系统技术领域，尤其涉及一种基于uml模型的安全苛求系统的故障树生成方法。

背景技术

安全苛求系统对组成系统的软件和硬件安全级别要求很高，其出现故障后可能会导致重大的生命、财产损失。为了避免人员伤亡、降低经济损失，安全苛求系统在设计和研发过程中必须慎之又慎。但是即使如此，由于设计工程师对于系统特性、行为等认识理解的局限性以及系统复杂、频繁的交互和协作，系统内及系统与环境间不可避免的会产生一系列的缺陷或故障。相对于其它类型的故障，这些故障对系统安全危害更大，隐藏的更深，对其检测和消除的难度也更高，本发明将其称为设计型故障，设计型故障成为了安全苛求系统不安全的一个主要原因。系统设计由于系统功能的复杂性而更难以进行且更容易出现一些错误，大部分错误只有在系统研发后期才会被发现，而当错误发生之后用来纠正这些错误的花费是相当耗费成本的。这些都为安全工程师们对安全苛求系统进行安全分析带来了巨大的挑战。

虽然安全分析技术目前已经非常成熟并广泛应用于安全苛求系统的设计过程中，但是大多数技术都是高度主观并且依赖于安全分析人员的从业技能。这些分析通常都是基于一个非正式的系统模型，很难做到完整一致且不出错。事实上，由于缺乏系统结构的精确模型和失效模式经常迫使安全分析人员花费很多的精力从多个资源处收集系统行为的细节信息，并将这些细节信息嵌入如故障树等安全分析方法中。尽管现在已经有了能够实现对设计模型进行自动安全分析的工具，但是现有的安全分析工具却是与设计过程分离的，并且在工程周期中安全分析的结果是明显滞后的。

技术实现要素：

本发明的实施例提供了一种基于扩展uml模型的安全苛求系统的故障树生成方法，以克服现有技术的缺点。

为了实现上述目的，本发明采取了如下技术方案。

一种基于扩展uml模型的安全苛求系统的故障树生成方法，包括：

构造安全苛求系统的扩展uml模型；

从所述扩展uml模型中提取安全苛求系统的结构关系信息，所述结构关系信息包括类图中的关联关系和基数信息；

基于所述结构关系信息使用故障树生成算法生成所述安全苛求系统的动态故障树。

进一步地，所述的构造安全苛求系统的扩展uml模型，包括：

使用类图对安全苛求系统的结构关系进行逻辑建模，安全苛求系统中的每个组件看作是类中的一个带有属性和操作的例子，使用构造型来扩展uml对安全苛求系统故障描述的语义，所述构造型用于建立安全苛求系统的故障树逻辑门。

进一步地，所述的使用类图对安全苛求系统的结构关系进行逻辑建模，安全苛求系统中的每个组件看作是类中的一个带有属性和操作的例子，包括：

使用类图对安全苛求系统的结构关系进行逻辑建模，所述类图允许设计者指明类的基数，类是具有相似结构、行为和关系的一组对象的描述符，基数描述了此类中存在的相似对象的数目，组件实例的数目存在于安全苛求系统运行时的类结构体本身；

类的关系的扩展方法如下：关联关系用于表示系统组件之间的信息交互，关联的方向代表着组件之间信息交互的方向；依赖关系用带箭头的虚线表示，箭头方向由依赖的一方指向被依赖的一方；组合关系用带实心菱形的实线表示，菱形指向整体，用于表示某大型平台与该平台下的子系统之间的关系。

进一步地，所述的使用构造型来扩展uml对安全苛求系统故障描述的语义，所述构造型用于建立安全苛求系统的故障树逻辑门，包括：

使用构造型来扩展uml对安全苛求系统故障描述的语义，表1表示了uml模型中的元素、关联和构造型语义与动态故障树之间的语义对照关系；

表1

在上述表1中，用<<propagateserrorto>>语义来表示差错传播路径，<<propagateserrorto>>依赖于类图中的关联关系，是类图中关联关系的构造型，同关联的方向有关；

备用组件为主组件提供冗余功能，主备组件都被归为一类，<<coldspare>>、<<hotspare>>和<<warmspare>>构造型来分别表明该类的冷备、热备和温备；

<<substitutesfor>>用来描述不同组件之间的冷备关系，与依赖关系一起使用，箭头从冷备组件指向主要主件；

<<runson>>构造型用来表明软硬件之间的映射关系，构造型<<runson>>与依赖关系一起使用。

进一步地，所述的从所述扩展uml模型中提取安全苛求系统的结构关系信息，所述结构关系信息包括类图中的关联关系和基数信息，包括：

(1)定义xmi和uml的命名空间，使用openfiledialog控件来查找uml模型生成的emx文件，获取emx文件的文件路径以及文件名后，调用xdocument类的load()方法，载入emx文件至xdocumentdoc中；

(2)遍历doc中具有xmi:type＝"uml:class"属性的"packagedelement"元素字段，将遍历到的uml模型中的类保存至varlistclass中，对于已经查找到的模型的类获取以下信息：

类名称class_name[i]

类idclass_id[i]

类属性class_attribute[i]

类冗余信息class_csphsp[i]

类从属关系class_owned[i]

获取与该类相连类的名称及相连类的数量，直到该元素的所有owenedattribute字段都遍历完，将遍历到的所有类的信息都储存在classinfolist类信息列表中；

(3)遍历doc中具有xmi:type＝"uml:dependency"属性的"packagedelement"元素字段，将遍历到的元素字段保存至varlistdependency中，"uml:dependency"是uml模型中依赖关系的属性，对于已经识别的依赖关系获取以下信息：

主模块idsupplier_id[j]

主模块名称supplier_name[j]

备模块idclient_id[j]

备模块名称client_name[j]

依赖关键字key_word[j]

将遍历到的所有的依赖关系信息存储在dependencyinfolist依赖信息列表中。

进一步地，所述的基于所述结构关系信息使用故障树生成算法生成所述安全苛求系统的动态故障树，包括：

(1)指定某模块失效作为故障树顶事件，生成模块失效的事件，从故障树顶事件开始向外遍历，所述某模块指uml模型中的某类；

(2)获取所述某模块的相关信息；

(3)判断所述某模块是否存在构造型<<coldspare>>和<<hotspare>>，如果存在<<coldspare>>就生成冷备门且向下生成两个中间事件：该模块1失效和该模块2失效；如果存在<<hotspare>>就生成热备门且向下生成两个中间事件：该模块1失效和该模块2失效；如果该模块不存在构造型<<coldspare>>和<<hotspare>>，则直接进行步骤(4)的操作；

(4)判断该模块的所有数据传递方向是否向外、推理是否重复

如果该模块是信息源即没有其他的模块传送信息给该模块，则将现在指针指向的节点变为基本事件，通过递归算法进行后续操作；

如果该模块仍接收其他模块传来的信息，那么则需判断该模块所有的关联模块是否都出现过；

(5)如果该模块的所有关联模块仍未完全遍历，那么向下生成一个或门，并添加一个该模块自身故障作为基本事件，表示该模块自身的失效也是导致模块失效的其中一个原因，然后添加该模块未出现过的关联模块故障，如果有多个则指针指向其中一个模块。

进一步地，所述的通过递归算法进行后续操作，包括：

所述递归算法的起点是判断node下一节点是否为空，node的下一节点指的是node同层的下一节点，在故障树中就是同层的另一模块；如果同层节点不为空，则指针将指向那个节点，完成递归回到故障树生成算法中继续进行分析。

如果同层的下一节点为空，则返回此节点的上一层即此节点的父节点，在此之前需要判断父节点是否为顶事件，如果父节点不是顶事件，那么将指针指向父节点，再检验父节点的同层节点是否已经分析完毕，如果未分析完毕，则指针移至未分析节点继续回到故障树生成算法中进行分析；

整个故障树生成算法会不断的进入上述递归算法中，直到判断出父节点是顶事件，则不用在进行循环判断下一节点是否为空，返回顶节点。

由上述本发明的实施例提供的技术方案可以看出，本发明实施例提出的方法将安全分析有关信息嵌入系统设计模型中去，便于设计人员进行基于模型的开发及分析，为其提供了极大的自由度和灵活性。解析了模型文件语义，实现了从建模工具到故障树生成软件之间的数据交互，为实现自动转换功能奠定了基础。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种从uml模型到动态故障树的自动转换过程示意图；

图2为本发明实施例提供的一种uml模型信息的提取算法的处理流程示意图；

图3为本发明实施例提供的一种动态故障树生成算法步骤示意图；

图4为本发明实施例提供的一种动态故障树生成算法中的递归算法流程图；

图5为本发明实施例提供的一种uml模型到动态故障树自动生成软件界面示意图。

具体实施方式

下面详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。

为便于对本发明实施例的理解，下面将结合附图以几个具体实施例为例做进一步的解释说明，且各个实施例并不构成对本发明实施例的限定。

本发明实施例设计了一套安全苛求系统扩展uml(unifiedmodelinglanguage，统一建模语言)模型的设计及故障树求解算法，使系统设计更加有效、准确，设计者和安全分析人员能进行一个完全的设计分析过程。在系统设计阶段，安全分析能够与系统设计并行从而确定所有可能的危害。在系统设计阶段能够马上分析出威胁系统安全的各种设计故障，检验系统能不能按照设计要求运行，进而设计者就可以决定是否需要重新设计以及需要改进原有的哪些不合理设计，这样设计时间和资源就会大大缩短。

本发明实施例使用了工程实践中设计人员更方便使用的统一建模语言uml来描述系统设计模型，并引入了构造型的方法来扩展uml模型，使uml模型能更好地描述安全苛求系统的特征。采用国际公认的故障树分析法对其进行安全分析，并在原有故障树分析法基础上加入了冷备门和热备门两种动态逻辑门形成动态故障树模型，以解决传统分析方法不能很好的描述安全苛求系统冗余特点的问题。然后，针对扩展后的uml模型生成的模型文件进行解析开发了一个将uml模型转换为动态故障树的自动转换算法。从uml模型到动态故障树的转化示意图可以参考图1。此研究为uml模型进行自动化分析奠定了良好的基础，设计师们可以在设计模型中加入自己的安全标准，而安全工程师们也能很好的了解设计师所要表达的安全理念，提高了安全苛求系统的可靠性和安全性，降低了开发和设计成本。

图1为本发明实施例提供的一种从uml模型到动态故障树的自动转换过程示意图。从参考图1可以看出，该转换过程包括三部分的工作：uml建模与扩展方法、模型信息提取算法和故障树生成算法。

1：uml建模与扩展方法

本发明实施例使用了观感更直观的类图来对系统结构关系进行逻辑建模。系统中的每个组件可以看作是类中的一个带有属性和操作的例子。各组件的可靠性信息(如失效率、分布等)可以在类图的属性中表示出来。每个系统组件传递的信息以类的操作的方法名的形式体现出来，可以表明信息如何在类图中传输的。

类的基数的扩展方法如下：

类图还允许设计者指明类的基数，相当于间接指明了系统的冗余结构。关联、聚合和组合这几种关系是有基数的，连线两端的数字表明这一端的类可以有几个实例。类是具有相似结构、行为和关系的一组对象的描述符，基数清晰地描述了此类中存在的相似对象的数目。组件实例的数目存在于系统运行时的类结构体本身。

类的关系的扩展方法如下：

在本发明的建模方法中，关联关系用于表示系统组件之间的信息交互，关联的方向代表着组件之间信息交互的方向。

依赖关系用带箭头的虚线表示，箭头方向由依赖的一方指向被依赖的一方。依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，表示一个事物使用另一个事物。

组合关系用带实心菱形的实线表示，菱形指向整体，用于表示某大型平台与该平台下的子系统之间的关系。

本发明实施例使用了构造型来扩展uml对系统故障描述的语义，便于设计人员进行基于模型的开发及分析。

表1提供了一个语义对照表，用来确定模型中的元素、关联和构造型语义以及相对应的故障树实现方法。

表1uml与动态故障树之间的语义对照

差错传播可以发生在两个或多个组件之间，一个组件中发生的差错由于组件间的关联关系会传播至另一个组件。所以用到了<<propagateserrorto>>这个语义来表示差错传播路径。<<propagateserrorto>>依赖于类图中的关联关系，是类图中关联关系的构造型，同关联的方向有关。如果关联是双向的，那么差错传播就是双向的。如果关联是单向的，那么差错传播就是单向的。

备用组件可以为主组件提供冗余功能，由于冗余组件具有和主件相似的结构和行为，所以主备组件都被归为一类。表中定义了<<coldspare>>、<<hotspare>>和<<warmspare>>构造型来表明该类的备用性质。从备份的方式分，备用分为冷备、热备、温备。热备时刻处于运行状态，并与主件保持同步。当主件不可用时，热备可以立即自动接替主件而不中断服务。

<<substitutesfor>>用来描述不同组件之间的冷备关系，与依赖关系一起使用，箭头从冷备组件指向主要主件。如果主件出现了故障，那么冷备可以代替主件继续工作，使系统能够继续运行不至失控。这种表示方法的最大优点在于它能重现系统最真实的情景。比如各个子模块之间的关系，某组件出现故障之后其他组件所扮演的角色。

表中还定义了<<runson>>构造型来表明软硬件之间的映射关系。构造型<<runson>>与依赖关系一起使用，这种依赖性是由于软件在硬件上运行形成的，是单向的，箭头从依赖对象指向被依赖对象。

系统uml模型是在rationalsoftwarearchitect中构建的，其系统模型保存的格式为emx(expertmoldbaseextension，专家模架扩展)文件，模型的所有信息都存储在emx文件中，这个emx文件是可以访问的，其书写方式遵循xml(extensiblemarkuplanguage，指可扩展标记语言)标准，通过访问xml的方法将该emx文件中的系统结构信息和扩展语义提取出来。

uml模型信息的提取算法首先识别了uml模型在emx文件中的关键字表示方法，对系统结构进行编码载入emx文件，类图中的关联关系被用来获取系统结构。基数就被用来获取系统中组件的个数和系统中的冗余情况。表1中定义的构造型用于建立相应的故障树逻辑门。

图2为本发明实施例提供的一种uml模型信息的提取算法的处理流程示意图，下面对该算法步骤进行详细的解说说明。

(1)首先定义了xmi和uml的命名空间，使用openfiledialog控件来查找uml模型生成的emx文件，获取emx文件的文件路径以及文件名后，调用xdocument类的load()方法，载入emx文件至xdocumentdoc中。

(2)遍历doc中具有xmi:type＝"uml:class"属性的"packagedelement"元素字段，将遍历到的元素字段保存至varlistclass中。根据前面对emx文件中的语义进行的研究，已经知道具有"uml:class"属性的元素是uml模型中的类，所以通过这样的遍历方法将类识别出来。对于已经遍历到的模型的类需要获取以下信息：

类名称class_name[i]

类idclass_id[i]

类属性class_attribute[i]

类冗余信息class_csphsp[i]

类从属关系class_owned[i]

获取到元素中的以上信息之后还需获取与该类相连类的名称及相连类的数量，直到该元素的所有owenedattribute字段都遍历完。算法建立了一个classinfolist用来存储模型中的类的所有相关信息，所有packagedelement的上述信息都储存在classinfolist模块信息列表中。

(3)遍历doc中具有xmi:type＝"uml:dependency"属性的"packagedelement"元素字段，将遍历到的元素字段保存至varlistdependency中。"uml:dependency"是uml模型中依赖关系的属性，是一种较普通关联关系特殊的关系，因为依赖关系的两端分别是主件和备件关系，所以需要特殊处理。对于已经识别的依赖关系需要获取以下信息：

主模块idsupplier_id[j]

主模块名称supplier_name[j]

备模块idclient_id[j]

备模块名称client_name[j]

依赖关键字key_word[j]

与classinfolist相同，算法建立了dependencyinfolist，将遍历所有的依赖关系获得的信息存储在依赖信息列表中。

这样从模型中获得的所有信息都储存在了classinfolist模块信息列表和dependencyinfolist依赖信息列表中，供下章提出的故障树生成算法使用。

本发明实施例提供的一种从系统uml设计模型生成动态故障树的算法流程如图3所示，使用故障树生成算法自动生成动态故障树需要进行以下步骤：

(1)指定某模块失效作为故障树顶事件，生成模块失效的事件

首先需要在算法中指定uml模型中的某一模块的名称，将该模块失效并作为故障树的顶事件，从顶事件开始向外遍历。上述模块指uml模型中的类。

(2)获取模块信息

从上节中获取到的模型信息中抽取与该模块相关的信息，如构造型、直接关联的类等。

(3)判断该模块是否具有冷备或热备

从获取到的模块信息中，判断是否存在构造型<<coldspare>>和<<hotspare>>，如果存在<<coldspare>>就生成冷备门且向下生成两个中间事件：该模块1失效和该模块2失效，并且把(2)中获取的该类的信息去除<<coldspare>>后分别赋予到这两个中间事件上，同时指针指向中间事件：”该模块1失效”。然后返回上一步获取模块信息。同理，如果存在<<hotspare>>就生成热备门且向下生成两个中间事件：该模块1失效和该模块2失效，并且把(2)中获取的该类的信息去除<<hotspare>>分别赋予到这两个中间事件上。同时指针指向中间事件：”该模块1失效”。然后返回上一步获取模块信息。如果该模块不存在<<coldspare>>和<<hotspare>>信息，则直接进行步骤(4)的操作。

(4)判断该模块的所有数据传递方向是否向外及推理是否重复

在经历了再一次的冷备门和热备门的判断之后，由于具有热备门和冷备门的属性已经在赋值时被剔除，而不具有冷备和热备的将直接向下一步进行，所以此时应判断该模块的所有数据传递方向是否是向外的，即是否还有别的关联模块传递失效给该模块。

如果该模块是信息源即没有其他的模块传送信息给该模块，则将现在指针指向的节点变为基本事件(圆圈)，再通过一个递归算法进行后续操作。递归算法将在步骤(6)中给出详细解释。

如果该模块仍接收其他模块传来的信息，那么则需判断该模块所有的关联模块是否都出现过，这个步骤是遵循了“推理不重复”原则，不能对已经推理过的模块进行重复推理。如果省略了这个步骤，整个算法将会陷入死循环中。

(5)判断该模块所有关联模块是否出现过——否

如果该模块的所有关联模块仍未完全遍历，那么向下生成一个或门，并添加一个该模块自身故障作为基本事件，表示该模块自身的失效也是导致模块失效的其中一个原因。然后添加该模块未出现过的关联模块故障，如果有多个则指针指向其中一个模块。

接着返回之前的步骤“获取模块信息”来获取该未出现过的关联模块的相关信息，经过与上述相同的一系列步骤，直到进入递归算法中。

(6)递归算法

本发明实施例提供的一种递归算法的过程如图4所示，算法的起点是判断node下一节点是否为空，node的下一节点指的是node同层的下一节点，在故障树中就是同层的另一模块。如果同层节点不为空，那么就是说同层中仍有模块未分析完毕，那么指针将指向那个节点，完成递归回到故障树生成算法中继续进行分析。

如果同层下一节点为空，意味着这层的所有节点都已经分析完毕，那么返回此节点的上一层即此节点的父节点，在此之前需要判断父节点是否为顶事件，如果父节点不是顶事件，那么将指针指向父节点，再检验父节点的同层节点是否已经分析完毕，如果未分析完毕的话则指针移至未分析节点继续回到故障树生成算法中进行分析。整个故障树生成算法会不断的进入此递归算法中，直到判断出父节点是顶事件，那么就不用在进行循环判断下一节点是否为空，返回顶节点。回到故障树生成算法中后，再次判断节点是否为顶节点，答案是肯定的，整个分析过程结束。

uml模型到故障树自动生成软件的设计与实现如下：

为了简化uml文件读取和故障树顶事件定义步骤，提升用户操作体验，更方便快捷地实现uml到动态故障树的转化过程，本发明设计了一个uml模型到故障树自动生成的软件，将第2节中的模型信息提取方法使用c#编码实现，开发工具使用的是microsoftvisualstudio2012，uml模型到故障树自动生成软件的整体功能分为两个部分，第一部分是uml模型的emx文件的选取和解析，第二部分是定义故障树的顶事件，按照上面描述的故障树生成算法生成动态故障树。

图5中所示的软件界面就是uml模型到故障树的自动生成软件，在软件主界面点击“新建”来建立一个项目，通过左侧的项目资源管理器可以查看已经建立的项目。建立了项目之后点击“选取文件”来查找所需要载入的某个uml模型的emx文档，获取所需要的文件路径以及文件名之后，点击“读取信息”，当读取成功前面被选中，那么emx文档中的逻辑结构及故障的信息就被存入软件中了。此时可以选择一个故障树顶事件，输入“顶事件名”，点击“生成故障树”，那么软件内部的动态故障树生成算法启动，生成的故障树将显示在下方的“故障树显示框”内，当故障树体积过于庞大显示不全时，可以双击全屏显示。软件目前提供“保存”或“导出”为图片格式(jpg/jpeg/png)故障树的功能。

此处需要特别说明的是，该软件目前并不能绘制树状的故障树，只能在软件显示区域显示如上图所示的一个折叠菜单，可以点开前面的+/-号来展开或收起某个分支。折叠菜单的每一行都是一个基本事件或中间事件还有其连接的逻辑门(包括动态逻辑门和静态逻辑门)。点选某个事件的名称可以打开这个事件下的所有分支。虽然这并不是安全工程师普遍认知的树状故障树形式，但是这种形式足以充分描述产生的故障树了。

综上所述，本发明实施例针对标准uml方法对系统安全方面的描述缺陷，提出一种与故障树生成相关的系统uml模型扩展方法，使用了构造型来扩展uml对系统冗余结构的描述并提供一个语义对照表，用来确定模型中的元素、关联和构造型语义以及相对应的故障树实现方法，成功地将安全分析有关信息嵌入到系统模型中去，便于设计人员进行基于模型的开发及分析，为其提供了极大的自由度和灵活性。

本发明实施例提出的方法围绕模型文件emx进行分析，对根据上面提出的扩展方法建立的模型生成的模型文件内容进行解析，分析其中所包含的模型文件语义，确定需要提取的元素节点，成功地解析了模型文件语义，实现了从建模工具到故障树生成软件之间的数据交互，为实现自动转换功能奠定了基础。

本发明实施例提出的方法结合uml模型与故障树在描述系统因果影响关系方面的相似性和安全苛求系统的冗余特征，成功地实现了系统设计模型与系统安全模型之间的自动转换，并将故障树自动生成算法落实到软件层面，极大的方便了用户的使用。

本领域普通技术人员可以理解：附图只是一个实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。