【发布时间】：2017-07-31 10:21:43
【问题描述】：
如果我们采用“取消订单”用例，用户可能必须先查看所有订单，然后才能从订单列表中取消特定订单。如我所见，“查看订单”是“取消订单”用例的先决条件。
还有其他用例，例如查看/生成列表或报告。这些在用例图中有效吗？
【问题讨论】：
【发布时间】：2017-07-31 10:21:43
【问题描述】：
用户可能必须在取消之前查看所有订单...“查看订单”是“取消订单”用例的先决条件。
在您的情况下，这不是先决条件。这是“取消订单”用户目标用例中的一个步骤。并且此步骤可以扩展（或根据您描述的级别保留为单个步骤）扩展（如果用户可能查看）或包含（如果用户必须查看) “查看订单”用例。
其他用例，例如查看/生成列表或报告。这些在用例图中有效吗？
您很可能面临（注意用例的标题）：
- 用户目标用例，如
Accountant orders [payments/agents/etc.] report，步骤为System generates [payments/agents/etc.] report。 （请记住，用户从来没有故意进入系统“现在我想生成报告”，用户需要报告来实现更高的目标）。 - 子函数用例
System generates [payments/agents/etc.] report。
如果您的图表完全是关于用户目标用例和层次结构中更高的用例 - 不要牺牲子功能的可读性。更好地为特定的业务流程或应用程序领域创建单独的图表。
【讨论】：
通常，一个用例显示了一个正在考虑的系统返回给参与者的单个附加值。现在，什么是附加值？有时这取决于。尤其是当您处理 CRUD 时，讨论往往会最终导致分歧。因此，是否更好地为“创建/读取/更新/删除 X”显示单独的 UC 或将它们总结为单个“管理 X”绝对取决于单个 CRUD 部分的重要性。如果观看是一个非常重要的部分，因为它大部分时间都完成了，而且 CUD 肯定是其中的一部分，那么它们应该被拆分。如果您以或多或少相同的强度执行所有 CRUD 操作，则最好使用单个 UC。
【讨论】：
生成报告 - 是的。更重要的是，区分报告不仅适用于不同类型的用户，而且适用于 SW 的支持者，也是一种非常好的做法。
但不要忘记，您还应该在高级别报告报告，这些报告可以按需或自动完成，并且包含一些集中信息，从数据库生成 SQL 报告的意义上的报告。您可以为不同的抽象级别编写用例。第一份报告适用于以人为本的用例，而数据库报告适用于更具体的用例。最后这些不常用。
所以，我们可以想象一个表格：
high level low level
Users useful/usual The reports themselves are not useful
Support/lisense team useful/not so usual useful/usual
在这里您可以了解报告等用例元素的用处以及这些用例的使用频率。
【讨论】：