在 UML 中建模两个相似类之间的关系

Question

我正在对我的项目进行建模，随后我将使用 UML 在 Java 中实现该项目。我的项目涉及管理一家健身房。更具体地说，我目前正在建模一个类图，它允许我组织锻炼程序（请参阅黄色的类）：

我将锻炼程序解释为列表的列表：锻炼程序是“WorkoutDay”课程的列表（从 1 到 7），而“WorkoutDay”课程又是“ExercisesForTheWorkoutRoutine”课程的列表。然而，workoutRoutines 中的“ExercisesForTheWorkoutRoutine”与“Exercise”类（只有 String 类型的名称和枚举类型的状态）不同，因为它们还具有恢复时间、重复次数和次数。套。

我的疑问是如何连接“ExercisesForTheWorkoutRoutine”和“Exercise”这两个类。因为我需要当一个练习从“练习”列表中删除时（例如，健身房不再有某种设备），与删除的练习同名的所有“exercisesForTheWorkoutRoutine”实例也将被删除。

我不知道它是泛化、简单关联（在本例中，我认为基数为 1..1）还是聚合。

Answer 1

当有疑问时，优先选择组合而不是继承。这个流行建议中的“组合”指的是 OOP 对象组合，即在 UML 中表示为关联。

事实上，

Exercise

似乎是一种模板或参考，很可能具有其他属性（例如状态）和与

ExerciseForWorkout

完全不同的行为。例如，您可以想象

Exercise

稍后可以通过视频链接来丰富或与作者相关联以进行数字版权管理，而这些信息可能与

ExerciseForWorkout

中不相关。

仅当

ExerciseForWorkout

对象始终可以替换

Exercise

对象时，才应考虑继承。而这里的情况似乎并非如此。

尽管如此，从建模的角度来看，您可能想知道

ExerciseForWorkout

是否始终与

Exercise

相关，这是您的（模糊的）多重性所暗示的。在这种情况下，您应该问问自己是否真的需要重复引用的名称 锻炼。您还可以将 ExerceForWorkout 视为

Exercise

和

DailyWorkout

之间的关联类。

一些不相关的言论：

• 多重性应该位于关联的每一端（并且 1..1 应该位于 Ercise 端，而 * 应该位于 ExerceForWorkout 端，因为我预计相同的参考练习可以多次重复使用）
• 避免使用共享聚合（白色菱形），因为虽然菱形是永恒的，但这个没有任何价值，因为与简单关联相比，UML 规范没有给出任何额外的语义。