问题描述
UML中是否允许在Administrator和Member之间生成如下箭头？
一方面，管理员是次要角色，因为他会根据成员的动作做出反应。
另一方面，他修改网站的内容，可以做会员能做的一切。
我对箭头的样式有疑问，因为它没有正确地直接显示遗产，这是一个问题吗？
解决方法
UML 怎么说？
主要 和次要 演员之间的区别不是 UML。 UML 规范（参见 UML 2.5.1 第 638 页）甚至没有定义当多个参与者与同一个用例相关联时的语义：
每个用例都指定了一个主体可以与一个或多个 Actor 协作执行的一些行为。 (...)
多个 Actor 参与 UseCase 的方式取决于手头的具体情况，本规范中未定义。例如，一个特定的用例可能需要两个单独的 Actors 的同时动作，或者它可能需要 Actors 的互补和连续动作。 (...)
Actor 为实体所扮演的角色建模，该实体与其关联的用例的主题进行交互。
在 UML 中，actor 是分类器，而分类器可能是其他同类分类器的特化。所以，是的，从 UML 的角度来看，一个演员可以是另一个演员的概括，而不管主要还是次要。
顺便说一下，泛化的符号是一个大的非填充三角形。小箭头无论是开口还是平头都不对；它甚至具有误导性。
是关于角色还是关于用户？
根据你的叙述：
Admin 是次要角色，因为他会根据成员的动作做出反应。另一方面，(...) 他可以做 Member 能做的一切。
这里的主要问题是要知道您是在谈论用户（即与系统交互的人）还是在谈论用户的角色。为了帮助您确定这一点，让我们用一个极端的情况来推理：假设您有一个智能机器人或一个外部系统来代替 Admin（例如，使用某种接口）；这个自动化的 Admin 还必须是 Member 吗？
- 如果是，
Admin的角色似乎自动暗示Member的角色。概括是可以的。 - 如果不是，则
Admin的角色实际上独立于Member的角色，并且恰好具有管理员角色的人类用户也具有Member角色。在这种情况下，您不应使用泛化。
用例价值以及主要与次要参与者
UML 对此持中立态度，但原则上用例应该对用户有价值，并帮助用户实现他/她的目标。没有这个价值原则，就没有初级用户和次级用户。这里以 Spence & Bittner 的定义为例：
主要参与者：(...) 主要参与者是系统为其构建的对象；他们是系统提供足够经济价值以保证其建设的人。
次要参与者：这些参与者是支持系统提供的用例的参与者以及支持系统本身的参与者。
我怀疑如果 Admin 生成引号（图中法语中的“devis”）和发票（法语中的“Facture”），则它可能不是次要角色，而是主要角色。
最后但并非最不重要的一点，请验证您对 include 和 extend 的使用。这似乎对应于系统的导航流或功能分解（或两者），而不是真正的用例。但我不会开发更多：为此，您需要翻译您的用例。
是否允许在主要和次要 Actor 之间进行泛化？
UML 标准中不存在主要和次要参与者，因此标准中没有任何内容说这是不允许的。
在您的情况下，您可以进行概括，因为它不会产生循环。
UML中是否允许在Administrator和Member之间生成如下箭头？
我不知道你图中的 Membre 和 Admin 之间的关系是什么，所以我宁愿说 no >
我对箭头的样式有疑问，因为它没有正确地直接显示遗产，这是一个问题吗？
是的，这是一个问题，因为人们不知道这种关系是什么/意味着什么
如果你想要一个概括的箭头是不同的：
您的图表中还有其他问题：
-
我不明白为什么 Admin 是次要角色，在您的图表中 Admin 始终是主要角色。但见下面的注释5
-
根据定义，Membre 不能注册或登录，所以 Membre 不能激活 UC s'inscrire 或 se连接器。像guest这样的演员可以登录或订阅
-
当 UC 包含其他内容时，意味着所包含的 UC 总是每次完成，则包含的 UC 被激活。您当然不希望 Member 在每次他/她想要编辑他/她的个人资料时登录，对于 Admin 每次删除帐户时也是如此，正如我所说的Member 和 Admin 参与者的定义 登录不能被他们激活。
-
对于很多人来说，“se connecter”（登录）没有足够的附加价值成为 UC
-
Membre 如何“咨询 l'historique de ses demandes / devis / facture”而 Membre 不能要求系统创建它们（使用 管理员作为次要演员）？显然，会员可以激活的某些 UC 丢失了