初次見到OCL是在《應(yīng)用MDA》這本書中，在介紹DBC（Design by Contract，契約式設(shè)計）時候提到了OCL，當(dāng)時的感覺是OCL適合用于規(guī)定方法的前置條件和后置條件。匆匆一瞥，未能留下什么映像。再次見到OCL是在OMG的UML2.0規(guī)范中，OMG大張旗鼓的將OCL從UML的附屬中分離出來，單獨作為UML的一個部分，名字就叫做Response to the UML 2.0 OCL RfP (ad/2000-09-03)。但是單從規(guī)范來看，OCL紛繁迷亂，未見其如此值得重視之處。以后卻屢屢在E文的paper中遭遇OCL，最有名的就是昨天看的“A Relational Approach to Defining Transformations in a Metamodel”，文中簡直將OCL作為一種形式化語言來定義了元模型的轉(zhuǎn)換。這下我真的看到了OCL的強大威力。它沒有晦澀的形式化符號，卻有著與其相當(dāng)?shù)谋磉_能力，通過OCL約束的UML類圖才真正精確的表達了設(shè)計的概念。無論目前國內(nèi)應(yīng)用OCL的前景如何，它都是一門值得關(guān)注的技術(shù)。
為什么要OCL？
OCL的規(guī)范是這樣解釋它的由來：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圖（例如類圖）通常不夠精細，無法提供與規(guī)范有關(guān)的所有相關(guān)部分。這其中就缺少描述模型中關(guān)于對象的附加約束。這些約束常常用自然語言描述。而實踐表明，這樣做經(jīng)常造成歧義。為了寫出無歧義的約束，已經(jīng)開發(fā)出幾種所謂的“形式語言”。傳統(tǒng)上的形式語言，缺點是僅適合于有相當(dāng)數(shù)學(xué)背景的人員，普通商務(wù)或系統(tǒng)建模者則難以使用。
OCL即為填補這一空白而來。它是一種保留了易讀易寫特點的形式語言。它已在IBM的保險分部作為一種業(yè)務(wù)建模語言開發(fā)出來，根植于 Syntropy 方法。）
OCL的入門介紹
Mdachina論壇的笨蛋01，提供了OCL的入門教程，我就不再復(fù)述了。（注意論壇目前在調(diào)整期，地址可能很快過期。不過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.一個約束就是對一個（或部分）面向?qū)ο竽Ｐ突蛘呦到y(tǒng)的一個或者一些值的限制。UML類圖中的所有值都可以被約束，而表達這些約束的方法就是OCL。
在UML2標(biāo)準(zhǔn)中，OCL不僅用來寫約束，還能夠用來對UML圖中的任何元素寫表達式。每個OCL表達式都能指出系統(tǒng)中的一個值或者對象。因為OCL表達式能夠求出一個系統(tǒng)中的任何值或者值的集合，因此它具有了和SQL同樣的能力。SQL和OCL都不是約束語言，因為OCL既是約束語言，同時也是查詢語言。
2. OCL是基于數(shù)學(xué)的，但沒有使用數(shù)學(xué)符號
OCL的基礎(chǔ)是數(shù)學(xué)中的集合論和謂詞邏輯，并且它有一個形式化的數(shù)學(xué)語義。但是它并沒有使用某種數(shù)學(xué)符號。因為雖然數(shù)學(xué)符號能夠清晰的、無歧義的表達事物，但是只有極少的專家可以看懂。所以數(shù)學(xué)符號并不適合用于一個廣泛應(yīng)用的標(biāo)準(zhǔn)語言。
自然語言是最易懂的，但是它是含混不清晰的。OCL取了自然語言和數(shù)學(xué)符號的折中方案，使用普通的ASCII字符來表達數(shù)學(xué)中同樣的概念。如果你不喜歡當(dāng)前的OCL表達方法，OCL規(guī)范還允許你定義自己的OCL符號集，這點是可以理解的，因為OCL有一個清晰的數(shù)學(xué)語義。
3. 強類型的語言
OCL是一個類型語言，任何表達式的值都是屬于一個類型的。這個類型可以是預(yù)定義的標(biāo)準(zhǔn)類型例如Boolean或者Integer，也可以是UML圖中的元素例如對象。也可以是這些元素組成的集合，例如對象的集合、包、有序集合等等。
流行的類型語義有Java，C++等，流行的無類型語言有VB，好像JavaScript也是。
4. 宣言式（Declarative）的語言
Declarative翻譯為宣言式的我不知道是否正確，但是對理解其含義并沒有影響。與Declarative language相對應(yīng)的是過程式的語言（procedural language）。過程式語言，類似編程語言，描述了動作執(zhí)行的步驟。但是在宣言式的語言中，表達式僅僅描述了應(yīng)該去做“什么”，而不是應(yīng)該“怎樣”去做。為了保證這一點，OCL的表達式是沒有副作用的，也就是說，計算一個OCL表達式的值不會對系統(tǒng)的狀態(tài)產(chǎn)生任何改變。
因為OCL是宣言式語言，所以UML中的表達式被提升到了純建模的領(lǐng)域，而不必理會實現(xiàn)的細節(jié)和實現(xiàn)的語言。表達式在高的抽象層次上規(guī)定了系統(tǒng)的值，從而保留了100％的精確。
從游擊隊到正規(guī)軍
作為主流的建模語言，UML始終處于不冷不熱的地步，老像是游擊隊，打一槍換一個地方，很難有人將UML自始至終的貫徹。OMG覺得“沒有紀(jì)律的部隊是不能打仗的”，因此加上了OCL這個“軍令”，希望能夠建設(shè)建模領(lǐng)域的“正規(guī)軍”。但是如果要詳細的用OCL描述所有約束，那么在設(shè)計階段花費的時間就會大量增加，是否能夠在開發(fā)的后期得到效率和質(zhì)量上的補償呢？我們只能希望如此。
另外，MML（Modeling Maturity Levels，模型成熟度層次）分為5層，要想能夠貫徹MDA方法，模型成熟度必須達到level4，即精確的模型，但是精確的模型目前只能用OCL加UML來描述。所以，OCL也是通向MDA的必經(jīng)之路。到底它是通向MDA之路的橋梁還是絆腳石呢？