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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.1.3 架構(gòu)的模型

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

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

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

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

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

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

9.2.1 軟件質(zhì)量屬性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 可用性的描述

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

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

1. 錯(cuò)誤檢測(cè)

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

2. 錯(cuò)誤恢復(fù)

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

3. 錯(cuò)誤預(yù)防

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

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

1. 可修改性的描述

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

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

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

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

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

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

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

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

1. 性能的描述

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

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

• 資源消耗：事件到達(dá)后進(jìn)入一系列的處理程序，每一步處理都要占用資源，而且在處理過(guò)程中消息在各構(gòu)件之間轉(zhuǎn)換，這些轉(zhuǎn)換也需要占用資源。
• 閉鎖時(shí)間：指對(duì)事件處理時(shí)碰到了資源爭(zhēng)奪、資源不可用或?qū)ζ渌?jì)算的依賴等情況，就產(chǎn)生了等待時(shí)間。

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

1. 資源需求

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

2. 資源管理

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

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

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

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

1. 安全性的描述

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

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

1. 抵抗攻擊

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

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

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

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

1. 可測(cè)試性的描述

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

1. 輸入/輸出

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

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

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

1. 易用性的描述

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

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

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

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

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

軟件架構(gòu)風(fēng)格是描述某一特定應(yīng)用領(lǐng)域中系統(tǒng)組織方式的慣用模式。架構(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)。按這種方式理解，軟件架構(gòu)風(fēng)格定義了用于描述系統(tǒng)的術(shù)語(yǔ)表和一組指導(dǎo)構(gòu)件系統(tǒng)的規(guī)則。

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

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

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

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

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

1. 批處理序列

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

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

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

2.管道和過(guò)濾器

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

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

管道/過(guò)濾器風(fēng)格的軟件架構(gòu)具有很多很好的特點(diǎn)：

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

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

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

3. 批處理序列風(fēng)格與管道過(guò)濾器風(fēng)格對(duì)比

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

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

1. 主程序/子程序

是結(jié)構(gòu)化時(shí)期的經(jīng)典架構(gòu)風(fēng)格。這種風(fēng)格一般采用單線程控制，把問(wèn)題劃分為若干處理步驟，構(gòu)件即為主程序和子程序。子程序通?？珊铣蔀槟K。過(guò)程調(diào)用作為交互機(jī)制，即充當(dāng)連接件。調(diào)用關(guān)系具有層次性，其語(yǔ)義邏輯表現(xiàn)為子程序的正確性，取決于它調(diào)用的子程序的正確性。

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

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

這種風(fēng)格的兩個(gè)主要特征為：

1. 對(duì)象負(fù)責(zé)維護(hù)其表示的完整性
2. 對(duì)象的表示與其他對(duì)象而言是隱蔽的。因?yàn)橐粋€(gè)對(duì)象對(duì)它的客戶隱藏了自己的表示，所以這些對(duì)象可以不影響它的客戶就能改變其實(shí)現(xiàn)方法。

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

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

存在的問(wèn)題如下：

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

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

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

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

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

1. 支持基于抽象程度遞增的系統(tǒng)設(shè)計(jì)，使設(shè)計(jì)者可以吧一個(gè)復(fù)雜系統(tǒng)被遞增的步驟進(jìn)行分解。
2. 支持功能增強(qiáng)，因?yàn)槊恳粚又炼嗪拖噜彽纳舷聦咏换?，因此功能的改變最多影響相鄰的上下?/li>
3. 支持重用。只要提供的服務(wù)接口定義不變，同一層的不同實(shí)現(xiàn)可以交互使用。這樣就可以定義一組標(biāo)準(zhǔn)的接口，而允許各種不同的實(shí)現(xiàn)方法。

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

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

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

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

1. 進(jìn)程通信架構(gòu)風(fēng)格

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

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

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

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

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

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

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

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

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

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

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

1. 解釋器

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

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

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

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

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

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

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

數(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)行操作。而超文本系統(tǒng)的典型代表，就是早期的靜態(tài)網(wǎng)頁(yè)。三種架構(gòu)子風(fēng)格中，最復(fù)雜的是黑板系統(tǒng)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.4.3 MVC架構(gòu)風(fēng)格

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

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

1. 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)的通知。
2. View實(shí)現(xiàn)可視化界面的呈現(xiàn)并捕捉最終用戶的交互操作。
3. View捕捉到用戶交互操作后悔直接轉(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)。

9.4.4 MVP架構(gòu)風(fēng)格

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

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

1. 模型與視圖完全分離，我們可以修改視圖而不影響模型。
2. 可以更高效的使用模型，因?yàn)樗械慕换ザ及l(fā)生在一個(gè)地方——Presenter內(nèi)部。
3. 我們可以將一個(gè)Presenter用于多個(gè)視圖，而不需要改變Presenter的邏輯。
4. 如果我們將邏輯放在Presenter的中，那么我們就可以脫離用戶接口來(lái)測(cè)試這些邏輯。

MVP的缺點(diǎn)包括：

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

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

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

9.5.1 SOA概述

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

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

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

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

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

2. SOA設(shè)計(jì)原則

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

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

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

SCA服務(wù)構(gòu)件與傳統(tǒng)構(gòu)件的主要區(qū)別在于：服務(wù)構(gòu)件旺旺是粗粒度的，而傳統(tǒng)構(gòu)件以細(xì)粒度居多；服務(wù)構(gòu)件的接口是標(biāo)準(zhǔn)的，主要是服務(wù)描述語(yǔ)言接口，而傳統(tǒng)構(gòu)件常以具體API形式出現(xiàn)；服務(wù)構(gòu)件的實(shí)現(xiàn)與語(yǔ)言是無(wú)關(guān)的，而傳統(tǒng)構(gòu)件常綁定某種特定的語(yǔ)言；服務(wù)構(gòu)件可以通過(guò)構(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ù)的信息注冊(cè)規(guī)范，以便被需要該服務(wù)的用戶發(fā)現(xiàn)和使用它。UDDI規(guī)范描述了服務(wù)的概念，同時(shí)也定義了一種編程接口。通過(guò)UDDI提供的標(biāo)準(zhǔn)接口，企業(yè)可以發(fā)布自己的服務(wù)供其他其他企業(yè)查詢和調(diào)用，也可以查詢特定服務(wù)的描述信息，并動(dòng)態(tài)綁定到該服務(wù)上。

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

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

2. WSDL

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

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

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

3. SOAP

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

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

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

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

4. REST

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

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

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

1. Web Service

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

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

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

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

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

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

2. 服務(wù)注冊(cè)表

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

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

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

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

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

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

9.5.4 微服務(wù)

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

核心特點(diǎn)是：小，且專注做一點(diǎn)事情、輕量級(jí)的通信機(jī)制、松耦合、獨(dú)立部署。

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

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

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

2. 彈性

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

3. 擴(kuò)展

可以針對(duì)單個(gè)服務(wù)進(jìn)行擴(kuò)展

4. 簡(jiǎn)化部署

微服務(wù)架構(gòu)中，每個(gè)服務(wù)的部署都是獨(dú)立的?？梢愿斓膶?duì)特定部分的代碼進(jìn)行部署。

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

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

6. 可組合型

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

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

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

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

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

3. 微服務(wù)與SOA

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

1. 演變交付生命周期

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

2. 屬性驅(qū)動(dòng)設(shè)計(jì)法

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

ADD的步驟如下。

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

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

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

3. 按架構(gòu)組織開(kāi)發(fā)團(tuán)隊(duì)

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

5. 利用商用軟件進(jìn)行開(kāi)發(fā)

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

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

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

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

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

3. 視圖編檔

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

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

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

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

4.跨視圖文檔

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

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

5. 使用UML

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

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

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

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

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

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

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

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

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

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

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

ATAM的九個(gè)步驟如下：

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

9.8.3 成本效益分析法

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

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

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

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

9.9.1 商用構(gòu)件標(biāo)準(zhǔn)規(guī)范

1. CORBA

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

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

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

2. J2EE

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

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

3. DNA 2000

Microsoft的COM+組件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 確定變化點(diǎn)：確定變化是一項(xiàng)需要持續(xù)進(jìn)行的活動(dòng)，可以在開(kāi)發(fā)過(guò)程中的任何時(shí)間確定變化。
2. 支持變化點(diǎn)：對(duì)變化的支持有多種形式，例如：

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

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

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

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

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

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

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

DSSA的必備特征有：

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

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

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

DSSA的活動(dòng)階段如下：

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

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

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

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

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

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

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

9.11.1 軟件視圖的分類

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

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

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

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

9.11.2 模塊視圖類型及其風(fēng)格

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

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

模塊視圖的四種風(fēng)格如下：

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

9.11.3 C&C視圖類型及其風(fēng)格

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

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

9.11.4 分配視圖類型及其分割

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

分配視圖類型的常見(jiàn)風(fēng)格如下：

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

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

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