CN109032945A - 一种软件可靠性工程集成环境框架设计方法 - Google Patents

Abstract

本发明提出一种软件可靠性工程集成环境框架设计方法，属于软件可靠性工程领域。本发明包括：对软件可靠性工程中各项工作的数据进行统一建模；提取软件可靠性工程中各项工作的公共的数据管理需求、权限管理需求、公共界面需求和网络传输需求；集成环境采用C/S架构，客户端为各软件可靠性工作提供公共的数据管理、权限管理、界面管理及网络传输服务，并以插件模型的形式将各可靠性工具的独有功能集成起来，再通过服务器进行软件可靠性项目管理和数据交互，实现对各软件可靠性工作的综合集成。本发明实现的软件可靠性工程集成环境，支持脱机和联网两种工作状态，促进了软件可靠性工作的综合应用，提高了软件可靠性工作的效率。

Description

一种软件可靠性工程集成环境框架设计方法

技术领域

本发明属于软件可靠性工程领域，具体涉及软件可靠性要求确定、分配、早期预计、分析、设计、测试、评估等技术及其工具的软件可靠性工程集成环境框架系统。

背景技术

软件可靠性工程自上世纪80年代提出后，其中的各项技术均得到了迅速的发展[1]，包括软件可靠性要求确定技术、分配技术、早期预计技术、设计技术、分析技术(软件故障树分析、软件失效模式及影响分析等)、测试技术、评估技术、举证技术等[2,3]，国内外亦开发出了对于相应技术的支撑工具。

但是，目前的软件可靠性工程研究中仍存在如下问题：

第一，各项软件可靠性技术发展不均衡。

如软件可靠性评估技术，从Musa提出操作剖面的概念到如今，已经发展出了基于失效数据的软件可靠性评估、基于体系结构的软件可靠性评估等多种方法、多种评估模型，技术和工具成熟度均较高[3-7]。而软件可靠性要求确定技术则尚处于起步阶段，仅有少量的方法支撑[8,9]，未见相应的支撑工具。随着理论的提升，各个软件可靠性工具功能上的扩充变化也会较大。

第二，各项软件可靠性技术往往都是单独应用，缺乏综合应用，导致实践中需要大量的重复工作，效率低下。

例如，对于软件故障树分析(SFTA)与软件失效模式及影响分析(SFMEA)分别存在成熟的方法、商业化的应用软件。但是，实际上二者的分析结果应该且可以互相转化从而实现更加全面的分析[10]，如软件FMEA(失效模式与影响分析)分析出的失效模式、本单元影响、上层影响通常应进一步进行故障树分析，最终影响也应作为故障树的顶事件进一步进行故障树分析；同时，FTA(故障树分析)分析出的底事件也可作为FMEA对应模块的失效模式或失效原因。再如，软件可靠性分配的结果应作为软件可靠性评估的目标值，以实现软件可靠性要求的验证。

第三，缺乏支撑软件可靠性工程全生命周期、支撑各项软件可靠性工作开展、且支持各项软件可靠性工具不断扩充功能的软件可靠性工程集成环境及工具集。

在系统可靠性领域，已经出现了G-ARMS(RMS技术集成应用平台)、CARMES(工业和信息化部电子第五研究所,五性工程软件)、ReliaSoft Synthesis Master Suite、ITEM等支持系统可靠性各阶段工作的集成环境，但是其中的各项方法均与对应的软件可靠性技术存在一定的区别，其中的各项工具对软件可靠性工作的适用性不强。

在软件可靠性领域，国内外对于软件可靠性工程的集成工作研究较少。国防科技大学提出的基于模型的软件可靠性集成环境[11]面向的是基于组件的、采用模型驱动方法开发的软件系统，支持软件可靠性早期预计、测试、评估等工作，但是其支持的软件对象范围较为特定，且无法支持软件可靠性要求确定、指标分配、分析、设计等工作。

因此，有必要对软件可靠性工程中的各项技术及工具进行综合集成，以实现贯穿生命周期的软件可靠性保障工作。

参考文件：

[1]MR Lyu,Handbook of software reliability engineering[M],《SoftwareIEEE》,1996,18(3):98-98.

[2]MR Lyu,Software Reliability Engineering:A Roadmap[J],Future ofSoftware Engineering,2007:153-170.

[3]Xavier J,Macêdo A,Matias R,et al.A Survey on Research in SoftwareReliability Engineer-ing in the Last Decade[C].Acm Symposium on AppliedComputing,2014:1190-1191A.

[4]Pham H.System Software Reliability[M].Springer-Verlag New York,Inc.,2007.

[5]Chi J,Honda K,Washizaki H,et al.Defect Analysis and Prediction byApplying the Multistage Software Reliability Growth Model[C].20178thInternational Workshop on Empirical Software Engineering in Practice(IWESEP),2017.

[6]Caiuta R,Pozo A,Vergilio SR.Meta-learning Based Selection ofSoftware Reliability Models[J].Automated Software Engineering,2016,24(3):1-28.

[7]Peng KL,Huang CY.Reliability Evaluation of Service-orientedArchitecture Systems Considering Fault-tolerance Designs[J].Journal ofApplied Mathematics,2014.

[8]马永刚,李强,陈立哲等.基于MDA的指挥控制系统软件可靠性需求分析研究[C].//中国电子学会电子系统工程分会信息化理论学术研讨会,2008:374-376.

[9]Littlewood B,Strigini L.Software Reliability and Dependability:ARoadmap[C]Proceed-ings of the Conference on the Future of SoftwareEngineering.ACM,2000:175-188.

[10]张虹,姜明明,黄百乔.软件可靠性分析方法研究与应用[D].,2011.

[11]唐赞岳,毛晓光,王戟等.一个集成的软件可靠性工程环境[J].计算机工程与科学,2007,29(7):116-118.

发明内容

本发明通过对软件可靠性工程中各项工作间的数据交互分析和公共需求提取，提出了一种软件可靠性工程集成环境框架设计方法，设计开发了对应的环境框架，支持各软件可靠性工作间的数据交互、流程控制。所设计的集成环境可以有效地提高软件可靠性工作的开展效率，同时，统一的交互数据建模方法、客户端平台采用的插件模型也为各项技术及工具的演化提供了一定的扩充性、为业务流程变更提供了一定的灵活性。

本发明的软件可靠性工程集成环境框架设计方法，包括如下步骤：

步骤一，对软件可靠性工程中各项工作的数据进行统一建模。

数据模型中包括源工作项和交互数据，源工作项用于标识提供数据的工作项，交互数据用于存储源工作项提供的数据内容；交互数据至少包含1个子数据项，子数据项包括一个目标工作项、提供给该目标工作项的数据的版本、以及针对该目标工作项的输出数据；子数据项的目标工作项与源工作项不相同。

步骤二，提取软件可靠性工程中各项工作的公共需求，包括公共的数据管理需求、权限管理需求、公共界面需求、以及网络传输需求。

步骤三，根据公共网络传输需求，确定集成环境采用客户端/服务器架构。

构建客户端平台为各可靠性工具提供公共服务，将完成各项工作的软件可靠性工具以插件的形式插入到客户端平台中；客户端平台以主执行文件的形式为每个可靠性工具提供公共执行入口、以公用动态链接库的形式提供公共服务；各工具以动态链接库和配置文件的形式放置到插件区，由客户端平台运行时动态调用和加载。

所述的客户端平台上，设计有一个公共运行引擎，在公共运行引擎中设计三个业务管理器——工具管理器、工程管理器与服务管理器；其中，服务管理器提供工具服务、文件服务、工程服务、网络服务、UI服务和日志服务；工具管理器与工程管理器由服务管理器提供的工具服务与工程服务分别调用，用于对各软件可靠性工具的管理与工程数据的管理。

构建服务器端，服务器端包含服务器、数据库和服务器管理客户端三部分；服务器通过网络与各客户端和数据库相连；服务器端以配置文件的形式设置了交互数据的自动推送规则，当收到客户端传来的交互数据后，服务器端将读取自动推送规则，自动判断待接收的客户端是否在线，一旦目标客户端连接后进行自动数据推送。

本发明方法通过对软件可靠性工程各项技术数据交互的分析和建模，提出了交互数据统一建模方法，通过对各软件可靠性工程技术公共需求分析，提取了各软件可靠性工作的共性公共服务，以此为基础，提出了一种C/S架构的软件可靠性集成环境，该环境由客户端平台和服务器组成，客户端平台为各软件可靠性工作提供公共的数据管理、权限管理、界面管理及网络传输服务，并以插件模型的形式将各可靠性工具的独有功能集成起来，再通过服务器进行软件可靠性项目管理和数据交互，实现对各软件可靠性工作的综合集成。本发明与现有技术相比，具有以下明显优势：

(1)本发明设计的软件可靠性工程集成环境，既支持脱机状态下软件可靠性工具的单独使用，也支持联网状态下各项可靠性工作的综合集成，对不允许通过网络式软件进行可靠性工作的情况也适用；

(2)本发明提供的统一的交互数据建模方法以及客户端平台采用的插件模型支持更多软件可靠性工具的加入，对于随着单项软件可靠性技术的发展各工具可能存在的功能扩充也提供了有效的机制和较高的灵活性；

(3)本发明提出的软件可靠性工程集成环境将有助于推动软件可靠性工程各项工作的综合应用，实现软件可靠性工程各项工作的流程协调和数据共享，提高软件可靠性工作的开展效率。

附图说明

图1是本发明软件可靠性工程各项工作间数据流程示意图；

图2是本发明软件可靠性工程交互数据模型示意图；

图3是本发明软件可靠性工程集成环境C/S架构图；

图4是本发明的客户端平台的插件模型示意图图；

图5是本发明客户端平台业务逻辑结构图；

图6是本发明软件可靠性工具配置文件格式结构图；

图7是本发明公共界面框架示意图；

图8是本发明基础数据类型框图；

图9是本发明数据表设计框图；

图10是本发明服务器端体系结构设计结构图；

图11是本发明服务器端与客户端平台的业务流程定义结构图；

图12是本发明创建项目并添加项目基本信息框图；

图13是本发明添加项目参与人员并配置权限框图；

图14是本发明客户端联网时申请连接服务器框图；

图15是本发明客户端申请连接服务器端可靠性项目框图；

图16是本发明软件可靠性项目连接审批框图；

图17是本发明SFTA客户端上传本地数据至服务器流程图；

图18是本发明手动推送交互数据框图；

图19是目标客户端解析并显示交互数据框图。

具体实施方式

为了便于本领域普通技术人员理解和实施本发明，下面结合附图对本发明作进一步的详细描述。

现今的软件可靠性工程实践中，各项软件可靠性工程技术往往都是单独应用，缺乏综合应用的方法和环境支撑，导致实践中需要大量的重复工作，效率低下。本发明针对软件可靠性工程集成环境开展研究，通过对各软件可靠性工程技术交互数据的分析，提出了交互数据统一建模方法及软件可靠性工程数据流图，确定了软件可靠性工程集成环境的数据基础；通过对各软件可靠性工作的内容进行分析，提取了各软件可靠性工程技术的公共需求。以此为基础，本发明提出了一种C/S架构的软件可靠性工程集成环境框架系统，其中，以插件模型构造了软件可靠性工程通用客户端平台，为各软件可靠性工作提供公共的可靠性数据管理、权限管理、界面管理及网络传输服务，各软件可靠性工具以插件的形式插入客户端平台；再通过服务器及附属的服务器管理客户端进行软件可靠性项目管理和数据交互，实现了对各软件可靠性工作的综合集成。本发明提出的软件可靠性工程集成环境可以促进软件可靠性工作的综合应用、提高软件可靠性工作的效率。本发明的软件可靠性工程集成环境框架设计方法主要包括四个步骤，下面对各步骤进行说明。

步骤一，对软件可靠性工程中各项工作的数据进行统一建模。

为了实现软件可靠性工程中各项工作的集成，首先需要分析各项工作间的数据交互关系。

对于软件可靠性要求确定工作，其输出的定量要求可为可靠性分配各工作提供顶层目标，其输出的定性要求可为可靠性分析中的SFTA提供顶事件，为可靠性设计工作提供实例化的设计准则。

对于软件可靠性分配工作，其输出为各子系统和部件的可靠性分配结果：该结果可为可靠性设计工作中阶段准则的生成提供参考；为可靠性测试提供目标；为可靠性评估提供评价目标。

对于软件可靠性早期预计工作，其输出的预计结果可利用DPPM方法验证可靠性分配的合理性。

对于软件可靠性分析工作，其中故障树分析与失效模式及影响分析工作的结果可以互相转化；分析结果可为可靠性设计提供新的或实例化的设计准则；分析结果还可为可靠性测试工作中的剖面设计提供参考。

对于软件可靠性设计工作，其设计准则可为可靠性分析工作提供失效模式、失效原因等方面的参考。

对于软件可靠性测试工作，构造的操作剖面可为可靠性分配工作中基于操作剖面的分配方法提供Musa剖面；测试结果可为可靠性评估提供可靠性失效数据。

对于软件可靠性评估工作，评估结果可以反馈给可靠性测试，根据目标判断是否需要继续进行可靠性测试；最终评估结果还可以返回给可靠性早期预计工作，以验证早期预计的精度和合理性，为下一个可靠性项目中的早期预计工作的改善提供帮助；评估结果还可以返回给可靠性分配工作，给出分配值和实际值的差异，进而判断下一步的可靠性工程活动，还可以用于判断可靠性分配的合理性；

根据上述分析，绘制软件可靠性工程各项工作间的数据流图如图1所示。

利用XML schema，将软件可靠性交互数据统一建模，模型的格式如图2所示。该模型分为两大部分，包括源工作项和交互数据。

源工作项(SourceTool)用于标识提供数据的工作项，为软件可靠性要求确定、分配、早期预计、设计、分析、评估、测试、脚本转换等8个工作项之一。

交互数据(InterData)用于存储源工作项提供的数据内容。交互数据部分包含1至多个子数据项，每个子数据项包括一个目标工作项、提供给该目标工作项的数据的版本、针对该目标工作项的输出数据。子数据项的目标工作项，同样为8个工作项之一，但不能与源工作项相同。

所采用的数据模型实现了对不同工作间所需交互数据的统一描述，各软件可靠性工作及支撑工具可利用该模型对交互数据进行建模，为后续的集成工作提供基础。

步骤二，软件可靠性工程公共需求分析。各软件可靠性工作的具体内容千差万别，为实现综合集成，需分析各项工作间的公共需求，构造可支持各项工作的统一公共服务。

步骤2.1，数据管理需求分析。

虽然各项软件可靠性工作的具体内容不同，但是均需依照对象软件开展工作。

如软件可靠性要求确定工作需要对象软件的软件任务书、需求规格说明书开展工作；软件可靠性分析工作需要对象软件的需求规格说明书、概要设计(FTA与系统级FMEA)、源代码(详细级FMEA)开展工作。因此，对于同一对象软件，各软件可靠性工作具有相同的数据来源。

与此同时，各项软件可靠性工作均需要保存中间数据及最终输出的各项文档。如软件故障树分析工作需要保存故障树分析的中间结果、最终输出定性或定量的分析结果等。这些工作输出的数据均不相同，但是均可以划分为工程数据和文档两类。

此外，根据步骤一的分析，各软件可靠性工作需要能够为其它工作输出不同类型的数据、能够读取其它工作传输给该工作的数据。

根据上述分析，制定软件可靠性工程的公共数据管理需求：一、需要读取对象软件的文档及其它信息；二、需要生成、保存、读取软件可靠性工作中间数据；三、需要生成软件可靠性工作文档；四、需要生成其它工作需要的交互数据；五、需要读取其它工作提供的交互数据。

步骤2.2，权限管理需求分析。

为了实现软件可靠性各工作间的协调，需要对针对同一对象软件开展可靠性工作的各执行人员进行统一调配和管理，每个执行人员应具有对相应数据的访问权限。

因此，制定软件可靠性工程的公共权限管理需求：一、需要为对同一对象软件开展的软件可靠性工作设立单独的解决方案，对同一解决方案内的各项工作进行统一的流程控制、数据交互控制；二、需要为软件可靠性工作参与人员进行权限配置，包括能够读取、修改、删除哪一项工作的数据。

步骤2.3，公共界面需求分析。

在实际工作中，各软件可靠性工作差别较大，要求确定、设计准则管理等工作需要的是类似于表格和清单形式的要求条目、设计准则条目，而故障树分析、可靠性测试等工作则需要构建图形化的故障树、操作剖面等，这就给统一化各工具的操作界面带来了困难。

为了实现各软件可靠性工具界面的尽量统一化，制定软件可靠性工程各工具的公共界面需求：一、需要支持多个子工作内容的显示和跳转，如多棵故障树、多个可靠性要求清单；二、需要支持可靠性工作过程信息的临时显示；三、需要支持各个可靠性工作特有信息的显示，如故障树节点的相关信息、可靠性设计准则的具体内容、实例等；四、需要支持其它软件可靠性工作项提供的信息的展示。

步骤2.4，公共网络传输需求分析。

在实践中，各项可靠性工作均有单独开展的需求，也有同时开展的需求。因此，各个对应的软件可靠性工具应能在单机状态下独立运行、完整支持相关工作，在联网时亦能实现数据交互、流程控制。

因此，制定软件可靠性工程的公共网络传输需求：一、需要支持断网状态下单机开展可靠性工作；二、需要支持联网状态下的权限校验；三、需要支持连接服务器后文件的发送和接收、与其它可靠性工具进行数据交换。

本步骤提取了各项软件可靠性工作的公共需求，包括公共的数据管理需求、权限管理需求、公共界面需求、网络传输需求，为后续平台的公共服务提供基础。

步骤三，软件可靠性工程集成环境设计。根据步骤二分析得出的软件可靠性工程各项工作的公共需求，对软件可靠性集成环境进行详细设计。

步骤3.1，设计集成环境框架。

首先，根据步骤2.4的公共网络传输需求，确定集成环境采用客户端/服务器(Client/Server，C/S)架构，以支持各软件可靠性工作的单独开展和综合集成：在脱机状态下，各工具可直接执行，以支持各项可靠性工作的开展，数据存储在本地；在联网状态下，各工具可自主选择继续单机运行或连接至服务器，通过权限校验后，可将数据同步至服务器，以实现与其它工具的数据交互等。集成环境的整体框架如图3所示。

步骤3.2，客户端平台研究与设计。

在完成了集成环境整体框架设计后，需要对客户端部分和服务器部分进行进一步的详细设计。本发明提出了一个基于插件模型的软件可靠性工程公共客户端平台：支持将各个软件可靠性工具以插件形式插入平台，以实现各工具的功能；并支持各软件可靠性工具的灵活更新，以及新的软件可靠性工具的灵活插入；亦在底层实现了不同软件可靠性工具间的数据共享和与服务器端的交互。

步骤3.2.1，插件模型。

为了实现各软件可靠性工具的集成，不应采用传统的形式，为每个软件可靠性工具设计单独的客户端，这样既不方便各软件可靠性工具的交互，也难以保证业务和数据流的一致性，同时也会带来大量的重复开发工作。

为解决此问题，根据步骤二提取的软件可靠性工程各项工作的公共需求，构建了一个公用的客户端平台。客户端平台为各可靠性工具提供公共服务，再将完成各项软件可靠性工作专有任务的工具以插件的形式插入到平台中。客户端部分采用的插件模型如图4所示。

在插件模型中，客户端平台需要以主执行文件的形式为每个可靠性工具提供公共执行入口、以公用动态链接库的形式提供公共服务。各工具以动态链接库和配置文件的形式放置到插件区，由客户端平台运行时动态调用和加载。这种隔离软件可靠性公共基础服务和具体业务功能的形式，既能保证了各工具基础服务的稳定性、交互数据的一致性、基础服务变更时的快捷性(只需动态替换相应的组件)，又能便于软件可靠性工具的不断添加、功能的不断扩充，而无需整体重新开发，适应现阶段软件可靠性研究的现状。

步骤3.2.2，客户端平台业务分解。

在确定了插件模型后，对客户端平台进行了进一步详细的研究和设计，其业务逻辑如图5所示。

为了给软件可靠性工具提供统一的底层数据管理、权限管理、网络通信等，在客户端平台中，设计了一个公共运行引擎。

在公共运行引擎中，设计了三个业务管理器——工具管理器、工程管理器与服务管理器。

其中服务管理器提供工具服务(即插件管理)、文件服务和工程服务(对应步骤2.1的数据管理需求)、网络服务(对应步骤2.2、2.4的权限管理和网络传输需求)、UI(用户界面)服务(对应步骤2.3的公共界面需求)、日志服务6类软件可靠性工程公共服务。

工具管理器与工程管理器由服务管理器提供的工具服务与工程服务分别调用，实现对于各软件可靠性工具的管理与工程数据的管理。

步骤3.2.3，客户端平台业务流程设计。

以三大业务管理器和六类服务为依托，进一步设计了客户端平台的业务流程。

首先，在公共运行引擎中定义了各软件可靠性工具的核心配置文件、公共界面框架、基础数据类型。引擎启动时，预读取配置文件、基础数据类型，并显示界面框架。

软件可靠性工具配置文件的格式由客户端平台定义，如图6所示，包含工具类型、工具产生的数据文件类型、工具界面元素的描述文件等部分，其中具体的内容由各工具自主提供。

公共界面框架包括一个父级应用窗体、一套公共菜单栏和工具栏，以及功能列表窗体(左侧)、主工作空间窗体(中心)、信息显示窗体(下侧)、信息交互窗体(左下侧并自动隐藏)等四个子窗体，如图7所示。在公共运行时引擎启动时，加载平台的公共窗体、公共菜单栏及工具栏框架。

基础数据类型为客户端平台定义的抽象类，其中包含工具类型、工程文件后缀、路径、抽象的工程数据，为各工具的数据类型提供顶级父类，其类图如图8所示。

随后，公共运行引擎加载服务管理器。服务管理器上的工具服务调用工具管理器，解析工具的配置文件。

然后，由工具管理器唤醒服务管理器中的工程服务，工程服务调用工程管理器，根据工具管理器获取的工具数据文件类型，加载对应的工程数据组件。工程数据组件由各个软件可靠性工具的开发者根据平台提供的基础数据类型继承派生而成，定义各工具独有的数据模型，其中包含根据步骤一定义的交互数据模型构造的提供给其它工具的数据，但是无论是FTA工具还是要求确定工具，都可以由工程管理器统一加载其数据模型。

在工程数据模型加载完成后，唤醒公共服务管理器上的UI服务，UI服务根据工具管理器获取的工具界面元素描述文件，加载对应工具的子窗体、独有的菜单栏和工具栏。工具的子窗体、菜单栏和工具栏全部加载到公共运行引擎维护的平台公共界面元素容器中。UI服务在工具的整个运行生命周期中持续运行，负责界面元素的呈现、维护与销毁。工具与工具的界面元素均由平台提供的公共父类派生而成。

最后，服务管理器将工程服务和网络服务与公共界面框架的公共菜单栏、工具栏绑定。这样通过公共菜单栏的工程子项可直接调用工程服务，实现工程数据文件的新建、打开、删除、保存等操作；公共菜单栏的网络服务子项可以直接调用平台提供的网络服务，实现权限校验、发送、接受工程数据、交互数据及项目的各种文档，与服务器端实现统一的交互。

步骤3.3，服务器端研究与设计。

软件可靠性工程集成环境的服务器端包含服务器、数据库和服务器管理客户端三部分。服务器通过网络与各客户端和数据库相连，实现软件可靠性工作各类输入数据的统一存储、输出数据的统一备份、各工具间数据的自动推送；服务器管理客户端供管理员远程实现软件可靠性工作的配置、人员权限分配、手动的数据推送等。

具体来说，可将服务器端需提供的业务分解为数据管理和业务管理两部分。

步骤3.3.1，数据管理功能分解与设计。

在数据管理部分，应支持用户信息管理、用户权限管理、可靠性项目及工程管理三部分工作，支持用户信息、用户权限信息、各软件可靠性工作信息的增、删、改、查等统一控制。

为此，在数据库中设计了三张数据表，存储用户user、权限permission和项目工程信息ProjectInfo，如图9所示。

管理员在登录服务器管理客户端后可远程连接至服务器，并进行软件可靠性的项目、人员及权限管理。

步骤3.3.2，业务管理功能分解与设计。

在业务管理部分，服务器端应提供网络通信、任务控制、数据流传三部分功能。

其中，网络通信处理与客户端平台交互时必需的端口监听、请求路由、超时检测、权限验证、状态轮询；任务控制实现对于具体软件可靠性项目及各项专门的分析、分配等工作的进度控制、关联信息推送、工程信息同步、心跳包监听、工程列表及描述文件更新、多版本管理等；数据流传实现各软件可靠性工作产生的文件的接收、存储与发送等功能。

根据上述功能分解，设计了服务器端的体系结构，如图10所示。其中，ServerCore表示服务器核心组件，BusinessManager表示业务管理组件，Database表示基础数据库，DatabaseManager表示数据库管理组件，ServerManager表示服务器管理组件，ServerConfig表示服务器配置组件，ClientRouter表示客户端消息路由组件，ClientManager表示客户端管理组件，DataTransferBusinessManager表示数据传输业务管理组件，PermissionBusinessManager表示权限管理组件，ProjectBusinessManager表示工程业务管理组件，PushBusinessManager表示推送业务管理组件，UserBusinessManager表示用户管理组件。

其中，ServerCore组件负责服务器的启动、停止、配置，采用多线程的方式对客户端进行消息监听、请求路由及连接管理；BusinessManager组件处理相关软件可靠性业务，包括软件可靠性相关文档的收发与存储、软件可靠性人员及权限配置、软件可靠性工程数据的收发与备份、各软件可靠性工具间数据的自动推送与手动推送。

根据步骤一的软件可靠性工程数据流图，以配置文件的形式设置了交互数据的自动推送规则，当收到客户端传来的交互数据后，服务器端的PushBusinessManager组件会读取自动推送规则，并自动判断待接收的客户端是否在线，一旦目标客户端连接后会进行自动数据推送，以实现同一对象软件各可靠性工作间的数据共享。

步骤四，软件可靠性工程集成环境的典型应用流程。

为说明本发明所实现的软件可靠性工程集成环境，一个典型的业务流程，如图11所示。

第一，当收到新的软件可靠性工程任务后，管理员在服务器管理客户端创建项目，并填写该项目信息，包括软件名称、重要程度、版本、主要功能、可靠性要求、功能结构图等，如图12所示。服务器端将在数据库中添加相关信息，并创建该项目的共享文件夹，用于存储该项目的相关文档，如软件任务书、需求规格说明书等。

第二，管理员在服务器管理客户端创建项目的参与人员，并分配这些参与人员对于相应工具的访问权限，如图13所示。

第三、各工具的使用人员使用工具进行对应的软件可靠性工作，在本地创建工程，待有联网条件时，通过工具的公共网络菜单连接服务器，如图14所示。

第四、在权限校验通过后，服务器向客户端推送服务器端有权限的项目列表，用户选择对应的项目，并申请将本地的工程链接至服务器端项目，如图15所示。

第五、服务器管理客户端会及时收到客户端发来的对应工程至项目的连接申请，管理员在审批后可以批准或拒绝连接申请，如图16所示。

第六、待连接审批通过后，客户端将自动下载服务器端该项目对象软件的相关信息及文档。同时，客户端可以选择上传本地的工程数据，以供其它工具使用，如图17所示；或上传本地工程文件至服务器端备份。

第七、服务器端收到客户端上传的数据后，根据配置文件将其中的相关数据推送至对应的连网客户端。此外，项目管理员可以登录服务器管理客户端，查看某个项目下工程的联网状况，并手动将服务器端保存的某项目的工程数据推送给该项目下需要这些数据的工具。如图18所示。

第八、对应的客户端收到服务器端推送的数据后，由客户端平台自动解析，显示在该工具对应的服务器面板上，并进行复用。如图19所示。

Claims (8)

1.一种软件可靠性工程集成环境框架设计方法，其特征在于，包括如下步骤：

步骤一，对软件可靠性工程中各项工作的数据进行统一建模；

数据模型中包括源工作项和交互数据，源工作项用于标识提供数据的工作项，交互数据用于存储源工作项提供的数据内容；交互数据至少包含1个子数据项，子数据项包括一个目标工作项、提供给该目标工作项的数据的版本、以及针对该目标工作项的输出数据；子数据项的目标工作项与源工作项不相同；

步骤二，提取软件可靠性工程中各项工作的公共需求，包括公共的数据管理需求、权限管理需求、公共界面需求、以及网络传输需求；

步骤三，根据公共网络传输需求，确定集成环境采用客户端/服务器架构；

构建客户端平台为各可靠性工具提供公共服务，将完成各项工作的软件可靠性工具以插件的形式插入到客户端平台中；客户端平台以主执行文件的形式为每个可靠性工具提供公共执行入口、以公用动态链接库的形式提供公共服务；各工具以动态链接库和配置文件的形式放置到插件区，由客户端平台运行时动态调用和加载；

所述的客户端平台上，设计有一个公共运行引擎，在公共运行引擎中设计三个业务管理器——工具管理器、工程管理器与服务管理器；其中，服务管理器提供工具服务、文件服务、工程服务、网络服务、UI服务和日志服务；工具管理器与工程管理器由服务管理器提供的工具服务与工程服务分别调用，用于对各软件可靠性工具的管理与工程数据的管理；

构建服务器端，服务器端包含服务器、数据库和服务器管理客户端三部分；服务器通过网络与各客户端和数据库相连；服务器端以配置文件的形式设置了交互数据的自动推送规则，当收到客户端传来的交互数据后，服务器端将读取自动推送规则，自动判断待接收的客户端是否在线，一旦目标客户端连接后进行自动数据推送。

2.根据权利要求1所述的方法，其特征在于，所述的源工作项是软件可靠性要求确定、分配、早期预计、设计、分析、评估、测试、脚本转换8个工作项之一。

3.根据权利要求1所述的方法，其特征在于，所述的步骤二中，公共数据管理需求包括：一、需要读取对象软件的文档；二、需要生成、保存、读取软件可靠性工作中间数据；三、需要生成软件可靠性工作文档；四、需要生成其它工作需要的交互数据；五、需要读取其它工作提供的交互数据；

公共权限管理需求包括：一、需要为对同一对象软件开展的软件可靠性工作设立单独的解决方案，对同一解决方案内的各项工作进行统一的流程控制、数据交互控制；二、需要为软件可靠性工作参与人员进行权限配置，包括能够读取、修改、删除哪一项工作的数据；

公共界面需求包括：一、需要支持多个子工作内容的显示和跳转；二、需要支持可靠性工作过程信息的临时显示；三、需要支持各个可靠性工作特有信息的显示；四、需要支持其它软件可靠性工作项提供的信息的展示；

公共网络传输需求包括：一、需要支持断网状态下单机开展可靠性工作；二、需要支持联网状态下的权限校验；三、需要支持连接服务器后文件的发送和接收、与其它可靠性工具进行数据交换。

4.根据权利要求1所述的方法，其特征在于，所述的步骤三中，在客户端平台的业务流程为：

首先，公共运行引擎启动，预读取各软件可靠性工具的配置文件和基础数据类型，并显示界面框架；

随后，公共运行引擎加载服务管理器，服务管理器上的工具服务调用工具管理器，解析工具的配置文件；

然后，由工具管理器唤醒服务管理器中的工程服务，工程服务调用工程管理器，根据工具管理器获取的工具数据文件类型，加载对应的工程数据组件；在工程数据模型加载完成后，唤醒服务管理器上的UI服务，UI服务根据工具管理器获取的工具界面元素描述文件，加载对应工具的子窗体、独有的菜单栏和工具栏；

最后，服务管理器将工程服务和网络服务与公共界面框架的公共菜单栏、工具栏绑定。

5.根据权利要求1所述的方法，其特征在于，所述的步骤三中，在服务器端的数据库中设计三张数据表，分别用于存储用户、权限和项目工程信息。

6.根据权利要求1所述的方法，其特征在于，所述的步骤三中，服务器端提供网络通信、任务控制和数据流传三部分功能；其中，网络通信处理与客户端平台交互时必需的端口监听、请求路由、超时检测、权限验证和状态轮询；任务控制用于对软件可靠性项目及各项工作的进度控制、关联信息推送、工程信息同步、心跳包监听、工程列表及描述文件更新、多版本管理；数据流传实现各软件可靠性工作产生的文件的接收、存储与发送。

7.根据权利要求1所述的方法，其特征在于，所述的步骤三中，服务器端设计的实现业务管理的体现结构包括：

ServerCore组件，负责服务器的启动、停止和配置，采用多线程的方式对客户端进行消息监听、请求路由及连接管理；

BusinessManager组件处理相关软件可靠性业务，包括软件可靠性相关文档的收发与存储、软件可靠性人员及权限配置、软件可靠性工程数据的收发与备份、各软件可靠性工具间数据的自动推送与手动推送。

8.根据权利要求1所述的方法，其特征在于，根据所述方法设计的软件可靠性工程集成环境，在该集成环境下实现的一个业务流程包括：

第一，当收到新的软件可靠性工程任务后，管理员在服务器管理客户端创建项目，并填写该项目信息，服务器端将在数据库中添加相关信息，并创建该项目的共享文件夹，用于存储该项目的相关文档；

第二，管理员在服务器管理客户端创建项目的参与人员，并分配各参与人员对于相应工具的访问权限；

第三、各工具的参与人员使用工具进行对应的软件可靠性工作，在本地创建工程，待有联网条件时，通过工具的公共网络菜单连接服务器；

第四、在权限校验通过后，服务器向客户端推送服务器端有权限的项目列表，用户选择对应的项目，并申请将本地的工程链接至服务器端项目；

第五、服务器管理客户端及时收到客户端发来的对应工程至项目的连接申请，管理员在审批后批准或拒绝连接申请；

第六、待连接审批通过后，客户端将自动下载服务器端该项目对象软件的相关信息及文档；同时，客户端选择上传本地的工程数据至服务器端备份；

第七、服务器端收到客户端上传的数据后，根据配置文件将其中的相关数据推送至对应的连网客户端；项目管理员登录服务器管理客户端，查看某个项目下工程的联网状况，并手动将服务器端保存的某项目的工程数据推送给该项目下需要相关数据的工具；

第八、对应的客户端收到服务器端推送的数据后，由客户端平台自动解析，显示在该工具对应的服务器面板上，并进行复用。