一段时间以来，我一直对形式化方法感兴趣。我已经使用正式的方法来推理我一直在从事的几个项目的一些非常具体的子领域。我永远无法说服其他团队成员尝试相同的方法，更不用说使用正式的方法指定整个域了。
我发现一种特别有趣的方法是Alloy。我认为它可以更好地“扩展”作为整个项目的基础，因为它在概念上和符号上非常接近实际的编程语言。此外，这些工具非常可靠，因此模型验证的好处很容易获得。
我很想听听你们在项目中使用 Alloy 的实际经验。你觉得它帮助你设计了一个更好的领域模型吗？验证期间是否在您的域模型中发现错误？你会再次使用它吗？
我在几个项目中使用过 Alloy，发现它很有帮助；在一些但不是全部的项目中，我能够说服其他相关人员也使用 Alloy，或者至少使用我编写的 Alloy 模型。这些项目可能是也可能不是您在要求“现实世界”项目时所想到的，但它们肯定发生在我工作的现实世界的一部分。
在 2006 年和 2007 年，我为当时的 W3C XProc 规范草案创建了部分合金模型；据我所知，工作组的大多数成员从未读过我写的论文（http://www.w3.org/XML/XProc/2006/12/alloy-models/models.html）；他们说“哦，我们上周更改了规范的那部分，所以模型所说的不再相关”。但是这篇论文确实说服了规范的编辑，规范第一稿中描述的抽象“组件”级别被严重低估，需要完全指定或删除。他放弃了它，（我认为）对规范的可读性和可用性有很好的结果。
2010 年，我制作了XPath 1.0 数据模型的合金模型，它发现了规范中的一些漏洞。遗憾的是，大多数相关方（包括负责维护 XPath 1.0 规范的 W3C 工作组）的反应并不令人鼓舞。
我参与的一个研究项目使用 Alloy 对 MLCD 重叠语料库进行建模，这是我们正在创建的样本文档和相关信息的集合（在 SO 的坚持下禁止了超链接）；Alloy 模型在我们对语料库目录的初始设计中发现了一些错误，因此值得付出努力。
我们还使用 Alloy 将我们所做的一些建模工作形式化，这些工作涉及转录的性质以及将类型/标记区分扩展到文档结构（对于我们的论文，请查找 2010 年 Balisage 的论文集：标记会议）。这有点超出了 Alloy 通常的应用领域，因为它与软件设计无关，但是 Alloy 检查模型的一致性和生成实例的能力对于向我们展示这个或那个可能的公理的一些逻辑后果是非常宝贵的对于我们的模型。
回答您的具体问题：是的，Alloy 帮助我指定了更清晰的域模型，是的，它发现了错误和故障。它们通常很小，原因是 Daniel Jackson 在他的《软件抽象》一书中解释道：首先，如果你在设计过程中使用模型，你会在一切都还很小的时候尽早发现错误。其次（用杰克逊的话来说），“事后看来，大多数软件设计问题都是微不足道的。”
他继续说：“但如果你不正面解决它们，琐碎的问题就会变得不平凡，这是一种令人讨厌的习惯。” 我的经验充分证实了这一点。尽早阻止此类问题要好得多。所以是的，我会再次使用合金。
是的，我用过合金，它是工业上的表亲。Alloy 在让我相信我的模型并没有大错特错方面最有帮助——或者更确切地说，向我展示了它们在哪里出错并导致了愚蠢的结果。其他更具体的工具，如 Song 的 Athena 和 Guttman 以及 Ramsdell 的 CPSA，在其较窄的领域中更有用。你还想听什么？
姗姗来迟地添加到这个线程...... Eunsuk Kang 最近应用 Alloy 为一些初创公司执行 Web API 的安全分析（遵循 Alloy 在安全方面的许多应用，例如 Apurva对 OAuth 的分析和 Barth 等人对基于浏览器的安全机制的分析CSRF等）；Pamela Zave 一直致力于对Chord（一种点对点存储系统）进行令人印象深刻的分析，并且最近编写了对原始算法的修复。