War*_* P 2 oop uml jbuilder borland-together ocl
我试图绕过为什么我们首先解决设计问题并决定采用可视化方法（UML）的原因，而不是从碰巧也是可执行的正式规范（RAD原型）开始，我们从可以不容易被证明有效。因此，当需要证明模型的属性时，我们发现需要在设计中定义约束，因此我们设计了形式语法（OCL）来定义模型上的约束。我很难理解这一飞跃回到我们开始的地方。我发现OCL困扰的UML设计（甚至是小册子中显示的示例）也不可读，甚至比无数的UML符号和约定更难以理解。因此，我想知道的是：在当今的软件开发世界中，使用OCL的关键领域是什么，与谁相关或值得学习？您的工作角色是什么样的？从来不编写代码的架构师是否使用UML和OCL，还是也与实现该代码的团队相同的程序员来设计和架构系统？
[更新：其次，在我看来，敏捷开发似乎与“重量级”过程相反，并且像OCL这样的用于设计图约束的领域特定语言似乎并不十分敏捷。是否在任何“敏捷”商店中使用UML + OCL，还是Scrummers普遍避开了它？]
有趣的问题。
对象约束语言的“圣杯”是提供一个框架，当与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）进行的开发。