《软件工程-理论、方法与实践》课件第16章

第16章净室软件工程16.1净室方法基础16.2净室技术16.3盒子行为和结构本章小结习题16.1净室方法基础

16.1.1函数理论

净室开发方法基于数学中的函数理论。一个函数定义了一个从定义域到值域的映射，定义域中的每个元素都可在值域中找到唯一的元素与之对应。一个特定的程序好似定义了一个从定义域(程序所有可能输入序列的集合)到值域(所有对应于输入的输出集合)的映射。这样一个程序的定义就是一个函数的定义，描述了一个程序的定义域(输入序列)到值域(输出空间)的映射。一个定义明确(well-defined)的函数有如下特性：完备性、一致性和正确性。因为一个程序定义描述了一个函数，所以它必须是完备的、一致的和正确的。

数学完备性要求对定义域中的每个元素，值域中至少有一个元素与之对应。也就是说，每种可能的输入都必须定义，并有一个输出与之对应。

数学一致性要求在值域中最多有一个元素与定义域中的某一元素对应，也就是说，每个输入只能对应一个输出。相对于需求定义的正确性由定义域专家判断，对于一个给定的定义，某项设计及其定义的正确性是可以通过基于函数理论的推理来验证的。

1986年Linger、Mills和Hevner提出了用于净室软件开发的盒子结构的方法，该方法取代了Linger、Mills和Witt于1979年提出的将数学函数理论应用于软件开发的方法。并明确地提出有三种功能形式的盒子：黑盒、状态盒和明盒。16.1.2统计理论

净室测试方法基于统计学。在过去的几十年中，统计学在工程中获得了广泛的应用。

当从经济上或技术上无法测试全体样本时，便可以使用统计抽样的方法。如果统计结果没有达到质量目标，生产过程需做必要调整。这种以统计学为坚实基础的从产品度量到生产过程之间的反馈循环，得到了广泛的认可和应用。在软件中，用于采样的总体(population)是所有可能使用情况的集合，其中集合中的每个元素代表系统的一种可能运行情况。统计的目的是度量系统正确运行一个样本的能力。因为总体是无限的，完全的测试是不可能的，所以必须利用统计学方法来对系统性能做一个有效的推理。测试过程无论如何扩展，在所有可能的输入序列中都只能算一个很小的集合，所有的测试活动只能是无限总体中的抽样。16.1.3净室开发小组活动

净室开发小组通常由3～8人组成，小组中有一名组长，根据整个组的责任和进度优先级，负责小组内部的工作分配和协调。净室开发小组要完成三项主要工作：制定系统规范、开发和认证。

小规模的项目可以只由一个小组来承担开发任务。小组在开发的不同阶段分别完成系统的规范制定、开发和认证工作。对于中等规模的项目，可能需要多个小组的协作，一个核心小组负责规范和定义系统的结构，开发并认证一两个增量，并为子系统制定规范，然后由这个核心小组的成员担任开发和认证各个子系统的小组组长。为了适应用户需求的变化或系统层次策略的改变，核心小组在一段时间后可能重组。对于大规模的项目，多组协作是必要的，小组职责的划分可能要更清晰，包括规范组、开发组和认证组。因此，开发伊始，应该组成三个初始组，一个组制定系统规范，一个组开发初始增量，还有一个组认证这些增量。此后，三个初始组的成员在子系统层次上领导特定的小组，所有小组成员都要接受净室技术培训。评审是净室小组的一项重要工作。每个产品从最初的概念到最后形成都要经历多次评审。评审有两种类型，一种称为开发评审，一种是验证评审。

开发评审的焦点集中于技术策略、好的想法以及小组培训和交流。一般来说，软件开发过程中，最初的开发思路未必是合理、全面的。因此，评审的一个关键目标是在软件的规范、设计和验证方面找到更好的方案。一个小组成员可以召集相关人员来评审和讨论一个只有一两页程序的设计方案，讨论的焦点是关于控制和最初数据结构的策略、算法的折中方案等等，这有利于产生好的思路和方案。一个产品可能要经历多次开发评审。成功的评审，可通过积累的知识进行交流来提高效率，也会使小组成员对产品更熟悉，并利于产生良好的软件开发活动，最后的产品是小组所有成员智慧的结晶。验证评审通过形式化方法来验证产品的正确性和完备性，验证评审首先由设计者逐一列举出满足函数的正确性条件，小组按顺序检查每个条件，不允许有存在异议的情况。任何修改必须经过后续评审的重新验证。一个产品经过验证评审后不再有更改的必要时就被认为是正确和完整的。在净室活动中，整个组对产品拥有主权，其中任何后续错误都应该由该组承担责任。由于在开发评审中，每个参与者都已熟悉了被验证产品的结构和内容，因此在验证评审中效率能够得到保证。另外，净室过程常采用可重用的规范和设计模型，因此，验证工作多数也是可重用的。

16.2净室技术

16.2.1基于统计过程控制下的增量开发

统计过程控制(SPC)是一种借助于数理统计方法的生产过程质量控制的重要工具，它应用统计方法对过程中各个阶段进行监控与诊断，从而达到改进与保证产品质量的目的。SPC强调全过程管理，强调从整个系统看待问题；强调用科学的统计技术保证全过程预防原则的实现。SPC广泛适用于生产过程、服务过程和管理过程。增量开发基于产品开发中受控迭代的工程原理——控制迭代。增量开发不是把整个开发过程作为一个整体，而是将其划分为一系列较小的、累积的增量。增量开发是开发小组保持对项目控制的基础。因为小组成员在任何时刻只需把注意力集中于工作的一部分，而不是一次考虑所有的事情。

增量开发把一个净室项目分成一个有序的开发周期序列。在每个周期完成一些用户功能。在每个增量开发完成时，产品的功能便可向客户演示。这样客户对产品有真实的感观认识，可不受约束重新确认需求或使需求更加清晰。这将使产品在完成时双方的不满意程度降到最低。增量开发计划由系统结构驱动，系统结构定义了高层的结构和接口。在给定一个系统结构的情况下，增量的规划(参见第2章)有许多因素要考虑。如要考虑功能依赖的问题，核心功能应该优先开发。例如，在嵌入式系统中，硬件开发的进度协调是一个要考虑的要素；在图形用户界面(GUI)系统中，第一个增量通常是制定用户接口原型，这是需求中最易改变的部分。另外，影响增量开发的其他因素还包括：开发的风险、复杂性、重用性以及使用频率等。如果可能，在较早的增量中要包含最具不确定性的部分，这样可尽早理解影响进度的因素。

智能控制、客户反馈、风险管理以及增量开发等优点可使项目组有效地统计过程控制。在每一增量开发结束时，要度量产品的质量并和小组的质量目标进行比较。比较的结果可以确定开发是否在控制之下，出现较小的偏差时要对项目进行追踪，而出现不可接受的偏差时要进行仔细的性能评审。如果确定了问题，则小组要进行过程调整以便在下一个增量中改进性能。16.2.2基于函数的定义(Specification)、设计和验证

净室采用的方法不仅具有坚实的理论基础，而且具有良好的可操作性。系统的定义和实现被规范为函数盒的转换过程。系统首先定义描述外部视图的黑盒，之后，黑盒被转化成一个状态机视图，称之为状态盒，最后由过程，即明盒来实现。这些形式上不同、行为上等价的视图统称为盒子结构。盒子结构是基于对象的，并支持软件工程的信息隐蔽以及接口和实现分离的关键原则。图16.1黑盒的概念视图黑盒规范定义了一个系统或其组件从输入到输出的映射的外部行为。因只需定义外部行为，而不必描述内部状态或实现细节，故称之为黑盒。黑盒只定义一个系统或其组件的用户视图。这里的用户可能是一个人、硬件单元或其他程序。图16.1从概念上描述了一个黑盒，其中SH代表激励历史(StimulusHistory)，R代表相应的响应(Response)。一个激励序列是对系统的一系列单一输入。一个激励可能由用户(如一次按键或鼠标单击)产生，也可能由硬件(如一个时钟脉冲或来自传感器的信号)产生，或者是由另一个软件组件(如操作系统或数据库)产生。一系列这样的激励组成了一个独一无二的激励序列，激励必须对应一个响应。黑盒由所有可能的激励列表、响应列表以及激励到响应的映射规则(函数)组成。黑盒是一种与状态无关，与过程无关的函数描述，其映射必须是完备的、一致的和可跟踪的正确性。状态盒规范由黑盒导出，是通向实现的第一步。状态盒把为获得黑盒指定的外部行为而需保存的激励元素定义为状态数据。状态盒把系统或其组件所需行为定义为一个从当前激励和旧状态到对应响应和新状态的映射(变换)。定义状态数据后，就不必考虑激励的历史了。图16.2描述了状态盒的概念视图。

状态盒只描述了系统或其组件的响应和状态更新，它不包括过程实现的细节。和黑盒一样，状态盒必须满足完备性、一致性和可跟踪的正确性。明盒规范用过程实现了对应的状态盒。这些过程实现了状态盒的映射规则，也有可能引进代表宏操作的新黑盒。过程必须足以完成必要的状态更新和所需的响应。图16.3描述了明盒的概念视图，为一顺序控制结构。分支、循环和并发控制结构也可在明盒中出现。引入的黑盒将在随后的求精过程中细化为状态盒和明盒。图16.2状态盒的概念视图图16.3明盒的概念视图(BB=黑盒)与黑盒和状态盒一样，明盒也必须满足完备性、一致性和可跟踪的正确性。明盒可由系统的设计语言或目标语言来加以定义。

在盒子结构规范设计中，黑盒定义系统的行为；状态盒是黑盒的细化，定义了所需的状态数据；明盒是状态盒的细化，定义了所需的过程/处理。每一种盒结构在小组评审时都要经正确性验证。小组采用基于函数理论的推理，根据前一步来验证每一细化步骤的正确性。换言之，开发小组确认在每一步中定义的激励—响应映射规则都在后续步骤中被保持。明盒过程可能包含无限多的实现路径，在净室技术中，这些路径不是通过基于路径的审查或软件测试进行全部的检查，而是通过函数理论的正确性定理进行程序正确性验证。正确性定理是基于验证单个控制结构而不是跟踪整个路径，由于明盒过程包括有限的控制结构，因此正确性定理将验证定义为有限情形的检查，并从逻辑上全部验证所有可能的情况。16.2.3统计测试和软件认证

使用模型是指系统使用中所有可能的情形及其发生的概率。使用模型可以是多种形式的，如马尔可夫模型和形式化语法。在马尔可夫模型中，使用模型由一个状态集组成，状态之间由转移弧线连接，转移弧线表示系统测试时可能的激励条件，并有一个概率值与之对应，该概率值表示从给定状态发生特定转移的可能性大小。从起始状态穿过模型到终点状态便得到了一个测试用例。图16.4描述了一个使用模型。其中弧线代表激励条件，节点代表使用状态，每条弧线标有激励和发生的概率。图16.4一个简单的使用模型使用模型是可重用的项目资源，测试用例可由其产生。实际上，测试一个系统可采用多种使用模型，对每种使用模型可采用多种概率分布。在某些情况下，系统可能提供一些很少使用的功能，但这些功能如果出现处理失误则会带来严重的后果，如关闭核反应堆。这种功能执行概率很小，但当集中测试这种可能产生重大后果的功能时，需要采用严格的安全使用模型、风险使用模型、恶意使用模型或其他特定环境使用模型。统计测试可以方便地结合其他测试一起进行。

16.3盒子行为和结构

盒子结构是在需求定义和设计中对系统的外在基本属性和内在实现行为的描述。图16.5描绘了三种盒子(黑盒、状态盒、明盒)从定义到实现的精化过程，以及相反的验证过程。黑盒确定了一个系统或系统组件的外部行为；状态盒则指定了完成外部行为所需的状态数据。明盒则进一步把状态盒具体化，它确定了完成状态盒行为的过程设计。明盒由程序控制结构组成。每一步的细化是根据前一步进行验证的。盒子结构将系统开发的三个方面(行为、数据和过程/处理的定义)分离开，但又把它们连成一个细化和验证的内聚过程。图16.5盒结构的精化和验证(BB=黑盒)16.3.1黑盒行为

黑盒定义了一个系统或系统组件的外部行为，提供了从外部行为来看待系统或组件的视图。例如，工作站接受键盘和鼠标的激励会改变当前窗口内容或显示新的窗口以作出响应，而用户对工作站的内部操可以一无所知，感受到的仅仅是它的外部行为。当系统接受激励S，将产生响应R。响应往往不仅与当前激励有关，还与到目前为止收到的历史激励有关。例如，假设定义一个计算器的黑盒，如果正在进行一次计算，当前的激励是按了键5；如果此前的历史激励是C718，其中C表示清零，那么响应将是显示7185。也就是说，计算器将当前显示的数字左移一位，并在单元位置插入5；如果此前的历史激励是C718+，则响应是在屏幕位置显示一新的字符5。因此，系统的当前激励及此前的历史激励的共同作用才确定了它的响应。黑盒行为的数学语义可以写成如下函数：

历史激励 → 响应

简记为

SH → R

SH表示包括当前激励的所有历史激励。黑盒行为不包含状态数据及过程实现。它仅定义了取决于历史使用的能被用户感受到的外部可见行为。因此，黑盒关心的是从用户角度看待系统行为的问题，而并不是考虑状态和过程的设计。黑盒规范定义了所有可能使用情况所需的行为。也就是说，在黑盒规范中，为所有可能的当前激励和历史激励以及它们的组合定义了正确的响应，在净室项目中黑盒定义的下列三个原则对高效系统开发很关键。

(1)对系统拥有者和用户而言，黑盒定义了他们分析和协商的所需行为，这是他们准备资源、着手开发和测试的前提。

(2)对系统开发者而言，黑盒定义了待设计和实现的所需行为。

(3)对系统测试者而言，黑盒定义了在测试过程中待确认的所需行为。黑盒可以用表格形式来定义，表16.1的三列分别对应于激励历史条件、当前激励和响应。这个黑盒定义了一个基于12个月平均销售额的预测系统，用于为一个产品清单控制系统中数以千计的产品预测销售额。其中，产品的月销售额构成当前的激励，并根据历史激励条件产生响应。黑盒规则1指定了某一产品少于12个月销售额时的正确响应，规则2指定了至少有12个月销售额时的正确行为。这张表以一种非形式的方式描述了系统行为，其中尖括号中的内容有待于进一步定义和细化。比如，规则1可进一步细化为6～12个月的平均销售额。16.3.2状态盒行为

状态盒对系统或组件进行初步细化，定义了状态空间。状态盒把激励历史条件封装成状态数据，但仍没有涉及具体过程。它把旧的状态OS(OldState)和激励S映射到新的状态NS(NewState)和响应R；而新的状态在下—次变换时则变成了旧状态。状态盒子行为的语义是一个如下的变换函数：

(旧状态，激励) → (新状态，响应)

或简写为

(OS，S) → (NS，R)

状态盒根据黑盒来细化和验证。状态信息就是为了符合黑盒子定义而必须保存的激励历史，这样信息来自于黑盒，无需再定义。因为每个历史激励可用状态来表示，所以每个黑盒对应一个状态盒。状态可以有多种不同的表示和访问方法。状态盒可用表格来定义，对应的列包括旧状态、激励、新状态、响应以及相应的黑盒规则等。表16.1定义了销售额预测系统的黑盒，表16.2将其转换为状态盒。通过对黑盒的激励历史条件进行分析，产生〈销售文件〉状态项，用来保存每种产品最近11个月的销售额；销售文件的每条记录〈产品〉来标识，并包含一个能存11个月销售额的数组。由于当前激励加上前11个月的销售额便可求出所需的平均值，所以只需存11个值就够了，不必保留更早的，而接下来的激励将导致删除早于11个月的销售额。表16.2中的规则1定义了当激励引入一个新产品时所需的行为；规则2定义了当状态盒已知的产品还没达到11个月的销售额时所需的行为，变换1和2只是将激励显示给用户；规则3定义了计算平均值的稳定状态。注意，每条规则都要进行相应的状态更新，为处理随后的激励做好准备。例如，规则3将引起这样的状态更新：删除最早的〈销售额值〉，把当前激励作为最新的〈销售额值〉加入到〈销售文件〉的该〈产品〉记录中。16.3.3明盒行为

系统或组件的明盒实际上定义了状态盒行为的过程，即定义了黑盒/状态盒行为的具体实现过程，也是对状态盒进一步细化的过程。明盒可以是精确的处理过程定义，也可以是计算机程序或程序集，基于程序的内部状态OS，接受激励S，产生新的内部状态NS并产生响应R。这些过程由基于结构化程序设计的控制结构来定义，即顺序、选择、循环结构，如果引入并发机制则还要加上并行结构。明盒用这些控制结构来完成新状态和响应的计算。对于所给状态盒可以定义多种不同的明盒。明盒可用一个变换函数表示：

(旧状态，激励) → (新状态，响应)，借助过程定义

或简记为

(OS，S) → (NS，R)，借助过程定义

明盒的过程可以重用已有的黑盒，也可在后续求精过程的状态盒与明盒中引入新的黑盒。

明盒的验证是把其操作抽象成一个导出的状态盒并与原来的状态盒进行比较。16.3.4盒子结构层次

正如前面所述，盒子结构层次随着逐步求精和验证而不断进化。这是一种使用的分层结构而不是一个部件的分层结构。也就是说，一个盒子的每次使用都在分层结构中占有不同的位置，并且通过盒子的顺序和并发使用定义了所有处理过程。

图16.6的例子描绘了一个初始黑盒被细化为一个状态盒，再细化为一个明盒的过程。明盒的控制结构在下一个层次包含六个黑盒。这些黑盒可以是相同的，也可以是不相同的，或者是几个黑盒的组合。使用系统组件的分层结构有助于对系统开发管理保持智能控制。图16.6盒结构的使用层次(BB=黑盒；SB=状态盒；CB=明盒)16.3.5盒子结构的开发过程

基于前面的描述，下面归纳了盒子结构的开发过程：

(1)定义系统需求。

(2)确定和确认黑盒。

●定义系统边界和确定所有的激励和响应。

●

确定黑盒映射规则。

●与系统拥有者和用户一起确认黑盒。

(3)确定和验证状态盒。

●确定状态数据和初始状态值。

●确定状态盒变换功能。

●从状态盒导出黑盒的行为，把