CN104679510B - 安全苛求系统的扩展uml类图模型的故障树生成方法 - Google Patents

Abstract

本发明实施例提供了一种安全苛求系统的扩展UML类图模型的故障树生成方法。该方法包括：构造安全苛求系统的UML类图模型，UML类图模型中的各个类包含属性和操作,各个类之间存在一定的关系，使用了构造型来扩展模型元素语义；将UML类图模型保存为设定格式的文件，按照设定的信息提取算法对UML类图模型对应的设定格式的文件进行解析，提取UML类图模型的UML类图模型中的各个类和各个类对应的属性和操作信息，基于设定的故障树生成算法生成所述UML类图模型对应的故障树。本发明实施例成功地将安全分析有关信息嵌入到安全苛求系统的设计模型中去，实现了系统设计模型与系统安全模型之间的自动转换，可以有效地克服安全苛求系统的设计型故障。

Description

安全苛求系统的扩展UML类图模型的故障树生成方法

技术领域

本发明涉及安全苛求系统技术领域，尤其涉及一种安全苛求系统的扩展UML类图模型的故障树生成方法。

背景技术

安全苛求系统对组成系统的软件和硬件安全级别要求很高，其出现故障后可能会导致重大的生命、财产损失。为了避免人员伤亡、降低经济损失，安全苛求系统在设计和研发过程中必须慎之又慎。但是即使如此，由于设计工程师对于系统特性、行为等认识理解的局限性以及系统复杂、频繁的交互和协作，安全苛求系统内及安全苛求系统与环境间不可避免地会产生一系列的缺陷或故障。相对于其它类型的故障，这些故障对系统安全危害更大，隐藏的更深，对其检测和消除的难度也更高，本发明实施例将其称为设计型故障，设计型故障已经成为安全苛求系统不安全的一个主要原因。

大部分安全苛求系统的设计型故障只有在系统研发后期才会被发现，而当错误发生之后用来纠正这些错误的花费是相当耗费成本的。这些都为安全工程师们对安全苛求系统进行安全分析带来了巨大的挑战。

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

发明内容

本发明的实施例提供了一种安全苛求系统的扩展UML类图模型的故障树生成方法，以实现有效地克服安全苛求系统的设计型故障。

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

构造安全苛求系统的UML类图模型，所述UML类图模型中的各个类包含属性和操作；

将所述UML类图模型保存为设定格式的文件，按照设定的信息提取算法对所述UML类图模型对应的设定格式的文件进行解析，提取所述UML类图模型的UML类图模型中的各个类和各个类对应的属性和操作信息；

根据所述各个类和各个类对应的属性和操作信息，基于设定的故障树生成算法生成所述UML类图模型对应的故障树。

优选地，所述的构造安全苛求系统的UML类图模型，所述UML类图模型中的各个类包含属性和操作，包括：

使用UML语言构造安全苛求系统的UML类图模型，所述UML类图模型中的各个类表示相同组件的集合，每个类包含属性、操作和基数，所述安全苛求系统中的每个组件对应类中的一个带有属性和操作的例子，所述类的基数描述此类中存在的相似对象的数目,所述类的基数存在于关联关系、依赖关系和组合关系中，所述关联关系用于表示所述安全苛求系统中的组件之间的信息交互，所述依赖关系用于表示所述安全苛求系统中的元素之间的使用关系，所述组合关系用于表示所述安全苛求系统中的平台与该平台下的子系统之间的关系。

优选地，设置冷备构造型、热备构造型和温备构造型来表明一个类的备用属性，所述热备构造型表示当主用组件不可用时，热备组件自动接替主用组件,所述温备构造型表示温备组件处于加点代用状态，并周期性同步复制或镜像主用组件，当主用组件不可用时，需要经过一定时间后切换到温备组件；所述冷备构造型表示冷备组件处于不加电待用状态，当主用组件不可用时，冷备组件经过启动、备份数据导入后，切换到冷备组件。

优选地，所述的方法还包括：

设置所述UML类图模型元素、构造型语义和动态故障树元素之间的对应关系，所述对应关系包括：

优选地，所述的UML类图模型元素、构造型语义和动态故障树元素之间的对应关系还包括：

优选地，所述的将所述UML类图模型保存为设定格式的文件，按照设定的信息提取算法对所述UML类图模型对应的设定格式的文件进行解析，提取所述UML类图模型的UML类图模型中的各个类和各个类对应的属性和操作信息、类之间的关系和构造型，包括：

将所述UML类图模型保存为遵循XML格式的文件，通过访问XML的方法识别所述文件中的关键字，通过遍历所述文件中的类元素对应的关键字识别出所述文件中的所有类，并且提取每个类对应的标识、属性、冗余信息和从属关系，将每个类和每个类对应的标识、属性、冗余信息和从属关系存储在类模块信息列表中；

通过遍历所述文件中的依赖元素对应的关键字识别出所述文件中的所有依赖关系，并且提取每个依赖关系对应的主模块标识、主模块名称、备模块标识、备模块名称和依赖关键字，将每个依赖关系和每个依赖关系对应的标识、属性、冗余信息和从属关系存储在依赖关系信息列表中。

优选地，所述的根据所述各个类和各个类对应的属性和操作信息，基于设定的故障树生成算法生成所述UML类图模型对应的故障树，包括：

指定所述UML类图模型中的某一类模块失效，将所述某一类模块失效作为动态故障树的顶事件，根据所述某一类模块查询所述类模块信息列表，获取所述某一类模块对应的属性、操作、基数信息和关联信息，根据所述某一类模块查询所述依赖关系信息列表，获取所述某一类模块对应的构造型信息；

根据所述某一类模块对应的属性、操作、基数信息、关联信息和构造型信息，按照设定的故障树生成算法生成所述UML类图模型对应的故障树。

优选地，所述的根据所述某一类模块对应的属性、操作、基数信息、关联信息和构造型信息，按照设定的故障树生成算法生成所述UML类图模型对应的故障树，包括：

步骤1、根据所述某一类模块对应的构造型信息，判断所述某一类模块是否存在冷备构造型或热备构造型，如果存在，则生成子模块，该子模块继承所述某一类模块的除了构造型信息之外的全部信息，执行步骤2；否则，执行步骤2；

步骤2、判断所述某一类模块或者子模块的所有数据传递方向是否是向外传递，如果是，则将所述某一模块设为基本失效事件，以所述某一类模块或者子模块为起点节点，通过设定的递归算法完成故障树的生成过程；否则，执行步骤3；

步骤3、判断所述某一类模块或者子模块的所有关联模块是否完全遍历，如果否，则生成一个或门，添加所述某一类模块或者子模块的自身故障作为基本事件，添加所述某一类模块或者子模块未遍历过的关联模块故障，并指定其中一个故障关联模块，根据所述故障关联模块查询所述类模块信息列表，获取所述故障关联模块对应的属性、操作和基数信息，根据所述故障关联模块查询所述依赖关系信息列表，获取所述故障关联模块对应的构造型信息，执行步骤1，继续执行上述动态故障树的生成过程。

优选地，所述的以所述某一类模块或者子模块为起点节点，通过设定的递归算法完成故障树的生成过程，还包括：

当所述起点节点同层的下一节点不为空，则指针指向所述下一节点，根据所述下一节点查询所述类模块信息列表，获取所述下一节点对应的属性、操作和基数信息，根据所述下一节点查询所述依赖关系信息列表，获取所述下一节点对应的构造型信息，执行步骤1；

当所述起点节点同层的下一节点为空，则指针指向所述起点节点的父节点，判断所述父节点是否为顶事件，如果是，则所述递归算法结束，完成故障树生成过程；否则，检查所述父节点的同层节点是否已经分析完毕，如果未分析完毕，则指针指向未分析节点，指定所述未分析节点失效，根据所述未分析节点查询所述类模块信息列表，获取所述未分析节点对应的属性、操作和基数信息，根据所述未分析节点查询所述依赖关系信息列表，获取所述未分析节点对应的构造型信息，执行步骤1，继续执行上述动态故障树的生成过程。

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

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

附图说明

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

图1为本发明实施例提供的一种安全苛求系统的扩展UML类图模型的故障树生成方法的实现原理示意图；

图2为本发明实施例提供的一种安全苛求系统的扩展UML类图模型的故障树生成方法的处理流程图；

图3为本发明实施例提供的一种UML类图模型信息提取算法的处理流程图；

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

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

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

具体实施方式

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

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

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

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

本发明实施例提供了的一套安全苛求系统的扩展UML(Unified ModelingLanguage，统一建模语言)模型的设计及故障树求解算法，采用国际公认的故障树分析法对扩展UML类图模型进行安全分析，并在原有故障树分析法基础上加入了冷备门和热备门两种动态逻辑门形成动态故障树模型，以解决传统分析方法不能很好地描述安全苛求系统冗余特点的问题。然后，针对扩展后的模型生成的模型文件进行解析开发了一个将UML类图模型转换为动态故障树的自动转换算法。

该实施例提供了一种安全苛求系统的扩展UML类图模型的故障树生成方法的实现原理示意图如图1所示，具体处理流程如图2所示，包括如下的处理步骤：

步骤S210、构造安全苛求系统的基于类图的UML类图模型。

使用了工程实践中设计人员更方便使用的UML来描述系统的设计模型，并引入了构造型的方法来扩展UML类图模型使其能更好的描述安全苛求系统的特征。使用UML语言构造安全苛求系统的UML类图模型，使用了观感更直观的类图来对系统结构关系进行逻辑建模。

UML类图模型中的各个类表示相同组件的集合，每个类包含属性、操作和基数。安全苛求系统中的每个组件对应类中的一个带有属性和操作的例子，各组件的可靠性信息(如失效率、分布等)可以在类图的属性中表示出来，每个系统组件传递的信息以类的操作的方法名的形式体现出来。

类图还允许指明类的基数，相当于间接指明了系统的冗余结构。类的基数存在于关联关系、依赖关系和组合关系中，关联关系用于表示系统组件之间的信息交互，关联的方向代表着组件之间信息交互的方向。依赖关系用带箭头的虚线表示，箭头方向由依赖的一方指向被依赖的一方。依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，表示一个事物使用另一个事物。组合关系用带实心菱形的实线表示，菱形指向整体，用于表示某大型平台与该平台下的子系统之间的关系。

类是具有相似结构、行为和关系的一组对象的描述符，连线两端的数字表明这一端的类可以有几个实例。基数清晰的描述了此类中存在的相似对象的数目。组件实例的数目存在于系统运行时的类结构体本身。

步骤S220、使用构造型扩展故障描述语义，设置UML类图模型元素、构造型语义和动态故障树元素之间的对应关系。

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

设置UML类图模型元素、构造型语义和动态故障树元素之间的对应关系，上述对应关系如下述表1所示：

表1

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

备用组件可以为主组件提供冗余功能，由于冗余组件具有和主件相似的结构和行为，所以主备组件都被归为一类。表中定义了<<coldSpare>>、<<hotSpare>>和<<warmSpare>>构造型来表明该类的备用性质。从备份的方式分，备用分为冷备、热备、温备。热备时刻处于运行状态，并与主件保持同步。当主件不可用时，热备可以立即自动接替主件而不中断服务。温备组件处于加点代用状态，并周期性同步复制或镜像主用组件。当主用组件不可用时，需要经过一定时间，才能切换到温备组件。冷备组件处于不加电待用状态，但在需要时能够启用。当主用组件不可用时，需要经过较长时间，冷备组件完成启动、备份数据导入后，才能切换到冷备组件。

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

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

步骤S230、将UML类图模型保存为设定格式的文件，按照设定的信息提取算法对UML类图模型对应的设定格式的文件进行解析，提取所述UML类图模型的UML类图模型中的各个类和各个类对应的属性和操作信息。

系统UML类图模型是在Rational Software Architect中构建的，其系统模型保存的格式为EMX，模型的所有信息都存储其中，这个EMX文件是可以访问的，其书写方式遵循XML(ExteileMarkuLaguage，扩展性标识语言)标准，通过访问XML的方法将该EMX文件中的系统结构信息和扩展语义提取出来。

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

上述通过遍历所述文件中的类元素对应的关键字识别出所述文件中的所有类，并且提取每个类对应的标识、属性、冗余信息和从属关系，将每个类和每个类对应的标识、属性、冗余信息和从属关系存储在类模块信息列表中。通过遍历所述文件中的依赖元素对应的关键字识别出所述文件中的所有依赖关系，并且提取每个依赖关系对应的主模块标识、主模块名称、备模块标识、备模块名称和依赖关键字，将每个依赖关系和每个依赖关系对应的标识、属性、冗余信息和从属关系存储在依赖关系信息列表中。

该实施例提供的一种UML类图模型信息提取算法的处理流程图如图3所示，下面对该算法步骤进行详细的解说说明。

(1)首先定义了XMI和UML的命名空间，使用openFileDialog控件来查找模型生成的EMX文件，获取其文件路径以及文件名后，调用XDocument类的Load()方法，载入EMX文件至XDocument doc中。

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

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

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

与ClassInfoList相同，算法建立了DependencyInfoList，将遍历所有的依赖关系获得的信息存储在依赖信息列表中。这样从模型中获得的所有信息都储存在了ClassInfoList模块信息列表和DependencyInfoList依赖信息列表中，供下章提出的故障树生成算法使用。

步骤S240、根据各个类和各个类对应的属性和操作信息，基于设定的故障树生成算法生成UML类图模型对应的动态故障树。

指定所述UML类图模型中的某一类模块失效，将所述某一类模块失效作为动态故障树的顶事件，根据所述某一类模块查询所述类模块信息列表，获取所述某一类模块对应的属性、操作、基数信息和关联关系，根据所述某一类模块查询所述依赖关系信息列表，获取所述某一类模块对应的构造型信息；

根据上述某一类模块对应的属性、操作、基数信息、关联关系和构造型信息，按照设定的故障树生成算法生成所述UML类图模型对应的动态故障树。该故障树生成算法主要包括：

步骤1、根据所述某一类模块对应的构造型信息，判断所述某一类模块是否存在冷备构造型或热备构造型，如果存在，则生成子模块，该子模块继承所述某一类模块的除了构造型信息之外的全部信息，执行步骤2；否则，执行步骤2；

步骤2、判断所述某一类模块或者子模块的所有数据传递方向是否是向外传递，如果是，则将所述某一类模块设为基本失效事件，以所述某一类模块或者子模块为起点节点，通过设定的递归算法完成故障树的生成过程；否则，执行步骤3；

步骤3、判断某一类模块或者子模块的所有关联模块是否完全遍历，如果否，则生成一个或门，添加所述某一类模块或者子模块的自身故障作为基本事件，添加所述某一类模块或者子模块未遍历过的关联模块故障，并指定其中一个故障关联模块，根据所述故障关联模块查询所述类模块信息列表，获取所述故障关联模块对应的属性、操作和基数信息，根据所述故障关联模块查询所述依赖关系信息列表，获取所述故障关联模块对应的构造型信息，执行步骤1，继续执行上述动态故障树的生成过程。

该实施例提供的一种动态故障树生成算法的处理流程图如图4所示，包括如下的处理过程；

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

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

(2)获取模块信息

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

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

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

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

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

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

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

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

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

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

(6)递归算法

该实施例提供的一种动态故障树生成算法中的递归算法流程图递归算法的过程如图5所示，算法的起点是判断起点节点Node下一节点是否为空，Node的下一节点指的是Node同层的下一节点，在故障树中就是同层的另一模块。如果同层节点不为空，那么就是说同层中仍有模块未分析完毕，那么指针将指向那个节点，根据那个节点查询类模块信息列表，获取那个节点对应的属性、操作和基数信息，根据那个节点查询依赖关系信息列表，获取那个节点对应的构造型信息，执行上述步骤1，继续故障树生成算法中继续进行分析。

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

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

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

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

综上所述，本发明实施例提出的安全苛求系统的扩展UML类图模型的故障树生成方法成功地将安全分析有关信息嵌入到安全苛求系统的设计模型中去，便于设计人员进行基于模型的开发及分析，为其提供了极大的自由度和灵活性。该方法成功地解析了模型文件语义，实现了从建模工具到故障树生成软件之间的数据交互，为实现自动转换功能奠定了基础。该方法成功地实现了系统设计模型与系统安全模型之间的自动转换，并将故障树自动生成算法落实到软件层面，极大地方便了用户的使用。应用本发明实施例的方法，可以有效地克服安全苛求系统的设计型故障。

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

本发明实施例为UML类图模型进行自动化分析奠定了良好的基础，设计师们可以在设计模型中加入自己的安全标准，而安全工程师们也能很好的了解设计师所要表达的安全理念，提高了安全苛求系统的可靠性和安全性，降低了开发和设计成本。

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

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

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

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

Claims (7)

1.一种安全苛求系统的扩展UML类图模型的故障树生成方法，其特征在于，包括：

使用UML语言构造安全苛求系统的UML类图模型，所述UML类图模型中的各个类表示相同组件的集合，每个类包含属性、操作和基数，所述安全苛求系统中的每个组件对应类中的一个带有属性和操作的例子，所述类的基数描述此类中存在的相似对象的数目,所述类的基数存在于关联关系、依赖关系和组合关系中，所述关联关系用于表示所述安全苛求系统中的组件之间的信息交互，所述依赖关系用于表示所述安全苛求系统中的元素之间的使用关系，所述组合关系用于表示所述安全苛求系统中的平台与该平台下的子系统之间的关系；

设置所述UML类图模型元素、构造型语义和动态故障树元素之间的对应关系，所述对应关系包括：

将所述UML类图模型保存为设定格式的文件，按照设定的信息提取算法对所述UML类图模型对应的设定格式的文件进行解析，提取所述UML类图模型的UML类图模型中的各个类和各个类对应的属性和操作信息；

根据所述各个类和各个类对应的属性和操作信息，基于设定的故障树生成算法生成所述UML类图模型对应的故障树。

2.根据权利要求1所述的安全苛求系统的扩展UML类图模型的故障树生成方法，其特征在于，设置冷备构造型、热备构造型和温备构造型来表明一个类的备用属性，所述热备构造型表示当主用组件不可用时，热备组件自动接替主用组件；所述温备构造型表示温备组件处于加点代用状态，并周期性同步复制或镜像主用组件，当主用组件不可用时，需要经过一定时间后切换到温备组件；所述冷备构造型表示冷备组件处于不加电待用状态，当主用组件不可用时，冷备组件经过启动、备份数据导入后，切换到冷备组件。

3.根据权利要求2所述的安全苛求系统的扩展UML类图模型的故障树生成方法，其特征在于，所述的UML类图模型元素、构造型语义和动态故障树元素之间的对应关系还包括：

。

4.根据权利要求1至3任一项所述的安全苛求系统的扩展UML类图模型的故障树生成方法，其特征在于，所述的将所述UML类图模型保存为设定格式的文件，按照设定的信息提取算法对所述UML类图模型对应的设定格式的文件进行解析，提取所述UML类图模型的UML类图模型中的各个类和各个类对应的属性和操作信息、类之间的关系和构造型，包括：

将所述UML类图模型保存为遵循XML格式的文件，通过访问XML的方法识别所述文件中的关键字，通过遍历所述文件中的类元素对应的关键字识别出所述文件中的所有类，并且提取每个类对应的标识、属性、冗余信息和从属关系，将每个类和每个类对应的标识、属性、冗余信息和从属关系存储在类模块信息列表中；

通过遍历所述文件中的依赖元素对应的关键字识别出所述文件中的所有依赖关系，并且提取每个依赖关系对应的主模块标识、主模块名称、备模块标识、备模块名称和依赖关键字，将每个依赖关系和每个依赖关系对应的标识、属性、冗余信息和从属关系存储在依赖关系信息列表中。

5.根据权利要求4所述的安全苛求系统的扩展UML类图模型的故障树生成方法，其特征在于，所述的根据所述各个类和各个类对应的属性和操作信息，基于设定的故障树生成算法生成所述UML类图模型对应的故障树，包括：

指定所述UML类图模型中的某一类模块失效，将所述某一类模块失效作为动态故障树的顶事件，根据所述某一类模块查询所述类模块信息列表，获取所述某一类模块对应的属性、操作、基数信息和关联信息，根据所述某一类模块查询所述依赖关系信息列表，获取所述某一类模块对应的构造型信息；

根据所述某一类模块对应的属性、操作、基数信息、关联信息和构造型信息，按照设定的故障树生成算法生成所述UML类图模型对应的故障树。

6.根据权利要求5所述的安全苛求系统的扩展UML类图模型的故障树生成方法，其特征在于，所述的根据所述某一类模块对应的属性、操作、基数信息、关联信息和构造型信息，按照设定的故障树生成算法生成所述UML类图模型对应的故障树，包括：

步骤1、根据所述某一类模块对应的构造型信息，判断所述某一类模块是否存在冷备构造型或热备构造型，如果存在，则生成子模块，该子模块继承所述某一类模块的除了构造型信息之外的全部信息，执行步骤2；否则，执行步骤2；

步骤2、判断所述某一类模块或者子模块的所有数据传递方向是否是向外传递，如果是，则将所述某一模块设为基本失效事件，以所述某一类模块或者子模块为起点节点，通过设定的递归算法完成故障树的生成过程；否则，执行步骤3；

步骤3、判断所述某一类模块或者子模块的所有关联模块是否完全遍历，如果否，则生成一个或门，添加所述某一类模块或者子模块的自身故障作为基本事件，添加所述某一类模块或者子模块未遍历过的关联模块故障，并指定其中一个故障关联模块，根据所述故障关联模块查询所述类模块信息列表，获取所述故障关联模块对应的属性、操作和基数信息，根据所述故障关联模块查询所述依赖关系信息列表，获取所述故障关联模块对应的构造型信息，执行步骤1，继续执行上述动态故障树的生成过程。

7.根据权利要求6所述的安全苛求系统的扩展UML类图模型的故障树生成方法，其特征在于，所述的以所述某一类模块或者子模块为起点节点，通过设定的递归算法完成故障树的生成过程，还包括：

当所述起点节点同层的下一节点不为空，则指针指向所述下一节点，根据所述下一节点查询所述类模块信息列表，获取所述下一节点对应的属性、操作和基数信息，根据所述下一节点查询所述依赖关系信息列表，获取所述下一节点对应的构造型信息，执行步骤1；

当所述起点节点同层的下一节点为空，则指针指向所述起点节点的父节点，判断所述父节点是否为顶事件，如果是，则所述递归算法结束，完成故障树生成过程；否则，检查所述父节点的同层节点是否已经分析完毕，如果未分析完毕，则指针指向未分析节点，指定所述未分析节点失效，根据所述未分析节点查询所述类模块信息列表，获取所述未分析节点对应的属性、操作和基数信息，根据所述未分析节点查询所述依赖关系信息列表，获取所述未分析节点对应的构造型信息，执行步骤1，继续执行上述动态故障树的生成过程。