《軟件架構設計》讀書筆記
2009-12-02 來源：網絡
前言
春節前後花了將近兩個月時間才把《軟件架構設計》一書看完。此書緊緊圍繞“軟件架構設計”這一主題，非常系統地解析了軟件架構的概念，闡述了切實可行的軟件架構設計方法，給出了可實施性很強的完整的架構設計過程。閱讀此書過程中，常常會發現讓人眼前一亮的引文或觀點。此讀書筆記將《軟件架構設計》中重要的觀點提取出來，進行再一次的歸納和整理。寫這篇筆記的目的一是爲了加強將來再次閱讀此書時的針對性；其次也是爲自己平時的項目架構實踐提供一份足夠簡明的指導提綱。
1. 軟件架構概述
1.1 什麼是軟件架構
◎ 軟件架構的概念很混亂。如果你問五個不同的人，可能會得到五種不同的答案。
◎ 軟件架構概念主要分爲兩大流派：
組成派：軟件架構 = 組件 + 交互。
決策派：軟件架構 = 重要決策集。
◎ 組成派和決策派的概念相輔相成。
1.2 軟件架構和子系統、框架之間的關係
◎ 複雜性是層次化的。 --《人月神話》
◎ 好的架構設計必須把變化點錯落有致地封裝到軟件系統的不同部分(即關注點分離)。
通過關注點分離，達到“系統中的一部分發生了變化，不會影響其他部分”的目標。
◎ 軟件單元的粒度：
* 粒度最小的單元通常是“類”。
* 幾個類緊密協作形成“模塊”。
* 完成相對獨立的功能的多個模塊構成了“子系統”。
* 多個子系統相互配合才能滿足一個完整應用的需求，從而構成了軟件“系統”。
* 一個大型企業往往使用多套系統，多套系統通過互操作形成“集成系統”。
◎ 軟件單元的粒度是相對的。同一個軟件單元，在不同場景下我們會以不同的粒度看待它。
◎ 架構(Architecture)不等於框架(Framework)。
框架只是一種特殊的軟件，框架也有架構。
◎ 可以通過架構框架化達到“架構重用”的目的，如很多人都在用 Spring 框架提供的控制反轉和依賴注入來構建自己的架構。
1.3 軟件架構的作用
◎ 如果一個項目的系統架構(包括理論基礎)尚未確定，就不應該進行此係統的全面開發。-- Barry Boehm,《Engineering Context》
◎ 一個缺陷充斥的系統，將始終是一個缺陷充斥的系統。-- Timothy C. Lethbridge,《面向對象軟件工程》
◎ 軟件架構設計爲什麼這麼難？
因爲它是跨越現實世界與計算機世界之間鴻溝的一座橋。
軟件架構設計要完成從面向業務到面向技術的轉換，在鴻溝上架起一座橋樑。
需求 -> 架構設計 -> 軟件架構 -> 系統開發 -> 軟件系統
~~~~~~~~ ~~~~~~~~
◎ 軟件架構對新產品開發的作用：
* 上承業務目標。
* 下接技術決策。
* 控制複雜性。
先進行架構設計，後進行詳細設計和編碼實現，符合“基於問題深度分而治之”的理念。
* 組織開發。
軟件架構方案在小組中間扮演了“橋樑”和“合作契約”的作用。
* 利於迭代開發和增量交付。
以架構爲中心進行開發，爲增量交付提供了良好的基礎。在架構經過驗證之後，可以專注於功能的增量提交。
* 提高質量。
◎ 軟件架構對軟件產品線開發的作用：
* 固化核心知識；
* 提供可重用資產；
* 縮短推出產品的週期；
* 降低開發和維護成本；
* 提高產品質量；
* 支持批量定製。
◎ 軟件產品線：指具有一組可管理的、公共特性的、軟件密集性系統的集合，這些系統滿足特定的市場需求或任務需求，並且按照預定義方式從一個公共的核心資產集開發得到。
軟件產品線架構：針對一個公司或組織內的一系列產品而設計的通用架構。
2. 軟件架構設計方法
2.1 軟件架構爲誰而設計
◎ 架構師應當爲項目相關的不同角色而設計：
* 架構師要爲客戶負責，滿足他們的業務目標和約束條件。
* 架構師要爲用戶負責，滿足他們關心的功能需求和運行期質量屬性。
* 架構師必須顧及處於協作分工“下游”的開發人員。
* 架構師必須考慮“周邊”的管理人員，爲他們進行分工管理、協調控制和評估監控等工作提供清晰的基礎。
2.2 五視圖法
◎ 什麼是軟件架構視圖？
軟件架構視圖是對於從某一視角看到的系統所作的簡化描述，描述中涵蓋了系統的某一特定方面，而省略了與此無關的其他方面。
◎ 軟件架構要涵蓋的內容和決策太多了，超過了人腦“一蹴而就”的能力範圍，因此宜採用“分而治之”的辦法。即通過不同的視圖來描述架構。
◎ 軟件架構的五視圖法：
* 邏輯架構
邏輯架構關注功能。其設計着重考慮功能需求。
* 開發架構
開發架構關注程序包。其設計着重考慮開發期質量屬性，如可擴展性、可重用性、可移植性、易理解性和易測試性等。
* 運行架構
運行架構關注進程、線程、對象等運行時概念，以及相關的併發、同步、通信等問題。
其設計着重考慮運行期質量屬性，例如性能、可伸縮性、持續可用性和安全性等。
* 物理架構
物理架構關注軟件系統最終如何安裝或部署到物理機器。其設計着重考慮“安裝和部署需求”。
* 數據架構
數據架構關注持久化數據的存儲方案。其設計着重考慮“數據需求”。
2.3 從概念性架構到實際架構
◎ 少就是多 (Less is more.)。 -- 密斯·凡德羅
◎ 概念性架構是對系統設計的最初構想。
◎ 一般來說，實際的軟件架構設計過程是，先進行概念性架構的設計，把最關鍵的設計要素和交互機制確定下來，然後再考慮具體技術的運用，設計出實際架構。
2.4 架構設計中的關鍵要素及解決策略
◎ 策略是制勝的關鍵。-- 張明正，《擋不住的趨勢》
◎ 最好的軟件開發人員都知道一個祕密：美的東西比醜的東西創建起來更廉價，也更快捷。-- Robert C. Martin, 《軟件之美》
◎ 時間就是系統架構的生命。-- Philippe Kruchten
◎ 方法產生於恐懼。
◎ 面對時間緊迫的壓力，我們有理由質疑那種不顧時間花銷、一味追求軟件架構高質量的做法。軟件架構是軟件系統質量的核心，必須足夠重視，但在不適當的時候“用時間換完美”會毀掉整個項目。
◎ 架構設計並非“好的就是成功的”，而是“適合的纔是成功的”。
◎ 軟件架構設計中的關鍵要素及解決策略：
關鍵要素 策略
------------------------------------ -----------------
1. 是否遺漏了至關重要的非功能需求？ 全面認識需求。
2. 能否馴服數量巨大且頻繁變化的需求？ 關鍵需求決定架構。
3. 能否從容地設計軟件架構的不同方面？ 多視圖探尋架構。
4. 是否及早驗證架構方案並作出了調整？ 及早驗證架構。
2.5 軟件架構要設計到什麼程度
◎ 軟件系統的架構涵蓋了整個系統，儘管架構的有些部分可能只有“一寸深”。-- Ivar Jacobson, 《統一軟件開發過程之路》
◎ 軟件架構是團隊開發的基礎。
◎ 軟件架構要設計到什麼程度？
* 由於項目的不同、開發團隊情況的不同，軟件架構的設計程度會有不同。
* 軟件架構應當爲開發人員提供足夠的指導和限制。
◎ 高來高去式架構設計的症狀：
* 缺失重要架構視圖。
遺漏了某些重要視圖，從而遺漏了對團隊某些角色的指導。
* 淺嘗輒止、不夠深入。
將重大技術風險遺留到後續開發中。
* 名不副實的分層架構。
對各層之間交互接口和交互機制的設計嚴重不足。
3. 軟件架構設計過程
3.1 軟件架構設計過程總覽
◎ 一般的軟件過程：
概念化階段 -> 分析階段 -> 架構設計階段 -> 並行開發與測試階段 -> 驗收與交付階段
──┬── ──┬─ ───┬── ────┬──── ───┬───
↓ ↓ ↓ ↓ ↓
願景 需求 架構 可執行系統 交付的系統
◎ 軟件架構設計過程：
需求分析 -> 領域建模 -> 確定關鍵需求 -> 概念性架構設計 -> 細化架構 -> 驗證架構
│ │ └──────┬──────┘ └────┬───┘
│ │ 概念性架構 實際架構
└───┬────┘ └───────┬──────┘
分析階段 架構設計階段
3.2 需求分析
3.2.1 幾個概念
◎ 需求捕獲 vs 需求分析 vs 系統分析
* 需求捕獲是獲取知識的過程，知識從無到有。
* 需求分析是挖掘和整理知識的過程，它在已掌握知識的基礎上進行。
* 系統分析？如果說需求分析致力於“做什麼”，那麼系統分析則涉及“怎麼做”。
3.2.2 架構師必須掌握的需求知識
◎ 軟件架構師不必是需求捕獲專家，也不必是編寫《軟件需求規格說明書》的專家。
但他一定應在需求分類、需求折衷和需求變更的研究方面是專家，否則他和其他軟件架構師相比，就輸在了“起跑線”上。
◎ 軟件需求的類型
┌ 功能需求 ┌ 運行期質量屬性
軟件需求 ┤ ┌ 質量屬性 ┤
└ 非功能需求 ┤ └ 開發期質量屬性
└ 約束
◎ 軟件質量屬性分類方式
運行期質量屬性
* 性能 (Performance)
* 安全性 (Security)
* 易用性 (Usability)
* 持續可用性 (Availability)
* 可伸縮性 (Scalability)
* 互操作性 (Interoperability)
* 可靠性 (Reliability)
* 魯棒性 (Robustness)
開發期質量屬性
* 易理解性 (Understandability)
* 可擴展性 (Extensibility)
* 可重用性 (Reusability)
* 可測試行 (Testability)
* 可維護性 (Maintainability)
* 可移植性 (Portability)
3.3 領域建模
◎ 就像《高效能人士的七個習慣》提到的“由內而外全面造就自己”的觀點一樣，對待軟件開發，要具備“由內而外造就軟件”的理念。
◎ 想讓軟件系統隨需應變嗎？請給軟件一個支持變化的“心”。
◎ 什麼是領域模型？
領域模型是對實際問題領域的抽象表示，它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。
◎ 領域建模和需求分析活動是相互伴隨、互相支持、交疊演進的。
◎ 領域模型對軟件架構乃至整個軟件系統開發工作的作用：
* 探索複雜問題、固化領域知識；
* 決定功能範圍、影響可擴展性；
* 提供交流基礎、促進有效溝通。
3.4 確定關鍵需求
◎ 功能、質量和商業需求的某個集合“塑造”了架構。-- Len Bass, 《軟件架構實踐(第2版)》
◎ 關鍵需求決定架構，其餘需求驗證架構。
◎ 什麼是對軟件架構關鍵的需求？
* 關鍵的功能需求。
* 關鍵的質量屬性需求。
* 關鍵的商業需求。
◎ 如何確定關鍵需求？
┌> 確定關鍵功能需求 ┐
● -> 全面整理需求 -> 分析約束性需求 ┤ ├> ●
└> 確定關鍵質量屬性需求 ┘
3.5 概念性架構設計
◎ 概念性架構設計的步驟(這三個步驟以迭代方式進行)：
1. 魯棒性分析；
2. 引入架構模式；
3. 質量屬性分析。
3.5.1 魯棒性分析
◎ 所謂魯棒性分析是這樣一種方法：通過分析用例規約中的事件流，識別出實現用例規定的功能所需的主要對象及其職責，形成以職責模型爲主的初步設計。
◎ 魯棒性分析是從功能需求向設計方案過度的第一步，所獲得的初步設計是一種理想化的職責模型，它的重點是識別組成軟件系統的高級職責塊、規劃它們之間的關係。
◎ 魯棒性分析填補了分析和設計之間的鴻溝。
◎ 魯棒圖包含三種元素：邊界對象、控制對象和實體對象。(見書P196)
3.5.2 引入架構模式
◎ 較爲經典的幾種架構模式：
分層、MVC、微內核、基於元模型的架構、管道-過濾器。
◎ 關於架構模式的幾點說明：
* 分層
避免名不副實的分層架構，即對各層之間交互接口和交互機制的設計嚴重不足。
* 微內核
缺點：設計和實現的複雜性；性能較低。
優點：擴展性強，可移植性強，軟件系統的生命週期長。
3.5.3 質量屬性分析
◎ “屬性-場景-決策”表方法。舉例如下：
┌────┬─────────┬─────────────────────┐
│屬性 │場景 │決策 │
├────┼─────────┼─────────────────────┤
│可擴展性│數據庫類型可替換 │建立數據庫存取層 │
├────┼─────────┼─────────────────────┤
│ │允許加載第三方模塊│採用插件機制 │
├────┼─────────┼─────────────────────┤
│... │... │... │
└────┴─────────┴─────────────────────┘
3.6 細化架構設計
◎ 架構細化工作主要體現在基於五視圖方法進行架構細化：
約束
↓
┌───────┐
領域模型 -> │基於五視圖方法│
關鍵需求 -> │ │-> 架構方案
概念架構 -> │ 進行架構細化 │
└───────┘
↑
經驗
◎ 架構細化設計的工作內容：
┌───────┬──────────────────────────┐
│ 架構設計視圖 │ 設計任務 │
├───────┼──────────────────────────┤
│ 邏輯架構 │ 細化功能單元； │
│ │ 發現通用機制； │
│ │ 細化領域模型； │
│ │ 確定子系統接口和交互機制。 │
├───────┼──────────────────────────┤
│ 開發架構 │ 確定要開發或直接利用的程序包之間的依賴關係； │
│ │ 確定採用的技術； │
│ │ 確定採用的框架等。 │
├───────┼──────────────────────────┤
│ 數據架構 │ 持久化數據存儲方案； │
│ │ 數據傳遞、數據複製、數據同步等策略(可選)。 │
├───────┼──────────────────────────┤
│ 運行架構 │ 確定引入哪些進程與線程； │
│ │ 確定主動對象、被動對象，以及控制關係； │
│ │ 處理進程線程的創建、銷燬、通信機制、資源爭用等； │
│ │ 協議設計。 │
├───────┼──────────────────────────┤
│ 物理架構 │ 確定物理配置方案； │
│ │ 確定如何將目標程序映射到物理節點。 │
└───────┴──────────────────────────┘
◎ 邏輯架構設計中，“發現通用機制”是應被特別強調的。
機制(Mechanism)是模式的實例。機制是特定上下文中重複出現的問題的特定解決方案。
具有良好架構的系統具備概念完整性。它通過對系統架構建立一種清晰的認識來發現通用的抽象和機制。利用這種共性使最終產生的系統結構更爲簡單。
3.7 實現並驗證軟件架構
◎ 好的策略必須是一再求證、測試、發現瑕疵漏洞，另想途徑或方法來彌補策略不足，有時甚至得全盤放棄，重新策劃。-- 張明正，《擋不住的趨勢》
◎ 架構原型對功能性需求的實現非常有限，那麼“架構驗證”要驗證什麼？
答案是要驗證架構對質量屬性需求的支持程度，包括運行期質量屬性和開發期質量屬性。
◎ 驗證架構的兩種方法：
* 原型法。
對於項目型開發，常採用“原型法”。即對一組架構設計決策在非功能需求方面的滿足程度進行驗證。該原型往往是演進型，而非拋棄型。
* 框架法。
對於產品型開發，採用“框架法”有更多優點。該方法將架構設計方案用框架的形式實現，並在此基礎上進行評估驗證。在框架實現後，在框架基礎上實現部分應用的功能，即實現一個小的垂直原型，從而進行實際非功能測試和開發期質量屬性評價。