摘 要： 給出一種源模型和目標模型間的鏈接技術及其實現(xiàn)方法,，該方法能很好地實現(xiàn)源模型和目標模型間的雙向可追蹤,。既可以對源模型的更新執(zhí)行正向轉換,，還可以實現(xiàn)目標模型向源模型的逆向轉換。
關鍵詞： 模型驅動,；模型轉換,；同步；可追蹤性
模型驅動架構(MDA)是繼CORBA,、UML之后由OMG推出的重要的軟件開發(fā)方法學[1-3],。MDA對軟件開發(fā)、異構平臺的集成,、互操作以及對不斷涌現(xiàn)出的軟件新技術和新平臺的自洽性等方面都有著巨大的影響[1-2],。
MDA的核心問題是模型轉換。其基本方法是：先抽象出與實現(xiàn)技術無關,，完整描述業(yè)務的平臺無關模型(PIM),，并針對不同的實現(xiàn)制定多個映射規(guī)則，再將平臺無關模型轉換成與具體實現(xiàn)技術相關的應用模型(PSM),。由于建模過程和用戶業(yè)務邏輯固有的變動性,，在模型轉換過程中必須保持源模型和目標模型的同步，這對MDA的模型轉換的同步性研究具有重要意義,。
本文提出一種創(chuàng)建中間轉換對象的方法,，將模型轉換信息保存在中間對象中，使模型轉換具有正,、反向可追溯性,，以較好實現(xiàn)源模型和目標模型轉換的同步。并從通用性和模型轉換的同步性的角度對MOF元模型和OCL進行了改進,。
1 模型轉換同步性的中間轉換對象技術
模型轉換過程中,，由于建模過程和用戶業(yè)務邏輯固有的變動性，一項重要的實際工作是必須實現(xiàn)源模型和目標模型之間的正向和反向的完全同步,。通常的做法是為源模型和目標模型中相應元素之間的所有關系建立元素鏈接,，并把鏈接信息添加到源模型或目標模型中。這樣做不但破壞了模型的純潔性,，而且當源模型和目標模型之間不是一對一時容易引起混亂,。
方法(1)是在源模型中創(chuàng)建一系列標記(tag)，這些標記記錄了轉換的信息,。圖1所示的轉換必須建立表1所示的兩個標記,。
這些標記是轉換信息，并不屬于源模型,。把它們加入到源模型中不但破壞了源模型的純潔性,，而且當一個PIM要轉換成幾個PSM時，大量的標記將給PIM帶來很多額外的負擔,。
方法(2)把標記信息保存在目標模型中,。NetBeans開發(fā)平臺就使用這種方法,。但該方法的缺點與方法(1)類似，而且在執(zhí)行第一次轉換之前,，因為目標模型還沒有生成,，所以只有在執(zhí)行過一次系統(tǒng)的默認轉換之后,，才能在生成的目標模型中保存標記信息,。
而較好的解決方法是：(1)讓每條被執(zhí)行的轉換規(guī)則創(chuàng)建一個轉換實例，每個轉換實例包含一個或多個轉換對象,；(2)在每個轉換對象中存儲一條轉換信息,，即源模型元素和目標模型元素的鏈接信息；(3)建立一個中間對象模型,，把轉換實例及轉換對象保存在這個模型中,。如圖1所示，設要把源模型Customer轉換到SQL模型C_CUSTOMER,，attribute_to_attribute是負責把源模型中的String類型屬性轉換到SQL模型的VARCHAR類型屬性的轉換規(guī)則,。則當對Customer的description屬性應用規(guī)則attribute_to_attribute時，生成轉換實例①,，實例①包含一個轉換對象信息③,，在信息③中保存轉換信息“Customer的String類型的description轉換成C_CUSTOMER的VARCHAR(255)類型的description”。同理,，對Customer的name屬性應用這條轉換規(guī)則時,，生成轉換實例②，②包含一個轉換對象信息④,，而轉換對象信息④中保存了轉換信息“Customer的String類型的name轉換成C_CUSTOMER的VARCHAR(255)類型的name”,。并把轉換實例及轉換對象保存在另外的既不屬于源，也不屬于目標的模型中,。這樣不僅能保留完整清晰的轉換信息又不破壞源模型和目標模型的純潔性,。
為了實現(xiàn)以上方法，需要對MOF進行擴展,，建立一個雙向圖結構的元模型,。如圖2所示，ModelElement是一個最通用的模型元素,；一個Link引用兩個ModelElement,，分別為源對象和目標對象；一個Step包含一個或多個Link,，則一個Step就可以保存一次模型轉換的追溯信息,。如果考慮到支持一個鏈式的轉換，那么整個的轉換過程相當于有多個Step,，因此,，為了支持鏈式轉換,，用一個包含了Step的有序集合的Trace來實現(xiàn)。
在MOF元模型層次中增加兩個新的元素TransformationTraceClass和Relation,，并定義兩個操作setRelation()和getRelation(),，用于讀寫Relation的值，如圖3所示,。
在源模型第一次發(fā)生模型轉換并需要保存相關信息時,，調用TransformationTraceClass，并把本次轉換的相關信息用setRelation()操作寫入到Relation的一個元組,，此后每進行一個模型元素的轉換,，就首先到Relation中查找有沒有相同模型轉換的元組。若有,，則把目標元素追加到該元組中,；若沒有，則在Relation中再創(chuàng)建一個新的元組,。即可實現(xiàn)對轉換的完全同步支持,，同時可將轉換關系的信息和模型本身分隔開，實現(xiàn)了關注點的分離,，保證了PIM和PSM的清晰性和單純性,。
2 支持模型轉換同步的OCL擴展
在MDA中，用UML結合OCL已被認為是開發(fā)符合MDA規(guī)范的PIM的最佳方案[1,，3],。研究指出：OCL對于模型轉換可以發(fā)揮重要的作用[3-4]。但是,，如何把OCL應用于模型轉換的實際工作卻做得較少,。由于模型轉換的關系信息的復雜性，所以難以用現(xiàn)有OCL來表示,。對于用中間轉換對象技術保留模型轉換的關系信息的OCL實現(xiàn),，對OCL進行如下的擴展：
將圖3看成是TransformationTraceClass的圖語法。TransformationTraceClass是以由Tuple組成的并以Relation作為其組成元素的,。作為一個類,，其創(chuàng)建操作必須由創(chuàng)建原語實現(xiàn)，具體格式為：
createElement(TransformationTraceClassName：TransformationTraceClass)
創(chuàng)建原語實際生成的是對TransformationTraceClass的引用,，每個模型轉換中的源模型對應生成一個TransformationTraceClass,，它在第一次進行模型元素轉換時被創(chuàng)建，且調用setRelation()操作保存轉換信息,，調用getRelation()操作查詢轉換信息,。下面是setRelation()和getRe1ation()的語法。
setRelation(newValue,，Relation.Tuple.sourceName)
setRelation操作類似普通類中對于屬性的set操作,，但該原語的操作對象是Relation中的元組,。其含義是：把轉換關系信息newValue寫入到以sourceName為source的元組中。
getRelation(Relation.Tuple.sourceName)
getRelation操作類似普通類中對于屬性的get操作,，但其操作對象和返回值均是Relation中的元組,。由于元組只是將一組值集合在一起的一種途徑，所以具體使用時元組必須被賦給一個變量,。
此外,，在模型轉換中，對任何模型元素的操作都定義其必須查詢相應的TransformationTraceClass來確定與被修改元素的相關轉換信息,，從而實現(xiàn)源模型和目標模型的同步,。
MDA堪稱是一種革命性的新方法,。MDA的核心問題是模型轉換,。本文給出一種能對模型轉換的向前和向后可追溯性的方法，較好地實現(xiàn)了源模型和目標模型轉換的同步,。由于OCL具有形式化且簡潔易懂等眾多顯著特征,，因而用它來描述MDA中的模型具有突出的優(yōu)點。但OCL作為模型轉換語言必須進行一定的擴展[3-4],。本文所做的保存模型同步信息的擴展僅是其中之一,。
參考文獻
[1] SENDALL S， KOZACZYNSKI W. Model transformation： The heart and soul of model-driven software development [J]. IEEE Software,， 2003(9)：42-45.
[2] 王學斌,，王懷民，等.一種模型轉換的編織框架[J].軟件學報,，2006,，17(6)：1423-1435.
[3] 陳婧，趙建華,，張康康.處理動態(tài)行為描述的MDA模型轉換技術[J].計算機應用與軟件,，2010，27(4)：162-166.
[4] CARIOU E,， MARVIE R,， SEINTURIER L， et al. OCL for the specification of model transformation contracts In： Octavian Patrascoiu[R]. OCL and model driven engineering UML 2004 workshop. Lisbon,， Portuga1,， 2004.