对象约束语言简称OCL

对象约束语言简称OCL(ObjectConstraintLanguage)，它是一种用于施加在指定的模型元素上约束的语言。OCL表达式以附加在模型元素上的条件和限制来表现对该对象的约束，其中包括附加在模型元素上的不变量或约束的表达式，附加在操作和方法上的前置条件和后置条件等。对象约束语言概述对象约束语言是一种形式化语言，它主要用于表示UML模型中施加于模型上的约束。OCL具有如下特点：1、OCL是一种精确的，无二义性的语言2、OCL是一种规范说明性语言，所有有关实现的问题都不能用OCL来表达3、OCL是一种纯表达式语言，它是具有没有任何副作用的申明性语言。4、OCL是一种类型化语言，即OCL中的每一个表达式都是具有类型的。5、OCL不是一种程序设计语言，不能用OCL编写程序逻辑和控制流程。标准OCL类型OCL预定义的标准类型定义了一组基本类型和集合类型。OCL的基本类型有"Boolean”、"Integer”、"Real”、"String〃等。集合类型包括"Collection”、〃Set〃、"Bag”、"Sequence”等。这些标准型是OCL表达式的组成部分。OCL标准型的层次结构如下：OCL表达式OCL表达式对于一个OCL类型求值。OCL表达式有以下特点：1、OCL表达式可以附加在模型元素上，模型元素的所有实例都应该满足表达式的条件。2、OCL表达式可以附加在操作上。3、OCL表达式可以指定附加在模型元素上的监护条件。4、OCL表达式的计算顺序是从左到右。5、OCL表达式既可以使用基本类型又可以使用集合类型。用OCL表达对象性质约束OCL表达式可以附加在模型元素或模型元素的属性和操作上表达一个约束条件。

精确域模型的需求让我们拿系谱树形结构作为一个范例，从图1之中的图表开始。系谱树形视图的UML模型显示了一个Person是由名字和性别定义的，并且可以有或者没有小孩。而且，它显示了一个Person拥有两个小孩，小孩也是Person。这意味着两个小孩可以有相同的性别，但是这在遗传上是不可能的。因此，该模型是不精确的。图1.系谱树形模型■enunieration?*MaleFemalE一个UML图，例如一个类图，通常不够精确来提供一个业务模型的所有相关元素。它可以通过多种政策来表达约束，但是其他的约束仍然不够清晰。如果我们需要为模型对象描述其他的约束，那么通常可以以一种自然语言来描述它们。该实践还显示了它导致了模糊性的产生。您可以开发一个规范语言来避免这些模糊性。传统规范语言的劣势在于，它们是由拥有稳固数学知识的人员使用的，使用它来建模系统很困难。您可以开发OCL(对象约束语言)来填补这个空白。这就是一种读起来和写起来都很轻松的规范语言。以OCL写成的表达式可以得到理解，并且不会在不同角色的人员之间产生差异，这些人员例如分析员，开发员。为了创建一个精确且完整的模型，我们需要UML图表及OCL表达式。没有OCL表达式，那么模型就是严重未指定的。对于类和联系的代表来说，UML图表仍然是不可或缺的，但是OCL表达式会参考尚不存在的模型元素，因为在OCL中尚没有方法去指定类与联系。当我们合并图表和约束时，才能够完整地指定模型。至于如图1所示系谱树形视图中指定的模型，我们需要添加这些约束，来指定两个父类拥有不同的属性：{self.parents->asSequence()->at(1).sex<>self.parents->asSequence()->at(2).sex}图2.带有OCL约束的系谱树形模型

■{selfparents-^asSeqiuenatilt5ex5elf.parents-^a55equen-ceO-^attJ^-ew-«■£numter^atian??SnMaheFemale而且，模型的规模和数量会得到极大的增加，使得公司不能完整发挥MDA（模型驱动结构）的优势。系统由数以百计的模型组成，而模型又由数以千计的元素组成。使用MD技术能够获得较大的改进。但是，分析阶段确认模型仍然存在许多问题。有很多程序不能理解以OCL写成的约束。就算代码生成过程之中能够转化代码的约束，在编码开始之前仍然应该确认模型及其约束。因此，分析阶段最终的错误可以尽早地检查到，而不用对开发规划造成什么大的影响。模型确认的结果对分析阶段会产生一定的影响。约束并不适合：.如果约束太强，那么许多实例并不满足约束的条件。在这些情况下，为方便大多数的实例可以放松约束。.如果约束太弱，会出现系统不想要出现的一些情况。在这种情况之下，约束并不具有较强的限制性。我们的目标是构建更好的域模型。模型不能适应选择的约束，在这种情况下应该编辑它。.一方面，它生成了特定模型的实例，并自动确认它们是否与已有的OCL约束兼容。.另一方面，可视化使得分析员能够更轻松地发现和校正域模型之中的模糊性或者不稳定性。让我们考虑一下如图3所示的系谱树形模型的一个实例。我们可以看到两个父类拥有相同的属性，这在条件下是不可能的。因此，我们拥有合并的UML与OCL，来帮助分析员提高域模型的质量。OCL表达式会得到评价，并且仍然不会得到注释（这就是今天RationalSoftwareArchitect的实例）。但是，分析员就是决定做出什么更改的人，并且由他来决定应该添加什么约束来构建更精确的模型。回页首实施第一眼看上去时，会觉得上面提到的插件实施起来不可能，因为我们不能评价模型层次上的OCL约束。RationalSoftwareArchitect中提供的API并不支持评价OCL约束。我们所实施的方案就是执行以下的这些步骤：UMLmodel>Ecoremodel（使用已有的RationalSoftwareArchitect向导）Ecoremodel>Generatormodel（使用已有的RationalSoftwareArchitect向导）Generatormodel>EMFcode（使用已有的RationalSoftwareArchitect功能）使用已有的EMF模型来评价OCL约束图4演示了这个过程。图4.进程

现在我们要从测试员的观点来解释进程。域模型的范例为了演示前面章节之中描述的进程，我们要使用库的域模型，如图5所示。图5.库域模型■fE浦5/jSuggestionPenalty：...Lojn图5的大图图6显示了进程开始时项目是什么样的。您可以看到在LibraryExample项目之中只有叫做Analysis的UML模型，它包含的类有：BookCopy，BookReference，Company，Contract，Loan，Penalty，Reservation以及User。：...Lojn图6.原始的项目

\.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画pe:ties"•pliigni.xml如上所述，UMLAPI并不支持在模型层次上评价OCL表达式。在搜索一些之后，我们已经注意到EclipseModelingFramework（EMF）API支持OCL评价。现在，EMF代码可以从Ecore模型生成。您可以在RationalSoftwareArchitect中作出转变，这样我们可以使用已有的向导来生成它，稍后也能够评价OCL限制因素。从LibraryExample转化之后的M2M获得的Ecore模型如图7所示。图7.M2M之后的Ecore模型HlMainjEanalysis.ecore舌&日由jplatform:/；,£sojrce/LibraryExam3!£/anal7E；s,ecore-击Analysis目目目目目目目目

田：©■:•a-•©■.©■:0-s-;ffl-UserReservatianBookCopvEookRefierenceLoanCompanyContractPenalty项目如图目目目目目目目目

田：©■:•a-•©■.©■:0-s-;ffl-图8.带有Ecore模型的RationalSoftwareArchitect项目

EtlProjectExplorerQ-J^7LibraryExample+'Diagrams-方Modelsi；；_.-口1吒P日ck己口仁“Rn占It膏3+(2^AssodatjonE百IMain+;;:=+=EE;;+;;:=+=EE;;:(±iJ!!E—(±!=1■*z|±:Mii■(SiEI!®-x亩JRESystemLibrary[JavaSE-L^J1Piug-inDepsndendesQ-苫arc-庄I:'braryexanpeJ]Activator.javdFl巳META-INF驱MANIFES7.MF-analysis.ecore-串Analysis+目EoskCapy+目BocikReference^ConnpcinYj..：Contact♦yLoanPenalty+2Reservatior+日User园pertiesEMF让我们生成了一个代码，您可以使用该代码来创建模型实例，我们可以使用它来完成生成操作。图9显示了包含生成代码的更新项目。图9.带有生成源代码目录的项目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国perties:笋plugin.xml上面描述的两步应该由确认模型的人员手动完成。在完成之后，实例的生成和OCL表达式的评价就可以开始了。生成实例本文描述了完整的生成规则。出于简便性的考虑，我们将会使用类图(entryDiagram),它包含了三类：User,Contract与Company。在这里的范例之中，我们将会假设库向相关公司雇佣的每一个人提供了信息。在这里的范例之中，雇员与库之间没有协议，但是与他所服务的公司有，所以，我们要添加以下的限制条件(同样见于图10)：{self.contract->notEmpty()pany<>null}图10.输入表yContract-contract-company昌CompanyL卢0..1评价结果的OCL约束以及可视化与约束相关的实例拥有_OK的后缀，而其他的实例拥有_KO后缀:图11.生成的对象图

-'.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-费-375SObjectD.agran2010-09-22-03-02-33-765OKOKOKOKOKOKOKOKOKObjectDiagr邪2d10-09-22-0OKOKOKOKOKOKOKOKOKSObiectCiagram2010-09-22-3302-34-562_OKEObjectTiagram201jO-Cig-22-0302-35-^18.性ObjectDiagranZOlO-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)让我们进一步查看一下两个实例。在图12之中，我们可以看到实例关注User类的限制性因素。确实，识别为userT6D的用户拥有contractQYR协议，而且他不是相关公司的雇员（与Company类型的实例没有联系）。图12.关注约束的实例