结合OCL和编程语言处理UML模型

理论计算机科学电子笔记102（2004）175-194www.elsevier.com/locate/entcs结合OCL和编程语言处理UML模型Mika Siikarla，Jari Peltonen，and Petri Selonen米卡·西卡拉，贾里·佩尔托宁和佩特里·塞洛宁1，2芬兰坦佩雷理工大学软件系统研究所摘要模型处理任务，如模型检查，合并，切片和合成，需要有效和维护机制来定义模型，以及查询，比较和操作其中的信息。虽然对象约束语言（OCL）主要用于表达UML模型的约束，但它也可以用于各种模型处理目的。 在本文中，我们讨论了使用OCL处理模型的需求和可能性，并展示了我们如何应用和扩展OCL。我们还介绍了一个模型处理工具，使用OCL作为模型操作设施的一个组成部分。我们特别强调需要结合使用OCL和编程语言在UML模型处理。保留字：OCL，UML，模型处理，编程语言，Python1介绍在以UML为中心的CASE工具中，缺乏对不同软件工程方法的丰富支持反映了UML [17]是建模语言的标准，而不是设计方法的标准。这对工具供应商来说既是机遇也是挑战。一方面，有很大的自由来实现对工具的任何类型的方法支持。另一方面，用户希望使用和开发最适合他们的1这项工作由芬兰科学院和诺基亚资助 我们想感谢前总统塔尔贾·西斯塔，让她的生活更美好。2电子邮件：miksi@cs.tut.fi、jpe@cs.tut.fi和pselonen@cs.tut.fi1571-0661 © 2004 Elsevier B. V.根据CC BY-NC-ND许可证开放访问。doi：10.1016/j.entcs.2003.09.009176M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-目的因此，工具供应商应该能够为用户想要使用的任何方法我们的总体研究目标是为软件工程过程提供自动化工具支持.每个过程都包含各种任务，如模型检查，合并，切片，合成等。需要清晰和可维护的机制来有效地定义模型，以及查询，比较和操作其中的信息过程支持所需的附加这些接口通常使用通用编程语言（例如Rational Rose Basic [21]），允许访问模型数据。当使用通用编程语言进行模型处理时，人们很快就会意识到该工具是多么不适合这项工作。简单的查询通常会变成多行嵌套循环或递归调用，从而有效地隐藏用户更复杂的搜索在代码中表现为冗长，难以理解函数。不需要对查询的匹配条件进行很大的更改就可以强制重写整个部分。在模型处理任务的早期开发和测试过程中，这种变化是常见的只要更改只涉及查询中的值，而不涉及其结构，就可以通过参数化查询来减少影响。而且，程序的一部分越复杂，就越难发现其中的错误，因此需要一种用于UML领域的高级语言对象约束语言（OCL）[17，第6章]可以满足领域语言的部分需求。OCL是一种用于在UML模型中表达约束的形式化语言。OCL的下一个版本的草案[3]扩展了其目的，包括UML模型上的所有表达式，并将查询作为一种可能的用途。实际上，OCL是灵活的，并且表达能力足以编写相当清晰和完整的查询和检查。但这并不是模型处理所需的全部。 OCL规范坚持认为该语言是一种规范语言，而不是编程语言。没有提到应该或可以如何实现操作，或者即使实现是可能的或计算上可行的。然而，事实证明，即使不是所有的操作，也很容易为大多数操作构造一个简单的算法。作为一种规范语言，OCL自然缺乏用户交互和读取或写入文件的功能。但从模型处理的角度来看，最大的问题是OCL被定义为无侧射。因此，无法更改对象的值或在对象之间创建链接这种限制是语言的一个组成部分，它涉及语言的许多方面，不能简单地忽略。侧面效应可以用M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-177OCL，例如作为后置条件，但在实践中，这种方法难以应用，并且不会产生易于阅读的操作。可以扩展OCL以包含表达式（“旧OCL”，没有副作用）和语句（“新OCL”，有副作用）。这本质上与将OCL嵌入到另一种编程语言中是一样的，所以我们最好使用现有的编程语言。通过混合OCL表达式和用于模型处理的编程语言，我们可以使用它们中的每一个用于预期的目的。总之，我们需要一种处理UML模型的机制，不仅提供对模型的原始访问，而且还提供对实现模型处理任务的高级支持。在本文中，我们将讨论使用OCL进行模型处理的需求和可能性，并展示我们如何应用和扩展OCL。我们还介绍了一个模型处理环境xUMLi [1]，其中我们使用OCL作为模型操作工具的一个组成部分。我们特别强调需要结合使用OCL和编程语言在UML模型处理。2模型处理我们研究的主要目标是为各种软件工程过程提供自动化工具支持，每个过程都引入一组模型处理任务。我们认为，这些任务可以执行，并组成，一组原始模型处理操作。模型操作又被组合在一起，以使用更高级别的组合机制来形成任务，我们将这些操作的使用称为模型处理。也许模型操作的最简单的例子是在给定的UML模型中搜索和过滤信息。这些操作提供了模型的无副效应检查和验证。这种操作的一个明显的例子是强制执行标准的UML格式良好性规则[17]。类似地，一个操作可以检查模型是否遵循给定的过程或领域特定的规则：例如，确保继承树中的所有节点都应该是抽象类，所有叶子类都应该是具体的，这是OPEN软件过程建议的规则[8，pp.90]。模型操作的其他例子是转换操作、投影操作、重构操作和集合操作。一个转换操作[25]将一个（一组）UML图作为它的输入操作数，并基于这个图所隐含的信息产生另一种类型的新UML图。有用的转换操作的示例包括基于一组交互的178M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-图[23][29][27]，从交互图合成结构图[25][11]，从对象图合成类图[6]。投影操作基于现有的UML模型产生新的UML模型，新模型是原始模型的投影（例如抽象或切片）。作为在逆向工程过程中产生的大型模型中特别有用的投影操作的示例，考虑基于现有结构图生成压缩结构图[20]。重构操作基于给定的重构模式产生新的、修改过的模型;举个例子，上拉方法[7，pp. 332]声明如果给定超类的所有子类都有一个方法，该方法具有相同的结果，则该方法将被移动到超类。一个集合运算[24]（例如，union，intersection，difference）以两个UML模型作为输入操作数，生成一个新的UML模型（如合并图和切片图）。集合操作对于依赖于从单个模型片段中组成规范的机制的过程（例如催化[5]）和范式（例如面向主题的设计[4模型操作的一个特别有趣的类别是一致性操作。这些操作强制执行一致性规则，用于根据域或产品线特定的配置文件验证架构设计[26]。使用适当一致性规则的配置，根据概要文件对架构设计进行验证。这些规则可以被看作是一组OCL约束模板，由概要文件实例化，然后在架构视图上进行评估。因此，违反一致性规则的元素可以被收集并呈现给用户。目前，本文中描述的技术，以及它们的实现平台，正在评估一个行业的研究，重点是利用一致性操作。目标系统是一个大规模的现实生活中的模型，描述了诺基亚的产品线之一上面提到的模型操作也可以被看作是对象管理组的模型驱动架构（MDA）倡议[ 16 ]意义上的模型转换为了支持模型处理，需要可行的机制来查询、定义和操作UML模型。为了在实践中实现这些概念，需要一个高级别的（即，UML领域特定的）机制，用于实现模型操作，以便使用UML模型进行推理，访问商业UML CASE工具，以及将操作组合在一起的方法。M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-1793扩展OCL -查找操作OCL有一组预定义的类型和这些类型的操作。它们在所谓的OCL标准库中定义，并且强制性的实现包括它们。预定义的类型包括String、Real、String、Boolean和一组非常有用的结构化数据类型。类型结构也由当前应用程序模型中的所有分类器追加。在某些情况下，需要更多的操作，例如取平方根，甚至是新的类型。OCL提供了强大的扩展机制来改变语言。最轻量级的机制是let表达式，它允许定义变量名和相应的表达式。变量名为有点误导，因为变量名在计算之前被相应的表达式替换。也可以定义具有参数的让类似于定义宏与#defineC和C++中的-directive。 还有一个更强的机制，将变量作为新属性或方法添加到类型。这对于从应用程序模型中扩充一个分类器，使用一种简化所使用的OCL表达式对于严重的扩展需求，可以定义新的基本类型或独立于应用程序模型的新方法。这些扩展放在一个名称空间中，可以在普通的OCL表达式中使用在本文的OCL表达式中，我们经常使用find操作。它不是OCL标准库的一部分，而是我们对语言的扩展。该操作类似于select，因为它们都选择与给定条件匹配的元素。但是，除了检查集合的元素之外，find还会递归地遍历每个元素的子元素也就是说，它沿着与部分的任何整体-部分关系下降，也测试它。搜索继续到测试部件的子部件，依此类推，直到找到没有子部件的元素当对固有的层次元素（如UML元模型的Packages和Pupacets）进行操作时，经常需要进行这种深度搜索作为find表达式的一个例子，让我们考虑在模型中搜索新的、用户定义的原型的情况。用户定义的构造型为UML提供了一种轻量级的扩展机制，允许用户定义新的、特定于领域的概念，用于模型中。如[17]所述，用户定义的原型是一种细化UML标准语义的方法。它们允许建模者添加新的建模元素，这些元素可以在特定于过程或特定于实现语言的领域的UML模型让我们假设构造型位于包的层次结构中，并且我们只对某个包下的构造型感兴趣，180M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-<<刻板印象>>企业案例模型<<元类>>模型<<刻板印象>>Fig. 1. 显式刻板印象建模[17，图4-1]等级制度。我们假设新的刻板印象被明确地建模，如[17]中所定义的。4-3]。原始的UML元类扩展，是作为一个标记有元类的类用户定义的构造型作为一个标记为原型，它的名字就是新原型的名字。后一类依赖于前一类。这个附属物本身就带有刻板印象。图1给出了这种原型定义的一个例子1，采用[17，图4-1]。图1中的关系图引入了一个新的构造型RISKCaseModel，它扩展了标准的UML元类Model。图2中的表达式递归地在Package层次结构中搜索用户定义的构造型。让我们以图3中的两个包、五个类和一个特性的层次结构为例。类S1和S2是用户定义的原型。根包P1包含包P2和类C1、S1和C3。P2包含类别C2和S2，类别C1包含一个特征F1。Package通过whole-part关系ownedElement[17，Figure 2-32]知道它的内容，Class通过feature[17，Figure 2-5]知道它的Features第一个检查的元素是self，即P1。 作为一个包，而不是类，它不符合标准。搜索沿着ownedElement向下到P1同样，它从P2和C1下降到他们的孩子。 S1和S2符合条件，并组成结果集合。如果将相同的表达式应用于包P2，则检查元素P2、C2和S2，从而返回S2。现有的扩展机制为建模者提供了强大的工具来增强和简化其表达式。虽然新的操作，甚至是全新的类型都可以添加到OCL中，但这些机制有其局限性。我们不能改变语言的基本原则。不可能使OCL表达式具有边效应，也不可能在计算某个表达式时指定要应用的算法，因为M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-1811.self-> find（元素|2.element.oclAsType（Class）. clientDepth-> exists（cd|3.cd.stereotype.name->includes（'stereotype'）4.和cd.supplier.stereotype.name->includes）6.）图二、查找操作示例包P1C1类特征F1S1类刻板印象包P2类别C2S2类刻板印象C3图三.包和类example.4纯OCLOCL是一种规范语言，首先用于表达约束。它提供了执行计算、比较和字符串操作的基本功能，以及有用的集合操作。一般来说，这种语言非常适合表达约束。约束只是检查的一种形式，因此OCL也可用于检查也就不足为奇了。在上一节中，我们在一定程度上讨论了OCL，结论是OCL具有，或者至少可以扩展为具有足够的查询机制。一个规范语言所需的特性是存在的，但这不足以使OCL本身成为一个合适的模型处理语言。由于OCL在定义方面是无效应的，因此它只能直接用于不修改建模系统状态的操作。这排除了OCL作为许多模型处理操作（例如转换操作）的可行选项。不能修改模型的限制是语言中固有的，不能轻易忽视。要改变这一点，除了简单地向182M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-Context Math：：solveSecondDegree（a：Real，b：Real，c：Real）：Real Pre：b b−4 a c>= 0Post：a查询结果查询结果+ b查询结果+ c =0图四、使用OCL post条件定义操作的示例语法.如果可以修改对象，表达式的求值就不再被认为是即时的。为了保持表达式的人们可能还必须重新考虑失败的导航和其他操作的处理方式，如前所述，限制深深地交织在语言中为了改变它，人们需要仔细考虑其他方面可能会受到影响。虽然不能使用OCL更改系统，但可以使用表达式来指定更改，例如post条件。这种方法的问题主要是由于它的不切实际。post条件描述的是操作完成后系统的状态，而不是如何修改现有的状态来实现结果。必须开发某种机制，用于将任意输入修改为与有效的任意OCL后置条件相匹配的输出。即使在所有情况下都是可能的，但在没有任何关于如何有效地实现结果的提示的情况下，操作的执行往往是非常低效的。下面这个简单的例子，虽然来自数学世界，但说明了这一点。让我们考虑图4中的操作solveSecondDegree，它给出了形式为ax2+bx+c= 0的方程的一个实根如果不知道如何求解这种特殊类型的方程，该机制将不得不求助于更通用的方法，例如或多或少受过教育的猜测。可以在后条件中减少允许的OCL表达式的集合，使得神秘的求解机制总是能够正确地构造结果。例如，我们可以只允许一个等式，其中左手边是一个对象或导航，右手边只引用旧值（或未更改的值）。实际上，为了使post条件完整，我们还必须假设存在一个隐含规则，声明“系统中的其他所有内容都保持未修改”。图5中显示了一个带有受限post条件的操作示例。现在，表达式的右边可以正常计算，并且值用作左边指定的任何新值。赋值在OCL表达式求值之后进行，因此我们避免了本节前面描述的副作用的问题。因此，我们通过以下方式向语言引入了赋值语句：M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-183Context Math：：solveSecondDegree（a：Real，b：Real，c：Real）：Real Pre：b b−4 a c>= 0Post：result =（−b +（b b− 4 a c）.sqrt（））/（2 a）图五、使用受限OCL post条件定义操作的示例将无侧面效应的部分与分配分开。这种方法可以仔细修改以允许多个post条件甚至循环，但它确实需要一些时间。虽然它适用于给出的简单示例，但实际操作要复杂得多，并且用上述残缺的post条件表示它们会产生令人绝望的难以理解的操作。即使对于一个对OCL有着丰富知识和经验的实现者来说，也需要大量的技能和计划来制作必要的OCL表达式。 如果操作是以声明的方式定义的，那么将其转换为正常的OCL post条件通常相当直接。对于有限的员额条件来说，情况不再如此。如果将运算定义为一种算法，那么翻译就变得非常困难。这些问题可以通过将引起副效应的元素（语句）与无副效应的元素（表达式）分开来解决。表达式是标准的OCL表达式，仍然是即时的，完全没有副作用。状态是一种全新的语言结构，它包含表达式，并具有修改模型的能力。每个表达式现在都是一个单独的实体，尽管模型在单个表达式的计算过程中不会更改，但它可以在该表达式之后，在另一个表达式开始之前更改。前面的后置条件构造现在可以被称为赋值语句。同时，我们可以添加更多的语句，例如（控制）if和while。这本质上与定义一种带有嵌入式标准OCL的新编程语言相同。同样的结果也可以通过采用现有的成熟编程语言并将OCL嵌入其中来实现。所有现有的功能，例如与用户的交互，都可以立即提供给程序员。OCL非常适合对模型执行查询和检查。 它是UML的一部分，因此自然满足了高级领域语言的要求。然而，OCL不是一种编程语言，也不应该成为一种编程语言。 通过混合编程语言和OCL，我们可以将每个工具用于最适合的目的。甚至不需要将OCL嵌入到语言中来获得这些好处，只要OCL易于用作表达式即可。OCL支持可以采取以下形式，例如函数库或程序模块。184M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-|1.self.model->find（element2.element.isKindOf（类）3.）.stereotype.name-> forAll（nm|4.self. profile-> find（cl）|5.cl.oclAsType（Class）. clientDepth-> exists（cd|6.cd.stereotype.name->includes（'stereotype'）7.和cd.supplier.stereotype.name->includes）9.）.name->includes（nm）10.）见图6。使用OCL的5用编程语言当然，通用编程语言也可以用于模型处理。它们通常有各种各样的结构化数据类型，良好的选择流程控制语句，以及足够的用户交互机制等。然而，对于模型处理目的，它们有点太通用了。由于缺乏对处理UML模型的直接支持，即使是简单的查询也会变成冗长而复杂的代码。这一点在中间迷失了，不再清楚高层次的想法是什么。这是通用编程语言和高级领域语言之间的权衡。通过缩小范围，领域语言可以为特定任务提供更复杂和更适合的操作，但对于其范围之外的任务不再有用。在本章中，我们将使用Python作为示例，但要点适用于其他编程语言也一样。作为一个简单但有用的例子，考虑要求设计器只对类使用正确定义的构造型。在本工作的上下文中，[26]中的原型一致性规则的变体可以使用纯OCL（图6），使用没有OCL的Python（图7）以及使用OCL和Python（图8）来实现。原型的定义如图1所示。对于用户模型中的每个类图6中的示例显示了这个约束，它使用了通过find操作扩展的OCL。 约束的上下文是一个元组，其中包含原型定义profile（在称为profile的部分中）和模型（在称为model的部分中）。约束首先递归搜索模型中的所有类。对于这些类，建立了以下约束：这些类的所有原型必须在原型定义概要文件中定义。M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-185这个例子虽然比较长，而且没有针对性能进行优化，但它显示了一种建立约束的方便方法。这个例子还说明了OCL的一个很好的特性，即在集合上导航的能力。例如，在第三行，导航stereotype.name引用了所有获取类的所有构造型的名称这使得声明一系列属性的约束变得容易。为了在不使用OCL的情况下执行相同的检查，我们假设一个UML元模型兼容 的 数 据 模 型 ， 并 且 存 在 导 航 操 作 。 我 们 还 将 假 设 存 在 一 个 函 数findAllClasses，它可以检索包层次结构下的所有类。 虽然它的威力远不及正如用OCL表示的匹配条件所发现的那样，它将适用于这个例子。图7显示了用于查找用户定义的构造型名称的纯Python实现。该函数执行与图6第4至8行中定义的搜索操作类似的搜索操作。此外，为了简单起见，纯Python实现假设每个UML元素都存在一个原型，并且只有二进制依赖关系。虽然后一种假设在实践中通常成立，但前一种假设肯定不成立。然而，在这个例子中，我们可以通过为原型定义配置文件定义合适的良构约束来规避这个问题。很明显，需要更先进的机制来导航模型。OCL很自然地满足了这一需求。我们省略了实际的原型检查过程。最后，图8显示了使用Python和OCL查询实现的相同的原型一致性检查。我们假设与上一个示例中相同的数据模型。查询是通过使用两个方法实现的，find和select，可以通过列表类型访问。这两个操作都有一个参数，一个包含匹配条件的字符串作为OCL表达式。变量元素引用操作的迭代器。虽然比纯Python代码更加紧凑和可读，但它很好地分解了纯OCL代码，并通过用户交互和模型操作的可能性对其进行了扩展。还请注意，该示例检索已定义的构造型并对模型执行有效性检查，而图6中的Python示例仅执行第一部分。6模型处理平台实现我们已经开发了一个软件平台的UML模型处理，称为xUMLi。该平台通过提供具有UML元模型兼容数据模型的环境来我们186M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-1.def findAllowedStereotypes（profile）：2.allowedStereotypes =[]3.candidates = findAllClasses（profile）4.对于候选人中的CLS：5.对于cls.clientDependency中的dep：6.如果len（dep.stereotype）>0：7.#假设单一原型8.if dep.stereotype[0].name==9.#这里，假设依赖项是二进制的10.bcls =部门供应商[0]11.如果bcls.Class==12.len（bcls.stereotype）>0和\13.bcls.stereotype[0].name==“元类”：14.#假设单一的刻板印象15.allowedStereotypes.append（cls.name）16.return allowed原型见图7。用于获取用户定义的原型而不使用OCL的1.st = profile.find（\2.”element.oclAsType(Class).clientDependency- |” \3.”cd.stereotype.name-4.”and cd.supplier.stereotype.name- ）5.6.对于model. find（7.for cst in cls.stereotype：8.如果len（st.select（cst.name9.# handle class with wrong stereotype见图8。使用Python一种方法是允许创作小的模型操作并将它们组合在一起，就好像它们是非常高级的模型处理语言的原始表达式一样。操作的链接可以用传统的编程语言来完成，也可以使用特殊的可视化语言VISIOME [18]。VISIOME提供了一个非常高级别的可视化编程范式，它严重依赖于OCL的使用以及一组基本的编程结构，并且在定义软件过程相关的模型处理功能时特别有用。 该环境不依赖于任何特定的CASE工具，但为组件提供了一个插件接口，M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-1871.st = profile.find（\2.“element.clientDependency- > exists（cd|“\3.”cd.stereotype.name-4.”and cd.supplier.stereotype.name- ）5.6.为CLS在model. find（metaclass->includes（ToList（）：7.for cst in cls.Get（8.如果st.select（8b.. 长度==0：9.# handle class with wrong stereotype见图9。使用OCL在工具存储库和数据模型之间传递模型。因此，它可以支持几个不同的案例工具或UML模型库。我们已经为Rational Rose、XMI和一些专有文件格式构建了这样的导入/导出插件。除了数据模型和可视化语言之外，xUMLi还包含 OCL解释器我们选择通过应用程序编程接口来操作解释器服务，而不是直接将OCL嵌入到语言中。OCL表达式作为字符串传递给解释器，而上下文作为数据模型的对象。解释器以及数据模型中的类都是作为公共对象模型（COM）自动化类实现的。这些类的实例可以从支持COM的编程语言中访问，就好像这些实例是该语言的本机对象一样。通常，单个模型操作是使用Python构建的，然后与VISIOME组合在一起，形成具有更复杂功能的脚本。我们还使用C++和Java来实现模型操作。其他支持COM的语言包括Perl和Visual Basic。图9显示了一个使用Python和OCL解释器的实际可执行示例。OCL和Python的结合形成了一个非常有表现力的用户脚本机制，用于执行模型处理操作。该示例与图8中的示例相同，只有四个小修改以适应xUMLi的特性这四种差异将在下文中解释。科. 在图中以粗体字标示OCL解释器于2001年开发，因此遵循OCL 1.4规范。解释器原本是供VISIOME引擎内部使用的，但后来发现它对单个模型操作也非常有用。由于与可视化语言的密切关系及其简单的类型结构，解释器将所有用户定义的对象视为188M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-是动态类型的。也就是说，它们可以具有任何名称的属性，并且每个属性可以包含任意数量的值。因此，解释器无法对导航的有效性执行解析时检查，并且会 很 乐 意 接 受 someClassi filer.name 作 为 其 错 误 输 入 的 形 式 someClassifiler.nmae。因此，尽管xUMLi数据模型本身知道UML元模型的结构，但OCL解释器却不知道。由于对象的动态类型，解释器不支持oclIsKindOf操作。因此，xUMLi数据模型中的每个对象都包含了一个新的属性元类。该属性包含关于对象的元数据，即对象的类所派生的UML元类的名称。例如，在Classifier的对象中的元类虽然这些信息是元数据，但从OCL解释器的角度来看，它只是一个普通的属性。 图9中的第6行包含一个示例，其中使用此构造代替oclIsKindOf。作为应用程序模型盲目性的另一个可能不那么明显的后果，导航总是导致一个集合。例如，在图9中的第8行，element.name会产生一组1或0的字符串，这取决于迭代器元素引用的分类器是否有名称。类似地，为了比较分类器的名称，我们必须编写element.name->includes这当然很烦人，它确实使OCL表达式的阅读稍微困难一些，但它并没有影响语言的表达能力。图8和图9之间的其余两个差异涉及收集。在第6行，ToList（）方法将OCL解释器友好的集合更改为更适合Python和其他动态语言的列表类型。第8b行的只读属性Length包含集合中的项目数。作为与OCL 1.4规范的一个偏差，集合可以被放置在其他集合中，尽管规范明确命令将这些嵌套集合封装起来。从很早开始就很清楚，集合的集合是一个非常有用的结构。此外，在OCL 2.0中引入元组抽象数据类型之前，collection是表示任何类似元组的东西的唯一方法。禁止使用一组元组或一组集合似乎是不必要的，甚至是有害的，因此有些奇怪的限制被忽略了，以及自动删除集合。OCL解释器允许用新操作扩展OCL这些M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-189|扩展被实现为插件。操作被放置在名称空间中，然后可以在语言规范中定义的OCL表达式中使用。我们为收集类型引入了两个新操作find和accounten前者将在第3节中详细解释，后者将从嵌套集合创建一个可扩展的随着OCL 2.0的采用，这将作为扩展而过时扩展的操作放在一个名为std ext的命名空间中。例如，图9中第6行的find表达式在OCL中可以写成model.std ext：：find（ee.metaclass->includes7对八达通卡的本节包含我们在使用OCL的两年中所做的观察我们讨论了OCL的一些简短的例子以及它可以改进的地方。所表达的想法描述了具体的问题，但我们没有详细的解决方案使用OCL的关键点之一是易用性和可读性。OCL规范指出，它6-2][3，pp.2-1]。从我们的经验来看，这更接近于定义一个目标，而不是陈述一个事实。当一个新人第一次接触八达通卡时，他们会感到非常困惑。简短、直接的表达式通常非常清晰，但当复杂性（和大小）增加时，清晰度和可读性就会急剧下降。可能涉及几个因素。例如，用户对OCL的使用并不像他们对首选编程语言那样精通。缺乏格式化表达式的指导，例如缩进规则，也可能起作用，但这并不完全是缺乏经验的用户和编写糟糕的OCL的问题。虽然可以通过注释和变量定义来提高清晰度，但语法似乎倾向于隐藏表达式的结构。毫无疑问，OCL1.4规范的模糊性是最初混乱的部分原因。在OCL 2.0草案中，规范的可读性和组织得到了极大的改进。可以说，OCL标准库中定义的类型和操作并不是很广泛。另一方面，扩展机制是克服预定义操作的限制的优秀和更灵活的手段尽管如此，我们仍然认为需要比allocation更好、更智能的方法来定位模型中的数据，并且这些工具应该包含在标准的OCL中例如，我们的扩展，190M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-parent：Set（GeneralizableElement）;parent= self.generalization.parentSystem. out. println（）;allparents = self.parent->union（self.parent.allParents）[3]不允许notself.allParents->includes（self）见图10。 沿着导航的find操作显然不是很聪明，但它仍然成为我们使用OCL的最常见方式。一个不同类型的高级导航的例子是根据特定导航的传递闭包。这是一个相当 常 见 的 表 达 ， 甚 至 UML 格 式 良 好 性 规 则 也 充 斥 着 它 们 。 例 如 ，GeneralizableElement的规则三[17，pp. 2-59]，禁止循环继承，使用导航泛化的传递闭包。2-60]。该规则及其两个助手定义如图10所示。我们并不建议将这两个例子添加到标准库中，我们提出它们只是为了证明在语言本身中需要更灵活的模型遍历。显然，使用OCL可以为特定导航创建allParents等操作制作一个更通用的版本，一个可以从应用程序模型中的任何类沿着任何导航遍历的版本，只有在我们修复应用程序模型的情况下才有可能。我们的财务运作也是如此。 由于OCL缺乏任何访问类型本身的元数据的方法，因此不可能表达这样的导航，或者指定不与应用程序模型绑定的如果语言包含对访问这种类型数据的更好支持，那么即使在高级泛型操作的情况下，也可以使用OCL本身来扩展以这种方式定义扩展的能力意味着扩展可以在任何OCL解释器中工作，而不管它的起源。这将进一步提高OCL表达式本身的可移植性。虽然扩展的可移植性目前并不重要，但如果CASE工具（和软件设计人员）更大规模地采用OCL，那么在不久的将来它可能会成为一个问题。M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-1918相关工作甚至在OCL 2.0的前夕，也有一些论文的作者发现，与我们类似，OCL对查询信息很有用。例如，Hobart和Malloy讨论了使用OCL查询来调试C++ [9]，Marder等人提出了一个基于UML元模型的UML存储库和API，用于管理和查询UML模型[13]。在后一种环境中，OCL约束可以用来指定和检查UML模型。例如，约束可以保持设计指导方针或语义不变，以加强UML模型的有效性还有一些其他的OCL工具用于模型检查。LCI OCL Evaluator（OCL）[15]是一个独立的模型检查工具，可以与任何CASE工具一起使用。ORACLE使用XMI格式在ORACLE和CASE工具之间传递UML模型。USE系统[22]由不来梅大学开发，是一个独立的系统，用于指定支持OCL的信息系统，以指定模型上的其他完整性约束。Dresden OCL toolkit [10]由几个解析、类型检查和规范化OCL约束的模块组成。例如，它与Novosoft UML（NSUML）[14] Java库一起使用，该库用于各种CASE工具，例如ArgoUML [2]。因此，ArgoUML也支持OCL，允许添加OCL约束，并实现语法和类型检查。然而，模型检查只是模型处理中的一组任务。在这些工具中，像模型操作这样的使用场景不可能单独使用OCL，也不可能将OCL与编程语言结合使用以下三个工具背后的想法可能与我们的想法最接近：图尔库计算机科学中心制作的模型处理工具包[19]、UML通用Transformer（UMLAUT）[28]和Kent建模框架（KMF）的OCL 4Java库[12]。在[19]中，Porres讨论了独立的UML感知编程环境的需求和最重要的特性，依赖于一种类似Python的脚本语言，可以用来从任何UML模型中操作和提取信息。脚本语言和支持环境用于加载、查询、修改和保存UML模型。通过支持XMI序列化，可以实现与现有工具的互操作性。与我们的方法相反，OCL在他们的系统中并不是这样使用的，而是脚本语言 被指定为包括OCL的功能。在他们的方法中，例如，UML的格式良好性规则目前必须手动从OCL翻译成此外，虽然他们使用特定的脚本语言来编写操作，但我们的平台允许使用与特定编程语言无关的独立等。al. [28]开发了UMLAUT，一个致力于MA的框架192M. Siikarla et al. / Electronic Notes in Theoretical Computer Science 102（2004）175-创建UML模型。它们使用