问UML概要中扩展原型的约束

EN

如果应用的原型是梅赛德斯，那么

，我会假设

是的你是对的。

梅赛德斯继承了约束，所以self.stereotype.name='Car'是错误的，因为“奔驰”和“汽车”是两个不同的字符串。

如果您想让第一个暗示活动的元类专门性Car直接或间接，您可以得到所有的概括原型本身搜索一个名为“Car”，也检查的概要文件的名称，并可能是它的URI。因此，例如，将self.stereotype.name='Car'替换为：

self.stereotype.profile.name = 'Cars' and
-- self.stereotype.profile.URI= '...' and
self.stereotype.generalization()
  ->closure(general.generalization).general()
    ->including(self.stereotype)
      ->select(name = 'Car')
        ->notEmpty()

或者有一个名为Cars的个人资料，其中有一个单独的刻板印象，名为Car：

self.stereotype.oclIsKindOf(Profile.allInstances()
                              ->any(name = 'Cars') -- may be check also URI
                                 .ownedStereotype->any(name = 'Car'))

补充说明：

在您的建议中，

• 假设在所有配置文件的所有原型中，只有您的原型命名为Car，当然，这可能是错误的。您还可以检查配置文件的名称，并且可能是它的URI，如：

Cars=“Car”和

图中的

• 箭头错误，因为它必须是填充的三角形，而不是< (可能使用PlantUML) :

​

​

如果你想一想，你的要求是不合理的。

假设您的系统已经有了过度热情的限制，即汽车的FuelType是汽油。你很难定义一辆FuelType是柴油的衍生汽车；它不是汽车的wrt，而是汽车的模型定义。

你可以试着用混合器来解决这个问题，但是对于任何实际生产的汽车来说，排列的数量都是无法忍受的。

相反，您可以采用Namespace.isDistinguishable规范所采用的漏洞的方法，比如确定是否需要惟一的名称(允许多个未命名的约束)。

因此，对于Car，您可以定义可以重写的getAcceptableFuelTypes()助手，以便为派生类创建一个漏洞；将基本约束实现为getAcceptableFuelTypes()->includes(fuelType)。