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 實現并驗證軟件架構

◎ 好的策略必須是一再求證、測試、發現瑕疵漏洞，另想途徑或方法來彌補策略不足，有時甚至得全盤放棄，重新策劃。-- 張明正，《擋不住的趨勢》

◎ 架構原型對功能性需求的實現非常有限，那么“架構驗證”要驗證什么？

   答案是要驗證架構對質量屬性需求的支持程度，包括運行期質量屬性和開發期質量屬性。

◎ 驗證架構的兩種方法：

   * 原型法。
     對于項目型開發，常采用“原型法”。即對一組架構設計決策在非功能需求方面的滿足程度進行驗證。該原型往往是演進型，而非拋棄型。
   * 框架法。
     對于產品型開發，采用“框架法”有更多優點。該方法將架構設計方案用框架的形式實現，并在此基礎上進行評估驗證。在框架實現后，在框架基礎上實現部分應用 的功能，即實現一個小的垂直原型，從而進行實際非功能測試和開發期質量屬性評價。