多个玩家应该在Actor-Goal列表中共享相同的目标

Craig Larman表示，创建一个表格/网格形式的Actor [/ User] -Goal列表是在需求分析期间查找用例的好方法。（应用UML和模式 - P. 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? " ..

管理员可以做什么用户可以+更像是管理开发中的系统用户或为他们分配条目。

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

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

我的大脑告诉我，我可以通过重用/抽象来节省时间和精力，所以我很可能最终得到一个实现CRUD Entry行为的公共超类，其中Admin通过Manage Goals扩展功能（CRUD用户，分配，等等。）。

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

什么时候开始考虑抽象？我现在这样做会让事情过于复杂吗？我们应该像上面那样离开演员目标列表并将其作为“完整”神器进行检查吗？

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

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

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

1
投票

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

识别用例时的问题

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

一些受访的用户/业务专家将描述非常详细的一步一步目标（对应于系统功能），而其他人将描述相当高级别的目标用户目标。所以你需要第三列来识别每个用例的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>>和泛化关系几乎不应该使用，因为它们很容易使图表难以理解。

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