第四章 用例集
用例集模式是编写一组良好用例的质量标志。
4.1 SharedClearVision（愿景共识）
缺乏一个清晰的系统愿景可能会导致优柔寡断，涉众之间不能达成一致意见，并可能很快就使项目瘫痪。
原因：
时间压力可能会使人过早的开发系统，他们的工作建立在错误的基础之上，使其步入正轨的代价可能会非常昂贵；
构建人员有一种扩展系统范围的自然倾向；
涉众之间有一些相互冲突的愿景；
项目目标不清晰；
开发人员之间缺乏交流；
所以：
准备一份清晰描述系统目标的陈述，确保其支持组织的使命，并将其直接分发给参与项目的每个人。
愿景陈述应该包括：
? 系统目标；
? 系统将解决的问题；
? 系统不会解决的问题；
? 涉众是谁；
? 系统将如何使涉众受益；
4.2 VisibleBoundary（可见的边界）
如果不知道系统的边界，系统的范围就会以一种不可控制的方式增长。
原因：
对于系统边界，不同的人有有不同的观点；
定义糟糕的边界会导致范围的蠕变，开发人员喜欢添加某些不会给系统带来好处的特性；
有些人认为定义边界时不必要的；
所以：
通过列举与系统交互的人员与设备，在系统与其环境之间建立一个可见的边界；
开发的早期阶段，由于系统的愿景并不清晰，系统边界可能是模糊的，先确定一个系统边界，变成文档，然后随着开发的深入，对其进行SpiralDevelopment。
上下文图：
|
系统 |
|
终结器 |
|
终结器 |
|
终结器 |
|
终结器 |
4.3 ClearCastOfCharacters（清晰识别角色）
如果仅分析系统的用户，而忽视他们在系统中所扮演的角色，就可能会遗漏重要的系统的行为或引入冗余的行为。
原因：
系统必须满足其用户的需要并保护其涉众的利益，这样的系统才是有用的；
把服务和某些用户绑在一起可能会使系统变得非常死板；
主体专家的狭窄焦点或视野可能会使我们漏掉用户要求的服务；
将焦点放在用户身上可能会使我们纠缠于实现细节，而不是提供对用户所需要的服务的理解；
时间压力和权宜之计鼓励我们仅对用户进行分析；
所以：
识别系统必须与之交互的参与者，以及每个参与者和系统交互时所扮演的角色，并清晰描述每个参与者。
4.4 UserValuedTransactions
如果系统不能为其用户提供有价值的服务，不支持系统愿景所规定的目的和目标，那么系统就是不完善的。
原因：
一个编写良好的用例应该清晰准确的描述系统提供的基本功能，该信息能够使客户在构建系统前察看它，以确定系统是否提供了他们认为有价值的服务；
识别低层的事务相对来说是容易的，但识别有价值的服务就难了；
在一个足够高的级别编写用例，可以保证用例相对稳定；
在太高的级别上编写用例，对系统开发人员毫无用处；
在太低的级别上编写用例；难以从高的层次上理解系统；
所以：
识别系统为参与者提供以满足其业务目的的有价值的服务；
避免基于表单的用例集；
4.5 EverUnfoldingStory
描述系统的行为所需的步骤已经超出了所有读者的记忆和兴趣范围。
原因：
不同的涉众从不同的角度看待系统；
每个用例都有可能有许多读者和很多使用方式，它们需要不同的详细级别；
在多个层次编写用例会让人感到混乱；
编写人员需要遵循一个原则来对需求进行组织；
所以：
将一组用例组织为分层故事的形式，可以将其展开获得更多的细节，也可以将其折叠起来隐藏细节，显示更多的上下文；
三个级别用例：
l 概要级：需要用多个用户目标会话来完成；
l 用户目标级：满足了主参与者当前的特定价值目标，一般由一个主参与者在一个位置执行；
l 子功能级：满足了用户目标级用例或另一个子功能的部分目标；