有效用例模式（四）

 

第四章 用例集

用例集模式是编写一组良好用例的质量标志。

4.1 SharedClearVision（愿景共识）

缺乏一个清晰的系统愿景可能会导致优柔寡断，涉众之间不能达成一致意见，并可能很快就使项目瘫痪。

原因：

时间压力可能会使人过早的开发系统，他们的工作建立在错误的基础之上，使其步入正轨的代价可能会非常昂贵；

构建人员有一种扩展系统范围的自然倾向；

涉众之间有一些相互冲突的愿景；

项目目标不清晰；

开发人员之间缺乏交流；

所以：

    准备一份清晰描述系统目标的陈述，确保其支持组织的使命，并将其直接分发给参与项目的每个人。

 

愿景陈述应该包括：

?         系统目标；

?         系统将解决的问题；

?         系统不会解决的问题；

?         涉众是谁；

?         系统将如何使涉众受益；

 

4.2 VisibleBoundary（可见的边界）

如果不知道系统的边界，系统的范围就会以一种不可控制的方式增长。

原因：

对于系统边界，不同的人有有不同的观点；

定义糟糕的边界会导致范围的蠕变，开发人员喜欢添加某些不会给系统带来好处的特性；

有些人认为定义边界时不必要的；

所以：

通过列举与系统交互的人员与设备，在系统与其环境之间建立一个可见的边界；

开发的早期阶段，由于系统的愿景并不清晰，系统边界可能是模糊的，先确定一个系统边界，变成文档，然后随着开发的深入，对其进行SpiralDevelopment。

上下文图：

系统

终结器

终结器

终结器

终结器

 

4.3 ClearCastOfCharacters（清晰识别角色）

如果仅分析系统的用户，而忽视他们在系统中所扮演的角色，就可能会遗漏重要的系统的行为或引入冗余的行为。

原因：

系统必须满足其用户的需要并保护其涉众的利益，这样的系统才是有用的；

把服务和某些用户绑在一起可能会使系统变得非常死板；

主体专家的狭窄焦点或视野可能会使我们漏掉用户要求的服务；

将焦点放在用户身上可能会使我们纠缠于实现细节，而不是提供对用户所需要的服务的理解；

时间压力和权宜之计鼓励我们仅对用户进行分析；

所以：

识别系统必须与之交互的参与者，以及每个参与者和系统交互时所扮演的角色，并清晰描述每个参与者。

4.4 UserValuedTransactions

如果系统不能为其用户提供有价值的服务，不支持系统愿景所规定的目的和目标，那么系统就是不完善的。

原因：

一个编写良好的用例应该清晰准确的描述系统提供的基本功能，该信息能够使客户在构建系统前察看它，以确定系统是否提供了他们认为有价值的服务；

识别低层的事务相对来说是容易的，但识别有价值的服务就难了；

在一个足够高的级别编写用例，可以保证用例相对稳定；

在太高的级别上编写用例，对系统开发人员毫无用处；

在太低的级别上编写用例；难以从高的层次上理解系统；

所以：

识别系统为参与者提供以满足其业务目的的有价值的服务；

避免基于表单的用例集；

 

4.5 EverUnfoldingStory

描述系统的行为所需的步骤已经超出了所有读者的记忆和兴趣范围。

原因：

不同的涉众从不同的角度看待系统；

每个用例都有可能有许多读者和很多使用方式，它们需要不同的详细级别；

在多个层次编写用例会让人感到混乱；

编写人员需要遵循一个原则来对需求进行组织；

所以：

将一组用例组织为分层故事的形式，可以将其展开获得更多的细节，也可以将其折叠起来隐藏细节，显示更多的上下文；

三个级别用例：

l         概要级：需要用多个用户目标会话来完成；

l         用户目标级：满足了主参与者当前的特定价值目标，一般由一个主参与者在一个位置执行；

l         子功能级：满足了用户目标级用例或另一个子功能的部分目标；