初次见到OCL是在《应用MDA》这本书中，在介绍DBC（Design by Contract，契约式设计）时候提到了OCL，当时的感觉是OCL适合用于规定方法的前置条件和后置条件。匆匆一瞥，未能留下什么映像。再次见到OCL是在OMG的UML2.0规范中，OMG大张旗鼓的将OCL从UML的附属中分离出来，单独作为UML的一个部分，名字就叫做Response to the UML 2.0 OCL RfP (ad/2000-09-03)。但是单从规范来看，OCL纷繁迷乱，未见其如此值得重视之处。以后却屡屡在E文的paper中遭遇OCL，最有名的就是昨天看的“A Relational Approach to Defining Transformations in a Metamodel”，文中简直将OCL作为一种形式化语言来定义了元模型的转换。这下我真的看到了OCL的强大威力。它没有晦涩的形式化符号，却有着与其相当的表达能力，通过OCL约束的UML类图才真正精确的表达了设计的概念。无论目前国内应用OCL的前景如何，它都是一门值得关注的技术。
为什么要OCL？
OCL的规范是这样解释它的由来：A UML diagram, such as a class diagram, is typically not refined enough to provide all the relevant aspects of a specification. There is, among other things, a need to describe additional constraints about the objects in the model. Such constraints are often described in natural language. Practice has shown that this will always result in ambiguities. In order to write unambiguous constraints, so-called formal languages have been developed. The disadvantage of traditional formal languages is that they are usable to persons with a strong mathematical background, but difficult for the average business or system modeler to use.
OCL has been developed to fill this gap. It is a formal language that remains easy to read and write. It has been developed as a business modeling language within the IBM Insurance division, and has its roots in the Syntropy method.
（UML图（例如类图）通常不够精细，无法提供与规范有关的所有相关部分。这其中就缺少描述模型中关于对象的附加约束。这些约束常常用自然语言描述。而实践表明，这样做经常造成歧义。为了写出无歧义的约束，已经开发出几种所谓的“形式语言”。传统上的形式语言，缺点是仅适合于有相当数学背景的人员，普通商务或系统建模者则难以使用。
OCL即为填补这一空白而来。它是一种保留了易读易写特点的形式语言。它已在IBM的保险分部作为一种业务建模语言开发出来，根植于 Syntropy 方法。）
OCL的入门介绍
Mdachina论坛的笨蛋01，提供了OCL的入门教程，我就不再复述了。（注意论坛目前在调整期，地址可能很快过期。不过www.mdachina.net还是可以作为长期的论坛入口）
OCL的特性
Jos Warmer和Anneke Kleppe在他们的著作《Object Constraint Language, The: Getting Your Models Ready for MDA》第二版中详细介绍了OCL的4个特性。
1. OCL是查询（Query）语言也是约束（Constraint）语言：
A constraint is a restriction on one or more values of (part of) an object-oriented model or system.一个约束就是对一个（或部分）面向对象模型或者系统的一个或者一些值的限制。UML类图中的所有值都可以被约束，而表达这些约束的方法就是OCL。
在UML2标准中，OCL不仅用来写约束，还能够用来对UML图中的任何元素写表达式。每个OCL表达式都能指出系统中的一个值或者对象。因为OCL表达式能够求出一个系统中的任何值或者值的集合，因此它具有了和SQL同样的能力。SQL和OCL都不是约束语言，因为OCL既是约束语言，同时也是查询语言。
2. OCL是基于数学的，但没有使用数学符号
OCL的基础是数学中的集合论和谓词逻辑，并且它有一个形式化的数学语义。但是它并没有使用某种数学符号。因为虽然数学符号能够清晰的、无歧义的表达事物，但是只有极少的专家可以看懂。所以数学符号并不适合用于一个广泛应用的标准语言。
自然语言是最易懂的，但是它是含混不清晰的。OCL取了自然语言和数学符号的折中方案，使用普通的ASCII字符来表达数学中同样的概念。如果你不喜欢当前的OCL表达方法，OCL规范还允许你定义自己的OCL符号集，这点是可以理解的，因为OCL有一个清晰的数学语义。
3. 强类型的语言
OCL是一个类型语言，任何表达式的值都是属于一个类型的。这个类型可以是预定义的标准类型例如Boolean或者Integer，也可以是UML图中的元素例如对象。也可以是这些元素组成的集合，例如对象的集合、包、有序集合等等。
流行的类型语义有Java，C++等，流行的无类型语言有VB，好像JavaScript也是。
4. 宣言式（Declarative）的语言
Declarative翻译为宣言式的我不知道是否正确，但是对理解其含义并没有影响。与Declarative language相对应的是过程式的语言（procedural language）。过程式语言，类似编程语言，描述了动作执行的步骤。但是在宣言式的语言中，表达式仅仅描述了应该去做“什么”，而不是应该“怎样”去做。为了保证这一点，OCL的表达式是没有副作用的，也就是说，计算一个OCL表达式的值不会对系统的状态产生任何改变。
因为OCL是宣言式语言，所以UML中的表达式被提升到了纯建模的领域，而不必理会实现的细节和实现的语言。表达式在高的抽象层次上规定了系统的值，从而保留了100％的精确。
从游击队到正规军
作为主流的建模语言，UML始终处于不冷不热的地步，老像是游击队，打一枪换一个地方，很难有人将UML自始至终的贯彻。OMG觉得“没有纪律的部队是不能打仗的”，因此加上了OCL这个“军令”，希望能够建设建模领域的“正规军”。但是如果要详细的用OCL描述所有约束，那么在设计阶段花费的时间就会大量增加，是否能够在开发的后期得到效率和质量上的补偿呢？我们只能希望如此。
另外，MML（Modeling Maturity Levels，模型成熟度层次）分为5层，要想能够贯彻MDA方法，模型成熟度必须达到level4，即精确的模型，但是精确的模型目前只能用OCL加UML来描述。所以，OCL也是通向MDA的必经之路。到底它是通向MDA之路的桥梁还是绊脚石呢？