如何選擇合適的軟體體系結構設計方法

A. 設計軟體系統結構的具體辦法有哪些

結構化程序設計的思路是：自頂向下、逐步求精；其程序結構是按功能劃分為若干個基本模塊；各模塊之間的關系盡可能簡單，在功能上相對獨立；每一模塊內部均是由順序、選擇和循環三種基本結構組成；其模塊化實現的具體方法是使用子程序。結構化程序設計由於採用了模塊分解與功能抽象，自頂向下、分而治之的方法，從而有效地將一個較復雜的程序系統設計任務分解成許多易於控制和處理的子任務，便於開發和維護。 雖然結構化程序設計方法具有很多的優點，但它仍是一種面向過程的程序設計方法，它把數據和處理數據的過程分離為相互獨立的實體。當數據結構改變時，所有相關的處理過程都要進行相應的修改，每一種相對於老問題的新方法都要帶來額外的開銷，程序的可重用性差。由於圖形用戶界面的應用，程序運行由順序運行演變為事件驅動，使得軟體使用起來越來越方便，但開發起來卻越來越困難，對這種軟體的功能很難用過程來描述和實現，使用面向過程的方法來開發和維護都將非常困難

B. 在產品設計時，如何選擇合適的軟體進行設計

數據的邏輯結構、存儲結構和操作（特別是基本操作）的實現這三者是密切相關的。一般地，在選擇（或設計）數據結構時應該完成以下三步：
⑴ 確定表示問題所需的數據及其特性；
⑵ 確定必須支持的基本操作，並度量每種操作所受的時、空資源限制；
⑶ 選擇（或設計）最接近這些開銷的數據結構。

C. 軟體設計化結構包括哪些設計方法

1數據流的類型

在需求分析階段，用SA方法產生了數據流圖。結構化的設計能方便地將數據流圖（DataFlowDiagram，DFD）轉換成軟體結構圖。DFD中從系統的輸入數據流到系統的輸出數據流的一連串連續變換形成了一條信息流。根據數據流類型不同，可分為變換型和事務型2類，事務型和變換型數據流的設計步驟基本是大同小異，它們之間主要差別就是從數據流圖到軟體結構的映射方法不同。因此，在進行軟體結構設計時，首先對數據流圖進行分析，然後判斷屬於那一種類型，根據不同的數據流類型，通過一系列映射，把數據流程圖轉換為軟體結構圖。基本流程見圖1.

1.1變換型數據流

信息在沿著輸入通路進入系統，同時由外部形式變換成內部形式進入系統的信息，通過變換中心經加工處理，以後再沿著輸出通路變換成外部形式離開系統。當數據流具有了信息流的這種特徵時這種信息流就叫作變換型數據流。變換型數據流的DFD可明顯地分為三大部分：邏輯輸入、變換中心（主加工）、邏輯輸出。變換型數據流結構見圖2.邏輯輸入：可以從數據流圖上的物理輸入開始，一步一步向系統中間移動，一直到數據流不再被看作是系統的輸入為止，則其前一個數據流就是系統的邏輯輸入。可以認為邏輯輸入就是離物理輸入端最遠的，且仍被看作是系統輸入的數據流。變換中心：多股數據流匯集的地方往往是系統的中心變換部分。
邏輯輸出：從物理輸出端開始，一步一步地向系統中間移動，就可以找到離物理輸出端最遠，且仍被看作是系統輸出的數據流。
圖片 [轉到圖文版]
圖1數據流程圖轉換為軟體結構圖基本流程
圖片 [轉到圖文版]
圖2變換型數據流結構

1.2事務型數據流

信息在沿著輸入通路進入系統，由外部形成內部形式後到達事務中心。通常事務中心位於幾條處理路徑的起點，從數據流程圖上很容易標識出來，因為事務處理中心一般會有「發射中心」的特徵。因為事務流有明顯的事務中心，所以各式各樣活動流都以事務中心為起點呈輻射狀流出。事務型數據流結構見圖3.
圖片 [轉到圖文版]
圖3事務型數據流結構

事務中心主要完成下述任務：接收輸入數據（輸入數據又稱為事務）；分析每個事務以確定它的類型；根據事務類型選取一條活動通路。通常，事務中心前面的部分叫作接收路徑，發射中心後面各條發散路徑叫作事務處理路徑。對於每條處理路徑來講，還應該確定它們自己的流特徵。
2映射過程

任何一個設計過程都不是統一、固定不變的，設計的要求越高，往往需要設計者在方法上不但具有超強的判斷能力還要有規則性的創造精神。根據不同類型，分析其映射過程。
2.1變換型數據流到軟體結構圖映射

（1）設計軟體結構的頂層和第1層。設計一個主模塊，並用系統的名字為它命名，作為系統的頂層。第1層為每個邏輯輸入設計一個輸入模塊，它的功能是為主模塊提供數據；為每一個邏輯輸出設計一個輸出模塊，它的功能是將主模塊提供的數據輸出；為中心變換設計一個變換模塊，它的功能是將邏輯輸入轉換成邏輯輸出。主模塊控制和協調第1層的輸入模塊、變換模塊和輸出模塊的工作。
（2）設計軟體結構的下層結構。每個邏輯輸入模塊有2個下屬模塊：一個接收數據；另一個把數據變換成上級模塊所需要的數據格式。而接收數據模塊又是輸入模塊，又要重復上述工作。如此循環下去，直到輸入模塊已經涉及到物理輸入端為止。同樣，每個邏輯輸出模塊有2個下屬模塊：一個是將上級模塊提供的數據變換成輸出的形式；另一個是將它們輸出。對於每一個邏輯輸出，在數據流程圖上向物理輸出端方向移動，遇到物理輸出為止。設計中心變換模塊的下層模塊沒有通用的方法，一般應參照數據流程圖的中心變換部分和功能分解的原則來考慮如何對中心變換模塊進行分解。
變換型數據流轉換後的初始軟體結構圖見圖4.
圖片 [轉到圖文版]
圖4變換型數據流轉換後的初始軟體結構圖

2.2事務型數據流到軟體結構圖映射

事務型數據處理問題的工作機理是接受一項事務，根據事務處理的特點和性質，選擇分派一個適當的處理單元，然後給出結果。
（1）設計軟體結構的頂層和第1層。軟體結構圖的頂層是系統的事務控制模塊。第1層是由事務流輸入分支和事務分類處理分支映射得到的程序結構。也就是說，第1層通常是由兩部分組成：取得事務和處理事務。
（2）設計軟體結構的下層結構。設計事務流輸入分支的方法與變換分析中輸入流的設計方法類似，從事務中心變換開始，沿輸入路徑向物理輸入端移動。每個接收數據模塊的功能是向調用它的上級模塊提供數據，它需要有兩個下屬模塊：一個接收數據；另一個把這些數據變換成它的上級模塊所需要的數據格式。接收數據模塊又是輸入模塊，也要重復上述工作。如此循環下去，直到輸入模塊已經涉及到物理輸入端為止。
事務處理分支結構映射成一個分類控制模塊，它控制下層的處理模塊。對每個事務建立一個事務處理模塊。如果發現在系統中有類似的事務，就可以把這些

D. 如何選擇合適的軟體體系結構設計方法

（1）軟體體系結構的多視圖建模
通過邏輯視圖，開發視圖、進程視圖、物理視圖、進程來描述的軟體體系結構。
（2）基於評估與轉換的軟體體系結構設計
通過迭代的開發方式，直至滿足客戶的需求。
（3）模式驅動的軟體體系結構設計
通過總結、記錄、復用來實現的體系結構設計
（4）領域特定的軟體體系結構設計
借鑒領域中已經成熟的軟體體系結構來實現解決方案在某個領域內的復用。
（5）軟體產品線方法
軟體復用發展的一個更高階段，它並不僅僅局限於以前人們在軟體復用中考慮的對函
數、模塊、類、體系結構甚至子系統的復用。
（6）其於目標推理的軟體體系結構設計方法
功能需求和非功能需求皆被表達為要達到的目標。
（7）其於屬性的軟體體系結構設計方法
基於目標圖推理的體系結構設計方法、基於屬性的體系結構設計方法。
開發心得：
在這些具有系統化過程的軟體開發方法中，體系結構設計師一個不可避免
的過程，它們也都有自己的一些設計方式。但這並不排斥前面講到的軟體體系結構設計
方法，反之，如果能把這些體系結構設計方法與開發方法學結合起來，將能起到更好的
效果。

E. 如何進行軟體架構設計

軟體架構設計的幾個步驟 1、分析需求和理解業務模型（或領域建模），並選定關鍵Use case。 軟體的需求，可以分為從用戶視角和開發人員視角來看，從用戶的角度看，又可以分為功能性和非功能性需求，我們必須從不同的視角和級別去全面的認識需求並分析需求，理解業務模型。實踐表明，常常被我們忽視的非功能性需求常常會導致整個項目失敗。 理解業務需求最好的方式莫過於進行領域建模，領域建模與需求分析往往是交替穿叉進行的，領域建模主要有以下三個方面的作用： ◆探索復雜問題，弄清領域知識。Martin Fowler曾經說過，他採用面向對象方法最大的好處就是它有助於解決更為復雜的問題。領域建模本身作為輔助思維的工具，幫助我們將注意力始終保持在最為重要的業務概念及其關繫上，使我們能夠不斷深入地，系統的對需求進行分析和認識。領域建模往往是一個從模糊到清晰，從零散到系統的過程。 ◆決定功能范圍，影響可擴展性。任何模型都是對現實世界某種程序的抽象，這種抽象就會忽略某一些東西，例如忽略對象的屬性和對象間的關系，而這些忽略往往都是帶有一定的目的性的，這種忽略就決定了功能的范圍。模型揭示了各種功能背後的結構，如果說定義功能相當於「拍照片」的話，那麼領域建模就相當於「做透視」，更加關注問題領域的內在結構，相當於對問題領域進行了一定的抽象，良好的領域模型不僅能很好的支持現有的功能，而且還可以在一定程度上支持未來可能出現的新需求，體現良好的可擴展性。 ◆提供交流基礎，促進有效溝通。領域建模通常會使用UML圖作為呈現的方式，這樣為我們的溝通提供了方便。當然，有時候文字在描述某些特定領域的問題時可能更適合，可以靈活運用。 在我們公司的實際軟體開發流程中，往往領域建模缺少這一環節，這可能是在以後的工作中需要進一步提高之處。 雖然我們總是期望架構設計師能全面掌握需求，但由於時間和精力的限制，擺在我們面前的現實就是架構設計師沒有時間對所有需求進行深入分析，所以我們的策略就是「把好鋼用在刀刃上」，即把大部分時間和精力花在對決定架構最重要的關鍵需求上。在選擇關鍵需求時要注意：高優先順序的需求往往是從用戶的角度來看的，可能並不是真正的關鍵需求。在《RUP實踐者指南》一書中向我們講述了如何確定關鍵功能需求？A.作為應用程序的核心或實現了系統的主要介面的功能，B.必須被實現的功能，即如果這些功能不被實現，則開發出來的軟體就失去了價值，C.覆蓋了系統架構的一些方面，但沒有被其他重要的Use case覆蓋到的功能。 2、分別從各個視角來考慮軟體架構的方方面面。 軟體的架構設計必須考慮到各方面，根據前期工作確立的領域模型，關鍵需求，系統約束等進行設計，必須從系統用戶，開發人員，系統管理員，部署管理員，數據管理員等人員的角度去分析並解決問題。比如說，如果我們的運行架構採用Cluster方式時，就必須小心Cache和Session等的使用；如果我們的業務邏輯要求我們要操作多個資料庫時，就要考慮採用支持二階段事務提交的方式。 只有將這些方方面面的問題都考慮到了，這樣的架構設計才是完整的。至於每一個視圖中，我們應該設計到什麼細節這一問題，實際上與整個項目的過程定義有關。例如，如果我們有專門安排資料庫概要設計的活動，那我們在架構設計的過程中就可以只需要關注更高層次的資料庫特性及資料庫之間的關系，而每一張表的數據字典可以在後續的相關活動中進行設計，但如果沒有這樣的活動，那我們就要細化到每一張表的每一個欄位，以及表之間的關系。 3、解決技術面的重點問題和難題 在軟體架構設計的過程中，我們往往會需要攻克一些技術面的重點問題和難題，這完全是一項極其需要扎實的理論知識和豐富的實踐經驗支撐的工作。例如，我們如何提高整個系統的性能？如何能很好的導出極其復雜的「中國式報表」（一般比西方國家產出的報表要復雜很多，而且很多開源的BI類的框架並不能完全解決問題）？ 當遇到確實是很困難的問題，可以去網路一下或Google一下，也可以去請教公司的資深技術人員或專家，或者召開小范圍的技術專題討論會議，採用腦力激盪的方法試著找找答案，這樣才能提高工作的效率。 4、召開架構設計評審會議進行同行評審。 架構設計評審是極其重要的一環，我曾將其形容為「七種武器」中的離別鉤，就是因為在會議上，同行們可能會提很多問題或意見，而且很多意見很尖銳，所以一定要虛心接受，並做好記錄，正所謂「良葯苦口利於病，忠言逆耳利於行」。 在評審會議之前，我們要完成很多准備工作，最好是能准備一份簡明扼要的電子簡報，把最重要的問題列出來，這樣在進行評審會議時，就不會漫無目的，在會議前就將這些資料發給與會人員，請他們抽空先了解一下，在會議進行時，要學會控制會議的進度，提高會議的效率。 5、針對關鍵Use case在設計的架構上實現功能來驗證架構。 對於架構設計的驗證也是一項十分重要的工作，其驗證技術有很多種，在我們公司通常會採用Sample的形式，即XP中所說的迭代0，RUP中所說的切片。這樣做的好處是既可以從實際的產品角度出發來有效的驗證架構是否滿足要求，又可以比拋棄型原型驗證技術節省成本。 這個Sample絕不是我們在解決架構設計中的問題時拿來做實驗的一些代碼的拼湊，而是完整的實現某一關鍵Use case的符合架構設計和一系列規范的可交付的代碼及相關文檔。同時，這個Sample可以作為你在給大家講解或培訓架構時的教材，也可以作為開發人員使用此架構進行開發的藍本，甚至是只需要復制粘貼，加上簡單的修改即可。 6、交付給客戶Review。 這一環節，在很多公司可能並不存在，因為他們的軟體架構並不一定需要客戶Review，但像我們這種做服務的公司，最重要的就是客尊，落實到軟體架構設計這一活動，就是讓客戶理解並接受你的架構設計方案，同時，客戶也會起到幫你驗證架構的作用。通常，我們的架構得到客戶的認可後，便可進入大規模的開發。 在交付給客戶Review時，通常

F. 如何設計軟體系統框架結構,功能模塊,和資料庫

摘要 數據結構 數據結構指的是數據之間的相互關系，即數據的組織形式。數據結構是計算機存儲、組織數據的 方式。數據結構是指相互之間存在一 種或多種特定關系的數據元素的集合 。通常情況下，精心選擇的數據結構 可以帶來更高的運行或者存儲效率。 數據結構往往同高效的檢索演算法和索 引技術有關。 我們把數據結構設計、資料庫設計、甚至數據文件設計等統一稱為數據模型設計。 在數據模型設計中有一個重要概念：持久數據操作，它包括寫入、查詢、更新和刪除四類基本操作以及由它們復合而成的業務數據操作。 在很多軟體系統中，數據是其核心，因此，對數據元素的格式、結構、訪存、表示等機制進行良好建模和優化，是提高軟體設計質量和系統性能的基礎，對軟體系統的應用具有重要意義。 面向組件設計

G. 如何進行基於軟體體系結構的軟體設計

MVC是當前流行的Web應用設計框架的實施標准，是軟體工程中的一種軟體架構模式[ ]。它把軟體系統分為三個基本部分:模型(Model)、視圖(View)和控制器(Controller)，目的是實現一種動態和可持續的程序設計，使後續對程序的修改和擴展簡化，並且使程序某一部分的代碼或功能重復利用成為可能。 在這種設計結構下，一個應用被分為三個部分：model、view和controller，每個部分負責不同的功能。根據用戶界面（view）的操作完成對程序數據（model）的更新。將程序數據（model）改變及時反應到用戶界面（view）上。也就是完成兩個方向的動作。

H. 如何進行系統的架構設計

如何進行系統的架構設計

一個軟體項目在需求確定後，就可以開始系統的架構設計了。架構設計不同於編寫代碼，需要遵循嚴格的語法和編程規范。它沒有規范可遵循，存在即合理，適合系統開發和運行的架構就是最合理的系統架構。

系統的架構設計是在業務需求已經清晰的前提下進行的，假定在系統需求分析階段已經確定了系統的功能和業務范圍，也明確了系統運營需求。在上述需求還沒有確定的情況下，不適宜開展系統的架構設計，需要回到需求分析階段完善上述需求後再開展系統的架構設計。

系統架構就是一些模型圖，模型圖是人們用來理解系統和溝通的工具。這些模型圖需要提供給系統相關干係人來理解系統，系統相關干係人有項目經理、產品經理、開發人員、系統運營維護人員、客戶、項目投資人等。這些干係人有不同的知識背景，對同一架構模型圖也會有不同的認知和理解：如果把開發架構模型圖給產品經理或客戶看，他們定然看不懂也不能理解；同樣的道理，如果只把邏輯架構圖給開發人員看，就不能正確地指導開發人員構建開發環境。

因此架構設計師在進行系統架構設計時，需要從系統的不同維度進行設計，以滿足系統相關干係人理解系統架構的需求。架構設計模型主要有邏輯架構、開發架構、數據架構、物理架構和運行架構五種模型圖。一般來說需要設計的系統架構模型有邏輯架構、開發架構和物理架構三種架構模型圖。數據架構模型一般放在資料庫中進行設計，運行架構和物理架構基本相近，只是在物理架構中加了數據的流向，因此一些系統設計使用物理架構代替了運行架構。

設計邏輯架構模型

邏輯架構模型主要是確定系統的功能范圍和系統劃分。在設計邏輯架構模型時，可以抓住兩個關鍵點：一個關鍵點是對系統進行邏輯劃分，將一個大系統劃分為多個子系統；另外一個關鍵點是明確各子系統之間的協作和調用關系。

繪制邏輯架構的模型圖有系統流程圖和系統結構圖：系統流程圖描述了系統各子系統、相關文件和數據之間的關系，記錄了整個系統的體系結構；系統結構圖也稱為層次圖，它以層次方式描述了系統從頂層到最底層的功能分解。

下圖分別是人脈系統的系統流程圖和系統結構圖。

上面的人脈系統流程圖和人脈系統結構圖就是依據人脈系統需求規格說明書給出的功能和業務范圍繪制的。

設計開發架構模型

開發架構模型圖是給開發人員看的，開發架構模型指導開發人員如何來架構系統的開發環境。開發環境包括系統開發框架的選型、開發工具和編程語言、模塊劃分等內容。下圖是人脈系統開發架構模型圖。

開發架構模型圖給出了技術體系是B/S結構，開發框架選擇SSM，開發語言是JavaEE。系統採用三層結構，分別是表示層、WEB應用層和數據層。表現層是JSP頁面，在瀏覽器中運行，表現層是MVC的View。WEB應用層的控制層是MVC的Controller，業務邏輯層是MVC的Service，實體層是MVC的POJO。數據層由MyBaits資料庫開發框架組成。

設計物理架構模型

物理架構模型是給系統部署人員和運營維護人員看的，主要給出系統的部署環境模型，包括網路環境、硬體環境和軟體環境。下圖是系統部署網路環境模型圖。

從上面網路環境模型圖中可以看出，系統部署只需要一台主機，要求支持HTTP協議和遠程桌面協議。系統可以考慮部署到阿里雲或騰訊雲。

系統的架構設計主要涉及到三種模型圖，分別是邏輯架構模型、開發架構模型和物理架構模型。邏輯架構模型一般採用系統流程圖和系統結構圖建模；開發架構模型沒有標準的模型圖，可以使用PPT或Visio繪圖工具進行繪制；物理架構模型主要是由網路環境、硬體和軟體環境組成。

I. 幾種常見的軟體體系結構及特點分析

20世紀60年代的軟體危機使得人們開始重視軟體工程的研究。起初，人們把軟體設計的重點放在數據結構和演算法的選擇上，然而隨著軟體系統規模越來越大，對總體的系統結構設計和規格說明變得異常重要。隨著軟體危機程度的加劇，軟體體系結構(software architecture)這一概念應運而生。軟體體系結構著眼於軟體系統的全局組織形式，在較高層次上把握系統各部分之間的內在聯系，將軟體開發的焦點從成百上千的代碼上轉移到粒度較大的體系結構元素及其交互的設計上。與傳統軟體技術相比，軟體體系結構理論的提出不僅有利於解決軟體系統日益增加的規模和復雜度的問題，有利於構件的重用，也有利於軟體生產率的提高。面向方面軟體開發(AOSD)認為系統是由核心關注點(corn concern)和橫切關注點(cross-cutting concern)有機地交織在一起而形成的。核心關注點是軟體要實現的主要功能和目標，橫切關注點是那些與核心關注點之間有橫切作用的關注點，如系統日誌、事務處理和許可權驗證等。AOSD通過分離系統的橫切關注點和核心關注點，使得系統的設計和維護變得容易很多。
Extremara大學的Navasa等人［1］在2002年提出了將面向方面軟體開發技術引入到軟體體系結構的設計中，稱之為面向方面軟體體系結構(aspect oriented software architecture，AO-SA)，這樣能夠結合兩者的優點，但是並沒有給出構建面向方面軟體體系結構的詳細方法。
盡管目前對於面向方面軟體體系結構這個概念尚未形成統一的認識，但是一般認為面向方面軟體體系結構在傳統軟體體系結構基礎上增加了方面構件(aspect component)這一新的構成單元，通過方面構件來封裝系統的橫切關注點。目前國內外對於面向方面軟體體系模型的研究還相對較少，對它的構成單元模型的研究更少，通常只關注方面構件這一構成單元。方面構件最早是由Lieberherr等人［2］提出的，它是在自適應可插拔構件(adaptive plug and play component，APPC)基礎之上通過引入面向方面編程(AOP)思想擴展一個可更改的介面而形成的，但它關於請求介面和服務介面的定義很模糊，未能給出一個清晰的方面構件模型。Pawlak等人［3］提出了一個面向方面的框架，該框架主要包含了一個方面構件模型———Java方面構件(Java aspect component，JAC)，但該方面構件模型僅包含了切點(pointcut)，並把AOP中裝備(advice)集成到了切點的表達式中，它主要從實現的角度進行了闡述，並沒有給出詳細的方面構件模型。本文沒有隻關注面向方面軟體體系結構中方面構件這一構成單元模型，還詳細分析了它的另外兩個構成單元，即構件和連接件，因為面向方面軟體體系結構各部分之間是相互關聯的。
1面向方面軟體體系結構相關概念
面向方面軟體體系結構涉及諸多概念，以下將分別介紹。軟體體系結構在軟體工程領域有著廣泛的影響，但當前仍未形成一個統一的、標準的定義。目前國內外普遍認可的看法是軟體體系結構包含構件、連接件和約束［4］。其中約束描述了體系結構配置和拓撲的要求，確定了體系結構的構件與連接件的連接關系。這樣就可以把軟體體系結構寫成
軟體體系結構(software architecture)=構件(components)+
連接件(connectors)+約束(constraints)
構件是軟體體系結構的基本元素之一。一般認為，構件是指具有一定功能、可明確辨識的軟體單位，並且具備語義完整、語法正確、有可重用價值的特點，然而目前對於構件的具體結構及構成並沒有一個統一的標准［5］，而且一些主要的構件技術也沒有使用相同的構件類型。另外，當前被廣泛接受的構件定義並不包含具體的軟體構件模型(software component model)。例如，Szyperski等人［6］給出了軟體構件一個很有名的定義:軟體構件是一個僅帶特定契約介面和顯式語境依賴的結構單位，它可以獨立部署，易於第三方整合。但是關於軟體構件模型有一個被普遍接受的觀點是:軟體構件是一個具有服務提供和服務請求功能的軟體單元［7］。
連接件是軟體體系結構另一個基本的構成元素，是用來建立構件間交互以及支配這些交互規則的構造模塊。連接件最先是由Shaw［8］提出來的，她建議把連接件作為軟體體系結構中第一類實體，用來表示普通構件之間的交互關系。目前對於連接件尚未形成統一的認識，盡管在軟體體系結構中強調了連接件存在的必要性，但是關於連接件模型的研究還很少，連接件的實際應用還不成熟。
面向方面軟體體系結構在傳統軟體體系結構的基礎上增加了方面構件單元。通常認為，方面構件是封裝了系統橫切關注點的一類特殊的構件。目前關於方面構件模型的研究還處於起步階段。
2面向方面軟體體系結構模型
由於傳統軟體體系結構模型包含構件、連接件和約束，而面向方面軟體體系結構是在傳統軟體體系結構的基礎之上擴展了方面構件，所以面向方面軟體體系模型結構包含構件、連接件、方面構件和約束。其中約束描述了面向方面體系結構配置和拓撲的要求，確定了體系結構的構件、連接件和方面構件之間的連接關系，而構件、連接件、方面構件是它的三個基本的構成單元。以下對這三個構成單元的模型進行詳細的設計。