摘  要: 對于MDA橫切于核心業(yè)務邏輯的關注點對封裝的破壞的問題,本文給出把AOP引入到MDA的擴展策略和主要方法，并對不同的擴展策略進行了比較。
關鍵詞： 模型驅(qū)動架構； 面向方面； 擴展； 元模型； 統(tǒng)一建模語言

　MDA是一種以模型為中心的軟件開發(fā)新方法[1,2]。但是，MDA仍然不能有效地處理橫切“關注點”問題。
　近來MDA和AOSD兩者的融合和相互支持已成為具有重要的理論意義和實用價值的研究課題[1]。其中的主要研究方向之一是：采用主流開發(fā)框架MDA，在MDA的建模過程中引入AOP 的概念和思想，建立通用的具有面向方面特性的PIM。
　如何把面向方面的概念和思想引入到MDA中，可以采取多種不同的擴展策略。
1 MDA引入AOP的擴展策略
　在MDA的建模過程中引入面向方面的思想和概念，其中最重要的是如何表示面向方面AOP的概念和思想以及表達方式。
    下面給出兩種有代表性的擴展策略及其實現(xiàn)方法：基于MOF的擴展和基于UML 2.0 Profile的擴展，這是當前的主流。
1.1 基于MOF的擴展策略
    在MDA中,MOF位于MOF四層模型的最高層。MOF體系是開放的，因而可以對它添加新的描述UML的元類型，以擴展新的功能和應用。圖1給出了這種擴展的示意。    但是,這種擴展策略要做的工作較多也較為困難，必須對UML的核心語義十分熟悉。目前所做的研究還很少?；贛OF的AOP擴展也稱為“重量級”的擴展。參考文獻[2]比較全面地介紹了一種通用的支持AOP 的MOF 2.0元模型。

    MOF擴展策略以MDA作為不同的AOP擴充方案之間的集成元素，自動或半自動地把在某開發(fā)階段建立的模型轉(zhuǎn)換成下一階段的模型，直到最終實現(xiàn)為止。首先建立AO術語的被廣泛接受的本體，基于這些本體的共同元素和它們之間的關系建立通用的支持AOP的MOF元模型。其擴展方法和過程可描述如下：
　第一步是確定出各種不同的AOP擴充方案所共享的概念，并根據(jù)概念的目的把它們分組成包，以提高可理解性。然后，建立包與包之間的關系。由此，可以建立三個主要的包：(1)Entities包，描述分解單元和它們之間的關系的實體；(2)JoinpointModel包，包含允許注入行為對應用程序的執(zhí)行進行干預的關注點的包；(3)CompositionRules包，它有兩個子包，SymmetricRules描述對稱規(guī)則， AsymmetricRules描述不對稱規(guī)則。這三個包可以從UML 2.0元模型的內(nèi)核和CommomBehaviors包的元素進行特化。
    實體：UML2.0 BehaviouredClassifiers的特化。
　JoinpointModel：連接點是對應用程序的運行進行干預以執(zhí)行一個方面行為（AspectJ中的advice）。所以，每個實體由一個可以隱式附上方面行為的Hook集組成。在UML2.0中，這些Hooks是基本單元的Behaviors。
　CompositionRules：SymmetricRules用以通過若干實體（也稱為子模塊）的組合產(chǎn)生一個更大的實體。AsymmetricRules用于說明任何在連接點（hooks）上應用aspects。
　這樣建立的通用元模型可以精細化為更加具體的模型，例如CBSD(Component-Based Software Development)與AOSD的集成模型CAM、Theme/UML模型。CAM與Theme/UML模型之間還可以實現(xiàn)相互轉(zhuǎn)換。
1.2 基于UML 2.0 Profile擴展策略
    這種擴展策略的基礎是： UML2.0 Profile提供了很好的擴展機制。圖2是其示意圖。

1.2.1 擴展方法和擴展機制
　UML2.0是建模語言的核心，其本身就是可擴展的。基于UML Profile的擴展策略實際上是一種 基于UML 2.0的擴展。基于UML 2.0的擴展策略有兩種方法：
　(1) First-Class擴展。它允許增加、修改具有相應功能的元類就能使得UML 2.0具有描述AOP特性的建模能力。這種擴展增加了UML 2.0語言的復雜性和應用建模的困難性，還涉及到 MOF的修改，對已有的標準化造成了破壞，因而其缺點是明顯的。
　(2) Profiles方式。它是一種通過建立面向方面PIM的PIM-AOP Profile的方式。Profiles擴展無需改動已有的元模型，也不改變現(xiàn)有的語法和語義，而是通過UML Profiles的構造型、標記值和約束等擴展機制來擴展 UML 2.0的建模能力。這種方法易于理解,不破壞現(xiàn)有標準,還可以充分利用現(xiàn)有的相關工具。
　因此,通常選擇后一種擴展方法。它利用了UML 2.0 Profiles提供的三種擴展機制：  
　(1) 構造型
　該機制利用一個已存在的模型元素來定義一種新的模型元素。新模型元素是已有模型元素的子類，通過泛化繼承已有的元模型類，并添加額外的語義來實現(xiàn)擴展。
　(2) 標記值
　標記值用于指定模型元素的性質(zhì)，由標記字符串和值字符串組成，是對特性的顯式定義。任何模型元素都可以應用標記值來增加新的語義。標記值也可用來提供附加信息以有效提高模型的質(zhì)量。
　(3) 約束
　約束用于對模型元素提供語義條件或限制。它用大括弧內(nèi)的字符串表達式來表示。約束可應用于一個或多個元素上，可以附加在依賴、注釋等元素上以表示約束和關系。因此可以用來對模型元素進行語義上的限制。
1.2.2 Profiles擴展方式實例
   (1) 方面aspcet的表示。方面是AOP最主要的概念，在建模過程中應該把它作為一個獨立的、封閉的并且可以擁有自定義的結(jié)構成員的實體來定義。Aspect可以通過UML Profiles的構造型的擴展來實現(xiàn)。如圖3所示。

　在定義Aspect構造型時需要：(1)指出新定義的構造型是基于哪個元素的；(2)改變或增加新的語義。
　標記isPrivileged用于決定aspect是否能訪問被其橫切的類的私有屬性。
　標記aspectInstantiationType用來決定aspect實例化的方式。它可定義基于連接點中對象實例化的、基于連接點中的控制流的和在整個應用程序中只創(chuàng)建一個aspect對象的等幾種方式。
　利用方面aspect既可以擴展出新的方面aspect或者抽象方面abstractaspect,也可以通過實現(xiàn)接口方面Iaspect來構造方面aspect。
　(2) 切入點pointcut的表示。切入點、連接點的定義必須包含靜態(tài)語義和動態(tài)行為語義兩個方面。切入點、連接點的AOP動態(tài)行為語義是指干預應用的運行以執(zhí)行方面aspect的行為。動態(tài)行為語義的描述和擴展通常選用在AOP中具有代表性的AspectJ中的advice。
　切入點的表述可通過UML Profiles的構造型的擴展得到構造型pointcut。并可（也必須）為pointcut添加約束，使其只能用于構造型aspect。
　(3) 通知advice、連接點joinpoint。與切入點相關的通知advice和連接點joinpoint仍然可以通過UML Profiles的構造型的擴展來實現(xiàn)。
　用于描述動態(tài)行為語義的AspectJ advice實際上就是UML 2.0的Behaviors。對構造型advice可以且必須添加約束，使其只能用于構造型pointcut。并且可以實現(xiàn)通知的五種執(zhí)行方式：
?、?before通知：在連接點joinpoint執(zhí)行之前執(zhí)行before advice。但不能阻止連接點前的執(zhí)行；
　② after通知：在連接點joinpoint執(zhí)行之后執(zhí)行after advice；
?、?around通知：包圍一個連接點的通知，例如方法調(diào)用。Aroud通知在方法調(diào)用前后完成自定義的行為，并負責選擇繼續(xù)執(zhí)行連接點或通過自己的返回值或拋出異常來中斷執(zhí)行。
?、?AfterThrowingAdvice通知：在方法拋出異常時執(zhí)行的通知。
?、?AfterReturningAdvice通知：在連接點正常完成后執(zhí)行的通知。
　連接點有兩種類型：類連接點和方法連接點。
   類連接點構造型classjoinpoint的擴展實現(xiàn)可以也需要添加約束，使其只能用于切入點pointcut。并且可以實現(xiàn)通配符的條件比較。同樣,方法連接點構造型methodjoinpoint的擴展實現(xiàn)也需要添加約束，使其只能用于切入點pointcut。
　方法連接點methodjoinpoint是專門針對方法的。方法所具有的修飾符、返回值、方法名、參數(shù)、參數(shù)個數(shù)以及異常等的表述，都可以在此基礎上，將方法連接點methodjoinpoint分解為修飾符構造型modifierJ、返回值構造型returnJ、參數(shù)構造型argsJ以及異常構造型exceptionJ。對modifierJ、returnJ、argsJ也都可以添加約束，使得它們只能用在方法連接點構造型methodjoinpoint和類連接點構造型classjoinpoint中。
　此外，AOP中對連接點的動態(tài)捕獲(控制流程中類方法執(zhí)行中涉及的連接點以及對類的字段進行處理、類初始化、對象初始化等涉及的所有連接點)和靜態(tài)捕獲(捕獲在指定類或者方面中的程序體中的所有連接點以及滿足一定條件的連接點)，以及用于表示橫切關注點引發(fā)的行為順序等機制，都可以通過UML 2.0 Profile的擴展來獲得。
2 擴展策略的比較和相關研究
    相對來說，使用UML 2.0 Profile的最大好處是可以獲得大多數(shù)UML2.0工具的支持，建模人員可以容易地使用UML2.0 Profile擴展機制在MDA中引入面向方面的建模[9,13]。從理論上來說，可以創(chuàng)建無限個特征文件Profile。因而，只要遵循UML 2.0規(guī)范，任何的建模人員都可以創(chuàng)建滿足自己需要的任何特征文件。通過Profile 的擴展機制建立UML2.0 PIM-AOP Profile模型規(guī)范的方式具有較強的通用性，例如當AOP的語法增加或變動時，可以容易地在該PIM模型規(guī)范中實現(xiàn)。
　但是，在進行軟件開發(fā)時使用UML2.0 Profile擴展，必須首先利用面向方面技術將核心業(yè)務邏輯和橫切關注點分離，然后建立實現(xiàn)系統(tǒng)核心關注點的功能PIM 和橫切關注點的方面PIM，接下來還要根據(jù)選定的具體技術平臺利用相關的平臺變換規(guī)則分別將功能PIM和方面PIM變換為功能PSM和方面PSM。最后還需利用特定方面平臺的編織技術將這兩部分編織在一起形成最終代碼[1]。
　與UML Profile的擴展策略相比較，MOF擴展可以充分利用和表達元模型的語義，其抽象級更高，因而靈活性也更高。但它工作困難、現(xiàn)有的支持工具較少。
　支持AOP的MOF元模型具有更強的表達能力，而且獨立于任何的標記，同時還能為除MDA以外的其他建模標準（如XMI、QVT等）所使用。
　支持AOP的MOF元模型的優(yōu)點是： (1)有助于不同的AOP擴充方案建立元模型; (2)通過一個簡單的元模型能夠方便地確定不同的AOP擴充方案的異同; (3)能夠?qū)崿F(xiàn)模型之間的水平變換，即不同的AOP擴充方案之間的轉(zhuǎn)換; (4)有利于轉(zhuǎn)換工具的開發(fā)。
　MOF擴展可以遵循MDA方法，使用預定義的轉(zhuǎn)換，從元模型生成目標模型所有可能的元素。另一方面，利用這種方法，可以生成多個目標模型，獲取相同系統(tǒng)的不同實現(xiàn)方案。
　此外，基于各種特定的MOF元模型建立的任何模型，以及任何使用經(jīng)擴展的通用的支持AOP的MOF元模型構建的任何模型，都可以直接通過XMI標準序列化為XML。
　一些試圖擴展UML元模型以支持AOP的相關工作有：
　參考文獻[3]根據(jù)AspectJ 和AspectC++中元素的語義，通過繼承相應UML 中元素的方法擴展了UML 的元模型。類圖中的切入點可以從方面中分離出來，這樣可以清晰地表示在這個切入點處的多個橫切關系；順序圖中新添加的通知發(fā)出焦點可以方便地表達行為橫切。但所采用的方法是非形式化的，而且其實現(xiàn)和應用都較麻煩和困難。
　參考文獻[4]基于AspectJ語法語義和XMI擴展UML元模型，并實現(xiàn)了面向方面的重要概念。但該方法缺乏對基于面向方面的動態(tài)行為和特征的支持。
　這些基于UML元模型的擴展都非常接近于諸如AspectJ的原始AOSD方法，且不支持更高級的功能，如對稱組合。
　其他的一些對基于UML Profile擴展的研究工作有：參考文獻[5]給出了面向方面設計的通用UML Profile的構造。提出了用UML 中的collaboration template、 Feature和Association模型元素的擴展構造型。但是工作并沒有最終完成，而且寄希望于通過不同的方案來完成。此外，它仍然不支持諸如對稱組合規(guī)則等高級概念，其實用性也有待于在不同的方案中進行檢驗。參考文獻[6]提出了用于AspectJ的設計標記。參考文獻[7]提出一個原始的AspectJ profile，其中，advice和pointcut是基于operation的構造型，aspect與核心業(yè)務模塊之間的關系表達為依賴關系。參考文獻[6]、[7]給出的擴展策略的共同缺點是過分依賴于特定的技術。
   還有一些略有不同的擴展策略：(1)基于UML profile的擴展，同時又可通過MOF擴展引入新的元模型的方法；(2)在UML模型中引入構造型aspect；(3)不需要擴展UML，利用狀態(tài)圖和類圖為不同的關注點進行建模。但這些方法均不完善且存在較多的缺點[8]。
   以模型為中心的軟件開發(fā)新方法MDA有其獨特的絕對優(yōu)勢，面向方面技術可以對MDA進行補充，以解決MDA難以處理的橫切關注點的問題。將面向方面的MDA用于復雜軟件系統(tǒng)的開發(fā)可以大大提高軟件的可重用性和可維護性，降低開發(fā)成本。將這兩種重要的軟件開發(fā)方法結(jié)合起來有望成為未來軟件開發(fā)的發(fā)展趨勢。但是如何將兩者很好地結(jié)合起來還有許多問題需要進一步深入研究和解決。
參考文獻
[1] 劉敬勇，張立臣，陳成．基于面向方面MDA的軟件開發(fā)方法[J]. 計算機工程與設計，2009,30(17)：4077-4080.
[2] FUENTES L,SANCHEZ P. A generic MOF metamodel for  aspect-oriented modeling [C]. Proceedings of the Fourth  Workshop on Model-Based Development of Computer-Based Systems and Third International Workshop on Model-Based Methodologies for Pervasive and Embedded Software (MBD/MOMPES’06), Potsdam, IEEE Computer Society, 2006:113-124.
[3] 郭東亮，張立臣．基于擴展UML 的面向方面的建模 [J]. 計算機工程，2006，32（19）：100-102.
[4] 吳剛，郝克剛，葛瑋．基于UML的面向方面建模研究[J]. 計算機應用與軟件，2007，24（11）：95-97.
[5] ALDAWUD O, ELRAD T, BADER A. Uml profile for aspect oriented software development[C]. In Proc.of 3rd Int. Workshop on AOM,AOSD 2003, Boston, USA, 2003(3).
[6] STEIN D, HANENBERG S, UNLAND R. A UML-based aspect-oriented design notation for AspectJ[C]. In Proc. of  AOSD’02, Enschede, The Netherlands, 2002(4):106-112.
[7] STEIN D,HANENBERG S, UNLAND R.Designing aspect-oriented crosscutting in UML[C].In Proceedings of the AOM with UML workshop at AOSD 2002.
[8] YAN H, KNIESEL G, CREMERS A. A metamodel and  modeling notation for AspectJ[C]. In Proceedings of the AOM  workshop at AOSD 2004.