第8章基于构件的软件开发

在软件工程的范围内，复用既是旧概念，也是新概念。软件开发人员从软件开发的早期阶段，就已经开始复用概念、对象、论据、抽象和过程，但其复用的层次是较为特定的。而今，更为复杂的基于计算机的系统必须在非常短的时间内建立，这就需要更有组织的复用方法。

基于构件的软件工程（component-based software engineering, CBSE）是强调使用可复用的软件“构件”来设计和构造基于计算机的系统。

8.1构件和基于构件的系统开发

从表面上看，CBSE似乎类似于传统的或面向对象软件工程。当软件小组使用传统的需求分析技术建立了待建造系统的需求时，该过程开始，体系结构设计（见§4.4）被建立，但是，项目开发小组并不是立即转向更细节的设计任务，而是必须检查需求以确定系统的什么子集可直接通过组装而不是构造完成。也就是说，项目小组针对每个系统需求询问如下问题：

1) 是否存在商用成品构件（commercial off-the-shelf，COTS）可实现该需求？ 2) 是否存在内部开发的可复用构件可实现该需求？ 3) 可用构件的接口和待建造系统的体系结构相容吗？

在此，术语“构件”被重复地使用，而对该术语的确定性的描述未曾明确给出。常用的相关定义可为：

1) 构件——某系统中有价值的、几乎的并可替换的一部分，它在很好定义的体系结构语境内满足某清楚的功能。亦可定义为“系统中可以明确辨识的构成成分。

2) 运行时软件构件——作为单元管理的软件包，安装运行时可通过接口动态绑定其相关的一个或多个程序。

3) 软件构件——仅具有合约性描述的，显示的语境依赖的组装单元，亦即为一个发布的功能部分，它提供了通过接口对它的服务的方向。

4) 业务构件——某“自治的”业务概念或业务过程的软件实现。

5) 商品构件COTS，由第三个构造的满足一定构件标准的，可组装的软件构件。

在基于构件的软件系统开发指导下，开发小组试图修改或去除那些不能用COTS构件和自有构件实现的系统需求。如果需求不能被修改或删除，就必须传统的或面向对象的软件工程方法开发以满足需求的新构件。但是，对那些可被现存构件满足的需求，亦需采用不同的软件工程活动：

1) 构件合格性认证（component qualification）。系统需求和体系结构定义了所需的构件。可复用的构件（不管是COTS或自有）通常是通过它们的接口特征来标识的，即“被提供的服务，以及客户访问这些服务的方式”被作为构件接口的一部分而描述。但是，接口并不提供构件将符合体系结构和需求的全面描述。软件工程师必须通过一个发现和分析过程来认证每个构件的适合性。

2) 构件适应性修改(component adaptation)。在第4章，我们提到软件体系结构表示了由构件（功能性单元）、连接和协同构成的设计模式。在某些情形，现存的可复用构件可能和体系结构的设计规则不匹配，这些构件必须被自适应以满足体系结构的需要或被丢弃并被其他更合适的构件替代。亦可通过适应性修改以更改（也称掩盖(mask)或包装(wrap)不想

1

要的或不希望的特征）。

3) 构件组装（component composition）。体系结构风格再次在软件构件被集成以形成工作系统的方式中扮演了关键角色。通过标识连接和协同机制（如设计的运行时性质），体系结构指导最终产品的组装。

4) 构件更新（component update）。当系统由COTS构件实现时，更新由于第三方的强行进入而变得复杂（即开发可复用构件的组织可能是在软件工程组织的直接控制范围之外）。

8.1.1 CBSE对质量、生产率和成本的影响

大量来自产业实例研究的证据表明从积极的软件复用可以导出实质性的商业收益，产品质量、开发生产率和整体成本都将得到改善。 1) 对质量的影响

理想情况下，为了复用而开发的软件构件已被验证是正确的且不含有错误。在现实中，形式化验证并不能例行公事地进行，错误可能而且也确实存在。然而，随着每一次复用，错误被发现和消除，构件的质量也随之改善。随时间推移，构件变成实质上无错误的。 在HP公司的研究中，Lim报告说：被复用的代码的缺陷率是每KLOC有0.9个缺陷，而新开发的代码的缺陷率是每KLOC有4.1个缺陷。对一个包含68%复用代码的应用来说，缺陷率是每KLOC有2.0个缺陷——相对应用的无复用开发，对期望的缺陷率有35%~51%的改善。虽然不同的报告跨越了质量改善百分率的一个合理的范围，但是，显然我们可以说，复用对交付的软件在质量和可靠性方面确实带来的实质性的收益。

2) 对生产率的影响

当可复用软件制品被应用于软件开发过程中，在创建对开发一个可交付系统所需要的计划、模型、文档、代码和数据方面所花费的时间自然要少，导致的结果是：用较少的努力给客户提供了相同级别的功能，因此生产率得到了改善。虽然，对生产率改善百分率的报告是众所周知难于解释的，但是，似乎30%~50%的复用可以产生25%到40%的生产率改善。

3) 对成本的影响

复用带来的纯成本(cost)节省如下估算：估算出项目如果是从头开始开发所需要的成本Cs，然后减去和复用关联的成本Cr与软件被交付时实际的成本Cd之和。

Cs可以用第14章中讨论的估算技术的一个或多个来确定，和复用相关的成本Cr包括：

1) 领域分析和建模。 2) 领域体系结构开发。

3) 为方便复用所增加的文档量。 4) 可复用构件的支持和增强。

5) 对从外部获取的构件的版税和许可证费。 6) 可复用构件中心存储库操作的创建或者获得。 7) 对设计和构造复用人员的培训。

虽然和领域分析与复用中心存储库的操作相关的成本可能是实质性的，但是上面提到的很多其他成本所强调的问题实际上是一个好的软件工程习惯的一部分。

8.2 CBSE过程

图8－1给出了一个典型的过程模型，它显然适应CBSE。领域工程创建应用领域的模型，

2

该模型被用作在软件工程流中分析用户需求的基础。类属的软件体系结构（及其对应的结构点，见8.3.3节）为应用的设计提供了输入。最后，在可复用构件已经被购买、从现存库中选出或构造好后（作为领域工程的一部分），它们可以被从事基于构件开发的软件工程师使用。

领域工程领域分析软件体系结构开发可复用构件开发领域模型结构模型中心存储库可复用软件制品/构件 基于构件的开发构件合格性认证构件适应应用软件分析体系结构设计构件组装构件更新构件工程测试 图8－1 一个支持CBSE的过程模型

CBSE过程的刻画必须是：不仅标识候选的构件，而且认证每个构件接口合格性、适应性修改构件以消除体系结构不匹配、组装构件到选择结构风格中以及当系统需求变化时更新构件。

基于构件的软件工程的过程模型强调并行的轨迹，其中领域工程（见§8.3）和基于构件的开发并发地发生。领域工程完成一系列工作，以建立一组可以被其他软件工程师复用的软件构件，然后这些软件构件被越过分隔领域工程和基于构件的开发的“边界”传送。

8.3领域工程

领域工程的目的是标识、构造、分类和发布一组软件构件，它们对某特定应用领域中现存的和未来的软件系统具有良好的适用性。其整体目标是建立相应的机制，使软件工程师在开发新的或现存的系统时可以共享这些软件制品——复用它们。 领域工程包括三个主要的活动——分析、构造和发布。

3

8.3.1 领域分析过程

面向对象软件工程范围内的领域分析方法的步骤定义如下： 1） 定义将被研究的领域。 2） 分类从领域中抽取的项。 3） 收集领域中有代表性的应用样本。 4） 分析样本中的每个应用 5） 开发针对对象的分析模型。

必须注意，领域分析被采用到任意软件工程范型，可以采用到传统和面向对象的软件开发。

Prieto-Diaz扩展了上面给出的第二个领域分析步骤，建议了8个步骤的标识和分类可复用软件构件的方法： 1） 选择特定的功能或对象。 2） 抽象功能或对象。 3） 定义分类法。 4） 标识公共特征。 5） 标识特定的关系。 6） 抽象关系 7） 导出功能模型。 8） 定义领域语言。

领域语言使得可以在领域中进行应用规约及以后的应用构造。 在实际应用，可采用如下指南来标识可复用软件构件： 1) 构件功能对未来的实现工作是需要的吗？

2) 构件功能在领域中的公共性怎样？ 3) 在领域中存在构件功能的重复吗？ 4) 构件是否有硬件依赖性？

5) 硬件在不同实现之间保持不变吗？

6) 设计是否为了下面的实现进行过足够的优化？

7) 我们能够将一个不可复用的构件参数化以使其变成可复用的吗？ 8) 构件是否可以仅仅经过少许修改就能够在很多实现中可复用？ 9) 通过修改进行复用是可行的吗？

10) 某不可复用的构件能够通过分解以产生一组可复用构件吗？ 11) 针对复用的构件分解事正确的吗？

8.3.2 领域特征

有时要判定一个可能被复用的软件制品是否在某些特定情况下可使用可能存在一些难度。为了进行如此的判定，就有必要定义一组领域特征，在领域中所有的软件共享这组特征。一个领域特征定义了存在于领域中的所有产品的某种类属属性，例如，类属特征可能包括：安全性/可靠性的重要性、程序设计语言、处理中的并发性以及很多其他内容。

某可复用软件制品的领域特征的集合可以表示为{Dp}，这里集合中每个项Dpi表示某特定的领域特征。赋给Dpi的值表示一个顺序的等级，它指明了该特征对软件制品p的相关性，典型的等级可能是： 1) 与复用是否合适没有相关性。 2) 仅仅在某些特定的情况下相关。

4

3) 相关，软件制品可以被修改使其可以被复用。 4) 明显相关，并且如果新软件不具有这个特征，复用将是无效的，此时不推荐复用。

当新软件w将在某应用领域内被构造时，可为它导出一组领域特征，然后在Dpi间Dwi进行比较，以展示是否现存的软件制品p可以在应用w中被有效地复用。 表8－1列出了典型的可能对软件复用有影响的领域特征。

表8－1 影响复用的领域特征

产 品 过 程 人 员 需求稳定性 过程模型 动机 并发软件 过程符合性 教育 内存约束 项目环境 经验/培训 应用大小 进度约束 ·应用领域 用户界面复杂性 预算约束 ·过程 程序设计语言 生产率 ·平台 安全性/可靠性 ·语言 寿命需求 开发队伍的生产率 产品质量 产品可靠性

即使将被开发的软件显然属于某语言领域，在该领域中的可复用软件制品也必须被分析以确定它们的可用性。

8.3.3 结构建模和结构点

当应用领域分析方法时，分析员试图寻找在某领域中应用间的重复模式。结构建模（structural modeling）是一种基于模式的领域工程方法，应用该方法的前提假设是：每个应用领域存在重复的（功能的、数据和行为的）模式，它们具有可复用的潜在可能。 Pollak和Rissman描述结构模型如下：

结构模型由少量的结构元素组成，这些元素用于表明清晰的交互模式。使用结构模型的系统其体系结构通过多个由这些模型元素组成的东西来刻画，这样，在系统的体系结构单元间的复杂交互可以用在这些少量元素间的简单交互模式来描述。

每个应用领域可用一个结构模型来刻画（例如，飞行器电子设备在细节上差异很大，但是在该领域的所有现代软件具有相同的结构模型），因此，结构模型是一种体系风格，它可以也应该在领域内跨越应用被复用。

McMahon描述结构点（structure point）为：“结构模型中的一个独特构成成分”，结构点由三个独特的特征： 1） 一个结构点是一个抽象，它应该有有限数量的实例。用面向对象的术语来陈述，则是说类层次的规模应该较小。此外，抽象应该在领域中贯穿不同应用不断重现；否则，需要用于验证、文档化和发布结构点的工作在成本上是不合算的。 2） 管理结构点的使用的规则应该是容易理解的。此外，结构点的接口应该相当简单。 3） 结构点应该通过隐藏所有包含在结构点内部的复杂性而实现信息隐蔽，这样减少整个系统可被感知的复杂性。

作为把结构点当作系统的体系结构模式的一个例子，考虑报警系统软件领域，该领域可能包含如SafeHome这样简单的系统或如工业过程报警系统这样的复杂系统，然而，在每种情况下，均可以遇到一组可以预测的结构模式：

5

1) 界面，使用户能够和系统交互。

2) 范围设置机制，允许用户设置将被测度的参数的范围。 3) 传感器管理机制，和所有的监控传感器通信。

4) 响应机制，对传感器管理系统提供的输入作出响应。 5) 控制机制，使用户能够去控制监控被实施的方式。 这些结构点每个被集成到一个领域体系结构中。

有可能定义类属的结构点，它们跨越一组不同的应用领域：

1) 应用前端——包括所有菜单、面板、输入和命令编辑设施的GUI。 2) 数据库——所有和应用领域相关的对象的中心存储库。 3) 计算引擎——操作数据的数值和非数值模型。 4) 报告设施——产生所有种类的输出的功能。

5) 应用编辑器——根据用户特定需要定制应用的机制。

8.4基于构件的软件开发

基于构件的开发是一个和领域工程并行发生的CBSE活动。使用在本书前面提到的分析和体系结构设计方法，软件小组精化适合于（针对待建造应用而创建的）分析模型的体系结构风格。

一旦体系结构被建立，它必须用构件去充实，这些构件或者可从复用库中获得，或者根据专门需要而开发。因此，基于构件的开发的任务流有两个并行的路径（图8－1）。当可复用构件可被用于潜在地集成进体系结构中时，它们必须被进行鉴定和适应性修改。当需要新的构件时，必须重新开发，然后，产生的新构件被“组装”（集成）到体系结构模板中，并进行全面测试。

8.4.1构件鉴定、适配和组装

如前所述，领域工程从领域应用中提取可复用构件并将其放在构件库中。在构件库中，可以自行开发或从现存系统中抽取得到，亦可从第三方购买或外包。

但是，可复用构件的本身并不能保证这些构件可以被容易地或有效地集成到为新应用选择的体系结构中。因此，当某构件被提交复用时，亦有一系列基于构件的开发活动。

8.4.1.1构件鉴定

构件的鉴定保证某候选构件将完成所需的功能，将合适地“安装”到为系统选定的体系结构风格中，并且将展示该应用所需的质量特征（如性能、可靠性、可用性）。

接口描述提供了关于构件的操作和使用的有用信息，但是，它并没有提供可有效复用的所有信息。在构件认证中考虑的很多因素时： ·应用编程接口（API）。 ·构件所需的开发和集成。

·运行时需求，包括资源使用（如内存和存储器）、时间或速度以及网络协议。 ·服务需求，包括操作系统接口和来自其他构件的支持。 ·安全特征，包括访问控制和身份验证协议。

·嵌入式设计假定，包括特定的数值或非数值算法的使用。 ·异常处理。

当使用企业本身开发的可复用构件时，这些因素的每一个均是相当容易评估的。因此，在企业内部或应用了良好的软件工程实践，对所列出的这些问题的回答可以得到。然而，确

6

定COTS或第三方构件的内部细节是相当困难的。

8.4.1.2构件的适配

在理想情况下，领域工程创建可以被容易地集成到应用体系结构中的构件库。“容易集成”的含义是（1）对库中的所有构件已经实现了一致的资源管理方法，（2）对所有构件存在诸如数据管理等公共活动，（3）已经以一致的方式实现了体系结构内部及与外部环境的接口。

在现实中，即使在构件已经针对在应用体系结构中的使用而进行过认证，它也可能在刚才提到的一个或多个区域中出现冲突。为了缓解这些冲突，经常使用一种称为构件包装（component wrapping）的适配技术。当软件小组对某构件的内部设计和代码有完全的访问权时（当使用COTS构件时，常常不是如此），可以进行白盒包装。和其软件测试中的对应物一样，白盒包装检查构件的内部处理细节，并通过代码级的修改以消除任何冲突。当构件库提供了使得能够消除或掩盖冲突的构件扩展语言或API时，可以使用灰盒包装。黑盒包装需要在构件接口中引入前处理、后处理以消除或掩盖冲突。软件小组必须确定是否适进行适配包装构件所需的工作量是值得的或是否应该代之以开发定制构件（专门设计以消除遇到的冲突）。

8.4.1.3构件组装

构件组装任务将经认证的、适配后的构件和开发的构件组装到为应用建立的体系结构中。为了达成此目标，必须建立一个基础设施以绑定构件到某运行系统中。该基础设施（通常是专门构件的库）提供了构件协同的模型和使构件能够相互协同并完成共同任务的特定服务。

在很多用于创建有效的基础设施的机制中，以下4个“体系结构成分（architectural ingredients）”可用于实现构件的组装：

1) 数据交换模型。对所有的可复用构件应该定义使用户和应用间能够交互和传递数据的机制（例如，拖和放、剪切和粘贴）。数据交换机制不仅应允许人到软件、软件到构件的数据传递，而且也应使得能够在系统资源间进行数据传递（例如，将一个文件拖到某打印机图符上以实现输出）。

2) 自动化。应实现一系列工具、宏和脚本以帮助可复用构件间的交互。

3) 超文本存储。包含在一个“复合文档”中的异质数据（例如，图形数据、声音、文本和数值数据）应该被作为单独的数据结构组织和访问，而不是作为一组分开的文件。“超文本维持了嵌套结构的一个描述性索引，应用可以自由地进行导航浏览以定位，创建或编辑个体数据内容，就像终端用户直接操作一样”。

4) 底层对象模型。对象模型保证在不同平台上用不同程序设计语言开发的构件可以互操作，也就是说，对象必须能够跨网络进行通信。为了达到整个目的，对象模型定义了构件互操作的标准。

因为复用和CBSE对软件产业的潜在影响非常巨大，一些主要的公司和产业联盟已经揭出了一些构件软件的建议标准：

1) OMG/CORBA。对象管理组织发布了公共对象请求代理体系结构（OMG/CORBA），一个对象请求代理（ORB）提供了一系列服务，它们使得可复用构件（对象）可以和其他构件通信，不管它们在系统中的位置如何。当构件用OMG/CORBA标准建立时，那些构件在某系统内的集成（没有修改）可以得到保证，如果对每个构件创建一个接口定义语言（IDL）接口。使用客户/服务器的比喻，在客户端应用中的对象向ORB服务器请求一个或多个服务，请求是通过IDL或在运行时动态地进行的。一个接口池包含了所有关于服务请求和响应格

7

式的信息。

2) 微软的COM。微软开发了一个构件对象模型（COM），它提供了在运行于Windows操作系统之上的单个应用中使用不同厂商生产的对象的规约。COM包含两个元素：COM接口（实现为COM对象）和在COM接口间注册和传递消息的一组机制。从应用的观点看，“重点不在于[COM对象]如何被实现，仅在于这样一个事实：对象具有在系统中注册的接口，且对象使用构件系统和其他COM对象通信”。

3) Sun的JavaBean构件。JavaBean构件系统时一个可移植的、平立的CBSE基础设施，使用Java程序设计语言开发。JavaBean系统扩展了Java Applet以适应基于构件的软件开发所需的更复杂的软件构件。JavaBean构件系统包含一组工具，称为Bean开发工具箱(Bean Development Kit, BDK)，它允许开发者做以下工作：（1）分析现存的Bean（构件）如何工作，（2）定制它们的行为和外观，（3）建立协同和通信机制，（4）开发用于特定应用的定制Bean，（5）测试和评估Bean的行为。

8.4.2 构件工程

在本章前面我们提到，CBSE过程鼓励使用现存的软件构件，但是，有时必须开发新构件，也就是说，新的构件必须被开发和现存在COTS及自有构件集成。因为这些新构件将变成自有可复用构件库的成员，它们应该按照复用的要求来开发。

关于创建可以被复用的软件并没有任何不可思议的地方。设计概念（如抽象、隐蔽、功能性、求精以及结构化程序设计，连同面向对象方法、测试、SQA以及正确性验证方法）所有对可复用软件的创建均有贡献。在此，主要考虑特定于复用的问题，它们是对可靠的软件工程实践的补充。

8.4.3基于复用的分析和设计

数据、功能和行为模型（用一系列不同符号表示）可以被创建以描述特定应用必须完成的任务，写好的规约然后被用于描述这些模型并生成完整的需求描述。

理想地，分析模型被分析以确定模型中的那些指向现存的可复用软件制品的元素。问题是以能够导致“规约匹配”的形式从需求模型中抽取信息。Bellinzoni、Gugini和Pernici描述了一种针对面向对象系统的方法：

构件被在不同的抽象层次定义和存储为规约、设计和实现类——每个类是来自以前应用的某产品的工程化描述。规约知识（开发知识）被以复用建议（reuse-suggestion）类的形式存储，它们包括各种用法指导，例如，对以构件的描述为基础检索可复用构件的指导，对在构件检索完成后组装和剪裁构件的指导。

自动工具被用于浏览构建库，通过试图匹配在当前规约中记录的需求和那些对现存可复用构件（类）描述的需求。领域特征和关键词可用于发现潜在的可复用构件。

如果规约匹配产生符合当前应用需要的构件，设计者可从可复用构建库中提取这些构件并将它们用于新系统的设计中。如果设计构件没能找到，软件工程师必须应用传统的或面向对象的设计方法去创建它们。正是在这点（当设计者开始创建新的构件时）为了复用的设计（design for reuse, DFR）应该被考虑。

我们已经提到过，DFR需要软件工程师应用已有的设计概念和原则，但是，应用领域的特征也必须被考虑。有时还需考虑如下问题：

1) 标准数据。应该研究应用领域，标识出标准的全局数据结构（例如，文件结构或完整的数据库），所有设计构件然后可以通过使用这些标准数据结构来刻画。

2) 标准接口协议。应该建立三个层次的接口协议：模块内接口的本质、外部技术（非人）接口的设计以及人机界面。

8

3) 程序模板。结构模型可以作为新程序的体系结构设计的模板。一旦标准数据、接口和程序模板已经建立，设计者就有了一个，可在其中创建设计的框架。新的符合这个框架的构件对以后的复用有更高的概率。

8.5分类和检索构件

考虑一个大的大学图书馆，数万本的书籍、期刊和其他信息资源是可用的。但是为了访问这些资源，必须有合适的分类模式。为了在这些大量的信息中导航浏览，图书馆管理者定义了一种分类模式，它包括分类码、关键词、作者名以及其他索引条目，所有这些使用户可以快速而方便地找到需要的资源。

现在考虑一个大型的构件库，成千上万的可复用构件存放在其中。但是，软件工程师如何找到他所需要的构件呢？为了回答这个问题，又出现了另一个问题：我们如何以无二义性的、可分类的术语来描述软件构件？

8.5.1描述可复用构件

可复用软件构件可以用很多方式来描述，但是理想的描述是围绕Tracz提出的3C模型——概念（concept）、内容（content）和语境（context）。 软件构件的概念是“对构件做什么的描述”。构件的接口被完整地描述，而且在前置条件和后置条件的语境中被表示的语义被标识。概念将传达构件的意图。

构件的内容描述概念如何被实现。在本质上，内容是对一般用户隐蔽的信息，只有那些企图修改该构件的人才需要了解它。

语境将可复用软件构件放置到其可应用的领域中。也就是说，通过刻画概念的、操作的和实现的特征，语境使得软件工程师能够发现适当的构件以满足应用需求。

为了在实际环境中可用，概念、内容和语境必须被翻译为具体的规约模式。常用的方法可以分为三大类：图书馆和信息科学方法、人工智能方法以及超文本系统。目前为止，绝大部分研究工作建议使用图书馆科学方法进行构件分类。 图8－2给出了源于图书馆科学索引方法的一个分类法，“受控的索引词汇（Controlled indexing vocabulary）”了可以用来分类对象（构件）的术语和语法，“不受控的索引词汇（Uncontrolled indexing vocabulary）”则对描述的性质大多数软件构件分类模式可归为以下三类:

9

索引词汇受控的不受控的分类关键词从文本种抽取的术语非从文中抽取的术语枚举刻面主题词描述子主题带语法不带语法

图8－2 源于图书馆索引方法的一个分类法

·枚举分类（enumerated classification）。

通过定义一个层次结构来描述构件，在该层次中定义了软件构件的类以及子类的不同层次。实际的构件被罗列在枚举层次的任何路径的最低层，例如，对窗口操作的枚举层次可能是：

window operations display open

menu-based

openwindow system-based syswindow close

via pointer … resize

via command

setWindowSize, stdResize, ShrinkWindow via drag

pullwindow, stretchwindow up/down shuffle … move

… close …

枚举分类模式的结构使得它易于理解和使用，然而，在建立层次之前，必须进行领域工

10

程，使得在层次中适当的项含有足够的信息。 ·刻面分类（faceted classification）。

通过领域分析，可以标识出一组基本的描述特征，这些特征称为刻面，刻面被根据其重要性区分优先次序并被联系到构件。一个刻面可以描述构件完成的功能、被操作的数据、构件应用的语境或任意其他特征。描述构件的刻面的集合称为刻面描述子。通常，刻面描述被在不超过7或8个刻面。

作为一个简单的使用刻面构件分类的例子，考虑使用下列构件描述子的模式: {function,object type,system type}

在刻面描述子中的每个刻面可取一个或多个值，这些值一般是描述性关键词，例如，如果功能（function）是某构件的刻面，可赋给该刻面的典型值可能为： function=(copy, from) or (copy, replace, all)

多个刻面值的使用使得原函数copy能够被更完全地精化。关键词（值）被赋给在复用库中每个构件的刻面集，当某软件工程师在设计中希望查询构件库以发现可能的构件时，一个值表被给出，然后到库中去寻求匹配。使用的自动工具可以结合词典功能，这样使得查找不仅仅考虑软件工程师给出的关键词，还考虑这些关键词的技术同义词。刻面分类模式给领域工程师在刻画构件的复杂描述子时带来了更大灵活性，因为新的刻面值可以很容易地加入，因此，刻面分类模式比玫举分类方法更易于扩展和适应。 ·属性值分类（attribute-value classification）。

为领域中的所有构件定义一组属性，然后为这些属性赋值，其方式和刻面分类方法非常相似。事实上，属性值分类方法和刻面分类方法是类似的，除了下面几点不同：（1）对使用的属性的数量没有，（2）属性没有优先级，（3）不使用词典功能。

8.5.2复用环境

软件构件复用必须有环境的支撑，一个复用环境应包含如下元素： 1) 能存储构件和查找构件必需的构件分类信息的构件库。 2) 提供对构件库访问的库管理系统。

·允许客户应用从构件库服务器中检索构件和服务的软件构件检索系统（如对象请求代理）。

·支持被复用的构件到新设计或新实现中集成的CBSE工具。

这些功能的每一个在复用库的范围内交互或者被包含在复用库中。

复用库是一个大型CASE中心存储库的一个元素，并且为一系列可复用软件制品（例如，规约、设计、代码、测试案例、用户指南）的存储提供设施。复用库包含了一个数据库以及必需的支持数据库查询和构件检索的工具，构件分类模式是构件库查询的基础。

查询经常用前面描述的3C模型中的语境来刻画，如果某初始查询产生大量的候选构件，则查询被求精以减少候选对象。然后，概念和内容信息被抽取出来（在候选构件集得到后）以辅助开发者选择合适的构件。

11

[习题]

1. 复用的关键障碍之一是使软件开发者考虑复用现存的构件，而不是重新发明一个新的构件（毕竟，构件东西是有趣的！）。请建议软件组织可以采用以便对软件工程师的复用活动提供激励的3到4种不同的方式。为了支持复用，什么技术应该被采用？ 2. 虽然软件构件是最明显的可复用“制品”，很多其他的作为软件工程的一部分而产生的试题也可被复用。考虑项目计划和成本估计。这些将被如何复用？这样做带来的收益是什么？

3. 研究一下领域工程并丰富图8－1中概述的过程模型。标识对领域分析和软件体系结构开发所需要的任务。

4. 为和大学学生数据处理相关的信息系统开发一组领域特征 5. 开发一组和字处理/桌面出版软件相关的领域特征。

6. 对你的导师指定的或你熟悉的某应用领域开发一个简单的结构模型。 7. 什么是结构点？

8. 获取一份最近的CORBA或COM或JavaBeans标准的副本，准备3到5页论文讨论其主要特点。获取关于对象请求代理工具的信息，并距离说明该工具如何符合标准。 9. 针对导师指定的或你熟悉的领域，设计一种枚举分类模式。 10. 针对导师指定的或你熟悉的领域，设计一种刻面分类模式。

11. 研究文献以获得最近的关于支持CBSE的使用的质量和生产率数据。

[参考文献]

1. 《软件工程—实践者的研究方法》 第5版 Roger S. Pressman著，梅宏译 2. 《大规模基于构件和软件开发》 Alan W. Brown著，赵文耘等译 3. 《现代软件工程》 科学出版社 周之英编著 4. 《软件工程》 高等教育出版社 齐治昌 等

12