使用方面建模: 使用方面進行建模介紹

領測軟件測試網 面向方面建模用模型驅動開發(MDD)的方法來簡化面向方面的開發。這種面向方面建模的方法包括在設計時使用面向方面的關鍵字注釋UML面向方面模型單元以用于訪問橫切關系。特殊目標環境的面向方面代碼在從UML到目標轉換（target transformation）時生成。文章的以下部分將引入用于MDD架構的面向對象設計，它為使用IBM® Rational® Software Architect（以后簡稱，Software Architect）的AspectJ 和Java開發團隊提供了一種新的軟件開發方式。此構架可以讓使用者很方便地為應用程序里的多種橫切關系封裝他們自己的基于AspectJ的機制，這些橫切關系可以在設計建模期間引入到一個應用程序中。

介紹

面向方面技術是對用于訪問橫切關系卻不破壞對象的面向對象編程的一個重要補充，現在，支持應用面向方面的工具越來越多，最有代表性的例子是AspectJ Development Tools (AJDT) Eclipse 項目，它提供了支持AspectJ的工具，因此面向方面所帶來的好處也被更深入地了解。但是，為了能夠利用此項技術，開發者仍然需要學習一種新的編程語法和方式。

面向方面建模使用模型驅動開發（MDD）的方法用來解決這個問題。建模者/開發者可以將面向方面技術應用于UML模型（典型的是類圖）并且在UML 到 Java™轉換的同時生成 相應的 AspectJ。建模者/開發者不需要了解任何有關面向方面技術的的知識，而僅僅需要制定將哪個方面應用到這個模型中去。

模型驅動開發

UML為設計師和開發者提供一個為面向對象系統和它們內部之間交互過程實現可視化的方法。如IBM® Rational Rose® 和Software Architect這樣的建模工具了提供豐富的建模環境。

簡單的說，模型驅動開發就是通過使用抽象的模型進行軟件開發。應用軟件和系統的模型在不同的抽象級別中創建，并且通過自動或人工的方式驅動低抽象級別的模型進化（圖1）。這種軟件開發方式的模型被認為是開發流程的一流工件。他們就好像軟件開發活動中的源代碼一樣以位為單位。

圖1. 應用軟件開發項目中的典型模型

這個模型提供了一種關注應用軟件中特定部分的關系而不依賴于其它關系的機制。比如，數據模型總是和持久數據（對象狀態）以及它的結構有關。它與用戶界面的動態行為無關，甚至和事務邏輯行為也無關。選擇開發進程的不同模型種類來匹配特定的任務和行為，因此所有工作通常只關注分派任務的領域。這不僅讓開發團隊成員成為專家并且定義了一個分離工件和過程開發的方法。

例如，一個保留的用于事務應用程序的用例可以提供一個關于此用例的文本描述（易讀的）。這個描述可以讓團隊中不是此技術領域專家的成員看懂。分析師可以使用呈現出應用程序行為的對象來對系統進行描述。在模型中使用包含保留實體的詳盡規格和控制器類（用于實體管理）的程序表和類表把它們紀錄成文檔。這個被分析模型驅動的設計模型可以使用 EJB的多種接口實體，實現類，部署描述符以及對實現設計所必需的具體工件來實現實體。

設計模型抽象級別中，源代碼的差別是很小的，以至于現成的代碼生成器（轉換）可以把模型轉為源代碼和配置文件，如圖2所示。甚至在某些場合可以生成（當特定設計模式已被應用）行為（方法實體）。

圖2. 將模型轉換為代碼

回頁首

面向方面的技術

橫切關系是一個跨越各個層次或子系統進行分享和展示的問題。例如，通常的關系包括：

• 日志
• 安全性
• 持久性
• 緩存
• 錯誤處理
• 一致性檢查

傳統的訪問橫切關系的方法包括插入API或框架，在開發過程中通過IDE和其它類型的自動操作引入。這也許會導致難以維持的代碼，并會導致開發者的注意力從對象的核心事務功能性轉移到關系的集成。

Aspects 提供了一個非入侵的解決方法用于訪問橫切關系。 對象在開發完成之后，方面將特定的關系行為引入到系統。當對象被編譯后，它們的功能已被組合編排到運行代碼中。只留下了沒有被關系使用的對象事務代碼。

方面功能可以通過多種方法編排對象的行為。例如，圖3顯示了一些對象方法的UML行為。我們把焦點集中在對象的代碼和行為而不是任何橫切關系。這些關系在其它對象或者在編排在主控制流程中的方面中執行。

圖3. 一個典型對象方法的的控制流

在對象方法訪問之前（圖4）或之后（圖5），方面功能都可以嵌入到所有的流程中去。方面還可以安置在對象方法的周圍，在那里 方面可以選擇決定繞開或激活目標方法（圖6）。

圖4. 在一個方法前被激活的方面行為


圖5. 在一個方法后被激活的方面行為


圖6. 圍繞一個方法的方面行為

引入體系架構機制而不接觸IDE中的事務邏輯代碼，使用面向方面技術是一個非常有效的方法�？梢詫⒁粋�方面應用于一個特定的信息包，類或方法。在應用程序里使用方面需要兩件事：

• 方面自身的開發
• 橫切點，位置，調用方面代碼的條件定義

把方面功能的開發留給最好的專業人員，他們是項目的設計師和技術領導者。這些開發者在面向方面技術方面擁有著豐富的經驗和技術。這里仍然需要完成一項任務，把面向方面技術和應用程序中特定的點連接在一起。這項任務最好由余下的編程人員完成 。這里最大的困難是需要一些面向方面的知識并掌握一些AspectJ的語法。在MDD項目中我們就要用到面向方面的技術。

用于MDD框架的面向方面技術使它可以很容易地讓設計師封裝以方面為基礎的體系架構機制，所以普通的開發者——有些許或完全沒有面向方面的有關技術技術——也可以在應用程序的開發過程中使用面向方面技術。

回頁首

面向方面技術和模型驅動開發

MDD是一個用于軟件開發的方法論，而方面是為軟件應用程序傳達功能的方法。 兩者相輔相成；然而在過去卻總不會把他們想到一起。用于MDD框架的變相方面技術把兩者結合在一起用于解決如何讓大型開發團隊在MDD使用過程中更便捷地發揮面向方面的優勢。這里的關鍵問題在于那些想在應用程序中使用面向方面的開發者需要了解如何編寫將方面與正在進行的系統部分結合在一起的面向方面代碼。

架構師用UML進行系統實現建模典型的是在分析和設計的層面上進行的。在設計層面，軟件設計師對想要建立的工件進行代碼編寫的態度是鮮明的，在那里，架構師把訪問橫切關系作為非功能需求訪問的一種手段。

然而，為了記錄在對象模型中的橫切關系的使用情況，設計師經常需要創建詳細冗長的文件以便祥盡描述對體系結構方面的考慮事項。然后，開發者需要理解這些體系結構方面的考慮事項，或者利用面向方面的技術——假設他們已經充分地掌握了這些技術——或者他們更可能使用一個更傳統的方法比如剛才已經提及的API和框架。

把面向方面技術和MDD集成在一起解決了這兩個問題。本文就介紹了這種機制，方面可以被引入到開發工作中——使用標準的文本建模符號——無需了解他們是如何創建的或者此項技術所需的最低技術要求。

最重要的是開發者(不清楚面向方面技術的細節)也可以標記那些與之前開發的面向方面有關的模型單元。當這些模型單元被實現(或者轉換為代碼后)，任何方面必需的粘合代碼會自動創建，并和預先確定的方面進行結合。圖7顯示了一個類中幾個操作的注釋過程。這個類是一個操作的實現，并且僅僅具體的操作可以創建。在這個例子中getCatalog()操作模型元素用<<Log>>注釋，而getCatalogs()操作模型元素用<<Cache>>注釋。

圖7. 使用方面關鍵字對模型進行注釋


圖8. 生成AspectJ代碼

基本步驟包括讓設計師或面向方面開發的專家編寫以面向方面為基礎的代碼，此代碼被引用在應用程序的不同地方。例如，設計師可以創建一個可重復利用的緩存，當性能需要一個如簡單緩存一類的東西時就可以在應用程序中使用。在任何重大設計發生之前幾乎不可能知道此機制會被使用在哪里。然而，依照以往的經驗，你也許會猜出此機制會在哪些地方使用。

軟件設計師可以基于面向方面的技術開發這樣的一個機制，并且，面向方面技術應用于MDD框架包也是一個可以再利用的資產。這些面向方面已經幾乎完成，但是幾個對它們(指出定義在目標應用程序中的單元)的定義卻很抽象。這很重要，因為——在目標應用程序生成之前——這些以面向方面為基礎的架構機制就已經建立并且進行測試——只需要等待最終橫切的確定，讓目標應用程序中使用的方面進行具體化。這個橫切定義只有在應用程序開始定義之后才會得知。

這些抽象的面向方面被封裝，可以在開發者的工作站中安裝使用。在那里，可以將它們應用在正在開發中的應用程序的特定的，離散的地點。開發者可以不用了解面向方面的技術并且通過選擇模型單元(包，類，或者操作 )并且通過已安裝的面向方面的UML標記這些元素來應用此面向方面的技術。在隨后的代碼生成轉化的過程中，我們將在項目中引入開發前期的方面——或者包含它們的庫，并且抽象的方面也會進行稍加具體的引申并安排到目標應用程序中去。

使用面向方面方法的最大好處是——可實現任何數量的架構機制，并且可以訪問目標應用程序中不同的關系——可以在任何特定應用程序著手之前進行開發。它們可以在資源庫中開發和儲存，并且可以在日后開發項目過程中下載使用。其它的優點是那些非面向方面的開發者在正確的指引下可以在常規的MDD處理過程中使用面向方面的技術。不需要額外的技術——不需要知道目標和特殊方面的使用。

回頁首

哪些已經被完成

本文為Software Architect引入可用于MDD架構的面向方面技術。這是一個簡單的架構，用于包裝和開發以AspectJ為基礎的架構機制和代碼�？蓪⒋思軜嬘糜谡�在開發中的應用程序，在開發團隊將面向方面應用于真實的項目時卻無需掌握任何有關它的重要技術。它可以對向方面的機制進行開發并建立資源庫，選擇性地安裝和應用于還在開發過程中的應用程序的特定部分。它可以使軟件設計師和面向方面的專家與大型團隊分享他們的經驗與技術，可以讓開發團隊把全部精力放在設計和實行應用程序的事務及域的功能性。

延伸閱讀

文章來源于領測軟件測試網 http://www.kjueaiud.com/