Uml 多个参与者是否应该在参与者目标列表中共享相同的目标

CraigLarman指出，在需求分析期间，以表格/网格的形式创建参与者[/User]-目标列表是一种很好的发现用例的技术。（应用UML和模式——第69页及其后）

一些简单的两列表应该足以为这个例子提供一个很好的概述；想象一下下面的演员目标列表：

演员

目标

管理员

创建用户

“

阅读用户

“

。。（全积垢）

“

积垢条目

“

分配条目（给用户）

“

。

用户

创建条目

“

。。（全积垢）

“

克鲁德自己？

“

管理员可以做用户可以做的事情，更像是管理S系统underD开发的用户或为他们分配条目

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


我真的不确定在完善这个演员目标列表方面该从这里走到哪里

我的大脑告诉我，我可以通过这里的重用/抽象来节省时间和精力，因此我很可能最终会得到一个实现CRUD条目行为的公共超类，其中管理员通过管理目标（CRUD用户、分配等）来扩展功能。

但我知道这是一个设计问题，而不是分析问题。

我还知道，我可以单独编写这个用例：我不必说明到底是谁在使用它，我只需要知道它是一个遵守给定合同的实体[/interface]



什么时候开始考虑抽象？

我现在这样做是不是让事情变得过于复杂了？

我们是否应该像上面那样留下演员目标列表，并将其作为“完整”工件进行检查

由于参与者目标列表的经典目的是为我们的下一个工件（用例图）提供一些快速概述，我们可以从这里开始转换吗

用例图使整个重用部分更加可见（至少对我而言）。是否建议立即采用冗余，并在后期阶段（如设计）处理冗余？



感谢您的意见



编辑：另外，我也不太确定用户是否会自我欺骗。。但是让我们保持简单并坚持主要问题。
如您所述，在参与者目标列表中确定候选用例是一个很好的主意

确定用例时的问题

在现实生活中，在需求获取过程中，在详细描述列表时，您会很快遇到一致性问题：


一些接受采访的用户/业务专家将描述非常详细的逐步目标（对应于系统功能），而另一些将描述相当高级别的目标用户目标。因此，您需要第三列来识别每个用例的特性

术语和用户目标并不总是以一致的方式表达。因此，可能需要交叉检查和重命名用例。例如，我有一个系统，其中：


一名管理员声称管理授权

，一名业务用户声称管理授权。它是相同的用例吗？否：第一个

似乎维护了系统中的授权分配

，第二个被授权

决定授权分配并向管理员请求授权
一位采购员解释说，对于采购订单，在支付发票之前，必须有人
登记好收据。仓库职员解释说，他们在仓库管理库存移动。不过，后者似乎认为，那些收益良好、发行良好和股票转让良好的流动


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

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

用例图绘制

我现在将非常激动人心：一旦您有了一个包含所有参与者和用例的良好且一致的表，您期望从用例图中得到什么好处

通常建议使用（请参阅）。因此，用例图将为列表中已有的内容添加更多内容

此外，
、
和泛化关系应该很少使用，因为它们往往会很快使图表难以理解

最后，抽象和重用真的发生在用例级别吗？这与系统外的参与者有关吗？如果不是，更多的是设计和实现细节。因此，我建议在类模型中考虑这些，您将创建（或派生）以实现用例。p>