重溫軟件架構設計-程序員向架構師轉型必備

這本書是溫老師2012年出版的書，講述的是要想成爲一個入門架構師，從需求到底如何對應到架構設計，裏面有不少方法論和工具，能夠幫助咱們打通需求到架構的道路。本書2014年末讀過一遍，但一直沒空整理，最近又抽空從新學習了一遍，把書中的核心內容整理出來，一是造成知識結構幫助記憶，二是能夠幫助別人快速掌握本書的核心知識，具體內容以下：

（一）基本概念

1. 軟件架構指的是計算機與組件之間的交互，同時也能夠理解爲模塊、職責劃分、接口定義、交互機制、開發技術、組織元素、子系統、非功能性等一系列架構問題的樹形決策
2. 軟件架構一方面從大局着手，就技術方面的重大問題做出決策，構造一個由粗粒度模塊組成的解決方案，從而能夠把不一樣模塊分配給不一樣小組分頭開發；另外一方面，軟件架構設計方案規定了各模塊之間如何交互的機制和結構，在開發小組之間起到溝通橋樑和合做契約的做用。（模塊劃分及之間的相互關係）
3. 架構設計時須要考慮的幾種角色人員：
1. 用戶：UI、功能需求、易用性
2. 客戶：業務規則、業務目標、上線期限、預算
3. 開發人員：模塊設計、交互方式、可重用性
4. 管理人員：模塊劃分及交互關係、配置管理

（二）從需求到架構的步驟

1. 尋找需求，包括功能需求、質量需求、約束性需求，從中選出重大須要，特點需求以及高風險需求，並使用必定的領域建模術語進行需求描述；
2. 根據選擇的大需求進行概念架構，選取架構大方向，包括劃分頂級子系統，選型架構風格，選型開發技術，選型集成技術，選型二次開發技術；
3. 將概念架構進一步細化到模塊+接口級，獲得邏輯架構設計（模塊劃分、接口定義、領域模型）、開發架構設計（技術選型、文件劃分、編譯關係）、運行架構設計（技術選型、控制流劃分、同步關係）、物理架構設計（硬件分佈、軟件部署、方案優化）、數據架構設計（技術選型、存儲格式、數據分佈）；
4. 對細化後的架構進行驗證。

（三）每一步驟的關鍵內容注意事項

1. 尋找需求相關：
• 尋找需求時利用上下文圖來描述待開發系統與周圍全部事物之間的界限與聯繫，明確系統主體，明確系統使用方，明確系統須要與哪些系統進行交互；
• 需求分析全過程：需求捕獲（需求採集卡）--->需求分析（交付需求規格說明書）--->系統分析（交付數據流圖、分析類圖、魯棒圖、序列圖等），執行步驟爲：明確系統目標--->肯定範圍+Feature+上下文圖--->畫用例圖--->寫用例規約
• 上下文圖因爲在明確系統需求時，用以肯定系統用戶、系統範圍、系統交互的對象
• 需求規格說明書裏精確闡述系統必須提供的功能，必須到達的質量屬性指標以及必須遵照的約束。其中最經常使用的用例技術聚焦每一個系統應該提供的具體行爲功能，刻畫系統爲外部用戶或系統提供的服務。
• 需求分爲組織級、用戶級、開發級，每一個級別有各自的功能需求、質量屬性（運行期、開發期）以及約束（業務環境、使用環境、構建環境、技術環境），需求是一張二維表。
2. 領域建模相關
• 將業務概念以可視化的方式抽象成一套模型，在uml中用類圖和狀態圖來表示；
• 領域模型是需求到設計的中間轉化過程，鏈接業務端與開發端兩方人員，使得他們能夠進行溝通
3. 概念架構相關
• 關鍵需求決定架構，關鍵需求包括：最具表明的需求、必須實現的需求、會爲系統帶來風險的需求、獨特需特殊考慮的需求；
• 概念架構針對重大需求、特點需求、高風險需求造成的高層架構設計成果，用於界定系統的高層組件以及組件間的關係，對高層組件進行籠統界定而不涉及接口細節，是直指目標的設計思想、重大選擇；
• 概念架構的設計階段須要根據需求畫出用例圖，魯棒圖能夠幫助檢查用例規約是否正確，其包含3個要素（交互、行爲、信息）： 邊界對象：模擬外部環境和將來系統之間的交互，負責接收外部輸入、處理內部內容的解釋並表達或傳遞相應的結果；交互對象通常是外部系統、設備、人；控制對象：對行爲進行封裝，描述用例中事件流的控制行爲，行爲通常分爲應用邏輯、業務邏輯、數據訪問邏輯；實體對象：對信息進行描述，每每來自領域建模裏的對象，信息指的就是內存或DB中的數據；
• 魯棒圖和場景卡作完後就開始選擇架構風格，劃分頂級子系統，並對架構風格、開發技術選型、二次開發技術選型、集成技術選型等四個方面進行肯定。
• 魯棒圖畫完通常功能需求都知足了，接下來須要使用場景卡即目標-場景-決策的方式來考慮多種非功能的狀況，提高架構設計的質量。
• 概念架構中須要對功能模塊進行劃分，通常以使用人員的分類來劃分，同時兼顧開發上涉及的類、函數、數據結構等共性的功能劃分到同一模塊裏，其中公用類的尋找能夠經過用例驅動的方式，找到魯棒圖對應的公用類，進而將這些圖對應的功能劃分同一模塊裏，固然須要注意通用公共模塊如日誌、安全驗證等劃分到獨立模塊。若是是水平劃分模塊，則是所謂的分層架構；
• 常見兩種分層模式，1是分爲展示層、業務層、數據層；2是分爲UI用戶界面層、SI系統交互層、PD問題領域層、DM數據管理層；
• 一個獨立的功能用例便是某一功能模塊在具體某一層的功能集合。
4. 架構細化
• 架構設計迭代先邏輯架構再物理架構，邏輯架構迭代以交互爲主線，包括用戶交互、系統交互、業務邏輯、數據訪問四個方面逐步進行迭代，每次迭代後進行物理架構的迭代，以上述四個方面爲依據，首先找到須要的服務器數量，而後設計他們之間的關係及備份關係。如此往復，逐步細化。
• 邏輯架構：規定了軟件系統由哪些邏輯元素組成以及這些邏輯元素之間的關係。（層、子系統、模塊等的劃分決定+交互接口和交互機制[方法調用、RMI、消息]）
• 物理架構：規定了組成軟件系統的物理元素（進程、線程、類的運行時實例等），以及這些元素之間的關係和它們部署到硬件上的策略。
• 從邏輯架構（模塊劃分、接口定義、領域模型）、物理架構（硬件分佈、軟件部署、方案優化）、運行架構（技術選型、控制流劃分、同步關係）、數據架構（技術選型、存儲格式、數據分佈）、開發架構（技術選型、工程分佈、編譯關係）5個方面，15個內容來細化架構。
5. 架構驗證：水平原型、垂直原型、拋棄原型、演進原型

 

架構設計的核心在於經過UI把對人、經過SI把對外部系統或操做系統、經過DM把讀數據管理等屏蔽並封裝起來以使得PD更專一在本身的業務邏輯實現上。