如何建立伙伴关系？答案

【问题标题】：How to model partnership?如何建立伙伴关系？
【发布时间】：2019-03-07 23:18:57
【问题描述】：

我想模拟两个人之间的合作关系。我的第一个想法是使用协会。协会的两端必须以不同的方式命名。因此我需要两个角色：partner1 和partner2。这反过来又允许每个人有两个伙伴。不完全是我想要的。我的第二次尝试是使用属性partner。这里的问题是，一个人的伙伴的伙伴应该是这个人，但模型没有捕捉到这一点。当然，我们可以使用具有这种效果的约束，但我更喜欢使用图形表示法的解决方案。

第三个选项（建议在下面的评论中）使用一个额外的类Partnership。这可行，但如果它没有任何属性，它只会使模型变得比必要的复杂。

最优雅的解决方案是一个关联，其中两个member ends 将是相同的partner 属性。但是这是不允许的，因为成员端属性是唯一的。因此它不能包含两次相同的属性。这是规范中的错误吗？这真的是罕见的情况吗？所有递归关联都会发生这种情况，其中双方的角色相同。

【问题讨论】：

我假设您想避免使用名为 Partnership 的附加类来解决它？
如果合作伙伴需要额外的属性，这样的类是必要的。但没有它，我认为这是一种解决方法。
哦，我看到我给出了答案 - 哈哈
嗯，问题是在这种情况下它是最简单的解决方案。替代方案是约束，不是很优雅，但也可以工作。
最好的解决方案可能是具有约束self.partner.partner = self的定向关系“伙伴”

标签： uml class-diagram

【解决方案1】：

这是一个对称部分关联的例子。这种关联只能在合适的约束条件下进行建模，如下面的模型所示：

只有在“对称”等关联原型中使用的相应约束关键字已被定义时，才能避免附加的显式约束/不变量。不幸的是，UML 2.5 没有提供这样的原型，但我们可以随意添加它：

[提交答案后，我只阅读了上面“布鲁诺”的评论。 “bruno”正确地指出了约束主要部分的必要性：self.partner.partner = self。]

【讨论】：

是的，这解决了问题。但是，对于通常由协会建模的案例，它需要一个约束。妻子和丈夫之间的关联自动意味着 self.wife.husband=self。不需要约束。为什么我们必须添加一个约束，只是因为我们发现，任何两个人都可以形成合伙企业。我的直觉是，应该增强 UML 规范以涵盖这种情况。
不，“妻子和丈夫之间的关联自动意味着 self.wife.husband=self”不是真的。每个人都可以有妻子和丈夫！你总是需要一个约束来强制执行这些额外的要求。在夫妻的情况下，您可以通过要求丈夫是男性而妻子是女性的约束来强制执行此操作。
我忘了提到，需要两个新类：Man 和 Woman。只有Man 可以是丈夫，只有Woman 可以是妻子。我的主要观点是，这里隐含的约束也应该隐含在合作伙伴案例中。您认为我在上面提出的partner 属性与其自身之间的关联可以完成这项工作吗？
当然，对两个（不相交的）类之间的这种关联进行建模与将其建模为递归关联（范围与域类相同）是不同的问题。您的选项 2 与我的模型几乎相同，但您必须添加约束！正如我已经说过的：没有合适的约束，你不会得到对称的部分递归关联！
LOL（主题）：当然，这个古老的约束在世界范围内不再有效（曾经有过吗？）。同性婚姻是可能的……

【解决方案2】：

这个构造怎么样：？

一对夫妇恰好有 2 个人相关联。一个类不能有任何额外的属性。但是，您可以想到它的创建日期。在结婚的情况下，可以注明姓氏的人，等等。可能还有更多关于这种伙伴关系的信息，因为您似乎需要它。

现在，我为什么要使用复合聚合？基本上，组合意味着溶解组合元素也会消除组合元素。所以这看起来很天主教，不是吗？是的，让我感到羞耻。但是，应该有表达“一个人只能为一对夫妇组成”的东西。这就是复合聚合也说明的（在我最喜欢的第 110 页上）：

复合聚合是一种强大的聚合形式，它要求一个部分对象一次最多包含在一个复合对象中。如果一个复合对象被删除，它的所有作为对象的部分实例都会被删除。

好吧，所以应该使用共享组合

表示该属性具有共享聚合语义。共享聚合的精确语义因应用领域和建模者而异。

带有建模说明，说明每个元素只能在共享组合中使用一次。

当然，与约束的简单关联是最好的。不过，我会以这种方式保留图表，以供读者娱乐。

附：阅读各种 cmets 让我认为Partnership（及其兄弟会变体）的语义远比人们直觉开始想到的更敏感。所以真正的“答案”应该是：首先为Partnership 定义社交环境。

【讨论】：

在这种情况下我不会使用合成。一个人可以参与多种关系，如果关系结束，所涉及的人通常会存活下来。除此之外，我绝对推荐像Couple 或Relationship 这样的课程。该实体可以拥有自己的数据，例如legal status、start date 等...
@GeertBellekens 好吧，作为一名非复合材料战士，我对使用它意味着什么。我应该给出一些解释......现在就可以了。
这里可以使用聚合，但由于它没有任何语义，这只是一个口味问题。组合不是必需的，因为一个Person 只能是一个Couple 的一部分这一事实是由多重性给出的。当我们的系统还包含Friarhood 并且我们想要表达时，它可能很有用，Person 的实例可以是Couple 或Friarhood 的一部分。但是，正如您所说，删除语义可能不是有意的。
是的。实际上，我不喜欢任何一种钻石符号。它总是会引起讨厌的讨论。对关联的约束效果要好得多。我猜你的意思是Brotherhood？如果是这样，您只需将多重性设置为2..*。
我在谈论Brother/Friarhood 方面的多样性。它将是 0..1，如 Partnership 一侧。由于我假设兄弟俩都过着独身生活，Person 不能同时出现在Partnership 和Brotherhood 中，这是由组合表达的。我同意，在这种情况下，约束是更好的选择。

【解决方案3】：

问题中提到的优雅解决方案如下所示：它看起来与其他解决方案没有太大区别，但实际上在当前的 UML 中是不可能的，因为成员端属性有isUnique=true：我认为，这是规范的错误。它当然可以得到纠正（以蓝色显示）。但是，似乎这个错误并没有经常被注意到。这种更正是否有用，值得付出努力？

如果这个答案被赞成，我会提出问题。

【讨论】：

不确定自引用是否允许双方使用相同的角色名称。不幸的是，这意味着：UML 晚餐紧缩：-/ 向 OMG 提交错误会将其放在一长串列表中。我有一个几岁的。
我看不出“非唯一”有什么帮助。只有 ìsUnique` 作为约束，它不存在意味着“不一定是唯一的”。仅添加 isUnique 似乎有意义（对我而言）。两次提及同一个属性会让人感到精神分裂。
您的“解决方案”并不优雅，而是毫无意义！就映射到 OOP 类或形式逻辑（例如 OWL）而言，它应该意味着什么？
字符串“非唯一”是isUnique=false 的表示法。我同意这听起来很精神分裂，但它可以模拟协会的两个成员端都引用相同的属性。我不确定，到 OWL 的映射是什么。无论如何，映射到 OOP 是不可能的，因为双向关联不是 OO。但是，这意味着Person 的两个实例有一个partner 的插槽，该插槽被限制为self.partner.partner=self，就像Woman 的实例被限制为self.husband.wife=self 一样。这对我来说就像类似的情况。
再想一想，你的建议看起来很合理（OTOH，也太晚了......）。角色名称指的是实例属性（尽管您没有设置拥有的属性点）。但是，即使在 OWL 视图中，这也是有意义的。但它仍然没有解决布鲁诺建议的约束。