带有电影的域的 UML 类图

Question

我目前正在为电影测试域创建 UML 中的类图。我想知道我是否做得对。好吧，我有两个选择（第一张图片中的第一个版本，第二张图片中的第二个 - 我认为第一个更好）。我想知道我是否正确地建立了所谓的“关系所有者”，即关系从哪个类到哪个方向。我也不知道我是否没有弄错多重性（一对一、一对多等）。

因此，在我的域中，我当然希望有电影，这些电影中的演员和导演。我想知道在这种情况下类名“Character”是否合适，因为我指的是参与电影的所有角色——它可以是导演、演员，也可以是例如“蝙蝠侠”。也许我应该在这里区分“电影角色”和“人类”、“怪物”等等。但我不知道如何优雅地做到这一点，然后我会从 Character 类继承吗？我也想知道我是否不应该将像 City 或 Country 这样的类放在一个名为 Address 的类中 - 但我希望这些类在这种情况下采用属性，一个是 Master，另一个是 detail - 以及关系集在正确的方向。我只使用继承和依赖之类的关系，我不知道在这种情况下是否应该改变一些东西。

版本 1

第 2 版

提前感谢您的任何建议或意见！

Answer 1

总之

非常小心地使用继承。当你的继承不是从一个对象的诞生到死亡的永久真理时，首选association over inheritance。并且请记住，类之间的依赖关系不会对这些类的对象做出任何承诺。

更多解释

对UML语法的一些说明：

• 我知道您的粗线以一个小的空心三角形结尾表示一种专业化/概括关系（又名继承）。如果这是正确的，三角形应该更大以避免视觉混乱。此外，多重性对继承毫无意义，应该被删除。
• 我知道您打算用虚线表示与多重性的关联。如果这是正确的：
  • 关联应该是纯线，因为虚线用于依赖关系，多重性没有意义。
  • 你给箭头的含义会不清楚。您是否使用它们来记录可导航性？如有疑问，请将其删除。如果要记录关联端的所有权，请改用点符号。 （我们不能说它是对还是错，因为这取决于你的模型如何看待关联）

鉴于您的 cmets 和其中链接的第三个模型，您需要牢记一些关键的 UML 语义：

• 继承是一种超强的关系，这意味着“是（总是）一个”。在您的示例中，您可能会说Actor 始终是Person，因此，您所说的关于Person 的所有内容也适用于Actor。顺便说一句，您应该避免重复继承的属性或方法，因为这可能会产生一些歧义。
• 继承不能替代聚合、组合或关联。例如，您不能说CrewMember（一个人）始终是Crew（一群人）。 CrewMember 属于 Crew，但有些事情是工作人员可以一起做而单个成员不能做的。
• 如果继承并不总是正确的，那么继承是不合适的。例如，Character 通常可能是Person。但并非总是如此；：您可以拥有幽灵角色、漫画角色、机器人角色或动物。
• 关联意味着关联类的某些实例之间存在某种结构关系。例如，一个或几个人住在一个​​城市，似乎是一个非常相关的关联。
• 依赖意味着一个类依赖于另一个类，即没有另一个类，它将无法工作或缺少某些东西。这是关于类而不是对象的声明。 IE。如果您的意思是说 Person 依赖于 City 您只是说 Person 类在不了解 City 的情况下将无法工作（例如，因为操作 sendPostCardFrom(city: City) 需要该类型的参数）但您不需要说出关于人 X、Y 和 Z 的任何内容。如果您希望 X、Y 和 Z 与城市 a、b 和 c 相关，则需要关联。

关于模型内容，我不会替你决定，也没有单一的真理。因此，我更愿意提请您注意潜在问题。我以问题的形式提出它们，由您根据自己的答案调整模型：

• 两种变体之间的常见问题：

  • Actor 和 Director 真的是 Persons 吗？在这种情况下，同时是演员和导演的人（例如克林特伊斯特伍德）怎么办？还是Actor 和Director 只是Persons 为给定Movie 所扮演的角色？
  • Character 真的只与 1 个Movie 相关吗？印第安纳琼斯怎么办？同一个角色出现在几部电影中？
  • 以类似的方式，我想知道是否真的有一个Person 住在City 中，或者这不应该是多对多关联？

• 关于差异的问题：`

  • 版本 1 中的 Person 是 Character（继承）吗？还是Character 是Person 的代表（关联：代表）？
  • 版本 2 中的 Character 真的是 Actor 并且通过传递性也是 Person（继承）吗？还是Character 仅与Actor 关联（关联：播放）？

由您决定，但无论我问什么有关关联或继承的问题，您最好在使用继承之前三思而后行（即更喜欢关联/组合而不是继承）