正在生成/查看报告的有效用例吗？

如果我们将“取消订单”用例，用户可能必须在从订单列表中取消特定订单之前查看所有订单。正如我所看到的，“查看订单”是“取消订单”用例的前提条件。正在生成/查看报告的有效用例吗？

而且还可以有其他使用情况，如查看/生成列表或报告。这些在用例图中是否有效？

来源

2017-07-31 Harshakj89

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

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

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

最有可能你正面临着（注意用例的标题）：

用户目标的用例类似Accountant orders [payments/agents/etc.] report步骤System generates [payments/agents/etc.] report。（请记住，用户永远不会有意向的系统“，现在我想生成报告”，用户需要一些更高的目标报告）。
子功能用例System generates [payments/agents/etc.] report。

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

来源

2017-07-31 19:11:32 Vlad

通常情况下，用例显示了一个单一的附加价值，一个考虑中的系统返回给参与者。现在，什么是附加价值？有时候要看情况。特别是当你与CRUD打交道时，讨论往往会最终将头发分开。因此，对于“创建/读取/更新/删除X”显示单独的UCs还是将它们汇总到单个“管理X”中，最好取决于单个CRUD部件的重要性。如果观看是一个非常重要的部分，因为它大部分时间完成，并且CUD绝对是它的一部分，它们应该被拆分。如果你做所有CRUD操作的强度差不多一样，那么使用单一统一通信系统会更好。

来源

2017-07-31 11:15:18

生成报告 - 是的。更重要的是，不仅可以为不同类型的用户提供报告，还可以为SW的支持者区分报告。

但是别忘了，您还应该从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

在这里，你有这样的用例元素报表和频率使用等情况下使用的有效性。

来源

2017-07-31 13:26:22 Gangnus

正在生成/查看报告的有效用例吗？

回答

相关问题