模型库的生成和重用方法

理论计算机科学电子笔记253（2010）121-134www.elsevier.com/locate/entcs模型重用的库概念MarkusHermannsdüorfer1BenjaminHummel2德国慕尼黑大学信息技术学院摘要只要我们谈论源代码，重用和部分系统描述库的组合就是软件工程中一个基本的和很好理解的实践对于模型和建模语言，重用的概念通常仅限于复制粘贴，特别是当涉及到特定领域的建模语言（DSL）时。本文试图给出一个概述的技术，包括支持重用和库的概念，在元模型和建模工具，并提出了一种新的生成方法来完成这项任务。每一种方法的技术后果进行了讨论，并相互比较。关键词：复用，模型库，基于模型的开发1介绍软件工程的一个主要趋势是在软件开发过程中越来越多地使用半形式化模型。这包括用于捕获需求、描述软件的设计和架构或捕获系统的更正式规范的模型。然后，这些模型用于不同的分析和生成任务，这些任务是使用自然语言编写的文档无法实现的-例如检查系统的不同视图的一致性，从模型生成源代码或测试用例，或正式验证。虽然UML [8]一直是软件开发中驱动基于模型的开发的关键角色，但在许多领域中，使用所谓的领域特定建模语言更合适。这些语言的范围从用于数字手表用户界面设计的简单语言[6]，到用于定义业务流程[9]或开发嵌入式系统软件的更复杂的语言，例如众所周知的Matlab/Simulink [11]。随着这些模型变得越来越重要，规模越来越大，重用公共子模型成为一个重要的问题。重复使用经过良好测试的1电子邮件：herrmama@in.tum.de2电子邮件：hummelb@in.tum.de1571-0661 © 2010 Elsevier B.V. 在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2010.08.036122M.赫尔曼斯德弗湾Hummel / Electronic Notes in Theoretical Computer Science 253（2010）121-134模型降低了引入错误的风险，并降低了总体开发成本。从长远来看，识别常用部件并将其放入库中供以后使用-可能添加参数化机制-有很多与通常的复制粘贴重用相比，首先，它使重用更加结构化和系统化，因为它明确了哪些部分实际上是设计用于其他地方的-而不是仅仅掠夺现有模型。 第二、它允许更好地组织分析和测试活动，通过创建良好理解和测试的元素库。最后，它极大地简化了对变更的处理，无论是由于需求的变化还是检测到的错误。如果没有库，则必须事先找到要更改的模型部件的所有副本，尽管有现有的自动化方法[2]，但这是一项繁琐且容易出错的任务[4]。因此，我们认为特定领域建模语言的元模型和编辑器应该支持结构化重用和库概念。问题陈述尽管在模型级别重用的需求经常得到确认，但在用于将重用和库支持集成到建模语言中的模式和概念方面，只有很少的工作可用。特别是不同的实现可能对底层元模型以及操纵和分析模型的工具产生的影响很少讨论。贡献本文试图给出一个可能的选择实现复用和库支持到DSL的元模型和工具链的概述。因此，我们总结了一个“众所周知”的技术，以及在文献中建议，并介绍了一个（尽我们所知）新的生成方法来实现它，我们的重点是特别的影响和后果的讨论，通过选择其中之一暗示。这些想法和见解主要源于AutoFOCUS 33的当前开发，AutoFOCUS 3 3是用于建模嵌入式系统的Auto-FOCUS研究原型的重新实现[10]，以及COLA语言的专有编辑器[7]，该编辑器是在汽车领域的行业项目背景下开发的纲要下一节将介绍我们正在运行的示例，该示例用于演示添加重用支持的影响。秒3给出了现有的approaches的概述，而Sec.4介绍了我们对这个问题的解决方案。节中5.在我们结束第二节之前，我们讨论了每一个结论所隐含的后果第六章[3]实际上，这里讨论的概念是称为CCTS的基础框架的一部分 详情请访问http://af3.in.tum.de/。M.赫尔曼斯德弗湾Hummel / Electronic Notes in Theoretical Computer Science 253（2010）121123信道组件*inPorts *输出端口*源1 1目标*渠道Fig. 1.运行示例元模型。2运行实例我们使用一个数据流语言的面向组件的系统规范作为一个运行的例子在整个文件。语言的元模型摘录 在图1中被描述为一个UML类图。一个组件定义了一个语法接口，它由输入和输出端口组成（inPorts和out-Ports）。一个组件或者是一个基本组件，或者是由子组件组成的，从而产生了一个组件层次结构。组件的子组件通过通道彼此连接。组件的通道将源连接到目标端口-构件复用是减少系统描述工作量的关键技术。现在，我们希望以一种支持组件重用的方式扩展我们的建模语言。在下文中，可以重用的组件称为组件类型。我们应该能够通过所谓的库来提供组件类型。当涉及到组件的重用时，重用的组件被称为组件类型的实例。一个组件类型的实例可以用在任何可以使用常规组件的地方，例如在另一组分的组成中。一个实例必须知道它的组件类型，这样它才能适应这个组件的变化我们故意保持运行的示例尽可能简单，以便能够传达我们的想法。 然而，我们在上下文中开发的元模型我们的工具更广泛，定义了一百多个类。 这是由于事实上，相应的建模语言也提供了类型系统，允许指定组件属性，并允许我们在不同的抽象层次上对系统进行建模，如需求和技术实现[1]。因此，重用不仅应该对组件启用，还应该对不同的构件（如类型、需求或硬件组件）启用。因此，我们需要一个通用的重用概念或模式，它不仅适用于组件，而且适用于不同的工件。3现有方法关于模型重用技术的文献相当少，因此在本节中，我们集中描述两种最突出的集成重用方法端口组件124M.赫尔曼斯德弗湾Hummel / Electronic Notes in Theoretical Computer Science 253（2010）121-134inPorts*输出端口1类型1类型*组件*渠道源1目标1**inPorts*输出端口构件库PortInstance组件实例PortBase信道端口组件图二、实例类的介绍变成一种建模语言。第一种方法通过引入新的类在元模型级别解决问题，而第二种方法通过引入通用克隆机制在元-元模型级别解决问题。我们详细介绍了这两种方法的特点，并将它们应用到我们的运行示例中， 并提到它们对元模型和建模工具的影响3.1实例类可以通过引入显式建模实例的类来集成重用类型。这种技术在[3]中提出，它被应用于许多特定领域的元模型模式。在下文中，引入的类称为实例类，而类型的类称为类型类。 从实例类到其对应类型类的关联允许实例知道其类型。这种关联必须是多对一的，因为一个实例只有一 个 类 型 ， 而 一 个 类 型 可 能 有 多 个 实 例 。如 图 2 所 示 ，引 入 了classBecomentInstance来对组件类型的实例进行建模。对应的类型类Component可以通过关联类型从实例类Compo- nentInstance访问。为了允许从其他元素引用实例，该类型的某些子元素也必须被实例化。然后，一个实例基本上复制了类型结构的某一部分，我们在下面称之为接口。必须向元模型引入额外的约束，以确保实例正确地复制类型的接口。 在我们的示例中，组件的接口也由输入和输出端口组成。 如图2所示，因此，我们必须为端口引入一个实例 类 ， 即 类 PortInstance ， 以 及 在 PortInstance 和 PortInstance 之 间 的 inPorts 和outPorts组合。此外，我们必须添加约束以确保每个组件实例M.赫尔曼斯德弗湾Hummel / Electronic Notes in Theoretical Computer Science 253（2010）121125由每个组件端口的实例组成为了能够在与类型相同的上下文中使用实例，引入了实例类和类型类的公共超类。这些通用的超类必须是抽象的，因为它们的目的是使实例和类型能够互换使用。组成元素使用上下文的关联必须以这些新的超类为目标。在我们的例子中，我们 必 须引 入 新 的 类 ObjectBase 作 为 Component和 ObjectInstance 的 公 共超 类 ，PortBase作为Port和PortInstance的公共超类（见图2）。组合组件被重定向到类ObjecentBase，这样组件实例也可以用于组合组件。此外，关联源和目标被重定向到类PortBase，以便端口实例也可以通过通道连接简而言之，这种模式要求扩展元模型。 对于类型接口的每个类型类，必须引入两个新类：实例类和实例和类型类的公共超类。此外，实例类之间的结构必须复制类型类之间的结构。此外，必须添加新的约束以保证实例与其类型的一致性。 随着元模型的修改，在元模型上，例如，编辑和口译员的工作必须加以调整，以满足重用的需要。这还包括将类型的接口更改传播到其实例的功能。现有的模型不必迁移，因为Meta模型修改保留了现有的模型元素。然而，未来的元模型扩展，扩大接口的类型需要引入新的实例类。在这种情况下，模型的迁移是必要的，因为必须为现有实例复制额外的我们将这种技术应用于在工业项目背景下开发的COLA语言[7]。在我们开始为该语言开发工具之前，实例类已经被集成。尽管如此，该工具的实现变得更加复杂，因为它必须考虑额外的实例类。稍后的开发步骤添加了一个额外的抽象级别，这需要到现有组件的跟踪链接。由于子组件的组合不是接口的一部分，实例的子组件不直接表示为模型元素，因此跟踪链接不能以它们为目标。 为了能够处理这样的实例，我们不得不使用以下解决方法：通过从根组件引出的路径引用实例沿着类型/实例树。然而，这种技术降低了元模型的整体简单性，因为这些路径必须与组件结构保持一致。3.2通用克隆机制前面的技术只需要复制类型的接口。[5]中概述的另一种技术是完全复制类型的内部结构。这使得在以下级别以更通用的方式集成重用成为可能：元元模型因此，这种能力必须由126M.赫尔曼斯德弗湾Hummel / Electronic Notes in Theoretical Computer Science 253（2010）121-134原型克隆inPorts输出端inPorts输出端组件组件p4：端口p3：端口p1：端口p2：端口c4：组件c2：组件c3：组件c1：组件图三.组件的泛型克隆底层的元建模框架。作者通过GME（Generic Modeling Environment4）提供了一个参考实现类型基本上是通过创建元素的副本来实例化的。由于这种技术在基于原型的编程语言中是已知的，因此在下文中，类型被称为原型，实例被称为克隆。由于元建模框架，克隆知道它所派生的单个原型。 作为在图3中被描绘为UML对象图，通过产生克隆c2来重用组件c1。 虚线指示克隆c2关联到原型C1。克隆实际上是原型的深层副本，这意味着它也复制原型的内部结构。克隆人的孩子也知道原型的孩子，他们是从原型派生出来的，等等。 图3示出克隆不仅复制组件，还复制其端口和子组件。一个克隆体与它所衍生的原型具有相同的类型。因此，它可以很容易地在与原型相同的上下文中使用。因此，组件的克隆也是Component类型，因此可以使用组成其他组件。由于克隆知道其对应的原型，因此对原型的更改会自动传播到克隆。克隆可以独立于原型进行修改--对原型的修改只会传播到克隆的未修改部分。 在我们的示例中，向组件添加端口会导致将端口克隆添加到所有组件的克隆中。 的克隆可以通过添加新端口来定制组件由于它的通用性，这种技术不需要对Meta模型进行任何扩展。然而，元建模框架必须提供克隆模型元素的能力。据我们所知，这种功能目前只存在于GME。由于克隆是在元-元模型级别上实现的，4http://www.isis.vanderbilt.edu/Projects/gme/M.赫尔曼斯德弗湾Hummel / Electronic Notes in Theoretical Computer Science 253（2010）121127所有类型的模型元素都可以被克隆-没有限制。由于方法学问题，克隆可能只允许某些类型的模型元素。与前一种技术相比，类型在实例化时必须完全复制。此外，必须在模型中维护有关克隆的哪些功能被覆盖或未被覆盖的信息。这可能会过度增加必须存储在模型中的信息量。此外，通用克隆受到以下限制：克隆只能从内部结构中不使用克隆的原型产生。如果不强制执行这一限制，这可能会导致克隆有几个原型。在图3中，如果端口p1和p2之间存在克隆关系，则无法从组件c1生成克隆，因为端口p4将具有两个原型4生成库对于CCTS/AutoFOCUS 3框架，我们开始考虑库，当时元模型已经包含近100个类，并且许多核心功能，如图形编辑器，表达式计算器，模拟器和代码生成器的第一部分已经实现，导致超过50.000行源代码。因此，解决方案必须是微创的，尽可能少地删除元模型和现有代码，因为无法获得用于检查整个代码库的总体思想是设计一个库机制，它尽可能与现有的元模型和建模工具正交。因此，对于现有的代码，更改应该是透明的，提供与以前使用的模型兼容的模型。 这导致我们采用类似于[5]的方法，其中实例实际上是这些类型的完全克隆。 主要的区别是，我们的重点是一个更结构化的重用机制，其中元素可能不会被任意克隆，但只有专用的库元素可以被实例化。此外，我们的方法以一种允许我们参数化实际上由类型生成的实例的方式推广了克隆。与GME相比，克隆被深深地集成到元建模框架中，我们的方法可以很容易地建立在每个现有的元建模框架之上。例如，我们的建模工具是在EMF（Eclipse建模框架5）之上实现的。然而，它在建模工具的实现中复制了GME的一些功能。在下文中，我们概述了总体方法，并提供了更多的技术细节和我们的方法的影响。4.1大局在我们的设置中，我们在包含类型的库和包含这些类型的实例的导入模型之间进行了区分。 协会 实例到其对应类型的转换仅通过名称执行（惰性链接），5http://www.eclipse.org/modeling/emf/128M.赫尔曼斯德弗湾Hummel / Electronic Notes in Theoretical Computer Science 253（2010）121-134生成库已启用库组件inPorts *端口参考0.. 1图书馆参考name：Stringversion：参变数组件*输出端口*源1 1目标* 渠道信道prototypes 1.. *generate（）name：String版本：长参数对象LibraryElement见图4。 生成库的元模型。其允许实现不同的存储和查找方案。例如，我们决定将库保存在单独的文件中，可以由其他模型单独导入。使用我们的方法，元模型增加了三个类6，不管有多少现有的类应该被重用。这些类及其用法如图所示。四、抽象类LibraryEnabled用于标记所有可以用作类型的元模型类。LibraryEnabled引入了一个引用，它允许区分“普通”模型元素和实例。如果引用没有指向库中的类型，则它是普通元素，否则关联的LibraryReference存储被引用类型的名称、上次更新使用的版本以及 用于生成当前实例的参数赋值。在我们的例子中，只有一个组件可以通过库重用，但是对于更大的元模型，可以很容易地将多个元素标记为类型。LibraryElement类是库中类型的容器，它定义了一个名称，一个版本号，这个版本号必须随着这个元素的每次更改而递增，以及一组支持的参数。最重要的是存储在LibraryElement中的原型。原型组合物可以包括任何建模元素（在图4中通过使用对象来指示，是所有元模型类的传递超类），然后可以使用它来生成该元素的实例。 LibraryElement充当工厂，一个特定类型的类（由列表中的第一个原型确定）通过其generate（）方法生成一个基于参数赋值的实例。为了解释元模型类实际上是如何使用的，我们解释了创建、实例化和修改库元素的三个用例6根据库的内部组织方式以及用于参数化的机制，库文件夹和参数可能有更多的类然而，元模型元素的增长是恒定的。M.赫尔曼斯德弗湾Hummel / Electronic Notes in Theoretical Computer Science 253（2010）121129创建库元素新 类 型 的 创 建 包 括 LibraryElement 的 创 建 ， 然 后 由 所 需 的 原 型 组 成 。LibraryElement使用什么信息从给定的参数创建实例取决于实现。最基本的版本只是返回其第一个原型的副本，这与第二节中提出的克隆方法相对应。3.2. 在我们的工具中，我们还尝试包含Groovy7脚本，然后这些脚本根据给定的参数使用这些原型生成一个新实例。在我们的示例中，这可能是端口的数量和组件的子组件的类型。关于生成没有进一步的限制，除了库元素总是必须返回同一个类的实例作为生成结果（在我们的例子中是一个组件）。库元素要实例化库元素以便在现有模型中重用，调用相应元素的generate（）方法，并将结果插入到模型中。因此，生成的实例完全存储在模型中，这确保了模型具有与在没有库支持的情况下构建的模型相同的结构。 这对于避免前面提到的现有代码中的复杂更改至关重要。通过附加一个LibraryReference 来完成生成的元素，LibraryReference存储用于创建的库元素的名称和版本。包含纯拷贝的一个副作用是，即使没有依赖的库，模型也拥有所有必需的库元素构建库机制的最重要原因是支持库元素的修改，然后应该由它的所有实例来反映。由于我们仅通过标记实例的源代码来建模重用，并且库引用仅通过其名称松散耦合，因此我们必须在建模工具的实现中处理重用的某些方面。 第一部分是， 库元素的版本号必须随着每次更改而增加，由于这些更改是使用建模工具执行的，因 此 这 应 该 不 会 有 问 题 。 使 用 版 本 号 ， 我 们 可 以 很 容 易 地 识 别 过 时 的LibraryReference（即指向库元素的较早版本），因此必须被更新的版本替换。在我们的实现中，这种检查是由用户手动触发的，以允许完全控制对前模型的修改，因为库中的更改是对模型正确性的潜在威胁。然而，根据工具基础设施，这样的任务也可以在某些事件上自动执行。由于库元素的原型也可能是库实例，因此检查和更新过程必须以递归方式执行。7http://groovy.codehaus.org/130M.赫尔曼斯德弗湾Hummel / Electronic Notes in Theoretical Computer Science 253（2010）121-134更有趣的部分是库元素的所有实例的更新。实际上，我们必须用一个新的模型来替换模型的一部分，这个新的模型是由generate（）方法生成的。在这里，简单地交换模型部件是不够的，因为一个实例可能包含从其他部件引用的元素 模型（例如，到它的一个端口的通道）或布局和命名信息，我们不想失去这些信息。我们的解决方案使用了一个修改过的合并算法，它用新的模型部件替换旧的模型部件，但保留了所有对外部（相对于被交换的部件）元素的引用。使用现代的响应元建模框架，如EMF，这可以通过一种通用的方式来实现，只需要少量的代码（我们的实现有大约300行代码，包括注释）。然而，这段代码必须稍微调整，使用的元模型，因为它必须不同地处理一些数据。例如，在AutoFOCUS 3中，实例中最顶层元素的名称可能会更改由用户创建，不应被库中的更改覆盖4.2技术考虑和影响使用到目前为止描述的方案，建模工具代码的大部分都可以保持不变。 所需要的只是用于创建和管理库的新代码，以及在修改相应的库元素后处理实例更新的新代码。还有一些额外的小修改没有在这里描述。例如，人们通常希望查看库实例层次结构中的元素，但不应该（或仅以某种有限的方式）允许更改它们，因为这些更改在从库更新实例后会丢失。因此编辑器必须支持模型的（部分）只读部分。 总而言之，我们的实现基于EMF，大约有3000行，包括管理库（文件夹等）的代码。这里没有描述。特别是像在修改时更新库元素的版本号这样的任务，是使用递归侦听器来实现的，递归侦听器对元素或其子元素的所有更改做出反应。实现的元模型特定部分可能仅限于合并算法，尽管它保持足够的通用性，以便仅在严重的元模型更改时进行更新，例如更改布局数据的存储方式。在其他应用程序中重用代码仍然很困难，因为大多数代码都是针对我们的建模工具（例如，如何将编辑器切换到只读模式等）。总而言之，我们的解决方案的实施和修改工作非常易于管理，特别是当完整（推出）模型可用并且单个元素的识别和引用很容易时。然而，我们的方法也有一些缺点。最明显的是模型的大小增加，因为存储了冗余信息。虽然理论上模型元素的数量可以呈指数级增长，但根据我们的经验，被重用的元素通常相对通用且较小，因此它们的数量不是主要问题。 被重用的较大元素通常用于解决专门的任务，因此只使用几次（例如，用于监测汽车车轮压力的部件）。我们的估计表明，增长是一个常数，这取决于实际模型，但在M.赫尔曼斯德弗湾Hummel / Electronic Notes in Theoretical Computer Science 253（2010）121131标准实例类通用克隆生成库（第二节）（3.1）（第二节）（3.2）（第二节）四、元建模框架+–+元模型规模–++型号尺寸+––深度引用–++执行工作–+0重用策略计划特设计划任意参数化机制––+自动更新实例0/-+0/+表1重用方法的比较2到10的量级。由于目前可用的磁盘空间和内存大小，这通常不是什么大问题，但对于特定应用程序或超大型模型可能是一个问题。我们的方法的另一个问题是稍微隐藏的重用结构。虽然模型的相似或相同部分可以通过查看在图书馆参考资料，他们的开发，例如。只为这些部分生成一次代码，可能比显式实例类更复杂。在参数化的情况下尤其如此5讨论为了简化重用机制的选择，并澄清所提出的方法的 讨论的摘要见表1。1解释在本节的其余部分中更详细地介绍。我们要强调，没有“最佳”办法。根据不同的要求和背景，所提出的每一种方法都可能是最合适的。此外，标准的重要性对于每个应用程序都是不同的，所以简单地“总结优点”并不是一个有效的评估。相反，应评估是否存在硬敲除标准（例如，，如果元建模框架是固定的，并且不是GME，则通用克隆可能不是一个好的选择），然后应优先考虑和评估其余标准。元建模框架我们的第一个标准是该方法在多大程度上独立于所使用的Meta建模框架。很明显，使用实例类的方法可以很好地132M.赫尔曼斯德弗湾Hummel / Electronic Notes in Theoretical Computer Science 253（2010）121-134在任何元模型的上下文中使用，因为它只使用标准的元建模构造。这也适用于我们的生成方法，因为我们不依赖于元建模框架的特殊功能。 只有实现可能 稍微复杂一些，如果元建模框架不支持recruitment。相比之下，通用克隆目前仅在GME中实现，并且扩展不同的元建模框架以支持通用克隆是一项重要的任务。元模型规模元模型的大小和复杂性影响了开发人员理解和使用它所需的时间和时间，因此，更大的元模型更有可能以不期望的方式使用。另外，如果Meta模型要由约束支持，则这些约束的数量和复杂性通常也随着元模型的大小而增加。正如前面的例子所示，在使用实例类时，必须为每种类型引入许多类。 相反，生成式方法只需要引入恒定数量的类，不管有多少类在元模型中被标记为类型。 在基因克隆中，byextensions扩展to the meta元-meta元-model模型.型号尺寸如前所述，模型的大小可能不是最关键的因素，因为磁盘和内存的成本很低。仍然有一些应用程序，其中模型可以达到大小，这需要一个空间效率的表示模型的。这些应用程序可能从使用实例类中获益，其中模型中的冗余被减少到最小。其他两种方法都存储和操作完全扩展的模型，其中所有实例实际上都是其类型的完整副本。通用克隆甚至需要额外的存储来跟踪对所有克隆的功能的深度引用对于许多应用程序，我们必须引用模型元素，这些元素是实例的一部分。示例包括需求跟踪或部署模型。对于泛型克隆和生成库来说，创建这些深层引用非常容易，因为 实例的所有部分都在模型中实现，因此可以引用。 这对于实例类是不同的，其中这些部分在相应的类型中只表示一次。然后，解决方案要么使用更复杂的构造来引用这些元素（例如沿着类型/实例树的路径），要么必须在模型中部分实现实例。 在我们的示例中，已经为实例复制了端口，以允许通道连接到它们。但是，引用组件实例的子组件要复杂得多。M.赫尔曼斯德弗湾Hummel / Electronic Notes in Theoretical Computer Science 253（2010）121133执行工作另一个重要因素是在实现使用这些模型的编辑器和工具时所需的插件。当使用GME框架时，通用克隆方法需要最少的资源，至于工具，无论它们是在原型上还是在克隆上工作，都是完全透明的。所有克隆和再利用问题都由GME处理。这对于生成库来说几乎是一样的，但是类型及其实例的管理必须由我们的工具来处理。如前所述，为此的实现任务仍然是可管理的，并且编辑器仍然不需要调整。当使用实例类时，处理模型的工具，如编辑器和模拟器，必须处理额外的实例类。重用策略在某种程度上，重用方法会影响可用的重用策略。我们区分了有计划的重用，其中元素被显式地标记或建模为可以通过实例化重用的类型，以及ad hoc重用，其中每个元素模型可以作为原型。哪一个是首选，取决于所使用的域。例如，在嵌入式系统开发中，有计划的重用通常是受欢迎的，因为库中发布的组件可能必须进行更严格的测试和文档化。在其他情况下，特别的重用可能更合适，因为建模者不必通过决定将哪些部分放入库来中断建模流程。实例类和生成库更倾向于有计划的重用，而泛型克隆更好地支持即席重用。然而，这些之间的区别有些模糊，因为当然，特别重用可以通过建模工具来限制，以将其锻造成更有计划的方式，并且可以实现库类型的自动创建，以使计划重用的应用程序更加任意参数化机制实例类和泛型克隆都只支持相当简单的参数化机制。通常，一个实例只是一个类型的副本，可能有一些属性取决于参数。使用我们的生成方法，其中实例由库元素的方法生成，包括实例元素的模型结构的实例可以由参数选择来确定。这也简化了不同参数化概念的包含，从而简化了这里的实验自动更新实例使用重用机制的关键方面是每当类型发生变化时更新实例。虽然第一次认为这似乎是免费的实例类，但它实际上是最昂贵的。在我们的示例中，实例的子组件是自动更新的，因为它们只存在于 类型，但是当组件类型的端口改变时，端口实例总是必须被更新。这种情况与生成库类似，但当我们134M.赫尔曼斯德弗湾Hummel / Electronic Notes in Theoretical Computer Science 253（2010）121-134总是复制整个实例，更新/合并算法可以保持更通用，这大大简化了其实现。通过通用克隆，更新被深度集成到元建模框架中6结论本文概述了将重用集成到模型和建模语言中的不同方法。 重点特别放在元模型和建模工具的实现上。对于现有的建模语言要通过库机制扩展的情况，提出了一种生成方法，该方法只需要对元模型和现有代码进行少量修改。为了帮助选择其中一种方法，我们从几个方面讨论了它们的优点和缺点。没有一种重用方法明确地支配其他方法，但是给定特定的上下文和需求通常会简化选择。正如我们的讨论所揭示的，使用类型和实例类的“经典”解决方案通常会不必要地使工具的实现复杂化。 与文本建模（如源代码）相比，受控克隆在许多情况下似乎是有益的。引用[1] M. Br oy，M. Feilkas，J. Grunbauer，A. Gruler，A. Har hurin，J. 哈特曼湾 彭岑斯塔德勒湾 S c h？atz和D.野 外UmfassendesAr chitekturm odellfur？dasEngineeringeinge betteter Sof tware-i ntensiverSysteme. 技术报告TUM-I 0816，慕尼黑大学技术，2008年。[2] F. 戴森伯克湾Hummel，E.杰庚斯湾Schaetz，S.Wagner，J.-F. Girard和S.托歇特基于汽车模型开发中的克隆检测。在Proc. 30 th Int. Conf. on Software Engineering（ICSEACM，2008年。[3] M. 福勒分析模式：可重用对象模型。爱迪生-韦斯利·朗曼出版公司股份有限公司、美国马萨诸塞州波士顿，1997年。[4] Elmar Juergens，Florian Deissenboeck，Benjamin Hummel，and Stefan Wagner.代码克隆重要吗在proc 第31届国际软件工程会议（ICSE'09），2009年。出现。[5] G. Karsai，M. Maroti，A. Ledeczi，J. Gray，and J. Sztipanovits.建模与元建模中的组合与克隆。IEEETransactions on Control Systems Technology，12（2）：263[6] S. Kelly和R. Pohjonen。跨平台产品系列的特定领域建模。在Proc. Conceptual Modeling - ER 2002，第21届概念建模国际会议（研讨会），第182-194页。Springer，2002年。[7] S. Kugele，M. Tautschnig，A. 鲍尔角S. challhart，S. Merenda，W. Ha berl，C. Kühnel，F. 穆勒，Z. Wang，中国山杨D.怀尔德，S. Rittmann和M.微信COLA -组件语言。技术报告TUM-I 0714，Te chnischeUni versit？atMu？nchen，2007年。[8] 对象管理组。统一建模语言，Superstructure，v2.1.2，2007。[9] 对象管理组。Business Process Modeling Notation，v1.1，2008。[10] 伯恩哈德·舍茨和弗兰茨·胡伯。 集成形式描述技术。 在P roc. FMSpringer，1999年。[11] 数学工作公司Simulink 7用户