系统架构18 - 软件工程（6）

净室软件工程

净室 (Cleaning Room) 软件工程是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。净室方法不是先制作一个产品，再去消除缺陷，而是要求在规约和设计中消除错误，然后以“净”的方式制作，可以降低软件开发中的风险，以合理的成本开发出高质量的软件。
净室软件工程 (Cleanroom Software Engineering，CSE) 是一种在软件开发过程中强调在软
件中建立正确性的需要的方法。
在净室软件工程背后的哲学是：通过在第1次正确地书写代码增量，并在测试前验证它们的正确性，来避免对成本很高的错误消除过程的依赖。它的过程模型是在代码增量积聚到系统的过程的同时，进行代码增量的统计质量验证。它甚至提倡开发者不需要进行单元测试，而是进行正确性验证和统计质量控制。

理论基础

净室软件工程的理论基础主要是函数理论和抽样理论。

函数理论

一个函数定义了从定义域到值域的映射。一个特定的程序好似定义了一个从定义域（所有可能的输入序列的集合）到值域（所有对应于输入的输出集合）的映射。这样，一个程序的规范就是一个函数的规范。
一个明确定义的函数应当具有以下特性：
● 完备性：对定义域中的每个元素，值域中至少有一个元素与之对应。对程序而言，每种可能的输入都必须定义，并有一个输出与之对应。
● 一致性：在值域中最多有一个元素与定义域中的同一元素对应。对程序而言，每个输入只能对应一个输出。
● 正确性：函数的正确性可以由上述性质判断。对程序而言，某项设计的正确性可以通过基于函数理论的推理来验证。

抽样理论

不可能对软件的所有可能应用都进行测试。
把软件的所有可能的使用情况看作总体，通过统计学手段对其进行抽样，并对样本进行测试，根据测试结果分析软件的性能和可靠性。

技术手段

净室软件工程中应用的技术手段主要有以下4种：

统计过程控制下的增量式开发 (Incremental Development )

增量开发基于产品开发中受控迭代的工程原理——控制迭代。
增量开发不是把整个开发过程作为一个整体，而是将其划分为一系列较小的累积增量。
小组成员在任何时刻只须把注意力集中于工作的一部分，而无须一次考虑所有的事情。

基于函数的规范与设计

盒子结构方法按照函数理论定义了3种抽象层次：行为视图、有限状态机视图和过程视图。
规范从一个外部行为视图（称为黑盒）开始，然后被转化为一个状态机视图（称为状态盒），最后由一个过程视图（明盒）来实现。盒子结构是基于对象的，并支持软件工程的关键原则：信息隐藏和实现分离。

正确性验证

正确性验证被认为是 CSE 的核心，正是由于采用了这一技术，净室项目的软件质量才有了极大的提高。

统计测试 (Statistically Based Testing) 和软件认证

净室测试方法采用统计学的基本原理，即当总体太大时必须采取抽样的方法。
首先确定一个使用模型 （Usage Model） 来代表系统所有可能使用的（一般是无限的）总体。然后由使用模型产生测试用例。因为测试用例是总体的一个随机样本，所以可得到系统预期操作性能的有效统计推导。
净室软件工程是软件开发的一种形式化方法，它可以生成质量非常高的软件。它使用盒子结构规约进行分析和设计建模，并且强调将正确性验证（而不是测试）作为发现和消除错误的主要机制。

缺点

• CSE 太理论化，需要更多的数学知识。其正确性验证的步骤比较困难且比较耗时。
• CSE 开发小组不进行传统的模块测试，这是不现实的。
• CSE 脱胎于传统软件工程，不可避免地带有传统软件工程的一些弊端。

基于构件的软件工程

基于构件的软件工程 (Component-Based Software Engineering，CBSE) 是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。基于构件的软件系统中的构件可以是COTS（Commercial-Off-The-Shelf）构件，也可以是通过其他途径获得的构件（如自行开发）。 CBSE 体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于已有构件的组装，以更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担，从而降低软件开发的费用。

构件特性

在软件复用领域，一般观点认为构件是一个独立的软件单元，可以与其他构件构成一个软件系统。也有其他专家提出了其他的构件定义，然而不管构件如何定义，用于CBSE 的构件应该具备以下特征

• 可组装型：对于可组装的构件，所有外部交互必须通过公开定义的接口进行。同时它还必须对自身信息的外部访问。
• 可部署性：软件必须是自包含的，必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是二进制形式，无须在部署前编译。
• 文档化；构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。
• 独立性：构件应该是独立的，应该可以在无其他特殊构件的情况下进行组装和部署，如确实需要其他构件提供服务，则应显示声明。
• 标准化：构件标准化意味着在 CBSE过程中使用的构件必须符合某种标准化的构件模型。构件模型定义了构件实现、文档化以及开发的标准。
  其中包含的模型要素有：
  （1）接口。构件通过构件接口来定义，构件模型规定应如何定义构件接口以及在接口定义中应该包含的要素，如操作名、参数以及异常等。
  （2）使用信息。为使构件远程分布和访问，必须给构件一个特定的、全局唯一的名字或句柄。构件元数据是构件本身相关的数据，比如构件的接口和属性信息。
  （3）部署。构件模型包括一个规格说明，指出应该如何打包构件使其部署成为一个独立的可执行实体。部署信息中包含有关包中内容的信息和它的二进制构成的信息。
  构件模型提供了一组被构件使用的通用服务，这种服务包括以下两种：
  （1）平台服务，允许构件在分布式环境下通信和互操作。
  （2）支持服务，这是很多构件需要的共性服务。例如，构件都需要的身份认证服务。

CBSE过程

CBSE过程是支持基于构件组装的软件开发过程，需要考虑构件复用的可能性，以及在开发和使用可复用的构件中所涉及的不同过程活动。CBSE过程中的主要活动包括：（1）系统需求概览；（2）识别候选构件；（3）根据发现的构件修改需求；（4）体系结构设计；（5）构件定制与适配；（6）组装构件，创建系统。
CBSE 过程与传统的软件开发过程存在几点不同：

1. CBSE 早期需要完整的需求，以便尽可能多地识别出可复用的构件。而增量式开发中，早期并不需要完整的需求。
2. 在过程早期阶段根据可利用的构件来细化和修改需求。如果可利用的构件不能满足用户需求，就应该考虑由复用构件支持的相关需求。通过劝说用户修改需求，以便能节省开支且快速开发系统。
3. 在系统体系结构设计完成后，会有一个进一步的对构件搜索及设计精化的活动。可能需要为某些构件寻找备用构件，或者修改构件以适合功能和架构的要求。
4. 开发就是将已经找到的构件集成在一起的组装过程。其中包括将构件与构件模型基础设施集成在一起，有时还需要开发适配器来协调不匹配的构件接口，可能还需要开发额外的功能。

构件组装

构件组装是指构件相互直接集成或是用专门编写的“胶水代码”将它们整合在一起来创造
一个系统或另一个构件的过程。

组装方式

• 顺序组装。通过按顺序调用已经存在的构件，可以用两个已经存在的构件来创造一个新的构件。顺序组装的类型可能适用于作为程序元素的构件或是作为服务的构件。需要特定的胶水代码，来保证两个构件的组装：上一个构件的输出，与下一个构件的输入相兼容。
• 层次组装。这种情况发生在一个构件直接调用由另一个构件所提供的服务时。被调用的构件为调用的构件提供所需的服务。因此，被调用构件的“提供”接口必须和调用构件的“请求”接口兼容。如果接口相匹配，则调用构件可以直接调用被调用构件，否则就需要编写专门的胶水代码来实现转换。
  -** 叠加组装**。这种情况发生在两个或两个以上构件放在一起来创建一个新构件的时候。这个新构件合并了原构件的功能，从而对外提供了新的接口。外部应用可以通过新接口来调用原有构件的接口，而原有构件不互相依赖，也不互相调用。这种组装类型适合于构件是程序单元或者构件是服务的情况。

不兼容情况

当创建一个系统时，可能会用到所有的构件组装方式，对所有情况都必须编写胶水代码来连接构件。而当编写构件尤其是为了组装来写构件时，经常可能会面临接口不兼容的问题，即所要组装的构件的接口不一致。一般有下述3种不兼容情况。
（1）参数不兼容。接口每一侧的操作有相同的名字，但参数类型或参数个数不相同。
（2）操作不兼容。提供接口和请求接口的操作名不同。
（3）操作不完备。一个构件的提供接口是另一个构件请求接口的一个子集，或者相反。
上述不兼容情况，必须通过编写适配器构件来解决。
适配器构件使两个
可复用构件的接口相一致；适配器构件将一个接口转换为另外一个接口。
当用户选择组装方式时，必须考虑系统所需要的功能性需求、非功能性需求，以及当系统发生改变时，一个构件能被另一个构件替代的难易程度。