标签：
1 从程序员到架构师 1
1.1 软件业人才结构
1.1.1 金字塔型还是橄榄型？ 1
1. 橄榄型：中间大两头小；
2. 区分开学历结构和能力结构；学历结构：橄榄型，能力结构：金字塔型；
1.1.2 从程序员向架构师转型 2
1. 软企该怎么做？
2 解析软件架构概念 10
1. 架构的概念很多种，不统一；
2.1 软件架构概念的分类 11
1. 架构的概念很难统一；
2. 本书将概念分为组成派和决策派两大流派，来帮助理解；
2.1.1 组成派 11
1. 软件系统的架构将系统描述为计算组件及组件间的交互；
2. 组成派的两个显著特点：
a. 关注架构实践中的客体--软件；
b. 分析了软件的组成；
2.1.2 决策派 11
1. RUP：Rational Unified Process，Rational统一过程；
2. 软件架构是在一些重要方面做出决策的集合；
3. 两个特点：
a. 关注架构实践的主体--人；
b. 归纳了架构决策的类型；
2.1.3 软件架构概念大观 12
1. 很多牛人的有不同概念定义；
2.2 概念思想的解析 13
2.2.1 软件架构关注分割和交互 13
1. 组件+交互可以将MVC等具体架构设计决策高屋建瓴地抽象地表达出来；
2.2.2 软件架构是一系列有层次的决策 14
1. 架构属于设计，但不是所有设计都属于架构；
2. 架构涉及的决策，往往对整体质量、并行开发、适应变化等方面有着重大影响；
a. 模块如何划分；
b. 每个模块的职责如何；
c. 每个模块的接口如何定义；
d. 模块间采用何种交互机制；
e. 开发技术如何选型；
f. 如何满足约束和质量属性的需求；
g. 如何适应可能发生的变化；
3. 设计往往分层次依次展开；
4. 例子：设计一个硬件设备调试系统；
a. 理解需求；
b. 首轮决策：此时软件系统被高层切分；
c. N步，继续决策--此时软件系统被切分成更小单元；
2.2.3 系统、子系统、框架都可以有架构 17
1. 真实的软件其实是“由组件递归组合而成”；
2. 例子：航空航天领域的系统；极其复杂，总的系统需要配备系统架构师，子系统有时也需要单独配备架构师；
2.3 实际应用（1）--团队对架构看法不一怎么办 13
1.
2.3.1 结合手上的实际工作来理解架构的含义 18
1. 出现不按照架构进行后续的详细设计和编程的现象，有程序员和架构师对架构有不同的理解的原因；
2. 如果一个架构师认为“架构就是通用模块”，那么他可能就不会关心非通用单元的设计；
3. 如果一个架构师认为“架构就是技术选型”，那么他在拍版“Spring+Struts”之后就理所当然地无事可做了；
4. 如果一个架构师认为“投标时讲的架构就是架构的全部”，那么他才不管那“三页幻灯”对程序员的实际开发指导不够呢（因为没有意识到）；
5. 结合手上的实际工作来理解架构的含义，是笔者推荐的做法；
2.3.2 这样理解架构对吗？ 19
1. 架构设计细致到类，不太现实；
2.3.3 工作中找答案：先看部分设计 19
1. MVC架构和具体的技术无关，我们要不断细化架构方案，这样才能为开发人员提供更多的指导和限制，才能真正降低后续开发的重大技术风险；
2. 工期短，使用第三方SDK包，但是又不想绑定死某个SDK包，用适配器模式增加一个接口层；
3 理解架构设计视图
3.1 软件架构为谁而设计 24
1. 不同的人对架构的视角不同，架构要为不同的人而设计；
3.1.1 为用户而设计 25
1.
3.1.2 为客户而设计 26
3.1.3 为开发人员而设计 26
3.1.4 为管理人员而设计 26
3.2 理解架构设计视图 28
3.2.1 架构视图
3.3 运用逻辑视图和物理视图设计架构 30
3.4 开发人员如何快速成长
3.4.1 开发人员应该多尝试设计 33
3.4.2 例子：邮件代发系统 34
分而治之，迭代式开发；
不应先设计逻辑视图再设计物理视图，而是迭代进行相互验证；
4 架构设计过程
4.1 架构设计的实践脉络 41
节奏：看透需求，架构大方向正确，设计好架构的各个方面；
架构早期注重识别：1、重大需求；2、特色需求；3、高风险需求；
6大步骤：
1、需求分析；
2、领域建模；
3、确定关键需求；
4、概念架构设计；
5、细化架构设计；
6、架构验证；
4.2 架构设计速查手册 45
需求沟通，非功能性需求的确定，需求分析主线；
5 需求分析
5.1 愿景分析 54
愿景文档很重要；
不同类型的公司的文档名称不同；
上下文图（PPT或用例图的顶级视图）；描述系统和周围事物之间的界限和联系；
愿景分析即需求调研，
愿景=业务目标+范围+Feature+上下文图；
输出《愿景与范围文档》
5.2 需求分析 61
需求捕获、需求分析、系统分析；
相互伴随，交叉进行；
需求捕获输出需求采集卡；
需求分析交付《软件需求规格说明书》；
5.3 掌握的需求全不全 65
软件需求=功能+质量+约束；
任何一个功能都是一个职责责任链构成的；架构就是发现职责，并把功能分配到各个子系统；
质量是完善架构设计的驱动力；
5.5 实际案例 78
关键步骤：三横两纵；横表示顺序执行，纵表示随时进行；
三横：确定系统目标、研究高层需求、建立用例模型；
两纵：需求沟通、需求启发、需求验证；确定非功能需求；
高层需求之确定范围的方法；
6 用例和需求
6.1 用例技术族 89
几种不同的技术：用例图、用例简述（用户故事）、用例规约、用例实现（鲁棒图）；
6.2 应用场景 94
7 领域建模
7.1 什么是领域建模 106
领域模型常用：类图、状态图；
7.2 需求人员视角--促进用户沟通，解决分析瘫痪 108
7.3 开发人员视角 113
8 确定关键需求
8.1 什么决定了架构 129
用例驱动论：很多需求和质量都无法用用例来描述；
8.2 关键需求决定了架构 132
8.3 如何确定关键需求 133
8.4 案例-小系统和大系统的架构分水岭 137
架构设计只有合适，没有最好；
9 概念架构设计
9.1 是什么 144
只关注高层组件，给出高层组件的相互关系，不应涉及接口细节；
是直指目标的设计思想、重大选择；
9.2 概述 151
关键需求进，概念架构出的过程；
9.3 左手功能 153
左手功能，右手质量；
鲁棒图的3个元素：边界对象、控制对象、实体对象；
9.4 右手质量 159
10 细化架构设计
10.1 从2视图到5视图 175
2视图：物理视图+逻辑视图；
5视图：逻辑视图、开发视图、运行视图、物理视图、数据视图；
10.2 学会系统思考 177
11 架构验证
11.1 原型设计 194
对感兴趣的问题试试看，故意忽略其他方面的要求；
11.2 架构验证 198
两种验证方法：框架法、原型法；
12 粗粒度功能模块划分
标签：
原文地址：http://www.cnblogs.com/yejq/p/4491679.html
