任务:详细描述用例
在此任务中将详细信息添加到特定的用例。
规程:需求
用途

此任务的目的是:

  • 足够详细地描述一个或多个用例的事件流,以便能够基于它开始软件开发。
  • 详细描述用例,使参与者代表或客户能理解并感到满意。
关系
角色主执行者: 其他执行者:
输入必需: 可选:
输出
流程使用情况
步骤
复审和改进场景

在当前开发周期中,首先复审和改进您将要处理的场景。 这些场景可能最初在任务:查找参与者和用例中就已确定。从这些枚举的场景开始,确定将要描述的流的范围。

详细描述事件流

任务:查找参与者和用例期间,可能已概括了用例的事件流。以这个概述为起点,逐步进行细化。

故事板将帮助您理解和详细描述用例流。另一个要考虑的输入是用户界面原型(如果已设计了一个原型)。

按照对项目确定的标准来描述用例。为了在用例中保持一致,在描述用例之前先确定下面几点:

  • 用例如何开始?用例的开始必须明确地描述激活用例的信号。例如,记下“用例可以在 ... 发生时启动”。
  • 用例如何终止?您应明确规定流程中发生的使用例终止的任何情况。例如,记下“用例在 ... 发生时终止”。
  • 用例如何与参与者交互?为使误解的风险降到最低,请精确地规定什么将驻留在系统内,什么将驻留在系统外。 将描述结构化为一系列段落,其中每一段采用如下格式表示一个操作:“当参与者执行 .... 时,系统将 ....”。您还可以记下用例向参与者发送信号和从参与者处接收信号,以强调交互,例如:“用例在收到来自操作员的信号“启动”时启动。
  • 用例如何与参与者交换数据?您可以按照您的意愿引用信号中的参数,但最好还是有文字说明,例如,“在用户提供名称和密码登录到系统后,用例启动。”
  • 用例如何重复某些行为?您应尝试用自然语言表达这个问题。 但也存在例外情况,如果用自然语言很难表达某些术语,则值得采用类似代码的结构来表达,例如“WHILE-END WHILE”、“IF-THEN-ELSE”和“LOOP-END LOOP”。 但是,通常,您应该避免在用例描述中使用这样的类似代码的结构,因为它们很难阅读和维护。
  • 在用例的事件流中存在任何可选情况吗?有时会向参与者提供几个选项。 这应以同样的方式撰写。例如:

    “参与者一次或多次选择下面的其中一项:

    a) . . .

    b) . . .

    c) . . ." 等等

  • 应如何描述用例才能使客户和用户理解? 如果使用特定于方法的术语(例如用例、参与者和信号),可能会使得文本难以掌握(没必要)。为使文本更易于阅读,您可能要列出操作或者采用其他的某个策略。无论您使用什么策略,都应在一般用例建模指南中指定,这样就可在整个描述用例的任务中时刻牢记。

专注于描述用例中的操作,而非应如何解决系统内部的具体问题。 稍后将在生命周期中描述这些问题的详细处理方式,因此,此时的描述不必过于详尽。只需描述您认为将在以后稳定下来的内容。

如果用例的事件流包含的内容过多或者过于复杂,或者如果有些部分似乎彼此独立,则请将其分割成两个或更多的用例。

编写描述性文本时,请参阅工作产品:词汇表。一旦从新概念中引申出新的术语,则将其加入词汇表中。不要在没有通知相应项目成员的情况下更改术语的定义。 关于更多信息,请参阅任务:获取常用词汇表

事件流描述的内容

事件流描述探讨:

  • 用例何时以何种方式开始。
示例:

“用例可以在用户激活‘管理定单’功能时启动。”

  • 用例何时与参与者交互,它们交换什么数据。
示例:

“为创建一份新订单,用户需激活‘新建’功能,然后指定关于订单的以下必需数据:名称、网络元素(至少一个)和评测功能的类型。还可以指定关于订单的可选数据:注释(一段简短的文本描述)。 然后用户激活‘确认’功能,这样即在系统中创建了一份新的定单。”

注意:关于参与者和用例之间交换的数据,您必须清楚;否则,客户和用户将可能不理解用例描述。

  • 用例何时以何种方式使用存储在系统中的数据,或者何时以何种方式在系统中存储数据。
示例:

“用户激活‘修改’功能以修改现有订单,并指定一个订单号(小整数)。 然后,系统使用订单名称、网络元素以及度量功能类型初始化订单表单。这些数据可从辅助存储设备中检索到。”

  • 用例何时以何种方式结束。
示例:

“当订购人激活‘退出’功能时,用例结束。”

您还应描述奇怪的或异常的事件流。异常流是不符合用例流正常或基本行为的用例子流。 不过,这种流在用例行为的任何完整描述中仍是必要的。第一个示例中给出的异常流就是异常流的典型例子。 如果用例收到一些意外数据(参与者不是在该特定环境中预期会出现的参与者),则该用例终止。 具有错误的参与者以及过早终止不属于典型事件流。

描述用例时应考虑的其他一些“须知”还包括:

  • 描述事件流,而不仅描述用例的功能或用途。
  • 仅描述属于该用例的流,不描述与其并行运作的其他用例中正在发生的情况。
  • 不提及不与所讨论的用例进行通信的参与者。
  • 描述用例与任何参与者的交互时,不提供过多的细节。
  • 如果为用例描述的子流顺序无需固定,则不要将其描述为该顺序似乎必须固定。
  • 使用公共词汇表中的术语,并在撰写文本时考虑以下各条:
  • 使用简明的词汇表。如果可以使用简单的术语,则不要使用复杂的术语。
  • 撰写语句简短明了。
  • 避免使用副词,例如非常、更、相当等等。
  • 使用正确的标点符号。
  • 避免使用复合句。

关于更多信息,请参阅指南:用例中关于事件流的内容和风格的讨论。

构造事件流

用例的事件流可以分成几个子流。激活用例时,如果以下条件保持为真,则可以各种方式组合子流:

  • 可以从几种可能途径中的一种继续该用例,这取决于给定参与者的输入,或者某个属性或对象的值。 例如,参与者可以根据几个选项决定接下来要执行的操作,或者如果某个值小于或大于某一值,事件流就会有所变化。
示例:

自动柜员机系统中“取款”用例的描述可能包括“将客户想要从帐户中提取的金额与帐户余额比较。 如果该金额超过余额,则通知客户,且该用例终止。 否则就从帐户中提取该金额。”

  • 用例可按可选的顺序执行一些子流。
  • 用例可同时执行几个子流。

必须描述所有这些可选的或备用的流。建议您在“事件流”部分的单独附录中描述每个子流,且描述对于以下各情况是必需的:

  • 占用给定事件流的一个大分段的子流。
  • 异常事件流。这有助于更明确地突出用例的基本事件流。
  • 可在同一个事件流中分几个时间间隔执行的任何子流。

如果某个子流仅涉及到整个事件流的一小部分,则最好在文本正文体中对其进行描述。

示例:

“当参与者‘订购人’或‘性能管理员’调用‘管理订单’功能时,会激活此用例。 如果信号不是来自这两个参与者之一,用例将终止操作,并向用户显示相应的消息。 但如果已识别参与者,则该用例将继续执行 ....”

可以用任务图说明事件流的结构,请参阅指南:用例模型中的活动图。  

关于更多信息,请参阅指南:用例中有关结构的部分。

说明用例与参与者和其他用例的关系

创建用例图,显示用例及其与参与者和其他用例的关系。 此类图充当用例的本地图,且应与之相关。 请注意,此类本地用例图通常几乎没有价值,除非该用例有需要说明的用例关系,或者所涉及到的参与者具有罕见的复杂性。

关于更多信息,请参阅 指南:用例图

描述所有特殊需求

可能与该用例相关、但在用例的事件流中未予考虑的任何需求均应在用例的特殊需求中描述。 这样的需求可能是不起任何作用。

关于更多信息,请参阅指南:用例中有关特殊需求的部分。

定义通信协议

定义要用于作为其他系统或外部硬件的参与者的任何通信协议。如果要使用某个现有协议(特别是公认的协议或被认为是标准的协议),则用例的描述应只指定该协议。 如果协议是新的协议,则您应指向可以找到协议定义的位置,该协议定义需要在对象模型开发期间进行充分描述。

描述前置条件

用例的前置条件说明,为使用例有可能开始,系统必须处在的状态。

示例:

为使 ATM 系统能够分发现金,必须满足以下前置条件:

  • ATM 网络必须可访问。
  • ATM 必须处于准备接受交易的状态。
  • ATM 中必须存有一些可供分发的现金。
  • ATM 必须有足够的纸张为至少一次交易打印收据。

这些都将是用例“分发现金”的有效前置条件。

请谨慎描述系统状态;避免描述可能在此用例之前发生的其他偶发任务的详细信息。

前置条件不用来创建一系列的用例。永远不会出现这种情况:必须首先执行一个用例,然后执行另一个用例,才能有具有意义的事件流。 如果您觉得需要这样做,则可能是您过度分解了用例模型。 通过将序列相关的用例组合成单个用例,可纠正该问题。 如果这使得生成的用例过于复杂,则可考虑使用上面“构造用例的事件流”的步骤中或任务:构造用例模型中提供的构造用例的方法。

关于更多信息,请参阅指南:用例中有关前置条件的部分。

描述后置条件

用例的后置条件列出在用例结束时用例可能处在的状态。在用例执行结束时,系统必须处于这些状态中的一种。它还用来规定系统在用例结束时执行的操作,而与用例中发生的情况无关。

示例

如果 ATM 在用例结束时始终显示“欢迎”消息,这种情况可以记录在用例的后置条件中。

类似地,如果 ATM 在诸如“取出现金”之类的用例结束时始终结束客户的交易,而不管所发生事件的过程,那么该情况应记录为用例的后置条件。

后置条件用于降低用例的复杂性,并改善用例事件流的可读性。

在任何情况下后置条件都不应当用来创建一系列用例。 永远不应出现这种情况:必须首先执行一个用例,然后执行另一个用例,才能有具有意义的事件流。 如果觉得有必要这样做,则序列相关的用例应组合成单个用例。 如果这使得组合的用例过于复杂,则可考虑使用上面的“构造用例的事件流”中或任务:构造用例模型中提供的构造用例的方法。

关于更多信息,请参阅指南:用例中有关后置条件的部分。

描述扩展点

如果用例要通过其他用例进行扩展(请参阅指南:扩展关系),则需要描述什么是扩展点(请参阅指南:用例中关于扩展点的部分)。

评估您的结果

与项目干系人一起复审和讨论用例,这样他们就对用例有清楚的了解,并就其描述达成一致。

只有在用例描述描述了用例自始至终执行、实施或允许的任何内容之后,用例描述才是完整的。 在结束用例描述之前,检查用例是否显示出作为“好的”用例应具备的特征。关于更多信息,请参阅核对表:用例

更多信息