软体架构设计：程式设计师向架构师转型必备

文章插图
软体架构设计：程式设计师向架构师转型必备【软体架构设计：程式设计师向架构师转型必备】《软体架构设计：程式设计师向架构师转型必备》是2012年7月电子工业出版社出版的图书，作者是温昱。本书围绕“软体架构设计”主题，从“程式设计师”成长的视角，深入浅出地讲述了架构师的修炼之道。
基本介绍书名：软体架构设计：程式设计师向架构师转型必备
作者：温昱
页数： 246
定价：39.00元
出版社：电子工业出版社
出版时间：2012-7
副标题：程式设计师向架构师转型必备
作者简介温昱资深谘询顾问，软体架构专家。软体架构思想的传播者和积极推动者，中国软体技术大会杰出贡献专家。十五年系统规划、架构设计和研发管理经验，在金融、航空、多媒体、电信、中间件平台等领域负责和参与多个大型系统的规划、设计、开发与管理。内容简介从“基础篇”、到“设计过程篇”、到“模组划分专题”，《软体架构设计:程式设计师向架构师转型必备(第2版)》覆盖了架构设计的关键技能项，并且对于架构设计过程中可能出现的各种问题给与了解答。目录第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 设计的优点、缺点