一、軟件架構(gòu)設(shè)計(jì)

軟件或計(jì)算機(jī)系統(tǒng)的軟件架構(gòu)是該系統(tǒng)的一個(gè)（或多個(gè)）結(jié)構(gòu)，而結(jié)構(gòu)由軟件元素、元素的外部可見(jiàn)屬性及它們之間的關(guān)系組成。

軟件系統(tǒng)架構(gòu)是關(guān)于軟件系統(tǒng)的結(jié)構(gòu)、行為和屬性的高級(jí)抽象。指定了軟件系統(tǒng)的組織結(jié)構(gòu)和拓?fù)浣Y(jié)構(gòu)。

軟件架構(gòu)是可傳遞可復(fù)用的模型，架構(gòu)就是體系結(jié)構(gòu)。架構(gòu)設(shè)計(jì)介于需求分析和軟件設(shè)計(jì)之間。架構(gòu)設(shè)計(jì)就是需求分配，即滿足，需求的職責(zé)分配到組件上。

軟件架構(gòu)設(shè)計(jì)是降低成本、改進(jìn)質(zhì)量、按時(shí)和按需交付產(chǎn)品的關(guān)鍵因素。架構(gòu)設(shè)計(jì)能夠滿足系統(tǒng)的性能、可維護(hù)性等品質(zhì)；能夠使得不同的利益相關(guān)人（stakeholders）達(dá)成一致的目標(biāo)；能夠支持項(xiàng)目計(jì)劃和項(xiàng)目管理等活動(dòng)；能夠有效地管理復(fù)雜性；等等。然而系統(tǒng)架構(gòu)的給出必須建立在需求明確的基礎(chǔ)上。

軟件架構(gòu)能夠在設(shè)計(jì)變更相對(duì)容易的階段，考慮系統(tǒng)結(jié)構(gòu)的可選方案，便于技術(shù)人員與非技術(shù)人員就軟件設(shè)計(jì)進(jìn)行交互，能夠展現(xiàn)軟件的結(jié)構(gòu)、屬性與內(nèi)部交互關(guān)系。但是軟件架構(gòu)與用戶對(duì)系統(tǒng)的功能性需求沒(méi)有直接的對(duì)應(yīng)關(guān)系。

二、架構(gòu)的模型4+1視圖

點(diǎn)擊加載圖片

邏輯視圖：主要支持系統(tǒng)的功能需求，即系統(tǒng)提供給最終用戶的服務(wù)。（用戶關(guān)注）

開(kāi)發(fā)視圖：也稱為模塊(實(shí)現(xiàn))視圖，主要側(cè)重于軟件模塊的組織和管理。（程序員）

進(jìn)程視圖：側(cè)重于系統(tǒng)的運(yùn)行特性，主要關(guān)注一些非功能性的需求，例如系統(tǒng)的性能和可用性。（并發(fā)，集成人員）

物理視圖：主要考慮如何把軟件映射到硬件上，它通常要考慮到解決系統(tǒng)拓?fù)浣Y(jié)構(gòu)、系統(tǒng)安裝、通信等問(wèn)題。（軟件到硬件，系統(tǒng)工程人員）

場(chǎng)景：可以看作是那些重要系統(tǒng)活動(dòng)的抽象，它使四個(gè)視圖有機(jī)地聯(lián)系起來(lái)，從某種意義上說(shuō)，場(chǎng)景是最重要的需求抽象。（用例圖）

邏輯視圖和開(kāi)發(fā)視圖描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，而進(jìn)程視圖和物理視圖描述系統(tǒng)的動(dòng)態(tài)結(jié)構(gòu)。

三、軟件架構(gòu)風(fēng)格

軟件架構(gòu)風(fēng)格是描述特定軟件系統(tǒng)組織方式的慣用模式。組織方式描述了系統(tǒng)的組成構(gòu)件和這些構(gòu)件的組織方式；慣用模式則反映眾多系統(tǒng)共有的結(jié)構(gòu)和語(yǔ)義特性。強(qiáng)調(diào)對(duì)軟件設(shè)計(jì)的重用。

架構(gòu)風(fēng)格定義一個(gè)系統(tǒng)家族，即一個(gè)架構(gòu)定義一個(gè)詞匯表和一組約束。詞匯表中包含一些構(gòu)件和連接件類型，而這組約束指出系統(tǒng)是如何將這些構(gòu)件和連接件組合起來(lái)的。架構(gòu)風(fēng)格反映了領(lǐng)域中眾多系統(tǒng)所共有的結(jié)構(gòu)和語(yǔ)義特性，并指導(dǎo)如何將各個(gè)模塊和子系統(tǒng)有效地組織成一個(gè)完整的系統(tǒng)。對(duì)軟件架構(gòu)風(fēng)格的研究和實(shí)踐促進(jìn)對(duì)設(shè)計(jì)的重用，一些經(jīng)過(guò)實(shí)踐證實(shí)的解決方案也可以可靠地用于解決新的問(wèn)題。例如，如果某人把系統(tǒng)描述為“客戶/服務(wù)器”模式，則不必給出設(shè)計(jì)細(xì)節(jié)，我們立刻會(huì)明白系統(tǒng)是如何組織和工作的。

1.數(shù)據(jù)流風(fēng)格

點(diǎn)擊加載圖片

批處理序列

強(qiáng)調(diào)數(shù)據(jù)作為一個(gè)整體（數(shù)據(jù)必須是完整的，以整體的方式傳遞）

管道和過(guò)濾器

每個(gè)構(gòu)件都有一組輸入和輸出,構(gòu)件讀輸入的數(shù)據(jù)流，經(jīng)過(guò)內(nèi)部處理，然后產(chǎn)生輸出數(shù)據(jù)流.(構(gòu)件–>過(guò)濾器;連接件–>管道)（數(shù)據(jù)流的形式）

2.調(diào)用/返回風(fēng)格

點(diǎn)擊加載圖片

主程序/子程序

計(jì)算構(gòu)件作為子程序協(xié)作工作,由一個(gè)主程序順序地調(diào)用這些子程序,構(gòu)件通過(guò)共享存儲(chǔ)區(qū)交換數(shù)據(jù).曾經(jīng)作為結(jié)構(gòu)化開(kāi)發(fā)方法的主要選擇，具有結(jié)構(gòu)清晰，維護(hù)方便的特點(diǎn)，缺點(diǎn)是主子程序劃分缺乏標(biāo)準(zhǔn)，較難實(shí)現(xiàn)不同設(shè)計(jì)人員間設(shè)計(jì)的子程序復(fù)用。

面向?qū)ο箫L(fēng)格

面向?qū)ο笤陬惖膶哟螌?shí)現(xiàn)高度內(nèi)聚，整個(gè)系統(tǒng)通過(guò)不同類的組合調(diào)用實(shí)現(xiàn)不同功能，便于類的復(fù)用，只是面向?qū)ο笫且粋€(gè)通用風(fēng)格，類的劃分不同設(shè)計(jì)人員設(shè)計(jì)結(jié)果有很大不同，對(duì)實(shí)際架構(gòu)設(shè)計(jì)指導(dǎo)意義不大。

層次結(jié)構(gòu)風(fēng)格

分層結(jié)構(gòu)將整個(gè)系統(tǒng)按照抽象層次不同分為多層，每個(gè)層次的程序只需要負(fù)責(zé)與相鄰的上下兩層打交道，簡(jiǎn)化了系統(tǒng)中調(diào)用關(guān)系復(fù)雜度。允許每層用不同的方法實(shí)現(xiàn)，為軟件重用提供了強(qiáng)大的支持。（二層C/S、三層C/S、MVC、MVP、MVVP、RIA富互聯(lián)網(wǎng)應(yīng)用）

3.獨(dú)立構(gòu)件風(fēng)格

點(diǎn)擊加載圖片

進(jìn)程通訊

進(jìn)程通訊架構(gòu)將系統(tǒng)建設(shè)成一個(gè)個(gè)獨(dú)立構(gòu)件，構(gòu)件間采用命名的消息傳遞來(lái)實(shí)現(xiàn)溝通與協(xié)作。

事件系統(tǒng)子風(fēng)格（隱式調(diào)用）

事件驅(qū)動(dòng)架構(gòu)風(fēng)格與進(jìn)程通訊風(fēng)格類似，也是將系統(tǒng)分各個(gè)為獨(dú)立的構(gòu)件，不同的是不同構(gòu)件間通訊不采用命名的消息，而是采用隱式調(diào)用的方式，先將一個(gè)個(gè)構(gòu)件的過(guò)程注冊(cè)到某個(gè)事件中，當(dāng)這個(gè)事件發(fā)生時(shí)，所有注冊(cè)到該事件的過(guò)程自動(dòng)被觸發(fā)執(zhí)行。這類風(fēng)格的好處是獨(dú)立構(gòu)件間耦合度進(jìn)一步降低，方便構(gòu)件修改及替換，缺點(diǎn)是觸發(fā)事件放棄了對(duì)被觸發(fā)執(zhí)行程序組的控制。

4.虛擬機(jī)風(fēng)格

點(diǎn)擊加載圖片

解釋器

具有運(yùn)行時(shí)系統(tǒng)行為(自)定義與改變能力。如專家系統(tǒng)。

基于規(guī)則的系統(tǒng)

基于規(guī)則的系統(tǒng)包括規(guī)則集、規(guī)則解釋器、規(guī)則/數(shù)據(jù)選擇器及工作內(nèi)存。（一般用在人工智能領(lǐng)域和DSS中）

5.倉(cāng)庫(kù)風(fēng)格

點(diǎn)擊加載圖片

在倉(cāng)庫(kù)風(fēng)格中，有兩種不同的構(gòu)件：中央數(shù)據(jù)結(jié)構(gòu)說(shuō)明當(dāng)前狀態(tài)，獨(dú)立構(gòu)件在中央數(shù)據(jù)存儲(chǔ)上執(zhí)行。

數(shù)據(jù)庫(kù)系統(tǒng)

構(gòu)件主要有兩大類,一個(gè)是中央共享數(shù)據(jù)源,保存當(dāng)前系統(tǒng)的數(shù)據(jù)狀態(tài),另一個(gè)是多個(gè)獨(dú)立處理元素,處理元素對(duì)數(shù)據(jù)元素進(jìn)行操作。中央數(shù)據(jù)庫(kù)管理系統(tǒng)通過(guò)自身機(jī)制如數(shù)據(jù)排它鎖，共享鎖等，實(shí)現(xiàn)數(shù)據(jù)高速訪問(wèn)，數(shù)據(jù)一致性，數(shù)據(jù)完整性。同時(shí)各獨(dú)立數(shù)據(jù)處理單元之間互相不受約束。(如編譯器，傳統(tǒng)編譯器采用批處理架構(gòu)，現(xiàn)代編譯器采用數(shù)據(jù)共享架構(gòu)風(fēng)格。分析樹(shù)是共享數(shù)據(jù)。)

超文本系統(tǒng)

主要應(yīng)用于靜態(tài)網(wǎng)頁(yè)。

黑板風(fēng)格

由一個(gè)作為全局共享數(shù)據(jù)的黑板，一個(gè)控制單元和多個(gè)知識(shí)源組成，主要應(yīng)用與專家問(wèn)題解決系統(tǒng)。通過(guò)專家知識(shí)和反饋逐步得到正確結(jié)果.(如語(yǔ)音識(shí)別)

6.閉環(huán)控制架構(gòu)

過(guò)程控制

工業(yè)中的過(guò)程控制是指以溫度、壓力、流量、液位和成分等工藝參數(shù)作為被控變量的自動(dòng)控制。過(guò)程控制也稱實(shí)時(shí)控制，是計(jì)算機(jī)及時(shí)的采集檢測(cè)數(shù)據(jù)，按最佳值迅速地對(duì)控制對(duì)象進(jìn)行自動(dòng)控制和自動(dòng)調(diào)節(jié)，如數(shù)控機(jī)床和生產(chǎn)流水線的控制等。（比如空調(diào)制冷，溫度大于設(shè)定溫度制冷，小于等于時(shí)停止，一旦大于繼續(xù)運(yùn)作）

C2

點(diǎn)擊加載圖片

通過(guò)連接件綁定在一起按照一組規(guī)則運(yùn)作的并行構(gòu)件。

構(gòu)建和連接件都有一個(gè)頂部和一個(gè)底部

構(gòu)建的頂部都要連接連接件的底部，構(gòu)建的底部都要連接連接件的頂部，構(gòu)建之間不允許直連。

一個(gè)連接進(jìn)行直接連接時(shí)，必須有其中一個(gè)的底部到另一個(gè)的頂部。

四、分層C/S架構(gòu)風(fēng)格演化

1.二層C/S

點(diǎn)擊加載圖片

二層C/S結(jié)構(gòu)為單一服務(wù)器且以局域網(wǎng)為中心，所以難以擴(kuò)展至大型企業(yè)廣域網(wǎng)或Internet；(使用范圍)

軟、硬件的組合及集成能力有限；(擴(kuò)展性)

服務(wù)器的負(fù)荷太重，難以管理大量的客戶機(jī)，系統(tǒng)的性能容易變壞；(性能)

數(shù)據(jù)安全性不好。因?yàn)?a>客戶端程序可以直接訪問(wèn)數(shù)據(jù)庫(kù)服務(wù)器，那么，在客戶端計(jì)算機(jī)上的其他程序也可想辦法訪問(wèn)數(shù)據(jù)庫(kù)服務(wù)器，從而使數(shù)據(jù)庫(kù)的安全性受到威脅。(安全)

2.三層C/S架構(gòu)

點(diǎn)擊加載圖片

表現(xiàn)層（Web層）

負(fù)責(zé)接收客戶端請(qǐng)求，向客戶端響應(yīng)結(jié)果，通常客戶端使用http協(xié)議請(qǐng)求web，web層需要接收http請(qǐng)求，完成http響應(yīng)。

表現(xiàn)層包括展示層和控制層：控制層負(fù)責(zé)接收請(qǐng)求，展示層負(fù)責(zé)結(jié)果的展示。

表現(xiàn)層依賴業(yè)務(wù)層，接收到客戶端請(qǐng)求一般會(huì)調(diào)用業(yè)務(wù)層進(jìn)行業(yè)務(wù)處理，并將處理結(jié)果響應(yīng)給客戶端。

表現(xiàn)層的設(shè)計(jì)一般都使用MVC模型。MVC是表現(xiàn)層的設(shè)計(jì)模型，和其他層沒(méi)有關(guān)系。

業(yè)務(wù)層（Service層）

它負(fù)責(zé)業(yè)務(wù)邏輯處理，和我們開(kāi)發(fā)項(xiàng)目的需求息息相關(guān)。web層依賴業(yè)務(wù)層，但是業(yè)務(wù)層不依賴Web層。

業(yè)務(wù)層在業(yè)務(wù)處理時(shí)可能會(huì)依賴持久層，如果要對(duì)數(shù)據(jù)持久化需要保證事務(wù)一致性。(事務(wù)應(yīng)該放到業(yè)務(wù)層來(lái)控制）

持久層（dao層）

負(fù)責(zé)數(shù)據(jù)持久化，包括數(shù)據(jù)層即數(shù)據(jù)庫(kù)和數(shù)據(jù)訪問(wèn)層，數(shù)據(jù)庫(kù)是對(duì)數(shù)據(jù)進(jìn)行持久化的載體，數(shù)據(jù)訪問(wèn)層是業(yè)務(wù)層和持久層交互的接口；業(yè)務(wù)層需要通過(guò)數(shù)據(jù)訪問(wèn)層將數(shù)據(jù)持久化到數(shù)據(jù)庫(kù)中。

持久層就是和數(shù)據(jù)庫(kù)交互，對(duì)數(shù)據(jù)庫(kù)表進(jìn)行增刪改査的。

優(yōu)點(diǎn):

（1）允許合理地劃分三層結(jié)構(gòu)的功能，使之在邏輯上保持相對(duì)獨(dú)立性，從而使整個(gè)系統(tǒng)的邏輯結(jié)構(gòu)更為清晰，能提高系統(tǒng)和軟件的可維護(hù)性和可擴(kuò)展性。(邏輯獨(dú)立清晰,可維護(hù)性/可擴(kuò)展性)

（2）允許更靈活有效地選用相應(yīng)的平臺(tái)和硬件系統(tǒng)，使之在處理負(fù)荷能力上與處理特性上分別適應(yīng)于結(jié)構(gòu)清晰的三層；并且這些平臺(tái)和各個(gè)組成部分可以具有良好的可升級(jí)性和開(kāi)放性。(可升級(jí)性/開(kāi)放性)

（3）三層C/S架構(gòu)中，應(yīng)用的各層可以并行開(kāi)發(fā)，各層也可以選擇各自最適合的開(kāi)發(fā)語(yǔ)言。使之能并行地而且是高效地進(jìn)行開(kāi)發(fā)，達(dá)到較高的性能價(jià)格比；對(duì)每一層的處理邏輯的開(kāi)發(fā)和維護(hù)也會(huì)更容易些。(開(kāi)發(fā)維護(hù)成本/速度/技術(shù)門檻)

（4）允許充分利用功能層有效地隔離開(kāi)表示層與數(shù)據(jù)層，未授權(quán)的用戶難以繞過(guò)功能層而利用數(shù)據(jù)庫(kù)工具或黑客手段去非法地訪問(wèn)數(shù)據(jù)層，這就為嚴(yán)格的安全管理奠定了堅(jiān)實(shí)的基礎(chǔ)；整個(gè)系統(tǒng)的管理層次也更加合理和可控制。(安全)

3.三層B/S架構(gòu)

點(diǎn)擊加載圖片

用戶在使用系統(tǒng)時(shí)，僅僅需要一個(gè)瀏覽器就可運(yùn)行全部的模塊，真正達(dá)到了“零客戶端”的功能，很容易在運(yùn)行時(shí)自動(dòng)升級(jí)。(客戶端)

基于B/S架構(gòu)的軟件，系統(tǒng)安裝、修改和維護(hù)全在服務(wù)器端解決。(服務(wù)端)

B/S架構(gòu)還提供了異種機(jī)、異種網(wǎng)、異種應(yīng)用服務(wù)的聯(lián)機(jī)、聯(lián)網(wǎng)、統(tǒng)一服務(wù)的最現(xiàn)實(shí)的開(kāi)放性基礎(chǔ)。(開(kāi)放性)

缺點(diǎn):

B/S架構(gòu)缺乏對(duì)動(dòng)態(tài)頁(yè)面的支持能力，沒(méi)有集成有效的數(shù)據(jù)庫(kù)處理功能。

B/S架構(gòu)的系統(tǒng)擴(kuò)展能力差，安全性難以控制。

采用B/S架構(gòu)的應(yīng)用系統(tǒng)，在數(shù)據(jù)查詢等響應(yīng)速度上，要遠(yuǎn)遠(yuǎn)地低于C/S架構(gòu)。(性能)

B/S架構(gòu)的數(shù)據(jù)提交一般以頁(yè)面為單位，數(shù)據(jù)的動(dòng)態(tài)交互性不強(qiáng)，不利于OLTP應(yīng)用.

五、MVC的架構(gòu)風(fēng)格

點(diǎn)擊加載圖片

MVC全名是ModelViewController，是模型(model)－視圖(view)－控制器(controller)的縮寫，它是分層架構(gòu)風(fēng)格的一種。主要解決將與UI相關(guān)的邏輯都定義在針對(duì)視圖的相關(guān)元素的事件上的問(wèn)題。

MVC中各個(gè)部分的分工與協(xié)作：

Model是對(duì)應(yīng)用狀態(tài)和業(yè)務(wù)功能的封裝，我們可以將它理解為同時(shí)包含數(shù)據(jù)和行為的領(lǐng)域模型。Model接受Controller的請(qǐng)求并完成相應(yīng)的業(yè)務(wù)處理，在狀態(tài)改變的時(shí)候向View發(fā)出相應(yīng)的通知。

View實(shí)現(xiàn)可視化界面的呈現(xiàn)并捕捉最終用戶的交互操作（例如鼠標(biāo)和鍵盤的操作）。

View捕獲到用戶交互操作后會(huì)直接轉(zhuǎn)發(fā)給Controller，后者完成相應(yīng)的UI邏輯。如果需要涉及業(yè)務(wù)功能的調(diào)用，Controller會(huì)直接調(diào)用Model。在完成UI處理后，Controller會(huì)根據(jù)需要控制原View或者創(chuàng)建新的View對(duì)用戶交互操作予以響應(yīng)。

六、MVP的架構(gòu)風(fēng)格

點(diǎn)擊加載圖片

MVP是從經(jīng)典的模式MVC演變而來(lái)，它們的基本思想有相通的地方：Controller/Presenter負(fù)責(zé)邏輯的處理，Model提供數(shù)據(jù)，View負(fù)責(zé)顯示。

當(dāng)然MVP與MVC也有一些顯著的區(qū)別，MVC模式中元素之間“混亂”的交互主要體現(xiàn)在允許View和Model直接進(jìn)行“交流”，這在MVP模式中是不允許的。在MVP中View并不直接使用Model，它們之間的通信是通過(guò)Presenter（MVC中的Controller）來(lái)進(jìn)行的，所有的交互都發(fā)生在Presenter內(nèi)部，而在MVC中View會(huì)直接從Model中讀取數(shù)據(jù)而不是通過(guò)Controller，從而避免了View和Model之間的耦合。

擴(kuò)展：

1.MVVM架構(gòu)

點(diǎn)擊加載圖片

2.富互聯(lián)網(wǎng)應(yīng)用（RIA）

點(diǎn)擊加載圖片

3.分布式架構(gòu)

客戶機(jī)/服務(wù)器系統(tǒng)開(kāi)發(fā)時(shí)可以采用不同的分布式計(jì)算架構(gòu)：

分布式表示架構(gòu)是將表示層和表示邏輯層遷移到客戶機(jī)，應(yīng)用邏輯層、數(shù)據(jù)處理層和數(shù)據(jù)層仍保留在服務(wù)器上；

分布式數(shù)據(jù)架構(gòu)是將數(shù)據(jù)層和數(shù)據(jù)處理層放置于服務(wù)器，應(yīng)用邏輯層、表示邏輯層和表示層放置于客戶機(jī)；

分布式數(shù)據(jù)和應(yīng)用架構(gòu)數(shù)據(jù)層和數(shù)據(jù)處理層放置在數(shù)據(jù)服務(wù)器上，應(yīng)用邏輯層放置在應(yīng)用服務(wù)器上，表示邏輯層和表示層放置在客戶機(jī)。

4.ANSI

在ANSI/IEEE1471-2000標(biāo)準(zhǔn)中，系統(tǒng)是為了達(dá)成利益相關(guān)人（Stakeholder）的某些使命（Mission），在特定環(huán)境（Enviroment）中構(gòu)建的。每一個(gè)系統(tǒng)都有一個(gè)架構(gòu)（Architecture）。架構(gòu)（Architecture）是對(duì)所有利益相關(guān)人的關(guān)注點(diǎn)（Concern）的響應(yīng)和回答，通過(guò)架構(gòu)描述（ArchitectureDescription）來(lái)說(shuō)明。每一個(gè)利益相關(guān)人都有各自的關(guān)注點(diǎn)。這些關(guān)注點(diǎn)是指對(duì)其重要的，與系統(tǒng)的開(kāi)發(fā)、運(yùn)營(yíng)或其他方面相關(guān)的利益。架構(gòu)描述（ArchitectureDescription）本質(zhì)上是多視圖的。每一個(gè)視圖（View）是從一個(gè)特定的視角（Viewpoint）來(lái)表述架構(gòu)的某一個(gè)獨(dú)立的方面。試圖用一個(gè)單一的視圖來(lái)覆蓋所有的關(guān)注點(diǎn)當(dāng)然是最好的，但實(shí)際上這種表述方式將很難理解。視角（Viewpoint）的選擇，基于要解決哪些利益相關(guān)人的哪些關(guān)注點(diǎn)。它決定了用來(lái)創(chuàng)建視圖的語(yǔ)言、符號(hào)和模型等，以及任何與創(chuàng)建視圖相關(guān)的建模方法或者分析技術(shù)。一個(gè)視圖（View）包括一個(gè)或者多個(gè)架構(gòu)模型（Model），一個(gè)模型也可能參與多個(gè)視圖。模型較文本的表述的好處在于，可以更容易的可視化、檢查、分析、管理和集成。

5.需求和架構(gòu)

需求和軟件架構(gòu)設(shè)計(jì)面臨的是不同的對(duì)象：一個(gè)是問(wèn)題空間；另一個(gè)是解空間。保持兩者的可追蹤性和轉(zhuǎn)換，一直是軟件工程領(lǐng)域追求的目標(biāo)。

6.架構(gòu)風(fēng)格和設(shè)計(jì)模式的區(qū)別

架構(gòu)風(fēng)格往往是從全局的角度來(lái)考慮問(wèn)題，他是一種獨(dú)立于實(shí)際問(wèn)題的通用組織結(jié)構(gòu)。例如，常用的B/S架構(gòu)，在很多不同的系統(tǒng)中，都有應(yīng)用。

而設(shè)計(jì)模式著眼于解決某一特定的局部問(wèn)題，是一種局部解決方案的應(yīng)用。例如，在很多的軟件系統(tǒng)中，創(chuàng)建對(duì)象時(shí)，希望有統(tǒng)一的機(jī)制對(duì)這些對(duì)象的創(chuàng)建進(jìn)行管理，所以出現(xiàn)了工廠模式，創(chuàng)建者模式等設(shè)計(jì)模式。比如java內(nèi)存垃圾的回收機(jī)制也做成了一種設(shè)計(jì)模式。

7.軟件架構(gòu)需求

軟件架構(gòu)需求是指用戶對(duì)目標(biāo)軟件系統(tǒng)在功能、行為、性能和設(shè)計(jì)約束等方面的期望。需求過(guò)程主要是獲取用戶需求，標(biāo)識(shí)系統(tǒng)中所要用到的構(gòu)件，并進(jìn)行架構(gòu)需求評(píng)審。其中標(biāo)識(shí)構(gòu)件又詳細(xì)分為生成類圖、對(duì)類圖進(jìn)行分組和將類打包成構(gòu)件三步。軟件架構(gòu)需求并不應(yīng)該包括設(shè)計(jì)構(gòu)件的過(guò)程。

8.面向構(gòu)件的編程（COP）

面向構(gòu)件的編程（COP）關(guān)注于如何支持建立面向構(gòu)件的解決方案。一個(gè)基于一般OOP風(fēng)格的COP定義如下（Szyperski，1995）：“面向構(gòu)件的編程需要下列基本的支持：

多態(tài)性（可替代性）；

模塊封裝性（高層次信息的隱藏）；

后期的綁定和裝載（部署獨(dú)立性）；

安全性（類型和模塊安全性）?！?/p>

系統(tǒng)構(gòu)件組裝分為三個(gè)不同的層次：定制（Customization）、集成（Integration）、擴(kuò)展（Extension）。這三個(gè)層次對(duì)應(yīng)于構(gòu)件組裝過(guò)程中的不同任務(wù)。

9.OMG接口定義語(yǔ)言IDL

IDL是一種接口定義語(yǔ)言，具體的定義會(huì)涉及到接口以及相關(guān)部分。文件包含的主要元素有：接口描述、模塊定義、類型定義、常量定義、異常、值類型。接口描述是IDL文件中最核心的內(nèi)容。

由于IDL只是一種接口定義語(yǔ)言，最終還是要落地與語(yǔ)言對(duì)接的，所以IDL的數(shù)據(jù)類型要與實(shí)現(xiàn)語(yǔ)言進(jìn)行映射。以Java為例，IDL接口映射為Java類，而該接口的操作映射為相應(yīng)的成員函數(shù)。模塊定義映射為Java語(yǔ)言中的包(Package)或C++的namespaces。

9.擴(kuò)展知識(shí)

一個(gè)軟件的架構(gòu)設(shè)計(jì)是隨著技術(shù)的不斷進(jìn)步而不斷變化的。以編譯器為例，其主流架構(gòu)經(jīng)歷了管道-過(guò)濾器到數(shù)據(jù)共享為中心的轉(zhuǎn)變過(guò)程。早期的編譯器采用管道-過(guò)濾器架構(gòu)風(fēng)格，以文本形式輸入的代碼被逐步轉(zhuǎn)化為各種形式，最終生成可執(zhí)行代碼。早期的編譯器采用管道-過(guò)濾器架構(gòu)風(fēng)格，并且大多數(shù)編譯器在詞法分析時(shí)創(chuàng)造獨(dú)立的符號(hào)表，在其后的階段會(huì)不斷修改符號(hào)表，因此符號(hào)表并不是程序數(shù)據(jù)的一部分?，F(xiàn)代的編譯器采用以數(shù)據(jù)共享為中心的架構(gòu)風(fēng)格，主要關(guān)心編譯過(guò)程中程序的中間表示?，F(xiàn)代的編譯器采用以數(shù)據(jù)共享為中心的架構(gòu)風(fēng)格，分析樹(shù)是在語(yǔ)法分析階段結(jié)束后才產(chǎn)生作為語(yǔ)義分析的輸入，分析樹(shù)是數(shù)據(jù)中心中重要的共享數(shù)據(jù)，為后續(xù)的語(yǔ)義分析提供了幫助。