活动:
|
用途
|
|
角色: 需求指定者 | |
频率:对于在迭代中详细描述的每个用例或用例流,每次迭代一次 | |
步骤 | |
更多信息: |
输入工件: | 生成的工件: |
工具向导: |
工作流程明细: |
在开发周期中,首先复审和改进您将要处理的场景。 这些可能最初在活动:查找参与者和用例中就已确定。从这些列出的场景开始,确定将要描述的流的范围。
串连图板将帮助您理解和详细描述用例流。 另一个要考虑的输入是用户界面原型(如果已制定了一个)。
您应该已经有了一个关于用例事件流的概括性的逐步描述。这也在活动:查找参与者和用例中创建。从这个逐步概述开始,然后逐渐更详细地进行描述。
根据为项目。在描述用例之前决定以下各点,以便在各用例之间保持一致:
“参与者一次或多次选择下面的其中一项:
a) . . .
b) . . .
c) . . .”等等。
专注于描述用例中的操作,而非应如何解决系统内部的特定问题。 使用对象模型时,您可能必须用关于所发生情况的细节来对描述进行补充,因此,此时不要过于详细地进行描述。 只需描述您认为将在以后稳定下来的内容。
如果用例的事件流包含的内容过多或者过于复杂,或者如果有些部分似乎彼此独立,则请将其分割成两个或更多的用例。
撰写描述文本时,请参考词汇表。一旦从新概念中引申出新的术语,则将其加入词汇表中。不要在没有通知相应项目成员的情况下更改术语的定义。
事件流描述探讨:
“用例可以在用户激活‘管理订单’功能时开始。”
“为新建订单,用户激活功能‘新建’,然后指定关于订单的以下必需数据:名称、网络元素(至少一个)和度量功能的类型。 还可以指定关于订单的可选数据:注释(一段简短的文本描述)。 用户然后激活功能“确定”,在系统中新建一个订单。”
注意:关于参与者和用例之间交换的数据,您必须清楚;否则,客户和用户将可能不理解用例描述。
“用户激活“修改”功能来修改现有订单,并指定订单号(小的整数)。 然后,系统使用订单名称、网络元素以及度量功能类型初始化订单表单。这些数据可以从辅助存储设备上检索到。”
“当定购人激活功能‘退出’时,用例结束。”
您还应描述奇怪的或异常的事件流。异常流是不符合用例流正常或基本行为的用例子流。 不过,这种流在用例行为的任何完整描述中仍是必要的。第一个示例中给出的异常流就是异常流的典型例子。如果用例收到一些意外数据(参与者不是在该特定环境中预期会出现的参与者),则该用例终止。 具有错误的参与者以及过早终止不属于典型事件流。
描述用例时需要考虑的其它“要做的和不要做的”事项包括:
关于更多信息,请参阅指南:用例中关于事件流的内容和风格的讨论。
用例的事件流可以分成几个子流。激活用例时,如果以下条件保持为真,则可以各种方式组合子流:
自动柜员机系统中用例“取出现金”的描述一部分可能是“将客户想要从帐户中取出的金额与该帐户的余额比较。 如果该金额超过余额,则通知客户,且该用例终止。 否则就从帐户中取出该金额。”
必须描述所有这些可选的或备用的流。建议您在“事件流”部分的单独附录中描述每个子流,且描述对于以下各情况是必需的:
如果某个子流仅涉及到整个事件流的一小部分,则最好在文本正文体中对其进行描述。
“当参与者‘定购人’或‘性能管理器管理员’调用功能‘管理订单’时,会激活此用例。 如果信号不是来自这两个参与者之一,用例将终止操作,并向用户显示相应的消息。 但如果已识别参与者,则该用例会由 .... 继续”
可以用活动图说明事件流的结构,请参阅指南:用例模型中的活动图。
关于更多信息,请参阅指南:用例,事件流的结构。
创建用例图,显示用例及其与参与者和其它用例的关系。 此类图充当用例的本地图,且应与之相关。 请注意,此类本地用例图通常几乎没有价值,除非该用例有需要说明的用例关系,或者所涉及到的参与者具有罕见的复杂性。
关于更多信息,请参阅指南:用例图。
可能与该用例相关、但在用例的事件流中未予考虑的任何需求均应在用例的特殊需求中描述。 这样的需求可能是非功能性的。
关于更多信息,请参阅指南:用例,特殊需求。
定义要用于作为其它系统或外部硬件的参与者的任何通信协议。如果要使用某个现有协议(特别是公认的协议或被认为是标准的协议),则用例的描述应只指定该协议。 如果协议是新的协议,则您应指向可以找到协议定义的位置,该协议定义需要在对象模型开发期间进行充分描述。
用例的前置条件说明,为使用例有可能开始,系统必须处在的状态。
为使 ATM 系统能够分发现金,必须满足以下前置条件:
- ATM 网络必须可访问。
- ATM 必须处于准备接受交易的状态。
- ATM 中必须存有一些可供分发的现金。
- ATM 必须有足够的纸张为至少一次交易打印收据。
这些都将是用例“分发现金”的有效前置条件。
请谨慎描述系统状态;避免描述可能在此用例之前发生的其它偶发活动的详细信息。
前置条件不用来创建一系列的用例。永远不会出现这种情况:必须首先执行一个用例,然后执行另一个用例,才能有具有意义的事件流。 如果您觉得需要这样做,则可能是您过度分解了用例模型。 通过将序列相关的用例组合成单个用例,可纠正该问题。 如果这使得生成的用例过于复杂,则按照上面的构造用例的事件流中或活动:构造用例模型中提供的信息,考虑构造用例的技术。
关于更多信息,请参阅指南:用例、前置条件和后置条件。
用例的后置条件列出在用例结束时用例可能处在的状态。在用例执行结束时,系统必须处于这些状态中的一种。它还用来规定系统在用例结束时执行的操作,而与用例中发生的情况无关。
如果 ATM 在用例结束时始终显示“欢迎”消息,这种情况可以记录在用例的后置条件中。
类似地,如果 ATM 在诸如“取出现金”之类的用例结束时始终结束客户的交易,而不管所发生事件的过程,那么该情况应记录为用例的后置条件。
后置条件用于降低用例的复杂性,并改善用例事件流的可读性。
在任何情况下后置条件都不应当用来创建一系列用例。 永远不应出现这种情况:必须首先执行一个用例,然后执行另一个用例,才能有具有意义的事件流。 如果觉得有必要这样做,则序列相关的用例应组合成单个用例。 如果这使得组合的用例过于复杂,则按照上面的“构造用例的事件流”中或活动:构造用例模型中提供的信息,考虑构造用例的技术。
关于更多信息,请参阅指南:用例、前置条件和后置条件。
如果用例要由其它用例扩展(请参阅指南:扩展关系),您需要描述什么是扩展点(请参阅指南:用例,扩展点)。
与涉众一起复审和讨论用例,这样他们就对用例有清楚的了解,并就其描述达成一致。
只有在用例描述描述了用例自始至终执行、实施或允许的任何内容之后,用例描述才是完整的。 完成之前,检查用例展示的属性是否符合用例作为“好”用例的属性。请参阅活动:复审需求中检查点的用例和用例报告。
Rational Unified Process
|