OCL在UML和MOF中的元模型对齐及代码生成的规则评价

理论计算机科学电子笔记102（2004）43-61www.elsevier.com/locate/entcs基于元模型的UML和MOF的Sten Loecher，Stefan Ocke斯蒂芬·洛克1，2德国德累斯顿工业大学计算机科学系摘要在成为UML标准的一部分后，OCL已经成功地应用于各个领域。因此，OCL的未来版本所要满足的需求已经发展。 一个关键要求是为OCL和UML的正式集成提供方法。因此，最新的OCL规范修订提案包含了一个定义语言概念和语义的元模型。基于这个元模型，我们目前正在重新设计DresdenOCL Toolkit。除了处理OCL表达式的基本功能外，该工具包还旨在支持对模型和元模型上定义的格式良好规则的评估。在本文中，我们介绍了修改后的工具包的架构。OCL与UML和MOF的对齐进行了讨论，并提出了这些元模型之间的依赖关系的显式建模的几个概念。最后，我们证明了我们的设计的充分性，提出了一个代码生成器的良构规则的评价。关键词：OCL，MOF，UML，元建模，编译器1介绍在过去的几年里，对象约束语言（OCL）[12]已经从仅仅是统一建模语言（UML）[7]的扩展发展成为它的一个组成部分。OCL的最初目的是用先决条件精确地表达对象模型上的约束1电邮地址：Sten. inf.tu.dresden.de2电子邮件地址：so3@wh2.tu-dresden.de3这项工作得到了德国研究共同体的资助，Graduiertenkolleg 191。1571-0661 © 2004 Elsevier B. V.根据CC BY-NC-ND许可证开放访问。doi：10.1016/j.entcs.2003.09.00344S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）后置条件或不变量。用户很快就意识到了替代应用的潜力。在相应场景中的使用导致了规范语言的未来版本需要满足的许多需求，例如消息表达式和元组类型等概念的合并。因此，对UML 2.0 OCL提案请求的最新响应[1]包含了对OCL的完全重新设计的规范，将其定义为一种通用查询语言，可以在UML模型中的任何地方使用，以表达所需的与早期版本的OCL相比，这个响应包含了OCL概念和语义的定义，通过一个符合元对象设施（MOF）的元模型[8]。提供OCL元模型的动机是OCL与UML元模型的预期集成，例如[11]中所研究的。它也是有效开发工具支持的基础我们目前的工作旨在重新设计Dresden OCL Toolkit [4]，以支持由[1]中的元模型定义的OCL。一方面，该工具包旨在提供处理OCL表达式的基本功能，例如解析、类型检查和代码生成。另一方面，工具包的设计是由支持元模型上定义的格式良好性规则（WFR）的评估和正常模型上的约束的需求驱动的。作为第一步，我们已经开发了一个适当的OCL编译器基础架构，该架构基于UML和MOF（两者的版本1.4）的当前规范。 我们工作的一个主要部分涉及OCL元模型与UML和MOF元模型的对齐。 由于OCL和UML元模型之间定义的依赖关系以及在元模型上支持WFR的需求（实际上是MOF模型），因此这种一致性是必要的。一些问题的解决方案已经详细说明，并已开发出一个共同的接口OCL UML和MOF。我们认为，本文提出的结果可以是有用的OCL和UML版本2.0的前瞻性对齐。为了证明我们的设计的充分性，已经开发了一个代码生成器来生成Java表达式，通过该表达式可以评估元模型的格式良好规则在第2节和第3节讨论了相关工作和一些初步问题之后，第4节介绍了OCL编译器的一般体系结构。第5节讨论了OCL与UML和MOF的一致性。代码生成在第6节中介绍。最后，我们总结了我们的工作成果，并在第7节中对我们未来的工作进行了简短的展望。S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）452相关工作基于OCL规范的1.3版本，我们的团队已经开发了Dresden OCL Toolkit[4，5，3，13]。它具有模块化结构的OCL编译器，提供了一组接口，便于增强和集成到不同的软件工程环境中。使用该工具包，可以处理UML模型的前置条件、后置条件和不变量。已经为Java和结构化查询语言（SQL）开发了代码生成器，并且在几个项目中使用了该工具包，部分与行业合作伙伴一起进行了广泛的测试，并最终为OCL支持奠定了坚实的基础。在我们目前的工作中，我们使用来自这个早期工具集的工件，例如OCL基础库。[10]描述了USE工具，它可以在UML模型上评估OCL表达式它提供了在文本基础上描述模型和相关OCL表达式的功能，并创建它们的实例，即所谓的快照。OCL表达式基于这些快照进行计算基本上，这些模型也可以是元模型，因此可以进行OCL表达式评估。中的OCL表达式求值之间的差异[10]我们的工具关注所使用的元模型和OCL表达式评估的类型尽管USE是基于UML的一个小核心和OCL元模型的前身，但我们的工具是基于对象管理组（OMG）提出和接受的标准。此外，与我们的工具箱相反，USE不为OCL表达式的求值生成代码，而是使用解释。3预赛本节讨论了与本文中使用的术语和技术有关的一些初步问题讨论围绕MOF元数据架构，这是第一次介绍。XML元数据交换（XMI）和Java元数据接口（JMI）等术语随后进行了解释。由OMG定义的MOF旨在为元数据的管理提供一个框架。 它包括分层元数据架构，一个元-元模型。图1通过一个包含用于表示UML图和OCL实例的元模型的示例说明了元数据体系结构。这些层从M0到M3连续编号。每一层上的数据由上一层的模型描述，例如，实际的数据和对象由UML模型建模，这些模型本身就是UML元模型的实例。UML元模型本身是按照46S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）Fig. 1. MOF元数据架构。MOF元元模型。这个元元模型，或MOF模型，是面向对象的，包括一组基本的建模构造，与UML对象建模构造的特定子集相一致。MOF模型本身是自描述的，即，它是使用自己的元建模结构正式定义的。OCL是由一个元模型定义的，它依赖于UML元模型的元素，并允许为UML模型编写OCL表达式，这些表达式位于M1层。由于M2层上的元模型是MOF模型的实例，但OCL被设计为在M1层上为模型编写表达式，因此如果没有适用于MOF的OCL元模型，OCL对WFR的指定是不可能的。第5节描述了如何调整原始OCL元模型，以便用于M2层上的WFR规范。MOF元数据体系结构为XMI的定义提供了基础，XMI描述了软件工程工具之间交换模型的标准。XMI包括DTD4和文档生成规则。DTD生成规则用于描述从元模型生成DTD（M2），而文档生成规则描述从实际模型生成XML文档（M1）。例如，包含UML元模型和MOF模型的XML文档由4文件类型定义S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）47图二. 建筑设计。OMG。XMI支持工具之间的数据交换。对于共享位于公共存储库中的数据的工具，JMI和MOF-IDL映射提供了从任意元模型（M2）生成接口的技术，然后将其用于访问相应的实例（M1）或对其执行必要的操作。JMI描述了Java接口的产生，并不是OMG标准的一部分，而MOF-IDL映射是MOF规范的一部分，并描述了CORBA-IDL接口的产生。4建筑设计图2所示的编译器的一般体系结构是由开发基于标准化Meta模型的工具包的需求决定的。因此，架构的主要组件是MOF存储库。存储库的目的是管理模型和Meta模型，生成访问这些模型的特定接口，并根据给定的规范提供接口的实现。MOF存储库提供的接口可以根据其功能进行分类5：IRepository包括通过XMI加载和保存模型和Meta模型的操作，以及从元模型生成JMI接口的操作由于IRepository的标准化目前不是MOF的一部分，因此接口目前具有相当的专有性质。图2中用双圆圈表示5组接口。48S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）IMofOcl和IUmlOcl是从MOF生成的JMI接口的集合1.4和UML 1.4元模型。元模型与特定的OCL元模型（即MOF-OCL和UML-OCL）适当地集成。第5节提供了关于各个元模型和集成主题的详细信息。IComon是一组JMI接口，支持以透明的方式访问OCL元模型的实例，独立于MOF或UML。它们抽象了IMofOcl和IUmlOcl的共同概念。关于公共接口及其与UML和MOF的关系的细节在5.1节中描述。IRe接口是一组相应的JMI接口，它允许访问模型，而无需生成元模型特定的接口。例如，这些接口在WFR评估期间使用。第6节提供了关于这一特定主题的更多信息。到目前为止所解释的接口被几个组件用来完成标准任务（如解析）或更专门的任务（如代码生成）。解析器基本上将为元模型或UML模型声明的OCL表达式从具体语法转换为抽象语法。也就是说，它在存储库中创建特定于MOF或特定于UML的OCL元模型的实例。在第6节中更详细地讨论了用于评估WFR的示例代码生成器。它已被开发来测试编译器架构，并证明其充分性。我们要强调的是，解析器只使用IComon也就是说，可以使用相同的解析器来处理UML和MOF模型。除此之外，代码生成器在很大程度上与MOF元模型解耦。只有在特定于MOF的信息的情况下，它才必须依赖于IMofOcl。图2还显示了一个客户机，以说明工具包的使用。这个客户端可以是，例如，根据即将到来的MOF 2 QVT标准[9]的转换引擎，它使用OCL作为模型的查询语言。在通过IRepository将元模型加载到存储库中之后，将使用解析器从OCL表达式创建OCL元模型实例。代码生成器随后用于生成适当的代码，以评估开始时加载的元模型的任意实例的OCL表达式。实例本身也可以使用IRepository创建。为了实现这个架构，我们必须决定为我们的工具集使用在评估和比较了几个MOF存储库实现之后，我们决定使用NetBeans元数据存储库[6]。该产品是NetBeans集成开发环境的一部分，但也可以用作独立工具S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）495OCL与MOF和UML的一致性本节讨论OCL与MOF和UML的一致性。在讨论了MOF和UML核心之间的差异之后，我们引入了一个抽象接口，该接口允许独立于UML特定或MOF特定元模型访问OCL元模型的实例。然后，我们提出了一个基于适配器的解决方案之间的映射MOF和OCL数据库。最后，我们展示了如何从UML的内部结构中解耦OCL的WFR。5.1通用OCL元模型如前所述，从长远来看，OCL有望与MOF版本2和UML版本2的公共核心集成。当前版本的OCL提交[1]基于UML 1.4版本。由于我们需要在元模型上评估WFRs，当前的OCL元模型也必须与MOF 1.4集成。由于MOF 1.4和UML 1.4的核心之间的差异，有必要引入一个抽象层，该抽象层包括OCL元模型使用的MOF和UML的公共概念。在下文中，描述了MOF和UML之间的区别，并解释了使用MOF/UML抽象5.1.1MOF与UML Core的区别当前OCL提交的第8章提供了OCL元模型使用的UML元模型的所有类的列表。通过在MOF 1.4中寻找它们的等价物，可以区分三种情况(1) 在MOF中有一个适当的类，可以不同地命名。例如，OCL元模型使用UML元类分类器作为Types包的所有类的超类型。通过这种方式，分类器的属性（如具有操作的能力）可以通过OCL类型另一方面，在MOF中，也有一个名为Classifier的元类，但不允许实例具有操作。相反，只有元类Class的实例可以有操作。也就是说，Class是MOF中Classifier的正确选择(2) 在MOF中也有类似的概念，但它不是由单独的类建模的。例如，在OCL元模型中的EnumLiteralExp和UML元模型中的EnumerationLiteral之间有一个关联。MOF也知道枚举的概念，但是没有单独的枚举文字类。相反，枚举字面量由50S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）元类EnumerationType中的多值属性标签。(3) 在MOF中没有类似的概念。例如，UML元类AssociationClass被OCL元类AssociationClassCallExp引用。在MOF中，不以任何方式支持关联类。正如下面的部分所解释的，问题（1）和（3）通过引入MOF/UML抽象层来解决，而问题（2）需要为MOF引入适配器。尽管MOF和UML核心的元类通常非常相似，但它们之间的关联却非常不同。由于OCL元模型的WFR和抽象语法映射的规则沿着UML元模型的这种内部关联导航，它们不能直接应用于MOF。因此，5.3节介绍了MOF/UML抽象层中的附加操作，这些操作封装了通过UML元模型的内部导航。5.1.2公共OCL元模型通用OCL元模型的包结构如图所示3 .第三章。Common-OCL是抽象的中心元素。它可以通过IComon接口访问，这些接口是从这个包中生成的，这些包是由MOF存储库从包含的类中恢复的。Common-OCL一方面包含CommonModel，另一方面包含Expressions和Types包。CommonModel包为OCL元模型的Expressions和Types包所使用后者不仅存在于Common-OCL中，也存在于与MOF和UML一致的各个OCL元模型中，这些元模型包含在MOF-OCL和UML-OCL中。来自各个OCL元模型的类继承自Common-OCL中相应的抽象类，并与MOF或UML元模型的相应类有关系。读者应该知道，OCL元模型的实例是MOF-OCL或UML-OCL的实例。UML-OCL包包含[1]中定义的OCL元模型由于关联和泛化，它依赖于UML元模型关系。包UML和UML-OCL作为生成IUmlOcl的基础。这些接口可以被访问，例如，通过UML模型中OCL表达式的代码生成器。图4给出了Common-OCL和UML-OCL：Types包中的CollectionType类重用S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）51图三. 常见OCL元模型的包。UML元模型中的分类器和操作之间的关联6，UML-OCL中的CollectionType继承自UML：：Core：：Classifier。在CommonModel中，分类器和操作之间没有关联，因为相应的关联不会对UML中已经存在的关联的重用进行适当的建模。相反，通过为Classifier定义额外的操作lookupOperation（），可以访问这些操作。对于图4中未示出的M0F的情况，MOF-OCL：：Types：CollectionType继承自MOF：：Model：：Class，因为MOF：：Model：：Classifier不能有操作。5.2用于MOF和数据类型映射的MOF定义了自己的数据类型模式，提供了用于构造基本类型、结构化类型、集合类型和枚举类型的元类除了像String和String这样的基本类型之外，所有类型都是用户定义的。与OCL标准库中定义的数据库相比，MOF数据库不能有任何操作，因为它们不继承自MOF：：Model：：Class。例如，考虑一个元模型，它包含一个类A，类A有一个类型为x的属性x。来表示一个简单的OCL约束，[6]在图4中，这个关系被简化了。52S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）见图4。 Common-OCL和UML-OCLcontextA inv：x > 0在抽象语法中，x必须被视为原始OCL数据类型的属性。当应用于MOF模型时，约束不能被建模，因为x必须被视为具有原始的MOF数据类型“x”。也就是说，对“大于”的操作调用不可用。因此，MOF和OCL数据库之间的映射是必要的。图5描述了工具包中实现的原语类型的映射。如左侧所示，MOF类不需要映射，可以用作OCL类型。但是，MOF：：Model：：DataType的实例继承自Classifier，因此无法拥有任何操作。因此，引入了适配器AdDataType，它的实例代表MOF数据库的OCL等价物。AdDataType继承自Class，因此具有拥有操作的能力。在AdDataType和关联TypeMapping的帮助下，可以通过以下操作描述任意MOF分类器的映射：context MOF：：模型：：分类器def：toOclType（）：MOF：：Model：：Class=if self.oclIsKindOf（MOF：：Model：：Class）thenselfelseif self.oclIsKindOf（MOF：：Model：：DataType）thenself.oclAsType（MOF：：Model：：DataType）.oclType其他--关联不映射到OCL类型S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）53图五. PrimitiveType的类型映射Ocl未定义的endifendif此外，原始类型的（非内射）映射由以下约束指定：context MOF：：Model：：PrimitiveType投资者：self.oclType.oclIsTypeOf（MOF-OCL：：Adapters：：AdPrimitive）inv：self.name=oclType.nameself.nameoclType.nameself.nameoclType.nameinv：self.name=oclType.nameself.nameoclType.nameself.nameoclType.name其余MOF数据集的映射以类似的方式建模。下表列出了MOF数据类型元类与Common-OCL中相应类之间的关系：54S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）MOF数据类型元类OCL数据类型元类PrimitiveType基本类型EnumerationType枚举CollectionType收集类型结构类型元组类型虽然基元类型需要引入适配器（AdPrimitive），但CollectionType和TupleType并非如此。 相反，直接使用来自MOF-OCL：：Types的相应类。它们继承自Common-OCL中的对应对象以及AdDataType。对于集合和结构类型的映射，元素或字段的类型也需要映射。这是通过使用前面定义的操作toOclType（）来完成的。正如在5.1.1节中已经提到的，EnumerationType需要特殊处理，因为OCL元模型期望枚举文字由单独的类建模，而MOF将文字建模为EnumerationType中的多值属性标签。映射是通过引入两个适配器类来实现的，即AdEnumeration和AdEnumerationLiteral。下面的约束描述了EnumerationType和关联适配器之间的关系context MOF：：Model：：枚举类型inv：oclType.oclIsTypeOf（MOF：：Adapters：：AdEnumeration）和oclType.name = name和oclType.oclAsType（MOF：：Adapters：：AdEnumeration）. literal.name=labels->asBag（）对于UML，也需要映射数据库与MOF不同，UML不为UML模型预先定义任何数据库（应该注意，是UML模型中使用的数据库与为了定义UML元模型，后者包含在包UML：Core：：DataType中）。例如，某些模型可能包含名为“int”的原始类型，而其他模型可能称之为“int”。在这两种情况下，当在OCL表达式中引用它时，它被认为是原始的OCL类型。因此，toOclType（）操作也是为UML：：Core：：Classifier定义的。虽然它对类没有影响，但UML：Core：：DataType的实例被映射到OCL原语类型，只要它们有一个约定的名称（如“int”或“int”）。具有未知名称的数据库将导致OclUndefined。S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）55已删除属性源类型简体中文类型：AttributeCallExp年龄：属性见图6。 AttributeCallExp的WFR5.3良构规则OCL元模型的格式良好性规则沿着UML元模型的内部关联导航，并访问UML元类中定义的属性由于这些与UML的依赖关系，WFR不能直接应用于MOF-OCL或Common-OCL。为了将WFR从UML元模型的内部结构中分离出来，我们为CommonModel类引入了额外的操作。注意，这种解耦对于简化与UML2.0的一致性也很有用。只要UML元模型中有变化，而OCL中没有变化，WFR就不需要更新。只有helper操作必须对齐，因为它们本质上给出了OCL和UML之间接口的完整定义。该概念通过以下示例WFR来说明：上下文属性CallExp投资者：self.type=self. selfredAttribute.type如图6所示，WFR沿着UML和OCL元模型之间的两个关联以及UML元 模 型 的 一 个 内 部 关 联 进 行 导 航 为 了 避 免 后 者 ， 帮 助 器 操 作getOclType（）被定义为Common-OCL级别的Attribute，并在WFR中使用，而不是关联。它分别对UML和MOF有不同的规范56S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）context UML：：Core：：Attributedef：getOclType（）：OCL：：CommonModel：：Classifier=self.type.toOclType（）context MOF：：Model：：Attributedef：getOclType（）：OCL：：CommonModel：：Classifier=self.type.toOclType（）定义是不同的，因为在第一种情况下，self.type意味着从UML：：Core：：Attribute到UML：：Core：：Classifier的导航，但在第二种情况下，从MOF：：Model：：Attribute到MOF：：Model：：Classifier。如前一章所述，属性的类型通过toOclType（）操作映射6代码生成为了证明编译器的架构和设计的充分性，开发了一个代码为此，我们使用了以前为Dresden OCL Toolkit开发的现有OCL标准库在6.1节中讨论了标准库适配之后，在6.2节中描述了OCL元模型实例到代码的转换。6.1OCL基础库在[2]中，提出了OCL标准库的Java实现，本文称为OCL Base- sisLibrary它主要用于支持Java程序中运行时的OCL约束检查，它使用Java反射来访问模型信息。由于我们的目标是生成元模型上的OCL表达式的评估代码，因此需要一个支持通过JMI反射访问模型的库的实现图7描述了新库的主要构件。OCL类型的实际实现，如Boolean，Boolean或Set，在很大程度上被重用。为了改进设计和提高库的可重用性，开发了一个接口，用于灵活地替换实际的模型访问实现已经引入了相应的类，例如OclModelObject和OclEnumLiteral，它们提供由实际模型访问类实现的模板方法例如，OclModelObject提供了从模型中获取属性值或调用对象操作的方法对于通过JMI的模型访问，它由JmiModelObject实现。下面的示例不变式contextA inv：x>0S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）57图7.第一次会议。OCL Basis Library与相应的JMI Model Access。显示了重新设计的OCL Basis Library的使用示例58S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）见图8。 IfExp的定义public OclBoolean evaluate_example_constraint（OclModelObjectself）{ OclPrimitiveType intType = OclPrimitiveType. getOclType（）; OclType x = Ocl. toOclType（self.getFeature（intType，“x”））; OclType zero = new OclType（0）;return x.isGreaterThan（zero）;}OCL表达式到这样的代码片段的转换将在下面的部分中描述。6.2代码生成这里描述的代码生成是一个具有实例的转换作为输入，Java代码作为输出。我们通过使用OCL指定转换，其方式与OCL提交中所述的抽象语法映射类似。在下文中，代码生成的规范由IfExp的转换规则非常简单，如图8所示：上下文IfExpdef：appendJavaCode（env：Env）：Env =letjavaOclType：String=self.type.mapToJavaOcl（env，true）inletwithCond：Env =self.condition.appendJavaCode（env）inletwithThen：Env = self.thenExpression.appendJavaCode（withCond）inletwithElse：Env =self.elseExpression.appendJavaCode（withThen）inletwithId：Env =withElse. appendId（self）in withId.appendLine（'final $1 $2 =$3 '，Sequence{javaOclType，withId.getId（self），Cast：：withCast（javaOclType，'$1.ifThenElse（$2，$3 '，序列{withId.getId（condition），withId.getId（thenExpression），withId.getId（elseExpression）}）}）OclExpression的所有子类的代码生成都被指定为一个操作appendJavaCode（），它需要一个Env类型的参数。这个环境（见图9）包含代码生成的当前状态。也就是说，它保存到目前为止生成的代码以及为子表达式和变量创建的所有标识符。appendJavaCode（）操作将导致一个S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）59见图9。 代码生成环境。新环境包含由指定的转换规则生成的代码。使用let表达式• 在OCL基础库（javaOclType）中确定IfExp• 获取IfExp的三个子表达式的代码，即withCond、withThen和withElse;• 并为表达式（withID）创建一个标识符，并将其添加到环境中。注意，所有对环境的操作都没有副作用。它们并不改变环境的状态，而是产生一个新的环境，即原始环境的操作appendLine（）将一行代码添加到环境中。在代码字符串中声明的模板参数（如$1）被作为序列给出的参数替换。生成的代码使用ifThenElse（）方法，该方法在OclBoolean中定义。此方法的返回类型为OclRoot，它是OCL基础库中所有类的公共超接口因此，有必要在代码中插入一个类型转换，这将产生IfExp的正确类型。 操作getId（）会产生IfExp的标识符，该标识符之前已由GetId（）创建。7总结和展望在本文中，我们介绍了一个基于元模型的OCL编译器的一般架构，它是基于一个MOF存储库。OCL编译器的关键需求是：基于标准化的元模型，并支持对它们的格式良好性规则的评估。为此，我们必须将OCL元模型（由对UML 2.0 OCL请求提案的最新响应定义）与UML和MOF的当前版本保持一致。我们为对齐引入了几个概念，即60S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）MOF和UML到OCL的公共接口，元级适配器，OCL和MOF之间的数据类型映射，以及通过适当的操作将WFR与相应的元模型解耦。我们认为所提出的概念对于即将到来的OCL与UML 2.0版的一致性可能是有用的。为了证明我们的方法的充分性，代码生成器，以支持WFR的评价已经提出。我们已经展示了一个基于元模型的OCL编译器的原型，它包括MOF存储库实现和代码生成器，通过代码生成器，我们可以演示所选WFR的代码生成。目前，一个解析器模块正在基于当前的OCL规范提案我们正在调查，在何种程度上可以从提供的规范自动生成解析器。要将概念应用于实践，有效的工具支持是必不可少的。从我们的角度来看，最新的八达通卡规范建议是将八达通卡从科学乐园推向工业实践的重要一步。它为OCL工具支持的高效开发提供了正确的起点。确认作者感谢Ste Zschaler对本文提出的宝贵意见和建议。引用[1] Boldsoft，Rational Software Corporation，IONA，and Adaptive Ltd. Response to the UML 2.0OCL RfP（OMG Document ad/2003-01-07），revised submission，version 1.6，January 62003.[2] 弗 兰 克 · 芬 格 OCL 基 础 书 目 的 Java 实 现 。 http://www-st.inf 的 网 站 。 tu-dresden.de/ocl/ff3/beleg.pdf，1999年7月[3] 弗 兰 克 · 芬 格 模 块 化 OCL 编 译 器 的 设 计 与 实 现http://www-st.inf 。tu-dresden.de/ocl/ff3/diplom.pdf，2000年3月。[4] Heinrich Hussmann，Birgit Demuth，and Frank Finger.支持OCL的工具集的模块化体系结构。在<>2000，统一建模语言，第三届国际会议，约克，英国。LNCS 1939.斯普林格，2000年。[5] Heinrich Hussmann，Birgit Demuth，and Sten Loecher. OCL作为数据库应用程序中业务规则的规范语言<>2001，统一建模语言，第四届国际会议，多伦多，加拿大。LNCS 2185.Springer，2001年10月。[6] 太阳微系统公司 元数据存储库。 http://mdr.netbeans.org。[7] 对象管理组（OMG）。统一建模语言（UML）规范，1.4版，2001年9月。[8] 对象管理组（OMG）。Meta Object Facility（MOF）规范，版本1.4，2002年4月。S. Loecher，S. Ocke / Electronic Notes in Theoretical Computer Science 102（2004）61[9] 对象管理组（OMG）。请求提案：MOF 2.0查询/视图/转换。2002年10[10] 马克·里克特。验证UML模型和OCL约束的精确方法。博士论文，不来梅大学，2001年。[11] 马克·里希特和马丁·戈戈拉。OCL的元模型。在<>'99，统一建模语言，第二届国际会议，柯林斯堡，科罗拉多州，美国。 LNCS 1723. Springer，1999年。[12] 乔斯·沃默和安妮卡·克莱普对象约束语言：用UML精确建模。Addison-Wesley，1998年。[13] 拉尔夫·威比克 在Java程序中检查OCL业务规则的实用程序支持。网址：//rw7.de/ralf/diplom00/intro.html网站，十二月 两千