实体是一个人。
因此该实体有生日，也许已经有生日。
但是，这个日期可以或不能被告知（取决于实体和信息的可用性）；因此该实体可能没有这些。
但是我觉得基数和关系类型搞砸了。
我该怎么表示？
我创建了一个抽象类 Individual 。它导致2个最后的类：Person（已识别的人）或Pseudonym（匿名的人）。
它链接到Birthdate类和Deathdate类（都归类为Date类）。
[生日] ---- <> [个人]的关系是：
一对（可选）对多（0..1-1 .. *）
0..1：因为可以省略出生日期，而个人只能有一个出生日期。
1 .. *：因为出生日期必须涉及至少一个，但可以涉及几个人。
[死亡日期] ---- <> [个人]关系是：
一对（可选）对多（0..1-1 .. *）
0..1：因为该人尚未死亡，只能死一次。
1 .. *：因为死亡日期必须涉及至少一个，但可能涉及几个人。
但是，从理论上讲，由于每个人都有生日（并且将会有死亡日期），所以我对构图很感兴趣。但是有些人可能更喜欢将这些日期保密，我想知道组成是否可以允许这样做。
此外，一个日期可以对应几个人，在这里我也猜想不可能进行合成，否则，是我在个人类及其实例（个人）之间造成了混淆，然后可以进行合成，但没有上述基数。
此刻我选择了：
Aggregation :
___________ _______________
|Birthdate|0..1-----1..*< >| |
___________ | <<Individual>>|
|Deathdate|0..1-----1..*< >|_______________|
但是我对此很犹豫
Composition :
___________ _______________
|Birthdate|0..1-----1<#>| |
___________ | <<Individual>>|
|Deathdate|0..1-----1<#>|_______________|
正确的答案是什么？感谢您的关注。
答案 0 :(得分：3)
该方法存在许多问题。
首先-对日期使用类仅仅是一个过大的杀伤力。生日和死亡日期都是特定人的属性，可以很容易地将其建模为个人类的内联属性。除非出于某些重要原因而不是使用良好的旧Date DataType，否则请使用标准方法。
对于可见性问题，正如面向对象的原则所述，您无论如何都不应直接公开这些属性。而不是您应该有一个负责检索生日和死亡日期的操作，该操作将控制是否可以读取日期。您可以添加支持此功能的布尔属性，但是如果查看日期的能力取决于“个人”的某些状态或其他因素（例如“谁”询问），则没有必要。在前一种情况下，您可能还希望仍将那些布尔属性明确显示为派生属性。
如果您坚持使用日期类（例如，您希望拥有Wikipedia风格的“日期出生” /“日期已到期”集合），则应仅创建一个日期类并为该类建立漂亮的关联与第二种方法非常相似。在这种情况下，多重性不适用于“数据库样式”，而是关联本身的属性。特别是您有一个生日/死亡日期和一个个人。默认情况下，您将有两个1-0..1关联，每个关联一个，但是根据方法的不同，您可能会使用更复杂的方法。
稍后我将添加图表以更加清晰。
最后一句话。
请勿使用<< >>作为类名。这些保留用于指示刻板印象。
如果要表示“个人”是抽象的，则可以用斜体显示，或者（如果您的工具不允许这样做）使用<<abstract>>原型。