用例模型

      用例模型

      用例模型最重要的作用是将系统行为传达给客户或最终用户。因此，模型必须易于理解。 编写用例依据主角的需求来进行。这样就确保该系统成为用户期望得到的系统。

一、用例模型如何演进

      主角和用例都是通过将客户需求及潜在用户当作重要的信息查找到的。

     在迭代开发环境中，您可以选择用例的子集以便在每个迭代中详细描述。另请参见活动：确定用例的优先级。

      主角和用例找到后，需要详细说明每个用例的事件流。这些说明指出系统与主角交互的方式以及在各个独立用例中系统执行的有关操作。

二、避免功能分解

      用例名的构造类似于“根据这一特定数据执行本操作”或“利用这一数据执行本功能”等。例如，“在 ATM 机上输入个人识别号”不应建模为 ATM 机的一个单独用例，原因是没有人会使用系统仅执行这一操作。用例是一个完整事件流，它可以产生对主角有价值的东西。

      为避免功能分解，您需要确保该用例模型有助于回答诸如以下的问题：

      系统的环境是什么？
      为什么要建立系统？
      用户在使用系统时希望获得什么？
      系统将给用户创造什么价值？

三、非功能性需求

      非功能性需求通常分为可用性需求、可靠性需求、性能需求以及可替换性需求（另请参阅概念：需求）。它们通常是指定需要符合任意法律法规要求的需求。它们也可以是由于所使用的操作系统、环境平台、兼容性或所采用的任何应用标准等问题产生的设计约束。通常，任何不允许有一个以上设计选项的需求都可以认为是一个设计约束。

      许多非功能性需求适用于一个单独的用例，并且可以在该用例的特征内获得这些需求。在这种情况下，这些需求可以在用例的事件流内获取，或者作为用例的一个特殊需求来获取（请参阅指南：用例）。

      示例：

      在回收机系统中，返还储存项用例的一个特定非功能性需求是：

      该机器识别储存项的可靠性必须高于 95%。

      通常，功能性需求适用于整个系统。此类需求可以在补充规约中获得（请参阅工件：补充规约）。

      示例：

      在回收机系统中，一个适用于整个系统的非功能性规约是：

      机器每次只允许一个用户使用。

四、内容与方式的两难局面

      学习如何确定用例应该在哪个明细级别上“开始和结束”是一件比较困难的事情。特征和用例开始于何处，而用例结束和设计开始又在什么地方？我们通常说，用例或软件需求应该规定系统做“什么”而不是“如何”做的问题。以下图为例：

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

      根据个人背景，您可以使用不同的环境来确定您对“什么”以及“如何”的理解。当决定是否应该将某个细节摈弃于用例模型之外时，需要仔细考虑这一问题。

五、具体用例和抽象用例

      具体用例和抽象用例之间存在一个区别。具体用例由主角来启动，并且构成一个完整的事件流。“完整”意味着该用例的一个实例执行由主角调用的全部操作。

      抽象用例本身从来不会被实例化。抽象用例包括在（请参阅指南：包含关系）其他用例中，扩展到（请参阅指南：扩展关系）或泛化关系（请参阅指南：用例泛化关系）其他用例。在启动一个具体用例时，也就创建了该用例的一个实例。这一实例还展示了由其关联关系的抽象用例指定的活动。因而，从抽象用例中无法创建单独的实例。

      由于主角在系统中“看见”和启动的是具体用例，因此这两种用例之间的区别非常重要。

      表明一个用例为抽象用例时，可以将其名称格式设置为斜体。

      示例：

“创建任务”用例包括在“注册单”用例中“创建任务”用例是一个抽象用例。

      在库房管理系统中，“创建任务”抽象用例包括在“注册单”用例中。启动“注册单”用例后，将创建一个注册单实例。该实例除了遵循注册单的事件流之外，它还遵循在所包含的用例“创建任务”内说明的事件流。“创建任务”本身从来不被执行，但始终作为“注册单”（或其他任何包含“创建任务”的用例）的一个部分。因此，“创建任务”是一个抽象用例。

六、构建用例模型

      构建用例模型有三个主要的原因：

      使用例更易于理解。
      将在许多用例内说明的公有行为分离出来。
      使用例模型更易于维护。

下表显示了三个不同用例关系之间更详细的比较：

七、用例是否始终和主角有关？

      每个用例的执行都包含与一个或多个主角的交流。用例实例始终通过主角要求系统执行某些任务来启动。这意味着每个用例需要与主角建立通信关联关系。此规则的理由是强迫系统只提供用户需要的功能，而不提供任何其他的东西。如果存在无人请求的用例，则表明在该用例模型或需求中存在错误。

      然而，此规则也有一些例外情况：

      如果用例是抽象的（不是可独立实例化的），则其行为可能不包括与主角的交互。这种情况下，将不存在任何从该抽象用例到主角的通信关联关系。
如果父用例说明了所有的主角通信，则泛化关系中的子用例不需要与主角相关联。
      如果包含用例说明了所有的主角通信，则包含关系中的基本用例不需要与主角相关联。
      一个用例可能按照时间表（例如，一星期一次或一天一次）来启动，这意味着系统时钟即为启动程序。由于用例不是由主角而是由内部系统事件启动的，因此系统时钟对于该系统而言是内在的。如果在该用例中没有发生其他的主角交互，则它与主角之间不存在任何关联关系。然而，为了清楚起见，您可以在用例图中使用一个虚构的主角“时间”来显示该用例是如何启动的。

八、调查说明

      用例模型的调查说明应该：

      声明哪些是系统的主要用例（系统建立的原因）。
      总结有关系统的重要技术实际情况。
      指出系统定界 - 系统将不执行的操作。
      概述系统的环境，例如目标平台和现有的软件。
      描述在该系统中正常执行用例的任意序列。
      详细说明用例模型未处理的功能。