同一端的聚合和导航性

时间:2017-12-17 13:34:34

标签: associations uml diagram

在UML中,是否可以在组件对象可以访问复合对象的位置绘制聚合?就像在这个图像中,但只有一条关联线,所以触摸A的关联结束时会有一个菱形和一个箭头。 如果那是不可能的,我绘制的图表是有效的吗?如果没有,为什么?

2 个答案:

答案 0 :(得分:2)

Another point of view, navigability is important to show how is it possible to navigate in the model and how to access to instances.

Another point is about OCL, if navigability is not defined some OCL queries will be hard to write.

Specification describes (p 198): Navigability means that instances participating in links at runtime (instances of an Association) can be accessed efficiently from instances at the other ends of the Association. The precise mechanism by which such efficient access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient.

And about Property class (p 149): The query isNavigable() indicates whether it is possible to navigate across the property. body: not classifier->isEmpty() or association.navigableOwnedEnd->includes(self).

So to model or not navigability is important.

If you want to have navigability in both side, the following image shows that:

enter image description here

But in section 6 of the specifiation, it is written:

  • An association with neither end marked by navigability arrows means that the association is navigable in both directions.

  • Arrow notation is used to denote association end navigability. By definition, all class-owned association ends are navigable. By convention, all association owned ends in the metamodel are not navigable.

So the following schema is the same than the above one. This is tricky but it seems true.

enter image description here

答案 1 :(得分:1)

当然可能。

如果您想节省空间,可以使用一行进行关联:

enter image description here

以下是我对导航性的个人看法:不需要导航箭头,因为属性owner的存在意味着已经存在。

P上。 110规格:

  

当Property通过ownedAttribute由除Association之外的分类器拥有时,它表示分类器的属性。

P上。 200:

  

根据非正式惯例,过去经常使用导航符号,其中假定非导航端由协会拥有,而假定导航端由对方的分类器拥有。现在不推荐使用此约定。聚合类型,导航性和最终所有权是单独的概念,每个概念都有自己的显式表示法。类所拥有的关联端始终是可导航的,而关联所拥有的关联端可以是可导航的。

但是什么是刚刚命名的协会?到目前为止,这是一个无用的结构。你打算最终在任一类中创建属性 - 通过属性,在这种情况下你添加这个(新)点。对我来说,这只是过度构建和不切实际的。谁真的在使用那些点?在EA中,您必须打开子菜单才能显示它们。对于我(可能是大多数UML读者),角色名称表示属性,而这是另一方面的属性。那只是"(我的)人类逻辑"这个命题的背后。所以,我的实际方法:

  • 使用简单连接器进行关联
  • 最终添加(非)导航(十字和)箭头
  • 稍后添加角色名称以指示在另一端使用属性(而不是将类型属性添加到类'列表中)。

就是这样。只要忘记那些难以产生的愚蠢点(在EA中)和b)更难以识别。

再一次:这里的最后一部分是我对实际建模的建议。