初次見到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之路的橋梁還是絆腳石呢？