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原则的重要性，在需求级（模型）、设计级（模型），为什么不能意识到呢？

posted on 2004-08-16 01:16 阿飞外传阅读(3506) 评论(7) 编辑收藏网摘所属分类: MDA

#1楼  回复 引用

Basically,I quite agree with the Author's opinion. OCL is necessary supplemented by JML.
In the future, I predict a wonderful sky of 00A/D based on formal methods. I show you a suite of guidance

language: java(card)
case tool :Borland Together cc(Eclipse)
verification: The dynamci verification
design pattern (AOP is also considered as a special one )
UML/OCL,JML

I am a researcher of formal methods (especially SOFL)
if any one is interested in such domain, Send letters to me
we can communicate freely. (dragonlw@sjtu.edu.cn)

2004-11-21 15:34 | dragon

#2楼  回复 引用

guidances

2004-11-21 15:35 | dragon

#3楼  回复 引用

原来阿飞还有个blog啊,hoho.好久不见了,最近忙什么呢?

我也刚刚看了UML2.0的OCL部分,不论技术,仅仅从商业和标准的角度来看,OCL也是大有可为的.UML作为OMG最为成功的标准之一,OMG花费了大量气力要将其打造成建模领域的通用语言,OCL作为UML的语义精确性的最好补充,也必然成为OMG力推的目标.虽然OCL是Text的,不是Visual的,但是这正好体现了UML语言半text半visual的特性.
现在的代码生成工具中,太text的可读性不高,太visual的又不便于自动生成,OCL+UML图形标识正好继承发扬了UML类图的成功经验,必然在将来受到欢迎.
其实看看现在的很多paper,很多国外的作者都开始用OCL或者是类OCL语言来为自己的模型写约束了.

阿飞,有什么想法记得给我写信啊,wxb_nudt@163.com
或者到qq群里找我.

2004-11-22 15:04 | wxb_nudt

#4楼  回复 引用

一种约束语言应具有两个基本特征：一个是简单，另一个是能解决复杂问题。OCL满足第一个条件，对于第二个条件，我认为不满足。

问题的根源并不在OCL身上，而在UML的图上。UML的图的粒度太粗了，而且没有体系结构方面的支持。只考虑类和方法是不够的，UML图与系统之间的距离太大，我认为需要增加一个层次来描述各种对象是如何构成系统的，在这个层次里OCL将大展手脚。

我们现在需要研究的是PartOf关系、角色的形式性质等基本问题（在UML中这两个东东的潜力基本上没有被使用，所用到的都是浮浅和自然语言的含义，没有形式化的含义。好像在UML2.0中不再称PartOf关系是传递的、反自反，而只保留了生命期的含义。）。

在没有解决这个问题之前，我认为OCL是没有多大用途的，因为都是些简单问题，简单问题有简单的解决方法。目前OCL的潜力没有被完全用上，也不要指望其在现有状况下能解决多大的问题，结构与层次才是最重要的，没有好的结构和层次，OCL的使用将是不自然的、复杂的、不实用的。

我的观点是OCL很有用，现阶段不好用，需要为其提供使用的场景（有形式化含义）。

2005-01-04 10:51 | guest

#5楼  回复 引用

问题的根源并不在OCL身上，而在UML的图上。UML的图的粒度太粗了，而且没有体系结构方面的支持。---UML的部件图(UML2.0支持SA建模)如何？
只考虑类和方法是不够的，UML图与系统之间的距离太大，
我认为需要增加一个层次来描述各种对象是如何构成系统的，在这个层次里OCL将大展手脚。

我们现在需要研究的是PartOf关系、角色的形式性质等基本问题(---关系描述仅是一个方面，
我认为更重要的是UML规范的可执行性(可计算性)及其所提供的规范语境，
而关系只是对执行效果的约束)

（在UML中这两个东东的潜力基本上没有被使用，
所用到的都是浮浅和自然语言的含义(---浮浅?我不认为UML的自然语言描述的语义是肤浅的，只是没有形式化,
看看UMLspec就会知道里面充满了OO大师们对软件构造的认知以及相应描述方法的知识积累，这为所谓的
形式化提供了生存依据)
，没有形式化的含义。
好像在UML2.0中不再称PartOf关系是传递的、反自反，
而只保留了生命期的含义。

）。

在没有解决这个问题之前，我认为OCL是没有多大用途的，
因为都是些简单问题，简单问题有简单的解决方法。
目前OCL的潜力没有被完全用上，也
不要指望其在现有状况下能解决多大的问题，结构与层次才是最重要的，--- UML元模型不是结构化和层次化的么？
没有好的结构和层次，OCL的使用将是不自然的、复杂的、不实用的。

我的观点是OCL很有用，现阶段不好用，需要为其提供使用的场景（有形式化含义）---我认为更重要的是UML规范的可执行性(可计算性)及其所提供的规范语境。