构件形式认定指南

一、构件定义
1.1概述
目前对构件还没有一个公认的、统一的定义。一般来说有广义与狭义之分，广义上讲， 构件是指可以被明确标识的软件制品（ artefact），它可以是需求分析、设计、代码、测试用例、文档或软件开发过程中的其它产品。狭义来说，软件构件是指可复用的、提供明确接口完成特定功能的程序代码块（源代码、二进制代码或可执行代码），目前业界比较认可的定义有：

• 构件是指粗粒度的、相对独立的、可替换的软件系统组成部分，完成明晰的功能，在一个定义良好的体系结构下被组装到完整系统中去，它遵循和提供了一组接口的物理实现 [ Kruchten 98 ]。

• 软件构件是一个软件组装单元，具有契约规定的一组接口和外在的周境依赖。软件构件可独立部署和被第三方组装 [ 1996 ECOOP workgroup] 。

• 构件是指模块化的、可部署、可替换的软件系统组成部分，它封装了内部的具体实现并对外提供一组接口 [UML1.4Specification]。
• 运行时刻软件构件是一个可动态绑定的软件包，可作为一个单元来管理，通过文档化的接口来访问，这些接口可在运行时刻被发现 [Garner Group] 。

1.2本项目中有效构件的定义
根据 1.1 中所述，在此给出此次征集的有效构件的定义，如下：

软件构件是一个高内聚的、通过一组约定的接口完成明晰的功能、符合业界认可的模型标准（如 COM/.Net,Corba ， WebService 等）的、可复用软件包，可在一个体系结构周境下被直接或经适当调整后组装到软件系统中而成为其组成部分。 一个构件也可包含若干个子构件。一个构件也可以是 Web 服务方式的构件。

为方便起见，如非特殊说明，以后所提到的构件一词指上述定义的含义。

1.3构件的主要特点
根据 1.2 中定义，构件具有以下特点：

• 独立性 。构件可独立开发（需求分析、设计、编码、测试）、部署和发布。
• 有一组 定义良好的接口 。构件通过一组接口对外完成其功能，接口可分为 对外服务接口和服务请求接口。

• 封装性。 构件是一个高内聚的软件包，通过接口对外交互，屏蔽了内部实现细节，构件可通过独立开发封装为符合业界认可的模型标准的二进制代码。构件封装采用的标准有：
• COM/COM+/.NET
• JavaBean/EJB
• CORBA
• VCL
• WebService

• 可替换性。 构件被组装到软件系统中后，可以用具有相同接口和相同封装标准的其它构件将其替换下来，替换中无须任何编码工作，替换后该软件系统仍能运行。

• 可组装可调整性。 构件可在定义良好的体系结构下方便地组装到软件系统中，也可与其它构件组装成为粒度更大的构件。一般情况下，构件要有方便的可调整机制以便于复用，即提供了多个可变点利于客户化。

二、构件的呈现形式
根据 1.2，1.3中所述，在此提出，构件由以下几个物理组成部分：

• 构件刻面描述文档。每个构件应有规格化的描述文档，以满足构件在构件库中分类描述、存储和检索浏览的要求。
• 构件源码文件（本项为可选项）。开发该构件的所有源程序。对黑盒构件本部分可不提供。
• 构件封装后的软件包。包括构件源码编译后的生成的二进制文件（如 .dll,.jar等文件）包，伴随的部署文件和配置文件，以及需要的安装、注册文件。

封装后的二进制文件可符合下列五种之一：
• COM/COM+/.NET标准。其二进制文件格式可为.DLL,.OCX或.EXE。
• JavaBean/EJB。其二进制文件格式可为.Class或.Jar。
• CORBA 。
• VCL。其二进制文件格式为.BPS。
• WebService。

三、 关于领域构件
领域构件是构件的一个子类，它具有本文前面所提到的构件的所有属性特征，它的特点在于其功能上具有领域特征，领域构件从软件上实现了该领域中的重要概念，例如证券领域中的实时行情图。
领域构件的验定指标如下：
• 功能上实现了该领域中某个（些）重要概念。
• 呈现形式须满足第二节中所有组成部分的要求。

四、 关于构件粒度
目前软件工程领域对构件的粒度还没有统一的要求，由于构件是一个高内聚的软件包，只要符合软件工程中高内聚的原则，则构件的粒度大小可不限。一般来说，从可复用构件，领域构件，到商业构件（ Cots ），其粒度应是渐增的趋势。