我的讲师关于社团课是正确的还是不正确的？

Question

以下是他们关于协会课程的演讲幻灯片：

有时，关联具有的属性或行为不仅仅属于两端的类。我们可以使用关联类对此进行建模。假设下图对学生分配到模块的模型进行了建模。

属性< code>finalMark不适合关联的任何“end”。此外，有必要为每个学生(每个模块)记录一个以上的分数，反之亦然。因此，属性< code>finalMark是< code>Student和< code>Module之间关联的属性。

association类增加了一个额外的约束，即任何两个参与对象之间只能有一个association类实例。因此，如果我们允许< code >学生重新参加模块，但我们仍然需要保留以前< code >注册的< code >最终标记，我们就不能使用关联类，而需要“添加”一个类、注册和另外两个关联。

还有一个客户和性能示例。它需要是一个完整的类，因为客户可以有很多预订：

我真的很难同意将点符号更改为完整的类。我已经在互联网上查看了所有关于此的内容，找不到使用这种方法的任何内容。我找到了我的讲师从（这里）获得信息的文章，但即使是对该文章的评论也质疑其正确性。

当我试图完成他们布置的任务时，这真的让我很头疼，所以我想弄清楚这个问题。

Answer 1

这取决于讲师教授的UML版本。在版本1中，它们是正确的，在版本2中，它们不是。

我还认为你的讲师可能试图在这里教你一些关于分析和设计过程的东西。在UML中有许多方法来表示事物，因为它是一种通用语言(就像我们在其中使用的许多语言一样)；他们可能试图向你展示的是，当你发现更多信息和回答问题时，如何思考问题和发展你的模型。这在很大程度上是现实世界中的建模——在你阐述的过程中不断重复，不断调整，并逐渐确定一种能最好地与你和你的利益相关者沟通的表现形式，不管他们是谁，也不管他们的愿望和需求是什么。你肯定需要知道技术细节，但你也需要知道什么时候足够好，然后继续工作。换句话说——他们可能是错的，这取决于上下文(我不能对此发表更多评论),但实际上这没多大关系。

Answer 2

对于关联类，它们引用的约束不存在，即使isUnique设置为true。对于通常的关联，需要将isUnique设置为false，以允许此操作。

您之所以会发现关于这种转换的大量信息，是因为许多人不使用关联类，而是立即使用这样一个“完整”类来实现关联。除了这两个类没有直接的关联之外，这两个概念在技术上没有真正的区别。这意味着在实现中，通常无法区分实现关联的类是定义为关联类还是仅定义为类。因为关联类也是一个“完整”类（如果你想这样称呼它），因为它通过泛化关系与术语类相关，比如关联。在consequence中，它继承了两者的属性（嗯，元模型）。为了克服缺失的直接关联和不存在的约束，他们提出了一种可能的解决方案。但在讨论它们之前，我们可以问，我们是否真的需要这两个属性？因此，我们需要在逻辑上多次建立这种关系，正如问题中所定义的：是的。我们需要两个实例之间的直接关联吗？嗯……这里，不是真的。在某些情况下，这可能有一些原因，例如，当定义了一个高级体系结构，并且只允许您细化和完成它，但不能删除在更高级别上定义的关联时，另一个原因可能是一些工具问题，或者当您希望自动处理模型时，或者您依赖于使用的数据库引擎，关联对象的分辨率可能更快。但基本上，您可以在没有关联的实例之间建立连接。

另一个解决方案是拥有一个关联类，并拥有另一个包含信息的类，这些信息可以随着时间的推移而添加，并且仍然有助于这个关联。因此，添加信息的类只能链接到关联类的一个实例，而关联类可以链接到任意(或任何规则)实例。

理论上，使用限定符也是一种可能性，但我建议不要在这种情况下使用它，因为它的内涵有些不同。

但一如既往，每种方法都有一些好处和缺点。对于考试来说，只要老师们没有错，最好还是遵从他们的要求：-）

Answer 3

我不同意你的讲师。
事实上，UML 规范明确指出了相反的情况

UML v 2.5第199页

注意。即使AssociationClass的所有端都具有isUnique=true，也可能有几个实例关联端类的同一组实例。

我不认为将关联更改为关联类会改变关联已经施加的约束。

示例关联在两端都具有 [1..*] 多重性。这意味着学生的每个实例都必须注册一个或多个模块，但这并不是说学生不能多次注册同一模块。

将关联设置为关联类不会突然改变这一点，因此“解决方案”，即将关联类更改为链接到注册类的两个关联似乎没有必要。