在 class 图中使用递归关系或“猪耳朵”
Using recursive relationships or “pig ears ” in a class diagram
老师注意到这部分有一个环，建议用“猪耳朵”
我找不到太多关于此的信息或示例。
到处都是这样写的
reflexive relationships, which are sometimes called recursive relationships or "pig ears" (because the image of such a relationship in the drawing looks like a pig's ear — if you use a little imagination!). Note that this relationship is always optional; otherwise, it would be by definition an infinite hierarchy. We'll look at this rule later when we start studying invalid and unrealizable data structures.
也许有人可以举例说明如何使用“猪耳朵”以及如何更改我的图表。
你的老师肯定是被图片误导了。即使有一些想象力，我也很难找到一个真正合理的反身 class her（+1 任何人用这里没有提到的似是而非的案例回答）。
第一个建议：尝试使用 shared target 将泛化分组到相同的 class。这里的共享目标是 User,
第二个建议：然后显示将所有共享属性移动到共享目标。在你的图表中，给人的印象是 pupil 和 parent 都有名字，但 staff 和 admin 没有。
第三条建议：永远不要在图表中添加实现关联的属性。至少，在你的模型是 bullet-proof 之前。例如，在您的情况下，parent.pupilId 表示 parent 只有一个学生，而列表显示了几个。这令人困惑。
第四条建议：在心理上玩弄你的模型，看看它是否符合现实生活中的情况。例如：
- 一个parent在学校可以有几个children(ok)
- 一个child一个账号可以有多个parent（不行：你用黑色菱形组合，这意味着每个child只属于一个parent)
- A child 可以有一个帐户，但是 parents 没有互联网也没有帐户（不行：组合还要求有一个 parent 帐户child 帐户存在）。
- 一位老师（员工）在学校有自己的 children（不行：因为员工没有 children。解决方法：老师有一个账户作为员工，一个账户作为parent)（提示：如果您已经实施了您的系统，并且不想更改，您可以通过告诉您的客户这是为了提高安全性并避免老师更改自己的成绩来解决此缺陷children 滥用授权 ;-) )
- 管理员也一样（但是如果你发现了之前的缺陷而不是修复它，你现在就完蛋了...）
- 管理员是员工（不行，除非使用两个帐户）。
- 一个parent也可能是小学生（不行）（你不相信我？我家孩子上的是我镇上的音乐学校，我觉得很好，所以我自己也成了小学生, 拼命学吉他).
第五条建议：如有疑问，prefer composition over inheritance。但也只有在您绝对确定组合 object（在菱形的另一边）是专有的并且没有组合就不能存在的情况下才使用组合（这里，我们不是在谈论 children和 parents，但 children 帐户和 parent 帐户）。
应用所有这些原则后，您可能会得到一个更接近于此的模型：
Cross-check：以上所有情况都可以回答是。
现在，如果你想取悦你的老师，而不是从用户到角色的 one-to-many 关系，你可以做一个一对 0..1 的组合，并在一个角色和一个角色之间添加一个反身组合0..1 个其他角色，创建角色链。
最后的建议（今天）：不要使用“猪耳朵”这个词。它是模棱两可的（+1 因为已经完成你的研究），它不常用（好的，我已经听过“耳朵”和“mikey-mouse 耳朵”），它通过鼓励寻找第二只耳朵来产生偏见，最后同样重要的是，它会产生一种情绪偏见（我认为它是负面的，但这种印象可能是文化上的）。
老师注意到这部分有一个环，建议用“猪耳朵” 我找不到太多关于此的信息或示例。 到处都是这样写的
reflexive relationships, which are sometimes called recursive relationships or "pig ears" (because the image of such a relationship in the drawing looks like a pig's ear — if you use a little imagination!). Note that this relationship is always optional; otherwise, it would be by definition an infinite hierarchy. We'll look at this rule later when we start studying invalid and unrealizable data structures.
也许有人可以举例说明如何使用“猪耳朵”以及如何更改我的图表。
你的老师肯定是被图片误导了。即使有一些想象力，我也很难找到一个真正合理的反身 class her（+1 任何人用这里没有提到的似是而非的案例回答）。
第一个建议：尝试使用 shared target 将泛化分组到相同的 class。这里的共享目标是 User,
第二个建议：然后显示将所有共享属性移动到共享目标。在你的图表中，给人的印象是 pupil 和 parent 都有名字，但 staff 和 admin 没有。
第三条建议：永远不要在图表中添加实现关联的属性。至少，在你的模型是 bullet-proof 之前。例如，在您的情况下，parent.pupilId 表示 parent 只有一个学生，而列表显示了几个。这令人困惑。
第四条建议：在心理上玩弄你的模型，看看它是否符合现实生活中的情况。例如：
- 一个parent在学校可以有几个children(ok)
- 一个child一个账号可以有多个parent（不行：你用黑色菱形组合，这意味着每个child只属于一个parent)
- A child 可以有一个帐户，但是 parents 没有互联网也没有帐户（不行：组合还要求有一个 parent 帐户child 帐户存在）。
- 一位老师（员工）在学校有自己的 children（不行：因为员工没有 children。解决方法：老师有一个账户作为员工，一个账户作为parent)（提示：如果您已经实施了您的系统，并且不想更改，您可以通过告诉您的客户这是为了提高安全性并避免老师更改自己的成绩来解决此缺陷children 滥用授权 ;-) )
- 管理员也一样（但是如果你发现了之前的缺陷而不是修复它，你现在就完蛋了...）
- 管理员是员工（不行，除非使用两个帐户）。
- 一个parent也可能是小学生（不行）（你不相信我？我家孩子上的是我镇上的音乐学校，我觉得很好，所以我自己也成了小学生, 拼命学吉他).
第五条建议：如有疑问，prefer composition over inheritance。但也只有在您绝对确定组合 object（在菱形的另一边）是专有的并且没有组合就不能存在的情况下才使用组合（这里，我们不是在谈论 children和 parents，但 children 帐户和 parent 帐户）。
应用所有这些原则后，您可能会得到一个更接近于此的模型：
Cross-check：以上所有情况都可以回答是。
现在，如果你想取悦你的老师，而不是从用户到角色的 one-to-many 关系，你可以做一个一对 0..1 的组合，并在一个角色和一个角色之间添加一个反身组合0..1 个其他角色，创建角色链。
最后的建议（今天）：不要使用“猪耳朵”这个词。它是模棱两可的（+1 因为已经完成你的研究），它不常用（好的，我已经听过“耳朵”和“mikey-mouse 耳朵”），它通过鼓励寻找第二只耳朵来产生偏见，最后同样重要的是，它会产生一种情绪偏见（我认为它是负面的，但这种印象可能是文化上的）。