第四章 高層軟件架構的設計
在高層設計階段，主要工作是分析與設計軟件的體系結構。通過系統分解，確定子系統的功能和子系統之間的關係，以及模塊的功能和模塊之間的關係，產生《體系結構設計報告》。
這個階段是系統架構師發揮作用的主要位置，高層架構設計過程設計流程如下。
|
|
在分析階段，我們建立模型表示真實的世界，以便理解業務過程以及這個過程中所要用到的信息。基本上說，分析首先是分解，把複雜信息需求的綜合問題，分解成易於理解的多個小問題。然後通過建立需求模型來對問題領域進行組織、構造並且編制文檔。
分析建模過程必須要用戶參與，並且需要用戶解釋需求，並且驗證建立的模型是否正確。
設計也稱之爲架構設計，實際上也是個建模過程，它把分析階段得出的信息也就是需求模型，轉換爲稱之爲解決方案的模型。
一般來說架構設計是一個高度技術的工作，一般不需要涉及太多的用戶，但需要系統分析人員和部分開發人員參與。因爲系統設計的輸出就是開發的藍圖。
下面討論在這一階段一系列的原則和思想。
第一節 高層軟件架構的規劃
一、客戶服務結構（C/S architecture）
這個結構可以用部署圖來表示。
二、多級體系結構（four-tier architecture）
這裏使用了組件圖和部署圖。
三、多級體系結構（串行法和團聚法）
四、流處理體系結構（procedural prcessing architecture）
五、代理體系結構（agent architecture）
六、聚合體繫結構（aggregate architecture）
七、聯邦體系結構（federation architecture）
第二節 面向過程的架構設計
面向過程的架構設計，又稱之爲結構化設計。
它使用“輸入 – 處理 – 輸出”這樣一個基本模型，這些模式比較適用於描述商業軟件，它們中大多數依靠數據庫或者文件，並且不太需要複雜的實時處理。
我們可以使用流程圖來記錄各個子系統的結構，系統流程圖標識了每個程序，以及他們存取的數據。
一、系統流程圖
系統流程圖是用圖形的方式描述哪些子系統是系統自動完成的，哪些是需要人工參與的，並且顯示了數據流和控制流。
系統流程圖主要描述大的信息系統，這種大的信息系統由單個的子系統和大量的程序塊組成。繪製流程圖使用的主要符號如下，也可以有其它的變體。
下面是一個銷售系統的流程。
二、結構圖及其應用
結構化設計的基本任務，是自頂向下的分解任務，結構圖是用來展示計算機程序模塊之間的層次關係。結構圖的主要符號如下：
下面是一個工資系統的部分結構圖。
三、模塊算法設計（僞碼）
結構化設計的另一個需求，是描述每個模塊的內部邏輯，我們可以用自己熟悉的語言來定義僞碼（比如C），使用僞碼並不是寫出程序，而是爲了更清楚地描述模塊級的邏輯。這樣也可以避免各種圖氾濫成災。
第三節 面向對象的架構設計
在面向對象的設計中，關注點變成了消息和響應機制。
而我們由面向對象的分析轉向面向對象的設計是一個自然的結果，在OOA中已經提供了足夠多的信息，
在高層設計階段，我們可以用包圖來建立體系架構。
在詳細設計階段，可以利用類圖建立相應的體系結構。
下圖是以類表達的典型的Nhibernate體系結構。
在設計的各個階段，在必要的重點位置，我們還可以用順序圖或者協作圖來描述一些最重要的消息機制。
面向對象的設計不僅僅是根據功能性和非功能性需求建立一些相應的結構，更重要的是要分析一些潛在問題，通過種種設計技巧，提升系統的整體性能。
下面我們來討論有關問題。
第四節 高層設計中的架構分析
面向對象的設計並不是簡單的把需求分析中的領域模型轉換成設計模型就可以了，架構師必須在由需求分析獲取架構因素，因此我們首先必須研究架構分析的問題。
另外，由於面向對象設計的成熟和發展，已經形成了一系列的重要設計原則和方法，這些原則和方法可以大大的提高我們的設計質量，這是使用OOD必須關注的問題。面向對象的架構設計與結構化設計根本的不同，是非常注意實時信息，也就是消息和響應機制。另一方面，也非常注意代碼重用，設計的目標往往是大型的、分佈式的、可升級、可維護而且是安全的體系，這也對設計者提出了更高的要求。
架構分析的本質，是識別可能影響架構的因素，瞭解它的易變性和優先級，並解決這些問題。
其難點是，應該瞭解提出了什麼問題，權衡這些問題，並掌握解決影響架構重要因素的衆多方法。
架構分析是高優先級和大影響力的活動。
架構分析對如下的工作而言是有價值的：
l 降低遺漏系統設計核心部分的風險
l 避免對低優先級的問題花費過多的精力
l 爲業務目標定位產品
一、架構分析
架構分析是在功能性需求過程中，有關識別非功能性需求的活動。
1）架構分析需要解決的問題
下面說明在架構級別上，需要解決的諸多問題的一些示例：
l 可靠性和容錯性需求是如何影響設計的？
l 購買的子組件的許可成本將如何影響收益？
l 分佈式服務如何影響有關軟件質量需求和功能需求的？
l 適應性和可配置性是如何影響設計的？
2）架構分析的一般步驟
架構分析有多種方法，大多數方法都是以下步驟的變體。
1．辨識和分析影響架構的非功能性需求。
2．對於那些具有重要影響的需求而言，分析可選方案，並做出處理這些影響的決定，這就是架構決策
二、識別和分析架構因素
1）架構因素
任何需求對一個系統架構都有重要影響。
這些影響包括可靠性、時間表、技能和成本的約束。
比如，在時間緊迫、技能有限同時資金充足的情況下，更好的辦法是購買和外包，而不是內部開發所有的組件。
然而，對架構最具影響的的因素，包含功能、可靠性、性能、支持性、實現和接口。
通常是非功能性屬性（如可靠性和性能）決定了某個架構的獨到之處，而不是功能性需求。
2）質量場景
在架構因素分析期間定義質量需求的時候，推薦應用質量場景。
它定義了可量化（至少是可觀測）的響應，並且因此可以驗證。質量場景很少使用模糊的不具度量意義的描述，比如“系統要易於修改”。
質量場景用<激發因素><可量化響應>的形式作簡短的描述，如：
l 當銷售額髮送到遠程計稅服務器計算稅金的時候，“大多數”時候必須2秒之內返回。這一結果是在“平均”負載條件下測量的。
l 當系統測試志願者提交一個錯誤報告的時候，要在一個工作日內通過電話回覆。
這裏，“大多數”和“平均”需要軟件架構師作進一步的調查和定義。質量場景直到做到真的可測試的時候，纔是真正有效的。這就意味着需要有一個詳細的說明。
3）架構因素的描述
架構分析的一個重要目標，是瞭解架構因素的影響、優先級和可變性（靈活性以及未來演變的直接需要）。
因此，大多數架構方法，都提倡對以下信息建立一個架構因素表。
|
因素
|
測量和質量場景
|
可變性（當前靈活性和未來演化）
|
因素（和其變化）對客戶的影響，架構和其它因素
|
獲取成功的優先級
|
困難或風險
|
|
可靠性 --- 可恢復性
|
|||||
|
從遠程服務失敗中恢復。
|
當遠程服務失敗的時候，偵聽到遠程服務重新在線的一分鐘內，重新與之建立聯繫，在產品環境下實現正常的存儲裝載。
|
當前靈活性—我們的SME認爲直到重新建立連接前，本地客戶簡化的服務是可以接受的（也是可取的）。
演化—在2年之內，一些零售商可能選擇支付本地完全複製遠程服務的功能（如稅金計算器）。可能性？高。
|
對大規模設計影響大。
零售商確實不願意遠程服務失敗，因爲這將限制或阻止它們使用POS進行銷售。
|
高
|
低
|
|
……
|
……
|
……
|
……
|
|
|
注：SME表示主題專家。
請注意上面的分類方法：可靠性—可恢復性。
在這裏這麼說明不等於它是唯一的或者最好的，但它對架構因素的分類很有效。
3）架構因素和UP工件
在架構設計中，中心功能需求庫就是用例，它的構想和補充規範，都是創建因素表的重要源泉。在用例中，特殊需求、技術變化、未決問題應該被反覆審覈。其隱含或者清晰的架構因素要被統一整理到補充規範裏面去。
例如：
|
用例1：Process Sale
|
|
主要成功場景
1．……
特殊需求
l 90%的信用授權應該在30秒內響應
l 無論如何，當遠程服務如庫存系統失敗的時候，我們需要強健的恢復措施。
l …………
技術和數據變化表
2a. 商品的表識可以通過條形碼掃描器或者是鍵盤輸入。
…………
未決問題
l 稅法的變化是什麼？
l 研究遠程服務的恢復問題。
|
三、架構因素的解析
架構設計的技巧就是根據權衡、相互依賴關係和優先級對架構因素的解決作出合適的選擇。
但這還不全面，老練的架構師具有多種領域的知識（例如：架構樣式和模式、技術、產品、缺陷和趨勢），並且能把這些知識應用在它們的決定中。
1）記錄架構的可選方案、決定和動機
不管目前架構決策的原則有多少，事實上所有的架構方法都推薦記錄：
可選的架構方案；決定；影響因素；顯著問題；決定動機。
這些記錄按不同的的形式或者完善程度，被稱之爲：
技術備忘錄；問題卡；架構途徑文檔。
技術備忘錄的一個重要的的方面就是動機或者原理，當開發者或者架構師以後需要修改系統的時候，架構師可能已經忘了他當初的設計依據（一個資深架構師同時帶多個項目的情況非常多見），備忘錄對理解當時的設計背後的動機極爲有用。
解釋放棄被選方案的理由十分重要，在將來產品進化的過程中，架構師也許需要重新考慮這些備選方案，至少知道當初有些什麼備選方案，爲什麼選中了其中之一。
技術備忘錄的格式並不重要，關鍵是簡單、清楚、表達信息完整。
|
技術備忘錄
|
|
問題：可靠性---從遠程服務故障中恢復
|
|
解決方案概要：通過使用查詢服務實現位置透明，實現從遠程到本地的故障恢復和本地服務的部分複製
|
|
架構因素
l 從遠程服務中可靠恢復
l 從遠程產品數據庫的故障中可靠恢復
解決方案
在服務工廠創建一個適配器……
動機
零售商不想停止零售活動……
遺留問題
無
考慮過的備選方案
與遠程服務廠商簽訂“黃金級”服務協議……
|
2）優先級
下面是指導做出架構決定目標：
1．不可改變的約束，包括安全和法律方面的事務
2．業務目標
3．其它全部目標
早期要決定是否應該避免保證未來的設計，應該實事求是的考慮，那些將要推遲到未來的場景，有多少代碼需要改變？工作量將是多少？仔細考慮潛在的變更將有助於揭示什麼是首要考慮的重要問題。
一個低耦合高內聚的產品，往往比較容易適應將來的變化，但也要仔細分析這樣付出的代價，在這個問題上，架構師的掂量往往是決定這個項目的生命線。
3）系統不同方面的分離和影響的局部化
架構分析的另外一個基本原則，就是實現分離系統的不同方向。
系統不同方向的分離，是在架構級別上關於低耦合和高內聚的一種大尺度思考方法。雖然它們也應用在小尺度對象上，但這樣的分離對於架構問題尤其突出。
因爲系統的不同方面很廣泛，而且架構的解決方案涉及重要的設計選擇。
至少有三個實現系統不同方面分離的大尺度技術：
1．把系統的一個方面模塊化到一個獨立的組件（如子系統）中並且調用它的服務。
2．使用裝飾器模式
3．採用後編譯器技術和麪向方面的技術
有了架構分析的結果，我們就可以討論高層架構設計本身的一系列原則了。
第五節 高層架構設計中的層模式
一、面向對象軟件架構的優點
1）面向對象軟件架構的維和視圖
一個系統的架構包括了多個維。
例如：
l 邏輯架構：描述系統的層、包、主要框架、類、接口和子系統的概念組織方式。
l 部署架構：描述系統的進程如何分配給處理單元和網絡配置。
統一過程建議採用架構的六種視圖（邏輯、部署等），我們後面會討論這個問題。
2）架構模式和模式的種類
架構模式是有關大尺度和粗粒度的設計，特別是應用在早期迭代過程（細化階段）。也就是當主要的結構和連接建立起來的時候的一些原則。
二、層模式
1）解決方案：
層模式（Layers pattern）的基本思想很簡單。
l 根據分離系統的多個具有清晰、內聚職責的設計原則，把系統大尺度的邏輯結構組織到不同的層中，每一層都具有獨立和相關的職責，使得較低的層爲低級和通用的服務，較高的層更多的爲特定應用。
l 從較高的層到較低的層進行協作和耦合，避免從底層到高層的耦合。
層是一個大尺度的元素，通常由一些包或者子系統組裝而成。
層模式與邏輯架構相關，也就是說，它描述了設計元素概念上的組織，但不是它物理上的包或者部署。
層爲邏輯架構定義了一個N層模型，稱之爲分層架構（Layers Architecture），它作爲模式得到了極爲廣泛的應用和引述。
框架（framework）：
一般來說框架具有如下的特徵：
l 是內聚的類和接口的集合，它們協作提供了一個邏輯子系統的核心和不變部分的服務。
l 包含了某些特定的抽象類，它們定義了需要遵循的接口。
l 通常需要用戶定義已經存在的框架類的子類，是客戶得以擴展框架的服務。
l 所包含的抽象類可能同時包含抽象方法和實例方法。
l 遵循好萊塢原則：“別找我們，我們會找你。”就是用戶定義得類將從預定義的類中接受消息，這通常通過實現超類的抽象方法來實現。
2）問題：
l 由於系統的許多部分高度的耦合，因此源代碼的變化將波及整個系統。
l 由於應用邏輯與用戶接口捆綁在一起，因此這些應用邏輯在其它不同的接口上無法重用，也無法分佈到另一個處理節點上。
l 由於潛在的通用技術服務或業務邏輯，與更具體的應用邏輯捆綁在一起，因此這些通用技術服務或者業務邏輯無法被重用，或者分佈到其它的節點，或者被不同的實現簡單的替換。
l 由於系統的不同部分高度的耦合，因此難以對不同開發者清晰界定格子的工作界限。
l 由於高度耦合混合了系統的各個方面，因此改進應用程序的功能，擴展系統，以及使用新技術進行升級往往是艱苦和代價高昂的。
3）示例：
信息系統一般分層邏輯架構。
在具體架構設計的時候，可以建立比較詳細的包圖，但是，並不需要面面俱到。
架構視圖的核心，是展示少數值得注意的元素。
統一過程的架構視圖是這樣告誡的：“選擇一小組有意義的元素來傳達主要的思想。”
特別注意：
在面向對象的層模式中，底層的類不僅僅提供調用，更主要的是提供父類，很多情況下，需要使用配置文件來動態裝配，這樣才能適應不同的需求。
4）層與層之間和包與包之間的耦合
邏輯架構還可以包含更多的信息，用來描述層與層以及包與包之間值得注意的耦合關係。
在這裏，可以用依賴關係表達耦合，但並不是確切的依賴關係，而僅僅是強調一般的依賴關係。
有時候也可以不畫出類，專注於包之間的依賴關係。
5）協作：
在架構層面上，有兩個設計上的決策：
1．什麼是系統的重要部分？
2．它們是如何連接的？
在架構上，層模式對定義系統的重要部分給出了指導。
象外觀、控制器、觀察者這些模式，通常用於設計層與層、包與包之間的連接。
6）外觀模式
GoF的外觀模式，定義了一個公共的外觀對象綜合子系統的服務。
外觀不應該表示大量子系統的操作，更確切的說，外觀更適合表示少量的高層操作、粗粒度的服務。當外觀呈現大量的底層操作的時候，會趨向於變得沒有內聚力。
外觀模式爲了一組子系統提供一個一致的方式對外交互。這樣就可以使客戶和子系統絕緣，可以大大減少客戶處理對象的數目，注意下圖。
使用Facade之前
使用Facade之後
這樣本來一個類的修改可能會影響一大片代碼，而加了外觀類以後只需要修改很少量的代碼就可以了，使系統的高級維護成爲可能。
7）通過觀察者實現向上協作
外觀模式通常用於高層到底層的操作（底層提供外觀，高層實現調用）。
當需要上層對底層的操作的時候，可以使用觀察者模式。也就是上層響應底層的事件，但這個事件的執行代碼由上層提供。
8）層之間的鬆散耦合
大部分的多層架構不能像基於OSI 7層模型的網絡協議一樣，上一層只能調用下一層。
相反，在信息系統中的分層通常是“鬆散的分層”或者說是“透明的分層”。一個層的元素可以和多個其它層的元素協作或耦合。
對於一般層之間耦合的觀點是：
l 所有較高的層都可以依賴於技術服務層和基礎層
比如在Java中，所有的層都依賴於java.util包元素。
l 依賴於業務基礎設施層的領域層是要首先考慮的。
l 表示層發出對應用層的調用，應用層再對領域層進行服務調用。除非不存在應用層，表示層一般是不直接對領域層進行調用的。
l 如果應用是一個單進程的“桌面”程序，那麼領域層的軟件對象對於表示層、應用層和更底層（如技術服務層）可以直接可見或者在中間傳遞。
l 另一方面，對於一個分佈式系統，那麼領域層對象的可序列化複製對象（通常稱之爲值對象或者數據容納對象）通常可以被傳遞到表示層。在這種情況下，領域層被部署到另一臺服務器上，客戶端節點得到服務器數據的拷貝。
現在的問題是，與技術服務層和基礎層的關係不是很危險嗎？
正如GRASP的受保護變化模式和低耦合模式的論述，耦合本身並不是個問題，但是與變化點和演化點的耦合是不穩定的而且是難於修正的。
幾乎沒有任何理由，去抽象和隱蔽某些不太可能變化的因素，即使這些因素可能變化，這種變化所產生的影響也是微乎其微的。
例如，建立一個Java應用程序，隱蔽對Java類庫的訪問有什麼意義呢？
與類庫的多個緊密耦合不太可能是個問題，因爲它們是相對穩定而且無處不在的。
9）應用層是可選的嗎
如果存在應用層，那麼它所包含的對象要負責瞭解客戶端的會話狀態，協調錶示層和領域層，以及控制工作流。
10）在不同的層上模糊集合成員
一些元素必定只屬於一個層，但有些元素卻難以區分，特別是處在技術服務層和基礎層之間，或者領域層和業務基礎設施層之間的元素。其實這些層之間只存在模糊的差異，所以，“高層”、“低層”、“特殊”、“一般”這些術語是可以接受的。
開發組並不需要在限定的分類上做出決定，可以粗略的把一個元素歸類到技術服務層或者基礎層，也可以稱之爲“基礎設施層”，注意，對於層並沒有十分確定的命名習慣和約定，文獻上各種命名上的矛盾是常見的，研究問題主要把握精髓，不要被這些表面的區別搞昏了頭。
11）使用反射動態裝入對象
不論是Java還是.NET，都很好的支持了反射，這樣，建立一種通用對象容器成爲可能，在詳細設計的討論中，我們會討論一個這樣的例子。
12）利用工廠模式構建通用的創建者
爲了保證層的通用型，在層中的必要部分，可以採用工廠模式創建對象，這個問題我們也會在詳細設計的討論中加以闡述。
13）層模式的優點：
l 層模式可以分離系統不同方面的考慮，這樣就減少了系統的耦合和依賴，提高了內聚性，增加了潛在的重用性，並且增加了系統設計上的清晰度。
l 封裝和分解了相關的複雜性。
l 一些層的實現可以被新的實現替代，一般來說，技術服務層或者基礎層這些比較低層的層不能替換，而表示層、應用層和領域層可能進行替換。
l 較低的層包含了可重用的功能。
l 一些層可能是分佈式的（主要是領域層和技術服務層）。
l 由於邏輯上劃分比較清楚，有助於多個小組開發。
三、模型-視圖分離原則
這個原則我們已經討論了多次，但這裏還是有必要總結一下。
非窗口類如何與窗口類通信？推薦的做法，是其它組件不和窗口對象直接耦合。因爲窗口和特定的應用有關，耦合太強不利於重用。
這就是模型--視圖分離的原則。
模型—視圖分離（Model – View Separation）的原則，已經發展爲模型-視圖-控制器（Model-View-Controller MVC）模式的一個關鍵原則。MVC起源於一個小規模的Web架構（比如Struts），近來，這個術語（MVC）被分佈式設計團體採納，也應用在大規模的架構上，模型指領域層，視圖指表示層，控制器指應用層的工作流對象。
模型—視圖分離原則的動機包括：
l 爲關注領域處理而不是用戶界面而定義內聚的模型。
l 允許分離模型和用戶界面層的開發。
l 最小化界面因爲需求變更給領域層帶來的影響。
l 允許新的視圖方便的連接到領域層而不影響領域層。
l 允許在同一模型對象上有多個聯立的視圖。
l 允許模型層的運行獨立於用戶界面層。
l 允許方便的把模型層簡單的連接到另一個用戶界面框架上。
第六節 框架設計的方法學問題
一、框架（Framework）的基本概念
事實已經表明，一個軟件組織，合理的組織開發和使用框架，並且能跨越組織邊界進行合作的能力越來越重要。軟件架構使得您能夠組合大量支撐產品和服務，一個共享的架構，可以使企業開發團隊很方便的分解問題，從而確定：
哪些可以企業（或者開發組）內部解決；
哪些可以使用已有的服務。
當架構跨越組織的時候，你就可以調選公司內外組織的合作力量，獲得共享架構帶來的好處，在這樣的情況下，架構設計組或者整個公司都需要掌握一些新的組織技能。
當公司內部存在產品線的時候，設計優秀的共享架構都可以帶來實實在在的好處。
（1）框架
框架最簡單的形式是指已開發過並已測試過的軟件的程序塊，這些程序塊可以在多個軟件開發工程中重用。框架提供了一個概括的體系結構模版，可以用這個模板來構建特定領域中的應用程序。
（2）爲什麼會出現應用框架
您只要細心地研究真實的應用程序，就會發現程序大致上由兩類性質不同的組件組成，一類與程序要處理的具體事務密切相關，我們不妨把它們叫做業務組件；另一類是應用服務。人們自然會想要是把這些在不同應用程序中有共性的一些東西抽取出來，做成一個半成品程序，這樣的半成品就是所謂的程序框架，再做一個新的東西時就不必白手起家，而是可以在這個基礎上開始搭建。實際上，大型軟件企業往往選擇搭建自己的框架。
（3）爲什麼要用框架？
因爲軟件系統發展到今天已經很複雜了，特別是服務器端軟件，設計到的知識，內容，問題太多。在某些方面使用別人成熟的框架，就相當於讓別人幫你完成一些基礎工作，你只需要集中精力完成系統的業務邏輯設計。而且框架一般是成熟，穩健的，他可以處理系統很多細節問題，比如，事物處理，安全性，數據流控制等問題。還有框架一般都經過很多人使用，所以結構很好，所以擴展性也很好，而且它是不斷升級的，你可以直接享受別人升級代碼帶來的好處。
目前一些常用的開源框架如下：
|
Struts / WebWork / Tapestry / Spring MVC
|
|
Web層
|
|
Spring（輕量級容器）
Spring框架的主要內容
1）核心概念
依賴注入－－輕量級容器（應用上下文）
AOP －－聲明性企業級服務（如事務）
2）持久化：JDBC封裝、與其它開源實現的整合
3）Spring MVC
4）遠程調用、EJB服務的替代方案
|
|
Hibernate / ibatis / JDO
|
|
業務層
|
|
數據層（持久層）
|
二、框架設計的核心原則
五個核心原則：
構想、預見、節奏、協作和簡化。
1）構想
構想原則說明了如何向架構的受益人描繪一幅一致的、有約束力的、以及靈活的未來圖像。作爲架構師，關鍵是要確保它提出來的架構設想與公司的業務目標相吻合，對於一個大型公司，做到這點事實上並不容易。
再次提醒，面向對象的架構，關鍵不是調用，而是繼承和重用。
2）節奏
節奏原則確保軟件組織可以定期根據可預測的速度、內容和質量對工件進行取捨。在新穎的性能和規定的發佈日期之間，有時候必須進行取捨，以確保發佈日期，但這點可能和公司高層的設想不同，這如何解決呢？
3）預見
首席架構師必須對未來發展走向有敏銳的洞察力，但這種預見往往和現行的標準有衝突，這就需要在兩者間做出平衡，而這種平衡也是非常難處理的。
4）協作
當首席架構師開始架構設計的時候，協作顯得及其重要，我們一定要確保公司、周邊合作者、領域架構師和開發組都能理解架構的關鍵思想，
5）簡化
簡化原則要求澄清並最小化架構與創建，當發現兩個小組開發的構件有重疊的部分以後，應該可以考慮指定一個共享的構件，如何實現簡化是構架師最值得關注的一個問題，非此架構設計的意義就顯得不大。
這五個原則被稱之爲VRASP模型（Vision、Rhythm、Anticipation、Partnering、 Simplification）。這個模型重點在於軟件架構的組織方面，事實上，軟件架構師得以成功的最大障礙是組織問題而不是技術問題。
三、形成構想
1）把價值映射爲架構約束
這個問題的本質，是架構受益人如何把客戶價值與架構約束捆綁。這裏所謂受益人，實際上是指使用架構的開發者。
|
用戶價值
|
|
共享架構
|
|
受益人
|
|
受益人
|
|
用戶價值
|
一致性和靈活性的考慮：
一致性的問題：是指受益人使用架構與期望值的符合程度。
靈活性的問題：是指受益人不破壞架構的情況下，利用共享框架的創建新的沒有預見到的情況下的容易程度。
2）產品線及其挑戰
當產品線上有多個產品的時候，爲了避免架構的設計被被動的拉向不同的方向，可以使用下面的三步方法：
1，清楚、簡明的、闡述一條迫切的用戶價值。
2，把用戶價值映射爲少數的能解決的問題。
3，把以上問題轉譯爲一組最小的約束條件。
遵循準則：
1，各方面的一致性
2，實施人員信任並使用架構
3，架構潛藏的知識對用戶是可識別和可獲得的
四、保證節奏
節奏能夠克服複雜性，確保競爭優勢。
節奏有三個元素：速度、內容和質量。
速度：一個團隊和另一個團隊之間（架構團隊和開發工程師團隊之間）同類型交接發生的頻率，每次交接的時間越是可預測的，移交也就越容易管理。
內容：內容是指一個團體向另一個團體提供的價值。當軟件架構師向開發團隊提交的構架使開發團隊獲得了實實在在的好處，這個架構就被認爲是有價值的。
質量：質量的含義是開發過程確保架構沒有缺陷。
遵循準則：
1，經理們需要定期評估、同步和調整架構
2，架構用戶需要對架構發佈的內容和進度有高度的信心
3，通過節奏協調明確的活動
五、預測、驗證和調整
架構師可以通過自己的經驗和成功使用的架構，合理的猜測將來會發生什麼。例如：
用戶會有什麼變化？
競爭形勢會如何改變？
運行環境會如何改變？
架構的設計必須是能夠適應這種可能的變化。
1）驗證：
在架構設計中，驗證主要指的是對架構基礎假定的測試，在架構成型以前，除非通過測試當初的基礎假定是被確認的，否則就會發生代價高昂的錯誤。
2）調整：
當預測結果發生變化的時候，你所面臨的問題就是調整。
六、實現協作
在軟件架構環境中，協作主要涉及對受益人的關係進行管理的過程。
合作並不能保證架構的受益人總是能和您保持一致，但是，當架構供應者發現他們有哪些功能他們沒有一致的理解的時候，就必須用達成一致的方法來解決這個矛盾。
架構設計者應該和所有的架構受益人合作，使利益最大化，而不是僅僅靠合同和協議過日子。
注意價值鏈的概念，每個行業都有自己的價值鏈，成功的構架設計者應該關注這些價值鏈。
幾個準則：
1，架構師需要了解誰是關鍵受益人，他們如何貢獻價值，以及他們需要貢獻什麼。
2，和受益人之間達成明確和強制性的契約。
3，通過制度和非正式的規範強化合作。
七、簡化
架構師和高級經理應該協力保持架構的平衡。
當某個新產品加入的時候，會大大增加架構的體積。架構師應該關注通用的服務，某個客戶專用的能力不應該放入通用的架構裏面。
架構師應該仔細考慮，極力找出隱蔽在多個不同需求中的公共元素。對於不能放棄的大型客戶，需要仔細的談判，提出多種解決方案供用戶選擇，而不是簡單的行或者不行。
準則：
1，開發人員長期不斷的使用架構的時候，減少了總成本和複雜性。
2，架構師明確理解關鍵最小需求，並構造多應用共享核心單元。
3，當不能被共享或者增加了不必要的複雜性的時候，應該把相關元素從核心移走。
在一個善於簡化的組織中，開發人員會不斷地清理核心，因爲人人都知道複雜的核心所帶來的麻煩。
第七節 面向服務架構（SOA）
面向服務的架構 (Service-Oriented Architecture SOA)是一種形式化的分離服務的架構風格。
面向服務的架構關注的是哪些是服務向用戶提供的功能，哪些是需要這些功能的系統，這種分離，使用一種服務合約（Service Contract）的機制來完成的。
本質上來說，SOA體現的是一種新的系統架構，SOA的出現，將爲整個企業級軟件架構設計帶來巨大的影響。
一、SOA的優點
SOA框架的特點是以服務爲中心，它把應用程序劃分成具有明確定義接口的模塊，從而得到服務和應用程序之間相當鬆散的耦合。
在SOA中，服務供應商和消費者是兩個獨立的實體。
面向服務的架構的優點主要體現在以下幾個方面：
l 降低應用開發費用。
l 降低維護費用。
l 增長的公司敏捷性。
l 生成對應用程序和設備的故障、中斷更具免疫力的系統，提高整體的可靠性。
l 提供了一條應用系統的升級途徑，對比使用單一的應用程序的時候，需要替換整個應用系統的標準升級方法，顯然更爲經濟，更不容易失敗。
二、SOA的特性
SOA 有以下特性：
l 服務具有明確的接口（合約）與策略。
l 服務通常代表業務功能或者領域。
l 服務擁有模塊化的設計。
l 服務被鬆散的耦合在一起。
l 服務是可以被發現的。
l 服務的位置對客戶是透明的。
l 服務是獨立於傳輸層的。
l 服務是獨立於平臺的。
SOA可以通過很多方式來實現，但最常用的SOA是用Web Service來實現，這主要應爲Web Service的獨立於平臺的特性和其它特性更符合SOA 的規則。
1）服務具有明確的接口與策略
明確定義服務具有的接口（合約）是SOA 的核心定義。
合約應該包含兩部分內容，一個是接口，另一個是業務策略。
普通對象概念的接口包括：
l 數據類型。
l 期望的輸出。
l 必需的輸入。
l 錯誤信息。
SOA的合約擴大了接口的概念，包括：
l 所提供的功能。
l 需要的輸入和期望的輸出。
先決條件。
l 後置條件。
l 錯誤處理。
l 服務品質保證等。
關於業務策略，事實上服務的生產者和消費者都要定義策略，包括可靠性、可用性、安全性等等。
1．所提供的功能
確切說明服務允許完成什麼。
2，期望的輸入和輸出
服務期待什麼樣的輸入以及它能提供什麼樣的輸出，對客戶來說這是一個重要的信息。
3，先決和後置條件
先決條件：
服務激活前存在的輸入或者應用程序的狀態，最常見的輸入是安全口令。
後置條件：
請求被處理以後服務的狀態。比如服務作爲某個事物的一部分來調用的，這時候服務必須接到事務協調者的通知後才能完成這個事物的提交。
服務如何應對錯誤是絕對的後置條件，系統出錯以後不同的錯誤系統應該是什麼狀態，這點必須寫清楚。
4，錯誤處理
錯誤處理是另外一個需要在合約中說明的領域，從UML的觀點來看，錯誤是一個通道，所有錯誤都不返回參與者所期望的價值產品。
客戶需要知道描述錯誤的數據結構或者其它信息。
5，服務品質協議
服務品質（QoS）是可選的，但確是合約的重要組成部分，因爲消費者很大程度上可以根據提供者提供的服務水準，來選擇它們的提供者。
服務品質包括諸如：性能、多線程、容錯之類問題。
6，註冊表
註冊表（Registry）把所有的東西聯繫到了一起，它是服務保存信息和登記信息的地方，也是消費者找尋和履行合同的地方。
註冊表這個術語有很多意思。一個註冊表可以爲消費者提供一個指定的查詢標準，來查找合約的機制。然後消費者將和服務聯接在一起。
註冊表可以由企業、獨立來源、或者需要提供服務的其它業務組織來維護和提供，所有的註冊表都需要實現允許獨立登記，讓消費者查找服務提供者並且和它們連接的應用程序編程接口（API）。
註冊表是把消費者和服務方分離開來的核心機制，這種分離允許SOA增加需求能力，並且提供連續可用的服務。
註冊表並不一定需要包含合約，註冊表可以包括提供者所提供的服務以及合約地點的描述信息，這樣可以允許提供者在本地維護自己的合約，這樣也可能更加方便。
2）服務代表業務領域
服務可以用來建立各種各樣的問題的領域，即可以是企業領域，也可以是技術領域。
SOA真正的能力，在與可以爲企業領域建模，因爲業務服務通常比技術服務更加難以實現，無論對內和對外都更加有價值，所以SOA真正持久的價值在於建立一個重要業務過程的服務。
3）服務擁有模塊化設計
服務由模塊組成，模塊花設計對SOA來說是很重要的，模塊可以被看作是一個執行具體、明確功能的軟件和子系統。
模塊應該表現爲高的內聚性，而且是完整的功能。
粗粒度做法是構造一個完整的轉賬模塊，這種模塊提升了系統性能，但減少了可重用性。但是，SOA通過網絡實現服務，網絡擁擠可能是主要矛盾，因此，SOA推薦的是粗粒度設計。這點非常重要。
4）服務應該鬆散耦合
服務客戶和服務提供者之間應該實現鬆散耦合，也就是客戶和提供者之間沒有靜態的、編譯時刻的依賴關係。
服務把它履行職責的細節隱蔽起來。
這種隱蔽，幾乎大部分資料都是建議主要通過GoF 的外觀模式（Facade）實現。
5）服務應該是可以被發現並且支持內省的
SOA的靈活性和可複用性另外一個關鍵點，就是動態發現和綁定的概念。
服務和客戶之間沒有任何靜態連接，SOA客戶通過註冊表來查找它們想要的功能，而不是使用編譯的時候靜態連接。因此，服務和客戶都可以自由修改。
服務還可以在一個有限的時間內被提供，這就是說它們可以被租借，當客戶超過有效時間以後，將會被迫轉回到註冊表，重新綁定合約或者選擇另外的合約。
6）服務是獨立於傳輸機制的
客戶使用網絡來訪問和使用服務，SOA 應該獨立於訪問服務的網絡種類，服務獨立於用來訪問他的傳輸機制，意味着需要建立一個適配器來支持訪問它的各種傳輸機制。通常情況下，適配器需要根據情況來構造（HTTP或者RMI），同一個適配器，也可以被多個服務所使用。
7）服務的位置對客戶是透明的
服務的位置對客戶透明，實施上表達了客戶調用服務的時候，並不需要關心服務具體的位置。這就使SOA在實現過程具有巨大的靈活性。服務可以被放到最方便的地方去，必要的時候（比如企業整頓），服務業可以放到第三方提供者那裏。或者服務中斷的時候，可以把服務請求轉發到完全不同的另一個地點。
8）服務應該是獨立於平臺的
服務應該獨立於平臺和操作系統。
對於Web 服務來說，雖然在理論上，Java和.NET使用着相同的協議和標準，因此，進行互操作是沒有問題的，但實際上，由於SOAP、協議中有很多模糊和未定義部分，所以，這之間的互操作還是存在不少問題，需要我們認真加以研究和試驗。
三、構建SOA架構時應該注意的問題
當架構師基於SOA來構建一個企業級的系統架構的時候，一定要注意對原有系統架構中的集成需求進行細緻的分析和整理。基於SOA的企業系統架構通常都是在現有系統架構投資的基礎上發展起來的，我們並不需要徹底重新開發全部的子系統。
SOA可以通過利用當前系統已有的資源(開發人員、軟件語言、硬件平臺、數據庫和應用程序)來重複利用系統中現有的系統和資源。SOA是一種可適應的、靈活的體系結構類型，基於SOA構建的系統架構可以在系統的開發和維護中縮短產品上市時間，因而可以降低企業系統開發的成本和風險。
四、服務粒度的控制
當SOA架構師構建一個企業級的SOA系統架構的時候，關於系統中最重要的元素，也就是SOA系統中的服務的構建有一點需要特別注意的地方，就是對於服務粒度的控制。
服務粒度的控制SOA系統中的服務粒度的控制是一項十分重要的設計任務。通常來說，對於將暴露在整個系統外部的服務推薦使用粗粒度的接口，而相對較細粒度的服務接口通常用於企業系統架構的內部。
五、案例：電源銷售服務系統高層架構
這裏只列出了初步的頂層架構。
設計中注意了幾個問題：
1，對於管理層和客戶，主要從使用方便性考慮，採用瀏覽器。
2，對於工作人員，因爲要處理的內容比較複雜，採用應用程序，但是一個免維護的瘦客戶端。
3，瘦客戶段並不是指代碼越少越好或者功能越少越好，而是把易變的、需要配置的、需要集中處理的內容轉向應用程序服務器。事實上，客戶端的功能越強，越能緩解服務器的壓力。
4，某些特殊的專業通訊聯繫（比如信用卡授權機構），可以由客戶段直接完成，並不一定一切都通過服務器，但需要向服務器提交必要的信息。
5，對於集中處理的部分，採用大粒度設計，以緩解網絡壓力。
6，由於服務方採用無狀態模式，所以要嚴格控制客戶調用信息的時間，對於需要長時間傳輸的信息，可以採用其它通道完成。
7，對於客戶應用程序，某些不是十分大的，變化頻度不是十分高的，調用頻度比較高的數據，可以在客戶端建立緩存，並且可以建立關聯的映像表，這樣就可以對避免對最主要的數據處理的擠壓，提高數據庫的應用效率，但要考慮修改數據時候的併發策略。
第八節 軟件架構的質量描述和評估
一、軟件架構的創建原則
每個項目最開始的時候，是構架師最重要的時刻，在創建架構的過程中，可以依照下面的原則：
架構應該是精煉的；
架構應該是平易近人的；
架構應該是易讀的；
架構應該是容易理解的；
架構應該是可信的；
架構不一定要是完美無缺的；
不一定要一開始就做大的設計，如果在模型完善和實現之間作個選擇的話，選擇實現它；
做最簡單和可行的事情，不要排除未來的需求；
架構是共享的財產；
讓所有的涉衆都參加進來，但還要能控制局面；
架構組的規模應該小；
軟件架構需要做的事情是：
理解需求：
特別是非功能性需求，或者叫品質需求。
創建或者選擇架構：
儘可能使用架構師熟悉的方法、技術和實踐來滿足，使用不爲人所知的方法來創建架構是要冒一定風險的。
爲了識別好的架構方案，可以採用下面的檢查列表，作爲可能誤入岐途的早期預警徵兆：
1）架構被迫要求滿足當前組織習慣。
當軟件組織的習慣與需求不一致的時候，被迫滿足組織的習慣，很容易誤入岐途，很多情況下，適當的妥協是可以的，但架構的完整性應該儘可能保持。
2）有太多的最高層架構組件（複雜性太高）。
如果這些組件的數目達到一定的級別（一般爲25個），架構就已經太複雜了，以至於無法保證項目本身概念的完整性。
3）某個特定需求超過了設計中的其它需求。
當某個目標高於其它一切需求的時候，那就要考慮這個目標可能只是投資商、項目經理、甚至是構架師的偏好，某個需求高於一切的時候，往往不能兼顧其它的需求。
4）架構依賴於平臺提供的選擇。
實際上一個高度易用性的項目是不能受平臺制約的。
5）使用某些專用的組件，而不使用同樣好的標準組件。
不要被花哨的設計和有趣的設計所迷惑，有很多能力可以使用標準組件來完成的。
6）組件的定義劃分來自於硬件的劃分。
組件的設計過程是不考慮硬件結構的，否則軟件就缺乏拓展性。
二、品質屬性
軟件架構的品質屬性，可以通過下面幾個方面來描述，請試試能不能定量的描述。
1）性能
每個用例的預期響應時間是多少。
平均/最慢/最快的預期響應時間是多少。
需要使用哪些資源（CPU,局域網等）。
需要消耗多少資源。
使用什麼樣的資源分配策略。
預期的並行進程有多少個。
有沒有特別耗時的計算過程。
服務器是單線程還是多線程。
有沒有多個線程同時訪問共享資源的問題，如果有，如何來管理。
不好的性能會在多大程度上影響易用性。
響應時間是同步的還是異步的。
系統在一天、一週或者一個月，系統性能變化是怎樣的。
預期的系統負載增長是怎樣的。
2）可用性
系統故障有多大的影響。
如何識別是硬件故障還是軟件故障。
系統發生故障後，能多快恢復。
在故障情況下，有沒有備用系統可以接管。
如何才能知道，所有的關鍵功能已經被複制了呢。
如何進行備份，備份和恢復系統需要多長時間。
預期的正常工作時間是多少小時。
每個月預期的正常工作時間是多少。
3）可靠性
軟件或者硬件故障的影響是什麼。
軟件性能不好會影響可靠性嗎。
不可靠的性能對業務有多大影響。
數據完整性會受到影響嗎。
4）功能
系統滿足用戶提出的所有功能需求了嗎。
系統如何應付和適應非預期的需求。
5）易用性
用戶界面容易理解嗎。
界面需要滿足殘疾人的需求嗎。
開發人員覺得用來開發的工具是易用的和易理解的嗎。
6）可移植性
如果使用專用開發平臺的話，用它的優點真的比缺點多嗎。
建立一個獨立層次的開銷值得嗎。
系統的可移植性應該在哪一級別來提供呢（應用程序、應用服務器、操作系統還是硬件級別）。
7）可重用性
該系統是一系列的產品線的開始嗎。
其它建造的系統有多少和現有系統有關呢？如果有，其他系統能重用嗎。
哪些現有組件是可以重用的。
現有的框架和其它代碼能夠被重用嗎。
其它應用程序可以使用這個系統的基礎設施嗎。
建立可重用的的組件，代價、風險、好處是什麼。
8）集成性
於其它系統進行通信的技術是基於現行的標準嗎。
組件的接口是一致的和容易理解的嗎。
有解釋組件接口的過程嗎。
9）可測試性
有可以測試語言類、組件和服務的工具、過程和技術嗎。
框架中有可以進行單元測試的接口嗎。
有自動測試工具可以用嗎。
系統可以在測試器中運行嗎。
10）可分解性
系統是模塊化的嗎。
系統之間有序多依賴關係嗎。
對一個模塊的修改會影響其它模塊嗎。
11）概念完整性
人們理解這個架構嗎。是不是有人問很多很基本的問題呢。
架構中有沒有自相矛盾的決策。
新的需求很容易加到架構中來嗎。
12）可完成性
有足夠的時間、金錢和資源來建立架構基準和整個項目嗎。
架構是不是太複雜。
架構足夠的模塊化來支持並行開發嗎。
是不是有太多的技術風險呢。
上述問題，給我們提供了一個線索，在回答這些問題的時候，我們對初始設計的改進方向，就已經一目瞭然了。