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

Question

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

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

我非常有兴趣了解您在项目中使用Alloy时可能遇到的任何实际经验。 您是否认为它帮助您设计了更好的域模型？ 在验证期间是否在您的域模型中发现错误？ 你会再次使用它吗？

Answer 1

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

在2006年和2007年，我为当时的W3C XProc规范草案创建了一个部分合金模型; 据我所知，工作组的大多数成员从未阅读过我写过的论文（ http://www.w3.org/XML/XProc/2006/12/alloy-models/models.html ）; 他们说：“哦，我们上周改变了规范的那一部分，所以模型说不再具有相关性”。 但该文件确实设法说服规范的编辑，该规范初稿中描述的抽象“组件”级别严重不足，需要完全指定或删除。 他放弃了它（我认为）对规范的可读性和可用性有好的结果。

2010年，我制作了XPath 1.0数据模型的Alloy模型，该模型揭示了规范中的一些故障。 不幸的是，大多数利益相关方（包括负责维护XPath 1.0规范的W3C工作组）的反应并不令人鼓舞。

我参与的一个研究项目使用Alloy来模拟MLCD重叠语料库，这是我们正在创建的样本文档和相关信息的集合（超链接在SO的坚持下被压制）; Alloy模型在我们的语料库目录初始设计中发现了一些错误，因此值得付出努力。

我们还使用Alloy来形式化我们在转录的性质和类型/令牌区别到文档结构的扩展方面所做的一些建模工作（对于我们的论文，寻找2010年的Balisage会议记录：标记会议）。 这在Alloy通常的应用领域之外有一点点，因为它与软件设计无关，但是Alloy检查模型的一致性和生成实例的能力对于向我们展示这个或那个可能的公理的一些逻辑结果是非常宝贵的。对于我们的模型。

回答你的具体问题：是的，Alloy帮我指定了更清晰的领域模型，是的，它发现了错误和故障。 它们通常很小，因为Daniel Jackson在他的书“ 软件抽象”中解释过：首先，如果你在设计过程中使用模型，你会在一切都很小的时候及早发现错误。 而且，第二个（用杰克逊的话来说），“事后看来，大多数软件设计问题都是微不足道的。”

他继续道：“但如果你不直接解决这些问题，琐碎的问题就会变成一种令人讨厌的习惯。” 我的经历充分证实了这一点。 更好地提前解决这些问题。 是的，我会再次使用Alloy。

Answer 2

是的，我在工业上使用过合金和它的表兄弟。 合金最有助于说服我的模型不是非常错误 - 或者更确切地说，告诉我他们错在哪里并产生愚蠢的结果。 其他更具体的工具，如Song的Athena和Guttman以及Ramsdell的CPSA在其较窄的领域中更有用。 你还想听到什么？

Answer 3

姗姗来迟加入这个线程... Eunsuk Kang最近应用Alloy对一些初创企业进行Web API的安全性分析（遵循Apurva 对OAuth的分析和Barth等人对基于浏览器的安全机制的分析） CSRF等）; Pamela Zave一直致力于对Chord进行令人印象深刻的分析 ，这是一种点对点存储系统，并且最近已经对原始算法进行了修复。