有效用例模式阅读笔记三

第五章用例

5.1 CompelteSingleGole

不适当的目标，会使编写人员不能确定什么时候一个用例结束，什么时候另一个用例开始。

原因：

太大的用例可能会因细节过多占去涉众的大部分精力；

大的用例限制重用；

过小的用例仅能描述某些价值实现的一部分；

所以：

编写每个用例，用来描述一个完整而且定义良好的目标。

初速目标的特性为：

? 它与一个定义良好的参与者相关；

? 它对参与者或参与者代表的涉众是有价值的；

? 它与在这一级别上为系统确定的其他目标一致；

? 避免与具体的借口细节联系到一起，而编写出完成目标片断的用例；

5.2 VerbPhraseName

没有意义的普通名称不会使读者有什么期望，也不会提供一个方便的参考点。

原因：

名称为读者确定了基调和关联，并能够为编写人员提供一个焦点；

适当的用例名称能够使读者看到大的概貌，并且对整个用例集有效；

所以：

用一个代表主参与者目标的主动动词短语来命名用例。

5.3 ScenarioPlusFragments（主场景+分支片断）

读者必须能够非常轻松的阅读具体的场景或他们感兴趣的故事；否则，他们可能会变的沮丧，或遗漏重要的信息。

原因:

一个有趣的用例需要捕获主成功场景的分支；

将每个分支编写为一个完整的故事将会模糊故事变体之间的差别；

将每个变体分离出来也会使编写人员的工作变得非常困难；

需要清晰的确定主成功场景；

所以：

将成功的故事情节编写为简单场景，不考虑任何可能的失败。在该场景下面，放上展示会发生什么情况的故事片断。

5.4 ExhaustiveAlternatives

用例可以有很多分支，遗漏一些分支意味着开发人员会误解系统的行为，这样的系统是不完善的。

原因：

开发人员需要知道如何处理错误；

进度压力限制了开发人员可以识别各种变化的时间；

拥有关于变化的信息有助于开发人员构建一个健壮的设计；

所以：

必须捕获在用例中处理的所有分支和失败情况。

5.5 Adornments

在用例中包含非功能需求很难快就会将用例搞乱并模糊用例。

原因：

用例的目的是清晰的表达系统的功能需求；

不应该遗漏有助于理解用例或对开发人员来说有价值的信息；

所以：

在用例模板的场景文本之外创建额外的区域，来容纳对关联用例有用的补充信息；

用例和其他补充需求紧紧相扣，例如：性能需求、用户界面说明、约束条件、业务规则、数据字典等。

5.6 PreciseAndReadable

对非技术性读者来说太复杂，或对开发人员来说太不精确的用例是不完善的，很可能或导致构建不良且不适当的系统。

原因：

对涉众和开发人员来说，用例应该是可读的；

开发人员有一种添加细节和解决方案的倾向；

非技术性涉众可能会遗漏一些必要的考虑；

为客户和开发人员提供不同的需求文档集合是很糟糕的；

所以：

用例需要足够可读，以便使涉众可以阅读和作出评估；

用例需要足够精确，以便开发人员可以理解他们正在构建的系统。

转载于:https://www.cnblogs.com/LJT666/p/5045828.html