【问题标题】:Is my lecturer correct or incorrect about Association Classes?我的讲师对协会课程的看法是正确的还是错误的?
【发布时间】:2018-06-27 22:34:25
【问题描述】:

这是他们关于协会课程的演讲幻灯片:

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

属性finalMark 不“适合”到 协会。此外,还需要记录多个 标记每个学生(每个模块),反之亦然。就这样 属性finalMark是属性之间的关联 StudentModule

关联类增加了一个额外的约束,因为只有 是任意两个参与的关联类的一个实例 对象。因此,如果我们允许 students 重新安装模块,但我们 仍然需要保留之前enrolments 的finalMark,我们 不能使用关联类,需要“添加”一个类, 注册,以及另外两个协会。

还有CustomerPerformance 示例。它需要是一个完整的班级,因为客户可以有很多预订:

我真的很难同意将点符号改为完整的类。我已经在整个互联网上查看了这一点,但找不到任何使用这种方法的东西。我找到了我的讲师从 (here) 那里获得信息的文章,但即使是对该文章的评论也质疑其正确性。

在尝试他们设置的任务时真的让我很头疼,所以我想澄清一下这个问题。

【问题讨论】:

  • 图片 #3 显示了 #2 的另一个渲染,其中 Enrolled on 实际上不需要,只是为了便于阅读而添加。关联类绑定两个(或更多)类并添加功能。从技术上讲,关联类是关联和类的混合。
  • 附带说明:关联类不是虚线而是虚线。
  • 另见 p. 205 个 UML 规范。

标签: associations uml class-diagram


【解决方案1】:

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

UML v 2.5 第 199 页

注意。即使 AssociationClass 的所有端都有 isUnique=true, 可能有多个实例关联同一组 结束类的实例。

我认为将关联更改为关联类不会对关联已经施加的约束产生任何影响。

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

使关联成为关联类并不会突然改变这一点,因此“解决方案”,将关联类更改为与注册类关联的两个关联似乎没有必要。

【讨论】:

  • 很好看,Geert!
  • 是的,这就是我所害怕的,但我只能按照他们的想法去做,因为他们是标记作业的人:)
  • @user1323 正如我在回答中所说,当他们错了我不会去遵守。在这里,您有 UML 标准来证明您的解决方案。与一些旧的 UML 版本相比,这可能发生了变化,他们并没有意识到这一点。
  • 我不同意上面的一个说法:图表确实表明一个学生不能多次注册同一个模块。 isUnique 的默认值为 true,因此每个模块只能在链接到学生的模块集合中出现一次。这并没有说明链接的数量。链接和链接末尾的集合是不同的概念,听起来可能很奇怪。
【解决方案2】:

对于关联类,即使 isUnique 设置为 true,它们所引用的约束也不存在。对于通常的关联,您需要将 isUnique 设置为 false,以允许这样做。

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

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

理论上,使用限定词也是一种可能,但我建议不要在这种情况下使用它,因为它的含义有些不同。

但与往常一样,每种方法都有一些优点和缺点。而且对于考试,最好与老师保持一致,只要他们没有错:-)

【讨论】:

  • 您应该对您的第一个陈述进行更正。见吉尔特的回答。否则你的答案很好。
  • 刚刚更正了它,并进一步举例说明为什么关联类在某些情况下有用。
【解决方案3】:

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

另外,我认为您的讲师可能正试图在这里教您一些有关分析和设计过程的知识。由于 UML 是一种通用语言(就像我们在 IT 中使用的许多语言一样),因此有很多方法可以表示事物;他们可能试图向您展示的是如何在您发现更多信息和回答问题时思考问题并改进您的模型。这在现实世界中非常重要——在您详细阐述时不断重复、重新调整并逐渐确定最能与您和您的利益相关者沟通的表示,无论他们可能是谁,无论他们的愿望和需求是什么。您肯定需要了解技术细节,但您还需要知道它何时足够好并继续工作。换句话说——它们可能是错误的,具体取决于上下文(我无法评论更多),但实际上这并不重要。

【讨论】:

    【解决方案4】:

    从技术上讲,这些表示法略有不同,但实际上您无法编写关联类。 在业务级别构建需求和设计应用程序时,您应该使用关联类(它的存在是有原因的!它也更具可读性)。 然而,在进入必须考虑代码限制的技术设计时,您应该将关联类替换为您在类中显示的替代表示。

    这是另一个例子(抱歉,我不知道它的效果如何,如果需要,请查看第 259 和 260 页)

    https://books.google.pl/books?id=v7JL2oKwFEAC&pg=PA258&lpg=PA258&dq=replacing+association+class+with+class&source=bl&ots=VXiMY2efu3&sig=D4rXwBf8fQQsMhaF2EaWlF_NJcQ&hl=pl&sa=X&ved=0ahUKEwiv89X0seLYAhVSb5oKHXjVDog4ChDoAQhcMAc#v=onepage&q=replacing%20association%20class%20with%20class&f=false

    这不是确切的示例,因为没有派生关联,但是您会看到相同的方法,即添加表示关联的类,两个关联将一个关联引导到每个关联类。额外的派生关联直接表明这实际上是两者之间关联的表示。

    【讨论】:

    • 并非所有类图都需要翻译成代码。还有很多其他用途。
    • 你说的很对@GeertBellekens,我会更正我的回答,表明在技术设计层面需要进行这种更改。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-03-03
    • 2023-04-02
    • 2012-06-24
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多