关于协会课程,我的讲师是正确还是错误?

时间:2018-01-18 18:48:30

标签: associations uml class-diagram

以下是关于协会课程的演讲幻灯片:

  

有时,关联具有不属于的属性或行为   完全属于两端的班级。我们可以使用一个来建模   协会课。假设下图为分配建模   学生到模块。

     

enter image description here

     

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

     

enter image description here

     

关联类添加了一个额外的约束,因为只有   是任何两个参与之间的关联类的一个实例   对象。因此,如果我们允许students重新设置模块,但我们   仍然需要保留之前finalMark的{​​{1}},我们   无法使用关联类,需要“添加”一个类,   入学,还有两个协会。

     

enter image description here

     

同样是enrolmentCustomer示例。它需要是一个完整的课程,因为客户可以有很多预订:

     

enter image description here

我真的很同意将点缀符号改为全班。我在互联网上看过这个,并且找不到任何使用这种方法的东西。我找到了一篇文章,其中我的讲师从(here)获得了他们的信息,但即使是对这些文章的评论也会对其正确性提出质疑。

在尝试他们已经设定的任务时,这真的让我很头疼,所以我想对这个问题有所了解。

4 个答案:

答案 0 :(得分:2)

我不同意你的讲师 事实上,UML规范明确指出相反的

UML v 2.5 Page 199

  

请注意。即使AssociationClass的所有结尾都是isUnique = true,   可以有几个实例关联同一组   结束类的实例。

我认为将关联更改为关联类不会将任何内容更改为关联已经施加的约束。

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

使关联成为一个关联类不会突然改变它,所以“解决方案”,将关联类更改为链接到注册类的两个关联似乎没有必要。

答案 1 :(得分:1)

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

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

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

enter image description here

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

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

答案 2 :(得分:0)

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

这是另一个例子(对不起,我不知道它有多好,如果需要,请查看第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

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

答案 3 :(得分:0)

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

此外,我认为您的讲师可能会尝试向您介绍分析和设计过程。有许多方法可以用UML表示事物,因为它是一种通用语言(就像我们在IT中使用的许多语言一样);他们可能试图向您展示的是如何在发现更多信息和回答问题时思考问题并发展模型。这在现实世界中非常具有建模性 - 在您精心设计,重新调整和逐步确定最能与您和您的利益相关者沟通的代表时,不管他们是谁以及他们的愿望和需求是什么,都会不断重复。您肯定需要了解技术细节,但您还需要了解它何时足够好以及继续工作。换句话说 - 它们可能是错的,取决于背景(我不能评论更多),但实际上它并不重要。