往返工程在ＭＤＡ中的應用研究

摘 要：模型驅動體系(MDA)是OMG提出的一種IT系統描述和構造方法，在其發展與應用過程中，往返工程對于保證系統的實現與完善非常重要。論述了MDA中的三種往返工程方法，并給出了實例具體分析并比較，最后總結其發展趨勢。

關鍵詞：模型驅動體系;軟件工程;往返工程;模型驅動開發

中圖分類號：TP311.52文獻標志碼：A

文章編號：1001-3695(2007)06-0253-04

1 引言

隨著企業信息化的發展，企業用戶對IT技術和產品的應用與企業的管理運營之間無縫鏈接的需求日益迫切。電子商務、虛擬企業、動態聯盟、敏捷供需鏈等新的管理模式，要求企業各部門之間的應用以及企業與其合作伙伴之間的應用必須進行整合，以實現信息共享，但是這些應用卻是建立在不同的中間件技術基礎上的。中間件技術雖然大大簡化了異構系統的集成，但是眾多產品不斷發展，標準很難形成統一，使得新舊系統之間的集成或演化需要使用不同的實現技術。如何保護現有投資并推動整個系統的技術升級已成為不可避免且難以解決的問題。同時，軟件開發需要解決的業務問題正變得日益復雜，開發過程越來越多地圍繞著對要解決的業務問題進行建模，而非編寫代碼的細節。為此，2001年底OMG提出模型驅動體系(Model Driven Architecture， MDA)，其目的在于分離系統業務功能的分析設計與實現技術之間的緊耦合關系，建立獨立于實現的設計和架構，使技術變化對系統的影響達到最小。

模型驅動體系下的軟件開發改變了傳統的軟件開發過程，但由于現階段的MDA開發工具還不完善，在開發過程中不可避免地需要使用往返工程。本文敘述了MDA下軟件開發生命周期以及其中往返工程的分類，具體研究了EMF和KCOM商業工程兩個MDA開發工具中往返工程的應用，并對其做出比較，總結出往返工程在MDA中的應用發展趨勢。

2 MDA基本概念和主要標準

2.1 MDA中的模型

MDA的關注焦點是模型，其核心在于嚴格區別系統的功能規約與實現細節，抽象出與實現技術無關、完整描述業務功能的核心模型平臺無關模型(Platform Independent Model， PIM)，針對不同實現技術制定多個映射規則，并通過這些映射規則及輔助工具將PIM轉換成與具體實現技術相關的應用模型（Platform Specialize Model， PSM），最后轉換成具體代碼。

模型驅動開發過程中，包含如下不同類別的模型：①業務模型（即領域模型）描述了業務領域，包括業務中將要實現自動化的方面和不準備自動化的方面；需求模型描述了邏輯系統而不是業務，但它是用獨立于計算的方式來描述的；平臺獨立模型PIM具有高抽象層次，它獨立于信息格式化技術、3GL/4GL、分布式組件中間件和消息中間件，描述了支撐實際業務的軟件系統的功能和結構；平臺相關模型PSM，是一個與特定的信息格式化技術、編程語言、分布式組件中間件和消息中間件相關的計算模型；物理模型描述了在開發和運行時用到的物理實體和資源，包含模型文件、源代碼文件、可執行文件、檔案文件以及處理器等。

在MDA開發過程中，由于缺少領域元模型，需求模型一般沒有正式形成，而是由業務專家口述或文字描述?；贛DA的軟件設計真正是從建立PIM開始，通過充分使用已有模型并且不考慮實現技術進行形式化的建模，而PSM可以視為一個基于特定實現技術的設計模型。PIM可以被轉換成一個或多個PSM，為每個特定的技術平臺生成一個單獨的PSM。軟件開發者只需要建立表達業務邏輯的PIM，剩下的工作都將由MDA引擎自動完成。描述業務邏輯的PIM將具有長久的價值，而針對特定平臺的PSM可能會隨著平臺技術的進步而快速遷移。在MDA開發過程中，系統開發工作的最終產品是PIM，從PIM到PSM及至代碼實現都是由第三方的自動化工具來完成的。

2.2 MDA主要技術標準

為了實現MDA，OMG制定了一系列的標準，主要包括UML（Unified Modeling Language，統一建模語言）、MOF（Meta Object Facility，元對象設施）、XMI（XML－based Metadata Interchange，基于XML的元數據交換）和CWM（Common Warehouse Metamodel，公共倉庫元模型）。

UML作為一種通用的可視化建模語言，用于對體系結構、對象、對象間的交互、應用程序生命周期的數據建模特性以及基于組件的開發特性進行建模。

MOF用于描述關系數據模型、UML類模型或其他種類的建模所用到的結構，是CWM和UML元模型的公共模型。MOF提供了模型元數據互交換和互操作的基礎，是模型在XMI分析中的機制。

XML/XMI是表示結構化信息的一種標準文本格式，具有可擴展性、靈活性和自描述性。XML已經成為數據表示的一個開放標準，獨立于機器平臺、供應商以及編程語言。XMI則是一種在不同工具、知識庫和中間件之間使用的標準的互交換機制。MDA中的PIM是通過XMI靈活地轉換成各種PSM的。

CWM是OMG的數據倉庫標準。它覆蓋了數據倉庫應用程序的全生命周期，包括設計、構建和管理，并且支持生命周期的管理。

在OMG的藍圖中，UML、MOF、XML/XMI、CWM等一系列標準分別解決了MDA的模型建立、模型擴展、模型交換、模型變換的問題。OMG通過這些標準化的定義，擴大了MDA的應用范圍。同時通過這樣一個可擴展的建模語言環境，IT廠商可以自由實現自己的建模語言以及語言到可執行代碼的映射。

3 模型驅動開發與往返工程

3.1 模型驅動軟件開發生命周期

模型驅動開發改變了軟件的開發過程。對于傳統的需求獲取、結構分析、底層設計、編碼、測試和部署幾個階段，MDA帶來了一系列改變。分析階段不再只產生空泛的文檔，而是在不考慮系統實現平臺的前提下，根據需求創建精確的應用模型PIM，分析階段的產品是PIM。設計階段將選擇某一實現平臺，然后依靠變換工具得到相應平臺上的PSM，設計階段的產品是PSM。編碼階段由模型變換工具自動把精確的PSM模型轉換成代碼，基本上不需要程序員進行手工編碼。圖1所示為MDA下的軟件開發過程。

MDA開發過程看起來類似傳統軟件開發過程，但是有一個關鍵的不同點：傳統上，從模型到模型的變換，或從模型到代碼的變換，主要是由手工完成的；而MDA變換卻總是由工具執行的，避免了手工編寫代碼的出錯情況，使得軟件開發效率有了量級的提升，并且它還將軟件開發的重心轉移到了分析設計，確保了軟件開發的低成本、高質量和高回報。

圖1 MDA軟件開發生命周期

3.2 MDA中的往返工程

但是從MDA的應用現狀來看，層與層之間的轉換并不是期待的那樣順暢。從PIM到PSM、從PSM到代碼，這個實現的過程要遠比從3GL生成機器代碼困難。目前MDA工具中的模型組件也經常難以滿足系統的實現需求。因此，往返工程的方法對于目前MDA的應用相當重要。MDA中的往返工程是指分析、生成代碼和修改代碼，然后將其逆向工程到“分析”這一過程，從而同步PIM模型和生成的代碼。是否讓軟件開發者來增強生成器從較抽象的模型生成的相對底層的工件，MDA有以下三種觀點：

（1）“只允許正向工程”方法。該方法不允許改動從PIM生成的代碼，保證在迭代開發過程中PIM改變后，同步連鎖效應只反應在模型到代碼方向上，如圖2所示。在這種方法下，設計是一個單向過程，即先設計后，再根據設計生成代碼；先修改設計，再生成修改過的設計的代碼，如圖3所示。一些MDA工具允許把3GL代碼放進模型的操作規約里，生成器會直接把這些代碼抄進從模型生成的操作，這也屬于“只允許正向工程”的方法。

圖2 “只允許正向工程”方法——同步連鎖效應限制在一個方向

圖3 “只允許正向工程”方法的部署工作流

在MDA應用比較成功的一些領域（如實時和嵌入式系統）通常只采用正向工程的方法。但是對于大多數系統，尤其是企業信息系統，不可能通過純粹的說明性建模語言來生成完整的實現。

（2）局部往返工程（Partial Round－trip Engineering）。它允許軟件開發者增加或修改從高層模型生成的內容，但是不能覆蓋或刪除，也不能增加能在高層抽象中定義的東西，如圖4所示?！熬植客倒こ獭钡耐竭B鎖效應依然被限制在同一方向上（圖4）。但是，開發工作流變得更復雜，并要求開發工具必須能夠識別程序員所做的增強工作，以免在下次生成代碼時被覆蓋。

（3）“完整往返工程”（Full Round－trip Engineering）。它與“只允許正向工程”相反，在較低的抽象層次的定義和刪除工作會反映到較高層次的模型中，并迭代進行?！巴暾倒こ獭钡耐竭B鎖效應是沿著抽象層次向上和向下產生連鎖反應，如圖5所示?！巴暾倒こ獭钡拈_發過程工作流類似于“局部往返工程”工作流（圖4），但是有一個重要的不同之處：“完整往返工程”下開發者利用雙向同步允許手工完成大部分編碼，從而造成抽象層次的降低，提高生產效率的程度受到限制。

圖4 局部往返工程圖5 在兩個方向上的同步連鎖反應

4 應用現狀

OMG從推出MDA思想以來，一直不斷地完善和建立MDA框架內的各種標準。目前國內外已經出現了不少優秀的工具和平臺以支持MDA方法，如法國Softeam公司的Objecteering 工具，它是第一個完全支持MDA方法的CASE工具。其它公司如TogetherSoft的Together ControlCenter， Interactive Objects Software的ArcStyler，IBM的Rational Software都采用了MDA思想，并支持往返工程的一些方法。下面根據筆者的開發經驗，通過兩個實例：EMF和KCOM商業工程來看往返工程在MDA中的具體應用。

4.1 EMF

4.1.1 EMF介紹

EMF（Eclipse Modeling Framework，Eclipse建?？蚣埽┦情_源項目Eclipse的一個重要子項目。它作為一個Java框架與代碼生成機制，可以快速地將模型轉換成高效、正確和易于定制的Java代碼，從而構建基于結構化模型的工具或其他應用系統。EMF把Java、XML和UML這三種重要的技術結合了起來，是MDA在Eclipse上的一個實現，如圖6所示。

EMF支持MDA的關鍵概念，即使用模型作為開發工具和集成工具的輸入，再由同一個模型生出特定的程序代碼和數據交換文檔。EMF把XMI作為模型定義的規范形式，定義模型的方法之一是使用UML建模工具定義類模型（UML Class Models）。模型輸入EMF后，由代碼生成器轉換成一個Java實現類的集合。EMF框架通過輸入的UML類模型來驅動Java接口和實現類的代碼生成，并實現XML序列化。

4.1.2 EMF的標簽機制

在使用EMF進行開發的過程中，往往會采取“局部往返工程”的開發方法，即對EMF生成的Java代碼進行擴展，添加自定義的類方法或實例變量。局部往返工程的一個重要問題是：開發工具必須能夠識別和避免覆蓋用戶所做的增強工作。在使用EMF進行開發的過程中，模型定義階段產生的類模型可能被修改并被重新加工產生Java實現類。EMF通過標簽機制來保留用戶添加的擴展代碼，從而保持代碼和類模型的一致。如圖7所示的UML模型。

把模型導入EMF后，對模型中定義的每個類都會生成一個Java接口（Java Interface）和對應的實現類。在為Department類生成的實現類DepartmentImpl中，方法getName()的代碼如下所示：

EMF生成的每個接口、接口內聲明的方法和方法實現都有一段包含@generated標簽的Javadoc注解。每次根據模型重新生成代碼時，EMF的代碼生成器通過原有代碼的Javadoc注解來判斷是否覆蓋這段代碼。如果Javadoc注解里包含一行“@generated”標簽，表示這段代碼是根據模型自動生成的，則使用重新生成的代碼覆蓋原有代碼；否則說明這段代碼被用戶修改過，這部分代碼將保持不變。

在重新生成代碼的過程中，為了讓原有代碼中的用戶擴展不被覆蓋，可以直接刪除@generated這一行注解，或者將其改名成其他字符串，如“@generated NOT”，以便將來通過Javadoc搜索找到在哪些地方做了手工修改。可將上例中的getName()修改為：

代碼生成器就會根據“@generated NOT”標簽將它識別為用戶的擴展代碼，因此在模型被重新轉換后不被覆蓋掉。使用同樣的方法，還可以向生成的Java代碼中增加新的類方法而不被覆蓋。這樣就解決了“局部往返工程”中保留用戶的增強工作的問題。

另外， EMF還支持MDA定義的“只允許正向工程”方法。它利用一種使用額外信息對元模型對象進行注解的通用機制，可以把Java代碼作為操作注解放進EMF模型的操作規約里，然后在代碼生成過程中被添加到Java方法體中。

4.2 KCOM商業工程

4.2.1 KCOM商業工程介紹

KCOM商業工程采用模型驅動體系架構，集成了數據模型、業務過程、組織機構、商業智能、UML、KCOM組件、應用服務器等眾多的軟件工具。支持標準的UML圖、采用標準的XML作為數據交互格式，支持WFMC定義的標準的工作流模型和標準的COM組件模型。開發者在完全可視化的集成平臺上，利用平臺已有的功能組件對業務需求構建PIM模型，平臺會自動轉換為代碼，經過多次迭代開發，應用軟件系統逐步完善，最終達到可以交付發布運行的狀態。筆者在該平臺上進行了一年多的企業應用軟件的開發，發現KCOM商業工程可以達到80%－95%的代碼自動生成。某個小范圍的應用，如進銷存系統，KCOM商業工程可以做到接近100%的自動生成。

KCOM是一種基于組件的編程模型，每個KCOM應用程序都是一個KCOM組件，其中包括組件頁面、組件方法。所以KCOM的生成器要做的是組件頁面（用戶界面）的生成以及組件方法（程序代碼）的生成。

4.2.2 組件方法（程序代碼）的生成

開發者的增強工作可能會有兩種情況，一是添加自定義方法，二是在生成器產生的方法里添加程序代碼行。為了確保開發者的增強工作不會被覆蓋，KCOM生成器采取的方法如下：

(1)通過方法的描述信息來區分是生成器產生的方法還是自定義的方法，生成器產生的方法都有“組裝的”這樣的描述信息，否則就都認為是自定義的方法；

(2)在生成器產生的方法的代碼行的特殊位置加上特點的注釋作為標記，然后將自定義的代碼行嵌入到注釋之間。Note Trigger OnLoad

... 自定義代碼行

Note End Trigger

KCOM采用的方法與EMF的方法有所不同，它不是在生成代碼的過程中決定哪些要覆蓋，哪些不要覆蓋，而是對模型加以擴展，然后提供了一個模型工具，用來掃描程序代碼，將自定義的方法以及嵌入的代碼找出來，并反映到模型里。這樣自定義的方法及嵌入的代碼行就成為模型的一部分，生成器在生成代碼的過程中就會連帶生成自定義的方法及嵌入的代碼行。

4.2.3 組件頁面（用戶界面）的生成

對于自定義的組件頁面，模型工具也同樣需要掃描出來并反映到模型里。與程序代碼不同的是，組件頁面在KCOM里是以二進制（非文本）的方式存儲的。MDA的模型文件通常會用XML文本文件來存儲，所以如何將二進制的組件頁面轉換為XML文本，以及生成器如何將XML文本模型轉換回二進制的組件頁面是要解決的關鍵問題。為此生成器做了一個轉換工作，將二進制的組件頁面表示成“mem0100110000101100010110110100111000000”這樣的文本串。

KCOM商業工程雖然將開發者的增強工作回歸到模型中，但是這部分工作的抽象層次并沒有面對于開發者，開發者在模型的層次并沒有看見自己在底層的增強工作，只是為了模型能夠識別和避免覆蓋用戶所做的增強工作，所以仍屬于“局部往返工程”。

5 結束語

MDA將向“只允許正向工程”的方向發展，因為這樣將避免手工編寫代碼，從而確保企業建造信息系統的能力最強，即使在開發復雜系統時也容易管理。但目前在MDA應用于企業系統的過渡階段仍然需要“局部往返工程”，市場上很多支持MDA的開發工具也證明了這一點。采用模型驅動開發應用項目時，應注意以下幾點：

(1)要根據項目的實際需求選擇適合應用領域的模型驅動開發工具，然后要清楚應用項目中哪些部分是可以用模型來定義并自動轉換的，哪些還需要手工編寫代碼。

(2)在利用模型驅動開發工具進行開發時，必須掌握該種建模語言的模型元素及其屬性所代表的含義，并且確定這些屬性值對轉換生成的應用系統的哪些部分產生影響，這樣才能最大限度地利用平臺本身所具有的功能組件，從而提高開發效率。

(3)對于不能從模型自動生成而需要手工編寫的程序代碼，可以抽取并轉換成模板，通過不斷積累應用模板，可以豐富模型的功能和涵蓋范圍。

總之，MDA已經成為新一代的軟件開發方法，MDA的最終實現對于提高軟件的生產效率、可移植性、可復用性、可維護性等方面都會產生積極的影響。

本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文。