Uml 我的用例图正确吗？关于用例泛化

编辑：

最终结果基于以下人员给出的建议：

---

这是我在源代码管理系统中查看存储库的用例图

该系统是项目管理系统的一部分

该系统类似于GitHub，用户可以选择项目

它将显示项目的存储库列表

用户可以单击存储库以查看其详细信息，如文件树和存储库信息

最后，用户还可以单击树中的文件以查看其内容

我使用的用例概括正确吗？

下面的用例是以前的版本，我了解到使用用例图对流程建模是不正确的（Seidl等人，2015年，第37页）

Seidl，M.，Huemer，C.，Kappel，G.，和Scholz，M.（2015）。UML@教室：面向对象建模简介。湛：斯普林格国际出版公司

---

好吧，让我问一个问题：你能抽象出附加值吗？唯一正确的情况是特许经营。因此，您所做的是引入一个新的抽象气泡，将三个具体用例与您的参与者连接起来，而不是直接将具体气泡连接起来。为何“查看存储库”的附加值在哪里

对于抽象演员来说，这是相似的。没有必要将

User

抽象化，因为它已经是抽象的了。所有演员都代表角色，而不是真实的事物。你可以把那个抽象关键词放在一边，它不会改变任何语义

经常发生的事情（你正在这样做）是人们开始功能分解，而不是合成用例。用例是考虑中的系统向其参与者提供的附加值。就这样。只需呈现这些附加值。我知道这对技术人员来说很难，但请坚持下去

---

---

像往常一样，我建议阅读关于用例的Bittner/Spence。

在我看来，一个用例就是一个场景。因为我们必须为图中绘制的每个用例模型创建一个场景，所以一个用例必须有特定的前置条件和特定的后置条件，但只有一个主流程或基本流程。用例可能有很少的可选流，如extends关系中所示。而include关系用于避免在几个用例的主/基本流中的几个场景中重复。

我想得太多了，解决方案就是这么简单。关于函数分解，您也说得对，我已经像为entername创建bubble那样做了。谢谢你的帮助。