用户情景建模

您的团队可以创建模型，帮助其了解即将评估或开发的用户情景。如果问题相当复杂，则您的团队还可在开发期间与产品所有者进行日常讨论时使用模型。

例如，项目可能涉及一组您的团队不了解的概念。通过与产品所有者协作，您的团队可开发一个域类图来掌握这些概念及其相互关系。如果您的团队必须了解用户活动中的主要序列，则可创建一个活动图。

有关更多信息，请参见用户需求建模。

域模型：用户语言

域类图

域类图可演示与应用程序关联的概念和关系。与应用程序关联的每个人都可使用这些概念以实现更一致的理解。

上图中的示例并不是一个能以多种不同方式表示这些关系的软件解决方案的类图，而是提供一个可用来编写用户情景的词汇表。

客户选择一个可从中构造“订单”的“菜单”，然后客户通过从“菜单”中选择“菜单项”以在“订单”中创建“订单项”。

由于它是概念模型而非程序中的对象，因此，在将关系图用于此目的时，您通常不会向类分配操作。相反，您可使用活动图描述用户执行的操作。

有关更多信息，请参见UML 类图：准则。

活动图

您的团队可使用活动图来说明用户可执行的活动流，并演示每个点上的备选操作过程。

当团队创建测试时，可参考活动图并通过活动图为每条路径创建测试。

用户情景可能会在现有活动图中引入一条路径。例如，用户情景可能是“作为一名客户，我可选择保存订单供以后使用，而不是立即付款。” 当在要开发的冲刺 (sprint) 中考虑此情景时，可更新活动图以表示新功能。

如果您更新关系图以反映团队已实现的所有用户情景，则活动图可使用特定版本的应用程序来描述用户可遵循的一组完整路径。

有关更多信息，请参见 UML 活动图：准则。

使用模型揭示差距

通过避免在关系图不支持的对话中出现误解情况，您的团队可更好地理解用户要求。例如，关系图会清楚地区分订单上的项和菜单上的项。

创建模型可帮助您的团队提出原本可能在开发后期才会提出的问题。一些方法包括：

• 询问类图上的基数（例如，“某个菜单项是否可显示在多个菜单上？”）。

• 询问类图中的循环数（例如，“任何订单中的所有项目是否都来自同一个菜单？”）。

可在关系图上将这些类型的问题的答案添加为注释。

模型一致性

您的团队可通过确保模型和用户情景保持一致来解决歧义：

• 用户情景使用在模型中定义的术语，并与它定义的关系保持一致。如果模型定义菜单项，则情景不应使用术语“产品”来表示同一事物。如果类图表明某个菜单项只属于一个菜单，则情景不应提到在菜单之间共享某个项。

• 每个用户情景均描述活动图允许的一系列步骤。

• 用户情景或活动描述如何创建和销毁类图上的每个类和关系。例如，哪个用户情景创建了菜单项？何时销毁订单？

模型和产品积压工作

您的团队可标记模型和情节提要以演示每个用户情景将更改的部分，并可在模型上设置颜色并添加注释以帮助您规划开发。例如，您的团队可为活动图中的操作设置颜色，以指示已完成的操作和将在下次冲刺 (sprint) 时完成的操作。

有关更多信息，请参见用户需求建模。

模型和测试

您的团队可将域模型用作系统测试的基础，从而在测试和用户要求之间建立一种明确的关系。此关系可帮助您的团队快速准确地更新测试，并可帮助确保产品符合新的要求。

您的团队可将统一建模语言 (UML) 模型中的任何元素链接到任意工作项，例如测试。当模型的任何部分发生更改时，模型将帮助您的团队查找与之相关的测试。

使用域模型可帮助您创建测试：

• 至少创建一个涉及每个类型或关联的构造（例如，菜单项或订单项)的测试，以及至少一个涉及其构造的测试。

• 确保对活动图所描述的所有路径进行测试。

  说明
  测试还应涵盖通常不会在活动图中演示的异常路径。

• 使用域模型的词汇表定义测试。例如，您的测试应包含针对“选择菜单项”操作的测试，这将验证该操作是否会生成包含新“订单项”的“订单”。若要编写自动化测试，您可使用直接基于关系图的类和关系。

有关更多信息，请参见基于模型开发测试。