主题

说明 回到页首

用例模型是关于系统预期功能及其环境的模型,并充当客户与开发人员之间的约定。 用例充当贯穿整个系统开发过程的统一线程。同一个用例模型是“需求”规程的结果,并用作“分析与设计”和“测试”规程的输入。

下图显示了回收机器系统的用例模型的一部分。

在标题中描述的图。

用例图,显示具有参与者和用例的用例模型示例。

对系统建模的方法有多种,每种方法都可能针对一种不同的用途。但是,用例模型的最重要用途是将系统的行为传达给客户或最终用户。因此,模型必须易于理解。

用户和可与该系统交互的任何其它系统是参与者。因为参与者代表系统用户,所以它们有助于为系统定界并更明确地描绘出系统应该做什么。用例是根据参与者的需要而开发的。这就确保系统最终将符合用户的预期目标。

用例模型如何发展 回到页首

通过将客户和潜在用户的需求用作至关重要的信息,就可以找到参与者和用例。找到它们后,应简短描述用例和参与者。详细描述用例之前,应由客户检查用例模型,以验证所有用例和参与者都已找到,并且它们合起来就可满足客户需要。

在迭代开发环境中,将选择要在每次迭代中详细描述的一个用例子集。另请参阅活动:按优先级对用例排序

找到参与者和用例后,详细描述每个用例的事件流。这些描述显示系统如何与参与者交互以及系统在每个用例中的行为。

最后,检查已完成的用例模型(包括用例描述),而开发人员和客户使用该模型就系统应执行的操作达成一致。

避免功能分解 回到页首

用例模型退化而导致系统功能分解是很常见的。要避免这种情况,请注意以下征兆:

  • “小型”用例,表示事件流的描述仅为一句或几句话。
  • “多个”用例,表示用例的数量是成百的,而不是成十的。
  • 用例名称,类似“对这些特定数据执行此操作”或“使用这些特定数据执行此功能”的句子。例如,“在 ATM 机器上输入个人标识号”不应模拟成 ATM 机器的单独用例,因为没有人会只为执行该操作而使用该系统。用例是为参与者带来有价值事项的完整事件流。

要避免功能分解,应确保用例模型有助于回答像这样的问题:

  • 系统的环境是什么?
  • 为什么构建系统?
  • 用户使用系统时希望实现什么?
  • 系统怎样对用户增值?

非功能需求 回到页首

很容易发现,用例是获取系统功能需求的一种极好方法。但是非功能需求怎么办呢?非功能需求有哪些以及在何处获取呢?

非功能需求通常分为可用性、可靠性、性能和可替换性需求(另请参阅概念:需求)。这些需求通常指定了符合任何法律和条例需求的需要。也可以是针对所用操作系统、平台环境、兼容性问题或任何适用的应用程序标准的设计约束。在通常情况下,您可以认为:不顾及多个设计选项的任何需求均应被视为设计约束。

许多非功能需求都适用于单个用例,并且是在该用例的特征中获取的。在该情况下,这些需求是在用例事件流中获取的,或是作为用例的特殊需求(请参阅指南:用例)。

示例:

在回收机器系统中,特定于“返还堆积物项”用例的某个非功能需求可以是:

机器必须能够以 95% 以上的可靠性识别堆积物项。

非功能需求通常适用于整个系统。这样的需求是在补充规约中获取的(请参阅工件:补充规约)。

示例:

在回收机器系统中,适用于整个系统的的某个非功能需求可以是:

机器一次将只允许一个用户。

什么/如何两难境况 回到页首

其中一件更困难的事情是了解如何确定在怎样具体的情况下应“启动和结束”用例。在何处启动特性和开始用例,以及在何处结束用例和开始设计?我们经常说,用例或软件需求应规定系统做“什么”,而不是“如何”做。请考虑下图:

在标题中描述的图。

一个人的终点是另一个人的起点。

根据您的背景,将使用另一个环境来决定您认为什么是“什么”和什么是“如何”。在确定是否应将某一具体情况排除在用例模型之外时,需要考虑这个问题。

具体和抽象用例 回到页首

具体用例和抽象用例之间存在差别。具体用例由参与者发起,并构成完整的事件流。 “完整”表示该用例的实例执行参与者所要求的整个操作。

抽象用例本身从不实例化。 抽象用例是包含在(请参阅指南:包含关系)、扩展到(请参阅指南:扩展关系)或泛化到(请参阅指南:用例泛化关系)其它用例中的。当发起某一具体用例时,即创建该用例的一个实例。该实例还展示由其关联的抽象用例指定的行为。因此,没有从抽象用例创建任何单独的实例。

两种用例之间的区别是很重要的,因为参与者在系统中将“看到”并发起的是具体用例。

通过用斜体撰写用例名称,来表明该用例是抽象用例。

示例:

在标题中描述的图。

用例“创建任务”包含在用例“注册订单”中。“创建任务”是抽象用例。

在库处理系统中,抽象用例“创建任务”是包含在用例“注册订单”中的。在发起“注册订单”时,即创建“注册订单”的一个实例,该实例除遵循“注册订单”的事件流外,还遵循所包含的用例“创建任务”中描述的事件流。“创建任务”从不自行执行,它始终作为“注册订单”(或包含它的任何其它用例)的一部分。因此,“创建任务”是抽象用例。

构造用例模型 回到页首

构造用例模型有三个主要原因:

  • 使用例更易理解。
  • 划分出许多用例中描述的通用行为。
  • 使用例模型更易维护。

但构造并不是您的当务之急。只有在更多地了解用例行为(而不是一句简短的描述)之后,您才知道如何构造用例。您应当至少已确立了用例事件流的分步概括,以确保您的决策是以充分准确地了解行为为基础的。

要构造用例,有三种关系。您将使用这些关系分解用例段,这些用例段可在其它用例中重用,或者是该用例的专门化或可选方案。表示修改的用例被称为附加用例。 被修改的用例被称为基本用例

  • 如果基本用例中有一部分表示某种功能,用例使用该功能时只根据结果,而不是根据用于生成结果的方法,则可以将该部分用例分解为附加用例。使用包含关系可将该附加用例显式插入基本用例中。 另请参阅指南:包含关系
  • 如果基本用例中有一部分是可选的,或不是了解用例主要用途所必需的,那么为了简化基本用例的结构,可以将该部分用例分解为附加用例。使用扩展关系可将该附加用例隐式插入基本用例中。另请参阅指南:扩展关系
  • 如果用例在行为、结构方面有共同点并具有类似的用途,则这些用例的共同部分可分解成为一个基本用例(父),该用例由附加用例(子)继承。 子用例可以在从父用例继承而来的结构中插入新的行为和修改现有的行为。另请参阅指南:用例泛化关系

可以使用参与者泛化关系显示参与者如何作为相互的专门化情况。另请参阅指南:参与者泛化关系

示例:

对订单管理系统考虑部分用例模型。

将普通客户与 Internet 客户相分离是有用的,因为它们的属性略有不同。但由于 Internet 客户展示客户的所有属性,因此可以说,Internet 客户是客户的一种专门化情况(以参与者泛化关系表示)。

此图中的具体用例是“电话订单”(由客户参与者发起)和“Internet 订单”(由 Internet 客户发起)。这些用例都是更通用的“下订单”用例(在本例中该用例是抽象用例)的变体。“请求目录”用例表示可选的行为分段,不属于“下订单”的主要用途。该用例已分解成为抽象用例,以简化“下订单”用例。“提供客户数据”用例表示已分解的行为分段,因为它是只影响“下订单”用例的单独功能。“提供客户数据”用例还可由其它用例重用。在本例中,“请求目录”和“提供客户数据”都是抽象用例。

在标题中描述的图。

该用例图显示订单管理系统的用例模型的一部分。

下表显示三种不同的用例关系之间的更详细比较结果:

问题 扩展 包含 泛化
关系的方向如何? 附加用例引用基本用例。 基本用例引用附加用例。 附加用例(子)引用基本用例(父)。
关系具有多重性吗? 是的,在附加用例这方面。 不可以。如果要多次包含同一个行为分段,则需要在基本用例中规定该情况。 不是。
关系有条件吗? 可以。 不可以。如果要表达有关包含关系的条件,则需要在基本用例中明确指出。 不是。
附加用例是抽象用例吗? 通常是,但不一定是。 可以。 通常不是,但有可能是。
基本用例是由附加用例修改的吗? 扩展关系隐式修改基本用例的行为。 包含关系显式修改基本用例的影响。 如果基本用例(父)已实例化,则不受子用例的影响。 要获得附加用例的影响,则必须实例化附加用例(子)。
基本用例必须完整而有意义吗? 可以。 与附加用例一起时,是的。 如果是抽象用例,则不是。
附加用例必须完整而有意义吗? 不是。 不是。 与基本用例(父)在一起时,是的。
附加用例可以访问基本用例的属性吗? 可以。 不可以。存在包含关系,但只能“看见”它自身。 可以,按正常继承机制。
基本用例可以访问附加用例的属性吗? 不可以。在缺少附加用例的情况下,基本用例必须格式正确。 不可以。基本用例只了解附加用例的影响。包含附加用例。 不可以。在缺少附加用例(子)的情况下,基本用例(父)必须格式正确。

为了更易理解而组织用例模型的另一种情况是将用例合到包中。可以将用例模型组织成具有层次结构的用例包,其中“叶子”是参与者或用例。另请参阅指南:用例包

在标题中描述的图。

该图显示用例模型层次结构。箭头表示可能的所有权。

用例始终与参与者相关吗? 回到页首

执行每个用例包括与一个或多个参与者通信。用例实例始终由要求系统执行操作的参与者启动。这表示每个用例均应与参与者有通信关联。使用该规则的原因是强制系统只提供用户需要的功能。 如果存在无人请求的用例,则表示用例模型或需求中有错误。

不过,该规则也有一些例外:

  • 如果用例是抽象用例(不单独实例化),则它的行为可能不包含与任何参与者交互。在该情况下,参与者与该抽象用例将不存在任何通信关联。
  • 如果父用例描述所有参与者通信,则泛化关系中的子用例不需要具有与其相关联的参与者。
  • 如果包含用例描述所有参与者通信,则包含关系中的基本用例不需要具有与其相关联的参与者。
  • 可根据日程表(例如,一周一次或一天一次)发起用例,这意味着系统时钟就是发起者。系统时钟是系统内置的,并且用例不由参与者发起,而由内部系统事件发起。如果在用例中未出现其它参与者交互,该用例将与参与者没有任何关联。 但为了明确起见,可以使用虚构的参与者“时间”显示如何在用例图中发起用例。

调查描述 回到页首

用例模型的调查描述应:

  • 声明系统的主要用例是哪些(构建系统的原因)。
  • 归纳有关系统的重要技术事件。
  • 指出系统的界限 - 系统不应执行的操作。
  • 归纳系统的环境,例如目标平台和现有软件。
  • 描述在系统中正常执行用例的任何顺序。
  • 指定不由用例模型处理的功能。

示例:

以下是回收机器的用例模型的调查描述样例:

该模型包含三个参与者和三个用例。主要用例是“回收物项”,它表示回收机器的主要用途。

起支持作用的用例是:

  • “打印日常报告”,允许操作员获取有关已回收物项的数量的报告。

  • “管理堆积物项”,允许操作员更改某种堆积物项的退款额,或者添加新的堆积物项类型。



Rational Unified Process   2003.06.15