我试图弄清楚为什么我们首先解决设计问题并决定使用可视化方法 (UML)，而不是从碰巧也可以执行的正式规范（RAD 原型设计）开始，我们从可以'的图表开始'不容易证明有效。所以当需要证明模型的属性时，我们发现我们需要在设计中定义约束，因此我们设计了一种形式语法（OCL）来定义模型上的约束。我很难理解这种回到我们开始的地方的飞跃。我发现 OCL 阻碍的 UML 设计（甚至是小册子中显示的示例）不可读，甚至比无数 UML 符号和约定更难以理解。所以我想知道的是：OCL 在当今工作软件开发世界中使用的关键领域是什么，它对谁有意义或值得学习？你的工作角色是什么样的？从不编写代码的架构师会使用 UML 和 OCL，还是与实现它的团队一起设计和架构系统的程序员也使用它？
[更新：其次，在我看来，敏捷开发似乎有点反对“重量级”程序，并且像 OCL 这样的设计图约束的领域特定语言似乎不是很敏捷。UML+OCL 是否在任何“敏捷”商店中使用，还是被 Scrummers 普遍回避？]
有趣的问题。
对象约束语言的“圣杯”是提供一个框架，当与 UML 结合时，允许工具将其转换为具体的对象图/元模型，即一组已经具有基本结构和约束的类，因此，开发人员所要做的就是实现业务方法。（所有这些都以独立于语言的方式）
Borland 的 JBuilder 尝试在他们的企业版中支持这一点，而带有 ECO 的 Delphi 也通过支持 Query 能力以一种实用的方式（虽然不是作为转换输入）使用了 OCL。事实上，来自 Borland / BoldSoft 和 ECO 团队之一的 Anders Inver 撰写了 OCL 圣经《对象约束语言》第二版的前言（addison wesley）
我个人的观点是，没有足够的回报来保证学习曲线。如果不使用专门的（和昂贵的）工具，UML/OCL 模型仍然不容易在实际条件下进行测试，并且您获得的价值与迭代测试驱动开发相比是微不足道的（如果有的话）。语言独立性被高估了，一旦我们开始使用 Java、C#、Delphi、C++ 或任何路径，就让我们面对它吧，我们不可能在其他东西中重新生成，它只是不实用。
对于它的价值，我还没有看到使用 OCL 的模型驱动开发在现实世界中实际用于实际项目。（除了作为概念证明之外）最近在现实世界中似乎起作用的是敏捷流程、Scrum 等，以及使用标准 IDE 和标准语言和用户故事（可能是白板或故事板上的一些 UML）的迭代开发。
在模型上定义 OCL 约束的好处是可以指定域的所有业务规则，这些规则不能用 UML 的图形结构表示（例如，多重性是可以用图形表示为关联定义的一部分的约束） ，说 C 类的属性 A 必须大于 5 也是一个约束，但在这种情况下必须在 OCL 中定义，因为 UML 没有为此提供图形语法）
显然，如果代码生成工具能够接受这些约束并自动生成执行它们的代码（例如，Java 方法中的 if 条件或数据库中的触发器，当数据违反规则时引发异常），这将非常有用。规则）。
不幸的是，提供此功能的工具并不多（请参阅此处的列表：http: //modeling-languages.com/content/list-ocl-tools），但情况正在慢慢改善
作为我学士论文的一小部分，我使用了 OCL Constraints。Borland（现在的 Microfocus）Together 有一个有趣的方法，因此可以从 OCL 约束生成 Java 代码。您定义变量 X 应该 >= 0 或不为空，并且 Together 创建了断言命令来自动验证它。
发生了很大变化。
UML 2.5 使用 Eclipse OCL 工具来修复 UML 2.0...2.4 嵌入式 OCL 中的众多错误。
SysML 下一步将使用 Papyrus 和 Eclipse OCL 工具用于 SysML。
Eclipse OCL 提供了更强大的 UI 和 OCL2Java 代码生成器，因此嵌入在 Ecore/UML 中的 OCL 提供了更多可接受/可执行的代码。
仍有许多需要改变。
UML 中嵌入的 OCL 从未被认真执行过。
OCL 本身的 OCL 定义是可悲的。