OCL和MDA

閑聊：

我的BLOG又是一周沒(méi)有更新了，倒不是因?yàn)閼校巧现艿拇蟛糠謺r(shí)間花在審閱兩篇稿件上了。而尚未發(fā)表的稿件不能公開(kāi)討論，所以BLOG上面就空空如也了。這幾天集中精力讀《Object Constraint Language, The: Getting Your Models Ready for MDA, Second Edition》這本書(shū)，頗有心得。作者Jos Warmer是OCL的創(chuàng)始人，他對(duì)于這門(mén)語(yǔ)言的把握是最專(zhuān)業(yè)的，而且行文流暢，讀原著如同讀漢語(yǔ)一樣，不由得大發(fā)感慨，“好書(shū)即是好老師”。全書(shū)一共十章，分為兩大部分，第一部分User Manual包括前五章，主要講述OCL的由來(lái)、概念、簡(jiǎn)單的使用和實(shí)現(xiàn)方法，以及與MDA的關(guān)系等；第二部分Reference Manual內(nèi)容要深一些，講述了OCL的一些高級(jí)使用方法。

這幾天奮起疾“書(shū)”，以一天一章的速度看完了前五章，腦中彷佛有豁然開(kāi)朗之感，尤其對(duì)于OCL和MDA的關(guān)系有了新的認(rèn)識(shí)。

OCL和MDA的初感想

要談OCL和MDA之間的關(guān)系，先要搞清楚它們各自的定義。OCL的定義上次已經(jīng)說(shuō)過(guò)了，再貼過(guò)來(lái)看看：UML圖（例如類(lèi)圖）通常不夠精細(xì)，無(wú)法提供與規(guī)范有關(guān)的所有相關(guān)部分。這其中就缺少描述模型中關(guān)于對(duì)象的附加約束。這些約束常常用自然語(yǔ)言描述。而實(shí)踐表明，這樣做經(jīng)常造成歧義。為了寫(xiě)出無(wú)歧義的約束，已經(jīng)開(kāi)發(fā)出幾種所謂的“形式語(yǔ)言”。傳統(tǒng)上的形式語(yǔ)言，缺點(diǎn)是僅適合于有相當(dāng)數(shù)學(xué)背景的人員，普通商務(wù)或系統(tǒng)建模者則難以使用。OCL即為填補(bǔ)這一空白而來(lái)。它是一種保留了易讀易寫(xiě)特點(diǎn)的形式語(yǔ)言。它已在IBM的保險(xiǎn)分部作為一種業(yè)務(wù)建模語(yǔ)言開(kāi)發(fā)出來(lái)，根植于 Syntropy 方法。

而MDA的定義如下：MDA是OMG提出的一種新的軟件開(kāi)發(fā)方法，它定義了基于模型的開(kāi)發(fā)過(guò)程，以及自動(dòng)將模型映射到實(shí)現(xiàn)的方法。它提供了一種使用模型來(lái)指導(dǎo)系統(tǒng)的理解，設(shè)計(jì)，構(gòu)造，開(kāi)發(fā)，操作，維護(hù)和修改的方法。

直觀的來(lái)說(shuō)，MDA是OMG定義的一種軟件開(kāi)發(fā)方法，為了標(biāo)準(zhǔn)化這種開(kāi)發(fā)方法，OMG定義一組規(guī)范來(lái)支持MDA，其中最重要的有：MOF，UML，XMI，CWM。目前MOF，UML和XMI的最新版本都是2.0（CWM不知道，本身就不熟悉它）。在UML2.0的規(guī)范中，用了一個(gè)單獨(dú)的部分來(lái)專(zhuān)門(mén)定義OCL（OCL在UML的較早版本中已經(jīng)定義，不過(guò)沒(méi)有作為單獨(dú)的部分來(lái)定義）。這說(shuō)明，OCL和MDA的關(guān)系是：OCL是MDA眾多標(biāo)準(zhǔn)中的UML標(biāo)準(zhǔn)中的一個(gè)子標(biāo)準(zhǔn)。

但是OCL在MDA中的重要性如何呢？

模型成熟度（Modeling Maturity Levels，MML）

在書(shū)中我首次見(jiàn)到了MML的概念，當(dāng)然不一定是本書(shū)作者提出的，只不過(guò)是我以前孤陋寡聞罷了。MML指出了模型在你的軟件開(kāi)發(fā)過(guò)程中扮演了一個(gè)什么樣的角色？并且指出了為了提高軟件開(kāi)發(fā)效率你應(yīng)該采取什么樣的措施。

下圖畫(huà)出了MML的六層示范圖：

 

    第零層：沒(méi)有標(biāo)準(zhǔn)：模型存在于開(kāi)發(fā)者的頭腦中；

第一層：文本表達(dá)：用自然語(yǔ)言寫(xiě)下想法；

第二層：文本和圖：用自然語(yǔ)言以及一些圖來(lái)表達(dá)想法；

第三層：模型和圖：用建模語(yǔ)言描述的圖來(lái)表達(dá)模型，用自然語(yǔ)言加以輔助描述；

第四層：精確的模型：用一致而連貫的文本/圖來(lái)精確的描述模型，它們都是沒(méi)有歧義的，可以直接映射到編程語(yǔ)言；

第五層：只有模型：第五層的模型是對(duì)于系統(tǒng)的一個(gè)完備的、一致的、詳細(xì)和精確的描述。它足以進(jìn)行全部的代碼生成工作，生成的代碼不需要任何改動(dòng)即可運(yùn)行。總而言之一句話：“模型可運(yùn)行”！

通過(guò)以上MML的描述我們可以了解，如果使用UML來(lái)描述模型，但是不使用OCL來(lái)描述模型中的約束，那么只能達(dá)到第三層。如果使用UML+OCL，那么模型就是精確的，MML可以達(dá)到第四層。如果模型可以達(dá)到MML5，那么是我睡著了。。。當(dāng)然我們堅(jiān)信MML5總有一天會(huì)達(dá)到，那時(shí)我們就可以像使用高級(jí)語(yǔ)言一樣使用建模語(yǔ)言，而像不理今天的匯編一樣不理明天的高級(jí)語(yǔ)言。也許有一種叫做MVM（Model Virtual Machine）的東西就像今天的JVM一樣流行。

OCL用在了MDA的哪些方面？

從上一節(jié)可知，OCL是MDA的必要條件，但遠(yuǎn)遠(yuǎn)不是充分條件。但不可否認(rèn)的是，OCL被廣泛用于MDA的各個(gè)方面。下面的兩張圖可以說(shuō)明一部分問(wèn)題：

第一張圖是MDA的一個(gè)典型的開(kāi)發(fā)流程，建立PIM，描述轉(zhuǎn)換定義，利用轉(zhuǎn)換工具將PIM轉(zhuǎn)換為PSM。第二張圖是OCL在MDA典型開(kāi)發(fā)流程中的使用。其中三個(gè)方面使用了OCL：第一是model的創(chuàng)建使用了OCL來(lái)描述模型中的約束；第二是模型轉(zhuǎn)換的定義可以使用OCL來(lái)描述；第三是建模語(yǔ)言可以使用OCL來(lái)創(chuàng)建。

其中讓人迷惑的是第一和第三有什么區(qū)別呢？用OCL來(lái)約束模型和用OCL來(lái)創(chuàng)建建模語(yǔ)言有什么區(qū)別？區(qū)別在于它們所屬元層次的不同，也就是MOF中所描述的模型層次不同。這不是繞口令！其實(shí)我剛剛接觸MDA的時(shí)候也認(rèn)為模型、元模型、元元模型好像繞口令一樣，但這些概念在接觸中慢慢清晰起來(lái)。用OCL來(lái)約束模型是處于M1層，其模型是指對(duì)系統(tǒng)的描述，例如對(duì)一個(gè)信用卡管理系統(tǒng)的UML模型。而用OCL來(lái)建立建模語(yǔ)言是處于M2層，這時(shí)OCL是用來(lái)描述UML的元模型中存在的約束，因?yàn)樵Ｐ偷扔谀Ｐ偷恼Z(yǔ)言，也就是用OCL來(lái)創(chuàng)建建模語(yǔ)言（可能叫用OCL來(lái)定義建模語(yǔ)言中的約束更好）。下面是一個(gè)UML元模型中使用OCL的例子：

context Interface

inv: features->select(f |f.oclIsKindOf( Attribute ) )->isEmpty()

這個(gè)OCL表達(dá)式說(shuō)明，接口Interface中不能有屬性存在。如果UML的元模型中缺少OCL的描述，那么此元模型就不是一個(gè)“精確”的元模型，那么UML也就不是一個(gè)精確的建模語(yǔ)言了。那么MDA就離我們而去了！

OCL，約束自己，約束父親

    由上可知，雖然OCL號(hào)稱(chēng)“對(duì)象”約束語(yǔ)言，其實(shí)它可以對(duì)MOF的模型層次中的任一層次進(jìn)行約束，從而表達(dá)出精確的模型（四層模型中任一層的模型）。

    OCL可以約束M2層的模型，例如UML的元模型，而OCL的元模型也處于M2層，那么OCL是否可以約束自己的元模型呢？答案是肯定的。

上圖是OCL的元模型簡(jiǎn)化圖，其中也用OCL對(duì)一些地方進(jìn)行了描述：

context LoopExpression

inv: source.oclIsKindOf( Collection )

inv: iteratorVariable.type= source.oclAsType(Collection).elementType

    上面的約束表達(dá)了LoopExpression中source的類(lèi)型必須是Collection，而迭代子iterator的類(lèi)型必須是source這個(gè)Collection中的元素的類(lèi)型。由此可見(jiàn)，OCL的元模型也需要OCL來(lái)約束，否則這個(gè)元模型就是不“精確”的，可以說(shuō)，OCL在某種程度上自定義了自己。

從M0（對(duì)象），M1（模型）到M2（元模型）都可以用OCL來(lái)描述，那么M3層呢？定義UML和OCL元模型的元模型MOF，是否需要用OCL來(lái)約束。答案是肯定的！ 隨便舉一個(gè)例子：

[1] The multiplicity of Association::memberEnd is limited to 2 rather than 2..* (i.e. n-ary Associations are not supported).

context Association inv: memberEnd->size() = 2

[2] The type of Operation::raisedException is limited to be Class rather than Type.

context Operation inv: raisedException.oclIsType(Class)

約束1說(shuō)明Association的memberEnd的數(shù)量必須是2，也就是說(shuō)Association只能有兩個(gè)memberEnd；約束2說(shuō)明Operation拋出的異常類(lèi)型必須是Class。以上摘自MOF2.0規(guī)范。這說(shuō)明MOF作為OCL的定義者，父親，同時(shí)也被OCL這個(gè)兒子約束著。

后記

OCL是MDA中不可缺少的一環(huán)，MDA即使離開(kāi)了UML還有可能使用其他的建模語(yǔ)言來(lái)執(zhí)行，但是離開(kāi)了約束各層模型的OCL恐怕就處處漏風(fēng)了。OCL以后很可能會(huì)作為一個(gè)單獨(dú)的規(guī)范從UML中分離出來(lái)。因?yàn)樗粌H僅是一個(gè)“對(duì)象”約束語(yǔ)言，更是一個(gè)MDA約束語(yǔ)言，滲透在MDA的各個(gè)方面。文中還提到了OCL可以定義模型轉(zhuǎn)換，但是由于模型轉(zhuǎn)換的規(guī)范QVT還沒(méi)有最后確定，所以這個(gè)部分只是試探，而不是唯一標(biāo)準(zhǔn)。而目前的OCL如果要定義轉(zhuǎn)換，還必須做一些擴(kuò)充，所以這里沒(méi)有介紹。

OCL和MDA，目前我的理解也僅限于此，希望看完整本書(shū)后，能夠有進(jìn)一步的理解。