我的讲师关于协会 类 的说法正确还是错误？
Is my lecturer correct or incorrect about Association Classes?
这是他们关于协会 classes 的讲座幻灯片：
Sometimes associations have attributes or behavior that does not
belong solely to the class at either end. We can model this using an
association class. Assume the following diagram models the allocation
of students to modules.
The attribute finalMark does not ‘fit’ into either ‘end’ of the
association. In addition, it will be necessary to record more than one
mark for each student (for each module) and vice versa. Thus, the
attribute finalMark is an attribute of the association between
Student and Module.
The association class adds an extra constraint in that there can only
be one instance of the association class between any two participating
objects. Therefore, if we allowed students to re-sit modules but we
still needed to retain the finalMark’s of previous enrolments, we
could not use an association class and would need to ‘add’ a class,
Enrolment, and two more associations.
Also a Customer and Performance example. It needs to be a full class as customer can have many bookings:
我真的很难同意将点符号更改为完整符号 class。我在整个互联网上都看过这个，找不到任何使用这种方法的东西。我找到了我的讲师从中获得信息的文章 (here)，但即使是对该文章的评论也质疑其正确性。
在尝试他们设置的作业时真的让我很头疼，所以我想澄清一下这个问题。
从技术上讲，这些符号略有不同，但实际上您无法对关联进行编码 class。
在业务级别构建需求和设计应用程序时，您应该使用关联 class（它存在是有原因的！它也更具可读性）。
然而，在进入必须考虑代码限制的技术设计时，您应该将关联 classes 替换为替代表示，就像您在 class.
中显示的那样
再举一个例子（不好意思，我不知道它的引导效果如何，如果需要，请查看第259和260页）
这不是确切的示例，因为没有派生的关联，但是您会看到相同的方法，即添加 class 表示关联，两个关联导致每个关联 class。附加派生关联直接说明这其实是两者关联的表示
他们引用的约束不存在，对于关联 classes，即使 isUnique 设置为 true。对于通常的关联，您需要将 isUnique 设置为 false，以允许这样做。
您发现很多关于这种转换的信息的一个原因是许多人不使用关联 classes 而是直接用这样的 "full" class 定义实现关联。除了这两个 class 没有直接关联这一事实之外，这两个概念在技术上没有真正的区别。这意味着在实现中，您通常无法区分实现关联的 class 是定义为关联 class 还是仅定义为 class。因为关联 class 也是一个 "full" class （如果你想这样称呼它的话），因为它通过泛化关系与术语 class 相关，这样至于协会。结果它继承了两者的属性（呵呵，元模型）。
为了克服缺失的直接关联和不存在的约束，他们提出了一种可能的解决方案。但在讨论它们之前，我们可以问一下我们是否真的需要这两个属性？所以我们需要在逻辑上多次建立关系，正如问题中所定义的：是的。我们需要两个实例之间的直接关联吗？嗯...在这里，不是真的。在某些情况下，这可能有一些原因，例如，当定义了一个高级架构并且您只允许改进和完成它，但不能删除在更高级别上定义的关联时，另一个原因可能是某种工具问题或者当你想自动处理模型时，或者你依赖于使用的数据库引擎，关联对象的解析可能会更快。但基本上你在没有关联的实例之间建立了联系。
另一种解决方案是拥有关联 class 并拥有进一步的 class，其中包含可以随着时间的推移添加的信息，并且仍然有助于此关联。所以添加信息的class只能link关联class的一个实例，而关联class可以link任意（或无论规则是什么）实例。
从理论上讲，使用限定符也是一种可能性，但我建议不要在这种情况下使用它，因为它的含义有些不同。
但一如既往，每种方法都有一些优点和缺点。而且对于考试来说，只要他们没有错，最好听从老师的意见:-)
我不同意你的讲师。
事实上，UML 规范明确说明相反
UML v 2.5 第 199 页
NOTE. Even when all ends of the AssociationClass have isUnique=true,
it is possible to have several instances associating the same set of
instances of the end Classes.
我不认为将协会更改为协会 class 会改变协会已经强加的约束。
示例关联在两端都有 [1..*] 重数。这意味着 Student 的每个实例都必须注册一个或 更多 Module，但这并不是说学生不能注册同一个模块不止一次。
将协会设为一个协会 class 并不会突然改变这一点，因此 "solution"，将协会 class 更改为两个与注册链接的协会 class好像没必要。
这取决于您的讲师教您的 UML 的版本。在版本 1 中它们是正确的，在版本 2 中它们不是。
此外，我认为您的讲师可能想在这里教您一些有关分析和设计过程的知识。在 UML 中有很多表示事物的方法，因为它是一种通用语言（就像我们在 IT 中使用的许多语言一样）；他们可能试图向您展示的是如何在您发现更多信息和回答问题时思考问题并改进您的模型。这在很大程度上是在现实世界中建模——在你详细阐述、重新调整和逐渐确定最能与你和你的利益相关者进行沟通的表示时不断重复，无论他们是谁，无论他们的愿望和需求是什么。你肯定需要了解技术细节，但你也需要知道什么时候它足够好并继续工作。换句话说——他们可能是错的，这取决于上下文（我不能评论更多），但实际上这并不重要。
这是他们关于协会 classes 的讲座幻灯片：
Sometimes associations have attributes or behavior that does not belong solely to the class at either end. We can model this using an association class. Assume the following diagram models the allocation of students to modules.
The attribute
finalMarkdoes not ‘fit’ into either ‘end’ of the association. In addition, it will be necessary to record more than one mark for each student (for each module) and vice versa. Thus, the attributefinalMarkis an attribute of the association betweenStudentandModule.
The association class adds an extra constraint in that there can only be one instance of the association class between any two participating objects. Therefore, if we allowed
studentsto re-sit modules but we still needed to retain thefinalMark’s of previousenrolments, we could not use an association class and would need to ‘add’ a class, Enrolment, and two more associations.
Also a
CustomerandPerformanceexample. It needs to be a full class as customer can have many bookings:
我真的很难同意将点符号更改为完整符号 class。我在整个互联网上都看过这个，找不到任何使用这种方法的东西。我找到了我的讲师从中获得信息的文章 (here)，但即使是对该文章的评论也质疑其正确性。
在尝试他们设置的作业时真的让我很头疼，所以我想澄清一下这个问题。
从技术上讲，这些符号略有不同，但实际上您无法对关联进行编码 class。 在业务级别构建需求和设计应用程序时，您应该使用关联 class（它存在是有原因的！它也更具可读性）。 然而，在进入必须考虑代码限制的技术设计时，您应该将关联 classes 替换为替代表示，就像您在 class.
中显示的那样再举一个例子（不好意思，我不知道它的引导效果如何，如果需要，请查看第259和260页）
这不是确切的示例，因为没有派生的关联，但是您会看到相同的方法，即添加 class 表示关联，两个关联导致每个关联 class。附加派生关联直接说明这其实是两者关联的表示
他们引用的约束不存在，对于关联 classes，即使 isUnique 设置为 true。对于通常的关联，您需要将 isUnique 设置为 false，以允许这样做。
您发现很多关于这种转换的信息的一个原因是许多人不使用关联 classes 而是直接用这样的 "full" class 定义实现关联。除了这两个 class 没有直接关联这一事实之外，这两个概念在技术上没有真正的区别。这意味着在实现中，您通常无法区分实现关联的 class 是定义为关联 class 还是仅定义为 class。因为关联 class 也是一个 "full" class （如果你想这样称呼它的话），因为它通过泛化关系与术语 class 相关，这样至于协会。结果它继承了两者的属性（呵呵，元模型）。 为了克服缺失的直接关联和不存在的约束，他们提出了一种可能的解决方案。但在讨论它们之前，我们可以问一下我们是否真的需要这两个属性？所以我们需要在逻辑上多次建立关系，正如问题中所定义的：是的。我们需要两个实例之间的直接关联吗？嗯...在这里，不是真的。在某些情况下，这可能有一些原因，例如，当定义了一个高级架构并且您只允许改进和完成它，但不能删除在更高级别上定义的关联时，另一个原因可能是某种工具问题或者当你想自动处理模型时，或者你依赖于使用的数据库引擎，关联对象的解析可能会更快。但基本上你在没有关联的实例之间建立了联系。
另一种解决方案是拥有关联 class 并拥有进一步的 class，其中包含可以随着时间的推移添加的信息，并且仍然有助于此关联。所以添加信息的class只能link关联class的一个实例，而关联class可以link任意（或无论规则是什么）实例。
从理论上讲，使用限定符也是一种可能性，但我建议不要在这种情况下使用它，因为它的含义有些不同。
但一如既往，每种方法都有一些优点和缺点。而且对于考试来说，只要他们没有错，最好听从老师的意见:-)
我不同意你的讲师。
事实上，UML 规范明确说明相反
UML v 2.5 第 199 页
NOTE. Even when all ends of the AssociationClass have isUnique=true, it is possible to have several instances associating the same set of instances of the end Classes.
我不认为将协会更改为协会 class 会改变协会已经强加的约束。
示例关联在两端都有 [1..*] 重数。这意味着 Student 的每个实例都必须注册一个或 更多 Module，但这并不是说学生不能注册同一个模块不止一次。
将协会设为一个协会 class 并不会突然改变这一点，因此 "solution"，将协会 class 更改为两个与注册链接的协会 class好像没必要。
这取决于您的讲师教您的 UML 的版本。在版本 1 中它们是正确的，在版本 2 中它们不是。
此外，我认为您的讲师可能想在这里教您一些有关分析和设计过程的知识。在 UML 中有很多表示事物的方法，因为它是一种通用语言（就像我们在 IT 中使用的许多语言一样）；他们可能试图向您展示的是如何在您发现更多信息和回答问题时思考问题并改进您的模型。这在很大程度上是在现实世界中建模——在你详细阐述、重新调整和逐渐确定最能与你和你的利益相关者进行沟通的表示时不断重复，无论他们是谁，无论他们的愿望和需求是什么。你肯定需要了解技术细节，但你也需要知道什么时候它足够好并继续工作。换句话说——他们可能是错的，这取决于上下文（我不能评论更多），但实际上这并不重要。