如何通过关联 class 导航以使用 OCL 创建约束？
How to navigate through association class to create constraints with OCL?
我正在努力寻找一种方法来导航关联 class 以创建约束
我在这里查看了规范：https://www.omg.org/spec/OCL/About-OCL/
上面写着：
假设我有这个 class 图：
以及这个对象图：
如您所见，我在 class A 的上下文中创建了一个约束（就在 class 的名称下方），我尝试使用较低的 "c" 和较高的 "C", 都不起作用...
Context A:
inv: self.C[b].val.mod(2) = 0
（约束的含义并不重要，我只是想让它起作用）
当我执行验证过程时出现此错误：
"Expression has errors: Semantic errors at [0:5]: Unrecognized variable: (C)"
这个错误消息似乎是合乎逻辑的，因为我在类型 A 的对象中没有看到属性 "c" 或 "C"，但我不明白为什么会这样。
我做错了什么吗？
我不明白为什么它不起作用，因为我尊重规范中描述的语法。
相关信息：
我使用：
- 魔术抽奖：v18.5
- OCL: 2.0
提前致谢！
你看着一个很暗的角落。我第一次尝试实际测试此功能，但未能找到可以实际绘制图 7.1 的 UML 工具。一旦我掌握了文本，我就意识到有很多问题；两种不同的 x[y] 语法之间的潜在冲突，QVTo 缩写进一步加剧了这种冲突。扩展到不止二元关联存在问题。 OCL 抽象语法继续使用 AssociationEnd 的 UML 1.x 概念，而不是 UML 2.x 属性.
因此，您观察到的功能是某些工具供应商为理解非常不充分的规范所做的最大努力的结果。
对于 MagicDraw，您以前使用的是 Dresden OCL，但我了解到 MagicDraw 已切换到 Eclipse OCL，也许是 Classic Eclipse OCL。 NoMagic 在承认他们重新分发的开源软件方面似乎非常沉默寡言。
对于较新的 Pivot Eclipse OCL，我在其中对许多 OMG OCL 问题的解决方案进行了原型设计，UML 到 Pivot 加载规范化了许多 UML 概念，因此关联是多余的，除非到关联的显式导航需要关联Class待具体化。 AssociationClasses 被规范化为 AssociationClasses，每个看似合理的导航具有普通属性。
我认为你的表述不正确。
self.C[b] 不能是合格的关联，因为隐式 A::C 属性 没有键。
self.C[b] 可能是一个消除歧义的导航 A::C，其中 A::C 的歧义通过选择相反的 C::b 来解决。但是 A::C 并没有歧义，它的反义词是 C::a。所以 self.C 应该足够了，self.C[a] 是多余的，self.C[b] 是错误的。遗憾的是您的工具不喜欢 self.C 所以您的工具有缺陷。
我认为你应该写 self.C.val.mod(2) = 0.
大写 C 正确。 OCL <= 2.2 遵循 UML 风格指南错误地建议使用小写字母。请参阅 OCL 2.4 的 7.5.4 中 "Missing Association End names" 下的缩进段落。
我正在努力寻找一种方法来导航关联 class 以创建约束
我在这里查看了规范：https://www.omg.org/spec/OCL/About-OCL/
上面写着：
假设我有这个 class 图：
以及这个对象图：
如您所见，我在 class A 的上下文中创建了一个约束（就在 class 的名称下方），我尝试使用较低的 "c" 和较高的 "C", 都不起作用...
Context A:
inv: self.C[b].val.mod(2) = 0
（约束的含义并不重要，我只是想让它起作用）
当我执行验证过程时出现此错误：
"Expression has errors: Semantic errors at [0:5]: Unrecognized variable: (C)"
这个错误消息似乎是合乎逻辑的，因为我在类型 A 的对象中没有看到属性 "c" 或 "C"，但我不明白为什么会这样。
我做错了什么吗？ 我不明白为什么它不起作用，因为我尊重规范中描述的语法。
相关信息： 我使用：
- 魔术抽奖：v18.5
- OCL: 2.0
提前致谢！
你看着一个很暗的角落。我第一次尝试实际测试此功能，但未能找到可以实际绘制图 7.1 的 UML 工具。一旦我掌握了文本，我就意识到有很多问题；两种不同的 x[y] 语法之间的潜在冲突，QVTo 缩写进一步加剧了这种冲突。扩展到不止二元关联存在问题。 OCL 抽象语法继续使用 AssociationEnd 的 UML 1.x 概念，而不是 UML 2.x 属性.
因此，您观察到的功能是某些工具供应商为理解非常不充分的规范所做的最大努力的结果。
对于 MagicDraw，您以前使用的是 Dresden OCL，但我了解到 MagicDraw 已切换到 Eclipse OCL，也许是 Classic Eclipse OCL。 NoMagic 在承认他们重新分发的开源软件方面似乎非常沉默寡言。
对于较新的 Pivot Eclipse OCL，我在其中对许多 OMG OCL 问题的解决方案进行了原型设计，UML 到 Pivot 加载规范化了许多 UML 概念，因此关联是多余的，除非到关联的显式导航需要关联Class待具体化。 AssociationClasses 被规范化为 AssociationClasses，每个看似合理的导航具有普通属性。
我认为你的表述不正确。
self.C[b] 不能是合格的关联，因为隐式 A::C 属性 没有键。
self.C[b] 可能是一个消除歧义的导航 A::C，其中 A::C 的歧义通过选择相反的 C::b 来解决。但是 A::C 并没有歧义，它的反义词是 C::a。所以 self.C 应该足够了，self.C[a] 是多余的，self.C[b] 是错误的。遗憾的是您的工具不喜欢 self.C 所以您的工具有缺陷。
我认为你应该写 self.C.val.mod(2) = 0.
大写 C 正确。 OCL <= 2.2 遵循 UML 风格指南错误地建议使用小写字母。请参阅 OCL 2.4 的 7.5.4 中 "Missing Association End names" 下的缩进段落。