UML关联类-澄清

我正在阅读Martin Fowler的“UML蒸馏”，在阅读关于关联类的文章时，我得到了以下引用：

使用association类来抵消 你必须用额外的符号

记得吗？关联类添加了一个额外的约束，即 只能有一个实例

任意两个参与对象之间的关联类

然后有一个例子，但我想确保我得到了正确的答案，例如：

 ---------            ---------
|         |*        *|         |
| CLASS A |----------| CLASS B |
|         |     |    |         |
 ---------      |     ---------
                |
          ______|______
         |             |
         |             |
         |  CLASS C    |
         |             |
         |_____________|

然后，对于每个不同的对（A的实例，B的实例），只存在一个类C的实例

---

因此，如果我取A1，A2，B1，B2实例，那么对于（A1，B1）（A1，B2）（A2，B1）（A2，B2），我将得到4个C实例，没有更少，没有更多？

这是正确的，无意在这里混合概念，但它类似于数据库中的表，其中：

A 1-* C
B 1-* C

其中，C可以被视为破坏a和B之间的多对多关系的结果

对于B上的每一行，只能存在1行，也只能存在1行C，并且该特定行（C上）只能与A上的1行相关。

---

因此，对于A和B上的每对唯一行，C上只能存在1行或无行，因为*表示0或多行。

您的推理是正确的：如果关联类没有一个或两个关联端用

{ununique}

注释，则它意味着相同对象之间只能有一个链接的约束（如马丁·福勒所解释）

然而，请注意，非唯一关联结束选项仅在UML2（2005年）中添加，MartinFowler的书（2003年起）提到了UML1.x

一些示例可能会有所帮助。例如，可以将

Person

和

PieceOfLand

之间的关联

LandPurchase

建模为UML关联类（具有默认的唯一关联端），因为一个人和一块土地之间只能有一个购买链接。

person

和

Product

之间的关联

ProductPurchase

，只有在

Product

端的关联被注释为

{ununique}时，才能建模为关联类

因为同一个人和同一产品（作为一种类型）之间可以有多个购买链接。例如，我可以购买多辆特斯拉S型车（如果我有钱的话）

---

类似地，在

人员

和

医生

之间的

预约

的情况下，由于同一个人可以与同一医生有多个预约，因此

医生

侧的关联端必须根据UML2.5规范注释为

{ununique}

：

请注意，当AssociationClass的一个或多个端点 isUnique=false，可能有多个实例关联 最终类的同一组实例

福勒先生可能把事实弄错了。没有额外的限制，只有存储额外属性值的能力

---

当isUnique=false时，额外的属性允许一个人在不同日期对同一医生的多次就诊进行建模，或者在不同日期对同一产品的多次购买进行建模，例如。

UML中的关联表示（具有）逻辑意义（UML不是数据库建模的工具！）.关联描述可能的逻辑事实。例如，两个人A和B可能结婚，我们可以将其绘制为关联，它表示的意思类似于“我们知道人A和人B之间存在逻辑联系”。如果我们知道这是什么，我们绘制阶级关联[婚姻证书]作为具体事实。

我认为您还没有理解表示a和B之间二进制关联的“关联类”C和与a和B都关联的类C之间的UML区别。这个答案在可能的行数方面是不正确的。请参阅我引用UML规范的答案。说，“个人和产品之间的二进制关联ProductPurchase不能建模为UML‘关联类’。”请参阅我引用UML规范的答案。感谢您指出这一点。我已经修改了我的答案。现在它是正确的。唯一性指示符在BNF中是可选的。因此，没有明确的{unique}或{ununique}标记，不能说它意味着同一个对象之间只能有一个链接。更清楚的是，这不是关于是否对端点进行注释，而是关于端点元属性的设置方式。在可视化模型中，您不设置元属性，而是添加注释。

元属性的默认值为
true
，因此，如果图中的关联端没有
{unique}
注释，
isUnique
是
true
。他们在哪一页这样说？在第239页，他们说“当关联的一个或多个端具有isUnique=false时，可能有多个链接关联同一组实例。“注意，他们在UML1.x中没有这种多集合的关联结束语义，Martin Fowler的旧语句引用了它。因此，他没有弄错事实（请更正你关于他的句子），但OMG修改了语义。有人能告诉我Martin Fowler的UML第三版是否对UML2.x提出了相同的主张吗？请注意，我确实说了“may”。您的答案令人困惑，因为默认情况下（当关联结束时是唯一的），您没有解释这一点，存在此约束，并且只有当至少一个关联端被注释为非唯一时，才不存在此类约束。注释是可选的，因此不能假设默认约束在没有注释时有效。这可能是规范中的一个缺陷。我不知道此引号来自何处，但在2.5规范I downl中日期为2015年3月的oad我在第199页的§11.5.3——注释中发现了此注释。即使AssociationClass的所有端都具有isUnique=true，它也是