OCL需要吗

OCL应用方面确实存在不少观望者，这有两个原因：

1）他们认为：模型只适用于展示待构建系统的bigPicture，怀疑模型生成代码和模型可执行的开发范式的功用性。

2）OCL没有好的工具支持。

 

第1个原因，我想从另一个角度应答：

OCL并非仅用于表达UML模型的计算完整性，应用OCL应归属到形式化方法（见形式化方法列表：http://www.afm.sbu.ac.uk/）。在崇尚形式化方法的欧洲，应用形式化软件工程的例子有很多（详见形式化欧洲站点http://www.fmeurope.org/），使用的过程和工具有： RAISE（超过15年工业经验的严格形式化软件工程方法）、LOTOS（OSI大部分规范的工作语言）、Z/VDM/ADM/B（流行的形式化语言）。

OCL在描述前件/后件/不变式规范方面比Z/VDM/ADM/B要容易使用，且近几年半形化的UML趋向于形式化，这是欧洲积极开发OCL及UML等工具和过程环境的一个原因，例子有：neptune（欧盟）、UMLAUT（法国）。另一个应用OCL的例子是OCL for JavaCard spec（http://i11www.ilkd.uni-karlsruhe.de/~baar/oclworkshopUml03/）。

 

模型生成代码和模型可执行的必要而非充分条件是：精确的模型和形式化的模型，从这里我们可以看到模型驱动构架朝着形式化软件工程迈进的趋势，这在UML2.0Infrastructure的Chapter 1. Language Architecture已有暗示。事实上，模型驱动构架是应用形式化方法定义的ISO标准的开放分布式处理参考模型RM-ODP（http://www.dstc.edu.au/Research/Projects/ODP/standards.html）的一个半形式化版，

 

绕了一大圈，无非是想说明：在要求严格的软件开发方法中，合里的使用OCL或更高级的形式语言至少是有效的。至于形式化软件工程是不是解决软件自身问题（这也是软件工程提出的原因）的有效方法，存在很多争论，这里就不多说了。

 

第2个原因，现在已有一些支持OCL环境

ArchStyler、集成Dresden OCL Toolkit的Argo/UML、Bold for Delphi。下一版的OptimalJ将支持OCL。在模型驱动构架工具中集成OCL支持是必然的。

 

使用OCL的最小利益是：用OCL精化的模型所生成的代码将“自动”包含前件/后件/不变式，这不是正是Bertrand Meyer所提倡的DBC原则吗？，所不同的是：在代码级（模型）我们已意识到DBC原则的重要性，在需求级（模型）、设计级（模型），为什么不能意识到呢？