嘿伙计们！我一直在研究 UML，并试图设计一个问题的用例图。
假设我的应用程序包含以下内容：
两个要求： - 创建团队 - 创建球员
这是交易：用户可以创建一个团队，创建一个团队后，他可以为该团队创建球员（不是必需的）。但是在这个应用程序中有多个用户，一个用户可以创建一个团队，其他用户可以创建玩家。唯一的限制是创建球员必须已经存在于一个团队中。我研究了一下，结果有点困惑。如果我正确理解了用例图上的关系概念，我认为我应该有以下两个用例：
[用例-创建团队] <--------extends---- [用例-创建玩家]
我需要意见，这是正确的解决方案吗？还是我应该有两个不相关的用例？
在此先感谢，我很抱歉我的英语。
通常，您不需要在用例图中对依赖关系进行建模，例如“在执行 B 之前必须完成 A”。用例应该代表一组 Szenarios 以将它们分组为常见用例。
“扩展”依赖项用于指定一个比扩展的用例更特殊的用例。因此，如果您想表达创建球员是使用“扩展”创建团队的一种特殊形式就可以了。但是这与上述情况不符。
如果您想表达创建游戏总是意味着创建团队，您可以使用“包含”依赖项。这可能符合您的情况，但 imo 并不完全符合。
最后一个选项是绘制一个未指定的依赖关系（没有 << >> 标记），表示用例彼此之间有关系。
我的建议：在这种情况下不要使用任何依赖项。
顺便说一句，可以在这里找到一些更好的解释。
用例有一个共同的问题：关系。我们倾向于使用关系来描述用例的顺序。但这是一种误解。以下是《UML 用户指南》中关于用例和事件流的一些话（第 4 部分，第 17 章）：
You can specify a use cases's flow of events in a number of ways
[...] informal structured text
[...] formal structured text
[...] states machines
[...] activity diagrams
关键是，如果指南倾向于（隐含地）说不应该使用关系来指定事件流，它并没有说明用例关系应该用于什么。我认为这就是为什么用例是 UML 和 UP 的一个重点，但却是一个非常难以处理的工具的原因。
在您的模型中，您也许应该更改箭头和术语（简单的建议，您是分析师）：
如果您想强调约束，这应该在您的图表上表示，而不是作为操作顺序的表示（细微区别）。
扩展术语通常与泛化/专业化相关联。在我看来，这不是团队和用户创作之间的那种关系。该指南给出的示例如下（第 4 部分，第 18 章）：
也就是说，对用例的专业化建模大多数时候兴趣有限。但有时这是需要的，这取决于用例描述：如果两者相等，则不相等，否则不相等。有经验的程序员知道专业化并不意味着相等的断言。