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

如果一个玩家可以被分配到一个团队，那么用例将是分配玩家，但是如果一个玩家也可以被重新分配，那么会创建另一个用例，重新分配玩家，其中可能包括分配玩家

---

或者分配玩家的单一用例就足够了，只需说明假设分配玩家将处理当前分配的玩家的事件？

我不知道您的团队在玩什么。它可以是象棋之类的游戏，也可以是足球之类的运动

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

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

---

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

---

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

这取决于情况，一如既往

然而，使用

关系可能非常值得。重新分配一名球员最终可能会更加复杂，最终你只需像往常一样

分配球员。最终。但是同样，重新分配可能是一件完全不同的事情，在这种情况下，您有两个不同且独立的用例。或者它是一个“不关心以前的任务”，在这种情况下，您只有一个UC
分配玩家

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

我的一般建议是：阅读真正切中要害的Bittner/Spence。
不。您正在进行功能分析。这不是用例合成的全部内容！不，我不是建议功能分解。这在语法上是可能的，但正如我指出的，这不是好的实践。“你可以将其分解成更细粒度的用例”，如果你想说其他的话，这肯定是错误的措辞。因为它描述了功能分解。这是错误的，错误的，错误的。如果是“细粒度场景”那没关系，我收回我的反对票。+1强调这最终是一个平衡通用性和抽象性的决定，这有利于保持相似用例的独立性，而不是简单性和简洁性，这有利于组合足够相似的用例。这基本上与找到内聚和耦合的正确平衡是相同的问题。我认为很多人说这里没有正确的答案是错误的，而他们的意思是说这里有正确的答案，但比错误的答案更难找到。@Patrick87我说了最后一句话。我有一个很好的答案，但是页边太窄，写不下来（费马之后免费）；-）