如何在UML中建模协变关联类？ 简言之

我想建立两个类之间的协变关联模型，每个类都可以被专门化。我需要显示相关关联类的专门化。但我想避免我的模型可能意味着存在冗余关联，即泛化之间的关联和专门化之间的关联

问题的逐步解释 我在UML类图中有一个人和合同之间的许多关联。一个人可以参与多个合同，反之，一个合同可以涉及多个人。每个相关人员都在合同中扮演一个角色。一个人甚至可以多次参与同一合同中的不同角色：

合同专业有很多种。让我们来看看FuffyFuffy合同，其中有几个人决定创建一个公司。人也可以是专门的。这里我用了一种特殊的人叫方正。实际上，我更喜欢构图而不是继承，而创始人将是一名装饰师。但为了简化起见，我稍后将省略此细节：

通过UML专业化，我知道创始人和公司基金会契约继承了多对多关系。但在与我的法律实践用户讨论后，很快就发现，创始人在公司基金合同中的角色也需要专门化，例如考虑到公司持有的股份。在我的类图中对这种协方差建模似乎很简单：

乍一看，这种模式可以代表此类合同的法律复杂性：似乎很明显，非创始人的其他人可以以正常角色参与合同，例如注册公司的律师或律师

由于关联类ShareHolderRole是角色关联类的一个专门化，我希望能够澄清，它是合同和个人之间以及公司基金会合同和创始人之间的同一个关联

---

然而，我担心我遗漏了一些东西，并且严格解释UML将意味着有两个不同的冗余关联。我该如何准确地模拟只有一个关联，但有一个协变关联类的事实？

您的图表中有一个使用Founders的输入错误

我希望澄清的是，合同与人、公司基金会合同与创始人之间是同一种联系

对我来说不是，否则这意味着不可能将这种联系作为一种额外的联系，但这当然是可能的

如果要明确说明，请添加关联端点的名称，并使用相同的两个名称：

您还可以明确地说，每个关联端重新定义了另一个关联端，从而允许使用不同的名称：

当然，你也可以像我在《源头》中那样做：

---

如果蓝色的约束涉及关系类而不仅仅是对应的类，并且绿色的约束不是强制性的，因为它们可以从蓝色的约束推断出来

我希望澄清的是，合同与人、公司基金会合同与创始人之间是同一种联系

对我来说不是，否则这意味着不可能将这种联系作为一种额外的联系，但这当然是可能的

如果要明确说明，请添加关联端点的名称，并使用相同的两个名称：

您还可以明确地说，每个关联端重新定义了另一个关联端，从而允许使用不同的名称：

当然，你也可以像我在《源头》中那样做：

---

如果蓝色的约束涉及关系类而不仅仅是对应的类，并且绿色的约束不是强制性的，因为它们可以从蓝色的约束推断出来，一个人甚至可以多次参与同一合同中的不同角色-角色不应该是二元的，但是Person、Contract和RoleType之间的三元关联。

一个人甚至可以多次参与同一个Contract中的不同角色-角色不应该是二元的，而是Person、Contract和RoleType之间的三元关联。

专门的关联类不限于只连接重新定义的属性。所以，这个关联类连接founder和foundationContract是完全可能的，这些属性与person和contract无关，只是它们的类型是专门化。如果你确实重新定义了它们，那么这些新的属性甚至可以具有相同的名称，取代了旧的属性，使得创建者不可能有非基础契约。 现在，一个基础合同仍然是一个合同。因此，一个人所涉及的合同清单 d in，应该包含它们。这可以通过子集来实现。只需定义一个foundationContract{subsets contract}和创始人{subsets person}。我想，这才是你真正想要的

---

由于属性是按默认设置的集合，集合表示不包含重复项，因此同一个人不可能在同一合同中扮演多个角色。如果希望实现这一点，则必须为属性设置属性{ununique}。

专用关联类不限于仅连接重新定义的属性。所以，这个关联类连接founder和foundationContract是完全可能的，这些属性与person和contract无关，只是它们的类型是专门化。如果你确实重新定义了它们，那么这些新的属性甚至可以具有相同的名称，取代了旧的属性，使得创建者不可能有非基础契约。 现在，一个基础合同仍然是一个合同。因此，一个人参与的合同清单应该包含这些合同。这可以通过子集来实现。只需定义一个foundationContract{subsets contract}和创始人{subsets person}。我想，这才是你真正想要的

由于属性是按默认设置的集合，集合表示不包含重复项，因此同一个人不可能在同一合同中扮演多个角色。如果你想做到这一点，你必须为属性设置属性{ununique}。

初步评论：首先，我想比Bruno和Axel更了解他们各自的答案，这让我走上了正确的道路。尽管如此，根据他们的指示进一步挖掘，我还是偶然发现了一个更简单的解决方案和支持性参考资料。由于它很有用，并且遵循布鲁诺的建议，我最终决定将其发布为ananswer

简单的关联可以专门化吗？ 在我的问题中，我考虑了关联类的情况，因为我认为只有类可以被专门化。但事实上，简单的关联也可以推广

首先，根据UML 2.5，关联本身已经是一个分类工具：

第11.5.1节：关联对一组元组进行分类，这些元组表示 类型化实例。AssociationClass既是关联也是类

分类器可以专门化为：

第9.2.3.2节：概括定义了分类器之间的概括/专门化关系

符号如下：我不想告诉你规格的细节，我必须承认，如果我看到这一点，两周前我会声称这是胡说八道：

联想专业化是什么意思？ 关联专门化的语义是我精心定义的亮点：

第11.5.3.1节第198页：。。。在协会的情况下，专门化是指由专门化机构分类的链接 协会也按专业协会分类。这在语义上意味着 通过从表示项目结束的集合中消除重复项来计算的集合 专业化关联是通过消除 代表专业协会目的的集合的副本；这 子集的事实可以在模型中明确声明，也可以不明确声明

因此，在不说明任何关联目的的情况下，专门化意味着专门化关联是一般关联的子集。显式子集设置是可选的：

那么社团课呢？ 关联类既是关联类又是类。UML规范阐明了两者都是分类器，并且属性 元模型的属性不重复。所以是一样的。专业化同时适用于以下两种情况：

第11.5.3.2节：。。。为类和关联定义的专门化和细化规则也适用于AssociationClass

重要提示：关联可以泛化另一个关联，关联类可以泛化关联类，但AssociationClass不能 是一个关联或类的泛化，我们通常理解这一点的方式是无效的：

结论 当严格遵循UML规范时，我的图表（关联类之间的简单专门化）似乎是正确的， 明确的，表达意图的语义。Alex的回答建议明确声明隐含的子集：这是有效的，但它是有效的 不需要

请注意，有一个细微的区别：泛化/专门化与关联本身有关，而子集则与关联结束有关

其他见解：

对关联的重新定义、子集和专门化的语义进行了详细的分析。 初步评论：首先，我想比布鲁诺和阿克塞尔为他们各自的a nswers，这让我走上了正确的轨道。尽管如此，根据他们的指示进一步挖掘，我还是偶然发现了一个更简单的解决方案和支持性参考资料。由于它很有用，并且遵循布鲁诺的建议，我最终决定将其发布为ananswer

简单的关联可以专门化吗？ 在我的问题中，我考虑了关联类的情况，因为我认为只有类可以被专门化。但事实上，简单的关联也可以推广

首先，根据UML 2.5，关联本身已经是一个分类工具：

第11.5.1节：关联对一组元组进行分类，这些元组表示 类型化实例。AssociationClass既是关联也是类

分类器可以专门化为：

第9.2.3.2节：概括定义了分类器之间的概括/专门化关系

符号如下：我不想告诉你规格的细节，我必须承认，如果我看到这一点，两周前我会声称这是胡说八道：

联想专业化是什么意思？ 关联专门化的语义是我精心定义的亮点：

第11.5.3.1节第198页：。。。在协会的情况下，专门化是指由专门化机构分类的链接 协会也按专业协会分类。这在语义上意味着 通过从表示项目结束的集合中消除重复项来计算的集合 专业化关联是通过消除 代表专业协会目的的集合的副本；这 子集的事实可以在模型中明确声明，也可以不明确声明

因此，在不说明任何关联目的的情况下，专门化意味着专门化关联是一般关联的子集。显式子集设置是可选的：

那么社团课呢？ 关联类既是关联类又是类。UML规范阐明了两者都是分类器，并且属性 元模型的属性不重复。所以是一样的。专业化同时适用于以下两种情况：

第11.5.3.2节：。。。为类和关联定义的专门化和细化规则也适用于AssociationClass

重要提示：关联可以泛化另一个关联，关联类可以泛化关联类，但AssociationClass不能 是一个关联或类的泛化，我们通常理解这一点的方式是无效的：

结论 当严格遵循UML规范时，我的图表（关联类之间的简单专门化）似乎是正确的， 明确的，表达意图的语义。Alex的回答建议明确声明隐含的子集：这是有效的，但它是有效的 不需要

请注意，有一个细微的区别：泛化/专门化与关联本身有关，而子集则与关联结束有关

其他见解：

对关联的重新定义、子集和专门化的语义进行了详细的分析。

---

谢谢你这句有趣的话。您完全正确：只要一个关联类本身与另一个类关联，我们就可以将其建模为三元关联。但我认为这是一种选择，而不是强制性要求。现在，假设我要进行一个三元关联：这将使我如何解决这个问题？谢谢你这句有趣的话。您完全正确：只要一个关联类本身与另一个类关联，我们就可以将其建模为三元关联。但我认为这是一种选择，而不是强制性要求。现在，假设我要进行一个三元关联：这将使我如何解决这个问题？谢谢布鲁诺提出这个非常全面的问题。事实上，两端的名字使它不那么模棱两可，{redefinites}很好地处理了协方差和类型的变化。然而，我还有最后一个疑问。我的意图是专门处理创始人与公司基金合同之间的关联，但仍然允许创始人与正常的未重新定义的合同（如投资股票的抵押贷款）以及与正常人（如负责合同的公证人）签订的公司基金合同相关联。使用{redefinite}是否可能？因为我的印象是{redefinite}通过将关联类的定义限制为重新声明的值来更改它，从而排除了同时使用通用关联。我喜欢一个允许我和泛化一样的模型：专业化语义作为C++模板：如果我在特定的情况下，我想要特定的关联类，但是如果我不在特定的情况下，一般情况是SITLL可能的

---

---

e、 @Christophe。。。但仍允许创始人与正常的未重新定义的合同（如投资股票的抵押贷款）以及与正常人（如负责合同的公证人）签订的公司基金合同相关联。你可以在你的第二张图上看到，但对我来说，不是你的第三张图，也不是我所有的图，因为我的起点是你的第三张图diagram@Christophe对exactely@bruno在阅读了阿克塞尔的贡献后，我得出结论，他的建议允许以更简单的方式表达我的想法。因此，我将他的答案标记为解决方案，希望您能理解。当然，由于你以非常全面的方式提供了许多有用的建议，我认为在评论中也是一个有效的替代方案，因此，向上投票仍然有效。感谢布鲁诺提出这个极其全面的问题。事实上，两端的名字使它不那么模棱两可，{redefinites}很好地处理了协方差和类型的变化。然而，我还有最后一个疑问。我的意图是专门处理创始人与公司基金合同之间的关联，但仍然允许创始人与正常的未重新定义的合同（如投资股票的抵押贷款）以及与正常人（如负责合同的公证人）签订的公司基金合同相关联。使用{redefinite}是否可能？因为我的印象是{redefinite}通过将关联类的定义限制为重新声明的值来更改它，从而排除了同时使用通用关联。我喜欢一个允许我有同样的概括的模型：专业化语义作为C++模板：如果我在特定的情况下，我喜欢特定的关联类，但是如果我不在特定的情况下，一般的情况是可能的。@克里斯多夫…但仍允许创始人与正常的未重新定义的合同（如投资股票的抵押贷款）以及与正常人（如负责合同的公证人）签订的公司基金合同相关联。你可以在你的第二张图上看到，但对我来说，不是你的第三张图，也不是我所有的图，因为我的起点是你的第三张图diagram@Christophe对exactely@bruno在阅读了阿克塞尔的贡献后，我得出结论，他的建议允许以更简单的方式表达我的想法。因此，我将他的答案标记为解决方案，希望您能理解。当然，由于你以一种非常全面的方式提供了许多有用的建议，而且在我看来，在评论中也是一个有效的选择，所以投票权仍然存在！这似乎很有趣。我一直认为子集是一种轻松的重新定义。所以，如果我理解的很好，你的建议将在图形上看起来像布鲁诺的第二个图表，但使用子集而不是重新定义。从语义上看：这将使专门的关联只适用于子集的成员，而同时普通关联对不属于子集的成员仍然有效？是的，这就是它的外观和含义。你让我开心！您是否有机会引用支持此理解的2.5规格？抱歉，我通常会自己查看，但在internet访问受限的假日：-/UML 2.5:一个属性可能被标记为另一个子集属性的子集。在这种情况下，通过在某些上下文中消除子集属性表示的值集合中的重复项来计算集合。然后，该集合应包含在通过从相同上下文中的子集合属性所表示的值集合中消除重复项而计算的集合中，或与该集合相同。这意味着，所有用户定义的操作都需要将基础契约的任何元素添加到契约中。用户可能会搞砸。您可以通过定义/contract{derived union}来自动执行此操作。当然，非基础合同也必须是一个子集！这似乎很有趣。我一直认为子集是一种轻松的重新定义。所以，如果我理解的很好，你的建议将在图形上看起来像布鲁诺的第二个图表，但使用子集而不是重新定义。从语义上看：这将使专门的关联只适用于子集的成员，而同时普通关联对不属于子集的成员仍然有效？是的，这就是它的外观和含义。你让我开心！您是否有机会引用支持此理解的2.5规格？抱歉，我通常会自己查看，但在internet访问受限的假日：-/UML 2.5:一个属性可能被标记为另一个子集属性的子集。在这种情况下，通过在某些上下文中消除子集属性表示的值集合中的重复项来计算集合。然后，该集合应包含在通过从子集合表示的值集合中消除重复项计算的集合中，或与该集合相同

---

属性。这意味着，所有用户定义的操作都需要将foundationContract的任何元素也添加到Contract中。用户可能会搞砸。您可以通过定义/contract{derived union}来自动执行此操作。当然，非基础合同也必须是一个子集。