第九章 軟件架構(gòu)設(shè)計

9.1 軟件架構(gòu)概述

9.1.1 軟件架構(gòu)的定義

定義1：軟件或計算機系統(tǒng)的軟件架構(gòu)是該系統(tǒng)的一個（或多個）結(jié)構(gòu)，而結(jié)構(gòu)有軟件元素、元素的外部可見屬性及他們之間的關(guān)系組成。

定義2：軟件架構(gòu)為軟件系統(tǒng)提供了一個結(jié)構(gòu)、行為和屬性的高級抽象，由構(gòu)成系統(tǒng)的元素的描述、這些元素的相互作用、指導元素集成的模式及這些模式的約束組成。

定義3：軟件架構(gòu)是指一個系統(tǒng)的基礎(chǔ)組織，它具體體現(xiàn)在：系統(tǒng)的構(gòu)件，構(gòu)建之間、構(gòu)件和環(huán)境之間的關(guān)系，以及知道其設(shè)計和煙花的原則上。

為更好的理解軟件架構(gòu)的定義，特作如下說明：

1. 架構(gòu)是對系統(tǒng)的抽象，它通過描述元素、元素的外部可見屬性，以及元素之間的關(guān)系來反映這種抽象。因此，僅與內(nèi)部具體實現(xiàn)有關(guān)的細節(jié)是不屬于架構(gòu)的，即定義強調(diào)元素的“外部可見”屬性。
2. 架構(gòu)有多個結(jié)構(gòu)組成，結(jié)構(gòu)是從功能角度來描述元素之間的關(guān)系的，具體的結(jié)構(gòu)傳達了架構(gòu)某方面的信息，但是個別結(jié)構(gòu)一般不能代表大型軟件架構(gòu)。
3. 任何軟件都存在架構(gòu)，但不一定有對蓋家溝的具體表述文檔。即架構(gòu)可以獨立于架構(gòu)的描述而存在。如文檔已過時，則該文檔不能反映架構(gòu)。
4. 元素及其行為的集合構(gòu)成架構(gòu)的內(nèi)容。體現(xiàn)系統(tǒng)由哪些元素組成，這些元素各有哪些功能（外部可見），以及這些元素間如何連接與互動。即在兩個方面進行抽象：在靜態(tài)方面，關(guān)注系統(tǒng)的大粒度（宏觀）總體結(jié)構(gòu)（如分層）；在動態(tài)方面，關(guān)注系統(tǒng)內(nèi)關(guān)鍵行為的共同特征。
5. 架構(gòu)具有“基礎(chǔ)”性：它通常涉及解決各類關(guān)鍵的重復(fù)問題的通用方案（復(fù)用性），以及系統(tǒng)設(shè)計中影響深遠（架構(gòu)敏感）的各類重要決策（一旦貫徹，更改的代價昂貴）。
6. 架構(gòu)隱含有“決策”，即架構(gòu)是由架構(gòu)設(shè)計師根據(jù)關(guān)鍵的功能和非功能性需求（質(zhì)量屬性即項目相關(guān)的約束）進行設(shè)計和決策的結(jié)果。不同的架構(gòu)設(shè)計師設(shè)計出來的架構(gòu)是不一樣的，為了避免架構(gòu)設(shè)計師考慮不周，重大決策應(yīng)該經(jīng)過評審。特別是架構(gòu)設(shè)計師自身的水平是一種約束。

在設(shè)計軟件架構(gòu)時也必須考慮硬件特性和網(wǎng)絡(luò)特性。架構(gòu)設(shè)計師通常將架構(gòu)的重點放在軟件部分。

1. 影響架構(gòu)的因素。軟件系統(tǒng)的項目干系人（客戶、用戶、項目經(jīng)理、程序員、測試人員、市場人員等）對軟件系統(tǒng)有不同的要求，開發(fā)組織（項目組）有不同的人員知識結(jié)構(gòu)、架構(gòu)設(shè)計師的素質(zhì)和經(jīng)驗、當前技術(shù)環(huán)境等方面都是影響架構(gòu)的因素。
   這些因素通過功能性需求、非功能性需求、約束條件及相互沖突的要求，影響架構(gòu)設(shè)計師的決策，從而影響架構(gòu)。
2. 架構(gòu)對上述諸因素具有反作用。系統(tǒng)的示范性、架構(gòu)的可復(fù)用性及團隊開發(fā)經(jīng)驗的提升，同時，成熟的系統(tǒng)將影響客戶對下一個系統(tǒng)的要求等。這種反饋機制構(gòu)成了架構(gòu)的商業(yè)周期。

9.1.2 軟件架構(gòu)的重要性

從技術(shù)角度看，軟件架構(gòu)的重要性表現(xiàn)為如下幾個方面：

1. 項目關(guān)系人之間交流的平臺。
2. 早期設(shè)計決策。從軟件生命周期來看，軟件架構(gòu)是所開發(fā)系統(tǒng)的最早設(shè)計決策的體現(xiàn)，主要表現(xiàn)為：

• 架構(gòu)明確了對系統(tǒng)實現(xiàn)的約束條件：架構(gòu)是架構(gòu)設(shè)計師對系統(tǒng)實現(xiàn)的各方面進行權(quán)衡的結(jié)果，是總體設(shè)計的體現(xiàn)，因此，在具體實現(xiàn)時必須按架構(gòu)的設(shè)計進行。
• 架構(gòu)影響著系統(tǒng)的質(zhì)量屬性。
• 架構(gòu)可以用來預(yù)測系統(tǒng)的質(zhì)量。
• 架構(gòu)為維護的決策提供依據(jù)。在架構(gòu)層次上能為日后的更改決策提供推理、判斷的依據(jù)。
• 架構(gòu)有助于原型開發(fā)。可以按照架構(gòu)構(gòu)造一個骨架系統(tǒng)。
• 借助于架構(gòu)進行成本和進度的估計。

3. 在較高層面上實現(xiàn)軟件復(fù)用。軟件架構(gòu)作為系統(tǒng)的抽象模型，可以在多個系統(tǒng)間進行傳遞（復(fù)用），特別是比較容易的應(yīng)用到具有相似質(zhì)量屬性和功能需求的系統(tǒng)中。產(chǎn)品線通?？梢怨蚕硪粋€腳骨。
4. 架構(gòu)對于開發(fā)的指導和規(guī)范意義不容忽略。

從軟件開發(fā)過程來看，如果采用傳統(tǒng)的軟件開發(fā)模型（生命周期模型），則軟件架構(gòu)的建立應(yīng)位于概要設(shè)計之前、需求分析之后。

基于架構(gòu)的軟件開發(fā)模型則明確的把整個軟件過程劃分為架構(gòu)需求、設(shè)計、文檔化、評審（評估）、實現(xiàn)、演化等6個子過程。

9.1.3 架構(gòu)的模型

軟件架構(gòu)可以歸納為5種模型：結(jié)構(gòu)模型、框架模型、動態(tài)模型、過程模型和功能模型。最常用的是結(jié)構(gòu)模型和動態(tài)模型。

1. 結(jié)構(gòu)模型。是一個最直觀、最普遍的建模方法。這種方法以加過的構(gòu)件、連接件和其他概念來刻畫結(jié)構(gòu)，并力圖通過結(jié)構(gòu)來反映系統(tǒng)的重要語義內(nèi)容，包括系統(tǒng)的配置、約束、隱含的假設(shè)條件、風格、性質(zhì)。研究結(jié)構(gòu)模型的核心是架構(gòu)描述語言。
2. 框架模型。與結(jié)構(gòu)模型類似，但它不太側(cè)重描述結(jié)構(gòu)的細節(jié)而更側(cè)重于整體的結(jié)構(gòu)。框架模型主要以一些特殊的問題為目標建立只針對和適應(yīng)該問題的結(jié)構(gòu)。
3. 動態(tài)模型。是對結(jié)構(gòu)或框架模型的補充，研究系統(tǒng)“大顆?！钡男袨樾再|(zhì)。例如，描述系統(tǒng)的重新配置或演化。動態(tài)可能指系統(tǒng)總體結(jié)構(gòu)的配置、建立或拆除通信通道或計算的過程。
4. 過程模型。研究構(gòu)造系統(tǒng)的步驟和過程。因而結(jié)構(gòu)是遵循某些過程腳本的結(jié)果。
5. 功能模型。該模型認為架構(gòu)是由一組功能構(gòu)件按層次組成，且下層向上層提供服務(wù)?？梢钥醋鍪且环N特殊的框架模型。

“4+1”的視圖模型從5個不同的側(cè)面，即邏輯視圖、進程視圖、物理視圖、開發(fā)視圖和場景來描述軟件架構(gòu)。每一個視圖只關(guān)心系統(tǒng)的一個側(cè)面，5個視圖結(jié)合在一起才能反映系統(tǒng)的軟件架構(gòu)的全部內(nèi)容。

1. 邏輯視圖：主要支持系統(tǒng)的功能需求，即系統(tǒng)提供給最終用戶的服務(wù)。在邏輯視圖中，系統(tǒng)分解成一系列的功能抽象，這些抽象主要來自問題領(lǐng)域。這種分解不僅可以用來進行功能分析，而且可以用作標識在整個系統(tǒng)的各個不同部分的通用機制和設(shè)計元素。在面向?qū)ο蠹夹g(shù)中，通過抽象、封裝和繼承，可以用對象模型來代表邏輯視圖，用類圖來描述邏輯視圖。邏輯視圖中使用的風格為面向?qū)ο蟮娘L格，邏輯視圖設(shè)計中要注意的主要問題是要保持一個單一的，內(nèi)聚的對象模型貫穿整個系統(tǒng)。
2. 進程視圖：側(cè)重于系統(tǒng)的運行特性，主要關(guān)注一些非功能性的需求，例如系統(tǒng)的性能和可用性。進程視圖強調(diào)并發(fā)性、分布性、系統(tǒng)集成性和容錯能力，以及邏輯視圖中的主要抽象的進程結(jié)構(gòu)。它也定義邏輯視圖中的各個類的操作具體是在哪一個線程中被執(zhí)行的。進程視圖可以描述成多層抽象，每個級別分別關(guān)注不同的方面。
3. 物理視圖：主要考慮如何把軟件映射到硬件上，它通常要考慮到解決系統(tǒng)拓撲結(jié)構(gòu)、系統(tǒng)安裝、通信等問題。當軟件運行于不同的節(jié)點上時，各視圖中的構(gòu)件都直接或間接的對應(yīng)于系統(tǒng)的不同節(jié)點上。因此，從軟件到節(jié)點的映射要有較高的靈活性，當環(huán)境改變時，對系統(tǒng)其它視圖的影響最小。
4. 開發(fā)視圖：也稱為模塊視圖，主要側(cè)重于軟件模塊的組織和管理。軟件可通過程序庫或子系統(tǒng)進行組織。這樣一個軟件系統(tǒng)就可以由不同的人進行開發(fā)。開發(fā)視圖要考慮軟件內(nèi)部的需求，如軟件的容易醒、軟件的重用性和通用性，要充分考慮由于具體開發(fā)工具的不同而帶來的局限性。開發(fā)視圖通過系統(tǒng)輸入輸出關(guān)系的模型圖和子系統(tǒng)圖來描述，可以在確定了軟件包含的所有元素之后描述完整的開發(fā)角度，也可以在確定每個元素之前，列出開發(fā)視圖原則。
5. 場景：可以看做是那些重要活動的抽象，它是四個視圖有機的聯(lián)系起來，從某種意義上說，場景是最重要的需求抽象。在開發(fā)架構(gòu)中，它可以幫助設(shè)計者找到架構(gòu)的構(gòu)件和它們之間的作用關(guān)系。同時，也可以用場景來分析一個特定的視圖，或描述不同視圖構(gòu)件間是如何相互作用的。場景可以用文本表示，也可以用該圖形小時。

9.2 架構(gòu)需求與軟件質(zhì)量屬性

軟件屬性包括功能屬性和質(zhì)量屬性。但是，軟件架構(gòu)師重點關(guān)注的是質(zhì)量屬性。

9.2.1 軟件質(zhì)量屬性

軟件質(zhì)量特性包括功能性、可靠性、易用性、效率、可維護性、可移植性等六個方面，每個方面都包含若干子特性。

• 功能性：適合性、準確性、互操作性、依從性、安全性；
• 可靠性：成熟性、容錯性、易恢復(fù)性；
• 易用性：易理解性、易學性、易操作性；
• 效率：時間特性、資源特性；
• 可維護性：易分析性、易改變性、穩(wěn)定性、易測試性；
• 可移植性：適應(yīng)性、易安裝性、遵循性、易替換性；

1. 運行期質(zhì)量屬性

• 性能： 指軟件系統(tǒng)及時提供相應(yīng)服務(wù)的能力。包括速度、吞吐量和持續(xù)高速性三個方面的要求。
• 安全性：指軟件系統(tǒng)同時兼顧向合法用戶提供服務(wù)，以及阻止非授權(quán)使用的能力。
• 易用性：指軟件系統(tǒng)易于被使用的程度。
• 可伸縮性：指當用戶數(shù)和數(shù)據(jù)量增加時，軟件系統(tǒng)維持高服務(wù)質(zhì)量的能力。例如，通過增加服務(wù)器來提高能力。
• 互操作性：指本軟件系統(tǒng)和其他軟件系統(tǒng)交換數(shù)據(jù)和相互調(diào)用服務(wù)的難易程度。
• 可靠性：軟件系統(tǒng)在一定的時間內(nèi)無故障運行的能力。
• 持續(xù)可用性：指系統(tǒng)長時間無故障運行的能力。與可靠性相關(guān)聯(lián)，常將其納入可靠性中。
• 魯棒性：指軟件系統(tǒng)在一些非正常情況下（如用戶進行了非法操作、相關(guān)的軟硬件系統(tǒng)發(fā)生了故障等）下仍能正常運行的能力，也稱健壯性或容錯性。

2. 開發(fā)期質(zhì)量屬性

• 易理解性：指設(shè)計被開發(fā)人員理解的難易程度。
• 可擴展性：軟件因適應(yīng)新需求或需求變化而增加新功能的能力。也稱為靈活性。
• 可重用性：指重用軟件系統(tǒng)或某一部分的難易程度。
• 可測試性：對軟件測試以證明其滿足需求規(guī)范的難易程度。
• 可維護性：當需求修改缺陷、增加功能、提供質(zhì)量屬性時，定位修改點并實施修改的難易程度。
• 可移植性：將軟件系統(tǒng)從一個運行環(huán)境轉(zhuǎn)移到另一個不同的運行環(huán)境的難易程度。

下表反映了質(zhì)量屬性之間的相互制約關(guān)系（正相關(guān)或負相關(guān)），其中“+”代表“行屬性”能促進“列屬性”；而“-”則相反。

~|性能|安全性|持續(xù)可用性|可互操作性|可靠性|魯棒性|易用性|可測試性|可重用性|可維護性|可擴展性|可移植性
---|---
性能||||-|-|-|-|-||-|-|-
安全性|-|||-|||-|-|-
持續(xù)可用性|||||+|+
可互操作性|-|-|||||||||+|+
可靠性|-||+|||+|+|+||+|+
魯棒性|-||+||+||+
易用性|-|||||+||-
可測試性|-||+||+||+|||+|+
可重用性|-|-||+|-|||+||+|+|+
可維護性|-||+||+|||+|||+
可擴展性|-|-|||+|||+||+||+
可移植性|-|||+|||-|+|+|-|+

9.2.2 6個質(zhì)量屬性及實現(xiàn)

從架構(gòu)關(guān)注點角度，將質(zhì)量屬性分為六種：可用性、可修改性、性能、安全性、可測試性、易用性。

質(zhì)量屬性場景由以下六個部分組成：

• 刺激源：生成該刺激的實體（人、計算機系統(tǒng)或其他激勵器）
• 刺激：到達系統(tǒng)時可能產(chǎn)生的影響（即需要考慮和關(guān)注的情況）
• 環(huán)境：該刺激在某條件內(nèi)發(fā)生。如系統(tǒng)可能正處于過載情況。
• 制品：系統(tǒng)中受刺激的部分（某個制品被刺激）
• 響應(yīng)：刺激到達后所采取的行動
• 響應(yīng)度量：當響應(yīng)發(fā)生時，應(yīng)能夠以某種方式對其度量，用于是否滿足需求的測試。

需要將一般的質(zhì)量屬性場景與具體的質(zhì)量屬性場景區(qū)別開來，前者是指獨立于具體系統(tǒng)、適合于任何系統(tǒng)的一般性場景；而后者是指適合于正在考慮的某個特定系統(tǒng)的場景，具體場景通常是指從一般場景中抽取特定的、面向具體系統(tǒng)的內(nèi)容。

實現(xiàn)這些質(zhì)量屬性的基本設(shè)計決策，稱為”戰(zhàn)術(shù)“，而把戰(zhàn)術(shù)的集合稱為”架構(gòu)策略“。這些架構(gòu)策略工架構(gòu)設(shè)計師選擇。

1. 可用性及其實現(xiàn)戰(zhàn)術(shù)

1. 可用性的描述

2. 可用性戰(zhàn)術(shù)

目標是阻止錯誤發(fā)展成故障，至少能夠把錯誤的影響限制在一定范圍內(nèi)，從而使修復(fù)稱為可能。戰(zhàn)術(shù)分為：錯誤檢測、錯誤恢復(fù)、錯誤預(yù)防。

1. 錯誤檢測

• 命令/響應(yīng)：一個構(gòu)件發(fā)出一個命令，并希望在預(yù)定義的時間內(nèi)收到一個來自審查構(gòu)件的響應(yīng)，例如遠程錯誤的檢測
• 心跳（計時器）：一個構(gòu)件定期發(fā)出一個信條消息，另一個構(gòu)件收聽到消息。如果未收到心跳消息，則嘉定構(gòu)件失敗，并通知錯誤糾正構(gòu)件。
• 異常：當出現(xiàn)異常時，異常處理程序開始執(zhí)行。

2. 錯誤恢復(fù)

• 表決：通過冗余構(gòu)件（或處理器）與表決器連接，構(gòu)件按相同的輸入及算法計算輸出值給表決器，由表決器按表決算法（如多數(shù)規(guī)則）確定是否有構(gòu)件出錯，表決通常用在控制系統(tǒng)中。
• 主動冗余（熱重啟、熱備份）：所有的冗余構(gòu)件都以并行的方式對事件作出相應(yīng)。它們都處在相同的狀態(tài)，但僅使用一個構(gòu)件的響應(yīng)。丟棄其余構(gòu)件的響應(yīng)。錯誤發(fā)生時通過切換的方式使用另一個構(gòu)件的響應(yīng)。
• 被動冗余（暖重啟/雙冗余/三冗余）：一個構(gòu)件（主構(gòu)件）對事件作出響應(yīng)，并通知其他構(gòu)件（備用的）必須進行的狀態(tài)更新（同步）。當錯誤發(fā)生時，備用構(gòu)件從最新同步點接替主構(gòu)件的工作。
• 備件：是計算平臺配置用于更換各種不同的故障構(gòu)件。
• 狀態(tài)再同步：主動和被動冗余戰(zhàn)術(shù)要求所恢復(fù)的構(gòu)件在重新提供服務(wù)前更新其狀態(tài)。更新方法取決于可以承受的停機時間、更新的規(guī)模以及更新的內(nèi)容多少。
• 檢查點/回滾：檢查點就是使狀態(tài)一致的同步點，它或者是定期進行，或者是對具體事件作出響應(yīng)。當在兩個檢查點之間發(fā)生故障時，則以這個一致狀態(tài)的檢查點（有快照）和之后發(fā)生的事務(wù)日志來恢復(fù)系統(tǒng)（數(shù)據(jù)庫中常使用）。

3. 錯誤預(yù)防

• 從服務(wù)中刪除：如刪除進程再重新啟動，以防止內(nèi)存泄漏導致故障的發(fā)生。
• 事務(wù)：使用事務(wù)來保證數(shù)據(jù)的一致性，即幾個相關(guān)密切的步驟，要么全成功，要不全不成功。
• 進程監(jiān)視器：通過監(jiān)視進程來處理進程的錯誤。

2. 可修改性及其實現(xiàn)戰(zhàn)術(shù)

1. 可修改性的描述

2. 可修改性戰(zhàn)術(shù)

1. 局部化修改。在設(shè)計期間為模塊分配責任，以便把預(yù)期的變更限制在一定的范圍內(nèi)，從而降低修改的成本。

• 維持語義的一致性：語義的一致性指的是模塊中責任之間的關(guān)系，是這些責任能夠協(xié)同工作，不需要過多的依賴其他模塊。耦合和內(nèi)聚指標反映一致性，應(yīng)該根據(jù)一組預(yù)期的變更來度量語義一致性。使用”抽象通用服務(wù)“（如應(yīng)用框架的使用和其他中間軟件的使用）來支持可修改性是其子戰(zhàn)術(shù)。
• 預(yù)期期望的變更：通過對變更的預(yù)估，進行預(yù)設(shè)、準備，從而使變更的影響最小。
• 泛化該模塊：使一個模塊更通用、更廣泛的功能
• 限制可能的選擇：如在更換某一模塊（如處理器）時，限制為相同家族的成員。

2. 防止連鎖反應(yīng)。由于模塊之間有各種依賴性，因此，修改會產(chǎn)生連鎖反應(yīng)。防止連鎖反應(yīng)的戰(zhàn)術(shù)如下：

• 信息隱藏：就是把某個實體的責任分解為更小的部分，并選擇哪些信息稱為公有的，哪些稱為私有的，通過接口獲得公有責任。
• 維持現(xiàn)有的接口：盡可能維持現(xiàn)有接口的穩(wěn)定性。例如通過添加接口（通過新的接口提供新的服務(wù)）可以達到這一目的。
• 限制通信路徑：限制于一個給定的模塊共享數(shù)據(jù)的模塊。這樣可以減少由于數(shù)據(jù)產(chǎn)生/使用引入的連鎖反應(yīng)。
• 仲裁者的使用：在具有依賴關(guān)系的兩個模塊之間插入一個仲裁者，以管理與該依賴相關(guān)的活動。仲裁者有很多種類型，例如：橋、調(diào)停者、代理等就是可以提供把服務(wù)的語法從一種形式轉(zhuǎn)換為另一種形式的仲裁者。

3. 推遲綁定時間。系統(tǒng)具備在運行時進行綁定并允許非開發(fā)人員進行修改（配置）。

• 運行時注冊：支持即插即用
• 配置文件：在啟動時設(shè)置參數(shù)
• 多態(tài)：在方法調(diào)用的后期綁定
• 構(gòu)件更換：允許載入時綁定

3. 性能及其實現(xiàn)戰(zhàn)術(shù)

1. 性能的描述

2. 性能戰(zhàn)術(shù)

性能與時間相關(guān)，影響事件的響應(yīng)時間有兩個基本因素：

• 資源消耗：事件到達后進入一系列的處理程序，每一步處理都要占用資源，而且在處理過程中消息在各構(gòu)件之間轉(zhuǎn)換，這些轉(zhuǎn)換也需要占用資源。
• 閉鎖時間：指對事件處理時碰到了資源爭奪、資源不可用或?qū)ζ渌嬎愕囊蕾嚨惹闆r，就產(chǎn)生了等待時間。

性能的戰(zhàn)術(shù)有如下幾種：

1. 資源需求

• 減少處理事件流所需的資源：提高計算效率（如改進算法）、減少計算開銷（如在可修改性與性能之間權(quán)衡，減少不必要的代理構(gòu)件）。
• 減少所處理事件的數(shù)量：管理事件屢，控制采樣頻率。
• 控制資源的使用：限制執(zhí)行時間（如減少迭代次數(shù)）、限制隊列大小。

2. 資源管理

• 引入并發(fā)
• 維持數(shù)據(jù)或計算的多個副本：C/S結(jié)構(gòu)中客戶機C就是計算的副本，他能減少服務(wù)器計算的壓力；高速緩存可以存放數(shù)據(jù)副本（在不同速度的存儲器之間的緩沖）。
• 增加可用資源：在成本允許時，盡量使用速度更快的處理器、內(nèi)存和網(wǎng)絡(luò)。

3. 資源仲裁
   資源仲裁戰(zhàn)術(shù)是通過如下調(diào)度策略來實現(xiàn)的

• 先進/先出FIFO
• 固定優(yōu)先級調(diào)度：先給事件分配特定的優(yōu)先級，再按優(yōu)先級高低順序分配資源。
• 動態(tài)優(yōu)先級調(diào)度：輪轉(zhuǎn)調(diào)度、時限時間最早郵線
• 靜態(tài)調(diào)度；可以離線確定調(diào)度。

4. 安全性及其實現(xiàn)戰(zhàn)術(shù)

1. 安全性的描述

2. 安全性戰(zhàn)術(shù)

包括抵抗攻擊、檢測攻擊和從攻擊中恢復(fù)。

1. 抵抗攻擊

• 對用戶進行身份驗證：包括動態(tài)密碼、一次性密碼、數(shù)字證書及生物識別碼
• 對用戶進行授權(quán)：即對用戶的訪問進行控制管理
• 維護數(shù)據(jù)的機密性：一般通過對數(shù)據(jù)和通信鏈路進行加密來實現(xiàn)
• 維護完整性：對數(shù)據(jù)添加校驗或哈希值
• 限制暴露的信息
• 限制訪問：如用防火墻，DMZ策略。

2. 檢測攻擊。一般通過“入侵檢測”系統(tǒng)進行過濾、比較通信模式與歷史基線等方法。
3. 從攻擊中恢復(fù)

• 恢復(fù)：與可用性中的戰(zhàn)術(shù)相同
• 識別攻擊者：作為審計追蹤，用于預(yù)防性或懲罰性目的。

5. 可測試性及其實現(xiàn)戰(zhàn)術(shù)

1. 可測試性的描述

2. 可測試性戰(zhàn)術(shù)

1. 輸入/輸出

• 記錄/回放：指捕獲跨接口的信息，并將其作為測試專用軟件的輸入
• 將接口與實現(xiàn)分離：允許使用實現(xiàn)的替代（模擬器）來支持各種測試目的
• 優(yōu)化訪問線路/接口：用測試工具來捕獲或賦予構(gòu)件的變量值。

2. 內(nèi)部監(jiān)控。當監(jiān)視器處于激活狀態(tài)時，記錄事件（如通過接口的信息）

6. 易用性及其實現(xiàn)戰(zhàn)術(shù)

1. 易用性的描述

2. 易用性戰(zhàn)術(shù)

1. 運行時戰(zhàn)術(shù)

• 任務(wù)的模型：維護用戶的信息，使系統(tǒng)了解用戶試圖做什么，并提供各種協(xié)助
• 用戶的模型：維護用戶的信息，例如使系統(tǒng)以用戶可以閱讀頁面的速度滾動頁面。
• 系統(tǒng)的模型：維護系統(tǒng)的信息，它確定了期望的系統(tǒng)行為，并向用戶提供反饋。

2. 設(shè)計時戰(zhàn)術(shù)。將用戶接口與應(yīng)用的其余部分分離開來，預(yù)計用戶接口會頻繁發(fā)生變化，因此，單獨維護用戶接口代碼將實現(xiàn)變更局部化。這與可修改性相關(guān)
3. 支持用戶主動操作。如支持“取消”、“撤銷”、“聚合”和“顯示多個視圖”。

9.3 軟件架構(gòu)風格

軟件架構(gòu)風格是描述某一特定應(yīng)用領(lǐng)域中系統(tǒng)組織方式的慣用模式。架構(gòu)風格定義了一個系統(tǒng)家族，即一個架構(gòu)定義一個詞匯表和一組約束。詞匯表中包含一些構(gòu)件和連接件類型，而這組約束支出系統(tǒng)是如何將這些構(gòu)件和連接件組合起來的。架構(gòu)風格反映了領(lǐng)域中眾多系統(tǒng)所共有的結(jié)構(gòu)和語義特征，并指導如何將各個模塊和子系統(tǒng)有效的組織成一個完整的系統(tǒng)。按這種方式理解，軟件架構(gòu)風格定義了用于描述系統(tǒng)的術(shù)語表和一組指導構(gòu)件系統(tǒng)的規(guī)則。

9.3.1 軟件架構(gòu)風格分類

架構(gòu)風格最關(guān)鍵的四要素內(nèi)容：提供一個詞匯表，定義一套配置規(guī)則，定義一套語義解釋原則和定義對基于這種風格的系統(tǒng)所進行的分析。通用架構(gòu)風格的分類：

1. 數(shù)據(jù)流風格：批處理序列；管道/過濾器
2. 調(diào)用/返回風格：主程序/子程序；面向?qū)ο箫L格；層次結(jié)構(gòu)
3. 獨立構(gòu)件風格：進程通信；事件系統(tǒng)
4. 虛擬機風格：解釋器；基于規(guī)則的系統(tǒng)
5. 倉庫風格：數(shù)據(jù)庫系統(tǒng)；超文本系統(tǒng)；黑板系統(tǒng)

9.3.2 數(shù)據(jù)流風格

在該結(jié)構(gòu)下，所有的數(shù)據(jù)按照流的形式在執(zhí)行過程中前進，不存在結(jié)構(gòu)的反復(fù)和重構(gòu)，數(shù)據(jù)在流水點的各個結(jié)點上被加工，最終輸出需要的結(jié)果。

1. 批處理序列

批處理風格的每一步都是獨立的，并且每一步是順序執(zhí)行的。只有當前一步處理完，后一步才能開始。數(shù)據(jù)傳送在步與步之間作為一個整體。（組件為一系列固定順序的計算單元，組件間只通過數(shù)據(jù)傳遞交互。每個處理步驟一個獨立的程序，每一步必須在前一步結(jié)束后才能開始，數(shù)據(jù)必須是完整的，以整體的方式傳遞）。

批處理的典型應(yīng)用：

1. 經(jīng)典數(shù)據(jù)處理
2. 程序開發(fā)
3. Windows下的BAT程序就是這種應(yīng)用的典型案例

2.管道和過濾器

在該軟件架構(gòu)中，每個構(gòu)件都有一組輸入和輸出，構(gòu)件讀輸入的數(shù)據(jù)流，經(jīng)過內(nèi)部處理，然后產(chǎn)生輸出流。這個過程通常通過對輸入流的變換和增量計算來完成，所以輸入被完全消費之前，輸出便產(chǎn)生了。因此，這里的構(gòu)件被稱為過濾器。這種風格的連接件就像是數(shù)據(jù)流傳輸?shù)墓艿?，將一個過濾器的輸出傳到另一個過濾器的輸入。過濾器必須是獨立的實體，不能與其他的過濾器共享數(shù)據(jù)，而且一個過濾器不知道他上游和下游的標識。一個管道/過濾器網(wǎng)絡(luò)輸出的正確性并不依賴于過濾器進行增量計算過程的順序。

一個典型是以UNIX shell編寫的程序，另一個例子是傳統(tǒng)的編譯器。

管道/過濾器風格的軟件架構(gòu)具有很多很好的特點：

1. 使得軟構(gòu)件具有良好的隱蔽性和高內(nèi)聚、低耦合的特點
2. 允許設(shè)計者將整個系統(tǒng)的輸入/輸出行為看成是多個過濾器的行為的簡單合成。
3. 支持軟件重用。只要提供適合在兩個過濾器之間傳送的數(shù)據(jù)，任何兩個過濾器都可被連接起來。
4. 系統(tǒng)維護和增強系統(tǒng)性能簡單。新的過濾器可以添加到現(xiàn)有系統(tǒng)中來；舊的可以被改進的過濾器替換掉
5. 允許對一些如吞吐量、死鎖等屬性的分析
6. 支持并行執(zhí)行。每個過濾器作為一個單獨的任務(wù)完成，因此可與其他任務(wù)并行執(zhí)行。

但是，也存在若干不利因素

1. 通常導致進程成為批處理的結(jié)構(gòu)，這是因為雖然過濾器可增量式的處理程序，但它們是獨立的，所以設(shè)計者必須將每個過濾器看成一個完整的從輸入到輸出的轉(zhuǎn)換。
2. 不適合處理交互的應(yīng)用，當需要增量的顯示改變時，這個問題尤為嚴重
3. 因為在數(shù)據(jù)傳輸上沒有通用的標準，每個過濾器都增加了解析和合成數(shù)據(jù)的工作，這樣就導致了系統(tǒng)性能下降，并增加了編寫過濾器的復(fù)雜性

3. 批處理序列風格與管道過濾器風格對比

共同點：把任務(wù)分成一系列固定順序的計算單元（組件）。組件間指通過數(shù)據(jù)傳遞交互。
區(qū)別：批處理是全部的、高潛伏性的，輸入時可隨機存取，無合作性、無交互性。而管道過濾器是遞增的，數(shù)據(jù)結(jié)果延遲小，輸入時處理局部化，有反饋、可交互。批處理強調(diào)數(shù)據(jù)在步與步之間作為一個整體，而管道過濾器無此要求。

9.2.3 調(diào)用/返回風格

1. 主程序/子程序

是結(jié)構(gòu)化時期的經(jīng)典架構(gòu)風格。這種風格一般采用單線程控制，把問題劃分為若干處理步驟，構(gòu)件即為主程序和子程序。子程序通常可合成為模塊。過程調(diào)用作為交互機制，即充當連接件。調(diào)用關(guān)系具有層次性，其語義邏輯表現(xiàn)為子程序的正確性，取決于它調(diào)用的子程序的正確性。

2. 面向?qū)ο箫L格

這種風格建立在數(shù)據(jù)抽象和面向?qū)ο蟮幕A(chǔ)上，數(shù)據(jù)的表示方法和它們的相應(yīng)操作封裝在一個抽象數(shù)據(jù)類型或?qū)ο笾小＿@種風格的構(gòu)件是對象，或是說是抽象數(shù)據(jù)類型的實例。對象是一種被稱作管理者的構(gòu)件，因為它負責保持資源的完整性。對象是通過函數(shù)和過程調(diào)用來交互的。

這種風格的兩個主要特征為：

1. 對象負責維護其表示的完整性
2. 對象的表示與其他對象而言是隱蔽的。因為一個對象對它的客戶隱藏了自己的表示，所以這些對象可以不影響它的客戶就能改變其實現(xiàn)方法。

面向?qū)ο蟮南到y(tǒng)優(yōu)點如下：

1. 因為對象對其他對象隱藏它的表示，所以可以改變一個對象的表示，而不影響其他的對象；
2. 設(shè)計者可以將一些數(shù)據(jù)存取操作的問題分解成一些交互的代理程序的集合。

存在的問題如下：

1. 為了使一個對象和另一個對象通過過程調(diào)用等進行交互，必須知道對象的標識。只要一個對象的標識改變了，就必須修改所有其他明確調(diào)用它的對象；
2. 必須修改所有顯式調(diào)用它的其他對象，并消除由此帶來的一些副作用。例如，如果A使用了對象B，C也使用了對象B，那么C對B的使用所造成的對A的影響可能是料想不到的。

3. 層次結(jié)構(gòu)風格

層次系統(tǒng)組織成一個層次結(jié)構(gòu)，每一層為上層服務(wù)，并作為下層客戶。在一些層次系統(tǒng)中，除了一些精心挑選的輸出函數(shù)外，內(nèi)部的層只對相鄰的層課件。這樣的系統(tǒng)中構(gòu)件在一些層實現(xiàn)了虛擬機（在另一些層次結(jié)構(gòu)中層是部分不透明的）。連接件通過決定層間如何交互的協(xié)議來定義，拓撲約束包括對相鄰層間的交互的約束。

這種風格支持基于可增加抽象層的設(shè)計。允許將一個復(fù)雜問題分解成一個增量步驟序列的實現(xiàn)。由于每一層最多只影響兩層，同時只要給相鄰層提供相同的接口，允許每層用不同的方法實現(xiàn)，同樣為軟件重用提供了強大的支持。

層次結(jié)構(gòu)的優(yōu)點如下：

1. 支持基于抽象程度遞增的系統(tǒng)設(shè)計，使設(shè)計者可以吧一個復(fù)雜系統(tǒng)被遞增的步驟進行分解。
2. 支持功能增強，因為每一層至多和相鄰的上下層交互，因此功能的改變最多影響相鄰的上下層
3. 支持重用。只要提供的服務(wù)接口定義不變，同一層的不同實現(xiàn)可以交互使用。這樣就可以定義一組標準的接口，而允許各種不同的實現(xiàn)方法。

層次結(jié)構(gòu)的缺點如下：

1. 并不是每個系統(tǒng)都可以很容易的劃分分層的模式，甚至幾十一個系統(tǒng)的邏輯結(jié)構(gòu)是層次化的。出于對系統(tǒng)性能的考慮，系統(tǒng)設(shè)計師不得不把一些低級或高級的功能綜合起來；
2. 很難找到一個合適的、正確的層次抽象方法。

9.3.4 獨立構(gòu)件風格

主要強調(diào)系統(tǒng)中的每個構(gòu)件都是相互獨立的個體，它們之間不直接通信，以降低耦合度，提升靈活性。

1. 進程通信架構(gòu)風格

構(gòu)件是獨立的過程，連接件是消息傳遞。這種風格的特點是構(gòu)件通常是命名過程，消息傳遞的方式可以是點到點、異步和同步方式以及遠過程調(diào)用等。

2. 事件系統(tǒng)風格

基于事件的隱式調(diào)用風格的思想是構(gòu)件不直接調(diào)用一個過程，而是觸發(fā)或廣播一個或多個事件。一同中的其他構(gòu)建中的過程在一個或多個事件中注冊，當一個事件被觸發(fā)，系統(tǒng)自動調(diào)用在這個事件中注冊的所有過程，這樣，一個事件的觸發(fā)就導致了另一模塊中的過程的調(diào)用。

從架構(gòu)上來說，這種風格的構(gòu)件是一些模塊，這些模塊既可以是一些過程，又可以是一些事件的集合。過程可以用通用的方式調(diào)用，也可以在系統(tǒng)事件中注冊一些過程，當發(fā)生這些事件時，過程被調(diào)用。

基于事件的隱式調(diào)用風格的主要特點是事件的觸發(fā)者并不知道哪些構(gòu)件會被這些事件影響，這樣不能假定構(gòu)件的處理順序，甚至不知道哪些過程會被調(diào)用。因此，許多隱式調(diào)用的系統(tǒng)也包含顯示調(diào)用作為構(gòu)件交互的補充形式。

隱式調(diào)用系統(tǒng)的主要優(yōu)點有：

1. 為軟件重用提供了強大的支持，當需要將一個構(gòu)件加入現(xiàn)存系統(tǒng)中時，只需將他注冊到系統(tǒng)的事件中
2. 為改進系統(tǒng)帶來了方便，當一個構(gòu)件代替另一個構(gòu)件時，不會影響到其他構(gòu)件的接口。

隱式調(diào)用系統(tǒng)的主要缺點：

1. 構(gòu)件放棄了對系統(tǒng)計算的控制。一個構(gòu)件觸發(fā)一個事件時，不能確定其他構(gòu)件是否會響應(yīng)它。而且即使它知道事件注冊了哪些構(gòu)件的過程，它也不能保證這些過程被調(diào)用的順序。
2. 數(shù)據(jù)交換的問題。有時數(shù)據(jù)可能被一個事件傳遞，但另一些情況下，基于事件的系統(tǒng)必須依靠一個共享的倉庫進行交互。在這些情況下，全局性能和資源管理便成了問題。
3. 既然過程的語義必須依賴于被觸發(fā)事件的上下文約束，關(guān)于正確性的推理存在問題。

9.3.5 虛擬機風格

基本思想是人為構(gòu)建一個運行環(huán)境。在這個環(huán)境之上，可以解析與運行一些自定義的一些語言，這樣來增加架構(gòu)的靈活性。

1. 解釋器

一個解釋器通常包括完成解釋工作的解釋引擎，一個包含將被解釋的代碼的存儲區(qū)，一個記錄解釋引擎當前工作狀態(tài)的數(shù)據(jù)結(jié)構(gòu)，以及一個記錄源代碼被解釋執(zhí)行進度的數(shù)據(jù)結(jié)構(gòu)。

具有解釋器風格的軟件中包含有一個虛擬機，可以仿真硬件的執(zhí)行過程和一些關(guān)鍵應(yīng)用。解釋器通常被用來建立一個虛擬機以彌合程序語義與硬件語義之間的差異，其缺點是執(zhí)行效率過低。典型的例子是專家系統(tǒng)。

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

基于規(guī)則的系統(tǒng)包括規(guī)則集、規(guī)則解釋器、規(guī)則/數(shù)據(jù)選擇器及工作內(nèi)容。

9.3.6 倉庫風格

在倉庫風格中，有兩種不同的構(gòu)件：中央數(shù)據(jù)結(jié)構(gòu)說明當前狀態(tài)，獨立構(gòu)件在中央數(shù)據(jù)存儲上執(zhí)行，倉庫與外構(gòu)件間的相互作用在系統(tǒng)中會有大的變化。

倉庫風格包含的自風格有：數(shù)據(jù)庫系統(tǒng)；超文本系統(tǒng)；黑板系統(tǒng)

數(shù)據(jù)庫系統(tǒng)構(gòu)件主要有兩大類：一個是中央共享數(shù)據(jù)源，保存當前系統(tǒng)的數(shù)據(jù)狀態(tài)；另一個是多個獨立處理元素，處理元素對數(shù)據(jù)元素進行操作。而超文本系統(tǒng)的典型代表，就是早期的靜態(tài)網(wǎng)頁。三種架構(gòu)子風格中，最復(fù)雜的是黑板系統(tǒng)。

黑板系統(tǒng)是在抽象與總結(jié)語言理解系統(tǒng)HEARSAY-11的基礎(chǔ)上產(chǎn)生的，適合于復(fù)雜的非結(jié)構(gòu)化的問題，能在求解過程中綜合運用不同知識源，使得問題的表達、組織和求解都變得比較容易。黑板系統(tǒng)是一種問題求解模型，是組織推理步驟、控制狀態(tài)數(shù)據(jù)和問題求解之領(lǐng)域知識的概念框架，它將問題的解，空間組織成一個或多個應(yīng)用相關(guān)的分級結(jié)構(gòu)，分級結(jié)構(gòu)的每一層信息由一個唯一的詞匯來描述，它代表了問題的部分解。領(lǐng)域相關(guān)的知識被分成不同知識表達方法、推理框架和控制機制的組合來實現(xiàn)，影響黑板系統(tǒng)設(shè)計的最大因素是應(yīng)用問題本身的特性，但是支撐應(yīng)用程序的黑板體系結(jié)構(gòu)有許多相似的特征和構(gòu)件。

對于特定應(yīng)用問題，黑板系統(tǒng)可通過選取各種黑板、知識源和控制模塊中的構(gòu)件來設(shè)計，也可以利用關(guān)預(yù)先定制的黑板體系結(jié)構(gòu)的編程環(huán)境。黑板系統(tǒng)的傳統(tǒng)應(yīng)用是信號處理領(lǐng)域，如語言和模式識別。另一個應(yīng)用是松耦合代理數(shù)據(jù)共享存取。

黑板系統(tǒng)主要由三個部分組成：

1. 知識源：知識源中包含獨立的、與應(yīng)用程序相關(guān)的知識，知識源之間不直接進行通信，它們之間的交互只通過黑板來完成。
2. 黑板（共享數(shù)據(jù)）：黑板數(shù)據(jù)是按照與應(yīng)用程序相關(guān)的層次來組織的解決問題的數(shù)據(jù)，知識源通過不斷地改變黑板上的數(shù)據(jù)來解決問題。
3. 控制：控制完全由黑板的狀態(tài)驅(qū)動，黑板狀態(tài)的改變決定使用的特定知識。

9.4 層次系統(tǒng)架構(gòu)風格

9.4.1 二層及三層C/S架構(gòu)風格

C/S架構(gòu)是基于資源不對等，且為實現(xiàn)共享而提出的。將應(yīng)用一分為二，服務(wù)器（后臺）負責數(shù)據(jù)管理，客戶機（前臺）完成與用戶的交互任務(wù)。

C/S軟件架構(gòu)具有強大的數(shù)據(jù)操作和事務(wù)處理能力，模型西鄉(xiāng)簡單，易于人們理解和接收，但是隨著企業(yè)規(guī)模的日益擴大，軟件的復(fù)雜程度不斷提高，傳統(tǒng)的C/S架構(gòu)存在以下幾個局限：

• 二層C/S架構(gòu)為單一服務(wù)器且以局域網(wǎng)為中心，所以很難擴展至大型企業(yè)廣域網(wǎng)或Internet
• 軟、硬件的組合及集成能力有限
• 服務(wù)器的負荷太重，難以管理大量的客戶機，系統(tǒng)的性能容易變壞
• 數(shù)據(jù)安全性能不好，因為客戶端程序可以直接訪問數(shù)據(jù)庫服務(wù)器，那么，在客戶端計算機上的其他程序也可想辦法訪問數(shù)據(jù)庫服務(wù)器，從而使數(shù)據(jù)庫的安全性受到威脅。

三層C/S架構(gòu)將應(yīng)用功能分為表示層、功能層和數(shù)據(jù)層三個部分。

表示層是應(yīng)用的用戶接口部分，它但負責用戶與應(yīng)用間的對話功能，它用于檢查用戶從鍵盤等輸入的數(shù)據(jù)，并顯示應(yīng)用輸出的接口。在變更用戶接口時，只需要改寫控制和數(shù)據(jù)檢查程序，而不影響其他兩層，檢查的內(nèi)容也只限于數(shù)據(jù)的形式和取值的范圍，不包括有關(guān)業(yè)務(wù)本身的處理邏輯。

功能層相當于應(yīng)用的本體，他是將具體的業(yè)務(wù)處理邏輯編入程序中。而處理所需的數(shù)據(jù)則要從表示層或數(shù)據(jù)層取得。表示層和功能層之間的數(shù)據(jù)交往要盡可能簡潔。

數(shù)據(jù)層就是數(shù)據(jù)庫管理系統(tǒng)，負責管理對數(shù)據(jù)庫數(shù)據(jù)的讀寫。數(shù)據(jù)庫管理系統(tǒng)必須能迅速執(zhí)行大量數(shù)據(jù)的更新和檢索。因此，一般從功能層傳送到數(shù)據(jù)層的要求大都使用SQL語言。

9.4.2 B/S架構(gòu)風格

瀏覽器/服務(wù)器風格就是上述三層應(yīng)用結(jié)構(gòu)的一種實現(xiàn)方式，其具體結(jié)構(gòu)為：瀏覽器/web服務(wù)器/數(shù)據(jù)庫服務(wù)器。

B/S架構(gòu)主要是利用不斷成熟的WWW瀏覽器技術(shù)，結(jié)合瀏覽器的多種腳本語言，用通用瀏覽器就實現(xiàn)了原來需要復(fù)雜的專用軟件才能實現(xiàn)的強大工鞥呢，并節(jié)約了開發(fā)成本。

與C/S架構(gòu)相比，B/S架構(gòu)也有不足之處，例如：

1. B/S架構(gòu)缺乏對動態(tài)頁面的支持能力，沒有集成有效的數(shù)據(jù)庫處理能力。
2. 采用B/S架構(gòu)的應(yīng)用系統(tǒng)，在數(shù)據(jù)查詢等響應(yīng)速度上，要遠遠的低于C/S架構(gòu)。
3. B/S架構(gòu)的數(shù)據(jù)提交一般是以頁面為單位，數(shù)據(jù)的動態(tài)交互性不強，不利于在線事務(wù)處理應(yīng)用

9.4.3 MVC架構(gòu)風格

全名是模型-視圖-控制器。

MVC各個部分的分工與協(xié)作是這樣的。

1. Model是對應(yīng)用狀態(tài)和業(yè)務(wù)能力的封裝，我們可以將它理解為同時包含數(shù)據(jù)和行為的領(lǐng)域模型。Model在接收Controller的請求并完成相應(yīng)的業(yè)務(wù)處理在狀態(tài)改變的時候向View發(fā)出相應(yīng)的通知。
2. View實現(xiàn)可視化界面的呈現(xiàn)并捕捉最終用戶的交互操作。
3. View捕捉到用戶交互操作后悔直接轉(zhuǎn)發(fā)給Controller，后者完成相應(yīng)的UI邏輯，如果需要涉及業(yè)務(wù)功能的調(diào)用，Controller會直接調(diào)用Model。在完成UI處理后，Controller會根據(jù)需要控制原View或創(chuàng)建新的View對用戶交互操作予以相應(yīng)。

9.4.4 MVP架構(gòu)風格

Model-View-Presenter。Model提供數(shù)據(jù)，View負責顯示，Controller/Presenter負責邏輯的處理。MVC中允許View與Model直接交流，這在MVP模式中是不允許的。它們之間的通信是通過Presenter，所有的交互都發(fā)生在Presenter內(nèi)部。

MVP的優(yōu)點包括：

1. 模型與視圖完全分離，我們可以修改視圖而不影響模型。
2. 可以更高效的使用模型，因為所有的交互都發(fā)生在一個地方——Presenter內(nèi)部。
3. 我們可以將一個Presenter用于多個視圖，而不需要改變Presenter的邏輯。
4. 如果我們將邏輯放在Presenter的中，那么我們就可以脫離用戶接口來測試這些邏輯。

MVP的缺點包括：

視圖和Presenter的交互會過于頻繁。如果Presenter過多的渲染了視圖，往往會使得他與特定視圖的聯(lián)系過于緊密，一旦視圖需要變更，那么Presenter也需要變更。

9.5 面向服務(wù)的架構(gòu)

1. W3C的定義：SOA是一種應(yīng)用程序架構(gòu)，在這種架構(gòu)中，所有功能都定義為獨立的服務(wù)，這些服務(wù)帶有定義明確的可調(diào)用接口，能夠以定義好的順序調(diào)用這些服務(wù)來形成業(yè)務(wù)流程。
2. SA的定義：服務(wù)是精確定義、封裝完善、獨立于其他服務(wù)所處環(huán)境和狀態(tài)的函數(shù)。SOA本質(zhì)上是服務(wù)的集合，服務(wù)之間彼此通信，這種通信可能是簡單的數(shù)據(jù)傳遞。也可能是兩個或更多的服務(wù)協(xié)調(diào)進行某些活動。服務(wù)之間需要某些方法進行連接。
3. Garner的定義：SOA是一種C/S架構(gòu)的軟件設(shè)計方法，應(yīng)用由服務(wù)和服務(wù)使用者組成，SOA與大多數(shù)通用的C/S架構(gòu)模型不同之處，在于它著重強調(diào)軟件的松散耦合，并使用獨立的軟件接口。

9.5.1 SOA概述

雖然基于SOA的系統(tǒng)并不排除使用OOD來夠簡單個服務(wù)，但是其整體設(shè)計卻是面向服務(wù)的。由于SOA考慮到了系統(tǒng)內(nèi)的對象，所以雖然SOA是基于對象的，但是作為一個整體，它卻不是面向?qū)ο蟮摹?/p>

SOA建立在XML等新技術(shù)的基礎(chǔ)上，通過使用基于XML的語言來描述接口，服務(wù)已經(jīng)轉(zhuǎn)到更動態(tài)且更靈活的接口系統(tǒng)中。

在SOA系統(tǒng)中，所有的功能都定義成了獨立的服務(wù)。服務(wù)之間通過交互和協(xié)調(diào)完成業(yè)務(wù)的整體邏輯。所有的服務(wù)都通過服務(wù)總線或流程管理器來連接。各服務(wù)在交互的過程中無需考慮雙方的內(nèi)部實現(xiàn)細節(jié)，以及部署在什么平臺。

1. 服務(wù)的基本結(jié)構(gòu)

服務(wù)模型的表示層從邏輯層分離出來，中間增加了服務(wù)對外的接口層。通過服務(wù)接口的標準化描述，使得服務(wù)可以提供給在任何異構(gòu)平臺或任何用戶接口使用。

2. SOA設(shè)計原則

1. 明確定義的接口。服務(wù)定義必須長時間穩(wěn)定，一旦公布，不能隨意更改；服務(wù)的定義應(yīng)盡可能明確，減少請求者的不適當使用；不要讓請求者看到服務(wù)內(nèi)部的私有數(shù)據(jù)。
2. 自包含和模塊化。服務(wù)封裝了那些在業(yè)務(wù)上穩(wěn)定的、重復(fù)出現(xiàn)的活動和構(gòu)件，實現(xiàn)服務(wù)的功能實體是完全獨立自主的，獨立進行部署、版本控制、自我管理和恢復(fù)。
3. 粗粒度。服務(wù)數(shù)量不應(yīng)該太多，依靠消息交互而不是遠程過程調(diào)用。通常消息量較大，但是服務(wù)之間的交互頻率較低。
4. 松耦合。服務(wù)請求者可見的是服務(wù)的接口，其位置、實現(xiàn)技術(shù)、當前狀態(tài)和私有數(shù)據(jù)等，對服務(wù)請求者而言是不可見的。
5. 互操作性、兼容和策略聲明。

3. 服務(wù)構(gòu)件和傳統(tǒng)構(gòu)件

服務(wù)構(gòu)件架構(gòu)SCA是基于SOA的思想描述服務(wù)之間組合和寫作的規(guī)范，它描述用于使用SOA構(gòu)建應(yīng)用程序和系統(tǒng)的模型?？梢院喕捎肧OA進行應(yīng)用程序的開發(fā)和實現(xiàn)工作。提供了構(gòu)件粗粒度構(gòu)件的機制，這些粗粒度構(gòu)件由細粒度構(gòu)件組裝而成。SCA將傳統(tǒng)中間件編程從業(yè)務(wù)邏輯中分離出來，從而使程序員避免受其復(fù)雜性的困擾。允許開發(fā)人員集中精力編寫業(yè)務(wù)邏輯，而不必將大量的時間花費在更為底層的技術(shù)實現(xiàn)上。

SCA服務(wù)構(gòu)件與傳統(tǒng)構(gòu)件的主要區(qū)別在于：服務(wù)構(gòu)件旺旺是粗粒度的，而傳統(tǒng)構(gòu)件以細粒度居多；服務(wù)構(gòu)件的接口是標準的，主要是服務(wù)描述語言接口，而傳統(tǒng)構(gòu)件常以具體API形式出現(xiàn)；服務(wù)構(gòu)件的實現(xiàn)與語言是無關(guān)的，而傳統(tǒng)構(gòu)件常綁定某種特定的語言；服務(wù)構(gòu)件可以通過構(gòu)件容器提供QoS的服務(wù)，而傳統(tǒng)構(gòu)件完全由程序代碼控制。

9.5.2 SOA的關(guān)鍵技術(shù)

1. UDDI

統(tǒng)一描述、發(fā)現(xiàn)和集成。提供一種服務(wù)發(fā)布、查找和定位的方法，是服務(wù)的信息注冊規(guī)范，以便被需要該服務(wù)的用戶發(fā)現(xiàn)和使用它。UDDI規(guī)范描述了服務(wù)的概念，同時也定義了一種編程接口。通過UDDI提供的標準接口，企業(yè)可以發(fā)布自己的服務(wù)供其他其他企業(yè)查詢和調(diào)用，也可以查詢特定服務(wù)的描述信息，并動態(tài)綁定到該服務(wù)上。

UDDI技術(shù)規(guī)范中，主要包含下面三個部分的內(nèi)容：

1. 數(shù)據(jù)模型。是一個用于描述業(yè)務(wù)組織和服務(wù)的XML Schema
2. API。十一組用于查找或發(fā)布UDDI數(shù)據(jù)的方法。基于SOAP
3. 注冊服務(wù)。是SOA中的一種基本設(shè)施，對應(yīng)著服務(wù)注冊中心的角色。

2. WSDL

Web語言描述對象是對服務(wù)進行描述的語言。有一套基于XML的語法定義。描述的重點是服務(wù)，包含服務(wù)實現(xiàn)定義和服務(wù)接口定義。

服務(wù)接口定義就是一種抽象的、可重用的定義，行業(yè)標準組織可以使用這種抽象的定義來規(guī)定一些標準的服務(wù)類型，服務(wù)實現(xiàn)者可以根據(jù)這些標準定義實現(xiàn)具體的服務(wù)。

服務(wù)實現(xiàn)定義描述了給定服務(wù)提供者如何實現(xiàn)特定的服務(wù)接口。服務(wù)實現(xiàn)定義中包含服務(wù)和端口描述。一個服務(wù)往往會包含多個服務(wù)訪問入口而每個訪問入口都會使用一個端口元素來描述，端口描述的是一個服務(wù)入口的部署細節(jié)。

3. SOAP

簡單對象訪問協(xié)議。定義了服務(wù)請求者和服務(wù)提供者之間的消息傳輸規(guī)范。使用XML來格式化消息，用HTTP來承載消息。通過SOAP，應(yīng)用程序可以在網(wǎng)絡(luò)中進行數(shù)據(jù)交換和遠程過程調(diào)用RPC。SOAP主要包括以下四個部分：

1. 封裝。
2. 編碼規(guī)則，定義了一種序列化的機制，用于交換系統(tǒng)所定義的數(shù)據(jù)類型的實例。
3. RPC表示。定義了一個用來表示遠程過程迪奧喲經(jīng)和應(yīng)答的協(xié)議。
4. 綁定。定義了一個使用底層傳輸協(xié)議來完成在結(jié)點之間進行交換SOAP封裝的約定。

SOAP消息基本上是要從發(fā)送端到接收端的單向傳輸，但它們常常結(jié)合起來執(zhí)行類似于請求/應(yīng)答的模式。所有的SOAP消息都使用XML進行編碼。SOAP消息包括以下三個部分：

1. 封裝（信封）。元素名是Envelope，在表示消息的XML文檔中，封裝是頂層元素，在SOAP中必須出現(xiàn)。
2. SOAP頭。元素名是Header，提供了向SOAP消息中添加關(guān)于這個SOAP消息的某些要素的機制。SOAP定義了少量的屬性來表明這項要素是否可選以及由誰來處理?？赡艹霈F(xiàn)，也可能不出現(xiàn)，一旦出現(xiàn)，必須是第一個直接子元素。
3. SOAP體。元素名是Body，是包含消息的最終接收者想要的信息的容器。必須出現(xiàn)，且必須是直接子元素。如果有頭元素，則必須直接跟在頭元素的后面，如果沒有，則必須是第一個子元素。

4. REST

表述性狀態(tài)轉(zhuǎn)移。是一種只使用HTTP和XML進行基于web通信的技術(shù)，可以降低開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。REST從根本上只支持幾個操作（POST、GET、PUT和DELETE）。REST提出了如下一些設(shè)計概念和準則：

1. 網(wǎng)絡(luò)上的所有事物都被抽象為資源。
2. 每個資源對應(yīng)一個唯一的資源標識。
3. 通過通用的連接件接口對資源進行操作。
4. 對資源的各種操作不會改變資源標識。
5. 所有的操作都是無狀態(tài)的。

9.5.3 SOA的實現(xiàn)方法

1. Web Service

一共有三種工作角色，其中服務(wù)提供者和服務(wù)請求者是必需的，服務(wù)注冊中心是一個可選的角色。

1. 服務(wù)提供者。是服務(wù)的所有者，負責定義并實現(xiàn)服務(wù)，使用WSDL對服務(wù)進行詳細、準確、規(guī)范性描述，并將該描述發(fā)布到服務(wù)注冊中心，工服務(wù)請求者查找并綁定使用。
2. 服務(wù)請求者。是服務(wù)的使用者。從架構(gòu)的角度看，服務(wù)請求者是查找、綁定并調(diào)用服務(wù)，或與服務(wù)進行交互的應(yīng)用程序。服務(wù)請求者角色可以由瀏覽器來擔當，由人或程序來控制。
3. 服務(wù)注冊中心。是連接服務(wù)提供者和服務(wù)請求者的紐帶，服務(wù)提供者在此發(fā)布它們的服務(wù)描述，而服務(wù)請求者可以在服務(wù)注冊中心查找它們需要的服務(wù)。如果是使用靜態(tài)綁定的服務(wù)，服務(wù)提供者可以把描述直接發(fā)給服務(wù)請求者。

Web service模型中的操作如下，這些操作可以單次或反復(fù)出現(xiàn)；

1. 發(fā)布。服務(wù)提供者發(fā)布服務(wù)描述
2. 查找。服務(wù)請求者直接檢索服務(wù)描述或在服務(wù)注冊中心查詢所要求的服務(wù)類型。對服務(wù)請求者來說，可能會在生命中秋的兩個不同階段中涉及查找操作，首先是在設(shè)計階段，為了程序開發(fā)而查找服務(wù)的接口描述；其次是在運行階段，為了調(diào)用而查找服務(wù)的位置描述。
3. 綁定。服務(wù)請求者使用服務(wù)描述中的綁定細節(jié)來定位、聯(lián)系并調(diào)用服務(wù)，從而在運行時與服務(wù)進行交互。綁定可以分為動態(tài)綁定和靜態(tài)綁定。在動態(tài)綁定中，服務(wù)請求者通過服務(wù)注冊中心查找服務(wù)描述，并動態(tài)的與服務(wù)交互；在靜態(tài)綁定中，服務(wù)請求者已經(jīng)與服務(wù)提供者達成默契，通過本地文件或其他方式直接與服務(wù)進行綁定。

在采用Web service作為SOA的實現(xiàn)技術(shù)時，應(yīng)用程序大致可以分為六個層次，如下：

1. 底層傳輸層。主要負責消息的傳輸機制，HTTP、JMS和SMTP都可以作為服務(wù)的消息傳輸協(xié)議，其中HTTP使用最廣。
2. 服務(wù)通信協(xié)議層。主要功能是描述并定義服務(wù)之間進行消息傳遞所需的技術(shù)標準，常用的標準是SOAP和REST協(xié)議。
3. 服務(wù)描述層。主要以一種統(tǒng)一的方式描述服務(wù)的接口與消息交換方式，相關(guān)的標準是WSDL。
4. 服務(wù)層。主要功能試講遺留系統(tǒng)進行包裝，并通過發(fā)布的WSDL接口描述被定位和調(diào)用。
5. 業(yè)務(wù)流程層。主要功能是支持服務(wù)發(fā)現(xiàn)，服務(wù)調(diào)用和點到點的服務(wù)調(diào)用，并將業(yè)務(wù)流程從服務(wù)的底層調(diào)用抽象出來。
6. 服務(wù)注冊層。主要功能是使服務(wù)提供者能夠通過WSDL發(fā)布服務(wù)定義，并支持服務(wù)請求者查找所需的服務(wù)信息，相關(guān)的標準是UDDI。

2. 服務(wù)注冊表

雖然也有運行時的功能能，但主要在SOA設(shè)計時使用。它提供了一個策略執(zhí)行點PEP，在這個點上，服務(wù)可以在SOA中注冊，從而可以被發(fā)現(xiàn)和使用。從理論上來說，任何幫助服務(wù)注冊、發(fā)現(xiàn)和查找服務(wù)合約、元數(shù)據(jù)和策略的信息庫、數(shù)據(jù)庫、目錄或其他節(jié)點都可以被認為是一個注冊表。

1. 服務(wù)注冊。指服務(wù)提供者向服務(wù)注冊表發(fā)布服務(wù)的功能（服務(wù)合約），包括服務(wù)身份、位置、方法、綁定、配置、方案和策略等描述性屬性。
2. 服務(wù)位置。指服務(wù)使用者，幫助它們查找已注冊的服務(wù)，尋找符合自身要求的服務(wù)。
3. 服務(wù)綁定。服務(wù)使用者利用查找到的服務(wù)合約來開發(fā)代碼，開發(fā)的代碼將與注冊的服務(wù)進行綁定，調(diào)用注冊的服務(wù)，以及與他們實現(xiàn)互動。

3. 企業(yè)服務(wù)總線

ESB，是一種為連接服務(wù)提供的標準化的通信基礎(chǔ)結(jié)構(gòu)，基于開放的標準，為應(yīng)用提供一個可靠的、可度量和高度安全的環(huán)境，并可幫助企業(yè)對業(yè)務(wù)流程進行設(shè)計和模擬，對每個業(yè)務(wù)流程進行控制和跟蹤、分析、并改進流程和性能。

ESB是由中間件技術(shù)實現(xiàn)并支持SOA的一組基礎(chǔ)架構(gòu)，是傳統(tǒng)中間件技術(shù)與XML、Web Service等技術(shù)結(jié)合的產(chǎn)物，是在整個企業(yè)集成環(huán)境下的面向服務(wù)的企業(yè)應(yīng)用集成機制。具體來說，ESB具有以下功能

1. 支持異構(gòu)環(huán)境中的服務(wù)、消息和基于事件的交互，并且具有適當?shù)姆?wù)級別和可管理性。
2. 通過使用ESB，可以在幾乎不更改代碼的情況下，以一種無縫的非侵入方式使現(xiàn)有系統(tǒng)具有全新的服務(wù)接口，并能夠在部署環(huán)境中支持任何標準。
3. 充當緩沖器的ESB（負責在諸多服務(wù)之間轉(zhuǎn)換業(yè)務(wù)邏輯和數(shù)據(jù)格式）與服務(wù)邏輯相分離，從而使不同的系統(tǒng)可以同時使用同一個服務(wù)，不用在系統(tǒng)或數(shù)據(jù)發(fā)生變化時，改動服務(wù)代碼。
4. 在更高的層次，ESB還提供諸如服務(wù)代理和協(xié)議轉(zhuǎn)換等功能，允許在多種形式下通過向HTTP、SOAP和JMS總線的多種傳輸方式，主要是以網(wǎng)絡(luò)服務(wù)的形式，為發(fā)表、注冊、發(fā)現(xiàn)和使用企業(yè)服務(wù)或界面提供基礎(chǔ)設(shè)施。
5. 提供可配置的消息轉(zhuǎn)換翻譯機制和基于消息內(nèi)容的消息路由服務(wù)，傳輸消息到不同的目的地。
6. 提供安全和擁有者機制，以保證消息和服務(wù)使用的認證、授權(quán)和完整性。

9.5.4 微服務(wù)

微服務(wù)架構(gòu)是一種架構(gòu)模式，提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。每個服務(wù)運行在其獨立的進程中，服務(wù)與服務(wù)間采用輕量級的通信機制互相溝通。每個服務(wù)都圍繞著具體業(yè)務(wù)進行構(gòu)件，并且能夠被獨立的部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應(yīng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機制，對具體的一個服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言、工具對其進行構(gòu)件。

核心特點是：小，且專注做一點事情、輕量級的通信機制、松耦合、獨立部署。

1. 微服務(wù)的優(yōu)勢

1. 技術(shù)異構(gòu)性

在微服務(wù)架構(gòu)中，每個服務(wù)都是一個相對獨立的個體，每個服務(wù)都可以選擇適合于自身的技術(shù)去實現(xiàn)。

2. 彈性

主要講的是系統(tǒng)中的一部分出現(xiàn)故障，會引起多大問題。微服務(wù)架構(gòu)中，每個服務(wù)都可以內(nèi)置可用性的解決方案與功能降級方案。

3. 擴展

可以針對單個服務(wù)進行擴展

4. 簡化部署

微服務(wù)架構(gòu)中，每個服務(wù)的部署都是獨立的?？梢愿斓膶μ囟ú糠值拇a進行部署。

5. 與組織結(jié)構(gòu)相匹配

微服務(wù)架構(gòu)可以將架構(gòu)與組織結(jié)構(gòu)相匹配，避免出現(xiàn)過大的代碼庫，從而獲得理想的團隊大小及生產(chǎn)力。

6. 可組合型

在微服務(wù)架構(gòu)中，系統(tǒng)會開放很多接口供外部使用。當情況發(fā)生改變時，可以使用不同的方式構(gòu)件應(yīng)用。

7. 對可替代性的優(yōu)化

在微服務(wù)架構(gòu)中，我們可以在需要時輕易的重寫服務(wù)，或刪除不再使用的服務(wù)。

2. 微服務(wù)面臨的挑戰(zhàn)

1. 分布式系統(tǒng)的復(fù)雜度
2. 運維成本
3. 部署自動化
4. DevOps與組織結(jié)構(gòu)
5. 服務(wù)間依賴測試
6. 服務(wù)間依賴管理

3. 微服務(wù)與SOA

9.6 架構(gòu)設(shè)計

1. 演變交付生命周期

在生命周期模型中，架構(gòu)設(shè)計就是從初步的需求分析開始逐步進行循環(huán)迭代。即：一方面在了解系統(tǒng)需求前，不能開始設(shè)計架構(gòu)；另一方面，剛開始設(shè)計架構(gòu)時并不需要等到全部需求都收集到。

2. 屬性驅(qū)動設(shè)計法

是一種定義軟件架構(gòu)的方法，該方法將分解過程建立在軟件必須滿足的質(zhì)量屬性智商。

ADD的步驟如下。

1. 選擇要分解的模塊
2. 根據(jù)如下步驟對模塊進行求精：

• 從具體的質(zhì)量場景和功能需求集合中選擇架構(gòu)驅(qū)動因素。并不是同等看待所有需求，而是在滿足了最重要的需求的條件下，才滿足不太重要的需求，即針對架構(gòu)需求有優(yōu)先級。
• 選擇滿足架構(gòu)驅(qū)動因素的架構(gòu)模式，根據(jù)前面的戰(zhàn)術(shù)創(chuàng)建（或選擇）模式。其目標是建立一個由模塊類型組成的總體架構(gòu)模式。
• 實例化模塊并根據(jù)用例分配功能，使用多個視圖進行表示。
• 定義子模塊的接口。
• 驗證用例和質(zhì)量場景，并對其進行求精，使他們成為子模式的限制。

3. 對需要進一步分解的每個模塊重復(fù)上述步驟。

3. 按架構(gòu)組織開發(fā)團隊

4. 開發(fā)骨架系統(tǒng)

5. 利用商用軟件進行開發(fā)

9.7 軟件架構(gòu)文檔化

1. 架構(gòu)文檔的使用者

是架構(gòu)的項目關(guān)系人。編寫技術(shù)文檔的最基本的原則之一是要從讀者的角度來編寫。

2. 合理的編檔規(guī)則

1. 從讀者的角度編寫文檔
2. 避免出現(xiàn)不要的重復(fù)
3. 避免歧義
4. 使用標準結(jié)構(gòu)
5. 記錄基本原理
6. 使文檔保持更新，但更新頻率不要過高
7. 針對目標的適宜性對文檔進行評審

3. 視圖編檔

文檔組織結(jié)構(gòu)包含七個部分：

1. 視圖概述：對系統(tǒng)進行概述性的描述，包含視圖的主要元素和元素箭的關(guān)系（但并不包含所有元素和元素箭的過膝）。主要表示可用多個形式：圖形、表格、文本。通常用圖形形式，使用UML語言來描述。
2. 元素目錄：對主要表示中所描述的元素及其關(guān)系進行詳細描述，包括：元素及其屬性、關(guān)系及其屬性、元素接口、元素行為。這部分是文檔的主要組成部分，其中要注意：

• 對元素及其協(xié)同工作的行為進行編檔，如用UML中的順序圖和狀態(tài)圖描述行為；
• 對接口進行編檔

3. 上下文圖：用圖形展示系統(tǒng)如何與其環(huán)境相關(guān)。
4. 可變性指南：描述架構(gòu)的可變化點。文檔中應(yīng)包含這些變化點，如各系統(tǒng)要作出選擇的選項、作出選擇的時間。
5. 架構(gòu)背景：為架構(gòu)的合理性提供足夠的、令人信服的論據(jù)。包括：基本原理、分析結(jié)果及設(shè)計中所反映的假定。
6. 術(shù)語表：對文檔中每個術(shù)語進行簡要說明。
7. 其他信息：描述不屬于架構(gòu)方面的必要信息。

4.跨視圖文檔

包括如下內(nèi)容：

1. 文檔由哪些內(nèi)容以及如何組織：視圖目錄；視圖模板
2. 架構(gòu)概述：描述系統(tǒng)的目的、是土建的關(guān)聯(lián)、元素表及索引、項目詞匯
3. 基本原理：跨視圖基本原理解釋了整體架構(gòu)實際上是其需求的一個解決方案。及解釋了作出決策的原因、方案的限制、改變決策時的影響及意義。

5. 使用UML

6. 軟件架構(gòu)重構(gòu)

軟件架構(gòu)重構(gòu)就是研究及反向解析軟件架構(gòu)的工作。

軟件架構(gòu)重構(gòu)由以下活動組成，這些活動以迭代方式進行。

1. 信息提取：提取目標的依賴關(guān)系；提取靜態(tài)信息；提取動態(tài)信息
2. 數(shù)據(jù)庫構(gòu)造：將提取的信息轉(zhuǎn)化為標準的形式，并置于數(shù)據(jù)庫中。
3. 視圖融合：將數(shù)據(jù)庫中的信息組合在一起，生成該架構(gòu)的一個內(nèi)聚的視圖。
4. 重構(gòu)：根據(jù)數(shù)據(jù)抽象和各種表示以生成架構(gòu)表示，主要由兩個活動組成：最后生成需要的架構(gòu)文檔。

9.8 軟件架構(gòu)評估

是在對架構(gòu)分析、評估的基礎(chǔ)航，對架構(gòu)策略的選取進行決策。他可以靈活的運用于軟件架構(gòu)進行評審等工作中。

9.8.1 軟件架構(gòu)評估的方法

1. 基于調(diào)查問卷或檢查表的方式：關(guān)鍵是要設(shè)計好問卷或檢查表，它充分利用系統(tǒng)相關(guān)人員的經(jīng)驗和知識，獲得對架構(gòu)的評估。缺點是在很大程度上依賴于評估人員的主觀推斷。
2. 基于場景的方式：應(yīng)用在架構(gòu)權(quán)衡分析法和軟件架構(gòu)分析方法中。通過分析軟件建構(gòu)對場景的支持程度，從而判斷該架構(gòu)對這一場景所代表的質(zhì)量需求的滿足程度。
3. 基于度量的方式：建立在軟件架構(gòu)度量的基礎(chǔ)上的，涉及三個基本活動，首先需要建立質(zhì)量屬性和度量之間的映射原則，即確定怎樣從度量結(jié)果中退出系統(tǒng)具有什么樣的質(zhì)量屬性；然后從軟件架構(gòu)文檔中獲取度量信息；最后根據(jù)映射原則分析推導出系統(tǒng)的質(zhì)量屬性。它能提供更為客觀和量化的質(zhì)量評估，對評估人員及其使用的技術(shù)有較高的要求。

9.8.2 架構(gòu)的權(quán)衡分析法

從技術(shù)的角度對軟件架構(gòu)進行評估，旨在通過分析來遇見軟件的質(zhì)量，通過分析來創(chuàng)建、選擇、評估與比較不同的架構(gòu)。ATAM方法不但能夠揭示架構(gòu)如何滿足特定的質(zhì)量需求，而且還提供了分析這些質(zhì)量需求之間交互作用的方法。使用ATAM方法評價一個軟件架構(gòu)的目的是理解架構(gòu)設(shè)計滿足系統(tǒng)質(zhì)量需求的結(jié)果。ATAM產(chǎn)生如下結(jié)果。

1. 一個簡潔的架構(gòu)描述
2. 表述清楚的業(yè)務(wù)目標。
3. 用場經(jīng)濟和捕捉質(zhì)量需求。
4. 架構(gòu)決策到質(zhì)量需求的映射。
5. 所確定的敏感點和權(quán)衡點集合：這個集合是一些對一個或多個質(zhì)量屬性具有顯著影響的架構(gòu)。
6. 有風險角色和無風險決策
7. 風險主題的集合。
8. 產(chǎn)生一些附屬結(jié)果
9. 還產(chǎn)生一些無形結(jié)果。

ATAM的九個步驟如下：

1. ATAM方法的表述
2. 商業(yè)動機的表述
3. 架構(gòu)的表述
4. 對架構(gòu)方法進行分類
5. 生成質(zhì)量屬性效用樹。
6. 分析架構(gòu)方法
7. 集體討論并確定場景的優(yōu)先級
8. 分析架構(gòu)方法
9. 結(jié)果的表述

9.8.3 成本效益分析法

CBAM是在ATAM上構(gòu)建，用來對于架構(gòu)設(shè)計決策的成本和收益進行建模，是優(yōu)化此類決策的一種手段。CBAM協(xié)助項目管理人根據(jù)其投資回報ROI選擇架構(gòu)策略。CBAM在ATAM結(jié)束時開始，它實際上使用了ATAM評估的結(jié)果。步驟如下：

1. 整理場景
2. 對場景進行求精
3. 確定場景的優(yōu)先級
4. 分配效用。對場景的響應(yīng)級別（最壞情況、當前情況、期望情況和最好情況）確定效用表。
5. 架構(gòu)策略設(shè)計那些質(zhì)量屬性及相應(yīng)級別，形成相關(guān)的策略——場景——響應(yīng)級別的對應(yīng)關(guān)系。
6. 使用內(nèi)插法確定“期望的”質(zhì)量屬性響應(yīng)級別的效用。即根據(jù)第4步的效用表以及第5步的對應(yīng)關(guān)系，確定架構(gòu)策略及對應(yīng)場景的效用表。
7. 計算各架構(gòu)策略的總收益。
8. 根據(jù)受成本限制影響的投資報酬率ROI選擇架構(gòu)策略。

9.9 構(gòu)件及其復(fù)用。

定義1：構(gòu)件是指軟件系統(tǒng)中可以明確辨識的構(gòu)成成分。而可復(fù)用構(gòu)件是指具有相對獨立的功能和可復(fù)用價值的構(gòu)件。
定義2：構(gòu)件是一個組成單元，具有約定規(guī)范的接口及明確的依賴環(huán)境。
定義3：構(gòu)件是軟件系統(tǒng)中具有相對獨立功能、可以明確辨識、接口由七月制定、和語境由明顯依賴關(guān)系、可獨立部署的可組裝軟件實體。

9.9.1 商用構(gòu)件標準規(guī)范

1. CORBA

公共對象請求代理架構(gòu)。主要分為3個層次：對象請求代理、公共對象服務(wù)和公共設(shè)施。最底層的對象請求代理ORB，規(guī)定了分布對象的定義（接口）和語言映射，實現(xiàn)對象間的通信和互操作，是分布對象系統(tǒng)中的“軟總線”；在ORB之上定義了很多公共服務(wù)，可以提供諸如并發(fā)服務(wù)、名字服務(wù)、事務(wù)（交易）服務(wù)、安全服務(wù)等各種各樣的服務(wù)；最上層的公共設(shè)施則定義了構(gòu)件框架，提供可直接為業(yè)務(wù)對象使用的服務(wù)，規(guī)定業(yè)務(wù)對象有效寫作所需的協(xié)定規(guī)則。

CORBA CCM（CORBA構(gòu)件模型）是OMG組織制定的一個用于開發(fā)和配置分布式應(yīng)用的服務(wù)器端構(gòu)件模型規(guī)范，它主要包含以下三項內(nèi)容。

1. 抽象構(gòu)件模型：泳用以描述服務(wù)器端構(gòu)建結(jié)構(gòu)及構(gòu)件間互操作的結(jié)構(gòu)。
2. 構(gòu)件容器結(jié)構(gòu)：用以提供通用的構(gòu)件運行和管理環(huán)境，并支持對安全、事務(wù)、持久狀態(tài)等系統(tǒng)服務(wù)的集成。
3. 構(gòu)件的配置和打包規(guī)范：CCM使用打包技術(shù)來管理構(gòu)件的二進制、多語言版本的可執(zhí)行代碼和配置信息，并制定了構(gòu)建包的具體內(nèi)容和文檔內(nèi)容標準

2. J2EE

在分布式互操作協(xié)議上，J2EE同時支持遠程方法調(diào)用RMI和互聯(lián)網(wǎng)內(nèi)部對象請求代理協(xié)議IIOP。

EJB中的Bean可以分為會話Bean和實體Bean，前者維護會話，后者處理事務(wù)，通常由Servlet負責與客戶端通信，訪問EJB，并把結(jié)果通過JSP產(chǎn)生頁面返回客戶端。

3. DNA 2000

Microsoft的COM+組件

9.9.2 應(yīng)用系統(tǒng)簇與構(gòu)件系統(tǒng)

一般情況下，構(gòu)件系統(tǒng)只在開發(fā)單位內(nèi)部使用，而應(yīng)用系統(tǒng)提供給外部客戶。與應(yīng)用系統(tǒng)相比，構(gòu)件系統(tǒng)具有通用性、可復(fù)用性。一個構(gòu)件系統(tǒng)是能提供一系列可復(fù)用特性的系統(tǒng)產(chǎn)品。

9.9.3 基于復(fù)用開發(fā)的組織結(jié)構(gòu)

與傳統(tǒng)的開發(fā)組織結(jié)構(gòu)不同，它需要有一部分用于開發(fā)可復(fù)用資產(chǎn)的資源，這部分資源應(yīng)同具體引用系統(tǒng)的開發(fā)資源分開，以確保不被占用。

9.10 產(chǎn)品線與系統(tǒng)演化

實質(zhì)上是用架構(gòu)技術(shù)構(gòu)建產(chǎn)品線，并在此基礎(chǔ)上借用復(fù)用技術(shù)持續(xù)演化，不斷的推出新產(chǎn)品，滿足市場追求產(chǎn)品升級換代的需求。

9.10.1 復(fù)用與產(chǎn)品線

軟件產(chǎn)品線是指一組軟件密集型系統(tǒng)，它們共享一個公共的、可管理的特性及，滿足某個特定市場或任務(wù)的具體需要，是以規(guī)定的方式用公共的核心資產(chǎn)集成開發(fā)出來的。即圍繞核心資產(chǎn)庫進行管理、復(fù)用、集成新的系統(tǒng)。

可復(fù)用的資產(chǎn)非常廣，包括以下幾點：

• 需求
• 架構(gòu)設(shè)計
• 元素：捕獲并復(fù)用設(shè)計中的可取之處，避免設(shè)計失敗的地方
• 建模與分析
• 測試
• 項目規(guī)劃
• 過程、方法和工具
• 人員
• 樣本系統(tǒng)
• 缺陷消除

9.10.2 基于產(chǎn)品線的架構(gòu)

軟件產(chǎn)品線架構(gòu)是針對一系列產(chǎn)品而設(shè)計的通用框架，并在此基礎(chǔ)上，進一步向系列產(chǎn)品公用的模塊實現(xiàn)實現(xiàn)，供直接重用；將架構(gòu)用框架的形式予以實現(xiàn)，供定制使用。這就是通常所說的“平臺”。

產(chǎn)品線架構(gòu)較之單個產(chǎn)品架構(gòu)，有如下三點特別之處：

1. 產(chǎn)品線架構(gòu)必須考慮一系列明確許可的變化
2. 產(chǎn)品架構(gòu)一定要文檔化
3. 產(chǎn)品架構(gòu)必須提供“產(chǎn)品常見指南”（開發(fā)指南），描述架構(gòu)的實例化過程。

通常應(yīng)在識別變化時，應(yīng)考慮三個方面：

1. 確定變化點：確定變化是一項需要持續(xù)進行的活動，可以在開發(fā)過程中的任何時間確定變化。
2. 支持變化點：對變化的支持有多種形式，例如：

• 包含或生路額元素，如條件編譯
• 包含不同數(shù)量的復(fù)制元素：如通過添加更多的服務(wù)器產(chǎn)生高容量的變體。
• 具有相同的接口但具有不同的行為或質(zhì)量特性的元素版本的選擇：如靜態(tài)庫和動態(tài)鏈接庫的使用。
• 在面向?qū)ο蟮南到y(tǒng)中，通過特化或繁華特定的類實現(xiàn)變化。
• 通過參數(shù)配置來實現(xiàn)變化
  3、 對產(chǎn)品架構(gòu)的適應(yīng)性進行評估
• 評審方法
• 評估的內(nèi)容
• 評估的時間

9.10.3 產(chǎn)品線的開發(fā)模型

開發(fā)（確定）產(chǎn)品線的方法有兩種模型:

1. “前瞻性”產(chǎn)品線：利用在應(yīng)用領(lǐng)域的經(jīng)驗，對市場和技術(shù)發(fā)展趨勢的了解及企業(yè)判斷力等進行產(chǎn)品線設(shè)計，它反映了企業(yè)的戰(zhàn)略決策。通常是自上而下的采用產(chǎn)品線方法。
2. “反應(yīng)性”模型：企業(yè)根據(jù)以前的產(chǎn)品構(gòu)建產(chǎn)品家族，并隨著新產(chǎn)品的開發(fā)，擴展架構(gòu)和設(shè)計方案，它的核心資產(chǎn)庫是根據(jù)“已有證明”為共有、而非“預(yù)先計劃”為共有的元素構(gòu)建的。通常是自下而上的采用產(chǎn)品線方法。

9.10.4 特定領(lǐng)域軟件架構(gòu)

架構(gòu)的本質(zhì)在于其抽象性。包括兩個方面的抽象：業(yè)務(wù)抽象和技術(shù)抽象。其中業(yè)務(wù)抽象面向特定的技術(shù)領(lǐng)域

特定領(lǐng)域軟件架構(gòu)DSSA可以看做開發(fā)產(chǎn)品線的一個方法（或理論），它的目標就是在支持在一個特定領(lǐng)域中有多個應(yīng)用的生成。

DSSA的必備特征有：

1. 一個嚴格定義的問題域或解決域
2. 具有普遍性，使其可以用于領(lǐng)域中某個特定應(yīng)用的開發(fā)
3. 對整個領(lǐng)域的合適程度的抽象
4. 具備該領(lǐng)域固定的、典型的在開發(fā)過程中的可復(fù)用元素。

從功能覆蓋的范圍角度理解DSSA中領(lǐng)域的含義有兩種方法L

1. 垂直域。定義了一個特定的系統(tǒng)族，到處在該領(lǐng)域中可作為系統(tǒng)的克星解決方案的一個通用軟件架構(gòu)。
2. 水平域。定義了在多個系統(tǒng)和多個系統(tǒng)族中功能區(qū)域的共有部分，在子系統(tǒng)級上涵蓋多個系統(tǒng)（族）的特定部分功能。

DSSA的活動階段如下：

1. 領(lǐng)域分析：主要目標是獲得領(lǐng)域模型。即通過分析領(lǐng)域中系統(tǒng)的需求（領(lǐng)域需求），確定哪些需求是被領(lǐng)域中的系統(tǒng)廣泛共享的，從而建立領(lǐng)域模型。
2. 領(lǐng)域涉及：這個階段的目標是獲得DSSA，他是一個能夠適應(yīng)領(lǐng)域多個系統(tǒng)的需求的一個高層次的設(shè)計。
3. 領(lǐng)域?qū)崿F(xiàn)：主要目標是依據(jù)領(lǐng)域模型和DSSA開發(fā)和組織可復(fù)用信息。這些復(fù)用信息可以使從現(xiàn)有系統(tǒng)中提取得到的，也可能通過新的額開發(fā)得到。這個階段可以看做復(fù)用基礎(chǔ)設(shè)施的實現(xiàn)階段。

領(lǐng)域模型的主要作用如下：

1. 領(lǐng)域模型為需求定義了領(lǐng)域知識和領(lǐng)域詞匯，這較之單一的項目需求更有較好的大局觀。
2. 軟件界面的設(shè)計往往和領(lǐng)域模型關(guān)系密切
3. 領(lǐng)域模型的合理性將嚴重影響軟件系統(tǒng)的可擴展性
4. 在分層架構(gòu)的指導下，領(lǐng)域模型精化后即成為業(yè)務(wù)層的骨架。
5. 領(lǐng)域模型也是其數(shù)據(jù)模型的基礎(chǔ)
6. 領(lǐng)域模型是團隊交流的基礎(chǔ)，因為它規(guī)定了重要的領(lǐng)域詞匯表，并且這些詞匯的定義是嚴格的。

9.10.5 架構(gòu)及系統(tǒng)演化

架構(gòu)（系統(tǒng)）演化包含七個步驟：

1. 需求變動歸類
2. 制定架構(gòu)演化計劃
3. 修改、增加或刪除構(gòu)件
4. 更新構(gòu)件的相互作用
5. 構(gòu)件組裝與測試
6. 技術(shù)評審
7. 產(chǎn)生演化后的架構(gòu)

9.11 軟件架構(gòu)視圖

9.11.1 軟件視圖的分類

結(jié)構(gòu)是元素本身的集合，而視圖則是捕獲和表達結(jié)構(gòu)（文檔描述）

軟件視圖通常分為三種類型：

1. 模塊視圖類型：為系統(tǒng)的主要模塊實現(xiàn)單元編檔
2. 構(gòu)件和連接件視圖類型：為系統(tǒng)的構(gòu)件和連接件執(zhí)行單元編檔
3. 分配視圖類型：為軟件的開發(fā)和執(zhí)行環(huán)境之間的關(guān)系編檔

組別|架構(gòu)風格|說明|應(yīng)用于
----|--------
模塊視圖類型|分解|大模塊分解為小模塊，小到容易理解|資源分配、項目結(jié)構(gòu)化和規(guī)劃；信息隱蔽、封裝；配置控制
模塊視圖類型|使用|一個單元的正確性依賴于另一個單元的正確性（如版本）|設(shè)計子集；設(shè)計擴展（增量開發(fā)）
模塊視圖類型|分層|上層使用下層的服務(wù)；實現(xiàn)隱藏細節(jié)的抽象|增量式開發(fā)；基于“虛擬機”上的可移植性
模塊視圖類型|類或泛化|“繼承自”或“是一個實例”；共享訪問方法|面向?qū)ο蟮脑O(shè)計（使用公共模板）。
構(gòu)件-連接器視圖類型|客戶機-服務(wù)器|構(gòu)件是客戶機和服務(wù)器，連接件是協(xié)議及共享消息|分布式操作；關(guān)注點分離（支持可修改性）；負載均衡
構(gòu)件-連接器視圖類型|進程或通信進程|通過通信、同步或排除操作形成進程或線程之間的關(guān)聯(lián)|調(diào)度分析；性能分析
構(gòu)件-連接器視圖類型|并發(fā)|在相同的“邏輯線程”上運行|確定資源爭用；分析線程
構(gòu)件-連接器視圖類型|共享數(shù)據(jù)|運行時產(chǎn)生數(shù)據(jù)，使用數(shù)據(jù)（共享數(shù)據(jù)存儲庫）|性能；數(shù)據(jù)完整性；可修改性
分配視圖類型|部署|軟件功能分配給軟件（進程）、硬件（處理器）和通信路徑|性能、可用性、安全性說明。尤其是在分布式或并行系統(tǒng)中
分配視圖類型|實現(xiàn)|模塊映射到開發(fā)活動中|配置控制、集成、測試活動
分配視圖類型|工作分配|將責任分配到適當?shù)拈_發(fā)小組，特別是公共部分不是每個人去實現(xiàn)|項目管理、管理通用性，最好的專業(yè)技術(shù)安排。

9.11.2 模塊視圖類型及其風格

模塊將遵循某種方式將軟件系統(tǒng)分解成可管理的功能單元。

架構(gòu)模塊視圖是通過文檔來枚舉系統(tǒng)的主要實現(xiàn)單元或模塊，及這些單元之間的關(guān)系。任務(wù)完整的架構(gòu)文檔必須包含有模塊視圖，它為源代碼提供藍圖。

模塊視圖的四種風格如下：

1. 分解風格能展示向模塊分配責任的方式
2. 使用風格能展示模塊相互依賴的方式
3. 分層風格能將系統(tǒng)分割成一組虛擬機，通過“允許使用”關(guān)系相互關(guān)聯(lián)，分層風格能幫助實現(xiàn)可移植性和可修改性。
4. 泛化風格能展示一個模塊如何成為另一個模塊的泛化或特化，從而使模塊之間產(chǎn)生關(guān)聯(lián)。它廣泛應(yīng)用于面向?qū)ο蟮南到y(tǒng)，能展示繼承性，并能用來使用模塊之間的共性。

9.11.3 C&C視圖類型及其風格

能定義由具有某種運行時存在的元素模型，這些元素包括進程、對象、客機、服務(wù)器及數(shù)據(jù)存儲器等。此外，它還包括作為元素的交互路徑，如通信鏈路和協(xié)議、信息流及共享存儲器訪問。幾種風格如下：

1. 管道和過濾器風格中的交互模式表現(xiàn)出數(shù)據(jù)流連續(xù)變換的特征。數(shù)據(jù)抵達過濾器并經(jīng)過轉(zhuǎn)換后由管理傳送給下一個過濾器
2. 共享數(shù)據(jù)風格通過保留持久數(shù)據(jù)來支配交互模式，持久數(shù)據(jù)由多個數(shù)據(jù)存儲器和至少一個儲存庫保留。
3. 發(fā)布-訂閱風格用于向一組未知接受者發(fā)送時間和消息?？稍诓恍薷纳a(chǎn)者的情況下添加洗呢接受者（訂閱者）。在發(fā)布-訂閱風格中，構(gòu)件通過事件發(fā)布進行交互，構(gòu)件可以訂閱一組事件
4. 客戶機-服務(wù)器風格能展示構(gòu)件通過請求其他構(gòu)件的服務(wù)進行交互的過程，將功能劃分成客戶機和服務(wù)器后即可基于運行時準則把他們單獨分配給各個級。
5. 對等連接系統(tǒng)能通過構(gòu)件之間的直接交換支持服務(wù)交換。他是一種調(diào)用/返回風格。
6. 通信-進程風格的特征表現(xiàn)在通過各種連接件機制并發(fā)執(zhí)行構(gòu)件的交互，如通過同步、消息傳遞、數(shù)據(jù)交換、啟動和停止等進行交互。

9.11.4 分配視圖類型及其分割

硬件、文件系統(tǒng)和團隊結(jié)構(gòu)都會與軟件架構(gòu)進行交互，將軟件架構(gòu)映射到其環(huán)境的一般形式稱為“分配視圖類型”。

分配視圖類型的常見風格如下：

1. 布置風格體現(xiàn)為C&C風格（如進程-進程風格）的元素被分配到執(zhí)行平臺。
2. 實現(xiàn)風格能將模塊視圖類型中的模塊映射到開發(fā)基礎(chǔ)結(jié)構(gòu)，實現(xiàn)一個模塊總會產(chǎn)生許多獨立文件，必須對這些文件進行組織，以免失去對系統(tǒng)的控制及系統(tǒng)的完整性。通常利用配置管理技術(shù)進行文件管理。
3. 軟件項目的時間和預(yù)算估計取決于工作分解結(jié)構(gòu)WBS，而工作分解結(jié)構(gòu)則取決于軟件架構(gòu)。工作任務(wù)風格將軟件架構(gòu)映射到有人組成的團隊之中，實現(xiàn)這一項目管理的目的。

9.11.5 各視圖類型間的映射關(guān)系

1. 模塊視圖類型中的視圖通常會映射到構(gòu)件和連接件視圖類型中的視圖。模塊實現(xiàn)單元將映射到運行時構(gòu)件
2. 系統(tǒng)中的構(gòu)件和連接件視圖和模塊視圖之間的關(guān)系可能會非常復(fù)雜。同樣的代碼模塊可由C&C視圖的許多元素執(zhí)行。反之，C&C視圖的單一構(gòu)件可執(zhí)行有許多模塊定義的代碼。同樣，C&C構(gòu)件可能會擁有許多與環(huán)境進行交互的點，每個交互點由統(tǒng)一模塊接口定義。
3. 分配視圖類型是為有效的實現(xiàn)軟件架構(gòu)的輔助性視圖，它將其他視圖類型中的軟件元素映射到軟件環(huán)境中，即反應(yīng)其他視圖與軟件環(huán)境之間的關(guān)系。