formal-methods - 在实际项目中使用 Alloy 的经验

Question

一段时间以来，我一直对形式方法感兴趣。我已经使用正式的方法来推理我一直在从事的一些项目的一些非常具体的子领域。我永远无法说服其他团队成员尝试相同的方法，更不用说用正式的方法指定整个域了。

我发现特别有趣的一种方法是 Alloy .我认为它可以作为整个项目的基础更好地“扩展”，因为它在概念和符号上非常接近实际的编程语言。此外，这些工具非常可靠，因此很容易获得模型验证的好处。

我很想听听你们在项目中使用 Alloy 的真实体验。你觉得它帮助你设计了一个更好的领域模型吗？在验证过程中是否在您的域模型中发现错误？你会再次使用它吗？

Answer 1

我在一些项目中使用了 Alloy，发现它很有帮助；在一些但不是所有这些项目中，我已经能够说服其他相关人员也使用 Alloy，或者至少使用我编写的 Alloy 模型。这些项目可能是也可能不是您在要求“现实世界”项目时所想到的，但它们肯定发生在我工作的现实世界中。

在 2006 和 2007 年，我为当时的 W3C XProc 规范草案创建了部分 Alloy 模型；据我所知，工作组的大多数成员从未读过我写的论文(在 http://www.w3.org/XML/XProc/2006/12/alloy-models/models.html)；他们说“哦，我们上周更改了规范的那部分，所以模型所说的不再相关”。但是这篇论文确实说服了规范的编辑，规范的第一稿中描述的抽象“组件”级别严重不足，需要完全指定或删除。他放弃了它，(我认为)在规范的可读性和可用性方面取得了良好的结果。

2010 年我做了一个 Alloy model of the XPath 1.0 data model ，它发现了规范中的一些小故障。不幸的是，大多数相关方(包括负责维护 XPath 1.0 规范的 W3C 工作组)的 react 并不令人鼓舞。

我参与的一个研究项目使用 Alloy 对 MLCD Overlap Corpus 进行建模，这是我们正在创建的示例文档和相关信息的集合(超链接在 SO 的坚持下被压制)； Alloy 模型在我们对语料库目录的初始设计中发现了一些错误，因此值得付出努力。

我们还使用 Alloy 将我们在转录的性质和类型/标记区分扩展到文档结构方面所做的一些建模工作正式化(对于我们的论文，请查看 2010 年 Balisage session 记录:标记 session )。这有点超出 Alloy 通常的应用领域，因为它与软件设计无关，但是 Alloy 检查模型一致性和生成实例的能力对于向我们展示这个或那个可能公理的一些逻辑后果是非常宝贵的对于我们的模型。

回答您的具体问题:是的，Alloy 帮助我指定了更清晰的域模型，是的，它发现了错误和故障。它们通常很小，这是因为 Daniel Jackson 在他的《软件抽象》一书中解释的原因:首先，如果您在设计期间使用模型，您会在一切还很小的时候尽早发现错误。其次(用 jackson 的话来说)，“事后看来，大多数软件设计问题都是微不足道的。”

他继续说道:“但如果你不正面解决它们，琐碎的问题就会变成不平凡的坏习惯。”我的经历充分证实了这一点。尽早解决此类问题要好得多。所以是的，我会再次使用合金。