应用错误收集

Craig Larman表示，以某种表/网格的形式创建一个Actor [/ User] -Goal列表是在需求分析期间查找用例的好方法。（应用UML和模式 - 第69页ff）

一些简单的双列表应足以为此示例提供良好的概述;想象一下Actor-Goal List：

的 Actor 的 Goal

Admin Create User
" Read User
" .. (full CRUD)
" CRUD Entry
" Assign Entry (to User)
" ..

User Create Entry
" .. (full CRUD)
" CRUD himself?
" ..

管理员可以做用户可以更多地管理 S 系统的用户 u nder < strong> D 开发或分配条目。

管理员和用户显然正在分享一些目标（我们可以使用术语“用例”吗？）。

我不确定从这里开始改进这个Actor-Goal列表。

我的大脑告诉我，我可以通过重用/抽象来节省时间和精力，所以我很可能最终得到一个实现 CRUD Entry 行为的常见超类，管理员通过管理目标扩展功能（CRUD用户，分配等）。

但我知道这是一个设计而不是分析的问题我也知道我可以单独编写用例：我不必说明谁正确使用它，我只需要知道它是一个坚持给定合同[/ interface]的实体。

什么时候开始考虑抽象？我现在这样做是不是太复杂了？我们应该像上面那样离开Actor-Goal列表并将其作为“完整”神器进行检查吗？

由于Actor-Goal列表的经典目的是为我们的下一个Artifact提供一些快速概述 - 用例图 - 我们可以在这里开始转换吗？：

用例图使整个重用部分更加明显（至少对我而言）。现在采用冗余并在后期阶段（例如设计）处理它是否明智？

感谢您的意见！

编辑：我也不太确定用户CRUDing自己..但是让我们保持简单并坚持主要问题。

如您所述，在演员目标列表中识别候选用例是一个很好的主意。

识别用例时的问题

在现实生活中，在需求获取期间详细列出清单时，您会很快遇到一致性问题：

一些受访的用户/业务专家将描述非常详细的分步目标（对应于系统功能），而其他人将描述相当高级别的目标用户目标。因此，您需要第三列来标识每个用例的goal level。
术语和用户目标并不总是以同质的方式表达。因此可能需要交叉检查和重命名用例。例如，我有一个系统：
- 管理员声称manage authorizations，并且业务用户声称manage authorization。这个用例是一样的吗？否：看起来系统中的第一个maintained assignment of authorizations和第二个被授权给管理员decide on authorizations assignment and request them。
- 购买者解释说，对于采购订单，在付款之前，有人必须register a good receipt。仓库服务员解释说，他们在仓库manage stock movement。然而，后来看来，那些收益良好，问题和库存转移的运动。

因此，关于主要变体的评论的第四列可以帮助保持概述，并发现隐藏的共享潜力。

在共享/重用用例之前，通常需要进行大量的交叉检查和协调。重复使用太快可能会导致比预期更多的时间。

用例图表

我现在将非常具有挑衅性：一旦你拥有了与所有演员和用例的良好且一致的表格，你会从用例图中获得什么好处？

通常建议not to abuse use case diagrams for functional decomposition（请参阅also here）。因此，用例图将为您在列表中已有的内容添加更多内容。

此外，<<Include>>，<<Extend>>和泛化关系几乎不应使用，因为它们很容易使图表难以理解。

最后，抽象和重用是否真的发生在用例层面？这与系统外的演员有关吗？如果没有，它更多的是设计和实现细节。因此，我建议您在将要创建（或派生）实现用例的类模型中考虑这些。