MetaDiff——一个模式比较框架

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 <city></city><place></place>Enterprise Architect

由于使用许可的限制，作者对这些工具的评估无法进行。这个清单并不完整，也不能保证提供良好的解决方案。

第三章 需求分析

这一章以用例的形式对MetaDiff框架的需求分析进行了描述。用例模式是描述系统所需求的功能以及每个功能所表现出的动作（或角色）的模式。用例模式对系统分析和设计中的活动来说是十分必要的。图3.1为UML用例图。<stroke joinstyle="miter"></stroke><formulas></formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f><lock v:ext="edit" aspectratio="t"></lock><shape id="_x0000_i1025" style="WIDTH: 474.75pt; HEIGHT: 148.5pt" type="#_x0000_t75"></shape><imagedata src="file:///D:%5CDOCUME~1%5Cseafrog%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image001.png" o:title="" gain="86232f"></imagedata>

图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 用例：比较模式

在该用例中，框架调用者可对两个