基于工厂模式的OSLC数据集成接口设计与实现

0 引 言

随着空间信息技术的高速发展，航天器及其信息系统功能越来越强大，航天器上运行的软件系统的规模越来越大，软件复杂度也越来越高，其质量保证已成为影响航天产品质量的关键要素[1].针对复杂软件系统的开发，包括高可靠的航天软件系统研发，往往单一团队难以在规定时间内完成开发与测试开发，需要不同地域的不同团队来共同协作工作，即软件协同开发.然而，软件协同开发也使得软件开发过程越来越复杂[2]，产生的软件代码、软件文档及相应的测试数据等也越来越多.由于不同的团队可能使用不同的开发与测试工具，这些工具生成的数据格式往往是不一致的，也没有统一的存取接口，对这些数据的成和管理集将面临着很多问题.

首先，数据格式不一致.软件协同开发不同阶段生成的数据格式各都不相同，这些数据包括纯文本、图像、视频等不同存储格式，如何有效进行数据交互存在很大的困难.其次，数据存取接口不兼容.不同的团队往往使用不同的开发测试工具，这些工具生成的数据存取接口也没有统一标准，需要针对每一种工具实现一套数据存取API，影响软件协同开发的效率，也不利于软件协同开发过程中新工具的加入.为了提高协同开发效率，需要对不同阶段的数据提供统一的数据模型和存取接口.

开放式生命周期协作服务OSLC(open services of lifecycle collaboration)是由IBM提出的技术规范，主要用于解决产品生命周期内各种工具的集成问题，消除不同工具之间数据交互的障碍.OSLC规范由核心规范[4-5]和领域规范[6-7]组成.核心规范用于对核心的集成技术及通用概念进行描述.领域规范则是对具体的工程领域展开，如需求管理、配置管理、质量管理、资产管理、变更管理等传统软件工程领域.OSLC将软件研发生命周期的工件进行资源化.例如一条需求、一个测试用例、一个开发计划等都是HTTP URI标识的资源，用户可以通过HTTP协议对这些资源进行访问[8].

图1 OSLC 系统架构
Fig.1 OSLC system architecture

国内外已经有很多研究者针对OSLC规范展开了研究.例如，SAADATMAND等[9]研究了OSLC和系统工程之间的关系，重点介绍了OSLC如何将系统工程原理和概念应用到工具集成场景中，并讨论了系统工程概念和方法能否应用于工具集成.挪威奥斯陆大学的ZHANG等[10]基于OSLC Web服务讨论了一种用于管理工具集成的类建模方法，该方法可用于生成OSLC规范，以及使用OSLC Web服务构建工具适配器的实现代码.然而，OSLC只给出了软件协同开发过程中数据集成的规范，并没有给出具体的统一的数据集成接口.例如，OSLC规范对数据进行资源化，并通过统一的HTTP协议对这些资源进行访问.但是，不同工具产生的数据格式和结构等都各不相同，提供的数据存取接口也不相同.若要集成不同工具的数据，还需要针对每一种工具开发其数据集成接口，灵活性和扩展性较差.

工厂模式是软件设计中常用的一种创建型设计模式，主要用于解决接口选择的问题.在工厂模式中，可以将对象的创建和使用相分离[11-12]，有利于减少类间的耦合度，提高代码复用性和扩展性.例如，王志乐等[13]采用抽象工厂模式将机载飞行显示系统所有图形库按产品族和产品等级进行抽象，建立图形处理模型、图形绘制模型和显示模型三级架构.甄超[14]等基于工厂方法模式对具体网络通信设备的管理和使用进行了抽象，实现了通信中间件业务逻辑与具体设备的解耦.但是，工厂模式只是软件设计常用的一种模式，它并未涉及到如何实现符合OSLC规范的数据集成.

基于上述分析，针对航天软件系统协同研发过程中存在数据难以集成的问题，本文首次结合工厂模式和OSLC规范设计并实现数据集成接口.首先，抽象出统一的数据集成接口，基于工厂模式将不同工具的数据集成抽象成统一的公共接口，在工厂类中依据传入的参数，生成对应的产品对象，创建所需的产品对象；其次，在具体的产品对象中实现具体的数据集成功能，基于OSLC规范来设计工厂模式数据操作时序图，针对具体工具完成符合OSLC规范的数据集成，从而实现不同工具的数据集成.目前，以符合OSLC规范的Bugzilla缺陷管理系统和Jenkins持续集成工具的集成为例，以面向航天软件系统研发的SunwiseAEM一体化研发管理平台为载体，基于工厂模式实现了符合OSLC规范的数据集成系统，实现了不同工具间的数据集成.工厂模式具有良好的扩展性，若要集成其它工具的数据，只需要根据统一的公共接口实现该工具的数据集成即可，不会对其它工具的数据集成产生影响，因而可以提供一种通用的、可扩展的数据集成方式.

1 数据集成接口设计

工厂类是整个工厂模式的关键，包含了必要的逻辑判断，根据外界给定的信息，决定究竟应该创建哪个具体类的对象.使用工厂类，有助于隐藏对象创建的细节，将产品的实例推迟到子类中去.客户端无需关心使用哪一个产品，只需要知道用哪一个工厂即可.下面以符合OSLC规范的Bugzilla缺陷管理系统和Jenkins持续集成工具两个工具的集成为例，详细介绍基于OSLC规范的工厂模式类图设计和时序图设计.

1.1 基于OSLC规范的工厂模式类图设计

基于OSLC规范的工厂模式中工厂类设计如图2所示，它主要包含有OSLCOperatorFactory工厂类、OSLCOperatorAction操作类型类和OSLCOperatorDao接口类.使用工厂模式，在OSLCOperatorFactory中根据OSLCOperatorAction类型集成不同的OSLCOperatorDao对象；OSLCOperatorDao接口类提供统一的Operate()接口，由其子类具体实现.以Bugzilla和Jenkins集成为例，主要包括Bug数据管理、软件项目管理、部门管理和Jenkins任务管理，通过BugzillaDao类、ProjectDao类、DepartmentDao类、UserDao类和JenkinsDao类，分别实现了上述功能.

图2 OSLC Operator 相关类图
Fig.2 The class diagram about OSLC Operator

工厂模式中Bug数据管理相关的类设计如图3所示.其中BugzillaDao类继承自上面介绍的OSLCOperatorDao接口类，具体实现了Operate()方法.同样，BugzillaDao类也使用了工厂模式，在该类中根据Bug操作类型集成不同的Bugzilla_ActionDao对象.Bugzilla_ActionDao类提供统一的doAction()接口，由其子类具体实现，通过Bugzilla_Bug_update类、Bugzilla_Bug_delete类、Bugzilla_Bug_insert类、Bugzilla_Bug_queryall类各自实现doAction()方法，实现对Bugzilla中的Bug修改、删除、插入、查询等.

工厂模式中Jenkins任务管理相关的类设计如图4所示.其中JenkinsDao类继承自上面介绍的OSLCOperatorDao接口类，也具体实现了Operate()方法.同样地，JenkinsDao类也使用工厂模式，在该类中根据Jenkins操作类型集成不同的Jenkins_ActionDao对象.Jenkins_ActionDao类提供统一的doAction()接口，由其子类具体实现，具体实现的类有Jenkins_insert类、Jenkins_start类、Jenkins_close类等；这些类各自实现doAction()方法，从而实现创建Jenkins任务、启动Jenkins任务、删除Jenkins任务等.其它的类设计与上述类相似，故这里不再赘述.

图3 Bugzilla相关类图
Fig.3 The class diagram about Bugzilla

图4 Jenkins相关类图
Fig.4 The class diagram about Jenkins

图5 查询Bug时序图
Fig.5 Sequence diagram of querying bug

1.2 基于OSLC规范的工厂模式时序图设计

基于工厂模式设计相关类后，还需要进一步描述相关操作的时序图.例如，查询Bug的时序图如图5所示.用户需要查询Bug时，首先调用前端页面Javascript代码的query_all_bug()函数，然后admin.jsp传递一个post函数；HttpClient传递一个doPost()函数到后台AdminDao类，它执行后台操作Operator()，通过工厂类OSLCOperatorFactory分发到所属的BugzillaDao类，再判断此操作为查询操作，传递一个doAction()到Bugzilla_Bug_queryall类，这个类来执行具体的doAction()查询操作，返回相应的Bug数据.当执行成功后，返回一个query_success消息.

查询Jenkins任务的时序图与图5类似.用户需要查询Jenkins任务时，首先调用前端页面Javascript代码的query_all_jenkins()函数，然后admin.jsp传递一个post函数；HttpClient传递一个doPost()函数到后台AdminDao类，它执行后台操作Operater()，通过工厂类OSLCOperatorFactory分发到所属的JenkinsDao类，再判断此操作为查询操作，传递一个doAction()到Jenkins_queryall类，这个类来执行具体的doAction()查询操作，返回相应的Jenkins任务数据.当执行成功后，返回一个query_success消息.

其他操作的时序图与上述时序图类似，故不再赘述.

2 实验验证

本文以符合OSLC规范的Bugzilla缺陷管理系统和Jenkins持续集成工具的集成为例，以SunwiseAEM一体化研发管理平台为载体，采用工厂模式设计数据集成接口，完成基于OSLC的数据集成系统的设计与开发，实现了不同工具间的数据集成，对数据集成接口进行验证.

2.1 实验环境

操作系统：Win7及以上.

开发环境：MySQL、Eclipse.

运行环境：IE10.0、Chrome.

硬件环境要求：内存在 1GB 以上，显卡内存在 64MB 以上.

2.2 基于OSLC的数据集成系统

本文以SunwiseAEM一体化研发管理平台为载体来部署和验证基于OSLC的数据集成系统.SunwiseAEM是北京轩宇信息技术有限公司自主研发的一体化研发管理平台，支持工程管理过程，包括需求、设计、开发、测试与缺陷各个阶段的结构化管理，形成有效支持需求管理、代码管理、测试管理、持续集成、自动化测试与发布全流程、工具链集成，具有强大的工具集成功能，平台提供100%的API接口，可与第三方工具进行无缝集成.该平台的架构图如图6所示.

根据OSLC规范和工厂模式设计思想，设计数据集成系统架构图如图7所示.其中，数据集成系统视图层工作于SunwiseAEM平台的表示层，通过浏览器的Javascript页面实现用户数据的输入、系统数据的显示等功能；数据集成系统接口层工作于SunwiseAEM平台的接口层，采用工厂模式设计并实现OSLC数据集成接口，通过工厂类管理和调用相应的接口；数据集成系统功能接口层工作于SunwiseAEM平台的功能接口层，基于HTTP协议实现对符合OSLC规范的Bugzilla和Jenkins工具APIs的调用，实现对符合OSLC规范的Bugzilla和Jenkins工具的集成.

图6 SunwiseAEM平台架构图
Fig.6 System architecture of SunwiseAEM Platform

图7 系统架构图
Fig.7 System architecture diagram

该系统实现了如下功能：登录注册、组群管理、项目管理、用户管理、Bug管理，以及Jenkins持续集成管理，包括查看任务、创建任务、启动任务、禁用任务、删除任务、构建任务以及下载任务.功能结构图如图8所示.

仍以查询Bugzilla工具的Bug数据为例，在Javascript页面点击查看所有Bug，后端接收到这个请求后，解析出request中的字段，通过工厂类OSLCOperatorFactory获取BugzillaDao类对象.通过BugzillaDao类，获取Bugzilla_Bug_queryall类对象，调用Bugzilla_Bug_queryall类doAction()方法，在doAction()方法中通过调用Bugzilla的API实现对Bugzilla工具的Bug数据查询.获取的Bug信息显示如表1所示.其中，ID为Bug序号；项目名称为Bug所属的项目；描述为详细的Bug信息，可以是文本、图片等；版本为Bug所属项目的版本号；状态是当前Bug所处的状态，如未分配、已分配、修改中、回归测试中等状态.

图8 功能结构图
Fig.8 Functional block diagram

表1 查询Bug信息
Table 1 Querying all bugs

同样，以查询Jenkins工具的任务数据为例，在Javascript页面点击查看所有任务，后端接收到这个请求后，解析出request中的字段，通过工厂类OSLCOperatorFactory获取JenkinsDao类对象.通过JenkinsDao类，获取Jenkins_queryall类对象，调用Jenkins_queryall类doAction()方法，在doAction()方法中通过调用Jenkins的API实现对Jenkins工具的任务数据查询.获取的任务信息显示如表2所示.其中，ID为任务的序号；任务名称为Jenkins任务的名称；任务描述为详细的任务介绍；任务状态表示任务当前的状态，如启动、未启动等.

表2 查询Jenkins任务信息
Table 2 Querying all Jenkins tasks

该系统其它功能与查询Bug数据和Jenkins任务数据的过程类似，故不再赘述.

4 结 论

本文分析了软件协同开发过程中数据集成存在的问题，并调研了开放式生命周期协作服务(OSLC)规范用于数据集成的工作，结合工厂模式和OSLC规范来设计数据集成接口，将不同工具的数据集成抽象成公共接口，工厂类根据传入的参数，创建所需的产品对象，再实现具体工具的数据集成，有利于优化软件系统体系结构.目前，以符合OSLC规范的Bugzilla缺陷管理系统和Jenkins持续集成工具的集成为例，以面向航天软件系统研发的SunwiseAEM一体化研发管理平台为载体，基于工厂模式设计并实现了符合OSLC规范的数据集成系统，实现了不同工具的数据集成.

本文实现的数据集成系统只集成了Bugzilla缺陷管理系统和Jenkins持续集成工具两个工具，并没有对数据进行深入的分析和处理，无法对软件协同开发提供过多的帮助.当前，云计算、大数据与人工智能技术给软件协同开发也带来了巨大的改变，随着软件协同开发过程中各类数据的产生，包括数据集成系统在内的一体化研发管理平台需要进一步融合人工智能和大数据分析技术，为软件协同开发带来智能化服务.另外，数据安全/数据泄露事件频发，也使得数据安全成为数据集成领域的热点问题.一旦发生数据安全问题，对数据集成系统的影响将更加严重.因此，如何保障数据集成系统的数据安全也是下一步要考虑的问题.