会员登录
会员注册
如果我们想要描述 80% 的系统行为，并且将 Pareto 规则应用到类、操作和场景数量方面，那么对于每一者都需要描述其行为的 93%(0.933= 0.8)--也就是对于每一个都需要 50%，例如，4 个类和 5 个操作(= (12 - 2 构建器/析构器)/2)。节点树的不同分叉的数量可能达到数千个(其中节点树用来代表4个类及每个类5个操作的执行模式)。我为每个节点创建了 1 到 3 个链接，假设在顶层有 10 个操作(接口操作)的层次结构，并且形成了一个三层的树。这将会有 1000 条路径或者场景。所以，500 个场景将会得到 93% 的覆盖。使用 300 个场景(用相同的假定)我们可以得到 73% 的覆盖。根据一个选定的算法，可以对这个树进行修剪，从而删除冗余的行为说明，甚至更少的数量就完全可以符合要求。
达到该目的的另一个方法就是研究一下对于 7000 slocs 的 C 代码需要多少测试用例(从场景派生而来)。这些测试用例不受单元测试层次的制约，并且在 Jones 91 和 Boeing 777 项目中有许多证据表明这个数字是安全的，至少它符合实践。这些来源表明在 250 到 280 之间是合适的。在一个完全不同的层次上，加拿大自动空中交通系统(Canadian Automated Air Traffic System ，CAATS)项目使用了 200 项系统测试(我私下里获悉的)。
用例的规模
用例应该具有多大规模呢?是否应该足够大以及表达足够的细节才能表达所需要的行为--这取决于与系统有关的用例复杂性、内部用例和外部用例。--这里我们就应该描述多少系统的内部动作来深入探讨一下这个问题。很明显，从外部行为描述来构建系统，要求将输出与输入关联起来。例如，如果行为对历史记录敏感并且很复杂，那么在没有系统内部的一些概念模型及行为的动作时，就很难描述它。注意，没有必要描述一个系统是如何从内部构建的--任何满足非功能性需求和匹配模型行为的设计就能够满足要求。
UML 1.3 中提供的定义是："用例【类】：一个系统可以执行的动作(包括变体)序列的说明，其中这些动作与系统参与者进行交互"。对复杂的行为的内部动作，可能合理的采用这个定义也可以在实现阶段再进行定义――这对于最终用户来说是个更远的步骤。业务规则也应该纳入到用例中以便约束参与者的行为(例如，在一个ATM系统中，银行需要有一条规则：在一次交易中，提取的金额不能超过 500 美元，无论账号中的余额为多少)。
根据这种解释，事件的用例流描述的页数可以为 2-20 。从计算的角度上看，具有简单行为的系统显然不需要冗长的描述。或许我们可以认为简单的商务系统通常用 2 到 10 页来描述，平均为 5 页。对于更复杂的系统来说，业务系统和科学系统在 6 到 15 页之间，平均为 9 页。复杂的命令和控制系统在 8 到 20 页之间，平均为 12 页(这些比率反映了相同规模系统的工作量与类型之间的非线性关系)，尽管我没有数据来支持这种观点。更富有表达力和描述性的形式(例如状态机或者活动图)可能需要更少的篇幅--我们仍旧倾向于加强文本，所以此处不讨论其他形式，毕竟相关资料很少或者根本没有。
与上述规模有系统差异的开发应该运用乘法规则来计算在这些假设基础上得出的每个用例的小时数(我建议增加一个 COCOMO -样式的成本驱动，该驱动是系统类型的(简单的业务类型、更复杂的类型、命令及控制类型等等)的观察到的平均规模或建议的平均规模。
用例规模的另一个方面是场景的数量。例如，一个 5 页长的用例可能是一个具有很多路径的复杂结构。再一次重申，需要将场景的数量以及这个比例估计为 30(这是我对于每个用例的场景数的初步估计)，将其作为成本的驱动因素。
得到的结果是，我们假设基于大约长度为 100 页说明的用例，对于任何给定层次的外部说明及补充说明来说，都是足够的。范围是 20 到 200 页之间(这些界限是模糊的)。注意，一个系统(子系统组)在最低的层次上的总数是 3-15 页/ ksloc(简单的业务系统)到 12-30 页/ ksloc(复杂的命令和控制系统)。这或许能够解释 Royce 98 表中的 14-9 和实际项目之间明显的矛盾之处，前者的工件所占用的篇幅非常少，而实际项目却占用了大量的页。本文的观点认为规格说明的层次不应受页数的限制。--Royce 是正确的，对于大型的、复杂的系统而言，重要内容的说明(如版本声明)可以达到范围的上限――200 页