聚合与通航同在
Aggregation and navigability at the same end
在UML中，是否可以画出组件对象可以访问复合对象的集合？就像在这个图像中，但只有一条关联线，所以接触 A 的关联端将有一个菱形和一个箭头。
如果那不可能，我画的图有效吗？如果不是，为什么？
当然可以。
如果要保存space，可以使用单行关联：
这是我个人对导航性的看法：不需要导航箭头，因为 属性 owner 的存在已经暗示了这一点。
P. 110 个规格：
When a Property is owned by a Classifier other than an Association via ownedAttribute, then it represents an attribute of the Classifier.
P. 200:
Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the Association whereas navigable ends were assumed to be owned by the Classifier at the opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are separate concepts, each with their own explicit notation. Association ends owned by classes are always navigable, while those owned by associations may be navigable or not.
但是刚刚命名的协会是什么？到目前为止，这是一个无用的构造。您打算最终在 classes 中创建属性 - 通过属性，在这种情况下您添加这个（新）点。对我来说，这简直是过度构建且不切实际。谁真正在使用这些点？在 EA 中，您必须打开子菜单才能显示它们。对于我（可能还有大多数 UML 读者）来说，一个角色名称代表一个 属性 并且这是另一边的一个属性。那只是该命题背后的“（我的）人类逻辑”。所以，我的实用做法：
- 使用简单的连接器进行关联
- 最终添加（非）导航性（十字和）箭头
- 稍后添加角色名称以指示在另一端使用属性（而不是将类型属性添加到 class' 列表）。
就是这样。忘记那些 a) 难以生成（在 EA 中）和 b) 更难识别的愚蠢点。
再一次：这里的最后一部分是我对实际建模的建议。
从另一个角度来看，可导航性很重要，它展示了如何在模型中导航以及如何访问实例。
还有一点是关于OCL，如果不定义可导航性，一些OCL查询将很难写。
规范描述（第 198 页）：可导航性意味着可以从关联另一端的实例有效地访问运行时参与链接的实例（关联的实例）。实现这种有效访问的精确机制是特定于实现的。如果一端不可导航，则可能无法从另一端访问，如果可以，则可能效率不高。
关于 属性 class (p 149)：查询 isNavigable() 指示是否可以在 属性 上导航。正文：不是 classifier->isEmpty() 或 association.navigableOwnedEnd->includes(self).
所以建模与否导航很重要。
如果你想两边都通航，如下图所示：
但是在规范的第6节中，写着：
两端均未标有导航箭头的关联表示该关联可双向导航。
箭头符号用于表示关联结束导航。根据定义，所有 class 拥有的关联端都是可导航的。按照惯例，元模型中所有关联拥有的端点都是不可导航的。
所以下面的schema和上面的schema是一样的。这很棘手，但似乎是真的。
在UML中，是否可以画出组件对象可以访问复合对象的集合？就像在这个图像中，但只有一条关联线，所以接触 A 的关联端将有一个菱形和一个箭头。
当然可以。
如果要保存space，可以使用单行关联：
这是我个人对导航性的看法：不需要导航箭头，因为 属性 owner 的存在已经暗示了这一点。
P. 110 个规格：
When a Property is owned by a Classifier other than an Association via ownedAttribute, then it represents an attribute of the Classifier.
P. 200:
Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the Association whereas navigable ends were assumed to be owned by the Classifier at the opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are separate concepts, each with their own explicit notation. Association ends owned by classes are always navigable, while those owned by associations may be navigable or not.
但是刚刚命名的协会是什么？到目前为止，这是一个无用的构造。您打算最终在 classes 中创建属性 - 通过属性，在这种情况下您添加这个（新）点。对我来说，这简直是过度构建且不切实际。谁真正在使用这些点？在 EA 中，您必须打开子菜单才能显示它们。对于我（可能还有大多数 UML 读者）来说，一个角色名称代表一个 属性 并且这是另一边的一个属性。那只是该命题背后的“（我的）人类逻辑”。所以，我的实用做法：
- 使用简单的连接器进行关联
- 最终添加（非）导航性（十字和）箭头
- 稍后添加角色名称以指示在另一端使用属性（而不是将类型属性添加到 class' 列表）。
就是这样。忘记那些 a) 难以生成（在 EA 中）和 b) 更难识别的愚蠢点。
再一次：这里的最后一部分是我对实际建模的建议。
从另一个角度来看，可导航性很重要，它展示了如何在模型中导航以及如何访问实例。
还有一点是关于OCL，如果不定义可导航性，一些OCL查询将很难写。
规范描述（第 198 页）：可导航性意味着可以从关联另一端的实例有效地访问运行时参与链接的实例（关联的实例）。实现这种有效访问的精确机制是特定于实现的。如果一端不可导航，则可能无法从另一端访问，如果可以，则可能效率不高。
关于 属性 class (p 149)：查询 isNavigable() 指示是否可以在 属性 上导航。正文：不是 classifier->isEmpty() 或 association.navigableOwnedEnd->includes(self).
所以建模与否导航很重要。
如果你想两边都通航，如下图所示：
但是在规范的第6节中，写着：
两端均未标有导航箭头的关联表示该关联可双向导航。
箭头符号用于表示关联结束导航。根据定义，所有 class 拥有的关联端都是可导航的。按照惯例，元模型中所有关联拥有的端点都是不可导航的。
所以下面的schema和上面的schema是一样的。这很棘手，但似乎是真的。