编辑：
最终结果基于@qwerty_so给出的建议
这是我在源代码管理系统中查看存储库的用例图。
该系统是项目管理系统的一部分。
系统类似于 GitHub，用户可以选择项目。
它将显示项目的存储库列表。
用户可以单击存储库以查看其详细信息，例如文件树和存储库信息。
最后，用户还可以单击树中的文件来查看其内容。
我对用例泛化的使用是否正确？
下面的用例是以前的版本，我了解到使用用例图对流程建模是不正确的（Seidl et al., 2015, p. 37）。
好吧，让我问一个问题：你能抽象出附加值吗？唯一正确的情况称为特许经营权。所以你所做的是引入一个新的抽象气泡来连接三个具体的用例和你的参与者，而不是直接连接具体的气泡。做什么的？“查看存储库”的附加价值在哪里？
对于抽象 演员来说也是类似的。不需要User 抽象，因为它已经抽象了。所有演员都表示角色，而不是真实的事物。您可以离开那个抽象关键字，它不会改变任何语义。
经常发生的事情（你正在这样做）是人们开始功能分解而不是综合用例。用例是关于正在考虑的系统为其参与者提供的附加值。就是这样。只需呈现这些附加值。我知道这对技术人员来说很难，但请坚持下去。
与往常一样，我建议阅读 Bittner/Spence 关于用例的信息。
在我看来，一个用例就是一个场景。由于我们必须为图中绘制的每个用例模型制作一个场景，因此一个用例必须具有特定的前置条件和特定的后置条件，但只有一个主要或基本流程。用例可能有很少的替代流程，在扩展关系中说明。而包含关系用于避免在多个用例的主要/基本流程中的多个场景中重复。