架構實戰：軟件架構設計的過程

　　伊樂斯（Peter Eeles），IBM RationaI Software的高級IT架構師，主要工作是進行架構設計和實現大規模、分佈式的系統。他目前致力於幫助組織提高軟件開發能力。除本書外，Eeles還與人合作編寫了《Building J2EE Applicatio with  theRatio rlaI Unifjed Process》（Addisorl-WesIey，2003）和《BuiIdlng Busi rless Objects》（Wiley，1998）。
　　克里普斯（Peter Cripps），IBM Global Business Services的高級IT架構師，專注於應用組件和基於服務的開發技術，並在整個IBM公司推廣架構設計最佳實踐，目前從事IBM Unified Method FrarTlework的開發工作。

譯者序
序
前言
致謝
作者簡介

第1章 導言
1.1 流程應用
1.2 流程概述
1.3 範圍
1.4 總結

第2章 架構，架構師和架構設計
2.1 架構
2.1.1 架構定義結構
2.1.2 架構定義行為
2.1.3 架構關注重要的元素
2.1.4 架構平衡利益相關者的需要
2.1.5 架構基於合理證據使決策具體化
2.1.6 架構會遵循一種架構風格
2.1.7 架構受它的環境影響
2.1.8 架構影響開發團隊的結構
2.1.9 所有系統都存在架構
2.1.10 架構有特定的範圍
2.2 架構師
2.2.1 架構師是技術領導
2.2.2 架構師的角色可能由一個團隊來履行
2.2.3 架構師理解軟件開發流程
2.2.4 架構師掌握業務領域的知識
2.2.5 架構師掌握技術知識
2.2.6 架構師掌握設計技能
2.2.7 架構師具備編程技能
2.2.8 架構師是優秀的溝通人員
2.2.9 架構師進行決策
2.2.10 架構師知道組織政策
2.2.11 架構師是談判專家
2.3 架構設計
2.3.1 架構設計是一門科學
2.3.2 架構設計是一門藝術
2.3.3 架構設計跨越很多方面
2.3.4 架構設計是一個漸進的活動
2.3.5 架構設計受許多利益相關者驅動
2.3.6 架構設計經常包括折中
2.3.7 架構設計承認經驗
2.3.8 架構設計既由上而下也由下而上
2.4 架構設計的優點
2.4.1 架構設計解決系統的質量問題
2.4.2 架構設計促進達成共識
2.4.3 架構設計支持計畫編制流程
2.4.4 架構設計促進架構的完整性
2.4.5 架構設計有助於管理複雜性
2.4.6 架構設計為重用提供基礎
2.4.7 架構設計降低維護成本
2.4.8 架構設計支持影響分析
2.5 總結

第3章 方法基本原理
3.1 關鍵概念
3.2 方法內容
3.2.1 角色
3.2.2 工作產品
3.2.3 活動
3.2.4 任務
3.3 流程
3.3.1 瀑布流程
3.3.2 迭代流程
3.3.3 敏捷流程
3.4 總結

第4章 編寫軟件架構文檔
4.1 最終的結局
4.2 關鍵概念
4.3 視點和視圖
4.3.1 基礎視點
4.3.2 交叉視點
4.3.3 視圖及圖表
4.3.4 視點及視圖的優點
4.4 模型
4.4.1 實現的層級
4.4.2 模型的優點
4.5 架構描述框架的特徵
4.5.1 軟件架構的4+1視圖模型
4.5.2 Zachman框架
4.5.3 R0zanski和W00ds框架
4.6 一個架構描述框架
4.6.1 視點
4.6.2 產品
4.6.3 實現的層級
4.6.4 視圖一致
4.7 軟件架構文檔
4.8 總結

第5章 可重用架構資源
5.1 架構的來源
5.2 架構資源元模型
5.2.1 開發期資源
5.2.2 運行期資源
5.3 資源類型
5.3.1 參考架構
5.3.2 開發方法
5.3.3 視點目錄
5.3.4 架構風格
5.3.5 架構機制
5.3.6 模式
5.3.7 參考模型
5.3.8 架構決策
5.3.9 現有的應用程序
5.3.10 封裝的應用程序
5.3.11 應用框架
5.3.12 組件庫／組件
5.4 架構資源的屬性
5.5 重用的其他考慮因素
5.6 總結

第6章 案例介紹
6.1 流程應用
6.2 案例研究範圍
6.2.1 項目團隊
6.2.2 外部影響因素
6.3 應用簡介
6.4 YourFour的願景
6.4.1 問題聲明
6.4.2 利益相關者
6.4.3 系統功能
6.4.4 系統的質量
6.4.5 約束
6.5 總結

第7章 定義需求
7.1 關聯需求和架構
7.2 功能性需求和非功能性需求
7.3 編寫需求文檔的技術
7.4 流程應用
7.5 理解任務描述
7.6 定義需求：活動概覽
7.7 總結

第8章 創建邏輯架構
8.1 從需求走向解決方案
8.2 邏輯架構的價值
8.2.1 使邏輯架構最小化
8.2.2 把邏輯架構作為一項投資
8.2.3 可追溯性的重要性
8.3 流程應用
8.4 創建邏輯架構：活動概覽
8.5 總結

第9章 創建物理架構
9.1 從邏輯架構到物理架構
9.2 流程應用
9.3 創建物理架構：活動概覽
9.4 任務：調查架構資源
9.5 任務：定義架構概覽
9.6 任務：編寫架構決策文檔
9.7 任務：概述功能性元素
9.7.1 將邏輯功能元素映射到物理功能元素
9.7.2 確認物理功能元素
9.7.3 採購產品
9.7.4 適應特定技術的模式
9.8 任務：概述部署元素
9.8.1 映射邏輯部署元素到物理部署元素
9.8.2 確認物理部署元素
9.8.3 採購硬件
9.9 任務：檢驗架構
9.10 任務：構建架構概念證明
9.11 任務：細化功能性元素
9.12 任務：細化部署元素
9.13 任務：確認架構
9.14 任務：更新軟件架構文檔
9.15 任務：和利益相關者覆審架構
9.16 總結

第10章 進階
10.1 架構師和項目團隊
10.1.1 架構師和需求
10.1.2 架構師和開發
10.1.3 架構師和測試
10.1.4 架構師和項目管理
10.1.5 架構師和配置管理
10.1.6 架構師和變更管理
10.1.7 架構師和開發環境
10.1.8 架構師和業務分析
10.2 架構師和外界影響
10.2.1 企業架構
10.2.2 設計權威
10.2.3 基礎設施提供者
10.2.4 系統維護者
10.3 複雜系統的架構設計
10.3.1 許多獨特的功能正在開發
10.3.2 許多人員參與開發
10.3.3 系統是高度分佈式的
10.3.4 開發團隊是分佈式的
10.3.5 運行質量非常有挑戰性
10.3.6 存在系統之系統
10.4 總結
附錄A 軟件架構元模型
附錄B 視點目錄
附錄C 方法概述
附錄D 架構需求檢查列表
術語表
參考文獻