對(duì)象約束語(yǔ)言簡(jiǎn)稱OCL

對(duì)象約束語(yǔ)言簡(jiǎn)稱OCL(ObjectConstraintLanguage)，它是一種用于施加在指定的模型元素上約束的語(yǔ)言。OCL表達(dá)式以附加在模型元素上的條件和限制來(lái)表現(xiàn)對(duì)該對(duì)象的約束，其中包括附加在模型元素上的不變量或約束的表達(dá)式，附加在操作和方法上的前置條件和后置條件等。對(duì)象約束語(yǔ)言概述對(duì)象約束語(yǔ)言是一種形式化語(yǔ)言，它主要用于表示UML模型中施加于模型上的約束。OCL具有如下特點(diǎn)：1、OCL是一種精確的，無(wú)二義性的語(yǔ)言2、OCL是一種規(guī)范說(shuō)明性語(yǔ)言，所有有關(guān)實(shí)現(xiàn)的問(wèn)題都不能用OCL來(lái)表達(dá)3、OCL是一種純表達(dá)式語(yǔ)言，它是具有沒(méi)有任何副作用的申明性語(yǔ)言。4、OCL是一種類(lèi)型化語(yǔ)言，即OCL中的每一個(gè)表達(dá)式都是具有類(lèi)型的。5、OCL不是一種程序設(shè)計(jì)語(yǔ)言，不能用OCL編寫(xiě)程序邏輯和控制流程。標(biāo)準(zhǔn)OCL類(lèi)型OCL預(yù)定義的標(biāo)準(zhǔn)類(lèi)型定義了一組基本類(lèi)型和集合類(lèi)型。OCL的基本類(lèi)型有"Boolean”、"Integer”、"Real”、"String〃等。集合類(lèi)型包括"Collection”、〃Set〃、"Bag”、"Sequence”等。這些標(biāo)準(zhǔn)型是OCL表達(dá)式的組成部分。OCL標(biāo)準(zhǔn)型的層次結(jié)構(gòu)如下：OCL表達(dá)式OCL表達(dá)式對(duì)于一個(gè)OCL類(lèi)型求值。OCL表達(dá)式有以下特點(diǎn)：1、OCL表達(dá)式可以附加在模型元素上，模型元素的所有實(shí)例都應(yīng)該滿足表達(dá)式的條件。2、OCL表達(dá)式可以附加在操作上。3、OCL表達(dá)式可以指定附加在模型元素上的監(jiān)護(hù)條件。4、OCL表達(dá)式的計(jì)算順序是從左到右。5、OCL表達(dá)式既可以使用基本類(lèi)型又可以使用集合類(lèi)型。用OCL表達(dá)對(duì)象性質(zhì)約束OCL表達(dá)式可以附加在模型元素或模型元素的屬性和操作上表達(dá)一個(gè)約束條件。

精確域模型的需求讓我們拿系譜樹(shù)形結(jié)構(gòu)作為一個(gè)范例，從圖1之中的圖表開(kāi)始。系譜樹(shù)形視圖的UML模型顯示了一個(gè)Person是由名字和性別定義的，并且可以有或者沒(méi)有小孩。而且，它顯示了一個(gè)Person擁有兩個(gè)小孩，小孩也是Person。這意味著兩個(gè)小孩可以有相同的性別，但是這在遺傳上是不可能的。因此，該模型是不精確的。圖1.系譜樹(shù)形模型■enunieration?*MaleFemalE一個(gè)UML圖，例如一個(gè)類(lèi)圖，通常不夠精確來(lái)提供一個(gè)業(yè)務(wù)模型的所有相關(guān)元素。它可以通過(guò)多種政策來(lái)表達(dá)約束，但是其他的約束仍然不夠清晰。如果我們需要為模型對(duì)象描述其他的約束，那么通常可以以一種自然語(yǔ)言來(lái)描述它們。該實(shí)踐還顯示了它導(dǎo)致了模糊性的產(chǎn)生。您可以開(kāi)發(fā)一個(gè)規(guī)范語(yǔ)言來(lái)避免這些模糊性。傳統(tǒng)規(guī)范語(yǔ)言的劣勢(shì)在于，它們是由擁有穩(wěn)固數(shù)學(xué)知識(shí)的人員使用的，使用它來(lái)建模系統(tǒng)很困難。您可以開(kāi)發(fā)OCL(對(duì)象約束語(yǔ)言)來(lái)填補(bǔ)這個(gè)空白。這就是一種讀起來(lái)和寫(xiě)起來(lái)都很輕松的規(guī)范語(yǔ)言。以O(shè)CL寫(xiě)成的表達(dá)式可以得到理解，并且不會(huì)在不同角色的人員之間產(chǎn)生差異，這些人員例如分析員，開(kāi)發(fā)員。為了創(chuàng)建一個(gè)精確且完整的模型，我們需要UML圖表及OCL表達(dá)式。沒(méi)有OCL表達(dá)式，那么模型就是嚴(yán)重未指定的。對(duì)于類(lèi)和聯(lián)系的代表來(lái)說(shuō)，UML圖表仍然是不可或缺的，但是OCL表達(dá)式會(huì)參考尚不存在的模型元素，因?yàn)樵贠CL中尚沒(méi)有方法去指定類(lèi)與聯(lián)系。當(dāng)我們合并圖表和約束時(shí)，才能夠完整地指定模型。至于如圖1所示系譜樹(shù)形視圖中指定的模型，我們需要添加這些約束，來(lái)指定兩個(gè)父類(lèi)擁有不同的屬性：{self.parents->asSequence()->at(1).sex<>self.parents->asSequence()->at(2).sex}圖2.帶有OCL約束的系譜樹(shù)形模型

■{selfparents-^asSeqiuenatilt5ex5elf.parents-^a55equen-ceO-^attJ^-ew-?■￡numter^atian??SnMaheFemale而且，模型的規(guī)模和數(shù)量會(huì)得到極大的增加，使得公司不能完整發(fā)揮MDA（模型驅(qū)動(dòng)結(jié)構(gòu)）的優(yōu)勢(shì)。系統(tǒng)由數(shù)以百計(jì)的模型組成，而模型又由數(shù)以千計(jì)的元素組成。使用MD技術(shù)能夠獲得較大的改進(jìn)。但是，分析階段確認(rèn)模型仍然存在許多問(wèn)題。有很多程序不能理解以O(shè)CL寫(xiě)成的約束。就算代碼生成過(guò)程之中能夠轉(zhuǎn)化代碼的約束，在編碼開(kāi)始之前仍然應(yīng)該確認(rèn)模型及其約束。因此，分析階段最終的錯(cuò)誤可以盡早地檢查到，而不用對(duì)開(kāi)發(fā)規(guī)劃造成什么大的影響。模型確認(rèn)的結(jié)果對(duì)分析階段會(huì)產(chǎn)生一定的影響。約束并不適合：.如果約束太強(qiáng)，那么許多實(shí)例并不滿足約束的條件。在這些情況下，為方便大多數(shù)的實(shí)例可以放松約束。.如果約束太弱，會(huì)出現(xiàn)系統(tǒng)不想要出現(xiàn)的一些情況。在這種情況之下，約束并不具有較強(qiáng)的限制性。我們的目標(biāo)是構(gòu)建更好的域模型。模型不能適應(yīng)選擇的約束，在這種情況下應(yīng)該編輯它。.一方面，它生成了特定模型的實(shí)例，并自動(dòng)確認(rèn)它們是否與已有的OCL約束兼容。.另一方面，可視化使得分析員能夠更輕松地發(fā)現(xiàn)和校正域模型之中的模糊性或者不穩(wěn)定性。讓我們考慮一下如圖3所示的系譜樹(shù)形模型的一個(gè)實(shí)例。我們可以看到兩個(gè)父類(lèi)擁有相同的屬性，這在條件下是不可能的。因此，我們擁有合并的UML與OCL，來(lái)幫助分析員提高域模型的質(zhì)量。OCL表達(dá)式會(huì)得到評(píng)價(jià)，并且仍然不會(huì)得到注釋（這就是今天RationalSoftwareArchitect的實(shí)例）。但是，分析員就是決定做出什么更改的人，并且由他來(lái)決定應(yīng)該添加什么約束來(lái)構(gòu)建更精確的模型?；仨?yè)首實(shí)施第一眼看上去時(shí)，會(huì)覺(jué)得上面提到的插件實(shí)施起來(lái)不可能，因?yàn)槲覀儾荒茉u(píng)價(jià)模型層次上的OCL約束。RationalSoftwareArchitect中提供的API并不支持評(píng)價(jià)OCL約束。我們所實(shí)施的方案就是執(zhí)行以下的這些步驟：UMLmodel>Ecoremodel（使用已有的RationalSoftwareArchitect向?qū)В〦coremodel>Generatormodel（使用已有的RationalSoftwareArchitect向?qū)В〨eneratormodel>EMFcode（使用已有的RationalSoftwareArchitect功能）使用已有的EMF模型來(lái)評(píng)價(jià)OCL約束圖4演示了這個(gè)過(guò)程。圖4.進(jìn)程

現(xiàn)在我們要從測(cè)試員的觀點(diǎn)來(lái)解釋進(jìn)程。域模型的范例為了演示前面章節(jié)之中描述的進(jìn)程，我們要使用庫(kù)的域模型，如圖5所示。圖5.庫(kù)域模型■fE浦5/jSuggestionPenalty：...Lojn圖5的大圖圖6顯示了進(jìn)程開(kāi)始時(shí)項(xiàng)目是什么樣的。您可以看到在LibraryExample項(xiàng)目之中只有叫做Analysis的UML模型，它包含的類(lèi)有：BookCopy，BookReference，Company，Contract，Loan，Penalty，Reservation以及User。：...Lojn圖6.原始的項(xiàng)目

\.QjProjectExplorer誑LibraryExample+'Digrams-:方Models-也Analysisi<i?.冬AesodaUons旬MairBookCopyBoskRe^eienceCormpanvContactLoanPenaltyReser'.-'abonUser[UHLPiinnitiyel-fpes/田…威JRE5ysternLibrary[JavaSE-1.^}P!ng-inD&penclendes-涉src-i-tti'brarvexampie+EActjyator.java日&META-INFMANIFE57,MF畫(huà)pe:ties"?pliigni.xml如上所述，UMLAPI并不支持在模型層次上評(píng)價(jià)OCL表達(dá)式。在搜索一些之后，我們已經(jīng)注意到EclipseModelingFramework（EMF）API支持OCL評(píng)價(jià)。現(xiàn)在，EMF代碼可以從Ecore模型生成。您可以在RationalSoftwareArchitect中作出轉(zhuǎn)變，這樣我們可以使用已有的向?qū)?lái)生成它，稍后也能夠評(píng)價(jià)OCL限制因素。從LibraryExample轉(zhuǎn)化之后的M2M獲得的Ecore模型如圖7所示。圖7.M2M之后的Ecore模型HlMainjEanalysis.ecore舌&日由jplatform:/；,￡sojrce/LibraryExam3!￡/anal7E；s,ecore-擊Analysis目目目目目目目目

田：?■:?a-??■.?■:0-s-;ffl-UserReservatianBookCopvEookRefierenceLoanCompanyContractPenalty項(xiàng)目如圖目目目目目目目目

田：?■:?a-??■.?■:0-s-;ffl-圖8.帶有Ecore模型的RationalSoftwareArchitect項(xiàng)目

EtlProjectExplorerQ-J^7LibraryExample+'Diagrams-方Modelsi；；_.-口1吒P日ck己口仁“Rn占It膏3+(2^AssodatjonE百I(mǎi)Main+;;:=+=EE;;+;;:=+=EE;;:(±iJ!!E—(±!=1■*z|±:Mii■(SiEI!?-x畝JRESystemLibrary[JavaSE-L^J1Piug-inDepsndendesQ-苫arc-莊I:'braryexanpeJ]Activator.javdFl巳META-INF驅(qū)MANIFES7.MF-analysis.ecore-串Analysis+目EoskCapy+目BocikReference^ConnpcinYj..：Contact?yLoanPenalty+2Reservatior+日User園pertiesEMF讓我們生成了一個(gè)代碼，您可以使用該代碼來(lái)創(chuàng)建模型實(shí)例，我們可以使用它來(lái)完成生成操作。圖9顯示了包含生成代碼的更新項(xiàng)目。圖9.帶有生成源代碼目錄的項(xiàng)目LO.ProjectExplorerE3曰.?澇LibrarvEsample+芯Diagram?-蓉ModelsSMain因—SMain因—BOQkCODY——BookRe^rence?■—Companv畝…Coi-!tract(±1——Loan+Penalty?■■■—Rese:\-ation十——User&■2。(UMLPrimitJveTvpeg)Q也^Package^Analysis卜5AssodatiorisfOisrc"：+函Analysis+￡BAnalysis.inip:+由Analyais.util>■._[+■AnalYsis.validationii.+i%Ei■泠甘昨迪由MJRESystemLibraryiJc..'aSE-1.6]+蘭plug-inDependenciesEl■&META-INF?MANIFEST.MF+&text-也jsnalvsiE.ecoi'e--Analysis專analysis.genmDdel匾perties國(guó)perties:筍plugin.xml上面描述的兩步應(yīng)該由確認(rèn)模型的人員手動(dòng)完成。在完成之后，實(shí)例的生成和OCL表達(dá)式的評(píng)價(jià)就可以開(kāi)始了。生成實(shí)例本文描述了完整的生成規(guī)則。出于簡(jiǎn)便性的考慮，我們將會(huì)使用類(lèi)圖(entryDiagram),它包含了三類(lèi)：User,Contract與Company。在這里的范例之中，我們將會(huì)假設(shè)庫(kù)向相關(guān)公司雇傭的每一個(gè)人提供了信息。在這里的范例之中，雇員與庫(kù)之間沒(méi)有協(xié)議，但是與他所服務(wù)的公司有，所以，我們要添加以下的限制條件(同樣見(jiàn)于圖10)：{self.contract->notEmpty()pany<>null}圖10.輸入表yContract-contract-company昌CompanyL盧0..1評(píng)價(jià)結(jié)果的OCL約束以及可視化與約束相關(guān)的實(shí)例擁有_OK的后綴，而其他的實(shí)例擁有_KO后綴:圖11.生成的對(duì)象圖

-'.ProjectExplorer以-玉^Package*■Analysis■:-七Assticiatiors■ientryDiagramMainObjectDiagran2010<19-22<i3-02-29-953.Obje.：tDiagrann2010-09-22-0?-02-B1-5155ObjectDiagram20LO-09-22-□3-02-32-0465'ObjectDiagram2010-09-22-03-02-32-515SObjcctDiagran2D10-09-Z2-03-01-31-7315-ObjectDiagran2D10-09-22-03-01-33-093WObjectDiagran2010-09-Z2<i3-□N-費(fèi)-375SObjectD.agran2010-09-22-03-02-33-765OKOKOKOKOKOKOKOKOKObjectDiagr邪2d10-09-22-0OKOKOKOKOKOKOKOKOKSObiectCiagram2010-09-22-3302-34-562_OKEObjectTiagram201jO-Cig-22-0302-35-^18.性O(shè)bjectDiagranZOlO-Lig-Z2□3-01-35-875吒ObjectDiagran2010<i9-Z2-03-0Z-36-Z50典ObjectDiagranZaiO-09-22<i3<i2-36-7035-ObjectDiagran2010-09-22-li3-a2-37-1875Ob;sctDiBgram2O10-a9-22-03<12-37-531BObjectDiagramSOlO小-22-03心S-37-S43噸QbjsctDiagranZDlO-09-22-92-0Z-38-2035ObjectDiagranZaiJO-ag-22-03-O2-38-5003iObjSCtDiagranZOlO七9-ZZ-03-dZ-39-343a:H日aa□KOKQKOOKOKOKOK。札KQok!:I±J?畝?.?!0?:??;田…田;.?-:?BookCopyBookRefierericeCompanyConb'actLoanPenaltyRssei'^ationUser(UMLPrinriitiveTvpes)讓我們進(jìn)一步查看一下兩個(gè)實(shí)例。在圖12之中，我們可以看到實(shí)例關(guān)注User類(lèi)的限制性因素。確實(shí)，識(shí)別為userT6D的用戶擁有contractQYR協(xié)議，而且他不是相關(guān)公司的雇員（與Company類(lèi)型的實(shí)例沒(méi)有聯(lián)系）。圖12.關(guān)注約束的實(shí)例