修订历史
日期 |
版本 |
描述 |
作者 |
|
|
|
|
|
|
|
|
用例建模准则
此组准则的目的是确保用例模型的一致性。它提供如何记录用例的指南,以及需求指定者和系统分析员经常会有疑问的相关主题的一般帮助。
这些准则可以按原样使用,或者进行定制,以满足大部分项目的需求。
请参阅 Rational Unified Process 词汇表。
无
此组准则分为两个部分,第一部分描述用例建模的首选方式,第二部分提供用例模型的内容和模型中元素命名的准则。
用例将使用随 Rational Unified Process 提供的模板撰写,并进行一定的风格和布局修改,以符合适用的项目文档标准。
参与者和用例之间的关联称为“通信”关系。建议将此关联设为单向关系。 通过使用此种建模策略,可以将参与者进行以下区分:
q
主动参与者
在参与者启动(或触发)用例的执行时,参与者在“参与者 - 用例”对中视为是主动的。通信关系中的箭头指向用例。
q
被动参与者
在用例启动通信时,参与者在“参与者 - 用例”对中视为是被动的。被动参与者通常是外部系统或设备,系统需要与之进行通信。通信关系中的箭头指向参与者。
给出此建议是因为主动参与者和被动参与者的概念可以为用例模型的读者“增加价值”。
在第一个实例中,建议避免使用这些关系。给出此建议是因为误用这些关系更多的是可能导致混乱和混淆,而不是帮助简化用例模型。最佳实践是在初始时避免这种类型的分解,而在流程的稍后阶段考虑使用这些关系。这些关系可以用于:
1. 抽出两个以上用例中的公共行为。
2. 从基本用例中抽出行为,该行为对于理解该用例的主要目的并不是必需的,而只有行为的结果是重要的。
3. 显示可能存在一组行为段,其中的一个或几个行为段可以在基本用例中的扩展点处插入。
但是应当仅在它们能够帮助简化和管理用例模型而增加价值时使用它们。
包含关系描述一个行为段,该行为段要插入到执行基本用例的用例实例中。它在本质上是一种类似于子例程的机制,通常用于抽出公共的行为。
请参阅 Rational Unified Process 中的包含关系准则获取更多详细信息。
扩展关系是较难于利用的关系,主要是因为扩展用例对于基本用例是未知的。通常而言,在大多数业务系统中很少会使用此关系。但是要记住,规则总是存在例外,此机制在某些情况中会非常有用。
请参阅 Rational Unified Process 中的扩展关系准则获取更多详细信息:
通常,参与者泛化关系可以用于更好地定义由要开发的系统的用户充当的不同角色。 这在具有不同“类别”的最终用户的应用程序中非常有用。使用这种方式,对于每个类别的用户,将只提供相关的功能,并能够根据分组控制访问权。
经验:每个用例只由一个参与者启动。此“规则”可以被推翻,此时必须通过用例描述说明此决定是合理的。
来自大学业务领域的示例: “图书管理员”和“教授”是大学领域中两个现有角色(参与者)的示例。这两个角色具有一些公共的任务,同时也具有一些在“业务”中特定于其角色的任务。对此进行建模的首选方式在下面显示。
请参阅 Rational Unified Process 中的指南:参与者泛化关系获取更多详细信息。
在某些情况下,在文本事件流之外再包含一个交互图来说明用例的“高级别”事件流会很有好处。建议您在 Rational Rose 中为此绘制一个时序图。在其中仅包含参与者和边界对象之间的通信(包括输入和输出消息),并将系统当作是一个黑匣。边界对象使用在用例事件流中定义的逻辑名称,此时不将它们指定到任何类。
并不是每个用例都需要具有相应的交互图:它是可选的工作产品。
当活动图可以在帮助定义、阐明和完成用例中的事件流方面添加价值时,建议在 Rational Rose 中进行建模。为复杂用例(包含多个备选和/或异常流)考虑使用活动图是一条好的经验。活动图用于显示用例中的流的决策树。
并不是每个用例都需要具有相应的活动图:它是可选的工作产品。
有关一般信息和更多的用例准则,请参阅 Rational Unified Process。
有关一般信息和更多的参与者准则,请参阅 Rational Unified Process。
每个具体用例是否都至少涉及一个参与者?如果不是,就存在问题了。不与参与者交互的用例是多余的,应该将它删除或确定相应的参与者。
在某些情况中,会有多个参与者参与到用例交互中。请确保检查在一个用例中使用多个参与者是否是有效的(请参阅“参与者泛化关系”)。
参与者是否是具有直观、描述性的名称?用户和客户都能理解这些名称吗?参与者的名称与他们的角色对应,这一点很重要。如果不是,则更改它们。
您应当参考用例模型来确保为用例中的每个参与者使用了正确的参与者名称。
用例规范需要使用一致的参与者名称撰写。需要注意确保参与者命名是清晰明确的。
不要笼统地使用“参与者”,而应当使用实际的名称来唯一地确定或定义参与者。参与者名称可以视为是参与到一组系统交互中的角色。
用例名称应是唯一、直观和解释性的名称,从而可以清晰明确地定义从用例获取的值的可观察结果。
检查用例名称的一种好方法是调查客户、业务代表、分析人员和开发人员是否都能理解用例的名称和描述。请记住:您需要从参与者的角度定义值的可观察结果。
每个用例名称需要描述用例支持的行为。名称中需要包含要执行的操作和要操作的关键元素。通常,这是一种简单的“动词/名词”组合。用例应当从触发用例的参与者的角度进行命名。示例包括:“注册课程”、“选择授课课程”。
用例中需包含用例的简短描述。此描述的长度至少应当为 1 个段落,并且不超出 3 个段落。描述中需包含用例的关键目的、价值陈述和概念的说明。
如果简短的示例“故事”能够增加价值,则可以在简短描述中包含它来帮助进一步地描述环境。此示例通常需遵循基本流,同时在有帮助时包含数据值。
用例中的系统需求需使用祈使语气撰写。相对于“应当”和“必须”,通常更倾向于使用“需要”来一致地描述需求。并且应避免使用暗示需求是可选或未定义的需求的消极词汇,例如,“应该”、“可能”、“等”。
用例中使用的所有业务术语在项目的词汇表中进行定义。如果用例中存在词汇表中未包含的业务术语,则术语需要:
1. 添加到词汇表中,同时包含简短描述(最多 1 个段落)。
2. 在用例中进行更改,以反映词汇表中定义的正确业务术语。
用例需要明确地说明系统负责在何处提供用作供参与者选择的可用选项的操作。在多数情况下,可用选项应当作为基本流的组成部分而提供,并在对应的备选流的第一个语句中作为入口点引用。
诸如“新建”、“修改”、“取消”、“删除”、“确定”和“打印”之类的术语在整个用例的使用需保持一致:相同的逻辑操作不能使用不同的术语指代。特别需要注意确保在备选流中使用的操作术语与在基本流中使用的操作术语匹配。
每次参与者和系统之间的交互改变焦点(在参与者和系统之间)时,下一个行为段需使用新的段落描述。先描述参与者,然后再描述系统。
句子必须以“<参与者名称> 需 xxxxx”或“系统需 xxxx”开始。始终使用全称来正确地表示参与者名称,而不是使用缩写。
每个备选流和子流清晰明确地定义进入流中的所有可能的入口点,并结束于从流中退出的所有可能的出口点。
备选流还将明确地说明出口点和参与者继续到下一步的位置 - 是返回到基本流中的特定步骤还是结束。
在事件流由于存在复杂的行为而变得混乱时,或者在单个流的长度超出实际的打印页面时,可以使用子流来提高明确性和管理复杂性。子流使用以下形式撰写:将自包含的详细行为逻辑组移动到子流中,然后在事件流中以摘要形式引用此行为。
用例规范中需包含一组在用例开始之前(前置条件)和用例结束之后(后置条件)期望为真的条件(也称为假定)。请注意,用例可能会以多种方式结束,对于每种方式应相应地描述其“后置条件”。
在信息尚未定义或尚未确定时,用例中需包含对问题或元素的引用,并包含占位符:待定。
在一些附加需求无法在事件流期间自然地描述时,可以将这些需求定义为补充需求。对于那些特定于用例的需求,需在用例规范的“特殊需求”一节中定义。
对于那些在系统范围内适用的需求(特别是非功能性质的那些需求),需在一个或多个独立的补充规范文档中定义。
示例包括:
可靠性: - 系统必须每周 7 天、每天 24 小时可用。
- 系统的平均故障间隔时间(MTBF)必须为 48 小时。
性能: - 系统在预期的正常负载条件下的在线响应时间不得超出 5 秒。
用例内容需对照 UI 原型/设计进行交叉检查,以确保用例或 UI 原型/设计中没有缺少任何系统需求。在需要对用例进行更改时,需进行以下操作:将对 UI 原型的更改记录为未来操作的讨论内容。
提供以下准则来帮助发现异常流:
对于用例中的每个步骤,需要考虑会发生什么异常。每个独特的异常都可以捕获为“异常流”。在某些情况中,单个异常流可以在用例之间共用,例如“超时”。所要捕获的关键信息是在发生异常时的业务需求,即参与者应体验到什么?