电影领域的 UML class 图
UML class diagram for domain with movies
我目前正在用 UML 为电影测试域创建 class 图。我想知道我是否做对了。好吧，我有两个选择（第一张图片中的第一个版本，第二张图片中的第二个 - 我认为第一个更好）。我想知道我是否正确建立了所谓的“关系所有者”，即关系从哪个 class 向哪个方向发展。我也不知道我是否没有弄错多重性（一对一，一对多等）。
所以在我的域中，我当然想要电影，那些电影中的演员和导演。我想知道 class 名称“角色”在这种情况下是否合适，因为我指的是参与电影的所有角色 - 它可以是导演、演员，但也可以是“蝙蝠侠”。也许我应该在这里区分“电影人物”和“人类”、“怪物”等等。但是我不知道如何优雅地做，我会继承Character class吗？我还想知道我是否不应该将城市或国家/地区之类的 class 放在一个名为地址的 class 中 - 但我希望 class 具有像本例中那样的属性，一个是大师，另一个是细节——关系朝着正确的方向发展。我只使用继承和依赖等关系，我不知道在这种情况下我是否应该改变一些东西。
版本 1
版本 2
提前感谢您的任何建议或建议！
简而言之
谨慎使用继承。当您的继承不是对象从出生到死亡的永久真理时，请选择 association over inheritance。并且请记住，classes 之间的依赖关系不会对那些 classes 的对象做出任何承诺。
更多解释
对 UML 语法的一些说明：
- 我了解到您以空心小三角形结尾的普通粗线表示 specialization/generalization 关系（也称为继承）。如果这是正确的，三角形应该更大以避免视觉混淆。此外，多重性对继承没有意义，应该被删除。
- 我了解到您打算用虚线表示与多重性的关联。如果这是正确的：
- 关联应该是纯线，因为虚线表示依赖关系，多重性没有意义。
- 您赋予箭头的含义可能不清楚。你用它们来记录导航性吗？如有疑问，请将其删除。如果要记录关联端的所有权，请改用点表示法。 （我们不能说它是对还是错，因为它取决于你的模型如何看待这些关联）
鉴于您的评论和其中链接的第三个模型，您需要牢记一些关键的 UML 语义：
- 继承是一种超强关系，这意味着“是（总是）一个”。在您的示例中，您可能会说
Actor 始终是 Person，因此，您所说的关于 Person 的所有内容对于 Actor 也是如此。顺便说一下，您应该避免重复继承的属性或方法，因为它可能会产生歧义。
- 继承不能替代聚合、组合或关联。例如，您不能说
CrewMember（一个人）总是 Crew（一群人）。 CrewMember 属于 Crew，但有些事情是团队可以一起做的，而个人成员做不到。
- 如果继承不总是正确的，那么它就不适合。例如，
Character 通常可能是 Person。但并非总是如此；：您可以有幽灵角色、漫画角色、机器人角色或动物。
- 关联意味着关联的classes的某些实例之间存在某种结构关系。例如，一个或几个人住在一个城市，似乎是一个非常相关的关联。
- 依赖意味着一个 class 依赖于另一个，即没有另一个 class 它就不会工作或者会丢失一些东西。这是关于 classes 而不是对象的声明。 IE。如果你想说
Person 依赖于 City 你只是说 class Person 在不知道 City 的情况下无法工作（例如，因为操作 sendPostCardFrom(city: City) 需要那种类型的论点）但你没有说任何关于 X、Y 和 Z 的人。如果你希望 X、Y 和 Z 与城市 a、b 和 c 相关，你需要一个关联。
关于模型内容，我不给你定论，没有绝对的道理。因此，我更愿意提请您注意潜在的问题。我以问题的形式提出来，你可以根据自己的答案调整模型：
两种变体之间的共同问题：
Actor和Director真的是Persons吗？在这种情况下，同时是演员和导演的人 (g.g. Clint Eastwood) 怎么办？或者 Actor 和 Director 只是 Persons 在给定的 Movie 中扮演的角色？- 一个
Character 真的只与 1 个 Movie 相关吗？同一个角色出现在好几部电影中的夺宝奇兵怎么办？
- 以类似的方式，我想知道是否真的有一个
Person 住在 City 中，或者这是否应该是一个多对多的关联？
关于差异的问题：`
- 版本 1 中的
Person 是 Character（继承）吗？或者 Character 是 Person 的表示（关联：表示）？
- 版本 2 中的
Character 真的是 Actor 并且通过传递性也是 Person（继承）吗？或者 Character 仅与 Actor 关联（关联：播放）？
由你决定，但无论我问什么关于关联或继承的问题，你最好在使用继承之前三思而后行（即更喜欢 association/composition 而不是继承）
我目前正在用 UML 为电影测试域创建 class 图。我想知道我是否做对了。好吧，我有两个选择（第一张图片中的第一个版本，第二张图片中的第二个 - 我认为第一个更好）。我想知道我是否正确建立了所谓的“关系所有者”，即关系从哪个 class 向哪个方向发展。我也不知道我是否没有弄错多重性（一对一，一对多等）。
所以在我的域中，我当然想要电影，那些电影中的演员和导演。我想知道 class 名称“角色”在这种情况下是否合适，因为我指的是参与电影的所有角色 - 它可以是导演、演员，但也可以是“蝙蝠侠”。也许我应该在这里区分“电影人物”和“人类”、“怪物”等等。但是我不知道如何优雅地做，我会继承Character class吗？我还想知道我是否不应该将城市或国家/地区之类的 class 放在一个名为地址的 class 中 - 但我希望 class 具有像本例中那样的属性，一个是大师，另一个是细节——关系朝着正确的方向发展。我只使用继承和依赖等关系，我不知道在这种情况下我是否应该改变一些东西。
版本 1
版本 2
提前感谢您的任何建议或建议！
简而言之
谨慎使用继承。当您的继承不是对象从出生到死亡的永久真理时，请选择 association over inheritance。并且请记住，classes 之间的依赖关系不会对那些 classes 的对象做出任何承诺。
更多解释
对 UML 语法的一些说明：
- 我了解到您以空心小三角形结尾的普通粗线表示 specialization/generalization 关系（也称为继承）。如果这是正确的，三角形应该更大以避免视觉混淆。此外，多重性对继承没有意义，应该被删除。
- 我了解到您打算用虚线表示与多重性的关联。如果这是正确的：
- 关联应该是纯线，因为虚线表示依赖关系，多重性没有意义。
- 您赋予箭头的含义可能不清楚。你用它们来记录导航性吗？如有疑问，请将其删除。如果要记录关联端的所有权，请改用点表示法。 （我们不能说它是对还是错，因为它取决于你的模型如何看待这些关联）
鉴于您的评论和其中链接的第三个模型，您需要牢记一些关键的 UML 语义：
- 继承是一种超强关系，这意味着“是（总是）一个”。在您的示例中，您可能会说
Actor始终是Person，因此，您所说的关于Person的所有内容对于Actor也是如此。顺便说一下，您应该避免重复继承的属性或方法，因为它可能会产生歧义。 - 继承不能替代聚合、组合或关联。例如，您不能说
CrewMember（一个人）总是Crew（一群人）。CrewMember属于Crew，但有些事情是团队可以一起做的，而个人成员做不到。 - 如果继承不总是正确的，那么它就不适合。例如，
Character通常可能是Person。但并非总是如此；：您可以有幽灵角色、漫画角色、机器人角色或动物。 - 关联意味着关联的classes的某些实例之间存在某种结构关系。例如，一个或几个人住在一个城市，似乎是一个非常相关的关联。
- 依赖意味着一个 class 依赖于另一个，即没有另一个 class 它就不会工作或者会丢失一些东西。这是关于 classes 而不是对象的声明。 IE。如果你想说
Person依赖于City你只是说 class Person 在不知道 City 的情况下无法工作（例如，因为操作sendPostCardFrom(city: City)需要那种类型的论点）但你没有说任何关于 X、Y 和 Z 的人。如果你希望 X、Y 和 Z 与城市 a、b 和 c 相关，你需要一个关联。
关于模型内容，我不给你定论，没有绝对的道理。因此，我更愿意提请您注意潜在的问题。我以问题的形式提出来，你可以根据自己的答案调整模型：
两种变体之间的共同问题：
Actor和Director真的是Persons吗？在这种情况下，同时是演员和导演的人 (g.g. Clint Eastwood) 怎么办？或者Actor和Director只是Persons在给定的Movie中扮演的角色？- 一个
Character真的只与 1 个Movie相关吗？同一个角色出现在好几部电影中的夺宝奇兵怎么办？ - 以类似的方式，我想知道是否真的有一个
Person住在City中，或者这是否应该是一个多对多的关联？
关于差异的问题：`
- 版本 1 中的
Person是Character（继承）吗？或者Character是Person的表示（关联：表示）？ - 版本 2 中的
Character真的是Actor并且通过传递性也是Person（继承）吗？或者Character仅与Actor关联（关联：播放）？
- 版本 1 中的
由你决定，但无论我问什么关于关联或继承的问题，你最好在使用继承之前三思而后行（即更喜欢 association/composition 而不是继承）