关于 UML class 图中关联 classes 的问题
Question about association classes in UML class diagram
所以我需要对我们有一群人是联盟成员的情况进行建模。您可以是联盟的活跃成员或非活跃成员。如果您不活跃,则您不是任何俱乐部的会员。如果您是一名活跃会员,那么您就是一个俱乐部的主要会员,并且您可以拥有任意数量的俱乐部内部会员。
我当前的 UML 模型没有强制要求每个活跃玩家都应该只有一个主要成员,所以我想知道如何解决这个问题。我个人认为我可以通过在 'Main' 和 'Active' 之间绘制一个规则关联来解决这个问题,但我真的不知道这是否被允许或者是否有任何其他解决方案来解决我的问题。
Main
是 UML 关联 Class 的一个实例,因为它的超类是 Membership
。这意味着 Main
可以专门化关联(这需要另一条虚线)并且可以子集一个或两个关联端。当你说
isMemberOf { subsets isMemberOf } 1
在新协会线的左端,这意味着每位活跃玩家都必须参加恰好一个 Main
会员资格,以及任意数量的其他类型的会员资格。
为了清楚起见,您应该考虑重命名子集和/或子集属性,但 UML 不需要它。例如,
isMainMemberOf { subsets isMemberOf } 1
(虽然这个名字暗示一个人是一个俱乐部的 Main
会员,这是不完全正确的。)
虽然不一定是错误的,但您可能过度使用了 Generalization
泛化是一种是一种关系,如果你说
我可以遵循
- 一个
Player
是一个Person
但我很难理解
- 一个
Active
一个Player
一个Person
将 Active
或 NotActive
建模为 Player
的 Status
的值似乎更有意义。
下面是表达这些要求的最基本模型的样子。
一些建议
Player
变成Person扮演的角色,不是同一个对象。因此,如果 Player
被删除,Person
对象可以继续存在。在另一个方向上,我使用组合对其进行了建模。所以如果一个 Person
被删除,它的 Player
角色也被删除,而且它是 Memberships
- 使用Composition over Inheritance是众所周知的软件工程原理
- 我使用自然语言的约束来表达活跃成员应该有一个主要成员的要求。如果您喜欢(或需要)它更正式,您也可以使用 OCL。另一种选择可能是为主要成员添加另一个具有
[0..1]
多重性的关联。您可以在其中添加一个约束,说明它仅适用于 属性 IsMainMembership = True
的会员资格,并且对于 Status = "Active"
的玩家来说是强制性的
- 为了确保
Player.Status
和主要会员的存在之间的一致性,您还可以选择使 Player.Status
派生 。然后,您可以通过检查是否存在与主要会员资格的关联来导出状态。
- 在大多数实现中,实例无法更改 classes。因此,如果您的
Active
要成为 NotActive
,您将必须删除 Active
对象并创建一个新的 NotActive
对象。将 Active/Notactive 作为状态将允许您使用相同的对象并简单地更改它的状态。 如何可以使用状态机对这些状态进行建模。
- 大多数 OO 语言也不支持多重继承,因此在选择泛化时应谨慎。如果您选择让 Player 成为 Person,如果您以后需要不是 Persons 的玩家,例如计算机、组织或团队,您可能会遇到麻烦。 UML 确实支持多重继承,但在我迄今为止工作过的大多数组织中,指南禁止使用多重继承。
- 在这种情况下,我什至取消了 association-class 以支持具有常规关联的常规 class。关联 classes 使您的模型更难理解,因为 UML 不太精通
我并不是说这个模型比您的模型更好或更差,但值得考虑复杂性范围的另一端,以及您希望模型最终达到的位置。
所以我需要对我们有一群人是联盟成员的情况进行建模。您可以是联盟的活跃成员或非活跃成员。如果您不活跃,则您不是任何俱乐部的会员。如果您是一名活跃会员,那么您就是一个俱乐部的主要会员,并且您可以拥有任意数量的俱乐部内部会员。
我当前的 UML 模型没有强制要求每个活跃玩家都应该只有一个主要成员,所以我想知道如何解决这个问题。我个人认为我可以通过在 'Main' 和 'Active' 之间绘制一个规则关联来解决这个问题,但我真的不知道这是否被允许或者是否有任何其他解决方案来解决我的问题。
Main
是 UML 关联 Class 的一个实例,因为它的超类是 Membership
。这意味着 Main
可以专门化关联(这需要另一条虚线)并且可以子集一个或两个关联端。当你说
isMemberOf { subsets isMemberOf } 1
在新协会线的左端,这意味着每位活跃玩家都必须参加恰好一个 Main
会员资格,以及任意数量的其他类型的会员资格。
为了清楚起见,您应该考虑重命名子集和/或子集属性,但 UML 不需要它。例如,
isMainMemberOf { subsets isMemberOf } 1
(虽然这个名字暗示一个人是一个俱乐部的 Main
会员,这是不完全正确的。)
虽然不一定是错误的,但您可能过度使用了 Generalization
泛化是一种是一种关系,如果你说
我可以遵循- 一个
Player
是一个Person
但我很难理解
- 一个
Active
一个Player
一个Person
将 Active
或 NotActive
建模为 Player
的 Status
的值似乎更有意义。
下面是表达这些要求的最基本模型的样子。
一些建议
Player
变成Person扮演的角色,不是同一个对象。因此,如果Player
被删除,Person
对象可以继续存在。在另一个方向上,我使用组合对其进行了建模。所以如果一个Person
被删除,它的Player
角色也被删除,而且它是Memberships
- 使用Composition over Inheritance是众所周知的软件工程原理
- 我使用自然语言的约束来表达活跃成员应该有一个主要成员的要求。如果您喜欢(或需要)它更正式,您也可以使用 OCL。另一种选择可能是为主要成员添加另一个具有
[0..1]
多重性的关联。您可以在其中添加一个约束,说明它仅适用于 属性IsMainMembership = True
的会员资格,并且对于Status = "Active"
的玩家来说是强制性的
- 为了确保
Player.Status
和主要会员的存在之间的一致性,您还可以选择使Player.Status
派生 。然后,您可以通过检查是否存在与主要会员资格的关联来导出状态。 - 在大多数实现中,实例无法更改 classes。因此,如果您的
Active
要成为NotActive
,您将必须删除Active
对象并创建一个新的NotActive
对象。将 Active/Notactive 作为状态将允许您使用相同的对象并简单地更改它的状态。 如何可以使用状态机对这些状态进行建模。 - 大多数 OO 语言也不支持多重继承,因此在选择泛化时应谨慎。如果您选择让 Player 成为 Person,如果您以后需要不是 Persons 的玩家,例如计算机、组织或团队,您可能会遇到麻烦。 UML 确实支持多重继承,但在我迄今为止工作过的大多数组织中,指南禁止使用多重继承。
- 在这种情况下,我什至取消了 association-class 以支持具有常规关联的常规 class。关联 classes 使您的模型更难理解,因为 UML 不太精通
我并不是说这个模型比您的模型更好或更差,但值得考虑复杂性范围的另一端,以及您希望模型最终达到的位置。