在任务:查找参与者和用例期间,可能已概括了用例的事件流。以这个概述为起点,逐步进行细化。
故事板将帮助您理解和详细描述用例流。另一个要考虑的输入是用户界面原型(如果已设计了一个原型)。
按照对项目确定的标准来描述用例。为了在用例中保持一致,在描述用例之前先确定下面几点:
-
用例如何开始?用例的开始必须明确地描述激活用例的信号。例如,记下“用例可以在 ... 发生时启动”。
-
用例如何终止?您应明确规定流程中发生的使用例终止的任何情况。例如,记下“用例在 ... 发生时终止”。
-
用例如何与参与者交互?为使误解的风险降到最低,请精确地规定什么将驻留在系统内,什么将驻留在系统外。 将描述结构化为一系列段落,其中每一段采用如下格式表示一个操作:“当参与者执行 .... 时,系统将
....”。您还可以记下用例向参与者发送信号和从参与者处接收信号,以强调交互,例如:“用例在收到来自操作员的信号“启动”时启动。
-
用例如何与参与者交换数据?您可以按照您的意愿引用信号中的参数,但最好还是有文字说明,例如,“在用户提供名称和密码登录到系统后,用例启动。”
-
用例如何重复某些行为?您应尝试用自然语言表达这个问题。 但也存在例外情况,如果用自然语言很难表达某些术语,则值得采用类似代码的结构来表达,例如“WHILE-END WHILE”、“IF-THEN-ELSE”和“LOOP-END
LOOP”。 但是,通常,您应该避免在用例描述中使用这样的类似代码的结构,因为它们很难阅读和维护。
-
在用例的事件流中存在任何可选情况吗?有时会向参与者提供几个选项。 这应以同样的方式撰写。例如:
“参与者一次或多次选择下面的其中一项:
a) . . .
b) . . .
c) . . ." 等等
-
应如何描述用例才能使客户和用户理解?
如果使用特定于方法的术语(例如用例、参与者和信号),可能会使得文本难以掌握(没必要)。为使文本更易于阅读,您可能要列出操作或者采用其他的某个策略。无论您使用什么策略,都应在一般用例建模指南中指定,这样就可在整个描述用例的任务中时刻牢记。
专注于描述用例中的操作,而非应如何解决系统内部的具体问题。 稍后将在生命周期中描述这些问题的详细处理方式,因此,此时的描述不必过于详尽。只需描述您认为将在以后稳定下来的内容。
如果用例的事件流包含的内容过多或者过于复杂,或者如果有些部分似乎彼此独立,则请将其分割成两个或更多的用例。
编写描述性文本时,请参阅工作产品:词汇表。一旦从新概念中引申出新的术语,则将其加入词汇表中。不要在没有通知相应项目成员的情况下更改术语的定义。
关于更多信息,请参阅任务:获取常用词汇表。
事件流描述的内容
事件流描述探讨:
示例:
“用例可以在用户激活‘管理定单’功能时启动。”
示例:
“为创建一份新订单,用户需激活‘新建’功能,然后指定关于订单的以下必需数据:名称、网络元素(至少一个)和评测功能的类型。还可以指定关于订单的可选数据:注释(一段简短的文本描述)。
然后用户激活‘确认’功能,这样即在系统中创建了一份新的定单。”
注意:关于参与者和用例之间交换的数据,您必须清楚;否则,客户和用户将可能不理解用例描述。
-
用例何时以何种方式使用存储在系统中的数据,或者何时以何种方式在系统中存储数据。
示例:
“用户激活‘修改’功能以修改现有订单,并指定一个订单号(小整数)。 然后,系统使用订单名称、网络元素以及度量功能类型初始化订单表单。这些数据可从辅助存储设备中检索到。”
示例:
“当订购人激活‘退出’功能时,用例结束。”
您还应描述奇怪的或异常的事件流。异常流是不符合用例流正常或基本行为的用例子流。 不过,这种流在用例行为的任何完整描述中仍是必要的。第一个示例中给出的异常流就是异常流的典型例子。
如果用例收到一些意外数据(参与者不是在该特定环境中预期会出现的参与者),则该用例终止。 具有错误的参与者以及过早终止不属于典型事件流。
描述用例时应考虑的其他一些“须知”还包括:
-
描述事件流,而不仅描述用例的功能或用途。
-
仅描述属于该用例的流,不描述与其并行运作的其他用例中正在发生的情况。
-
不提及不与所讨论的用例进行通信的参与者。
-
描述用例与任何参与者的交互时,不提供过多的细节。
-
如果为用例描述的子流顺序无需固定,则不要将其描述为该顺序似乎必须固定。
-
使用公共词汇表中的术语,并在撰写文本时考虑以下各条:
-
使用简明的词汇表。如果可以使用简单的术语,则不要使用复杂的术语。
-
撰写语句简短明了。
-
避免使用副词,例如非常、更、相当等等。
-
使用正确的标点符号。
-
避免使用复合句。
关于更多信息,请参阅指南:用例中关于事件流的内容和风格的讨论。
|