用例图。结合用例是好还是坏的做法？答案

【问题标题】：Use Case Diagrams. Combining use cases good or bad practise?用例图。结合用例是好还是坏的做法？
【发布时间】：2018-01-23 17:57:40
【问题描述】：

如果可以将球员分配到团队，则用例将是分配球员，但如果球员也可以重新分配，那么另一个用例将是重新分配球员 , 被创建，其中可能包括 Assign Player？

或者，Assign Player 的单个用例是否就足够了，只需声明 Assign Player 将处理当前分配该玩家的事件吗？

【问题讨论】：

标签： uml use-case

【解决方案1】：

这取决于，一如既往。

但是，这可能值得使用<<includes>> 关系。重新分配玩家最终可能会更加复杂，最终您只需像往常一样Assign player。最终。但是，重新分配也可能是完全不同的事情，在这种情况下，您有两个不同且独立的用例。或者它是“不关心之前的分配”，在这种情况下你只有一个 UC Assign player。

编辑根据 Patrick87 的评论，我添加以下内容：UC 代表正在考虑的系统向其参与者之一提供的单一附加值。现在，附加值是独一无二的。发现这一点很困难，这就是为什么它需要了解自己工作的业务分析师。我自己尝试将 UC 视为一种独特的销售主张。在大多数情况下并不明显。但是，一旦您放置了正确的气泡，它就会感觉正确。不要开始将其分解为单个“功能”。这是一个不同的故事，它只能在所有 UC 都解决后才能开始。只有这样你才能开始在每个 UC 内部构建场景来描述操作方法。

我的一般建议是：阅读真正切中要害的 Bittner/Spence。

【讨论】：

+1 最好强调一下，这最终是一个平衡通用性和抽象性的决定 - 有利于将相似的用例分开 - 反对简单和简洁 - 有利于组合足够相似的用例.这与找到内聚和耦合的正确平衡基本上是相同的问题。我认为很多人会说这里没有正确的答案会出错，而他们的意思是有正确的答案，但比错误的答案更难找到。
@Patrick87 我做了最后的评论。我有一个绝妙的答案，但边距太窄，无法写下来（费马之后免费）;-)

【解决方案2】：

我不知道你们的球队在玩什么。可以是国际象棋之类的游戏，也可以是足球之类的运动。

因此，您的用例将告诉我们您正在构建的系统的总体目标：

是“踢足球”还是“下棋”？

只要您仍然描述系统的实际目标，您就可以将其分解为更细粒度的场景。

对于实际的功能分解，您应该使用其他图表类型，即活动图、状态图和可能的序列图。

【讨论】：

不。你是建议功能分析。这不是用例综合的全部意义！
不，我不是在建议功能分解。这在语法上是可行的，但就像我指出的那样，这不是一个好习惯。
“您可以将其分解为更细粒度的用例”如果您打算说其他的话，这绝对是错误的措辞。因为那描述了功能分解。这是错误的，错误的，错误的。
如果是“细粒度的场景”，那没问题，我会收回我的反对票。