我的用例图是否正确？关于用例泛化
Is my Use Case diagram correct? About Use Case generalization
编辑：
最终结果基于@qwerty_so
的建议
这是我在源代码管理系统中查看存储库的用例图。
此系统是项目管理系统的一部分。
系统类似于GitHub，用户可以select项目。
它会显示该项目的存储库列表。
用户可以单击存储库以查看其详细信息，例如文件树和存储库信息。
最后，用户还可以点击树中的文件来查看其内容。
我对用例泛化的使用是否正确？
以下用例是以前的版本，我了解到使用用例图来建模过程是不正确的（Seidl et al., 2015, p. 37）。
- Seidl, M., Huemer, C., Kappel, G., & Scholz, M. (2015)。 UML @ 课堂：面向对象建模简介。 Cham：施普林格国际出版社。
好吧，我问一个问题：你能抽象出附加值吗？唯一正确的情况称为特许经营。因此，您所做的是引入一个新的 abstract 气泡来将三个具体用例与您的参与者连接起来，而不是直接连接具体气泡。做什么的？ "View repository"的附加值在哪里？
对于 abstract actor 来说是相似的。没有必要制作 User abstract 因为它已经是抽象的了。所有演员都代表角色，而不是真实的事物。您可以只留下 abstract 关键字，它不会改变任何语义。
经常发生的事情（你就是这样）是人们开始功能分解而不是综合用例。用例是关于正在考虑的系统交付给其参与者的附加值。仅此而已。只需展示这些附加值即可。我知道这对技术人员来说很难，但请坚持下去。
一如既往，我建议阅读 Bittner/Spence 关于用例的内容。
在我看来，一个用例就是一个场景。由于我们必须为图中绘制的每个用例模型制作一个场景，因此一个用例必须具有特定的前置条件和特定的post-条件，但只有一个主要或基本流程。用例可能有很少的替代流程，这些流程在扩展关系中进行了说明。 while include 关系用于避免在main/basic几个用例流程中的几个场景中重复。
编辑：
最终结果基于@qwerty_so
的建议这是我在源代码管理系统中查看存储库的用例图。
此系统是项目管理系统的一部分。
系统类似于GitHub，用户可以select项目。
它会显示该项目的存储库列表。
用户可以单击存储库以查看其详细信息，例如文件树和存储库信息。
最后，用户还可以点击树中的文件来查看其内容。
我对用例泛化的使用是否正确？
以下用例是以前的版本，我了解到使用用例图来建模过程是不正确的（Seidl et al., 2015, p. 37）。
- Seidl, M., Huemer, C., Kappel, G., & Scholz, M. (2015)。 UML @ 课堂：面向对象建模简介。 Cham：施普林格国际出版社。
好吧，我问一个问题：你能抽象出附加值吗？唯一正确的情况称为特许经营。因此，您所做的是引入一个新的 abstract 气泡来将三个具体用例与您的参与者连接起来，而不是直接连接具体气泡。做什么的？ "View repository"的附加值在哪里？
对于 abstract actor 来说是相似的。没有必要制作 User abstract 因为它已经是抽象的了。所有演员都代表角色，而不是真实的事物。您可以只留下 abstract 关键字，它不会改变任何语义。
经常发生的事情（你就是这样）是人们开始功能分解而不是综合用例。用例是关于正在考虑的系统交付给其参与者的附加值。仅此而已。只需展示这些附加值即可。我知道这对技术人员来说很难，但请坚持下去。
一如既往，我建议阅读 Bittner/Spence 关于用例的内容。
在我看来，一个用例就是一个场景。由于我们必须为图中绘制的每个用例模型制作一个场景，因此一个用例必须具有特定的前置条件和特定的post-条件，但只有一个主要或基本流程。用例可能有很少的替代流程，这些流程在扩展关系中进行了说明。 while include 关系用于避免在main/basic几个用例流程中的几个场景中重复。