我试图理解为什么我们首先解决设计问题并决定可视化方法(UML)，而不是从碰巧也是可执行的正式规范(RAD 原型(prototype)设计)开始，而是从图表开始这不容易被证明有效。因此，当需要证明模型的属性时，我们发现需要在设计中定义约束，因此我们设计了一种形式语法(OCL)来定义模型的约束。我很难理解这种回到我们开始的地方的飞跃。 我发现 OCL 阻碍了 UML 设计(甚至小册子中显示的示例)难以阅读，甚至比无数的 UML 符号和约定更难以理解。所以我想知道的是:OCL 在当今的软件开发世界中使用的关键领域是什么，对于谁来说相关或值得学习？您的工作角色是什么样的？从不编写代码的架构师是否使用 UML 和 OCL，或者与实现它的同一团队一起设计和架构系统的程序员也使用它？
[更新:其次，我认为敏捷开发似乎有点与“重量级”程序相对立，并且像 OCL 这样的用于设计图约束的领域特定语言似乎不太敏捷。 UML+OCL 是否在任何“敏捷”商店中使用，还是 Scrummers 普遍回避的？]
最佳答案
有趣的问题。
对象约束语言的“ chalice ”是提供一个框架，当与 UML 结合时，允许工具将其转换为具体的对象图/元模型，即一组已经具有基本结构和约束的类连接起来，因此开发人员所要做的就是实现业务方法。 (所有这一切都以独立于语言的方式进行)
Borland 的 JBuilder 尝试在其企业版中支持这一点，并且带有 ECO 的 Delphi 也通过支持查询功能以实用的方式(尽管不是作为转换输入)使用 OCL。事实上，来自 Borland/BoldSoft 的 Anders Inver(ECO 团队成员之一)撰写了 OCL 圣经《对象约束语言》第二版的前言(addison wesley)我个人的观点是，没有足够的返回来保证学习曲线。如果不使用专门的(且昂贵的)工具，UML/OCL 模型实际上仍然不容易测试，并且与迭代测试驱动开发相比，您获得的值(value)是微不足道的(如果有的话)。语言独立性的事情被高估了，让我们面对现实吧，一旦我们开始使用 Java、C#、Delphi、C++ 或其他任何路径，我们根本不可能在其他东西中重新生成，它只是不切实际。
就其值(value)而言，我还没有看到 OCL 的模型驱动开发在现实世界中的实际项目中实际使用。 (除了作为概念证明)最近在现实世界中起作用的似乎是敏捷流程、Scrum 等，以及使用标准 IDE 和标准语言和用户故事(可能是白板或 Storyboard上的一些 UML)的迭代开发。
关于uml - 有人用 OCL 来使用 UML 吗？程序员使用它还是只有不编码的分析师才使用它？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3304610/