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: http://www.andromda.org/.
[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: http://www.xactium.com/.
[9] Eclipse Modeling Framework (2004) [Computer Software] [On-line]. Accessed on December 1, 2004 at URL: http://www.eclipse.org/emf.
[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: http://www.eclipse.org/gmt.
[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: http://www306.ibm.com/software/awdtools/rup/.
[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: http://www.dsv.su.se/ 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: http://mdr.Netbeans.org/.
[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: http://www.omg.org/mda.
[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日初稿）
