MetaDiff－一个模式比较框架 （翻译草稿，待审校）  译者注：这是来自瑞典斯得哥尔摩大学计算机和系统科学系的一篇硕士论文，由Mark Kofman撰文，导师为Erik Perjons。本文的中文译者为山东大学计算机科学与技术学院的本科生周翔。中文译文中省略了原文中的目录部分。  摘要  在软件开发中，开发模式重要性的日益提高产生了许多新的关注和挑战。本论文主要讨论了在模式驱动开发的环境中模式比较的问题。本论文的目的是为了描述一个名为MetaDiff的模式比较框架的需求分析，以及怎样来设计并实现它。这个框架是在现有的元对象工具（Meta Object Facility，MOF）标准的基础上建立起来的。作者希望这个框架能够在模式管理、实现特定的模式比较工具和算法组装等方面下一步的相关试验研究中派得上用场。 第一章  简介 1.1    背景 人们对模式驱动方法产生了越来越浓厚的研究兴趣，并在应用中给予了越来越多的支持。这些模式驱动方法包括模式驱动软件开发（Model Driven Software Development）[6]、对象管理组织的模式驱动构架（OMG Model Driven Architecture）[24]、语言驱动开发（Language Driven Development）[8]等等。一些开源项目，比如Eclipse Generative Model Transformer (GMT) [13]、Netbeans Metadata Repository (MDR) [22]、Eclipse Modeling Framework (EMF) [9] 、AndroMDA [3]和各种不同的CASE工具的厂商的工作实现了用于模式驱动开发的各种不同的组件。建模能为整个系统的开发和维护提供的一种更好的基础，然后才是以代码为中心的开发和维护[19]－－这些方法都是以这种想法为基础的。在这些方法的指导下，模式已不再仅仅开发的附属产物，而是构建软件应用程序的至关重要的组成部分。然而，日益提高的开发模式的重要性产生了许多新的关注和挑战。其中的一类问题与对建模工具的正确管理有密切关系。 1.2    问题 如果你看一看普通的以代码为中心的开发环境，你就会发现一些功能特性，这些功能包括环境所集成的版本控制、不同版本的合并和比较，以还包括一些使团队开发更便捷的工具。但是这些工具大多是面向单一的文本文件的，并且仅仅适用于以常规的编程语言为基础开发过程。将这些复杂的功能转换为模式驱动工具开发是不太容易的，因为在这其中存在着一些问题需要这一领域的专家和研究人员指出。 根据参考文献[17]，模式比较在模式驱动开发的实践中是一个关键性的挑战，处理这个问题时，有下面几个方面需要大家的注意： l         在一些面向对象的语言中，你可以把整个系统按照逻辑上和物理上的要求将其分为一些类。然而，建模语言缺少这样在物理上将其分解的标准方法。这常常导致大量的信息集中存储在一个模块单元中。 l         各个模块使用不同的符号来表示，这些符号通常是图形化的。但是，在区分各个模块逻辑上的不同的时候，这些符号起不到有效的作用。 l         视觉效果的不同在使用模式图表处理问题时也是一个需要引起重视的因素。现在的基于文本的比较工具通常使用两个窗口分别来显示接受比较的文本。但是使用这种方法来表示模式的不同的不切实际的。 l         模式的组织并不是像文本那样是顺序线性的。而是由各个整体组成树型或图型的结构[17]。因此，必须使用其他的技术来研究这些模式的不同。 问题描述：为了解决这些方面的问题，研究人员和工程人员需要进行广泛地试验。正因如此，他们需要一个合适的基础构架解决方案。这个基础构架可使他们能够根据自己的兴趣进行研究，并观察其他方面是怎样影响并介入其他方面的。此外，通过将来自各方的组件整合在一起，这个基础构架可以产生新的思路和结果。 1.3    目的和意图 这篇论文的目的是介绍这样一个基础构架。这个构架可以用来描述对一个通用的、半自动化的模式比较解决方案的需求、设计和实现。通用，在某种意义上说就是，它可以用来比较基于各种不同元模式（meta-model）的模式。半自动化，在某种意义上说就是，比较是由计算机来操作的，但是，这个算法需要调用者提供附加的信息和指导。 为了达到这样的目标，需要实现下面的结果（目的）： l         现在的论文并不致力于解决上面提到的所有的问题。然而，做为讨论的结果，需要将这些结果原型化以成为对这些问题感兴趣的研究人员的富有价值的工具。它意味着，对新的有效的比较和合并算法包括通用和元模式识别算法的继续研究是可能的。我们可以就不同的图表的可视性的问题做试验，并研究这个领域中相关问题。 l         现在的框架在实际的实践过程中也是适用的。不同的工具制造商可以在现有框架的基础上实现各自的具有特定功能的比较和合并工具。在现有的框架的基础上构建的比较和合并工具可以用于版本控制系统，用来改进对模式的处理。 1.4    方法 作者将归纳和演绎的方法暗中蕴含在这篇论文中。模式比较框架需要下面过程提供的数据： l         对在其他领域下不同模式比较技术的研究需要完成。对一般文本文件、XML文件、XML格式文件的研究需要完成，并且要为一个模式比较框架提取出合适的需求报告。 l         由包括IT University的研究人员在内的模式驱动开发和格式分析领域的专家参加的头脑风暴会议。 l         模式比较框架的早期原型用于需求优化。 在搜集到的需求的基础上，进一步分析和设计框架。 接下来，在开发原型框架的时候，使用Rational统一流程（Rational Unified Process）[15]。建模时使用UML语言[26]。 在研究的早期阶段，原型被广泛应用于实践，保证了理论概念的可用性。框架原型就是通过现实世界的实例来评估的。 由于要对运行结果进行评估，系统框架作为开源项目的一部分发布出来，这样有利于获得较多的用户反馈和模型的改进。 1.5    局限性  框架原型可以用两套MOF标准的Java开源系统实现（Eclipse EMF [9] 和NetBeans MDR [22]）。这意味着框架只能为模式资源与这些系统的协调一致提供支持。这个局限性可以靠整合其他的MOF标准的方案来解决。利用其他面向对象的语言实现原型也可以增强了框架自身的适用性。  由于时间关系，对框架的开源版本的用户反馈评估将不在本论文中讨论。  1.6 论文结构  本论文结构如下。在第二章我们给出了概念、思路、以及相关研究成果的介绍，而这些内容将在论文接下来的章节中广泛采用。在第三章，我们定义了开发框架的需求。在第四章，我们集中讨论了框架的设计和实现，而在第5章，我们给出了具体的应用实例。第6章是总结。  本论文结构如下。在第二章我们给出了概念、思路、以及相关研究成果的介绍，而这些内容将在论文接下来的章节中广泛采用。在第三章，我们定义了开发框架的需求。在第四章，我们集中讨论了框架的设计和实现，而在第5章，我们给出了具体的应用实例。第6章是总结。  本论文结构如下。在第二章我们给出了概念、思路、以及相关研究成果的介绍，而这些内容将在论文接下来的章节中广泛采用。在第三章，我们定义了开发框架的需求。在第四章，我们集中讨论了框架的设计和实现，而在第5章，我们给出了具体的应用实例。第6章是总结。  第二章 概念和相关工作  第二章 概念和相关工作  2.1 概念和基本定义  在这一节中将简要介绍本文中出现的基本概念。  2.1.1 模式驱动开发  近些年来，产生了许多不同的模式驱动方法。其中最有名的是对象管理组织的模式驱动构架（Model Driven Architecture from OMG） [24]、模式驱动软件开发（Model Driven Software Development）[6],和软件工厂（Software Factories） [14]。所有的模式驱动开发理论都强调模型在开发过程中做为基本单元的重要性。在建模过程中，模型转换是主要的操作，用于将信息从一种模式中转入另一种模式。这种软件生命周期的观念被视为一个模型转换链。  2.1.2 模式和图表  在定义模式和图表时，本文使用了对象管理组织的统一建模语言（OMG’s Unified Modeling Language）[26]类似的概念。图表是对模式的另一种看法或者另一种视角。图表通常通过图形符号来表示。  2.1.2 模式和图表  在定义模式和图表时，本文使用了对象管理组织的统一建模语言（OMG’s Unified Modeling Language）[26]类似的概念。图表是对模式的另一种看法或者另一种视角。图表通常通过图形符号来表示。  2.1.3 元对象工具（Meta-Object Facility ，MOF）  2.1.3 元对象工具（Meta-Object Facility ，MOF）  元对象工具(MOF) [25]提供了一个模式仓库用于模式的具体化并可以通过其对模式进行管理。MOF可以看做是一种设计和实现新型模式语言的工具。  2.1.4 元模式层（Meta-Model Layer）  2.1.4 元模式层（Meta-Model Layer）  在MOF中，建模的概念主要是分类器（classifier）和实例（Instance），或者类（Class）和对象（Object），还有将实例转到其分类器（元对象，meta-object）的能力。“元模式层”这个重要的概念有时用来组织建模层，以使之转化为更高的元层次（metalayer）。每一种上一级的元层次由其下一级的分类器构成。MOF标准确保可以按照需要随便定义许多层次。然而在大多数情况下仅限于定义4个层次。  传统构架是基于下面的4层结构的：  传统构架是基于下面的4层结构的： l         M0层，包含应用程序数据（例如，由一个面向对象系统运行时产生的实例，或者相关数据库的表中的某些行）。 l         M1层包含应用程序；包括面向对象系统的类，相关数据库的表的定义。应用程序可在这一层建模（也被称为类型或模式级别）。 l         M2层，包含概括语言的元模式：例如，UML元素，如类，属性，操作等。工具在这一层发挥作用（也被称作元模式或构架层）。 l         M3层，是元模式的元模式层，给出了所有元模式层（M2层）中能够获得的元模式的属性。这一层定义了建模语言，用来提供各种工具相互通信的方式。  2.2 相关工作  2.2 相关工作  尽管作做的很少，一些作者已经开始着手本文在这个方面讨论的问题。相似的问题已经在格式表的上下文和数据库综合中被提了出来。按照我的想法，我给出了本论文中最重要的几个问题，以概括我所做的工作的内容。相关研究方面的工作是获得模式比较框架的需求规范的主要途径。  2.2.1 模式管理  2.2.1 模式管理  模式管理的目标是为模式驱动应用程序的开发者制作一个统一的基础框架，这种模式管理基础框架必须把模式、元模式和映射之间的关系做为首要内容，并提供各种方法操作它们。  其他的模式管理问题将在相关的文献[4]中给出：  其他的模式管理问题将在相关的文献[4]中给出： l         有多种不同的方法来表征模式和映射：数据库中的相关格式表，科学界中的属性图，软件工程中的UML模型等，这种对基础结构的过于统一化的定义被认为是模式管理中严重的问题。 l         在与这些结构相关操作的定义中也会出现类似的麻烦。 l         相关工具的开发可以简化模式管理认为并使之自动化。  微软研究院[5]近几年在通用的模式管理的领域中已经做了一些研究。他们建立了一个代数运算符的集合。这些运算符是：  微软研究院[5]近几年在通用的模式管理的领域中已经做了一些研究。他们建立了一个代数运算符的集合。这些运算符是： l         匹配（Match）运算符－将两个模式做为输入并返回两者之间的映射。该映射可以识别在输入模式中等价或相似的对象的联合体，这取决于外部给该系统的等价或相似的标准定义。 l         复合（Compose）运算符－输入模式A到模式B的映射和模式B到模式C的映射，返回模式A到模式C的映射。 l         差（Diff）运算符－输入模式A和从A到模式B的映射，返回A中不参与映射关系的那一部分子集元素。 l         模式生成（ModelGen）运算符－输入模式A，返回一个基于A生成的新模式B和一个A和B之间的映射。 l         合并（Merge）运算符－输入模式A和模式B，以及它们之间的映射，返回A和B的联合C，以及C和A、C和B之间的映射。  本论文会讲述使模型管理任务自动化和简化的工具的迫切需求，并且这样的工具可以被看做是对上面已经讨论过的通用模式管理基础构架一小部分的实现。  2.2.2 比较算法  在符号序列中比较其中的不同的问题已被广泛地研究（见参考文献[29], [18], [21]）。因此，用于文本比较工具的算法和解决方案大量地涌现出来。这些成果都使开发实际的文本模式比较工具（比如GNU Diff和其他的一些工具）成为了可能。  随着研究的深入，出现了用于比较结构化对象的比较算法。近几年，很多作者的文章（见参考文献[28], [7]）中提到了树的差别分析问题。由此产生了一个使用这些算法的实际的应用技术，，这种技术已发展出许多用于XML和HTML等一些结构化文档的比较算法。  尽管树的差别分析算法应用的并不是很广泛，但是使该算法应用于建模工具的研究已经开始进行了。在文件[2]中，作者描述了为基于MOF的模式提供的差别分析算法，这个算法会体现在本论文实现原型化的问题中。  参考文献[27]中描述了一些与匹配技术相关的算法。不同的格式匹配方法有所区别：格式级（schema-level）和实例级（instance-level）的匹配、元素级（element-level）和结构级（structure-level）的匹配和基于语言（language-based）和基于约束（constrained-based）的匹配。本文中所描述的框架的目标是能够使之管理这些不同的匹配方法。  2.2.3 数据库格式综合  这里讨论的类似的问题已经在介绍格式表的上下文和数据库综合中的文献（比如[16], [27], [1]）中被提了出来。数据库格式综合是将现存的要进行操作的数据库的格式整合为一体的过程，在此过程中采用统一的格式。这在该领域中是一项浩大的工程，其中对本论文有重要意义的工作在IT University的DSV department完成[16]。这些工作指出了在联合系统中出现的格式整合问题。  2.2.4 差异的可视性  模式通常使用图形化的符号来表示，比如UML图表。参考文献[23]指出了图表差异可视化的重要性，该文章还建议使用不同的颜色来标识图表的差异，除了语意的差别之外，作者还指出了设计中需要改进的地方，比如将类移出图表。  开发的框架应该能够为显示差异提供不同的方法。  2.2.5 CASE工具  值得一提的是，一些CASE工具制造商希望通过本论文获得一些元模式的细节模式比较和合并的解决方案。而这个解决方案将是这个领域的一个重大进展，然而，这并不意味着这篇论文会提供一个完整的解决问题的方案。  作者首先确定了下面支持团队开发的一些工具： l         Omondo EclipseUML l         Rational Rose Tool Family l         Enterprise Architect  由于使用许可的限制，作者对这些工具的评估无法进行。这个清单并不完整，也不能保证提供良好的解决方案。  第三章 需求分析  这一章以用例的形式对MetaDiff框架的需求分析进行了描述。用例模式是描述系统所需求的功能以及每个功能所表现出的动作（或角色）的模式。用例模式对系统分析和设计中的活动来说是十分必要的。图3.1为UML用例图。 图3.1 用例图  3.1 概括描述   3.1 概括描述  MetaDiff框架是一个为建模工具设计的可扩展的模式比较解决方案。框架的核心是一整套接口或者称其为可扩展的模版。这样的一个可扩展模版所主要实现的是保证在框架的基础上能够容易地添加新的模式比较算法。这个框架的主要使用者是这一领域的工具制造商和研究人员，他们可以使用这个框架来开发他们自己特定的组件。  3.2 角色目录（Actor Catalog）  角色目录描述了与框架有关的不同的角色，并对框架中每个角色的需求进行了简要的描述。图3.2为UML中的角色。 图3.2 角色图  其中，框架调用者（Framework Caller）通过调用方法来使用框架功能。被模拟的系统是一个软件框架，它不提供任何用户接口。这说明框架调用者并不是人所扮演的角色，尽管它使用系统提供API，而它更可以将它看做是一个软件组件或其他的调用框架方法的工具。框架调用者在特定的情况下能够独立地工作，比如框架扩展者（Framework Extender）不能在很大程度上改变框架调用者使用框架的方式。  框架扩展者（Framework Extender）是一个可将框架的功能进行扩展并将其应用于自己的环境中的角色。这是人扮演的角色，该角色通常将将模式比较框架作为一个组件用于开发较大规模的系统过程中。  工具开发者（Tool Developer）属于框架扩展者，他开发提供模式比较功能的建模工具。工具开发者通常持有特定的元模式。这个角色的作用主要是扩展框架功能以使建模工具更适合往后的模块集成工作。  研究人员（Researcher）是另一种框架扩展者。他的工作是来尝试新的研究思路。这一角色的目标是为下一步相关问题的研究对框架进行扩展，这个过程通常是通过在框架的顶层建立不同的原型的方法来完成的。  3.3 用例模式  3.3.1 用例：匹配模式  可以模式匹配看作是一个函数，它将两个模式作为输入，返回两个模式之间的映射作为输出。在匹配结果中的每一个映射元素反应了从一个模式中的特定元素到另一个模式中的特定元素之间的逻辑对应关系（见参考文献[27]）。  此用例发生在框架调用者欲找出两个模式的映射关系时。首先，框架调用者指定模式匹配所使用的算法；然后调用模式匹配函数。框架执行被选中的算法并返回映射结果。这种映射在下面第3.3.2节提到的比较模式用例中最有可能用到。然而这种映射操作也可以在本用例中被框架调用者独立地执行。  在特定的情况下，模式匹配会成为难题。在一些情况下，它涉及对不同的人建立的模式的语意理解方面的问题[16]。因此，一些算法需要调用者或相关人员提供关键性的帮助才能够完成工作。框架的设计应为这一类匹配算法提供扩展。  3.3.2 用例：比较模式  在该用例中，框架调用者可对两个模式进行比较。首先，框架调用者指定用于模式比较的算法。然后调用模式比较函数。你也可以有选择地为框架调用者指定两个模式之间的映射，该映射可用于比较算法。最后，调用者可以获得基于选定的算法的运行结果，结果指明了两种模式的不同之处。而这个运行结果也可被看作差异偏移量（comparison delta）。  在一般情况下，用来比较的模式必须是在相同元级别（meta-level）上的两个实例。然而，为了避免在比较时遇到模式转换的麻烦，比较操作可作用于不同元模式（meta-model）的两个实例。框架在这方面不应该有所限制，但是对于比较算法来说，输入的模式和元模式要符合算法的要求，并能被算法接受。  和匹配算法类似，一些比较算法依赖于调用者和相关人员的帮助。框架设计应该是可扩展的以适用于这类比较算法。  3.3.3 用例：实现新的模式匹配算法  框架扩展者应该在可用元模式的基础上为模式匹配实现自己的算法。算法必须适合元模式的特性，并将一特定类型的模式作为输入。算法也应该是通用的，在某种程度上来说，这些算法只利用了MOF层的信息。  3.3.4 用例：实现新的模式比较算法  框架扩展者应该能够为模式比较实现自己的算法，如果需要或者方便的话，这些算法是根据元模式、格式化的比较偏移量和匹配算法来构造。算法必须适合元模式的特性，并将一特定类型的模式作为输入。算法也应该是通用的，在某种程度上来说，这些算法只利用了MOF层的信息。  3.3.5 用例：建立新的比较偏移量格式  目前还没有严格的方法表示模式比较的结果。各种各样的比较偏移量格式对表示模式比较结果有重要的作用。因此，框架扩展者应该能够根据需要定义自己的比较偏移量的格式。  3.3.6 用例：加载新的元模式  框架扩展者应该能够根据需要加载新的元模式。这个活动在实现MOF标准时被指定用于加载元模式。需要值得注意的是，对新的元模式进行定义并不是全自动的，它需要相关人员编写代码并使代码在框架内部整合。  3.4 计划说明书：构建模式比较工具  工具开发者作为其中的一个角色是通过使用MetaDiff框架来支持模式驱动工具的开发。我们不妨建立一个计划说明书来描述工具开发者成功完成任务的过程。图3.3是这个计划说明书的活动图。 图3.3： 计划说明书：构建模式比较工具的过程  整个过程由下面几个步骤组成： l         评估支持MOF标准的实现方法。在通常情况下，最好的选择是使用现有的实现方案。如果没有适合你的目的的方案，你可以实现你自己的MOF解决方案。 l         评估现有的元模式。你必须保证框架能够处理你的模式资源。这意味着你所使用的元模式应该提前加载。你也可以使用现有的基于MOF标准的解决方案来定义新的元模式。 l         评估现有的模式匹配和比较算法。你有可能重复使用现有的算法或算法中的一部分。然后实现自己的算法。 l         最后，你就可以在模式比较工具中使用这个框架了。  第四章 设计和实现 在这一章中，我们提出了MetaDiff模式比较框架的设计方案。  4.1 构架 图4.1：MetaDiff的构架  就像图4.1表示的这样，在较高的层次上看，MetaDiff框架可分为三个组成部分： l         扩展模版（Extension Template）－用于对框架进行各种扩展的接口的集合； l         基础构架（Infrastructure）－是加载不同模式资源的功能在MOF标准和各种元模式定义上的集成化的构架实现； l         扩展（Extensions）－基于MetaDiff框架的分布式的通用和专用扩展集合。扩展在基础构架的顶层实现，并能够实现扩展模版的接口。  MetaDiff框架是由Java语言实现的，并建立了下面的代码库（packages）： 图4.2 Java Package之间的依赖关系  l         org.metadiff －框架中最基本的代码库。 l         org.metadiff.template －该代码库中包含了框架中的主要接口。 l         org.metadiff.infra －该代码库中包含了与框架的基础构架相关的类和子代码库。 l         org.metadiff.infra.ecore －该代码库中包含了与Eclipse EMF的使用相关的类和接口。 l         org.metadiff.infra.mdr －该代码库中包含了与NetBeans MDR MOF系统的使用相关的类和接口。 l         org.metadiff.ext －该代码库中包含了对框架的扩展代码。包括框架中已经实现的那一部分。  l         org.metadiff.ext.generic －通用扩展类的集合。 l         org.metadiff.ext.tucs －在参考文献[2]中讨论的比较算法的实现代码。 l         org.metadiff.ext.deltaXML －在商业化XML比较工具DeltaXML的基础上实现的比较算法。  4.1.1 扩展模版设计  扩展模版对添加新的匹配比较算法和比较偏移量提供了便捷的途径。扩展模版是由一组接口组成，并提供给框架调用者使用，扩展模版的这种功能在用例模式中表示出来。图4.3为扩展模版的类视图。 图4.3：扩展模版的类视图  现在的基础构架是以符合MOF标准的两个用Java实现的解决方案为基础的。其中一个解决方案是Eclipse EMF [9]，另一个是NetBeans MDR [22]。两者都允许用户定义他们自己的元模式并提供了反射API（reflective API）来访问模式数据。这些API可用来实现匹配和比较算法。现在的MetaDiff框架并不提供通用的模式访问接口，但这正是其努力实现的目标之一。  4.1.3 扩展  MetaDiff框架提供了由不同的扩展组成的集合。作者认为其中最重要的是TucsDiffFinder、DeltaXMLDiffFinder和IdBasedMappingFinder这三者。 l         TucsDiffFinder通过实现了在参考文献[2]中说明的比较算法扩展了ModelDiffDinfer。该扩展是基于Ecore元模式（译注：Ecore元模式是在UML的类图中用Ecore标识的元模式）的。 l         DeltaXMLDiffFinder是基于商业化的XML比较工具DeltaXML实现的，它可以比较保存在XML中的模式。 l         IdBasedMappingFinder是ModelMappingFinder的扩展类。它使用对象的ID对两个模式进行匹配操作。这种形式的映射非常适用于一个模式的两个版本之间的差异比较。  我们发现下面的扩展也是很有用的： l         特定的元模式算法使用了元模式中用于改进算法质量和效率的有关信息，比如UML比较算法。 l         ModelMapingFinder的不同扩展。参考文献[27]给出了模式比较算法的详细的分类。 l         ModelComparisonDelta扩展为一个元素集，其中的元素为模式提供了可添加或删除元素的集合。 l         ModelComparisonDelta扩展为一个模式。它将偏移量（delta）看做一个模式，这样可使用户有可能将模式转换操作作用在偏移量上。这也需要在比较算法中对这种情况进行特殊的处理，以保证偏移量能够成为一个结构良好（well-formed）的模式[5]。  4.2 案例的实现  在这一节中，我会讲述扩展模版和各种扩展方案是怎样实现在第三章中描述的需求的。  4.2.1 匹配模式  l         假设框架调用者是FrameworkCaller类的一个对象； l         FrameworkCaller通过实现ModelMappingFinder接口定义了一个匹配算法； l         如果需要回调（callback），你可以使用自己特定的逻辑实现MappingCallback接口； l         FrameworkCaller加载了两个模式的实例，这两个实例使用了MOF实现的特定的加载功能类，比如org.metadiff.infra.ecore.util.ModelLoaderUtil或org.metadiff.infra.mdr.util.ModelLoaderUtil； l         FrameworkCaller调用ModelMappingFinder 类对象中的matchModels方法； l         ModelMapping返回结果，结果中包含两个模式之间的映射关系。  4.2.2 比较模式 假设框架调用者是FrameworkCaller类的一个对象； l         FrameworkCaller通过实现ModelDiffFinder接口定义了一个比较算法； l         如果算法中使用了映射，则实例化ModelMappingFinder接口； l         如果需要回调（callback），你可以使用自己特定的逻辑实现DiffCallback接口； l         FrameworkCaller加载了两个模式的实例，这两个实例使用了MOF实现的特定的加载功能类，比如org.metadiff.infra.ecore.util.ModelLoaderUtil或org.metadiff.infra.mdr.util.ModelLoaderUtil； l         FrameworkCaller调用ModelDiffFinder类对象中的findDiff方法； l         ModelComparisonDelta返回结果，结果中包含两个模式之间的差异。  4.2.3 实现新的模式匹配算法  需要值得注意的是，定义新的模式匹配算法是一个框架扩展活动。它不能够自动地完成编写代码和将代码与框架集成的工作，而是需要由人来协助。使该活动变得更方便和直接是该框架的目标。 l         你可以实现ModelMappingFinder接口，或者扩展一个现存的扩展。 l         如果需要的话，扩展ModelMapping或它的任何一个扩展。 l         建立你的扩展类。 l         现在，你就可以使用你前几步创建的扩展来识别模式间的映射关系了。  4.2.4 实现新的模式比较算法  需要值得注意的是，定义新的模式比较算法是一个框架扩展活动。它不能够自动地完成编写代码和将代码与框架集成的工作，而是需要由人来协助。使该活动变得更方便和直接是该框架的目标。 l         你可以实现ModelDiffFinder接口，或者扩展一个现存的扩展。 l         如果需要的话，扩展ModelComparisonDelta或它的任何一个扩展。 l         建立你的扩展类。 l         现在，你就可以使用你前几步创建的扩展来识别模式间的差异关系了。  4.2.5 实现新的模式比较偏移量的格式  需要值得注意的是，定义新的比较偏移量的格式是一个框架扩展活动。它不能够自动地完成编写代码和将代码与框架集成的工作，而是需要由人来协助。使该活动变得更方便和直接是该框架的目标。  l         你可以实现ModelComparisonDelta接口，或者扩展一个现存的扩展。 l         建立你的扩展类。 l         现在，你就可以使用你前几步创建的扩展来表示模式间的差异关系了。  4.2.6 加载新的元模式  在框架的基础构架的基础上，可以加载新的元模式。这个活动对每个MOF的解决方案来说都是特定的。  Eclipse EMF的文档[9]中详细描述了建立Ecore元模式的方法。简单起见，框架扩展者需要完成下面的活动： l         使用Eclipse EMF的功能实现元模式，EMF的文档中讨论了这个活动的细节； l         为保证实现你的元模式，你必须提供其所需要的特定的代码库； l         如果你愿意，可以通过扩展EcoreResource来使用org.metadiff.infra.ecore.util.ModelLoaderUtil中的帮助类来加载你的模式资源。 l         现在，你可以使用EcoreResource或你在前几步建立的扩展标识你的基于元模式的资源了。  NetBeans MDR的文档[9]中详细描述了建立MDR模式的方法。简单起见，框架扩展者需要完成下面的活动： l         使用支持XMI导出功能的UML或MOF建模工具建立你的元模式； l         建立适用于JMI Java的接口和类，用于访问元模式实例中的数据； l         在MetaDiff框架中将生成的代码和所需要的代码库整合起来； l         如果你愿意，可以通过扩展MdrResource来使用org.metadiff.infra.mdr.util.ModelLoaderUtil中的帮助类来加载你的模式资源； l         现在，你可以使用MdrResource或你在前几步建立的扩展标识你的基于元模式的资源了。  第五章 实例  我们开发了MetaDiff框架的两个应用实例。参考文献[20]中有这两个实例完整的源代码。  5.1 UML模式匹配工具  假设我们为UML 1.4 [26]开发基于命令行的模式匹配工具。该匹配工具的特点是它不能自动识别映射，但是它可以向人询问每个模式元素之间的映射关系。  我们按照建立模式比较工具的计划说明书进行开发，但需要注意的是，我们的工具仅仅具有模式匹配的功能。  l         有一个用NetBeans MDR定义的UML 1.4元模式供我们使用。 l         我们使用CallbackMatchingFnder扩展来提供与人交互的功能。同时我们实现了特定的MappingCallback接口。对每一次回调，我们的实现方案会让调用者使用命令行来选择用于匹配的一个元素。 l         我们通过Java类库实现了框架调用者访问MetaDiff的功能。  5.2 为Swallow模式建立Diff工具 假设我们为Swallow模式开发基于命令行的模式匹配工具。Swallow是由Eclipse GMT开源项目开发的简单元模式，它可以被看做是模式驱动软件开发[6]方法的一个实例，这个实例在参考文献[10]中有详细介绍。你可以在图5.1中看到这个元模式的EMF类图。 图5.1：Swallow元模式  我们按照建立模式比较工具的计划说明书进行开发： l         Swallow元模式是使用EMF Ecore定义的，并被现在的框架基础构架所支持。 l         现在，我们通过向类目录中添加jar文件的方式加载Swallow元模式。所有需要的代码库都能够从Eclipse GMT的项目中获得。 l         我们决定使用参考文献[2]中提供的框架来实现我们的算法，所以我们并不必自己建立新算法。 l        我们使用Java类来实现框架调用者访问MetaDiff的功能。  为了测试这个工具，我们引入了参考文献[10]中讲到的简单用户说明书应用模式（simple guest book application model）。在Swallow元模式的基础上，我们定义了用户说明书模式的第一个版本，并对其进行了相应修改以适用于那种模式。在图5.2中，你可以看到两者模式（译者注：Guest Book模式和对其修改后的模式）的树型表示，我们对原始的Guest Book模式进行了下列修改： l         将"guestbook"更名为"gb" l         为"GuestBook"类添加了新属性 l         在"GuestEntry"类中删除了"text"属性 图5.2：Guest Book应用模式版本  建立起来的工具在运行时会有下面一些不同的操作： l         建立Attribute类型的元素 l         将新建的Attribute类型的元素的name值由"null"设为"name" l         将Attribute的name值为"text"的由"text"设为"null" l         将Package的name值由"guestbook"改为"gb" l         将名为"GuestEntry"的Class元素到名为"null"的元素之间的链接删除 l         在Class元素的名为”GuestBook”的Attribute和名为"name"的Attribute之间插入一链接 l         通过将Attribute改为"null"将其删除  第六章 总结  6.1 达到的结果  本论文的主要贡献是发展了MetaDiff－一个可扩展的模式比较框架。这个框架提供了扩展模版（Extension Template）－由一些接口构成的集合，并为这些接口进行扩展提供了良好的条件。基础构架（Infrastructure）使符合MOF标准的解决方案、元模式集和扩展集整合在一起，这证明了扩展模版所具有的价值。  我们现在的工作取得了下面有益的成果： l         在MetaDiff框架的基础上，下一步的研究工作就比较简单了。下一步的工作只建立原型就可以。通过框架扩展进行试验对研究人员来说是一个重要的进步。 l         MetaDiff扩展模版能够被扩展以提供广阔的模式管理功能，而且能够通过它处理更加抽象的理论问题。 l         建立起来的框架还具有实践价值。领域特定语言（Domain Specific Language，DSL）的开发者可以使用这个框架在他们各自的领域中实现模式比较解决方案。而且我们在此通过Eclipse GMT的Swallow元模式的一个简单的例子，向大家演示了这个功能。  6.2 以后的工作  我们在下面列出了与本论文有关的以后要完成的工作。  6.2.1 改进扩展模版  不断地实现这个目标是非常重要的。现有的各种不同的框架扩展为扩展模版的升级提供了引导思路。一些通用的抽象类作为其中的以部分可以添加到扩展模版中，用来促使扩展功能的改进。  6.2.2 建立新的框架扩展  随着不同的扩展组件的增加，框架会越来越具有价值。下面我们认为的对模版最重要的进一步的改进方法： l         不在对象识别器的基础上对ModelMappingFinder进行扩展，以保证框架可以在更广泛的情况下使用； l         实现流行的元模式的比较算法； l         为ModelComparisonDelta的扩展建立结构良好的层次，这样会改进框架应用和比较偏移量视觉效果； l         对ModelDiffFinder和ModelMatchFinder的扩展可以对不同元模式进行模式比较和匹配。  6.2.3 包含其他的模式管理功能  当用户使用该框架时，对框架提供的功能进行扩展是十分重要的。作者认为，可以通过实现全部的模式管理功能来扩展框架的功能。  6.2.4 对团队开发问题的研究  在模式驱动开发的过程中，有一些团队开发的问题，作者认为开发的框架能够帮助表明这些问题： l         比较偏移量的图形表示的问题。特别是考虑到工业化的建模语言中的图形符号，清楚并且含义明确的表示模式差异是一个非常重要的目标。在现在的框架上建立原型可以为研究提供思路。 l         对框架的可测量性研究对模式比较来说是非常必要的，这一点在现实世界中对大型团队项目有可能采用的大型模型特别重要。  参考文献 [1] Alacig, S., Bernstein, P.A. (2001): A Model Theory for Generic Schema Management, Proc DBPL, Springer Verlag LNCS. [2] Alanen, M. and Porres, I.(2003): Difference and Union of Models. TUCS Turku Centre for Computer Science, Department of Computer Science, Åbo Akademi University. [3] AndroMDA Code Generator Framework (2004)[Computer Software][Online]. Accessed on December 1, 2004 at URL: [4] Bernstein, P.A., Shapiro, L.(2003): Summary of NSF IDMWorkshop Breakout Session NSF IDM Workshop. [5] Bernstein, P.A.(2003): Applying Model Management to Classical Meta Data Problems. Proceedings of the CIDR Conference. [6] Bettin, J.(2004): Introduction to Model-Driven Software Development. Business Proccess Trends, MDA Journal, Aprill 2004. [7] Chawathe, S. and Garcia-Molina, H. (1997): Meaningful change detection in structured data. In Proceedings of the ACM SIGMOD International Conference on Management of Data, pages 26-37, Tuscon, Arizona. [8] Clark, T., Evans, A., Sammut, P.,Willans, J.(2004) [On-line]: Applied Metamodelling - A Foundation for Language Driven Development, Version 0.1. Accessed on December 1, 2004 at URL: [9] Eclipse Modeling Framework (2004) [Computer Software] [On-line]. Accessed on December 1, 2004 at URL:  [10] Emde Boas, G. van (2004): Template Programming for Model-Driven Code Generation OOPSLA/GPCE: Best Practices for Model-Driven Software Development. [11] Fowler, M.(1999): UML Distilled: A Brief Guide to the Standard Object Modeling Language, (2nd ed.). [12] Fowler, M.(2003): UML Distilled: A Brief Guide to the Standard Object Modeling Language, (3rd ed.) pp 79-83. [13] Eclipse Generative Model Transformer (2004) [Computer Software] [Online]. Accessed on December 1, 2004 at URL: [14] Greenfield, J. and Short, K.(2004): Software Factories: Assembling Applications with Patterns, Frameworks, Models & Tools. John Wiley & Sons. [15] IBM Rational: Rational Unified Proccess homepage (2004) [Online]. Accessed on December 1, 2004 at URL: [16] Johannesson, P.(1993): Schema Integration, Schema Translation, and Interoperability on Federated Information Systems. Doctoral Thesis, Department of Computer & System Sciences, Stockholm University, pp 1-25. [17] Lin, Y., Zhang, J., Grey, J.(2004): Model Comparison: A Key Challenge for Transformation Testing and Version Control in Model Driven Software Development. OOPSLA/GPCE: Best Practices for Model-Driven Software Development. [18] Lowrance, R. and Wagner, R. A.(1975): An extension to the string-to-string correction problem. J. ACM, 22, (2), 177-183. [19] Mellor, S.J., Scott, K., Uhl, A., Weise, D.(2004): MDA destilled. Principles of Model-Driven Architecture, Addisson-Wesley. [20] MetaDiff Model Comparison Framework (2004) [Computer Software] [Online]. Accessed on December 1, 2004 at URL: emismak/metadiff/index.HTML. [21] Myers, E. W.(1986): An O(ND) difference algorithm and its variations. Algorithmica, 1:251-256. [22] NetBeans : Metadata Repository (2004) [Computer Software] [On-line]. Accessed on December 1, 2004 at URL: [23] Ohst, D., Welle, M., Kelter, U.(2003): Differences between Versions of UML Diagrams. European Software Engineering Conference and ACM SIGSOFT Symposium on the Foundations of Software Engineering. [24] OMG : Model Driven Architecture homepage [On-line], Accessed on December 1, 2004 at URL: [25] OMG (2003): Meta Object Facility (MOF) 2.0 Core Specification. [26] OMG (2003): Unified Modeling Language, Version 1.4. [27] Rahm, E., Bernstein, P.A.(2001): A survey of approaches to automatic schema mathing. The VLDB Journal 10: pp 334-350. [28] Shasha, D., Wang, J., Zhang, K., and Shih, F.(1994): Exact and approximate algorithms for unordered tree matching. IEEE Transactions on Systems, Man, and Cybernetics, 24(4):668-678. [29] Sellers, P. H. (1974): An algorithm for the distance between two finite sequences; J. Combinatorial Theory, Series A, 16, 253-258.   （全文完 2005年3月12日初稿）