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