开发组件软件工程论文

摘要：随着航电系统技术的发展及广泛应用，型号项目也越来越多，对产品或模块需求量也越来越大。该文主要提出了支撑系统平台解决方案，分析了组件开发方法，研究了组件应用模型，为航电系统支撑系统平台组件开发提供分析与设计依据。下面是小编整理的《开发组件软件工程论文(精选3篇)》，欢迎大家借鉴与参考，希望对大家有所帮助！

开发组件软件工程论文 篇1：

面向知识图谱的融合集成框架设计研究

摘  要：随着知识图谱技术及应用的不断发展，形成了一系列独立的开发组件库，这些组件库在知识图谱的某些环节和领域中具有广泛的应用，但是其中大多数组件库之间相互独立、缺少统一标准，难以聚合形成体系开放能力。由于需要掌握多个独立组件的开发规范标准，这给相关研究和应用造成一定的难度和阻碍，因此利用Python的集成设计模式和语言黏合优势，对成熟的组件库进行分层分类整合，具有重要的实用价值。

关键词：知识图谱;图谱数据库;設计模式;集成构建

Research on the Design of Fusion Framework for Knowledge Graph

HE Zongping，FAN Shaofen，HE Xiran

（Information Office，Nanjing Audit University，Nanjing  211815，China）

0  引  言

知识图谱在相关的研究和开发领域具有一系列成熟的开发组件库，这些组件库在知识图谱的某些环节和领域中具有较为广泛的运用，如自然语言处理模块spaCy、图分析算法包NetworkX。但是其中的大多数组件库之间相互独立、缺少统一标准和规范约束，无法提供体系化的功能。知识图谱的研究开发需要掌握多个独立组件的标准规范，给相关问题的研究开发造成了困难和阻碍。同时，由于jupyter、colab等数据工程和科学领域的平台工具，对编写Python Notebook程序的简洁性、可复现性提出了更高的要求。因此，构建统一简洁、全面完善的知识图谱集成框架，对于这个领域的研究发展有着重要的现实意义。

1  知识图谱构建

知识图谱的运用覆盖了从互联网搜索到聊天机器人、推荐系统、金融风控、物联网、医疗教育等多个热门领域，对知识图谱相关技术领域研究开发的热度不断攀升。例如传统的搜索是一种浅层次的关联搜索，通过对网页关键内容的过滤分析实现，而基于知识图谱的搜索将在进行知识语义理解的基础上进行深层次关联搜索，综合检索数据信息的来龙去脉，并提供对搜索事物的分类、属性和关系的描述。

知识图谱本质上是基于语义网络的知识库，由Google公司于2012年提出。实际应用中可以把知识图谱理解成由节点（Vertex）和边（Edge）构成的一种特殊的多关系图，通常多关系图一般包含多种类型的节点和边，而知识图谱一般只包含一种类型的节点和边。

1.1  数据处理

在Python语言中，可以通过pandas读取excel中的数据，并以图谱“三元组”形式存储到Neo4j图谱数据库，以构建相关的知识图谱。基于Neo4j图谱数据库能够很容易地构建知识图谱，除了用Neo4j自带的cypher语言导入，也可以通过py2neo组件创建节点和关系从而构建知识图谱。pandas组件包通常用于数据分析与处理，可以将excel格式文件转换成dataframe格式，这种格式类似于Spark中的Dataframe结构，支持类似SQL的形式对数据进行处理。

1.2  实体抽取

知识图谱构建流程主要就是抽取实体，通过抽取算法获取知识图谱上的“节点”。对于文本数据处理的方式，基于词性标注的方法从句子中提取单词，例如名词和专有名词就是需要的实体。此外，当一个实体关联多个单词时，还需要解析文本的依赖树。

1.3  图谱数据库

图数据库不同于一般的关系型数据库，是一种非结构化的图形数据库，与MySQL、Oracle等传统数据库存储结构化数据相对比，图数据库主要用来持久化存储图谱数据。目前主流的图数据库包括Neo4j、TigerGraph、JanusGraph等：

（1）Neo4j是典型的图数据库，也是图计算引擎，具备嵌入式、高性能、轻量级等优势。

（2）TigerGraph是为高性能存储和计算而设计的分布式图数据库。每个实体和连接实体的每个边都是计算单元，支持自动划分多个节点。

（3）JanusGraph是开源的图数据库，遵循Apache协议，具有良好的开放性。

2  架构需求

本文研究的主要内容是通过增加适配层方式进行多组件的集成，提供抽象层接口，统一SDK或API标准，以构建符合当前数据科学研究和知识图谱开发应用的需求。图1为融合多个技术组件的集成架构图。

2.1  层级区分

框架的体系架构垂直划分为三个层次，即图数据存储层、引擎处理层、功能集成层：

（1）图数据存储层：存储层主要由各种图数据库组成，支持分布式存储，实现图数据的持久化存储。在数据存储量上能够支持达到亿级以上点边总数，吞吐量数万QPS，查询响应在秒级以内。

（2）引擎处理层：引擎处理层是负责对图数据进行读取转换和序列化的处理，包括一些并行处理引擎、大数据内存处理引擎等。

（3）功能集成层：集成层主要是牵涉到图数据相关的建模、分析和计算等功能库，是知识图谱应用分析的主要功能集合。

2.2  集成与接口

集成框架的核心是为Python中的知识图谱相关组件构建统一抽象层。本文研究基于外观模式（Facade Pattern）进行封装设计，架构如图2所示。

在面向对象方法的程序设计中，外观模式又被称为门面模式，外观模式定义了一个高层接口，通过引入一个类对子系统进行封装，让外部通过统一的外观对象进行调用，为子系统中的接口提供一致的访问标准。引入封装的外观可有效降低原有系统的复杂度，同时减少客户端与子系统类之间的耦合度。

外观设计模式通过一个统一的外观对象实现子系统外部与其内部的通信，屏蔽了客户端访问子系统的复杂性，客户端只需与外观对象通信，无需要调用子系统内部的多个复杂对象的功能。外观模式的目的在于降低系统的复杂程度，极大程度上提高了聚合功能包开发的便捷性，使得客户端无须关心子系统的实现细节，通过外观接口类即可完成所有功能調用。

3  构建方法

Python有着多种丰富成熟的图数据组件包，提供了包括语义技术、图数据查询、交互可视化、图数据结构算法、概率图推断，以及和机器学习等方面集成的工具包。这些工具包各自独立向外提供编程功能接口，工具包之间在数据处理、接口规范、功能种类等方面都存在一定的差异性。此外，这些开发包与主流的数据科学基础平台和工具包（例如Apache Spark、Ray、RAPIDS、Apache Parquet、pandas、scikit-learn、PyTorch、spaCy等）相比，也同样缺少有效集成。

3.1  组件构成

组件集成了RDFlib、OWL-RL、pySHACL、NetworkX、iGraph、PyVis、node2vec等开源项目工具包，集成各种图计算分析、可视化分析相关的功能方法，有助于知识图谱开发融入数据科学，并推动与数据工程实践更加紧密关联。

3.2  功能要素

构建的功能要素包括6个方面的内容：

（1）RDFlib中的知识图谱构建功能。RDFlib主要功能就是将基于语法的文件转换成RDF格式的知识表达，需将原始数据按照相应语法进行预处理，如TTL、JSON-LD、Parquet等数据格式序列化。

（2）基于PyVis的交互可视化。PyVis专注于关系网络可视化方面，并支持javascript渲染。

（3）基于SPARQL的查询能力，并将查询结果输出转换为pandas格式数据。SPARQL是针对RDF存储的查询语言，SPARQL与SQL类似，通过查询可以返回一条或多条图存储内容结果。

（4）基于SHACL约束规则的图计算验证。SHACL是一种标准化的依据一组条件来验证RDF图的语言，可以在预定义图谱形状构建的数据图上，强制执行标准结构。

（5）NetworkX和iGraph的图分析算法。NetworkX和iGraph是Python中创建、操作和研究网络图谱的工具包，尤其在分析网络结构的方面具有十分完备的支持。

（6）基于RDFS、OWL知识推理功能。RDFS是对RDF的扩充，用来描述RDF数据，增加更多的关系表示方法，OWL则提供高效灵活的数据建模和自动推理能力。

3.3  接口构建

集成框架基于Facade设计模式，将各类复杂的知识图谱功能库封装，提供外界统一访问的模块接口，内部中各个功能库仍然相对独立，降低系统耦合度并相互减少依赖。外观接口类构建的代码示例：

class  SpecialGraphFacade（）：

igraphObj = None

rdfObj = None

visObj = None

def __init__（self）：

self. igraphObj = IGraph（）

self.rdfObj = RDF（）

self.visObj = PyVisual（）

def createSpecialGraph（self，data）：

self.rdfObj.readGraph（data）

return self.igraphObj.createSpecialPath（self.rdfObj）

def visualSpecialGraph（self）：

return self.visObj.visual（self.igraphObj）

4  结  论

开源社区在知识图谱相关的存储处理和计算分析层面提供了多种成熟的組件功能包，为避免在知识图谱应用开发和研究中带来的版本、接口和集成等问题，可充分发挥Python语言高效粘合式集成开发能力，基于Facade设计模式为一系列知识图谱组件功能包提供一致的高层接口层，隐藏多组件开发带来的复杂性，并承接版本控制的统一性、功能的一致性等内容，为知识图谱相关研究提供便利。

参考文献：

[1] 张云中，祝蕊.面向知识问答系统的图情学术领域知识图谱构建：多源数据整合视角 [J].情报科学，2021，39（5）：115-123.

[2] 张思龙，王兰成，娄国哲.基于知识图谱的网络舆情研判系统研究 [J].现代情报，2021，41（4）：10-16.

[3] 刘宝珠，王鑫，柳鹏凯，等.KGDB：统一模型和语言的知识图谱数据库管理系统 [J].软件学报，2021，32（3）：781-804.

[4] 于升峰.面向科技智库的知识图谱系统构建 [J].智库理论与实践，2021，6（1）：56-64.

[5] 贺宗平，张晓东，刘玉.基于Jupyter交互式分析平台的微服务架构 [J].计算机系统应用，2019，28（8）：63-70.

[6] 魏泽林，张帅，王建超.基于知识图谱问答系统的技术实现 [J].软件工程，2021，24（2）：38-44.

[7] 赵捷，宫政，李晟飞.基于知识图谱的机构大数据集成系统研究 [J].标准科学，2020（9）：74-78.

作者简介：贺宗平（1982.09—），男，汉族，江苏南京人，工程师，硕士，研究方向：软件体系架构、数据平台。

作者：贺宗平 范少芬 贺曦冉

开发组件软件工程论文 篇2：

支撑系统平台组件开发研究与分析

摘要：随着航电系统技术的发展及广泛应用，型号项目也越来越多，对产品或模块需求量也越来越大。该文主要提出了支撑系统平台解决方案，分析了组件开发方法，研究了组件应用模型，为航电系统支撑系统平台组件开发提供分析与设计依据。

关键词：支撑系统；平台；组件

基于组件的开发（Component Based Development，CBD）技术在软件工程中占有举足轻重的地位，并且在许多工程应用领域已经取得了重大的成功。随着航电系统技术的发展及广泛应用，型号项目也越来越多，对产品或模块需求量也越来越大。在产品或模块研制过程中，存在相同或相似度非高的产品，模块可能用于同一型号航电系统的多个不同子系统，也可能用于不同型号航电系统的多个子系统。由于型号的不同，課题的不同，硬件型号的不同，研制要求的不同，硬件环境和系统环境等不同，用户需求的差异，导致产生多个嵌入式系统产品或模块的项目（包括软硬件项目）。因此，相似度非高的多个软件项目，因研制阶段，进度要求，变更控制等，会导致项目管理，软件开发，配置管理等软件研制过程效率不高，工作量大，软件开发及维护成本等问题。

针对上述存在的情况，本文从构建系统平台的角度提出了系统平台组件的构建策略和思路，分析了组件应用及组件开发过程中，组件管理需要解决的问题等。其目的有三个：1）为通过组件方式构建系统平台产品提供参考；2）为组件开发及应用提供思路，策略和方案；3）提升产品的核心竞争力。最终目标是实现一套完整的可应用于航空领域的支撑系统平台，进一步加强产品的核心竞争力。

1解决方案研究

支撑系统平台组件的构建策略和思路分为三步：1）采用平台化思路构建系统平台框架；2）基于系统平台框架，对各平台采用组件化思路构建各平台；3）组件开发独立于型号课题，应用于型号课题，并纳入工程管理及资产库。

1.1支撑系统平台方案

1.1.1支撑系统平台框架

如图1所示，支撑系统平台分为机载硬件平台，机载软件平台和机载工具平台。

机载硬件平台结合了历史型号项目，现在型号项目，预言项目的功能及性能等特点，能够满足80%的新研项目和后续10年左右%80的新项目的功能及性能要求及能力。机载硬件平台为机载软件平台提供稳定可靠的运行平台。机载硬件平台采用组件化思路进行研制。

机载软件平台结合了历史型号项目，现在型号项目，预言项目的功能及性能等特点，能够满足80%的新研项目和后续10年左右%80的新项目的功能及性能要求及能力。机载软件平台运行于机载硬件平台，为加载应用软件提供系统平台服务。机载软件平台采用组件化思路进行研制。机载软件平台包括板级平台，支持软件平台，维护软件平台。

机载工具平台结合机载硬件平台，机载软件平台提供系统平台整体功能，包括产品展示及演示功能，产品管理及维护功能。机载工具平台为机载软件平台提供维护及管理支持。机载工具平台完成机载硬件平台和机载软件平台的资源管理，版本管理，设备管理，监控管理，健康管理等。

1.1.2机载软件平台框架

如图2所示，机载软件平台包括维护软件平台，支持软件平台和板级软件平台。其中，操作系统可采用天脉2，天脉1，VxWorks和WINXP等。

1.1.3机载工具平台框架

如图3所示，机载工具软件平台包括维护软件平台和支持软件平台。

1.1.4机载硬件平台框架

如图4所示，硬件平台包括通用模块，通信模块和其它模块。通用模块包括CPU，内存单元等必不可少的模块。通信模块包括各种通信硬件单元等。

1.2支撑系统平台组件方案

1.2.1支撑系统平台组件框架

如图5所示，系统平台组件包括机载软件组件平台，机载硬件组件平台和工具软件组件平台。

1.2.2机载软件平台组件框架

如图6所示，机载软件平台组件包括维护软件组件平台，支持软件组件平台，板级软件组件平台。维护软件组件平台包括版本管理组件，设备管理组件，监控管理组件，健康管理组件和网络管理组件。支持软件组件平台包括通信接口组件，通用组件，设备组件，通信组件，工具组件，系统操作系统组件，硬件接口组件等。

1.2.3工具软件平台组件框架

1.2.4硬件平台组件框架

2组件开发研究

组件开发研究主要介绍组件开发的策略和组件工程化需要解决的问题。

2.1组件开发分析

如图9所示，组件开发思路包括系统功能分析，系统方案分析，系统组件分析，组件分解，组件复用和开发，组件实现和测试等工作。组件开发对系统方案和软件开发提出了更高的要求。系统方案和组件复用与开发是实现支撑系统平台和支撑系统平台组件方案的关键。

2.2组件工程化

在解决方案提及到组件开发独立于型号课题，但源于和应用于型号课题，并纳入系统工程及资产库（知识库）管理。组件工程化开发难度较大，需要解决如下几个问题：

1）组件开发问题：组件化开发思路与原有开发思路存在本质的差异，需要研制团队转变开发思路和观念，注重需求整合与引导，产品模块整体架构，系统方案，系统平台化，组件化和标准化，组件裁减等。对系统方案和组件开发等人员等提出了更高的要求。

2）组件资质问题：型号课题要求多样，组件开发需要满足多个型号课题要求，因此涉及组件工程化，定型及合法化等问题。

3）组件应用问题：组件如何应用于多个型号课题项目，涉及组件应用方案策略，组件集成，组件测试及组件变更等。

3组件应用

如图10所示，给出了组件应用思路。组件应用包括产品演示，依据用户需求构建系统方案，依据系统方案构建组件方案，组件的分解与集成，最后组件的集成与开发。系统方案和组件复用与开发是组件应用的关键。

4结束语

软件开发的最佳方法是不进行任何开发。重用就是实现上述目标的一种方法。基于组件的软件重用是产品重用的主要形式，软件组件技术是当前重用研究的焦点。本文从构建系统平台的角度提出了系统平台组件的构建策略和思路，分析了组件应用及组件开发过程中，组件管理需要解决的问题等。本文研究了支撑系统平台解决方案，组件开发和应用模型。这将对航空领域同类型项目提供软件复用的基础，为航电系统型号项目软件提供可参考意义和借鉴价值。

作者：杜建华 瞿海娜

开发组件软件工程论文 篇3：

软件框架技术在BOM组件开发中的应用

摘要:基于BOM的仿真系统开发具备诸多优点,但仿真模型组件开发及测试也存在辅助过程复杂、工作量大、协调困难等问题,为辅助仿真模型组件开发及测试,文章借助于软件框架技术,建立了一套配置简单、资源需求小的仿真组件开发辅助框架,通过该框架可减小组件开发中的迭代活动涉及范围,降低组件修改带来的附加工作量,加快仿真组件开发进度。

关键词:基本对象模型;仿真;组件;组件测试

Software Framework in the Development of BOM Components

WANG Xiao-zhen, LI Ze-min, ZHAO Meng

(The Academy of Armored Forces Engineering, Beijing 100072, China)

Key words: Base Object Model (BOM); simulation; component; component testing

当前计算机仿真系统的规模不断增大,内部结构也越来越复杂,仿真构件的可重用性越来越重要,从1997年秋开始,仿真互操作标准化组织SISO(Simulation Interaction Standard Organization)在RFOM(Reference FOM)的基础上提出了基本对象模型(Base Object Model,BOM)的概念,其目的主要是解决联邦开发过程所存在的资源重用性较差、工作重复性较多的问题,将BOM作为快速构建未来的可组合可扩展仿真系统的重要手段[1]。借助BOM模型,将仿真系统和联邦的各组成部分抽取出来,作为建模的基本模块或者组件来使用,与传统的联邦开发方式下直接构建联邦成员的方式相比,BOM将仿真系统开发的复用粒度进一步细化,更有助于提高系统的重用性和大型仿真系统的开发和控制。

国内基于BOM的仿真体系有国防科技大学机电工程与自动化学院提出的KD-SmartSim仿真系统开发环境,可为仿真系统提供面向组件的开发及运行支持,在KD-SmartSim环境下,仿真模型组件由模型描述文件、模型数据文件和代码执行体三部分构成,其中代码执行体为仿真模型处理逻辑实现部分,其部分代码可由模型描述文件确定,从而通过KD-SmartSim提供的辅助工具来生成,而开发人员需补充仿真功能实现部分,在这种开发模式下,开发人员可将注意力集中在关键的功能实现部分,借助相关工具快速的构建完整的仿真系统,从而隔离了传统连邦成员开发过程中必需要考虑的与RTI交互等细节,降低系统开发难度,加快系统开发进度。应用KD-SmartSim环境,可以充分复用已有代码资源,快速建立完整的仿真系统,但在仿真模型组件开发实践中,也遇到一些新的问题,主要表现为:

1)BOM组件开发时辅助过程过于繁杂,并没有较好的工具支持。在KD-SmartSim环境下,仿真模型组件的基本开发流程如图1所示。

流程中这五个活动是顺序进行的,开发过程中每一个活动发生变化,其后续活动都受到影响。由于仿真模型组件本身不具备独立执行能力,因此,仿真模型组件的测试通常需要在完成图1中整个流程后才可进行,在软件开发中,缺陷和故障总是不可避免的,因此,在实际的仿真模型组件开发中,上述流程是需要不断迭代的,通常每次迭代的起点在于活动2处,可见每次迭代都囊括大部分的流程,其引入的额外工作量是相当大的;

2)大型复杂仿真系统开发过程中,完备的开发及测试环境难于获得。由于仿真模型组件通常不是独立的,需要和其它组件进行交互才能工作,而在仿真系统开发过程中,不同类型的组件开发工作通常由不同的单位分担,因此在进行功能测试时,会带来大量的协调工作,以及相互等待而产生难以控制的项目延期。

现有的BOM组件自动化测试工具,都是构建在BOM运行环境之上的,应用中无法回避上述所讨论的困难。

框架是一系列可重用软件,用于实现一般问题的通用解决方案,提供可用于不同应用程序的公共功能[2]。对于不同BOM组件开发及测试,大量的工作是相同或相似的,因此,可以将共性的问题进行抽象,寻找一致的解决方案,即通过构建框架来解决,而针对前述BOM组件开发中的问题,在实际工程实践中开发了一个轻型的仿真模型组件运行环境以及一系列辅助工具,对仿真模型组件的开发及测试提供支持,通过该运行环境,可以将迭代控制在只覆盖图1中第1、2个活动的范围内,以此消除后续活动带来的额外工作,提高组件开发效率。

1 轻型测试框架的目标及系统结构

KD-SmartSim环境下,仿真模型组件执行体包括两个部分:1)模型逻辑功能实现部分,由模型开发人员产生,产品表现为动态库形式,我们将其称为实体模型;2)组件封装代码,用于实现与成员框架的接口处理等功能,由KD-SmartSim模型开发工具根据组件描述文件自动生成。可见,对于模型开发人员而言,仿真模型组件测试实际上主要是对实体模型部分进行测试,轻型测试框架目标也在于此,即为实体模型提供一个操作简单、易于部署、资源需求小,支持接口测试、功能测试能力的运行环境。

为实现上述目标,轻型测试框架包含下列组成部分: 仿真执行引擎、工厂类插件和工厂类代码生成工具。

1.1 仿真执行引擎

仿真执行引擎具有如图2所示的内部结构。

其中,仿真执行引擎提供实体模型运行的支持环境,负责仿真对象及其工厂类对象管理,包括对象生命周期管理、对象检索、成员函数调用等,并向工厂类对象提供一个公用的内存数据库访问接口,系统运行时实体模型对象间不直接通信,而是借助于其对应的工厂类对象通过读写内存数据库来进行交互,以此降低各实体模型之间的耦合。

1.2 工厂类插件

工厂类插件是框架功能实现的核心部分,其功能为包装仿真组件模型,对其进一步抽象,并向仿真执行引擎提供一致的访问接口。对于BOM组件,仿真组件模型可理解为下列五元组的集合:

[3]

工厂类插件的作用即是将该五类信息的访问方式一致化并负责对应类型仿真对象的生命周期维护。为此,每个工厂类插件都是一个SimuObjectFactory抽象类的实现,其部署形式为Windows动态库,向外部输出一个名为getFactory的函数, 仿真执行引擎通过getFactory函数获得工厂类对象,借助工厂类对象,仿真执行引擎实现对实体模型的功能调用。SimuObjectFactory抽象类具有图3所示接口函数。

其中,CreateObject、DeleteObject用于实体对象的创建及销毁,Publish用于将实体对象自身产生的实体类数据及事件类数据写入内存数据库中,Subscribe用于实体对象从内存数据库获得自身关心的外部实体数据或事件数据,getProp用于获得实体对象的属性描述信息。通过SimuObjectFactory,实体对象被高度抽象,可以看到仿真执行引擎仅通过一个无类型指针对实体对象进行标识,其类型信息完全丢失,因此,仿真执行引擎完全借助工厂类对象实现对实体对象的操作,这样可以获得更大的适应性。

在BOM组件开发中,由于组件的五元组信息都需通过模型接口描述文件给出,因此,工厂类插件的代码可完全由模型接口描述文件确定,在轻型仿真框架中,开发了工厂类插件代码生成工具来辅助生成工厂类程序代码的编写。

1.3 工厂类插件代码生成工具

在轻型框架中,工厂类插件扮演着核心作用,向上为仿真执行引擎提供一致的访问接口,向下则负责与具体的仿真实体进行交互,为实现上述要求,工厂类插件动态库的编写需要遵守一定的规则,包括对于SimuObjectFactory抽象类的实现以及与仿真执行引擎向其暴露的内存数据库接口、态势显示接口、日志记录器及性能参数记录器等部件的交互规则,但针对不同的仿真实体所产生的工厂类所实现的功能是基本一致的,其代码都可根据模型接口描述文件提供的信息自动生成,在开发的轻型框架中,是通过建立一个自定义Visual Studio应用程序向导(BOM Factory AppWizard)实现的,该向导可以根据用户指定的组件描述文件,生成工厂类插件动态库程序代码。

2 轻型框架应用实例

在实际工程项目中的具体应用为例,通过工厂类插件代码生成工具建立通用飞机平台、攻击机、轰炸机、指挥所、战斗机等实体模型的工厂类插件,并配置在仿真执行引擎中,编写想定对作战任务进行仿真推演,以此对实体模型功能实现正确性进行检验,并且通过配置测试用例,也可实现对实体模型的接口测试。其运行效果如图4所示。

3 结束语

通过轻型测试框架的辅助,可将仿真模型组件测试提前到BOM组件封装操作之前,如图5所示,此时在组件开发、测试迭代过程中,所包含活动较应用轻型测试框架之前大为减少,显著减少开发过程中的工作量。并且对于特定的仿真实体,其工厂类代码的产生仅依赖于仿真组件描述文件,其内容相对而言是比较稳定的,因此,在实际组件开发工作中,也可以采取测试先行的模式,针对仿真实体先产生工厂类及测试用例,这样在实现模型组件功能而进行的编码工作中,可随时对产生的代码进行测试及调试,大大加快组件开发进度。

参考文献:

[1] 刘晓铖,邱小刚,龚建兴,等.基于BOM的组件测试研究和实现[J].系统仿真学报,2009,21(18).

[2] 张红光 译.面向对象软件工程[M].北京:机械工业出版社,2003.

[3] 李泽民,王小振. 基于实体模型的通用作战仿真引擎设计[J].电脑知识与技术,2010,6(3).

[4] 彭勇.基于BOM的仿真模型组件测试方法研究[D].长沙:国防科学技术大学,2006.

[5] 龚建兴,闫小曼,郝建国,等.基于BOM 的仿真模型组件研究[J].系统仿真学报,2007,19(22).

作者：王小振 李泽民 赵 萌