【问题标题】:Reasoning about properties of subtypes推理子类型的属性
【发布时间】:2019-04-17 15:32:51
【问题描述】:

我发现自己经常遇到以下情况:

sig Property {}

abstract sig Unit {
  property: some Property
}


sig Hardware, Software, Services extends Unit {}

fact  {
  no Hardware.property & Software.property
  no Hardware.property & Services.property
  no Software.property & Services.property
}

也就是说,我有一个声明属性的抽象签名,以及一些扩展该签名的子类型。我想确保子类型之间的属性property 没有重叠。

将允许Hardware 的两个实例共享property 值,但绝不允许HardwareSoftware 实例具有公共属性。

我真的不想像那样写fact。如果我添加第四种Unit,我很容易搞砸事实。

这感觉就像我需要能够自省类型,但我不知道有什么工具可以做到这一点。

有什么建议吗?

【问题讨论】:

    标签: alloy


    【解决方案1】:

    这可能不是最优雅的解决方案,但您可以为每个单元子类型定义一个属性子类型。

    这样,您就不需要手动编写叉积,从而减少出错的可能性:-)。

    abstract sig Property {}
    
    abstract sig Unit {
      property: some Property
    }
    
    sig Hardware, Software, Services extends Unit {}
    sig PropHard , PropSoft, PropServ extends Property{}
    
    fact {
        Hardware.property in PropHard
        Software.property in PropSoft
        Services.property in PropServ
    }
    

    【讨论】:

    • 我过去使用过类似的方法。也有人建议我可以使用disj [Hardware.property, Software.property, Services.property] 所以我有几个选择,但如果我添加Unit 的新子类型,它们都需要我“记住”做某事
    • 如果该模型需要进行大量更改并长期使用,您总是可以考虑一种自动生成这些附加事实的解决方案 :-)。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-08-31
    • 2021-06-11
    • 2015-04-29
    • 2021-06-06
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多