当前位置:首页 > 工业技术
一线架构师实践指南
一线架构师实践指南

一线架构师实践指南PDF电子书下载

工业技术

  • 电子书积分:9 积分如何计算积分?
  • 作 者:温昱编著
  • 出 版 社:北京:电子工业出版社
  • 出版年份:2009
  • ISBN:9787121095405
  • 页数:194 页
图书介绍:本书从架构师经常遇到的困惑出发,总结软件架构设计中经常遇到的问题,提出“方法体系必然是软件业界未来发展的重大趋势”,以及“架构设计方法已经扩展到方法体系”的观点。针对软件架构设计的三个阶段(Pre-Architecture阶段、Conceptual Architecture阶段和Refined Architecture阶段)中的各个具体环节,给出了最佳的实践原则和方法,内容涵盖了从需求分析到生成架构的整个过程。
《一线架构师实践指南》目录

第1章 绪论 1

1.1一线架构师:6个经典困惑 1

1.2本书的4个核心主张 2

1.2.1方法体系是大趋势 2

1.2.2质疑驱动的架构设计 2

1.2.3多阶段还是多视图? 3

1.2.4内置最佳实践 4

1.3 ADMEMS方法体系:3个阶段,1个贯穿环节 4

1.3.1 Pre-architecture阶段:ADMEMS矩阵方法 5

1.3.2 Conceptual Architecture阶段:重大需求塑造做概念架构 6

1.3.3 Refined Architecture阶段:落地的5视图方法 6

1.3.4持续关注非功能需求:“目标-场景-决策”表方法 7

1.4如何运用本书解决“6大困惑” 8

第Ⅰ部分 Pre-Architecture阶段 11

第2章 Pre-architecture的故事 13

2.1“不就是个MIS吗” 13

2.1.1故事:外籍人员管理系统 13

2.1.2探究:哪些因素构成了架构设计的约束性需求 14

2.2.1故事:嵌入式OS的剪裁 14

2.2.2探究:又是约束 14

2.3“都是C++的错,换C重写” 15

2.3.1故事:放弃C++,用C重写计费系统 15

2.3.2探究:相互矛盾的质量属性 15

2.4展望“Pre-architecture阶段篇” 16

第3章 Pre-architecture总论 17

3.1什么是Pre-architecture 18

3.2实际意义 18

3.2.1需求理解的大局观 18

3.2.2降低架构失败风险 18

3.2.3尽早开始架构设计 19

3.2.4明确架构设计的“驱动力” 20

3.3业界现状 21

3.3.1“唯经验论” 21

3.3.2“目标不变论” 21

3.3.3需求分类法的现状 22

3.3.4需求决定架构的原理亟待归纳 23

3.4实践要领 24

3.4.1不同需求影响架构的不同原理,才是架构设计思维的基础 24

3.4.2二维需求观与ADMEMS矩阵方法 26

3.4.3关键需求决定架构,其余需求验证架构 27

3.4.4 Pre-architecture阶段的4个步骤 27

第4章 需求结构化与分析约束影响 29

4.1为什么必须进行需求结构化 29

4.2用ADMEMS矩阵方法进行需求结构化 30

4.2.1范围:超越《软件需求规格说明书》 30

4.2.2工具:ADMEMS矩阵 30

4.3为什么必须分析约束影响 32

4.4 ADMEMS方法的“约束分类理论” 33

4.5 Big Picture:架构师应该这样理解约束 34

4.6用ADMEMS矩阵方法辅助约束分析 36

4.7大型B2C网站案例:需求结构化与分析约束影响 36

4.7.1需求结构化 36

4.7.2分析约束影响(推导法则应用) 37

4.7.3分析约束影响(查漏法则应用) 38

4.8贯穿案例 39

4.8.1 PASS系统背景介绍 39

4.8.2需求结构化 40

4.8.3分析约束影响 41

第5章 确定关键质量与关键功能 43

5.1为什么要确定架构的关键质量目标 43

5.2确定关键质量的5大原则 44

5.2.1整体思路 44

5.2.2分类合适+必要扩充 45

5.2.3考虑多方涉众 46

5.2.4检查性思维 46

5.2.5识别矛盾+划定优先级 46

5.2.6严格程度符合领域与规模特点 47

5.3为什么不是“全部功能作为驱动因素” 48

5.4确定关键功能的4条规则 49

5.5大型B2C网站案例:确定关键质量与关键功能 51

5.6贯穿案例 52

第Ⅱ部分 Conceptual Architecture阶段 53

第6章 概念架构的故事 55

6.1一筹莫展 55

6.1.1小张,以及他负责的产品 56

6.1.2老王,后天见客户 57

6.2制定方针 58

6.2.1小张:我必须先进行概念架构的设计 58

6.2.2老王:清晰的概念架构,明确的价值体现 59

6.3柳暗花明 60

6.3.1小张:重大需求塑造概念架构 60

6.3.2老王:概念架构体现重大需求 62

6.4结局与经验 62

6.4.1小张:概念架构是设计大系统的关键 62

6.4.2老王:概念架构是售前必修课 63

第7章 Conceptual Architecture总论 65

7.1什么是概念架构 65

7.2实际意义 66

7.3业界现状 67

7.3.1误将“概念架构”等同于“理想架构” 67

7.3.2误把“阶段”当成“视图” 68

7.4实践要领 68

7.4.1重大需求塑造概念架构 68

7.4.2概念架构阶段的3个步骤 69

第8章 初步设计 71

8.1初步设计对复杂系统的意义 71

8.2鲁棒图简介 72

8.2.1鲁棒图的3种元素 72

8.2.2鲁棒图一例 73

8.2.3历史 74

8.2.4为什么叫“鲁棒”图 74

8.2.5定位 75

8.3基于鲁棒图进行初步设计的10条经验 77

8.3.1遵守建模规则 77

8.3.2简化建模语法 78

8.3.3遵循3种元素的发现思路 78

8.3.4增量建模 78

8.3.5实体对象≠持久化对象 80

8.3.6只对关键功能(用例)画鲁棒图 81

8.3.7每个鲁棒图有2~5个控制对象 81

8.3.8勿关注细节 81

8.3.9勿过分关注UI,除非辅助或验证UI设计 81

8.3.10鲁棒图≠用例规约的可视化 82

8.4贯穿案例 82

第9章 高层分割 85

9.1高层分割的两种实践套路 85

9.1.1切系统为系统 86

9.1.2案例:SAAS模式的软件租用平台架构设计 87

9.1.3切系统为子系统 89

9.2分层式概念架构实践 91

9.2.1 Layer:逻辑层 91

9.2.2 Tier:物理层 92

9.2.3按通用性分层 94

9.2.4技术堆叠 95

9.3给一线架构师的提醒 96

9.4贯穿案例 96

9.4.1从初步设计到高层分割的过渡 96

9.4.2 PASS系统之 Layer设计 97

9.4.3 PASS系统之Tier设计 97

9.4.4引入通用性分层 98

第10章 考虑非功能需求 99

10.1考虑非功能目标要趁早 99

10.2贯穿案例 100

第Ⅲ部分 Refined Architecture阶段 103

第11章 细化架构的故事 105

11.1骄傲的架构师,郁闷的程序员 105

11.1.1故事:《方案书》确认之后 105

11.1.2探究:“方案”与“架构”的关系 106

11.2办公室里的争论 107

11.2.1故事:办公室里,争论正酣 107

11.2.2探究:优秀的多视图方法,应贴近实践 108

11.3展望“Refined Architecture阶段篇” 109

第12章 Refined Architecture总论 111

12.1什么是Refined Architecture 111

12.2实际意义 113

12.3业界现状 113

12.3.1误认为多视图是OO方法分支 113

12.3.2误将“视图”当成“阶段” 113

12.3.3 RUP 4+1视图 114

12.3.4 SEI 3视图 115

12.4实践要领 116

12.4.1缘起:5视图方法的提出 116

12.4.2总图:每个视图,一个思维角度 116

12.4.3详图:每个视图,一组技术关注点 117

第13章 逻辑架构 119

13.1划分子系统的3种必用策略 119

13.1.1分层(Layer)的细化 120

13.1.2分区(Partition)的引入 120

13.1.3机制的提取 121

13.1.4总结:回顾《软件架构设计》提出的“三维思维” 123

13.1.5探究:划分子系统的4个重要原则 125

13.2接口设计的事实与谬误 126

13.3逻辑架构设计的整体思维套路 127

13.3.1整体思路:质疑驱动的逻辑架构设计 127

13.3.2过程串联:给初学者 128

13.3.3案例示范:自己设计MyZip 129

13.4更多经验总结 133

13.4.1逻辑架构设计的10条经验要点 133

13.4.2简述:逻辑架构设计中设计模式应用 133

13.4.3简述:逻辑架构设计的建模支持 135

13.5贯穿案例 135

第14章 物理架构、运行架构、开发架构 139

14.1为什么需要物理架构设计 139

14.2物理架构设计的工作内容 140

14.3探究:物理架构的设计思维 140

14.4为什么需要运行架构设计 141

14.5运行架构设计的工作内容 142

14.5.1工作内容 142

14.5.2控制流图是关键 143

14.6实现控制流的3种常见手段 143

14.7为什么开发架构是必须的 144

14.8开发架构设计的工作内容 145

14.9观点:重用测试是关键 147

14.9.1探究:我们为何年复一年修改着类似的Bug 147

14.9.2观点:为了从根本上降低维护成本,重用测试是关键 147

14.9.3简评:设计模式对重用的意义 148

14.10贯串案例 149

14.10.1物理架构 149

14.10.2持续不断地考虑非功能需求 150

14.10.3开发架构 151

14.10.4架构设计应进行到什么程度 152

第15章 数据架构的难点:数据分布 153

15.1数据分布的6种策略 153

15.1.1独立Schema (Separate-schema) 154

15.1.2集中(Centralized) 154

15.1.3分区(Partitioned) 155

15.1.4复制(Replicated) 156

15.1.5子集(Subset) 156

15.1.6重组(Reorganized) 156

15.2数据分布策略大局观 157

15.2.1 6种策略的二维比较图 157

15.2.2质量属性方面的效果对比 158

15.3数据分布策略的3条应用原则 159

15.3.1合适原则:电子病历vs.身份验证案例 159

15.3.2综合原则:服务受理系统vs.外线施工管理系统案例 161

15.3.3优化原则:铃声下载门户案例 162

第Ⅳ部分 专题:非功能目标的方法论 165

第16章 故事:困扰已久的非功能问题 167

16.1“拜托,架构师不是需求分析师” 168

16.1.1故事:小魏请教老沈 168

16.1.2探究:架构师必须懂需求 169

16.2“敢说ISO 9126不对,真牛” 170

16.2.1故事:小冯与小汪的争论 170

16.2.2探究:死抱需求标准,还是务实应变 170

16.3“我说得很清楚,架构要灵活” 171

16.3.1故事:狮子说清了,绵羊没搞定 171

16.3.2探究:交流质量要求,如何做到“说得清楚、听得明白” 171

16.4展望本部分的后续内容 172

第17章 总论:非功能目标的设计环节 173

17.1非功能目标的设计环节简介 173

17.2实际意义 174

17.3业界现状 175

17.4实践要领 176

17.4.1场景思维 176

17.4.2纵穿环节 176

第18章 方法:“目标-场景-决策”表 177

18.1场景技术 177

18.1.1场景技术的历史 177

18.1.2软件行业中场景技术的应用现状与展望 178

18.1.3场景的5要素与场景卡 179

18.2“目标-场景-决策”表 180

索引 183

编辑手记 185

设计手记 187

返回顶部