任务:查找参与者和用例
在此任务中需要确定参与者和用例,以支持要实施的需求。确定参与者和用例可明确地定义系统范围。
用途

此任务的目的是:

  • 定义系统的范围 - 系统要处理什么,系统外要处理什么。
  • 定义要与系统交互的人和物。
  • 概述系统的功能。
关系
角色主要: 其他: 辅助:
输入必需: 可选: 外部:
输出
主要描述

举行用例研讨会是用于查找参与者和用例的非常成功的技术。

步骤
查找参与者

查找参与者是定义系统用途中的最初步骤之一。系统必须与之交互的每一类外部现象都用一个参与者表示。要查找参与者,请提出以下问题:

  • 哪些用户组需要系统的帮助来执行任务?
  • 执行系统最明显的主要功能需要哪些用户组?
  • 要求哪些用户组执行次要功能,如系统维护和管理?
  • 系统会与外部硬件或软件系统交互吗?

满足这些类别的一个或多个条件的任何个人、小组或现象就可能是参与者。

要确定您的(人员)参与者是否恰当,您可以尝试指定两个或三个可以充当参与者的人员,然后看看您的参与者集是否足够满足他们的需要。关于参与者的构成的更多信息,请参阅指南:参与者

一开始可能很难找到最适合的参与者,而且也不太可能马上找到所有参与者,因为您尚未找到所有的用例。只有利用用例,您才可以对系统的环境有更深的了解,才能更好地了解环境如何与系统交互。前进到那一步的时候,您就可能希望修改原来的模型,因为一开始往往会设定太多参与者。在变更参与者时要小心;您引入的变更可能也会影响用例。请记住,对参与者作出的任何修改对于系统的接口和行为都是一次重要改变。如果您已经开发了业务用例模型和业务分析模型,则可以将它们用作确定主要参与者的来源。

命名并简要描述所找到的参与者

参与者的名称必须清楚地指示参与者的角色。请确保将来某个阶段不会有将一个参与者的名称与另一个参与者的名称混淆的风险。

用简单的描述定义每个参与者,其中包含参与者的职责范围以及参与者为什么需要系统。因为参与者代表系统外的事物,所以就没有必要进行详细描述。另请参阅指南:参与者中的“简述”一节。

查找用例

首先完成参与者的概述后,下一步就是查找系统的用例了。一开始的用例是非常简单的,毫无疑问您必须数次更改用例直到它们变得稳定为止。如果系统的远景或需求不充分,或者如果系统分析不明确,那么系统的功能也将不清晰。因此,您必须经常问自己是否已经找到了恰当的用例。而且,您必须准备好添加、删除、合并以及分开用例,直到获得最终版本。当详细描述用例后,您就会更好地了解用例了。

查找用例的最好的方法是考虑每个参与者对系统要求什么。请记住,系统只为用户而存在,因此它必须以用户的需求为基础。通过对系统作出的功能需求,您将可以辨认出参与者的许多需求。对于每个参与者(不管是人还是物),请向自己提出以下问题:

  • 参与者希望系统执行的主要任务是什么?
  • 参与者会在系统中创建、存储、更改、删除或读取数据吗?
  • 参与者需要向系统通知突发的外部变更吗?
  • 需要通知参与者系统中发生的某些情况吗?
  • 参与者将执行系统启动还是关闭?

这些问题的答案代表能识别候选用例的事件流。不是所有问题都能构成单独的用例;有些可能是同一用例的变体。并不是总是很容易区分哪个是变体,哪个是独立的、不同的用例。但是,当详细描述事件流程时,两者的区别就明显了。

除了需求,您的组织的企业模型(也称为业务模型)是确定用例的有价值的输入来源。企业模型描述信息系统如何合并到现有的运作中,从而使您更好地了解系统的环境。您还将发现需要在企业模型中定义的概念,因为它包含了企业的“业务对象”。如果遵循了 业务建模 工作流程,您就会有 业务用例模型 和 业务分析模型 用作输入。

系统可能有数个可能的用例模型。找到“最佳”模型的最好的方法是开发两个或三个模型,选择较喜欢的一个,然后进一步开发。 开发数个备用的模型还可以帮助您更好地了解系统。

概述第一个用例模型后,您应该验证用例模型是否针对了所有功能需求。仔细核对需求,确保所有的用例满足所有的需求。

关于用例是什么以及如何查找用例的更多信息,请参阅指南:用例模型指南:用例

指定并简单描述您找到的用例

每个用例都应该有名称,表明它与参与者的交互实现了什么。名称可能必须由几个字组成才能理解。任何两个用例的名称都不能相同。另请参阅指南:用例中的“名称”一节。

写一段用例的简单描述来定义每个用例。在写描述时,请参阅词汇表,如果需要的话请定义新的概念。另请参阅指南:用例中的“简述”一节。

概述事件流程

在此时,您还应该撰写用例的事件流程的第一稿。简单描述每个用例的事件流执行时的瞬间,但不要详细描写。后来指定用例的人(即使是您自己)会需要这个逐步描述的。先从概述事件的基本流程开始,只要您同意添加备用流程。

示例:

“回收机器系统”的“回收项”用例的事件流程的初始的逐步描述看起来可能是这样的:

  • 客户按“启动”按钮。
  • 客户插入寄存项。
  • 系统检查插入的寄存项的类型。
  • 系统增加当日收到的项的类型总量。
  • 客户按“收据”按钮。
  • 系统打印收据。
收集其他需求

系统的某些需求无法分配给具体的用例;请将它们集中在“补充规范”(请参阅工作产品:补充规范)。

描述参与者和用例如何交互

因为表明参与者如何与用例相关这一点很重要,所以在找到了用例后应该确定哪些参与者将与该用例交互。要做到这一点,您必须定义一个通信关联关系,它应该可以按照与信号传输相同的方向在参与者和用例之间导航。

信号传输通常双向进行。在这种情况下,就必须让通信关联关系可以双向导航。请最多为每个参与者-用例对定义一个通信关联关系。

您还应该简单描述您定义的每个通信关联关系。

关于通信关联关系的更多信息,请参阅工作产品指南:通信关联关系

打包用例和参与者

如果参与者或用例的数量太大,请将它们分为用例包以简化用例模型的维护。这么做还更容易掌握用例模型,并通过让开发人员对用例包或参与者包负责简化了用例模型中的职责的分配。

存在将用例封装在一起的一些备用方式(如果它们满足以下条件):

  • 与相同的参与者交互。
  • 彼此有包含关系或扩展关系。
  • 所有都是任选的,一起由系统提供或者根本没有提供。

还有其他方法;但是,为了保持模型的直观,在封装时使用清晰的策略很重要。

有关用例包的更多信息,请参阅工作产品指南:用例包

在图中展示用例模型

可以在用例模型图中说明用例和参与者之间的关系以及相关的用例之间的关系。这些图可能包含以下各项的任意一项:

  • 属于同一个用例包的参与者。
  • 参与者和与该参与者交互的所有用例。
  • 处理相同信息的用例。
  • 同一组参与者使用的用例。
  • 通常在一个序列中执行的用例。
  • 属于同一用例包的用例。
  • 最重要的用例。这种图可充当模型的摘要,并有可能包括在用例视图中。
  • 一起制定的用例(按同一增量)。

每个图应该属于用例模型中恰当的包。

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

展开用例模型调查

在此步骤中制定用例模型的调查描述。在调查中,请确保包含了以下内容:

  • 用户使用用例的典型顺序。
  • 用例模型不处理的功能。

关于用例模型调查描述的更多信息,请参阅指南:用例模型中调查描述一节。

评估结果

在这个阶段您应该检查用例模型来验证您的工作是否在正确的轨道上,而不是详细复审模型。您还应该在对用例模型进行处理时考虑用例模型的检查。对于查找内容的特定建议,请参阅核对表:用例模型

在这个阶段,开发团队外的人员(例如用户和客户)要核准用例模型,这一点很重要。因此,您必须让用户和客户参与到复审用例模型中来,然后才能完成该任务。在讨论中可以使用用例模型和在上一步中创建的用例图作为指导。

相关各方将必须确定:

  • 是否识别了所有必要的用例。
  • 是否识别了不必要的用例。
  • 每个用例的行为是否按照正确的顺序执行。
  • 每个用例的事件流程是否达到了这一阶段的最完整状态。
  • 用例模型的调查描述是否使用例模型可以看懂。
属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息