使用IBM模型轉換框架進行模型轉換

首先，你將了解對MTF的簡要概述（它是什么，有哪些重要的用例，等等）。然后你將了解貫穿這篇文章的基本概念（映射關聯以及映射語言的語法）。

本文實際上是一個闡明如何為一個具體例子書寫規則的循序漸進的指南，而這個具體例子是指從一個UML(統一建模語言)轉變為關聯模型。每一步表達了一個新的映射規則，并解釋了相關的概念；在需要的地方有類圖描述規則。

指南結束于一個MTF安裝工具的表達，它使你能夠運行例子。最后，結論部分概括了本文中涉及的概念并推薦了一些其他資源。

在軟件開發中使用建模
使用建模是軟件工業的一個上升趨勢，正如模型驅動工程的興起和對象管理組織（OMG）最新的產品——模型驅動體系架構（MDA）——的發布所指出的。欲知更多信息，請參考本文后面的資源一章。模型轉換在本文中起了關鍵作用，因為它能使你：

• 把已有模型映射到其他模型
• 在不同模型之間建立通訊和可追溯性

在2002年，作為Meta Object Facility (MOF) 2.0標準版的一部分，OMG提出了建立允許用戶查詢、建立并維護視圖以及轉換MOF模型的標準的建議。這一MOF 2.0標準被稱為MOF 2.0 Queries/Views/Transformations (簡稱QVT)。在2004年11月，一些愿意遵從該標準的公司（包括IBM）開始合作定義QVT標準。當時的規約還需要大量的修訂。如果需要關于OMG初始版本的更多信息，請參看本文末尾的資源部分。

什么是模型轉換框架？
作為參與QVT標準的一部分，IBM已經開發了一個模型轉換工具包的原型，稱為MTF，現在可以從alphaWorks獲得(見資源)。MTF實現了QVT的一些概念，并且是基于EMF的。它提供了一種簡單的聲明語言，可為定義模型之間的映射而用，另外為了完成轉換還提供了一個轉換引擎，它解釋了映射的定義。

MTF的目的是通過支持遞增的更新、雙向的檢查、調和以及可追溯性簡化你開發轉換工具的工作。最常見的相關用例包括：

• 模型、代碼和文檔產生
• 模型比較和合并
• 設計模板擴展
• 模型一致性

MTF的外在形式是一組你可以在Eclipse或者IBM軟件開發平臺產品上部署的插件。它為EMF模型和一組幫助你書寫、運行和調試映射規則的工具提供轉換引擎。規則編輯器提供了基本編輯特性（比如語法檢查）。調試器允許你一步步地跟蹤規則的運行。映射視圖使你能夠在轉換完成時監視轉換的結果。

有趣的是，轉換引擎并不是只期望在一個Eclipse環境內部運行的。它只依賴于EMF運行時庫，因此它可以用于任何Java™應用以及Eclipse插件中。

MTF基礎

模型轉換概念
術語模型轉換背后的主要思想是根據預先定義元素間的關聯，根據輸入的其它模型產生模型。它假定為了使用一致性方式表達通訊，這些模型是用兼容的通用模型描述的。在QVT的作用域內，模型轉換與MOF模型相關。MTF把這些概念應用于EMF模型。

一個MTF轉換的結果是一組映射，它們把不同模型中的對象聯系起來；一個與任何映射都無關的對象被認為是位于轉換域外的。指定模型間的映射提供了定義轉換結果的聲明方式。比如說，如果一個映射需要目標模型中存在一個對象，轉換引擎將試圖創建該對象來滿足映射的需要。

關聯個體實例的映射也許不是指明一個轉換最簡明和方便的方式。你可能偏向于在類的級別上定義通訊，而不是為每一個實例定義。為了做到這一點，你可以指明關聯相同類型的對象的映射，并把它們命名為關聯。在MTF中的一個關系(也稱為一個映射規則)定義了一種可應用于給定模型類的實例的映射類型。在某種意義上，一個關聯的語義與一個限制十分相似。

下面的圖1是一個例子，指明了兩個模型（分別用紅色和藍色表示）之間的映射，其中包含了用于相關實例產生三個映射(m1, m2和m3，用白色表示)的兩個關聯(A2C和A2D)。

圖1 兩個模型間的映射的例子

MTF下的轉換是用一種聲明的方式定義的：你指明模型類間的一組關聯，然后讓MTF引擎使用關聯作為輸入完成轉換操作。轉換引擎的工作分為兩個階段，分別是映射和調和。在映射階段，引擎評估關聯，并通過在相關模型實例中進行迭代產生映射。在這一階段的最后，一些映射可能與關聯不一致。換句話說，不是所有關聯要求的限制都被滿足了。

調和試圖通過創建缺失的元素，修改現有的元素，或者刪除元素來滿足所有關聯。在某些情況下可能不需要調和（比如模型已經是一致的了，或者你只想檢查模型的一致性而不想改變它們）。此外，調和不是永遠可能的（如果從映射沒有可引用的值調和就是不可能的）。這些概念現在看來有點抽象，但是在后面的章節中我們將給出詳細的解釋。需要記住的主要思想是下面這個過程：

關聯 > 映射 > 映射 > 調和 > 更改的模型

關聯的組織方式是符合模型的結構的。通常你會在每個模型類中找到至少一個關聯，從聯系頂級模型類的關聯開始。與基于規則的系統相似，從一個關聯中調用另一個關聯是可能的，而且可以把映射的執行傳遞到有聯系的模型類。這種機制稱為通訊，它允許MTF通過把從頂級關聯開始的所有通訊變為可到達的（直接或間接）橫跨一個完整模型。

MTF支持一個靈活的轉換模型，它可以接受多個模型，聯系多個元素，并更新多個模型。關聯沒有指定評估的任何方向，它們可以在多個方向下執行，這在你處理雙向問題時是很有用的。轉換的方向（源和目的）實際上是在你調用轉換引擎時被定義的。

為MTF編寫規則
正如你可能已經猜到的，驅動轉換的關聯在MTF中起著重要作用。它們是用一種叫做關聯定義語言(RDL)的語言來表達的，該語言被轉換引擎分詞和評估�；�于結構化特性之間的通訊，RDL允許類之間的關聯的定義和應用。比如，一個典型的關聯會用一個匹配標志符屬性聯系兩個類。語言的語法很簡單，只包含幾個關鍵詞和標準布爾操作符。

關鍵詞relate允許使用表1中的格式定義關聯。名字和形式參數都在關聯中定義。在一些情況下你可以限制這些參數來過濾匹配的值。關聯的主體通常包含需要用于匹配的值屬性的通訊，這樣可以傳遞轉換的執行�；�于類的EMF結構化特性可以通過查詢匹配值查找屬性。關鍵詞equals是指一個內嵌的通訊，它允許對字符串和其他原始類型的相等測試。

            relate MyRelation(s:S source, t:T target)
            {
            equals(source.name, target.name),
            MyOtherRelation(source.value, target.value)
            }
            

RDL語言盡管很簡潔，卻使你能夠表達很多模型轉換中使用的關鍵概念（比如，通訊，表達式，以及條件）。由于關聯只定義元素間的通訊關系，它執行的上下文（換句話說，輸入的實際參數）就十分重要了。不同的執行可能會產生不同的結果。下一節中出現的轉換將有助于詳細解釋這些概念。

例子：一個UML到關聯模型的轉換

必要準備
這一節討論如何在一個具體用例中使用MTF：一個UML到關聯數據庫(RDB)模型的轉換。關于這個主題已經有很多討論和若干轉換算法。在本文中我們基于J. Rumbaugh et al.(參見資源)介紹的原則實現了一個部分映射。該映射的主要規則如下：

把類映射到表

• 每個UML類對應一個表。
• 類的每個簡單屬性對應表的一列。

映射關聯到表

• 每個多對多的關聯映射到唯一的表。
• 每個一對一的關聯在表中任一類中充當外鍵。
• 每個一對多的關聯在表中多個類中充當外鍵。
• 集合與關聯遵循相同的規則。

為了簡單起見，這個例子做了幾個簡化假設。它不：

• 支持非通用的關聯（每個關聯的結束屬于一個類）
• 為其它UML概念，比如包，概括鏈接，等等提供映射

你將使用Eclipse.org UML2項目(參見資源)的UML 2.0通用模型的一個EMF實現。IBM® Rational® Software Modeler的UML建模工具和IBM® Rational® Software Architect的產品都是基于這個EMF通用模型的。

由于沒有關聯計劃的標準通用模型，而且還是為了簡單起見，我們決定基于EMF來定義我們自己的通用模型，我們稱它為SimpleRDB見圖2。這張圖定義了一個包含一組表的計劃，它們可以用簡單鍵值限制聯系起來(細節如下)。

另一個解決方案是平衡RDBSchema通用模型，該模型被用于實現IBM? Rational? Application Developer (IRAD) SQL工具的一部分。在這種情況下，從UML模型中產生的計劃可以被IRAD工具消耗——比如說，為了產生SQL代碼。這是基于MTF的一個很好的工具集成的例子。

圖2 SimpleRDB通用模型

MTF運行在Eclipse 3.0或更高版本上，配合相應的EMF級別。它也可以安裝于IRAD，Rational Software Modeler，以及其他IBM軟件開發平臺工具上。它作為一組插件被封裝，你只需把它置于你的插件目錄下（關于安裝的更多細節請參見MTF程序員指南——見資源）。為了運行本轉換例子，你還需要安裝以下軟件：

• UML2 1.0: 可在www.eclipse.org獲得，點擊下載鏈接并參看Eclipse Tools Project一節
• SimpleRDB 1.0: 包含在本文中

這個例子解釋了RDL語言的基礎，這將幫助你開始學習MTF。這里解釋的很多關聯用UML類圖進行了說明。由于沒有標準圖形注釋來描述MTF用到的概念（關聯，通訊，條件），我們將使用一個變化的標準UML類圖，我們向其中加入了我們自己的格式和限制注解。

在你的工作空間中建立一個項目，然后創建一個名為simplerdb.rdl的新文件。使用MTF映射規則編輯器打開該文件（.rdl是編輯器默認的文件擴展名）�，F在，你已經準備好編寫你的第一個關聯了，如表2所示。

步驟1：定義導入陳述
RDL文件以一系列導入陳述開始，它們被用來聲明轉換中涉及的EMF包。一個導入把一個URI包綁定到一個邏輯名，作為關聯中指明的類的前綴，如表2所示。

            import uml "http://www.eclipse.org/uml2/1.0.0/UML"
            import rdb "http:///com/ibm/mtf/simplerdb.ecore"
            import ecore "http:///com/ibm/mtf/model/emf.ecore"
            import ws "http:///com/ibm/mtf/model/workspace.ecore"
            import util "http:///com/ibm/mtf/util.ecore"
            

這些邏輯名提供了與XML名字空間相似的一種唯一的識別機制。如果你不知道你確切需要導入哪些包的URI，映射規則編輯器提供了一個內容輔助特性，它列出了工作環境中注冊的包。

在你的例子中，為了把UML模型聯系到關聯計劃，你需要導入uml和rdb包。你還需要導入ecore, ws和util實用程序包，它們被用來加載模型（將在下一步中作解釋）并導入特殊結構。

步驟2：把UML2資源映射到SimpleRDB資源
轉換從頂級關聯開始，如表3所示。它為加載模型對象和在工作環境下運行轉換提供了一個方便的機制（參見運行！一節）。如果你已經編寫了Eclipse插件，你可能對類名IFile比較熟悉。這里，你要處理的不是 org.eclipse.core.resources.IFile類本身，而是它周圍的EMF包裝。

            relate Uml2SimpleRdb(
            ws:IFile source,
            ws:IFile target)
            {
            UmlModel2Schema
            (over source.resource.contents,
            over target.resource.contents)
            }
            

MTF的設計是對EMF模型進行轉換，但是它也提供了改寫非EMF類的方法。一種稱為擴展的機制使你能夠采用任何Java類并在轉換引擎中運用用戶定義語義進行操作。MTF包含一些對文件和EMF資源提供默認支持的擴展包，ecore和ws就是其中兩個。并不一定非要使用這些包，但是它們確實在你定義變化時很有幫助。

你可以分開編寫加載相關的EMF資源和對模型對象調用映射引擎的代碼，但是在這個例子中所有任務的完成都是透明的。如果你對RDL的語法還不熟悉的話不要擔心，在例子的下一步中我們將會加以詳細解釋。

RDL中沒有定義用例或命名的規則。本例子試圖遵循Java的命名規則按照自頂向下的方法組織關聯（映射，表達式，以及條件）。

步驟3：把模型映射到計劃
列表4表示的關聯把任何給定UML模型映射到同名的一個計劃。形式參數uml:Model和rdb:Schema被用于匹配標準；因此，只有當用于關聯的值是Model或者Schema的實例時才會創建映射。

            relate UmlModel2Schema(
            uml:Model model,
            rdb:Schema schema)
            {
            equals (model.name, schema.name)
            UmlClass2Table
            (over model.ownedMember, match over schema.tables),
            ManyToManyUmlAssociation2Table
            (over model.ownedMember, match over schema.tables)
            }
            

如果你仔細研究一下前面的關聯，你就會發現它為了傳播從EMF資源到它們的內容的轉換是如何調用這一關聯的。一個EMF資源定義了一個E對象的集合，這一集合在模型中是可獲得的，并可以通過contents屬性訪問。關聯UmlModel2Schema將同左面的資源（UML模型）的內容一起被例化。實際上，你永遠有把關聯應用到任何對象（或者一組對象）的能力。如果對象不符合類型標準，那么什么都不會發生。如果符合，對每一個符合的值的組合都會有一個映射被例化，然后轉換將被傳播到子元素。

關聯簽名主要關注UML模型和關聯計劃之間的映射，但是并不表達它們的內容應如何映射。用于聯系模型元素的通訊是在關聯體里的，當關聯被應用時，轉換引擎將搜索通訊——類之間的和UML模型內定義的關聯，以及關聯計劃中定義的表——并為它們產生相關映射。

我們確信計劃的名字與使用equals內嵌通訊的模型的名字是相同的；而且Model和Schema類的名字屬性是相同的。注意用于查詢EMF對象的屬性的基于點的語法。RDL中使用的屬性名是基于EMF類的結構特性的。

在UML 2.0的通用模型中，類和關聯是PackageableElement的子類，而且通過一個稱為ownedMember的瀏覽屬性從Model類中是可以訪問的。在你的轉換中你使用這個屬性來聯系類/關聯和關聯計劃的表。由于ownedMember和tables屬性指的是一個集合，我們使用關鍵詞over來指出通訊將被用于集合所有的元素，而不是把集合本身當作一個對象。

在這個特定用例中，關聯的執行將會在所有表和所有符合后面規則中解釋的標準的用戶之間產生一個銜接產品。注意到關鍵詞match指出了領域中的一些元素，比如列表4中的schema.tables，被允許保持不匹配。為了防止沒有帶有前綴的匹配關鍵詞的情況（比如列表4中的model.ownedMember）出現，集合中所有類型符合的元素都必須通過關聯UmlClass2Table進行映射。

圖3 關聯UmlModel2Schema及其通訊

示例的這一步驟中表達的關聯只表明了典型的UML到RDB的映射的一部分，因為它只處理二元關聯。一個完整的映射將考慮n元關聯，以及類之間的概括關聯。

步驟Step 4：把類映射到表
你的下一步是在關聯計劃中定義UML類如何聯系到表，如列表5所示。映射與前面的關聯很相似；你將找到一個與每一個類同名的相關表。這里關鍵詞when保證了類和表的名字的同一性。關聯的執行將把轉換傳播到每個類的屬性，并把它們映射到相關列。這一關聯還處理一對一和一對多關聯。

            relate UmlClass2Table(
            uml:Class class,
            rdb:Table table)
            when equals(class.name, table.name)
            {
            TablePrimaryKeyColumn [1] (match over table.columns,
            over table.constraints),
            UmlAttribute2Column(over class.ownedAttribute,
            match over table.columns),
            ClassOwnedEnd2ForeignKeyColumn(over class.ownedAttribute,
            match over table.columns, over table.constraints)
            }
            

由于這個例子只處理可瀏覽的關聯,它假設關聯的結束永遠屬于類。因此，所有實現關聯結束的屬性在關聯計劃中將同一個外鍵相關。多對多關聯需要一個特殊映射，它在另一個關聯中被單獨處理。

關聯TablePrimaryKeyColumn應用于通訊，它向每一個同UML類相關的表添加一個主鍵.主鍵定義了一列或一組列，它們是表的唯一標識。它是SimpleRDB的通用模型的第一個類實體,但是在UML 2.0中沒有它的對等體.這就是關聯的簽名沒有與UML元素相關的形式參數的原因。它還解釋了我們在通訊中使用特定多重性的原因。

此前RDL中的多重性概念還沒有被介紹到；它使得通過指定上下限限制映射的數量——從一個關聯中進行的例化——成為可能。在這個特定例子中，與一個關聯且只與一個關聯對應的多重性被定義為與關聯TablePrimaryKeyColumn對應（你可以看到列表5中的通訊介紹的括號符號）。如果沒有指明，默認的多重性是從0到n，這表示映射盡可能多，在這里這是無關的，因為主鍵意味著唯一。

關聯UmlAttribute2Column把一個類的簡單類型屬性映射到表的一列。在這里使用匹配關鍵詞是因為不是所有列都與UML屬性相關；正如前文介紹過的，添加主鍵和外鍵是為了同時映射UML關聯。在關聯ClassOwnedEnd2ForeignKeyColumn的例子中，我們把關聯的結束——表示為類型的屬性——映射到包含一個列和一個外鍵限制的外鍵。

圖4 UmlClass2Table關聯及其通訊

這個例子中貫穿的類圖是RDL語法之外的概念的又一種可能表示。在這些類圖中，關聯被定義為帶有特殊標記的類，它們的屬性代表了輸入中指明的形式參數。關聯涉及多個模型類，它帶有表示用于參數的值的屬性。定義在關聯的屬性上的限制表明了限制候選值的作用域的條件。正如你在圖4中看到的，property和column的角色是關聯UmlAttribute2Column的形式參數，而ownedAttributes和columns表示的是通訊涉及的實際值。

通訊是由兩個關聯之間的關聯表明的，并帶有詳細的類型標記。到目前為止這個例子集中于由包含關聯（屬性包含于一個類，表包含于一個計劃，等等）聯系起來的類之間的通訊，并已經在類圖中使用了累計符號來表示它們。盡管如此，在下一步驟中你將看到，有些通訊還可以用于由簡單關聯聯系起來的類。在這種情況下，表示將是不同的，不帶有累計符號。

步驟5：向表添加主鍵
列表6定義了一個列與一個主鍵之間的關聯，后面的圖5也表示了這點。該關聯保證：

• 列的名稱與主鍵一致——在這個例子中名字是 ID
• 實際上關鍵是表的主鍵的指向
• 鍵指向列
• 列的類型是INTEGER

            relate TablePrimaryKeyColumn(?
            rdb:Column column,
            rdb:PrimaryKey key)
            when equals (column.name, "ID")
            {
            equals (key.table.primary, key),
            equals (column, over key.column),
            equals (column.type, "INTEGER")
            }
            

指明列類型的內嵌通訊表現了RDL的聲明性。在你的轉換中，關聯計劃是目標模型，調和將為它產生值。對目標模型應用通訊是一種聲明性規約，目標值就屬此類。在我們的具體例子中，這意味著作為主鍵的每一列的類型都是INTEGER（整數）。這是本例子第一次把關聯作為一個定義表達式（換句話說，一個賦值語句）的聲明性陳述來使用，而不是用它作模型到模型的映射。

圖5 TablePrimaryKeyColumn及其通訊

步驟6：把一個屬性映射到一個列
列表7中的關聯把一個UML屬性映射到一個同名的列。在UML 2.0通用模型中，屬性和可瀏覽關聯結尾都被表達為類的屬性。

            relate UmlAttribute2Column(
            uml:Property property
            when util:InstanceOf "uml:DataType" (property.type),
            rdb:Column column)
            when equals(property.name, column.name)
            {
            equals(column.type, "VARCHAR")
            }
            

關鍵詞when有多種應用并可以用于不同上下文。盡管所有這些使用都表達了一種條件，它們各自的含義是有區別的。定義于一個參數聲明之內（比如，上面關聯中的property 參數），when從句定義了過濾用于通訊的候選值的方式。它只與參數域的屬性有關，當它用在關聯的簽名結尾時，基于相關參數之間的特定關聯，同一個從句定義了不同候選值組之間的共同標準（比如，屬性和列的名稱）。這稱為一個識別條件。

在上面的關聯中，你只想映射簡單類型屬性，因此你要確定應用于屬性參數的過濾條件InstanceOf限制，它保證了屬性的類型是Datatype。這一用戶限制擴展了RDL語言，是MTF附帶的util擴展的一部分。

在關聯體中，你用一個通訊來指明每個與匹配的屬性相關的列的類型。為了簡單起見，考慮把VARCHAR作為除主鍵和外鍵外的所有列的默認類型。

圖6 UmlAttribute2Column關聯

步驟7：把關聯結尾映射到外鍵
列表8中的關聯定義了一個關聯結尾和一個外鍵之間的映射。根據前文介紹的原則，Rumbaugh et al. 認為按照它們的多重性，不同的關聯映射用例：

• 一個一對一關聯被映射到表中的一個外鍵（無所謂哪個）
• 一個一對多關聯被映射到"many"表的一個外鍵
• 一個多對多關聯被映射到一個單獨的表

            relate ClassOwnedEnd2ForeignKeyColumn(
            uml:Property property when CheckOne(property)
            & util:InstanceOf "uml:Class" (property.type),
            rdb:Column column, rdb:ForeignKey fkey)
            when equals (property.name, column.name)
            & equals (column, over fkey.column)
            {
            equals(column.type, "INTEGER"),
            ref UmlClass2Table(property.type, fkey.refTable)
            }
            

這里你將集中于一對一和一對多的多重性，你將把它們作為單一的用例處理。多對多關聯（由另一個關聯處理）不在本文討論范圍之內。具體到本例，考慮所有關聯結尾的外鍵的建立都帶有多重性“1”。這樣做的結果，將會出現下面兩種情況：

• 在一對多關聯的情況下，你的轉換在所有"many"表中建立了一個外鍵
• 在一對一關聯的情況下，你的轉換在所有表中都建立了一個外鍵

你將注意到UML通用模型的結構暗示了關聯映射的不同策略，無論它們的結尾是可瀏覽的（屬于一個相關類）還是不可瀏覽的（屬于關聯本身）。為了訪問關聯結尾，你需要訪問模型擁有的類，或者訪問關聯，或者兩者都訪問（如果可瀏覽的和不可瀏覽的結尾都要處理）。

為了簡單起見，這個例子只支持兩路可瀏覽關聯。這使你能夠通過訪問類很容易地訪問關聯結尾，然后把相關屬性映射到外鍵。

列表8表現的關聯的一個特殊方面是使用了另一個關聯（比如，CheckOne）作為過濾值的條件。嵌套于域聲明中，通訊可用于建立基于關聯多重性的強大的過濾器。這里，它允許你定義更多表達能力很強的符號，而不止是嚴格的相等（比如，檢查一個組中某個元素的存在性）。

這里使用關聯CheckOne是為了保證在關聯執行時多對多關聯不會被考慮進去。其他預聲明的定義是為了保證作為參數提供的屬性是一個關聯結尾（還是以InstanceOf為限制）。它們還檢查了屬性和列的名稱的一致性是否被滿足了。

當我們能夠清楚無二義地聯系任何關聯結尾和外鍵時，我們可以把通訊應用于指明外鍵指向的是哪個主鍵。在SimpleRDB中，主鍵和外鍵被定義為一個和指向該列的鍵值限制相關聯的列，以及一個同時擁有列和限制的表。此外，外鍵擁有一個refTable屬性，它指向另一個表定義的主鍵。在該通訊中，你需要表達主鍵和外鍵之間的聯系，并指明該屬性的值。

應用于屬性property.type和fkey.refTable，UMLClassToTable關聯可被用來指明主鍵和外鍵之間的聯系。在前面關聯曾被用在通訊中來把模型擁有的每個類映射到一個關聯計劃。在兩種情況下，目標都是把UML類（uml:Class的實例）映射到關聯表（rdb:Table的實例）。

你在這里所作的有一點不同，主要是你把簡單引用映射到已經相關的元素了（換句話說，映射到UML類）。這不同于映射累計關聯，那樣實際是建立新的元素。從映射的角度來看，這意味著你需要引用已有的映射（UmlClassToTable的實例并聯系一個已有類和表）而不是例化新的映射。

這就是本例在通訊中使用關鍵詞ref來表達對引用元素映射應該已經存在而無須再建立一個映射的含義。

圖7 ClassOwnedEndToForeignKeyColumn關聯及其通訊

列表9定義的關聯是MTF中關聯多種使用的又一個例子。這里你的主要興趣是從關聯建立相關的映射，然后對它們計數作為條件的一部分。從這個關聯中例化的映射在調和時將不被考慮。

            relate CheckOne(
            uml:Property property when equals(property.upper, "1")
            

此關聯的目的是過濾掉多對多關聯，它由另一個關聯處理。你在尋找多重性為1的關聯結尾，記為1in UML2 (請見下面的圖8)。

圖8 CheckOne關聯

本文中表現的關聯實現了基于簡單假設的從UML類到表的轉換——以及UML一對一和一對多關聯到鍵值限制的轉換。它使你能夠理解RDL語言的主要概念，即使此刻一個UML到關聯的映射還未完全說明。多對多關聯的情況這里沒有討論，因為它的實現與我們前面介紹的大同小異。整體原則是為每個相關關聯建立第三個表，然后定義相關鍵值限制。這里沒有詳述的額外關聯將作為例子的源代碼的一部分出現。

更深入的概念，如抽象關聯，或者抽象繼承，也是RDL語言的一部分，但是本文將不作介紹。關于這些主題的更多資料可在MTF程序員指南中獲得——請參見資源。

運行！
一旦關聯定義完畢，你就可以在實際模型上執行轉換了。本文使用了Primer Purchase Order模型，一個EMF書中(參見資源)描述的經典例子，如圖9所示。UML2指南(參見資源)使用了一個變化版本，叫做Extended Purchase Order。我們使用UML2定義Primer Purchase Order模型，指明PurchaseOrder，USAddress和Item類之間的雙向關聯，它在本文中可以獲得。你將需要復制你工作區中的文件，最好是你為這個例子創建的項目。使用這個模型作為輸入，你將能夠運行一個MTF任務并產生相關的關聯模型。

圖9 改寫Adapted Primer Purchase Order模型

MTF提供了一個高級發布界面，它允許你從Eclipse工作環境中觸發轉換。你只需要創建一個新的運行配置并輸入需要的參數：

• 頂級規則
• 源文件和目標文件
• 轉換的目錄

MTF任務的配置畫面如圖10所示。你需要輸入simplerdb.rdl文件的路徑，并把Uml2SimpleRdb定義為輸入文件。然后你需要指明源和目的變量的值；源變量是Primer Purchase Order文件的路徑（將是不可修改的），而目標變量則指向要創建的關聯計劃的路徑（必須被修改）。這個組合，包括可修改的參數，使你能夠定義轉換的方向。如果這一方面配置不當，調和將不會產生相關的結果。

圖10 作為一個任務運行的Uml2SimpleRdb轉換

規則應被順利執行，一個對應于關聯計劃的新文件應在你的工作環境中出現。

MTF在Eclipse工作環境中的作用是提供映射視圖，通過它你可以檢查由轉換引擎產生的映射。這個特性確實幫助你跟蹤和理解轉換的執行。當任務完成后，你可以點擊出現在屬性列底部的按鈕。你將會看到和圖11相似的結果。

圖11 檢查MTF產生的映射

結論
MTF為模型轉換提供了一種聲明的方式。在這篇文章中，我們簡要描述了MTF語言并示范了它在從一個UML模型到關聯計劃的映射轉換中的使用。MTF為自動模型轉換和同步活動提供了各種可能性：

• UML到UML
• 模式擴展
• 基于不同Profile(EJB, CORBA, 等等)的獨立于平臺模型(PIM)到特定平臺模型(PSM)轉換