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