有序超集的 UML 子集

Question

某些属性被定义为具有

{ordered}

约束的继承属性的子集，例如：

RedefinableTemplateParameter::/inheritedParameter

子集

TemplateSignature::parameter

（请参阅 UML 2.5.1 规范的 PDF 文件的第 196 页和第 99 页）。后者是

{ordered}

，但子集没有定义为有序的。

事实上，对于派生属性

RedefinableTemplateParameter::/inheritedParameter

给出的OCL实现如下：

inheritedParameter() : TemplateParameter [0..*]
Derivation for RedefinableTemplateSignature::/inheritedParameter

body: if extendedSignature->isEmpty() then Set{} else extendedSignature.parameter->asSet()
endif

或许继承的财产不需要排序？或者是否隐含地假设超集的排序将延续到子集？

Answer 1

你对黑暗角落的探索太深了。您必须记住，UML 规范是由一个善意的委员会在有限的工具支持下所做的最大努力。

UML 还允许您绘制面向模型的 C++ 或 Java 系统的漂亮图片。由于 super 的调用是程序员的自由裁量权，遵守里氏替换原则是一种设计选择，因此 UML 必须支持该选择。 （干净的建模语言不会有在分析时被 OCL 忽略的私有/受保护/公共。相反，它们应该是代码生成器标记。）

LSP 将规定对有序/唯一特征进行子集化必须产生相应的有序/唯一派生特征，因为调用超级访问器应该返回超级类型。但在非 LSP 世界中，超级访问器可能不存在，或者实现者可能只是想禁止用户利用有序/唯一或具有奇怪的多重继承方面。

随着

redefines

，情况会变得更糟，事情真的可能会发生不兼容的变化。

redefines

的初衷似乎是手动“实现”UML元模型的重载算法。然而，对于用户模型，UML 指定 OCL 指定重载，相应地，OCL 指定 UML 指定重载。尽管如此，

redefines

的灵活性允许建模者创建完全难以理解/无法实现的设计。

对于您的具体示例，拼写

parameter

而不是更一致的

ownedParameters

可能会让作者感到困惑，认为只有一个，因此顺序是无关紧要的。