3.5 描述用例

正如我们前面曾提到过的，图形化表示的用例本身不能提供该用例所具有的全部信息，因此还必需描述用例不可能反映在图形上的信息。通常用文字描述用例的这些 信息。用例的描述其实是一个关于角色与系统如何交互的规格说明，该规格说明要清晰明了，没有二义性。描述用例时，应着重描述系统从外界看来会有什么样的行 为，而不管该行为在系统内部是如何具体实现的，即只管外部能力，不管内部细节。
用例的描述应包括下面几个方面：
（1）用例的目标
用例的最终任务是什么？想得到什么样的结果？即每个用例的目标一定要明确。
（2（用例是怎样被启动的
哪个角色在怎样的情况下启动执行用例。比如：张三渴了，张三买矿泉水。“渴了”是使张三买矿泉水的原因。
（3）角色和用例之间的消息流
角色和用例之间的哪些消息是用来通知对方的？哪些是修改或检索信息的？哪些是帮助用例做决定的？系统和角色之间的主消息流描述了什么问题？系统使用或修改了哪些实体？
（4）用例的多种执行方案
在不同的条件或特殊情况下，用例能依当时条件选择一种合适的执行方案。注意，并不需要非常详细地描述各种可选的方案，它们可以隐含在动作的主要流程中。具体的出错处理可以用脚本描述。
（5）用例怎样才算完成并把值传给了角色
描 述中应明确指出在什么情况下用例才能被看作完成，当用例被看作完成时要把结果值传给角色。需要强调的是，描述用例仅仅是为了站在外部用户的角度识别系统能 完成什么样的工作，至于系统内部是如何实现该用例的（用什么算法等）则不用考虑。描述用例的文字一定要清楚，前后一致，避免使用复杂的易引起误解的句子， 方便用户理解用例和验证用例。
用例也可以用活动图描述，即描述角色和用例之间的交互（如图3-9 所示）。活动图
（第五章中详叙）中显示各个活动的顺序和导致下一个活动执行的决策（decision）。 对用户来说用例视图更易于使用。
对于已经包含完全性和通用性描述的用例来说，还可以再补充描述一些实际的脚本，用脚本说明用例被实例化后系统的实际工作状况，帮助用户理解复杂的用例。注意，脚本描述只是一个补充物，不能替代用例描述。






对某个用例的描述完成之后，可以用一个具体的活动跟踪一下，检查用例中描述的关系能否被识别。在执行这个活动，时可以通过回答下列问题找出不足之处。

• 用例中的所有角色与该用例都有关联关系吗？
• 若干个角色的通用行为与基类角色（从若干个角色的行为中抽象出的最普通的那部分）的行为是否相似？
• 表示同一个活动流的多个用例之间是否存在相似性？它们是否能用使用关系描述为一个用例。
• 用例扩展关系中描述的特殊情况存在吗？
• 有没有存在无任何通信关联的角色或用例？如果有，那么用例一定存在问题，否则为什么还要这个角色。
• 有没有遗漏与需求的功能相对应的用例？如果有，那么就要新建一个用例。

注意，不要把所有的用例建好之后，再去识别用例中的关系是否正确。这种做法有时会导致错误。