当前位置: 首页 > 知识库问答 >
问题:

如何在UML中建模协变关联类?

艾宁
2023-03-14

我想建模两个类之间的协变关联,每个类都可以专门化。我需要展示相关关联类的专业化。但我想避免我的模型可能意味着存在冗余关联(即,泛化之间和专门化之间的关联)。

我在UML类图中有一个和一个合同之间的许多关联。一个人可以参与几个合同,反之,一个合同可以涉及几个人。每个相关人员都在合同中扮演一个角色。一个人甚至可以多次参与同一合同中的不同角色:

从UML专门化中,我知道FounderCompanyFoundation合约继承了多对多关系。但是在与我的法律实践用户讨论后,很快就出现了CompanyFoundation合约Founder角色也需要专门化,以考虑例如在公司中持有的股份。在我的类图中对这种协方差进行建模似乎很简单:

乍一看,这种模式可以代表此类合同的法律复杂性:显然,非创始人的其他人可以以正常角色参与合同(例如,注册公司的律师或律师)。

由于关联类ShareHolderRoleRole关联类的特化,我希望清楚它是合约Person之间以及CompanyFoundation合约Founder之间的相同关联。

然而,我担心我遗漏了一些东西,并且严格解释UML将意味着有两个不同且冗余的关联。我该如何准确地建模只有一个关联,但有一个协变关联类的事实?


共有3个答案

童宏富
2023-03-14

(您使用Founders在图表中输入了一个拼写错误)

我希望清楚这是合同与个人之间以及公司基金会合同与创始人之间的一种相同的联系

对我来说不是,否则这意味着不可能将这种联系作为额外的联系,但当然这是可能的

如果您想明确这一点,请添加关联结束的名称并使用相同的两个名称:

您还可以明确地说,每个关联端重新定义了另一个,允许使用不同的名称:

当然,你也可以用我在“来源”答案中的方法来做:

其中蓝色的约束涉及关系类而不仅仅是相应的类,绿色的约束不是强制性的,因为它们可以从蓝色的约束中推断出来

廉高邈
2023-03-14

专用关联类不限于仅连接重新定义的属性。因此,这个关联类很可能连接了创始人和基础契约,这些属性与人和契约无关(除了它们的类型是专门化)。然而,如果你确实重新定义了它们,那么这些新属性(甚至可能有相同的名称)将取代旧属性,使得创始人不可能拥有非基金合同。

现在,基础合同仍然是合同。因此,一个人参与的合同清单应该包含这些合同。这可以通过子集实现。只需定义一个foundationContract{subsets contract}founder{subsets person}。我想,这才是你真正想要的。

由于属性是每个默认集合,“集合”意味着它们不包含重复项,因此同一个人不可能在同一合同中扮演多个角色。如果希望实现这一点,则必须为属性设置属性。

蒋畅
2023-03-14

初步评论:首先,我想比布鲁诺和阿克塞尔各自的答案,这使我在正确的轨道上。然而,根据他们的指示进行进一步挖掘,我偶然发现了一个更简单的解决方案和支持性参考文献。由于它很有用,并且遵循布鲁诺的建议,我最终决定将其发布为ananswer。

在我的问题中,我考虑了关联类的情况,因为我认为只有类可以被专门化。但事实上,简单的关联也可以推广。

首先,根据UML 2.5,关联本身已经是一个分类器:

第11.5.1节:关联对表示类型化实例之间链接的一组元组进行分类。AssociationClass既是关联又是类。

分类器可以是专门的:

第9.2.3.2节:泛化定义了分类器之间的泛化/专业化关系。

符号如下(我不想告诉你规格的细节,我必须承认,2周前,如果我看到这个,我会声称“胡说八道”:

协会专业化的语义学定义明确(我的亮点:

第11.5.3.1节(p.198): (...)在协会的情况下,专门化意味着由专门化协会分类的链接也由专门化协会分类。从语义上讲,这意味着通过从代表专门化协会结束的集合中消除重复来计算的集合是通过从代表专门化协会结束的集合中消除重复来计算的相应集合的子集;子集的事实可能会也可能不会在模型中明确声明

因此,在不告诉任何关于关联结束的情况下,特殊化暗示了特殊化关联是一般关联的子集。显式子集是可选的:

关联类既是关联又是类。UML规范阐明了两者都是分类器,并且元模型的属性没有重复。所以是一个。专业化同时适用于两者:

第11.5.3.2节:(...)为类和协会定义的专门化和细化规则也适用于协会类。

重要提示:一个关联可以泛化另一个关联,一个关联类可以泛化一个关联类,但是“一个AssociationClass不能是一个关联或一个类的泛化”),我们一般理解这一点的方式是无效的:

当严格考虑UML规范时,我的图(具有关联类之间的简单专门化)似乎是正确的、明确的,并且表达了预期的语义。Alex的回答建议明确声明隐含子集:这是有效的,但不是必需的。

请注意,有一个细微的区别:泛化/专门化与关联本身有关,而子集与关联结束有关。

其他见解:

  • 这篇引人入胜的研究论文详细分析了联想的重新定义、子集和专门化的语义
 类似资料:
  • UML 2.5.1规范说明了关联最终所有权: 点表示法用于表示关联结束所有权,其中点表示线另一端的Class拥有属性,其类型为点触及的Class。 它说明了关联端可导航性: 箭头符号用于表示关联结束可导航性。根据定义,所有类拥有的关联端都是可导航的 我可以清楚地看到为什么类拥有的关联端是可导航的: 然而,我更难弄清楚一个由关联所有(所以不是类所有)的关联端如何可以导航? 规范规定,关联可以用关联类

  • 这就是我现在对关联、聚合和组合的理解。 协会 聚集 构成 我认为理解这些词的意思是没有意义的,除非我不能在实际代码中表示它。以上代码取自SO答案(如果以上代码错误,请告诉我)。 我的问题是闪烁。 1) 在类图中显示聚合和组合是否重要 2) 我使用了一个可以转换java的工具。将文件分类到类图中。类可视化工具,但我无法使此工具在类图中显示聚合或组合关系。这是工具的问题还是我不了解如何在代码中使用组合

  • 在UML图中,这些场景之间的关系是什么? <code>1.取2个类,类A和类B。类A中有一些方法,例如:public function(ArrayList <代码> 2。取两个类,A类和b类。A类中有一些方法,比如:公共函数(ArrayList

  • 我多次偶然发现这个词,但我不理解它的含义。当我读《结社终结》时,我倾向于思考结社的类别。每个联想都有两个联想终点,这是真的吗?还是我们说的“联想终点”是指类的角色?我已经搜索了这个术语的更详细的解释,但我找到的一切都在uml图上。组织: 你可以在我的截图底部看到,query和qbuilder,每个类的角色,都是“关联endpoint”。我的问题是,如果通过“关联端”,我们指向每个类的角色,还是指向

  • 问题内容: 在下面的代码中,我想测试是否为。如果是的话,我想作为。你怎么做到这一点?如果不使用强制转换,则使用其他技术。 那里的最后一行不会编译。错误是: 协议“ SpecialController”仅具有通用要求或关联类型要求,因此只能用作通用约束。 问题答案: 不幸的是,Swift当前不支持将具有关联类型的协议用作实际类型。但是,从技术上讲这对于编译器是可行的。并且很可能在该语言的未来版本中实

  • 因此,我对UML图中的关联、聚合和组合有一些疑问。以下是一些场景: > 产品评审对产品评审的评级组成。这意味着对于每一个产品评审等级必须有产品评审?如果产品评审不存在,评审评级就没有意义。 客户NRIC协助推车和订货。我们不能使用聚合,因为如果客户不存在,购物车和订单也不存在。 有人能帮我检查一下我的关系是否正确吗?因为我对聚合和关联有点困惑,所以用关联来链接所有的表是好的吗。我不知道什么时候该用