如果某个玩家可以被分配到一个团队，那么该用例将是分配玩家，但如果一个玩家也可以被重新分配，那么另一个用例重新分配玩家 ，可以创建，其中可能包括分配播放器？
或者分配播放器的单个用例是否足够并且只是声明分配播放器会处理当前分配的该播放器的事件？
答案 0 :(得分：2)
这一直依赖于此。
但是，这可能值得使用<<includes>>关系。重新分配一个玩家可能最终会更加复杂，最终你会像往常一样只Assign player。最终。但同样重新分配可能是完全不同的事情，在这种情况下，您有两个不同的独立用例。或者它是“不关心以前的任务”，在这种情况下，你只有一个UC Assign player。
编辑根据Patrick87的评论，我添加以下内容：UC表示正在考虑的系统向其中一个演员提供的单个附加值。现在，附加价值是独一无二的。发现这很难，这就是为什么它需要知道自己工作的业务分析师。我亲自尝试将UC视为独特的销售主张。在大多数情况下，这并不明显。但是，一旦你放置了正确的泡沫，感觉就合适了。不要开始将其分解为单个“函数”。这是一个不同的故事，它只能在所有公共汽车落户后才能开始。只有这样，您才能在每个UC内部开始构建场景来描述操作方法。
我的一般建议：阅读Bittner / Spence，他们真的很明白。
答案 1 :(得分：1)
我不知道你的球队在打什么。它可能像国际象棋这样的游戏，或者像足球这样的运动。
因此，您的用例将告诉我们您正在构建的系统的总体目标：
是“踢足球比赛”还是“下棋”？
只要您仍然描述系统的实际目标，您就可以将其分解为更细粒度的场景。
对于实际的功能分解，您应该使用其他图表类型，即活动图，状态图和可能的序列图。