架构实战

译者序序前言致谢作者简介第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 Rozanski和Woods框架 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 YoreTour的愿景 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 架构需求检查列表术语表参考文献

译者序序前言致谢作者简介第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 Rozanski和Woods框架 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 YoreTour的愿景 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 架构需求检查列表术语表参考文献
· · · · · · (收起)