一種新的面向方面的架構描述概念模型研究
2008-12-31 00:00:00葛君偉唐蓉夏英
計算機應用研究 2008年12期
（重慶郵電大學 a.軟件學院; b.中韓合作GIS研究所， 重慶 400065）
摘 要：
軟件架構的描述和設計決定了軟件的質量和生命。作為方面的橫切關注點橫跨在多個架構組件中，影響了模塊間的內聚性和耦合度，從而降低了軟件的可重用性，增加了維護的難度。目前提出的許多架構描述方法均未能對存在的橫切關注點進行恰當的描述和定位，所以在軟件的架構描述方法中引入了方面的概念機制來解決這些問題。基于IEEE 14712000中提出的架構描述概念模型，引入用例視圖提出了一種新的面向方面的架構描述概念模型。該模型能夠在架構描述中精確地描述和處理橫切關注點即增加方面這一抽象層，從而提高軟件系統的維護性、重用性和擴展性。
關鍵詞：面向方面； 架構描述； 用例； 面向方面的軟件開發
中圖分類號：TP311 文獻標志碼： A
文章編號：10013695(2008)12363603
Novel aspectoriented conceptual model for architectural description
GE Junwei a，b， TANG Rongb， XIA Yingb
(a.College of Software， b.SinoKorea Chongqing GIS Research Center， Chongqing University of Posts Telecommunications， Chongqing 400065， China)
Abstract:
The architectural description and design decide the quality and life of the software. Crosscutting concerns as aspects crosscut multiple architectural components， which affected cohesion and coupling of components. It results in lower values for modifiability and reuses quality attributes. But now a lot of methods about architectural description fail to accommodate the description for crosscutting concerns. Accordingly， the concept of aspectorientation is required to be addressed in architecture description. This paper， on the based of conceptual model for architectural description in IEEE 14712000， based on usecase and proposed a novel aspectoriented conceptual model to explicitly address aspects in architectural description. It is more favorable to maintain， reuse and evolve software system.
Key words：aspectoriented; architectural description; use case; AOSD
0 引言
軟件架構設計方法的目的就是在軟件系統被開發之前來預測和保證系統的質量。在整個軟件的開發生命周期內，軟件架構的設計具有非常重要的地位，因為它體現出了早期的設計決定，而且包含其中的整個組件設計會直接影響子系統的分析、設計和實現[1，2]。因此，對于不同的開發者來說，軟件架構設計能夠保證整個軟件系統的質量和性能，具有非常重要的作用。同時，如像軟件架構的抽象性、分離性和模塊性等特性會影響以后系統在運行時所關注的系統性能和安全特性，并且還會影響系統在運行時不會明顯關心的可修改性、可移植性、可擴展性、開發效率和可靠性等特性。因此，架構設計和其中的架構描述在整個軟件的開發生命周期中具有舉足輕重的作用，一旦該環節出錯將會導致后續開發的困難和順利進行。但是，目前開發的一些軟件系統尤其是大型的系統，都會存在如日志、權限、緩存或數據訪問這樣的功能模塊，它們被稱之為橫切關注點，會被系統中多個不相關的業務模塊使用，而本身與業務邏輯無關，使得這些基礎功能與業務邏輯混合，導致許多問題產生。在軟件架構設計階段就存在這樣的橫切關注點需要分離和重新定位描述，否則它將會造成后續程序實現階段出現代碼混亂和維護困難等問題。基于上述的問題，隨著AOSD（aspectoriented software development）即面向方面軟件開發技術的發展，本文提出了一種新的面向方面的架構描述概念模型，使得橫切關注點在架構描述中得到定位和描述處理，在架構設計階段就實現對橫切關注點的分離，從而提高軟件系統的重用性、維護性和擴展性。
1 橫切關注點和AOSD技術的概念
11 橫切關注點
一些復雜的軟件系統會包含若干核心級和系統級的關注點（concerns），軟件開發過程即是清楚地分離各個關注點，并逐一實現各個關注點的過程。本文所謂的關注點是指一個特定的目標、概念或感興趣的領域，核心級關注點是指系統要完成的業務功能，系統級關注點則是指系統的特性或需求[3]。使用面向對象方法開發復雜系統時，在多種需求關注點和實現的模塊之間映射時，核心關注點一般可以很好地用獨立的核心模塊來實現，而系統級的關注點如安全性能、日志等則會橫切到系統的多個模塊中，影響多個模塊的實現。從而這些系統級的關注點即橫切關注點造成了代碼交織（code tangling）和代碼混亂（code scatter）的問題出現，使得系統的不同需求在軟件模塊中同時需要滿足并相互影響，造成一個模塊要同時考慮業務邏輯、功能、性能以及它們之間的協同和安全性，導致軟件開發過程的可追蹤性差、開發效率低、代碼復用性差，難以開發和維護的困難。
12 AOSD技術的概念
AOSD即面向方面的軟件開發方法，是一種分別獨立分析和設計系統的各個核心關注點和橫切關注點的機制，并且能夠在軟件開發后期實現橫切關注點與相關核心關注點的集成，甚至能夠將一個橫切關注點實現代碼織入到軟件系統中，而無須改動原系統的各個模塊，解決了面向對象（OOP）方法中無法解決的問題[4]。AOSD方法根據系統分析的結果，分離出橫切關注點與核心關注點。對于核心關注點可以使用面向對象的方法實現，而對于用面向對象方法難以清晰封裝并模塊化實現的橫切關注點，就用面向方面的方法封裝成獨立的模塊來實現。其主要方法是引入了方面（aspect）機制來描述橫切關注點，并給出方面與原系統相合成的技術[3]。方面的實現與傳統的開發方法中模塊的實現不同，方面之間是一種弱耦合的關系，各方面的開發以及各個核心關注點的開發彼此獨立。只有在系統組裝時才將各方面和主代碼編排、融合在一起，使得軟件開發過程中無須考慮各個模塊之間錯綜復雜的關系，在很大程度上降低了軟件開發的難度。
AOSD方法是構建在面向對象方法的基礎之上，是對面向對象方法的一種演繹和發展，該方法可以更好地描述面向對象方法不擅長描述的橫跨多個模塊的需求或特性，很好地將關注點分離，從而模塊化地實現橫切特性，有效地解決復雜系統的橫切關注點的分離、設計和實現問題，實現各構件或模塊的弱耦合性。 在系統功能設計時，無須考慮散雜在對象中的關注點，同時在軟件的維護階段，將一個橫跨系統多個模塊的新特性加入到系統中去時也無須分別修改各個模塊，只需將此橫切特性設計成一個方面，再與相關模塊編譯一次即可，從而極大地降低了軟件開發和維護的難度，提高了代碼復用的粒度。
2 面向方面的軟件架構設計
目前，已有的一些軟件架構設計方法在處理橫切在多個架構模塊中的架構關注點時沒有與傳統方法作出一個明確的區分[5]，使得這些架構的橫切關注點不能被有效地處理，導致系統中產生代碼交織和分散的現象，從而影響了整個軟件的質量。然而AOSD方法正好能夠合理有效地處理和描述架構中的橫切關注點，該方法通過在架構設計和描述的階段引入架構方面機制來實現對架構橫切關注點的處理，體現出了所具有的優越性[5]。根據Pace和Campo的觀點和論證，軟件架構設計的重點是如何來定位和分離架構中的關注點[6]。因此面向方面的架構設計方法在架構設計階段提供了一種精確的機制即方面來確定和處理架構的橫切關注點，有效地分離了架構中的橫切關注點，解決了在實現階段的代碼交織和代碼分散以及系統的進一步擴展等問題。該方法有別于傳統的處理方法，尤其在架構的詳細說明中對于架構方面中的隱含信息處理具有很好的效果。但是，目前面向方面的架構設計方法的研究還處于起步階段，還沒有形成一個統一的標準，所以筆者需要從架構的高層次和低層次兩個方面來考慮對橫切關注點的處理并形成一個統一且詳細的說明，盡量向標準規格化的方向靠近。因為一個關注點可能被同時包含在幾個模塊中而且所有的這些模塊可能同時與那些橫切關注點的模塊有關聯，所以關注點的結構模塊比起功能型模塊具有更高的層次。 這樣就使得傳統方法設計出來的架構模型很難被理解，導致架構設計模型圖中對橫切關注點的描述混亂復雜，不利于架構設計模型的擴展和演化，不利于整個軟件系統的維護、擴展和重用，所以面向方面的軟件架構設計方法的提出具有很重要的研究價值和前景。
3 用例和方面
用例（use case）是UML[7]中非常重要的概念，在使用UML的整個軟件開發過程中處于中心的地位。所謂用例就是在不展現一個系統或子系統內部結構的情況下，對系統或子系統的某個連貫的功能單元的定義和描述，即對系統功能的描述。一個use case描述的是整個系統功能的一部分，這一部分一定是在邏輯上相對完整的功能流程。角色和用例之間的關系是通過用例圖來描述的，并使用結構化的敘述文本來進行補充。通常一個用例的描述應該包含如下部分[8]：
a)對用例描述的一般性注解；
b)必須讓用戶知道的需求；
c)約束條件；
d)執行用例的場景描述；
e)一系列描述工作流的場景圖；
f)增加的屬性描述，如像實現、版本號、復雜度等。
圖1就是一個描述售票系統的用例圖[9]。參與者包括售票員、監督員和公用電話亭。公用電話亭是另一個系統，它接收顧客的訂票請求。在售票處的應用模型中，顧客不是參與者，因為顧客不直接與售票處打交道。用例包括通過公用電話亭或售票員購票、購預約票（只能通過售票員）、售票監督（應監督員的要求）。購票和預約票包括一個共同的部分即通過信用卡來付錢（對售票系統的完整性還要包括其他一些用例，如換票和驗票等）。因此，一個用例可能同時包含其他用例的功能或對其他的用例進行了擴展。
那么對于一個軟件系統所涉及的用例和角色，在分析和設計階段雖然可以很好地定義其結構，但是它們可能在實現階段被分散或發生重疊現象，導致最后對整個產品的設計違背了先前的需求規定，變得復雜難懂，而且很難去改變和進一步擴展系統。因此，用例應該模塊化到已經分離的關注點中去，這樣的擴展機制思想正好與面向方面的程序設計技術（AOP）相吻合[10]。根據AOP的思想，在程序的執行過程中一個連接點模型允許來自于方面的代碼織入到面向對象的程序代碼中（叫做基本程序base program）形成一個特殊的點即連接點（join points）。這樣的思想剛好和用例與擴展點的擴展關系相一致。這里的擴展點就相當于前面所述的連接點，而且來自于擴展用例（extended use case）的連接點代碼能夠織入到基本用例中（base use case）。它們之間的關系如表1[11]所示。
4 架構描述的概念模型
根據IEEE 14712000的闡述表明，軟件系統的架構描述應該包含如下幾個方面[10]:
a)系統的描述和擴展；
b)系統之間的通信；
c)評估和比較架構的一致性；
d)管理和執行系統開發的規劃；
e)按照系統的原理描述其固有的特點以便于修改；
f)確認系統的實現與架構描述保持一致性；
g)記錄對于軟件系統結構知識體系的貢獻和作用。
軟件架構描述的概念框架如圖2所示[12]，圖中包含了多個視圖、帶有視圖的可重用模型和系統中架構的上下文關系。在這個架構描述的概念模型中，有如下的重要定義（如圖2中虛線所包含的部分）：
a)架構描述（architectural description）。一系列的視圖和增加的架構描述信息。
b)開發者（stakeholder）。個人、一個小組或與一個組織來關注和承擔對相關系統的開發。
c)關注點（concern）。軟件系統的功能或非功能需求。
d)視圖（view）。描述整個系統中對相關關注點觀察展現的一套模式，如用例視圖。
e)觀點（viewpoint）。對于創建、描述和分析一個視圖的常規說明。
f)模型（model）。根據定義在觀點中的方法來特別描述系統的構造，它能夠包含可以確認的子系統和要素。
從圖2中可以知道，一個架構描述是由一個或者更多的視圖（本文主要討論的是基于用例的視圖）和模型組成，而這些視圖和模型通常都是來自于所選擇的觀點。其中，選擇的觀點主要依賴于開發者和他們所關注的系統說明文檔；但是同時開發者又是由視圖來確定和定義的。所以，觀點確定了一個視圖的創建、描述和分析的常規說明，以此保證了一個視圖和一個觀點的一致性。而且，一個視圖可能由一個或多個架構模型組成，同時一個架構模型可能參與到一個或多個視圖中，使得該概念模型變得復雜，不利于理解、修改、維護和擴展系統。軟件維護是一個花費高但又不可避免的過程，并且擴展后的軟件系統會增加一些不可預料的關注點，這些關注點可能會根據改變后的需求橫切到多個模塊中去。因此，根據AOSD方法的特點，引入方面機制到架構描述中剛好能夠解決這一問題，能夠更好地處理架構中的橫切關注點問題，使得整個設計變得易于理解、維護和擴展。
5 基于用例的面向方面架構描述概念模型設計
根據上述第3、4章的闡述，為了軟件系統以后能夠更好地維護、修改和擴展，在架構設計過程中，筆者對架構描述的概念模型引入了方面的機制來實現，所以在架構描述的概念模型中需要確定對方面的描述。根據這一思想，本文對其IEEE 14712000中所提出的架構描述概念模型進行了擴展，將方面在基于用例的基礎上引入其中，使其成為新增加的一個抽象層介于關注點和觀點之間，如圖3所示（在這里只是將圖2中的虛線部分作為重點討論）。
從圖3中可以看出，這個新的架構描述概念模型由一個或更多的架構視圖組成，而且每一個視圖又確定出系統開發者所關注的一個或更多的方面視圖以及其中的多個關注點。在這個新模型中，與先前的概念模型一樣，每一個視圖都必須與觀點相一致，而且使用視圖來描述觀點中所確定的對于常規的創建、描述和分析方法的詳細說明。每一個視圖可能由一個或多個模型組成而且每個模型能夠被觀點的方法來確定和描述；同樣，一個架構模型可能參與到一個或多個視圖和架構描述中。特別地在該模型中，對于架構關注點中的橫切關注點，在基于用例的基礎上采用了方面這個抽象層給予了確定和描述。同時，一個架構描述不再像以前的模型通過選擇一個或多個視圖來使用，而是選擇模型中的方面來使用，并根據開發者對架構描述的要求來確定和選擇方面，從而達到了在架構設計階段對于橫切關注點進行很好的分離要求，以至于提高軟件開發的后期質量和進度，從而實現了對軟件系統的維護性、重用性和擴展性等方面的提高和改進。
6 結束語
本文的重點是在傳統的架構描述概念模型基礎上，建立了一種新的基于用例的面向方面的架構描述概念模型。在該模型中主要是在基于用例的基礎上引入AOSD方法中的方面機制到架構描述中，以此來解決在架構設計階段對于橫切關注點的確定、分離和描述的問題，從而提高軟件系統的維護性、重用性和擴展性。架構設計的重點是對于關系到軟件系統質量屬性的非功能需求的處理。在架構描述中，引入方面這個抽象層來對橫切關注點進行分離和描述能夠讓整個系統的結構設計更加清晰和容易理解，能夠實現系統設計的高度模塊化和提高功能關注點和非功能關注點的清晰度，從而能夠實現對于以后軟件系統的進一步修改、維護和擴展。總之，隨著AOSD技術的進一步發展和要求，在架構設計階段對于架構的描述引入方面機制來實現對于橫切關注點的確定、分離和描述將會變得越來越重要。
參考文獻：
[1]BASS L， CLEMENTS P， KAZMAN R. Software architecture in practice[M]. 2nd ed. Boston:AddisonWesley， 1998.
[2] AKSIT M. Software architectures and component technology: the state of the art in research and practice[M]. Netherlands: Kluwer Academic Publishers， 2001.
[3] KICZALES G， LAMPING J， MENDHEKAR A， et al. Aspectoriented programming[C]//Proc of the 11th European Conference on ObjectOriented Programming. Berlin: SpringerVerlag， 1997: 220242.
[4] 顧治華，假仰理，張振領.AOSD一種新型軟件開發方法[J].計算機時代，2005， 20 (12):1316.
[5] CHITCHYAN R， RASHID A， SAWYER P， et al. Survey of aspectoriented analysis and design approaches， AOSDEuropeULANC9[R]. 2005.
[6] PACE J A D， CAMPO M R. Analyzing the role of aspects in software design[J].Communications of the ACM，2001， 44 (10):6673.
[7] 巴拉赫，蘭寶.UML面向對象建模與設計[M].車皓陽，揚眉，譯.北京：人民郵電出版社，2006.
[8] [EB/OL].(2004).http:// www.sparxsystems.com.au.
[9][EB/OL].(2006).http://www.itisedu.com/phrase/200604161240175. html.
[10]JACOBSON I. Use cases and aspectsworking seamlessly together[J]. Chair of Software Engineering，2003， 2 (4):818.
[11] BHOLE M， LIEBERHERR K. Use case modularity using aspect oritented programming[EB/OL]. http://www.ccs.neu.deu/home/manali/Use Case Modularityusing AOP.pdf.
[12] IEEE Std 1471-2000， IEEE recommended practice for architectural description of softwareintensive system[S]. [S.l.]: Institute of Electronics Engineers， 2000.
