inheritance - 关于UML类图中关联类的问题

Question

所以我需要对我们有一群人是联盟成员的情况进行建模。您可以是联盟的活跃成员或非活跃成员。如果您不活跃，则您不是任何俱乐部的成员(member)。如果您是活跃成员(member)，那么您就是一个俱乐部的主要成员(member)，并且您可以拥有任意数量的俱乐部内部成员(member)。

我当前的 UML 模型并没有强制每个活跃玩家都应该有一个主要成员，所以我想知道如何解决这个问题。我个人认为我可以通过在“主要”和“事件”之间建立定期关联来解决这个问题，但我真的不知道这是否被允许或者我的问题是否有其他解决方案。

Answer 1

虽然不一定是错的，但您可能过度使用了Generalization

泛化是一种是一种关系，如果你说我可以遵循

• 一个玩家是一个人

但是我很难理解

• Active 是 Player 是 Person

将 Active 或 NotActive 建模为 Player 的 Status 值似乎更有意义.

下面是表达这些要求的最基本模型的样子。

一些提示

• Player 变成Person扮演的角色，不是同一个对象。因此，如果 Player 被删除，Person 对象可以继续存在。在另一个方向上，我使用组合对其进行了建模。因此，如果一个 Person 被删除，它的 Player 角色也会被删除，它也是 Memberships
• 使用Composition over Inheritance是一个已知的软件工程原则
• 我使用自然语言的约束来表达活跃成员应该有一个主要成员资格的要求。如果您喜欢(或需要)它更正式，您也可以使用 OCL。另一种选择可能是为主要成员添加另一个具有 [0..1] 多重性的关联。您可以在此处添加一个约束，说明它仅适用于具有属性 IsMainMembership = True 的成员(member)资格，并且对于具有 Status = "Active"
的玩家来说是强制性的
• 为了确保 Player.Status 和主要成员(member)的存在之间的一致性，您还可以选择使 Player.Status derived。然后，您可以通过检查是否存在与主要成员(member)资格的关联来得出状态。
• 在大多数实现中，一个实例不能改变类。因此，如果您的 Active 变为 NotActive，您将不得不删除 Active 对象并创建一个新的 NotActive 对象.将 Active/Notactive 作为状态将允许您使用相同的对象并简单地更改它的状态。 如何可以使用状态机对这些状态进行建模。
• 大多数 OO 语言也不支持多重继承，因此在选择泛化时应谨慎。如果您选择让 Player 成为 Person，如果您以后需要不是 Persons 的玩家，例如计算机、组织或团队，您可能会遇到麻烦。 UML 确实支持多重继承，但在我迄今为止工作过的大多数组织中，指南禁止使用多重继承。
• 在这种情况下，我什至取消了关联类，转而使用具有常规关联的常规类。关联类使您的模型对于 UML 不太了解的人更难理解

我并不是说这个模型比您的模型更好或更差，但值得考虑复杂性范围的另一端，以及您希望模型最终达到的位置。