码迷,mamicode.com
首页 > 其他好文 > 详细

软件架构设计:程序员向架构师转型必备(第二版) 笔记

时间:2015-05-10 07:25:36      阅读:334      评论:0      收藏:0      [点我收藏+]

标签:

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

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!