海关软件构件库建设和管理体系分析

海关软件构件库建设和管理体系分析

黄埔海关 郭建岭姚坚 唐伟伟

 

摘要：随着海关信息科技建设工作的迅速发展，如何实现软件重用已经成为一个具有研究性的课题。本文以黄埔海关软件开发团队测试小组较长一段时间以来在构件建设管理方面的实践为背景，结合全国海关科技应用项目建设工作的开展情况和已上线应用系统的运行情况，详细描述了在海关信息系统环境下，利用构件实现软件重用与整合，降低运维工作复杂度的思考。并阐述了构件与构件库的应用理念，工作思路，建设规范，具体做法，典型案例，成功经验以及未来发展方向等方面的情况。

关键词：构件 部署 测试 配置管理 软件复用

 

1   前言

H2010以来，海关信息系统的建设进入的新的高潮。H2000的日趋成熟和周边系统的大规模膨胀，与此同时，IT领域各种新技术，新观念，新产品的不断涌现。相对H883到H2000整体更迭模式，H2010是一种非抛弃型的建设模式，在全新的整体规划指导下，原有系统功能的升级、整合与新功能的建设有效结合。

而海关软件开发构件库的建设，正是在这种“改造，升级，整合”的SOA思路下，针对“软件重用”这个现实目标，以测试和部署环节为突破口，逐步建立起来的一套工具和管理体系。在这方面，黄埔海关首先进行了积极的研究和实践。

为什么要选择“测试和部署环节”作为突破口？这个答案来自于我们对海关信息系统建设和应用管理整体情况的全面分析。多年来，我们孜孜不倦的在开发架构，需求分析，业务梳理等多方面寻求软件重用的方法并进行了大量实践，也取得一定成效。但我们发现两个始终绕不开的困难：

10年多前，从VMS小型机平台开始转向WINDOWS平台后，基础软硬件呈现多样化和复杂化，并且这种趋势快速发展。

“基础”太多显然不是一件好事情——基于不同基础环境的软件即使功能类似，也很难重用：以开发工具为例：海关内部用到的了几乎全套微软的产品：H2000最初的VB，COM+等，到.NET1.0,1.1,2.0,3.5等，此外还有大量其它第三方基础软件，这些不同开发工具开发的软件，重用起来困难不小。

另一个方面，海关内部的软件重用大都停留在开发阶段的技术框架重用。而在测试阶段，尤其在部署到运行环境后，软件模块的重用度比开发环境大大降低，典型的现象就是从总署到各关，几乎每上线一个项目，都需要增加一组服务器。目前已经进行的资源整合，也只是停留在虚拟机的应用层面，而更本质的服务整合，应用整合的进展仍然是步履维艰。这造成了一方面信息化应用系统在资源方面的投入大量增加，同时运维部门工作量持续增加，运维人员不得不面对着比开发部门更多的配置管理任务和更复杂的环境。

随着运维部门的工作压力大增，应用系统的不稳定性随之增加。

经过全面的分析和对一些典型案例的观察，我们重新认识了这个原本以为可以忽视的问题：软件重用不能仅仅停留在开发阶段，而必须认真务实的解决测试和部署阶段的软件重用问题，必须正视当前运维工作复杂化和测试环节工作量大量增加的问题，才能真正实现信息系统可持续健康发展的目标。

同时，我们继续参考了IT领域业界的成功经验和主流趋势，越来越形成了清晰的认识：首先在测试和部署环节引入构件化的思路，以构件作为软件重用的基本单元，以构件作为海关应用系统产品化的突破口——这就是应对海关信息系统基础环境多样化带来的各种问题的关键解决方案。

2   构件是海关应用软件产品化的重要基础

(1) 概念描述

【Component】这个英文名称更准确概括了“构件”的含义。

此外，在详细阐述构件概念之前，仍然要再次强调一下我们的目标：

l  在测试和部署阶段有效延续开发环节实现的软件重用的成果；

l  提高软件系统的产品化水平，降低测试和运维工作的复杂程度，提高系统稳定性；

软件业界普遍认同的构件概念有如下一些：

 

构件是系统中实际存在的可更换部分，它实现特定的功能，符合一套接口标准并实现一组接口。构件代表系统中的一部分物理实施，包括软件代码（源代码、二进制代码或可执行代码）或其等价物（如脚本或命令文件）。

 

构件是面向软件体系架构的可复用软件模块。构件可被用来构造其他软件。它可以是被封装的对象类、类树、一些功能模块、软件框架（framework）、软件构架（或体系结构Architectural）、文档、分析件、设计模式（Pattern）等。

软件构件应具备以下属性：

（1）有用性（Usefulness）：构件必须提供有用的功能；

（2）可用性（Usability）：构件必须易于理解和使用；

（3）质量（Quality）：构件及其变形必须能正确工作；

（4）适应性（Adaptability）：构件应该易于通过参数化等方式在不同语境中进行配置；

（5）可移植性（Portability）：构件应能在不同的硬件运行平台和软件环境中工作。

日历、工作流构件、订单构件、用户界面控制等等都可以是构件。

 

构件库是为了支撑快速开发、部署应用系统而提供的，具有高度复用能力的一组预制构件的集合。通过对构件的管理可以建立一套针对构件的生产、改进、管理、沉淀和发展的完整软件管理机制，使得企业组织级的软件知识沉淀可以通过构件库的形式得以实现和发展。

面向构件就是面向服务的实现，面向构件可以按照面向服务的架构组装起来，它们可以让企业以粒度更小的服务构件去表达业务，从而让SOA得到更深入、更彻底的表达。

 

软件构件是指具有相对独立的功能和可复用的软件成分,而常提到的构件是代码级上的构件,它将一系列相关的操作和服务加以封装,只以接口的形式呈现给其他访问者

一般来说,软件构件就是指可以实现一定功能的相对独立的单元模块.它应该是具有预制性、封装性、透明性、互换性和通用性的一个软件单元

软件构件是指应用系统中可以明确辩识的构成元素,是软件构架的主要构成元素.软件构架包括软件构件、构件间的联系,以及系统构造方式,约束、语义、分析、属性、基本原理、系统需求等

软件构件是指可重用的软件单元,可以被用来构造其它软件.它可以是被封装的对象类、一些功能模块、软件框架、软件系统模型、软件的文档,如可重用的分析件、设计件等

“软件构件”是指经过事先测试的、预制的、自封闭的、可重用的软件模块.这种软件模块把数据和过程封装在一起以实现某一类特定的功能是构成软件重用的基本材料

所谓软件构件是指可应用于不同应用环境(同一系统的不同地方或不同系统)的软件实体,它可以是程序、文档或数据.本软件构件是指可对其进行复用的程序

因此软件构件主要是指可复用软件构件,即:可以被多个软件系统所复用的、具有相对独立功能的系统构成成分.在后面的讨论中,除非特别指出,我们论及的构件皆指可复用软件构件

 

汇总上面这些关于构件的定义，可以发现本文要重点讨论的几个观点：

重用性：以软件复用为目标；

标准性/独立性：标准接口；可更换；可组装；

适应性：应用于不同环境；

完整性：包括多种元素(对象，类，各种代码，文档，架构…)；

构件和服务的区别：单独的构件具备一定的技术能力，但并不具备直接提供业务功能的能力，一般情况下，需要通过开发人员的集成，进一步组合调试，才会形成具有真正业务功能的服务，从这个特征上看，构件和服务的区别就是“是否经过了集成而具备了直接可用的功能”。

(2) 下面谈谈具有海关特色的构件概念

我们全面参考了软件领域对构件认识的主流概念基础，结合海关信息系统当前的体系结构和工作环境，确认了海关软件开发构件库的几个最重要的特征和建设中遵循的原则：

构件既足够小，以便于维护，又应足够大，以使之具有功能，可以被打包和使用。实际上，决定构件的颗粒度的最重要出发点是便于开发，维护，升级等现实的技术工作需要。

海关软件应用系统在测试和部署环节的基本操作单元就是构件，它是测试和部署环节实现软件复用的基本单元。

构件是应用系统版本管理的最小单元，以构件为基础实现了软件应用系统产品化和版本化管理。

构件是一组包含若干个DLL、EXE、配置文件、多媒体文件、数据库脚本、XML文档、javascript脚本等等等的文件包；最常见的情况是对应1-n个编译好的DLL文件。

构件可分为基础框架构件和应用项目构件，前者可用于各种场景下的项目开发，重用度较高。

构件之间没有相互包含的关系，但存在广泛的相互引用关系。同时，一个程序集不能属于多个构件，其他辅助文件如果被多个构件包含，应该认为是不同的文件。

构件库的服务目标主要是测试和部署环节，但也可以提供开发阶段使用；例如：开发环境中的基础框架等公共服务组件可以直接从构件库获取。

每个构件有自己的部署方式，并且独立；

对象、类，构件，服务，应用系统之间的关系如下：

若干个方法，属性组成了类；

若干个类和其它资源(resources)组成了DLL；

若干个DLL（此外还可以包括其它资源，脚本，文档等）组成了构件；

若干个构件组成服务(但一个构件可以对应多个不同的服务）；

若干个服务组成了应用系统；

在确定上述原则的基础上，我们可以认为：构件是包含若干软件组件的基本单元，它实现了对更小颗粒度软件组件的标准化封装，成为海关信息系统软件包版本管理的基本单元。而构件库则是体现开发环节工作成果的标准发布位置。

实际上，从发布管理的角度看，构件库就是DSL（最终软件库）。构件库大大简化了开发和测试环节工作交接的复杂程度，降低了由于开发和测试之间沟通繁琐而可能产生的问题，同时，也为后续部署，运维等环节的工作规范化奠定了技术基础。

(3) 软件系统构件化的意义

上面谈到了软件构件的各种特征，这些特征的本质上是围绕着提高软件质量，提高软件开发效率和服务效能等目标。

为什么构件化能达到这些目标，这方面的理由我们可以从下面两个行业的经验很容易感受到。

一个行业就是与软件悉悉相关的硬件行业。

IT硬件发展到今天，不论是小到一部手机或MP3，还是超级服务器甚至巨型机等，无不是有各种硬件模块组成，这些硬件模块就是我们谈到的“构件”。这些硬构件显然都具有我们前面提到的各种特征：显卡上集成了多个芯片和电子元件，成为一个标准接口的部件；一个型号的显卡显然可以插在多个不同型号的电脑上；我们可以找到多种型号的符合这个标准接口的显卡，它们之间都可以互换。硬件层面的构件化让我们受益匪浅：低成本的DIY组装电脑，定制个性化的品牌电脑，随时升级正在使用的电脑，故障快速诊断并通过部件更换实现快速恢复。

构件化带来的效益继续在很多行业重复着：汽车、家具、建筑甚至是麦当劳式的快餐店，都在不断创造着一个又一个为行业带来高效率的“构件”，在这些行业中，没有哪个工厂会从最初级的原材料开始加工，直到生产出最终成品。相反，每个成品的生产厂往往与一批具有大规模生产能力的“加工型生产车间”形成紧密的合作关系，后者只生产半成品，即：“构件”，然后前者利用这些“构件”可以快速集成出各种型号的最终产品。

软件的未来也必然是相同的模式：今后最伟大的软件公司不再是微软这样垄断型的企业，而是成品软件的集成者，他们会像丰田公司这样，有一批零配件工厂围绕着。对于软件行业，大规模生产车间的产品就是“构件”，这些专门编写构件的软件企业为向负责系统集成的软件公司提供大量的“构件”，双方形成相互依赖又松散联系的关系。

再用更简单的语言重复一下上面的分析：实际上构件就是软件应用系统的半成品。越复杂最终产品，越庞大的生产管理体系，对半成品的管理要求就越高，这些要求概括起来，几乎就是前面谈到的构件化各种特点。

(4) 实施构件库建设，进一步完善SOA体系架构

SOA的实施有两个重要方面：一是建立服务总线（ESB），二是面向业务的需求架构设计方法。从技术出发到面向业务的SOA设计方法，实现这个转变的关键方法就是软件系统构件化。

下图示意了构件和SOA服务的关系：

【图1-1】

【图1-1】案例中，各个灰色的矩形是一个独立的服务，其中包含一个或多个构件(蓝色矩形)。构件具有可开发、可部署、可运行和可管理的特性，技术细节封装在构件内部。但构件的接口一般不直接作为服务接口，而是经过适配器的衔接使服务能处于服务总线的管理之下，同时服务的接口也实现了面向业务，契约化的转变。

当然，SOA并非实现构件化的前提条件。在SOA到来之前构件化只是有效实现技术层面的模块化、层次化和专业化，而SOA时代则实现了面向服务的业务集成和服务管理方法，构件化的发展对SOA的实施起到了重要的支撑作用。

3   建立构件管理体系，提高测试和配置管理水平

黄埔海关在这方面进行了深入和有益的尝试。

(1) 首先第一点，是建立专职测试人员队伍

埔关技术部门领导对测试工作的高度重视，这是我们实现构件化管理，推进软件系统产品化进程的最重要因素。H2000全面投入应用后，埔关技术部门很快意识到：海关信息系统日益复杂化的趋势不可避免，同时系统运行的稳定性对海关日常业务和政务管理的影响却越来越大。如何解决这种系统运维难度增加和运维效果要求更高的矛盾——显然，测试工作的重要性不言而喻。

测试小组的成立，使我们能够从人力投入，优化机制和技术手段三方面着力解决系统复杂性和运维稳定性之间的矛盾，从而大大推进了埔关开发团队在软件测试工具，测试方法等方面的专业化，规范化程度，也为埔关开发部门实现规模化的开发能力奠定了基础。

在测试小组成立的最初阶段，主要的工作目标有两方面：

一是围绕自动化测试和部署技术提高工作效率；

二是围绕测试用例的完善和优化，促进测试人员和开发人员的有效协作；

测试小组第一阶段的工作取得明显效果，最重要的标志是测试环节真正成为整个开发周期中不可缺少的环节，测试小组完全承担起了质量把关的角色。

(2) 以构件化为手段，推进海关软件应用系统产品化

测试小组第二阶段的工作重点已经转变为内部工作流程优化和测试技术本身的进步方面。在有效承担起质量把关角色的基础上，测试小组进一步开始了推进海关软件应用系统产品化的阶段任务。

长期以来，海关软件开发体系处于自产自销的状态，开发者往往最后演变成运维人员。不断附加的变更需求使软件内部结构越来越混乱，软件的生命周期日益缩短。开发人员直接承担运维任务的弊端是往往分不清到底是在开发还是在维护，大家分不清软件的每一项修改是为了适应新的需求还是为了解决一个BUG。这种机制下开发出来的软件基本没有复用的价值，而软件复用程度的降低，反过来导致开发工作量的增加，此外还进一步缩短了软件生命周期。

开发和运维的分离已经势在必行，但开发部门的成果如何顺利转移到运维部门——建立最终发布软件库（DSL）成为大家的共识。这项任务责无旁贷地落到测试小组的肩上，测试小组在第一阶段进展目标成功实现的基础上，以构件化为手段，在实现软件构件版本化的基础上，建立起最终发布软件库。

埔关建立的最终发布软件库目前有两部分的内容：

以应用系统为单元的部署包；

构件+构件化的部署包；

上述第一部分是传统的非构件化的软件部署包，随着构件化工作的不断推进，各种技术基础构件和业务构件会继续增加，最终将完全取代上述第一部分。

构件库对配置管理流程的简化和完善

配置管理是运维工作的核心，一般包括下面几方面任务：

版本控制：定义配置项和版本的标识规则。

变更管理：制定控制变更的权限和实施步骤。

配置数据：记录、追踪配置项的变更状态，并验证配置项的正确和完整性；

配置库管理：提供了配置信息可监控，可审计，可分解，可复制，可测试等全面可控的能力。

发布管理和流程化：在配置工具的支持下，形成配置信息的变更从提出到发布的流程化。

比起传统的以应用系统为单元的部署包，构件库在简化配置管理方面的优点主要有：

构件作为配置管理的对象，具有最佳的颗粒度，有效减少配置管理对象的数量；

构件本身已经实现了良好的版本化管理，大大简化了配置管理中的版本控制工作量；

构件实现了标准化的接口，使配置管理中的操作对象识别，操作过程审计，软件系统集成测试等步骤的自动化管理更加可行；

在海关这样的复杂运行架构下，运维人员最头痛的一个问题是大部分配置项只能手工维护，在传统按应用项目为单元的配置管理体系下，这些配置项很容易堆积在一起，修改维护起来非常困难；而构件把配置项大量封装在构件内部，不同构件的配置项各自独立，实现松耦合；

最终发布软件库（DSL）是开发团队和运维团队的接口，构件从一开始就作为DSL的组成部分，符合开发和运维两方面的工作需要，进一步增强了两边工作衔接的规范化和标准化。

根据埔关开发团队最近一年的工作情况统计，测试小组一年来提交各种应用项目的发布软件版本超过500个，平均每个工作日2个。这些发布版本分为初次发布，小型修改发布，大型修改发布等几种类型，每个发布版本的内容包括：可执行组件，部署文档，配置项(包括配置文件，参数等)三部分，其中编写文档和整理配置项的工作量最大，从实际工作情况看，生成一个发布版本平均需要1人天的工作量（其中初次发布版本和大型修改发布版本的生成一般需要2天，小型修发布版本则需要0.5人天）。

另一方面，从应用系统构件化实施以来，由于每个构件独立性很强，生成一个构件发布版本的工作量比起生成整个应用系统的工作量大为减少，一般情况下不超过半天工作量，尤其是小型修改的发布版本，大部分情况只需要不到半小时的时间。同时，由于一个应用系统包含的构件数量有限(一般不超过10个)，因此，应用系统整体的发布版本只是在构件发布版本的基础上进行简单的组合即可，工作量可以忽略不计。

(3) 形成海关特色的软件构件库管理体系

l  构件库建设规范

构件库的建设首先是确定各种规范标准，埔关构件库的两个主要组成部分说明如下：

a)     第一部分：技术基础构件部分

黄埔外挂框架——HpexFx

MuseFrame框架——MuseFx

HB2004框架——HB2004Fx

b)    第二部分：应用系统构件

一般来说，每个应用系统构件又可以分为几类：

客户端构件，一般命名规则：<子系统名>_client；

中间层服务构件，一般命名规则：<子系统名>_server；

业务通用构件，一般命名规则：<子系统名>_common；；

其它特殊应用点构件（例如：第三方提供的三维图像显示软件封装成的构件）

l  几个具体构件的范例

下面列出具体几个构件的文档部分，这些构件的实际组成部分还包括可执行组件，配置项等部分。（内容经过部分删减和修改）

黄埔外挂框架的数据访问构件

V1.0是H*Fx.DataAccess构件的初始版本，其所包含的内容如表2.1.1-1所示，该构件依赖项如表2.1.1-2所示。

表2.1.1-1H*Fx.DataAccess构件V1.0文件清单

文件名

版本

变更类型

H*.Practices.EnterpriseLibrary.Data.dll

1.0

新增

H*Define.dll

1.0

新增

H*Tools.dll

1.0

新增

H*.FrameWork.DataAccess.dll

1.0

新增

表2.1.1-2 H*Fx.DataAccess构件V1.0依赖清单

名称

类型

版本

备注

微软企业库

Microsoft.Practices.EnterpriseLibrary

第三方类库

1.1

 

H*框架外部支持构件

H*Fx.External是为了H*框架提供支持功能的构件。该构件的基本信息如表2.2所示。

表2.2H*Fx.External构件基本信息

创建日期

2010-3-25

存放位置

/基础框架构件/H*Fx.External

运行平台

Dot Net Framework 1.1 及以上

V1.0版是H*Fx.External构件的初始版本，其所包含的内容如表2.2.1-1所示，该构件依赖项如表2.2.1-2所示。

表2.2.1-1H*Fx.External构件V1.0文件清单

文件名

版本

变更类型

ADAccess.dll

1.0

新增

AxInterop.MSCommLib.dll

1.1

新增

AxInterop.SEALCONTROLLERLib.dll

1.0

新增

AxInterop.SHDocVw.dll

1.0

新增

DataAccess.dll

1.0

新增

 

1.0

新增

H*.OUAndPermissions.dll

1.0

新增

H*.Practices.EnterpriseLibrary.Data.dll

1.1

新增

Interop.SEC_CLIENTBASELib.dll

1.0

新增

Interop.SHDocVw.dll

1.1

新增

list.txt

1.0

新增

Mscomm32.ocx

6.00

新增

OUAndPermissions.dll

1.0

新增

PhotoListBox.dll

1.0

新增

SealController.ocx

1.0

新增

Tools.dll

1.0

新增

WebUtils.dll

1.0

新增

表2.2.1-2 H*Fx.External构件V1.0依赖清单

名称

类型

版本

备注

微软企业库

Microsoft.Practices.EnterpriseLibrary

第三方类库

1.1

 

 

(4) 埔关构件库建设进展情况

目前，埔关构件库仍然处于建设阶段，我们已经实现的阶段目标如下：

建立了构件库物理存储方式和空间；

确定构件版本编制规则和管理办法——版本分为测试版本和发布版本两种，发布版本是经过充分测试，确认是功能相对完整，运行稳定的测试版本转化生成；

制定构件生成和入库操作规范，尽量降低手工操作的比例，实现快速产生构件的新版本；

以构件作为技术联调测试和业务测试的基本单元，最终目标是完全针对构件进行测试，并且进一步实现运行环境和测试环境中发布版本完全对应；

在构件管理中，构件划分和构件生成是两个关键点：我们根据海关技术队伍和应用场景的特点，确定一般由开发人员和测试人员协商确定构件的划分和颗粒度，而构件生成则完全由测试人员负责；

结合正在开发建设的应用项目，持续不断增加构件的数量并提高质量。

 

4   结束语

软件构件技术是支持软件复用的核心技术之一。目前，埔关构件库的建设和软件系统构件化的过程仍然在进行中，尽管取得了一定的成果，但还存在不少问题和疑惑，应用的广度和深度也有待继续扩展。

今后，我们还会在构件生产与获取、构件模型、构件描述语言、构件分类与检索、构件组装和标准化等各个方面继续研究和实践。同时，今后的构件化推进工作也会前推到开发阶段甚至需求分析阶段，涉及更完整的软件生命周期：需求、需求规约、构架、文档、测试计划、测试用例和数据等都会受到构件化管理模式的影响而进一步规范，标准和高效。

 

 

 

修改历史

 

修改人

修改日期

修改说明

修改标志

1.        

郭建岭

2010/4/1

创建本文档

 

2.        

郭建岭

2010/4/19

继续修订

 

3.        

郭建岭

2010/4/21

继续修订，基本完成

 

4.        

姚坚

2010/9/1

对摘要进行修订

 

5.        

郭建岭

2010/9/10—9/17

再次修订校对

 

6.        

郭建岭

2010/11/3

再次修订校对