面向J2EE主流框架的MDA模型轉換研究

謝培基，余金山

（華僑大學 計算機科學與技術學院，福建 泉州 362021）

計算機業界一直在探索一種新方法，既能夠提高軟件的開發效率，又能使所開發出來的軟件能夠有更高的質量和更長的生命周期。面向對象思想、分布式計算開發、基于組件開發等新方法都為這一探索起到了應有的作用。而模型驅動架構（MDA）同樣也為軟件開發的進步發揮了重要作用。

MDA （Model Driven Architecture）[1]是 OMG 組織在2001年正式提出的一種模型組織管理框架，它定義了平臺無關模型（PIM）和平臺相關模型（PSM），同時把PIM到PSM之間的自動映射定義為模型轉換。MDA提供了一系列指導軟件開發的方法，這種開發方法將傳統的重編程過程提高到了重系統模型設計的層次，使得開發人員能更好地設計系統，有效地提高了軟件的開發效率，同時降低了編程開發費用、解決了系統需求不斷變化帶來的維護性困難問題。

1 MDA模型轉換方法

在基于MDA的軟件開發過程中[2]，主要的兩個步驟是PIM到PSM的模型轉換和PSM到代碼的轉換。因為PSM與其對應的系統實現平臺技術緊密相關，因此這一轉換相對較為直接，且有眾多MDA工具的支持。而將PIM轉換到PSM是一個較為復雜的過程[3]，也是當前研究MDA的一個重點。本文歸納出了幾種模型轉換方法。

（1）手動轉換方法：即系統開發人員使用已經定義好的模型操作的API，將源模型轉換到目標模型的方法。例如JMI，在J2EE中提供了一套完整的JMI的類庫，系統開發人員可以通過編程實現相應的模型轉換。這種轉換并沒有使模型轉換自動化，所以很難在實際應用中得到推廣。

（2）基于 XMI的模型轉換方法[4]：實際上也是一種文本轉換方法，該轉換方法將源模型用XMI文本的形式表示，也相當于用XMI來存儲源模型，然后將XMI里的元素一個個按步驟轉換到目標模型。這種轉換方法的優點是相對簡單，缺點是轉換速度慢、步驟較多且繁雜、不夠直觀、容易導致模型前后的不一致。

（3）基于模式的模型轉換方法[5]：該方法建立在其他模型轉換方法的基礎上，引入模式的概念，將一些可用的模型轉換方案包裝成模式，然后以模式的形式放到存儲庫里以實現模型轉換方案的添加刪除和復用。這種模型轉換方法通常會改變源模型的結構信息，使其更加符合設計理念，而沒有改變模型的抽象級別和增加它的語義。

（4）結構驅動轉換方法：該方法主要分為兩個不同的步驟[6]：①為目標模型建立多層次的體系結構；②設置目標模型中的索引和屬性。這種轉換方法設計了一個總的規則調度框架和轉換機制，用戶需要做的就是提供轉換規則，然后實現模型的轉換。著名的模型驅動開發工具OptimalJ中的模型轉換框架就是使用結構驅動的方法。

面向 J2EE主 流 框 架 Struts、Spring和 Hibernate等MDA模型轉換，當前還沒有標準化的模型轉換方法，以上的幾種模型轉換方法也未能提供有效的支持，其中方法（1）和方法（2）過于簡單、手動化；方法（3）建立在其他模型轉換方法上，未能提供完整的解決方案；方法（4）有現成的工具，但偏向于模型到代碼的轉換。

針對 Struts、Spring和 Hibernate的整合框架 （SSH整合框架）的技術特性，本文提出了基于元模型和UML Profile相結合的模型轉換方法。其思想是先抽象出平臺無關模型PIM和平臺相關模型PSM的元模型，然后制定元模型間的轉換規則，間接實現PIM到PSM的模型轉換。而在建立PIM和PSM的元模型時，UML并不能完整地描述出針對特定平臺或技術的模型信息，但UML自身具備的擴展機制UML Profile，為構建MDA的各種特殊模型提供了有力的支持，因此本文借助UML Profile來建立PIM和PSM的元模型。其轉換過程如圖1所示。

圖1 基于元模型的模型轉換

2 面向J2EE主流框架的模型轉換

根據上文提出的模型轉換方法，首先建立PIM和PSM的元模型，然后分析元模型間的映射關系，建立具體的轉換規則，間接實現PIM到PSM的模型轉換。

2.1 建立PIM元模型

建立PIM元模型應充分考慮PSM所屬平臺的特性，確定使用何種建模技術來建立PIM以及建立一個能與PSM元模型相呼應的PIM元模型，以便制定模型轉換規則。當前基于動態行為建模的模型很少應用到MDA中，且這方面的模型轉換技術還不夠成熟，因此，本文采用靜態結構的類圖對SSH框架建模，對于Struts框架的建模，本文忽略其視圖層，對控制器層和模型層采用類圖表示。

在使用靜態的類圖結構來描述PIM時，往往是用描述業務的領域對象模型來表示PIM，但是一個系統的領域對象模型不足以完整描述系統的總體架構，因此需要進一步對PIM模型進行精化，使其既能描述領域對象間的關系又能描述系統的總體架構。

SSH整合框架是一種多層架構模式，可分為表示層、控制器層、業務邏輯層、實體層、數據持久層、數據庫層，這種N層架構模式實際上是對經典的Web應用軟件體系結構的擴展，也可以說是一個適合于SSH整合框架的Web應用層次結構。同時這種分層結構又是一種廣泛應用的軟件體系結構，不涉及到特定的技術或與平臺相關。因此，本文構建出一個與平臺無關又能適合于SSH整合框架的Web應用層次結構，以此來彌補領域對象模型的不足，展現系統的總體架構，這也是對PIM的精化。

本文把這種Web應用層次結構的模型作為PIM元模型。利用UML Profile來建立Web應用層次結構模型如圖2所示。

圖2 Web應用層次結構

圖2中，Controller是控制器，負責將視圖層發過來的用戶請求委派給相應的Action；Action調用需要的Service類來實現業務邏輯功能；DAO則提供數據訪問功能；Entity 是實體類，與 Action、ServiceImpl、DAOImpl是依賴關系，這三個類可以聲明實體類的對象，或接收實體類對象參數，因此它們之間是使用依賴的關系。

在進行PIM到PSM的模型轉換時，考慮到PIM的平臺獨立性，假如不對PIM的元模型進行擴展，則有可能造成PIM與PSM元模型元素間的映射關系復雜化等情況，在模型轉換過程中也將使得轉換不夠明朗，最終影響模型轉換的效果。因此，本文采用了UML Profile對Web應用層次進行了相應的擴展。表1列出了層次結構中的構造型，表2列出了構造型的屬性值。

表1 構造型

表2 構造型的屬性值

2.2 建立PSM元模型

對抽象SSH整合框架的元模型，本文先抽象出各個框架的元模型，然后對這些元模型進行整合以得到SSH整合框架的準元模型。下面對Spring、Hibernate兩個框架的元模型抽取做具體的研究，而對Struts框架，前面已經忽略掉了對視圖層的處理，在此也不對Struts的核心MVC進行元模型抽取，而是簡單地使用Web應用層次結構來表達控制器與業務邏輯的關系。

2.2.1抽象Spring框架的元模型

Spring框架的兩大核心是：面向切面編程（AOP）和控制反轉（IoC）。其核心在Web應用開發中起著舉足輕重的作用。

（1）抽象 Spring IoC的元模型

在IoC中，Spring容器把所有需要管理的類聲明成bean，一個 bean包括 id、class和 properties等。抽象出的Spring IoC的元模型如圖3所示。

圖3 IoC元模型

（2）抽象Spring AOP的元模型

AOP的提出是軟件開發史的一次重大創新，它用面向切面編程的思想有效地解決了橫切關注點問題。AOP的原理如圖4所示。圖中AOP在類A、類B等的方法上加入一個切面，并把一個可以聲明成bean的切面類織入到切面中，當程序執行到切面的時候先執行Aspect對象再往下執行。切面類可以為記錄日志、錯誤處理、數據驗證等提供服務。

圖4 AOP原理

根據圖4的AOP原理，對照應用開發，抽象出AOP的元模型如圖5所示。

圖5 AOP元模型

2.2.2 抽象Hibernate框架的元模型

Hibernate框架在業務邏輯層中又分出了數據持久層，數據持久層除了實現對象關系的映射，還封裝了底層數據庫操作類，為程序開發帶來了很好的靈活性，也避免了數據庫表的直接暴露。在抽象Hibernate框架的元模型時，為每一個實體類Entity創建一個對應的數據訪問接口EntityDAO，這樣既使得持久層的結構清晰，又能與業務邏輯層的服務接口很好地銜接。對Hibernate框架抽象出的元模型如圖6所示。

圖6 Hibernate框架元模型

2.2.3 SSH整合框架的PSM元模型

在抽象出各個框架元模型的基礎上，對這三個框架的元模型進行整合得到如圖7所示的SSH整合框架的PSM元模型。

圖7 SSH整合框架的PSM元模型

該SSH整合框架元模型不但串聯了各個框架的元模型，同時也融合了Web應用的層次結構，為PIM到PSM的模型轉換提供了極大的便利。在對Spring框架元模型整合中，控制器類、業務邏輯類、數據訪問類、面向切面編程類都繼承bean類，亦即這些類都可以聲明成bean被IoC容器來管理。對Hibernate框架元模型的整合，主要是對業務邏輯層和數據持久層的整合。

SSH整合框架元模型同樣采用了UML的擴展機制UML Profile進行了相應的擴展。表3列出了該元模型的構造型。

表3 PSM元模型的構造型

2.3 PIM到PSM的模型轉換

根據本文提出的模型轉換方法，模型轉換過程從一個初始的領域對象模型開始，根據定義的精化規則對其求精形成準PIM模型，然后根據模型轉換規則，轉換成相應的PSM模型。

2.3.1 PIM的精化

要實現PIM到PSM的轉換，首先需要建立適應Web應用層次結構的PIM模型，而在實際應用中，一開始往往建立的是領域對象模型，不能很好地滿足Web應用層次結構。因此可以參考系統的其他UML圖（如用例圖對這一初始PIM進行精化形成準PIM），使其能遵循PIM元模型的規范。本文對PIM的精化定義了如下的精化規則：

（1）為每個領域對象生成一個同名的實體類，領域對象的屬性對應實體類的屬性，關鍵字對應實體類的ID，領域對象間的關聯關系對應實體類的關聯。

（2）為每個實體類生成一個對應的數據訪問接口EntityDAO和實現類EntityDAOImpl，并添加需要的方法，EntityDAOImpl能調用對應的實體類。

（3）在業務邏輯層中，為每個實體類根據需要建立相應的EntityService接口和其實現類EntityServiceImpl或其他的服務類，添加需要的屬性和方法，EntityServiceImpl類可以訪問實體類Entity和數據訪問類EntityDAO。

（4）結合其他 UML圖生成控制器類 Controller和Action，Action可以調用需要的服務類。

2.3.2 PIM到PSM的模型轉換規則

PIM到PSM的模型轉換是MDA應用開發的核心，模型轉換規則則是PIM到PSM的轉換的核心，可以說模型轉換規則是MDA應用開發核心的核心，足以見得模型轉換規則的重要性。下面定義了具體的模型轉換的轉換規則：

（1）＜＜Entity>>轉換到 PSM

生成與＜＜Entity>>相同的實體類，將領域對象間的關聯＜＜EntityRelation>>映射成實體類的關聯映射＜＜MappingRelation>>，將領域對象的主鍵＜＜primaryKey>>映射到＜＜Entity_ID>>。主要轉換規則如下：

（2）＜＜DAOImpl>>、＜＜ServiceImpl>>、＜＜Action>>、＜＜Aspect>>轉換到 PSM

將 PIM 中的 每 個＜＜DAOImpl>>、＜＜ServiceImpl>>、＜＜Action>>、＜＜Aspect>>轉換成對應的＜＜bean>>， 主要轉換規則如下：

（3）＜＜Action_Service>>、＜＜ServiceImpl_DAO>>轉 換到PSM

將每個＜＜Action_Service>>、＜＜ServiceImpl_DAO>>關聯映射成PSM中的＜＜Property_DI>>，根據關聯的命名來定義規則，如＜＜ServiceImpl_DAO>>關聯，是將 DAO bean注入到ServiceImpl bean中，則主要轉換規則如下：

（4）對＜＜Action>>、＜＜ServiceImpl>>、＜＜DAOImpl>>實現到 PSM（AOP）中的轉換

根據＜＜Action>>、＜＜ServiceImpl>>、＜＜DAOImpl>>構造屬性＜＜aopType>>的值，選擇對應的PSM中的Aspect類。 屬 性＜＜advice>>、＜＜pointCut>>對 應 PSM 中 的＜＜Advice>>、＜＜PointCut>>， 本文選取＜＜ServiceImpl>>實現到PSM（AOP）中的轉換，其他的兩個轉換規則類似。主要轉換規則如下：

本文分析了幾種主流的模型轉換方法，但這些方法并未對J2EE主流框架提供有效的支持，而本文提出的基于元模型和UML Profile相結合的模型轉換方法，通過建立PIM元模型和PSM元模型，以及制定元模型間的轉換規則，間接實現了PIM到PSM的模型轉換。

[1]MILLER J，MUKER JI.MDA guideversion1.0[M].Object Management Group， 2003：3-7.

[2]FRANKEL D S.應用 MDA[M].鮑志云譯.北京：人民郵電出版社，2003：138-142.

[3]OLDEVIK J， SOLBERG A.Framework for model transformation and code generation. In： Enterprise Distributed Object Computing Conference[C].EDOC′02.Proceedings.Sixth International， 2002：181-189.

[4]張德芬，李師賢，古思山.MDA中的模型轉換技術綜述[J].計算機科學，2006，33（10）：228-230.

[5]張天，張巖.基于MDA的設計模式建模與模型轉換[J].軟件學報，2008，19（9）：2203-2217.

[6]王永濤，劉勇.基于 MDA的模型轉換研究[J].計算機工程，2011，37（16）：84-87.