下載地址：網盤下載

作者簡介

編輯溫昱 資深諮詢顧問，軟體架構專家。軟體架構思想的傳播者和積極推動者，中國軟體技術大會傑出貢獻專家。十五年系統規劃、架構設計和研發管理經驗，在金融、航空、多媒體、電信、中介軟體平臺等領域負責和參與多個大型系統的規劃、設計、開發與管理。[1]

內容簡介

編輯從“基礎篇”、到“設計過程篇”、到“模組劃分專題”，《軟體架構設計:程式設計師向架構師轉型必備(第2版)》覆蓋了架構設計的關鍵技能項，並且對於架構設計過程中可能出現的各種問題給與瞭解答。

目錄

編輯第1章 從程式設計師到架構師 [1]1.1 軟體業人才結構1.1.1 金字塔型，還是橄欖型？1.1.2 從程式設計師向架構師轉型1.2 本書價值1.2.1 閱讀路徑1：架構設計入門1.2.2 閱讀路徑2：領會大系統架構設計1.2.3 閱讀路徑3：從需求到架構的全過程1.2.4 閱讀路徑4：結合工作，解決實際問題第1部分 基本概念篇第2章 解析軟體架構概念2.1 軟體架構概念的分類2.1.1 組成派2.1.2 決策派2.1.3 軟體架構概念大觀2.2 概念思想的解析2.2.1 軟體架構關注分割與互動2.2.2 軟體架構是一系列有層次的決策2.2.3 系統、子系統、框架都可以有架構2.3 實際應用（1）——團隊對架構看法不一怎麼辦2.3.1 結合手上的實際工作來理解架構的含義2.3.2 這樣理解“架構”對嗎2.3.3 工作中找答案：先看部分設計2.3.4 工作中找答案：反觀架構概念的體現第3章 理解架構設計檢視3.1 軟體架構為誰而設計3.1.1 為使用者而設計3.1.2 為客戶而設計3.1.3 為開發人員而設計3.1.4 為管理人員而設計3.1.5 總結3.2 理解架構設計檢視3.2.1 架構檢視3.2.2 一個直觀的例子3.2.3 多組涉眾，多個檢視3.3 運用“邏輯檢視+物理檢視”設計架構3.3.1 邏輯架構3.3.2 物理架構3.3.3 從“邏輯架構+物理架構”到設計實現3.4 實際應用（2）——開發人員如何快速成長3.4.1 開發人員應該多嘗試設計3.4.2 實驗專案：案例背景、訓練目標3.4.3 邏輯架構設計（迭代1）3.4.4 物理架構設計（迭代1）3.4.5 邏輯架構設計（迭代2）3.4.6 物理架構設計（迭代2）第2部分 實踐過程篇第4章 架構設計過程4.1 架構設計的實踐脈絡4.1.1 洞察節奏：3個原則4.1.2 掌握過程：6個步驟4.2 架構設計的速查手冊4.2.1 需求分析4.2.2 領域建模4.2.3 確定關鍵需求4.2.4 概念架構設計4.2.5 細化架構設計4.2.6 架構驗證第5章 需求分析5.1 需求開發（上）——願景分析5.1.1 從概念化階段說起5.1.2 願景5.1.3 上下文圖5.1.4 願景分析實踐要領5.2 需求開發（下）——需求分析5.2.1 需求捕獲vs.需求分析vs.系統分析5.2.2 需求捕獲及成果5.2.3 需求分析及成果5.2.4 系統分析及成果5.3 掌握的需求全不全5.3.1 二維需求觀與ADMEMS矩陣5.3.2 功能5.3.3 質量5.3.4 約束5.4 從需求向設計轉化的“密碼”5.4.1 “理性設計”還是“拍腦袋”5.4.2 功能：職責協作鏈5.4.3 質量：完善驅動力5.4.4 約束：設計並不自由5.5 實際應用（3）——PM Suite貫穿案例之需求分析5.5.1 PM Suite案例背景介紹5.5.2 第1步：明確系統目標5.5.3 第2步：範圍 + Feature + 上下文圖5.5.4 第3步：畫用例圖5.5.5 第4步：寫用例規約5.5.6 插曲：需求啟發與需求驗證5.5.7 插曲：非功能需求5.5.8 《需求規格》與基於ADMEMS矩陣的需求評審第6章 用例與需求6.1 用例技術族6.1.1 用例圖6.1.2 用例簡述、使用者故事6.1.3 用例規約6.1.4 用例實現、魯棒圖6.1.5 4種技術的關係6.2 用例技術族的應用場景6.2.1 用例與需求分析6.2.2 用例與需求文件6.2.3 用例與需求變更6.3 實際應用（4）——用例建模夠不夠？流程建模要不要6.3.1 軟體事業部的故事6.3.2 小型方法：需求分析的三套實踐論（上）6.3.3 中型方法：需求分析的三套實踐論（中）6.3.4 大型方法：需求分析的三套實踐論（下）6.3.5 PM Suite應用一幕第7章 領域建模7.1 什麼是領域模型7.1.1 領域模型“是什麼”7.1.2 領域模型“什麼樣”7.1.3 領域模型“為什麼”7.2 需求人員視角——促進使用者溝通、解決分析癱瘓7.2.1 領域建模與需求分析的關係7.2.2 溝通不足7.2.3 分析癱瘓7.2.4 案例：多步領域建模，熟悉陌生領域7.3 開發人員視角——破解“領域知識不足”死結7.3.1 領域模型作為“理解領域的手段”7.3.2 案例：從詞彙表到領域模型7.4 實際應用（5）——功能決定如何建模，模型決定功能擴充套件7.4.1 案例：模型決定功能擴充套件7.4.2 實踐：功能決定如何建模7.4.3 PM Suite領域建模實錄（1）——類圖7.4.4 PM Suite領域建模實錄（2）——狀態圖7.4.5 PM Suite領域建模實錄（3）——可擴充套件性第8章 確定關鍵需求8.1 眾說紛紜——什麼決定了架構8.1.1 用例驅動論8.1.2 質量決定論8.1.3 經驗決定論8.2 真知灼見——關鍵需求決定架構8.2.1 “目標錯誤”比“遺漏需求”更糟糕8.2.2 關鍵需求決定架構，其餘需求驗證架構8.3 付諸行動——如何確定關鍵需求8.3.1 確定關鍵質量8.3.2 確定關鍵功能8.4 實際應用（6）——小系統與大系統的架構分水嶺8.4.1 架構師的“拿來主義”困惑8.4.2 場景1：小型PMIS（專案型ISV背景）8.4.3 場景2：大型PM Suite（產品型ISV背景）8.4.4 場景3：多個自主產品組成的方案（例如IBM）8.4.5 “拿來主義”雖好，但要合適才行第9章 概念架構設計9.1 概念架構是什麼9.1.1 概念架構是直指目標的設計思想、重大選擇9.1.2 案例1：汽車電子AUTOSAR——跨平臺複用9.1.3 案例2：騰訊QQvideo架構——高效能9.1.4 案例3：微軟MFC架構——簡化開發9.1.5 總結9.2 概念架構設計概述9.2.1 “關鍵需求”進，“概念架構”出9.2.2 概念架構≠理想化架構9.2.3 概念架構≠細化架構9.3 左手功能——概念架構設計（上）9.3.1 什麼樣的鴻溝，架什麼樣的橋9.3.2 魯棒圖“是什麼”9.3.3 魯棒圖“畫什麼”9.3.4 魯棒圖“怎麼畫”9.4 右手質量——概念架構設計（下）9.4.1 再談什麼樣的鴻溝，架什麼樣的橋9.4.2 場景思維9.4.3 場景思維的工具9.4.4 目標—場景—決策表應用舉例9.5 概念架構設計實踐要領9.5.1 要領1：功能需求與質量需求並重9.5.2 要領2：概念架構設計的1個決定、4個選擇9.5.3 要領3：備選設計9.6 實際應用（7）——PM Suite貫穿案例之概念架構設計9.6.1 第1步：通過初步設計，探索架構風格和高層分割9.6.2 第2步：選擇架構風格，劃分頂級子系統9.6.3 第3步：開發技術、整合技術與二次開發技術的選型9.6.4 第4步：評審3個備選架構，敲定概念架構方案第10章 細化架構設計10.1 從2檢視方法到5檢視方法10.1.1 回顧：2檢視方法10.1.2 進階：5檢視方法10.2 程式設計師向架構師轉型的關鍵突破——學會系統思考10.2.1 系統思考之“從需求到設計”10.2.2 系統思考之“5個設計檢視”10.3 5檢視方法實踐——5個檢視、15個設計任務10.3.1 邏輯架構=模組劃分+介面定義+領域模型10.3.2 開發架構=技術選型+檔案劃分+編譯關係10.3.3 物理架構=硬體分佈+軟體部署+方案優化10.3.4 執行架構=技術選型+控制流劃分+同步關係10.3.5 資料架構=技術選型+儲存格式+資料分佈10.4 實際應用（8）——PM Suite貫穿案例之細化架構設計10.4.1 PM Suite接下來的設計任務10.4.2 客戶端設計的相關說明10.4.3 細化領域模型時應注意的兩點第11章 架構驗證11.1 原型技術11.1.1 水平原型vs.垂直原型，拋棄原型vs.演進原型11.1.2 水平拋棄原型11.1.3 水平演進原型11.1.4 垂直拋棄原型11.1.5 垂直演進原型11.2 架構驗證11.2.1 原型法11.2.2 框架法11.2.3 測試執行期質量，評審開發期質量第3部分 模組劃分專題第12章 粗粒度“功能模組”劃分12.1 功能樹12.1.1 什麼是功能樹12.1.2 功能分解≠結構分解12.2 藉助功能樹，劃分粗粒度“功能模組”12.2.1 核心原理：從“功能組”到“功能模組”12.2.2 第1步：獲得功能樹12.2.3 第2步：評審功能樹12.2.4 第3步：粗粒度“功能模組”劃分12.3 實際應用（9）——對比MailProxy案例的4種模組劃分設計12.3.1 設計12.3.2 設計的優點、缺點12.4 實際應用（10）——做總體，要提交啥樣的“子系統劃分方案”第13章 如何分層13.1 分層架構13.1.1 常見模式：展現層、業務層、資料層13.1.2 案例一則13.1.3 常見模式：UI層、SI層、PD層、DM層13.1.4 案例一則13.2 分層架構實踐技巧13.2.1 設計思想：分層架構的“封裝外部互動”思想13.2.2 實踐技巧：設計分層架構，從上下文圖開始13.3 實際應用（11）——對比MailProxy案例的 4種模組劃分設計13.3.1 設計13.3.2 設計的優點、缺點第14章 用例驅動的模組劃分過程14.1 描述需求的序列圖 vs. 描述設計的序列圖14.1.1 描述“內外對話” vs. 描述“內部協作”14.1.2 《用例規約》這樣描述“內外對話”14.2 用例驅動的模組劃分過程14.2.1 核心原理：從用例到類，再到模組14.2.2 第1步：實現用例需要哪些類14.2.3 第2步：這些類應該劃歸哪些模組14.3 實際應用（12）——對比MailProxy案例的 4種模組劃分設計14.3.1 設計14.3.2 設計的優點、缺點第15章 模組劃分的4步驟方法——運用層、模組、功能 模組、用例驅動15.1 像專家一樣思考15.1.1 自頂向下vs.自底向上，垂直切分vs.水平切分15.1.2 橫切豎割，並不矛盾15.2 模組劃分的4步驟方法——EDD方法15.2.1 封裝驅動設計的4個步驟15.2.2 細粒度模組的劃分技巧15.3 實際應用（13）——對比MailProxy案例的4種模組劃分設計15.3.1 設計15.3.2 設計的優點、缺點下載地址：

網盤下載