《软件架构设计》读书笔记
前言
春節前后花了將近兩個月時間才把《軟件架構設計》一書看完。此書緊緊圍繞“軟件架構設計”這一主題，非常系統地解析了軟件架構的概念，闡述了切實可行的軟件架構設計方法，給出了可實施性很強的完整的架構設計過程。閱讀此書過程中，常常會發現讓人眼前一亮的引文或觀點。此讀書筆記將《軟件架構設計》中重要的觀點提取出來，進行再一次的歸納和整理。寫這篇筆記的目的一是為了加強將來再次閱讀此書時的針對性；其次也是為自己平時的項目架構實踐提供一份足夠簡明的指導提綱。
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 實現并驗證軟件架構
◎ 好的策略必須是一再求證、測試、發現瑕疵漏洞，另想途徑或方法來彌補策略不足，有時甚至得全盤放棄，重新策劃。-- 張明正，《擋不住的趨勢》
◎ 架構原型對功能性需求的實現非常有限，那么“架構驗證”要驗證什么？
?? 答案是要驗證架構對質量屬性需求的支持程度，包括運行期質量屬性和開發期質量屬性。
◎ 驗證架構的兩種方法：
?? *?原型法。
???? 對于項目型開發，常采用“原型法”。即對一組架構設計決策在非功能需求方面的滿足程度進行驗證。該原型往往是演進型，而非拋棄型。
?? *?框架法。
???? 對于產品型開發，采用“框架法”有更多優點。該方法將架構設計方案用框架的形式實現，并在此基礎上進行評估驗證。在框架實現后，在框架基礎上實現部分應用的功能，即實現一個小的垂直原型，從而進行實際非功能測試和開發期質量屬性評價。
總結
以上是生活随笔為你收集整理的《软件架构设计》读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。
