有人用 OCL 来使用 UML 吗？程序员使用它还是只有不编码的分析师使用它？
我试图弄清楚为什么我们首先解决设计问题并决定采用可视化方法（UML），而不是从恰好也是可执行的正式规范（RAD 原型设计）开始，而是从可以的图表开始不容易被证明有效。因此，当需要证明模型的属性时，我们发现需要在设计中定义约束，因此我们设计了一种形式语法（OCL）来定义模型的约束。我很难理解这种回到我们开始的地方的飞跃。 我发现 OCL 阻碍了 UML 设计（甚至小册子中显示的示例）难以阅读，甚至比无数的 UML 符号和约定更难以理解。所以我想知道的是：OCL 在当今的软件开发世界中使用的关键领域是什么，对于谁来说相关或值得学习？您的工作角色是什么样的？从未编写代码的架构师是否使用 UML 和 OCL，或者与实现它的同一团队一起设计和构建系统的程序员也使用它吗？
[更新：其次，我认为敏捷开发似乎与“重量级”程序相对立，并且像 OCL 这样的用于设计图约束的领域特定语言似乎不太敏捷。 UML+OCL 是否在任何“敏捷”商店中使用，还是 Scrummers 普遍回避的？]
I am trying to wrap my head around why we first approach the problem of design and decide upon a visual method (UML), instead of starting with formal specifications that happen to also be executable (RAD prototyping), we start with diagrams that can't be easily proven to work. So when it comes time to prove properties of a model, we find we need to define constraints into our design, so we design a formal syntax (OCL) to define the constraints on the model. I am having a hard time understanding this leap back to where we started.
I find OCL encumbered UML designs (even samples shown in brochures) unreadable, even more impenetrable than the myriad of UML symbols and conventions. So what I want to know is: What are the key areas where OCL is used in the working software development world today, and for whom is it relevant or worthwhile to learn? What does your job role look like? Do architects who never write code use UML and OCL, or do programmers who also design and architect the systems with the same team that implements it, use it too?
[updated: Secondly, it occurs to me that Agile development seems kind of opposed to "Heavyweight" procedures, and that a domain specific language for design diagram constraints like OCL doesn't seem very Agile. Is UML+OCL used in ANY "Agile" shops, or is it universally eschewed by Scrummers?]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
有趣的问题。
对象约束语言的“圣杯”是提供一个框架，当与 UML 结合时，允许工具将其转换为具体的对象图/元模型，即一组已经连接了基本结构和约束的类，因此开发人员所要做的就是实现业务方法。 （所有这些都以与语言无关的方式进行）
Borland 的 JBuilder 尝试在其企业版中支持这一点，并且带有 ECO 的 Delphi 也通过支持查询功能以实用的方式（尽管不是作为转换输入）使用 OCL。事实上，来自 Borland / BoldSoft 的 Anders Inver 以及 ECO 团队的成员之一，撰写了 OCL 圣经《对象约束语言》第二版 (addison wesley) 的前言。
我个人的观点是，没有足够的回报来保证学习曲线。如果不使用专门的（且昂贵的）工具，UML/OCL 模型实际上仍然不容易测试，并且与迭代测试驱动开发相比，您获得的价值是微不足道的（如果有的话）。语言独立性的事情被高估了，让我们面对现实吧，一旦我们开始使用 Java、C#、Delphi、C++ 或任何其他路径，我们根本不可能在其他东西中重新生成，它只是不切实际。
就其价值而言，我还没有看到 OCL 的模型驱动开发在现实世界中的实际项目中实际使用。 （除了作为概念证明）最近在现实世界中起作用的似乎是敏捷流程、Scrum 等，以及使用标准 IDE 和标准语言和用户故事（可能是白板或故事板上的一些 UML）的迭代开发。
Interesting question.
The "holy grail" of the Object Constraint Language was to provide a framework that when coupled with UML allowed a tool to transform that into a concrete Object Graph / Meta Model i.e. a set of classes that already had their basic structure and constraints wired in, so that all the developer had to do was implement business methods. (all this in a language independent way)
JBuilder from Borland tried supoprting this in their enterprise edition, and Delphi with ECO also made use of OCL in a practical way (though not as a transformation input) by supporting the Query abilities. In fact Anders Inver from Borland / BoldSoft, and one of the ECO team, wrote the forward on the OCL bible, The Object Constraint Language, Second Edition (addison wesley)
My personal opinion is that there is not enough pay back to warrant the learning curve. Without using specialised (and expensive) tools the UML/OCL model is still not easily testable in real terms, and the value you get is marginal (if anything) over itterative test driven development. The language independence thing is waaay overrated, lets face it once we start down the Java, C#, Delphi, C++ or whatever path, there is no way in hell we will re-generate in something else, its just not practical.
For what its worth, I am yet to see Model Driven Development with OCL actually used in the real world for a real project. (other than as a proof of concept) What seems to be working lately in the real world is Agile processes, Scrum etc and just itterative development using standard IDE's with standard languages and user stories (perhaps some UML on a whiteboard or storyboard).
在模型上定义 OCL 约束的好处是可以指定域中无法用 UML 的图形结构表示的所有业务规则（例如，多重性是可以作为关联定义的一部分以图形方式表示的约束） ，说类 C 的属性 A 必须大于 5 也是一个约束，但在这种情况下必须在 OCL 中定义，因为 UML 没有为此提供图形语法）
显然，如果代码 -生成工具将能够接受这些约束并自动生成强制执行它们的代码（例如，作为Java方法中的if条件或作为数据库中的触发器，当数据违反规则时引发异常）。
不幸的是，提供此功能的工具并不多（请参阅此处的列表：http:// /modeling-languages.com/content/list-ocl-tools）但情况正在慢慢改善
The benefit of defining OCL constraints on your models is the possibility of specifying all the business rules of your domain that you cannot represent with the graphical constructs of the UML (for instance, multiplicities are constraints that can be graphically represented as part of an association definition, saying that the attribute A of class C has to be greater than 5 is also a constraint but in this case has to be defined in OCL since UML does not provide a graphical syntax for this)
Obviously, this would be very useful if code-generation tools would be able to take these constraints and automatically generate a code that enforces them (e.g. as if-conditions in Java methods or as triggers in databases that raise an exception when the data violates the rule).
Unfortunately, there aren't many tools offering this functionality (see a list here: http://modeling-languages.com/content/list-ocl-tools) but the situation is slowly improving
发生了很多变化。
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定义是可悲的。
Much has changed.
UML 2.5 used Eclipse OCL tooling to remedy the numerous bugs in the UML 2.0...2.4 embedded OCL.
SysML is using Papyrus and Eclipse OCL tooling for SysML next.
Eclipse OCL provides a much stronger UI and an OCL2Java code generator so that OCL embedded in Ecore/UML provides much more acceptable/executable code.
Much has still to change.
The OCL embedded in UML has never been seriously executed.
The OCL definition of OCL itself is lamentable.
我使用 OCL 约束作为我学士论文的一小部分。 Borland（现在的 Microfocus）Together 有一个有趣的方法，从而根据 OCL 约束生成 Java 代码。您定义变量 X 应 >= 0 或不为空，并且 Together 创建了断言命令来自动验证它。
I worked with OCL Constraints as a small part of my bachelor thesis. Borland (now Microfocus) Together had an interesting approach thus generating Java code out of OCL Constraints. You defined that variable X should be >= 0 or not empty and Together created assert commands to verify it automatically.