Uml 生成/查看报告是有效的用例吗？

如果我们使用“取消订单”用例，用户可能必须先查看所有订单，然后才能从订单列表中取消特定订单。如我所见，“查看订单”是“取消订单”用例的先决条件

---

还有其他用例，如查看/生成列表或报告。这些在用例图中有效吗？

通常，用例显示的是一个正在考虑的系统返回给参与者的单一附加值。现在，什么是附加值？有时要看情况而定。特别是当你处理积垢时，讨论往往最终会分歧。因此，最好是为“创建/读取/更新/删除X”显示单独的UCs，还是将它们汇总到一个“管理X”中，这完全取决于单个CRUD部分的重要性。如果观看是一个非常重要的部分，因为大部分时间都在观看，而反刍绝对是其中的一部分，那么它们应该分开。当您以或多或少相同的强度执行所有CRUD操作时，最好使用单个UC。

生成报告-是。更重要的是，它是一个非常好的实践，不仅为不同类型的用户区分报告，而且也为软件的支持者区分报告

但别忘了，您还应该告诉高层报告，这些报告可以按需完成，也可以自动完成，并且包含一些集中的信息，从DB生成SQL报告的角度来看。您可以为不同的抽象级别编写用例。第一个报告适用于面向人的用例，而DB报告适用于更具体的用例。最后的这些不太常用

因此，我们可以想象一张桌子：

                           high level                  low level
Users                      useful/usual                The reports themselves are not useful
Support/lisense team       useful/not so usual         useful/usual

在这里，您可以看到诸如报告之类的用例元素的有用性，以及此类用例的使用频率

用户可能必须在取消之前查看所有订单。。。“查看订单”是“取消订单”用例的先决条件

在你的情况下，这不是一个先决条件。这是“取消订单”用户目标用例中的一个步骤。这个步骤可以扩展（或者根据您所描述的级别保持为单个步骤）为扩展（如果用户可以查看）或包含（如果用户必须查看）“查看顺序”用例

其他用例，如查看/生成列表或报告。这些在用例图中有效吗

您最可能面临的问题（请注意用例的标题）：

• 用户目标用例，如

  会计订单[payments/agents/etc.]报告

  使用步骤

  系统生成[payments/agents/etc.]报告

  。（请记住，用户来到系统时从来没有“现在我想生成一个报告”，用户需要报告以实现更高的目标）
• 子功能用例

  系统生成[付款/代理/等]报告

如果您的图表都是关于用户目标用例和层次结构中更高的用例，那么不要牺牲子功能用例的可读性。更好地为特定的业务流程或应用程序域创建单独的图表