有效用例模式笔记(六)(七)(八)

完整笔记下载

第六章场景和步聚

6.1DetectableConditions

编写人员总是绞尽脑汁地思考包括多少条件以及包括哪些条件

原因：

·         系统不能处理它检测不到的事件

·         开发人员需要知道检测什么条件

·         害怕忽视重要的分支使得开发人员叙述系统检测不到的不相关条件

·         很多从表面上看起为不同的条件可能会导致编写不必要的分支

所以：

只包含可检测的条件，合并对系统最终影响相同的条件

6.2 LeveledSteps

过大或过小的用例步聚会模糊目标，并会使用例难以阅读和理解。

原因：

·         过小的步骤使得用例不公冗长而且难以阅读，它们模糊了"为什么"。

·         过大的步骤可能会掩盖重要的行为。

·         在场景中，使用不同的详细级别编写会分散读者的注意力

所以：

将场景保持在3~9步内。理想情况下，步骤都是在类似级别编写，并且是公在用例目标之下的抽象级别

6.3ActorIntentAccomplished

如果对哪个能与者负责执行步骤，以及参与者在该步骤中试图完成什么表述得不够清晰，读者和开发人员就会对系统的行为感到困惑

原因：

·         编写高质量的用例是一项艰难的工作

·         开发人员需要清楚知道他们要实现什么，系统在什么时间应该等待输入信息，以及系统在什么时侯应该采取行动

所以：

编写每个步骤，清楚地显示哪个参与者在执行操作，以及参与者完成了什么工作。

6.4ForwardProgress

编写人员必须决定在任何一个步骤中包含多少行为。他们很容易编写太多的细节，使得用例冗长乏味而且难以阅读。

原因：

·         清晰简洁的步骤减少了理解和评估用例所需要的精力。

·         对完整性和细节的期望可能会导致包含偏离用例目标的步骤。

所以：

消除或合并对参与者没有推进作用的步骤。简化会分散读者对目标实现注意力的内容。

6.5TechnologyNeutral

在用例描述中包含技术约束和实现细节会提高复杂性，并且会模糊用例的目标。

原因：

·         许多人都喜欢用具体词语来思考问题

·         技术是不稳定的，包含具体技术的细节将会导致返工。

·         技术细节对未来的活动产生了不适当的约束

·         添加技细节提高了阅读和编写用例的成本

·         有时添加技术细节是一种需要。

所以：

以一种技术中性的方式编写每一个用例

第七章用例关系

7.1CommonSubBehavior

为不同的用例编写相同的步骤不仅浪费时间和精力，而且更难在一个用例模型中看到公共的子过程

原因:

·         重新编写公共的步骤是多余的，而且会提高模型不准确性和不一致性的风险

·         划分单个用例很可能会分散重要的行为，并且会使用例理难理解

·         误解"包含"关系会导致误用

所以：

用较低层的被"包含"用例表达共享的动作路径

7.2　InterruptsAsExtensions

影响场景中多个步骤的分支会把相关细节分散在用例中，这样会遗漏重要的信息或使读者感到混乱。

原因：

·         多次偏离或打断场景中几个步骤的分支可能会使读者失去他们正试图理解的路径线索，可能表明基本场景本身存在问题。

·         创建护展用例容易分散重要的行为，并使它们更难理解

·         误解"扩展"关系会导致扩展的误用

所以：

当分支动作路径中断了一个场景中的大量步聚时，创建一个扩展用例。

7.3 PromotedAlternative

冗长或复杂的分支可以占据用例的大部分，因为它们非常突出，所以导致其重要性被夸大。

原因：

·         复杂或冗长的分支会搞乱一个用例，并且会模糊其他分支。

·         一些问题非常复杂，它们要求用复杂的用例对其进行充分描述

·         划分单个用例容易分散重要的行为，并且会使它们变得更难理解。

所以：

　考虑将过分支配用例的复杂分支移到一个单独的用例中

7.5　CapturedAbstraction ---应用UML泛化的模式

在一个用例中，试图把两个或多个不同的分支(任何一个者不占支配地位)编成文档是很困难的，而且容易引起混淆。

原因：

·         复杂或冗长的分支会搞乱用例，并且可能会模糊其他分支。

·         一些问题非常复杂，而且有几个不同的解决方案

·         有许多单个的用例很可能会分散重要的行为，并且会使行为更难理解

所以：

考虑创建一个泛化的抽象用例，将具体描述这种抽象的每个不同的场景放在各处的特化用例中

第八章 编辑现有用例

8.1 RedistributeTheWealth

过长的用例不实用而且难以使用，会分散用户的注意力，并使他们失去重点

原因：

·         用例的目标对涉众必须清晰

·         添加新用例的代价是昂贵的

·         过多的细节可能会使用例难以阅读和理解

所以：

将冗长、难以处理的内容或过分复杂的护展转移到它自已的用例中

8.2 MergeDroplets

描述细小或孤立行为片断的用例不能传达足够的信息，来帮助读者理解系统如何提供UserValuedTransactions。

原因：

·         不完整的用例不能讲述整个故事

·         最好是在任何可能的时侯定位信息

·         最好使用例的数量最少

·         较小的用例易于理解和使用

所以：

将相关的小用例或用例片断合并到与相同目标相关的用例中

8.3 CleanHouse

对于整体没有什么价值的用例是分散注意力的，并可能会使读者误入岐途。

原因：

·         清除已有的用例会占用时间和精力

·         未使用的用例搞乱了工作空间，并且会浪费精力

·         去掉用例避免了大量的开发工作，并节约了精力

所以：

删除不会为系统添加任何价值，或者已不在现有用例清单中的那些用例