用途
  • 足够详细地描述一个或多个用例的事件流,以使得能在它上面开始软件开发。
  • 描述用例规范,使参与者代表或客户能理解并感到满意。
角色: 需求指定者 
频率:对于在迭代中详细描述的每个用例或用例流,每次迭代一次
步骤
更多信息: 
输入工件:   生成的工件:  
工具向导:  

工作流程明细:  

复审和改进场景 回到页首

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

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

详细描述事件流 回到页首

您应该已经有了一个关于用例事件流的概括性的逐步描述。这也在活动:查找参与者和用例中创建。从这个逐步概述开始,然后逐渐更详细地进行描述。

根据为项目。在描述用例之前决定以下各点,以便在各用例之间保持一致:

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

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

    a) . . .

    b) . . .

    c) . . .”等等。

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

专注于描述用例中的操作,而非应如何解决系统内部的特定问题。 使用对象模型时,您可能必须用关于所发生情况的细节来对描述进行补充,因此,此时不要过于详细地进行描述。 只需描述您认为将在以后稳定下来的内容。

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

撰写描述文本时,请参考词汇表。一旦从新概念中引申出新的术语,则将其加入词汇表中。不要在没有通知相应项目成员的情况下更改术语的定义。

事件流描述的内容

事件流描述探讨:

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

“用例可以在用户激活‘管理订单’功能时开始。”

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

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

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

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

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

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

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

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

描述用例时需要考虑的其它“要做的和不要做的”事项包括:

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

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

构造事件流 回到页首

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

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

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

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

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

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

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

示例:

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

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

关于更多信息,请参阅指南:用例,事件流的结构

说明与参与者和其它用例的关系 回到页首

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

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

描述所有特殊需求 回到页首

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

关于更多信息,请参阅指南:用例,特殊需求

定义通信协议 回到页首

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

描述前置条件 回到页首

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

示例:

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

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

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

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

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

关于更多信息,请参阅指南:用例、前置条件和后置条件

描述后置条件 回到页首

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

示例

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

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

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

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

关于更多信息,请参阅指南:用例、前置条件和后置条件

描述扩展点 回到页首

如果用例要由其它用例扩展(请参阅指南:扩展关系),您需要描述什么是扩展点(请参阅指南:用例,扩展点)。

评估您的结果 回到页首

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

只有在用例描述描述了用例自始至终执行、实施或允许的任何内容之后,用例描述才是完整的。 完成之前,检查用例展示的属性是否符合用例作为“好”用例的属性。请参阅活动:复审需求中检查点的用例和用例报告。



Rational Unified Process   2003.06.15