恰如其分的软件架构
| 恰如其分的软件架构 |
4657879809987.jpg)
本书描述了一种恰如其分的架构设计方法。作者建议根据项目面临的风险来调整架构设计的成本，并从多个视角阐述了软件架构的建模过程和方法，包括用例模型、概念模型、域模型、设计模型和代码模型等。本书不仅介绍方法，而且还对方法和概念进行了归类和阐述，将软件架构设计融入开发实践中，与敏捷开发方法有机地结合在一起，适合普通程序员阅读。
目录
基本内容
书名：恰如其分的软件架构:风险驱动的设计方法
作者：George Fairbanks
类型：计算机与互联网
出版日期：2013年9月5日
语种：简体中文
ISBN：9787560990750
外文名：Just Enough Software Architecture
译者：张逸
出版社：华中科技大学出版社
页数：359页
开本：16
定价：88.00
内容简介
《恰如其分的软件架构》的作者在探讨比较多种架构风格的差异和利弊的基础上，结合自己的工作经验，提炼出通过风险驱动的软件架构设计方法，旨在弥补敏捷开发方法在实际工程应用中的不足。本书将理论与实践相结合，不仅条理清晰地描述了设计软件架设的各种思路，而且详细介绍了经过实践检验的建模方法和架构分析技巧。
作者简介
George Fairbanks在卡内基•梅隆大学获得软件工程专业博士学位，现任Rhino Research公司董事长。Rhino Research是一家专门提供软件开发培训及咨询的公司，总部设在美国科罗拉多州博尔德市。
张逸是ThoughtWorks高级咨询师，程 序员。InfoQ中文站编辑。著译作包括《软件设计精要与模式》《WCF服务编程》《Java设计模式》以及评注版《重构：改善既有代码的设计》。目前居住于成都。
倪健是eBaoTech应用架构师，程序员。著作包括《简单之美：软件开发实践者的思考》《IT项目管理那些事儿》（与人合著）。目前居住于上海。
媒体推荐
《恰如其分的软件架构》一本超值的书，案例丰富有趣，言简意赅，阅读轻松。当年如果读到这样的书，我可以少犯许多错误！渴望成为更为优秀软件设计师的读者，这本书绝对值得在你的书架上占有一席之地。 ——Timothy J. Halloran博士，SureLogic Inc.工程总监
George Fairbanks的《恰如其分的软件架构》一书中的风险驱动建模方法已经被NASA Johnson Space Center（JSC）成功地应用于eXtensible Information Modeler (XIM) 项目。项目的所有成员，从项目管理人员到开发人员，都必须遵循。实际上，这本书应该是每一位开发人员的必备工具。仅仅是讲述(代码模型和反模式)的部分，就值回书价了。
——Christopher Dean，
美国国家航空航天局约翰逊空间中心工程科学团队XIM首席架构师
本书完全满足了那些软件开发实践者的关键需求，即如何有效地创建更加实际的系统。George常常运用自己的经验，并与学术理论相结合，为我们提供一个又一个概念模型、领域（或更广范围）内的最佳实践，以及在软件架构方面（如何更有用更现实）非常实用的指导。他在书中提出了基于风险的架构方法，并帮助我们认识到怎样才是“恰如其分”的。本书的问世为软件架构领域又增添了一份重要的文献。
——Desmond D’Souza, 《MAp and Catalysis》一书的作者，Kinetium, Inc.
名人推荐
这是一本超值的书，案例丰富有趣，言简意赅，阅读轻松。当年如果读到这样的书，我可以少犯许多错误！渴望成为更为优秀软件设计师的读者，这本书绝对值得在你的书架上占有一席之地。
——Timothy J.Halloran博士，SureLogic Inc.工程总监
本书提出的独特视角让软件架构设计变得不再难以捉摸。恰如其分的软件架构概念及风险驱动的设计理念让人耳目一新。作者将架构设计原则与现实问题有机地结合起来，值得所有从事软件开发工作的人士阅读。
——Marcus Fontoura博士，Yahoo！Research首席科学家兼架构师
图书目录
第1章概述1
1.1分治、知识与抽象2
1.2软件架构的三个案例3
1.3反思5
1.4视角转换6
1.5架构师构建架构7
1.6风险驱动的软件架构8
1.7敏捷开发者的架构9
1.8关于本书10
第2章软件架构15
2.1何为软件架构？16
2.2软件架构为何重要18
2.3架构何时重要？22
2.4推定架构23
2.5如何运用软件架构？24
2.6架构无关的设计25
2.7专注架构的设计26
2.8提升架构的设计27
2.9大型组织中的架构30
2.10结论31
2.11延伸阅读32
第3章风险驱动模型35
3.1风险驱动模型是什么？37
3.2你现在采用风险驱动了吗？38
3.3风险39
3.4技术42
3.5选择技术的指导原则44
3.6何时停止47
3.7计划式设计与演进式设计48
3.8软件开发过程51
3.9理解过程变化53
3.10风险驱动模型与软件开发过程55
3.11应用于敏捷过程56
3.12风险与架构重构58
3.13风险驱动模型的替代方案58
3.14结论60
3.15延伸阅读61
第4章实例：家庭媒体播放器65
4.1团队沟通67
4.2COTS组件的集成75
4.3元数据一致性81
4.4结论86
第5章建模建议89
5.1专注于风险89
5.2理解你的架构90
5.3传播架构技能91
5.4作出合理的架构决策92
5.5避免预先大量设计93
5.6避免自顶向下设计95
5.7余下的挑战95
5.8特性和风险：一个故事97
第6章工程师使用模型103
6.1规模与复杂度需要抽象104
6.2抽象提供洞察力和解决手段105
6.3分析系统质量105
6.4模型忽略细节106
6.5模型能够增强推理107
6.6提问在前，建模在后108
6.7小结108
6.8延伸阅读109
第7章软件架构的概念模型111
7.1规范化模型结构114
7.2领域模型、设计模型和代码模型115
7.3指定与细化关系116
7.4主模型的视图118
7.5组织模型的其他方式121
7.6业务建模121
7.7UML的用法122
7.8小结123
7.9延伸阅读123
第8章领域模型127
8.1领域与架构的关系128
8.2信息模型131
8.3导航和不变量133
8.4快照134
8.5功能场景135
8.6小结136
8.7延伸阅读137
第9章设计模型139
9.1设计模型140
9.2边界模型141
9.3内部模型141
9.4质量属性142
9.5Yinzer系统的设计之旅143
9.6视图类型157
9.7动态架构模型161
9.8架构描述语言162
9.9小结163
9.10深入阅读164
第10章代码模型167
10.1模型—代码差异167
10.2一致性管理171
10.3架构明显的编码风格174
10.4在代码中表达设计意图175
10.5模型嵌入代码原理177
10.6表达什么178
10.7在代码中表达设计意图的模式180
10.8电子邮件处理系统预演187
10.9小结193
第11章封装和分割195
11.1多层级故事195
11.2层级和分割197
11.3分解策略199
11.4有效封装203
11.5创建封装接口206
11.6小结210
11.7深入阅读210
第12章模型元素213
12.1和部署相关的元素214
12.2组件215
12.3组件装配219
12.4连接器223
12.5设计决策233
12.6功能场景234
12.7（不变量（约束）239
12.8模块239
12.9端口241
12.10质量属性246
12.11质量属性场景249
12.12职责251
12.13权衡252
12.14小结253
第13章模型关系255
13.1投影（视图）关系256
13.2分割关系261
13.3组合关系261
13.4分类关系261
13.5泛化关系262
13.6指定关系263
13.7细化关系264
13.8绑定关系268
13.9依赖关系269
13.10使用关系269
13.11小结270
13.12深入阅读271
第14章架构风格273
14.1优势274
14.2柏拉图式风格对体验式风格275
14.3约束和以架构为中心的设计276
14.4模式对风格277
14.5风格目录277
14.6分层风格277
14.7大泥球风格280
14.8管道—过滤器风格281
14.9批量顺序处理风格283
14.10以模型为中心的风格285
14.11分发—订阅风格286
14.12客户端—服务器风格和多层288
14.13对等风格290
14.14map—reduce风格291
14.15镜像，支架和农场风格293
14.16小结294
14.17深入阅读295
第15章使用架构模型297
15.1理想的模型特性297
15.2和视图一起工作303
15.3改善视图质量306
15.4提高图的质量310
15.5测试和证明312
15.6分析架构模型312
15.7架构不匹配318
15.8选择你的抽象级别319
15.9规划用户界面320
15.10指定性模型对描述性模型320
15.11对现有系统进行建模320
15.12小结322
15.13深入阅读323
第16章结论325
16.1挑战326
16.2聚焦质量属性330
16.3解决问题，而不是仅仅对它们建模331
16.4使用导轨一样的约束332
16.5使用标准架构抽象333
术语表335
文献347
索引355
序言
在我走上软件开发道路之初时，就希望能拥有这样一本书。在那时，介绍语言及面向对象编程的书籍可谓汗牛充栋，而关于设计的书却如凤毛麟角。了解C++语言的特性并不意味着你能设计出一个好的面向对象系统，熟知统一建模语言（UML），也未必能设计出一个好的系统架构。
本书不同于其他介绍软件架构的书籍，区别在于：
风险驱动的架构设计 当风险很小时，设计无须谨小慎微，但当风险威胁到项目的成功时，就没有任何借口进行草率的设计了。许多资历丰富的敏捷软件支持者都认为进行适度的预先设计是有裨益的，而本书则描述了一种恰如其分的架构设计方法。它避免了以“一招鲜，吃遍天”的方式来解决“焦油坑”问题，建议根据面临的风险来调整架构与设计的成本，摒弃仓促草率的做法，通过更为严谨的方式来调整大多数技术的精确度。
促进架构设计的民主化 你所在的团队可能拥有软件架构师——事实上，你可能正是其中一位。我认识的每一位架构师都希望所有开发者能够理解架构。他们抱怨开发者无法理解约束存在的原因，无法认识到表面看来细小的变化怎么会影响系统的属性。本书力求将架构与所有软件开发者联系起来。
积累陈述性知识 能够击中网球与知道为何能击中网球明显不同，心理学家将其分别称为过程性知识（procedural knowledge）与陈述性知识（declarative knowledge）。如果你已经善于设计和构建系统，你会用到本书提供的许多技术，但是，本书更要让你认识到你能做到的事情，并为这些概念命名。这些陈述性知识可以提高你指导其他开发者的能力。
强调工程实践 软件系统的设计者与构建者要做的事情很多，包括安排日程计划、协调资源的承诺及满足利益相关人的需求。诸多软件架构书籍业已涵盖了软件开发过程与组织结构。相对而言，本书将重心放在软件开发的技术部分，处理开发者要做的事情，以确保系统可以工作，即工程学的范畴。它为你展现了如何构建模型，如何分析架构，并在原则的指导下进行设计权衡。它还描述了软件设计者用来分析从中等到大型规模问题的技术，指出了在哪里才能学到专业技术的更多细节。因此，通观全书，软件工程师指的就是开发者，并没有将架构师从程序员中区分出来。
提供实践指导 本书提供了架构的实践方法。软件架构是一种软件设计，设计决策会影响到架构，反之亦然。最优秀的开发者所要做的事情就是深入那些障碍的细节，理解它们，再提炼出这些障碍的本质，从整体上将它们与架构相关联。书中采用的方式是，从架构到数据结构设计，描述具有不同抽象层级的模型，并遵循了这种向下深挖，继而向上提升的行为。
我的职业生涯源于我对如何构建软件系统的渴求。这种渴求引导我游走于学术研讨与行业软件开发之间。我拥有完整的计算机科学学位：学士、硕士及博士（获得卡耐基•梅隆大学软件工程学的博士学位）。我的论文专注于软件框架领域，因为它是许多开发者都要面临的问题。我开发了一种新的规格，称为设计片段（design fragment），它可以用来描述如何使用框架。同时，我还构建了一个基于Eclipse的工具，用于验证它们的使用是否正确。我非常荣幸能够得到David Garlan与Bill Scherlis的指导，并邀请到Jonathan Aldrich与Ralph Johnson成为论文的评审委员。
我受益于学术的精确与严密，但我的根还是在工程界。我作为软件开发者，参与了多个项目，包括：Nortel DMS-100中央办公电话交换机、驾驶模拟器的统计分析、时代华纳通信公司的IT应用系统、Eclipse IDE插件，还有我自己创建的网络初创公司开发的每一行代码。我作为一名业余的系统管理员捣鼓着自己的Linux机器，拥有一间闪烁着灯光、用电力供暖的小房间。
我在敏捷技术的早期就成为它的拥趸，1996年，我成功地鼓动我的部门将开发周期从6个月切换为2周，并在1998年开始测试先行的开发。
本书的主要读者是那些实践中的软件开发者。读者应该对基本的软件开发思想，包括面向对象软件开发、UML、用例与设计模式等有所了解。若能拥有实际的软件开发过程的经验，对阅读本书会更有帮助，因为本书的许多基本主张都基于这些常见的经验。若你看到开发者编写了太多的文档，又或者未经深思熟虑就急于编写代码，一定会认识到这种软件开发方式的谬误，需要寻找像本书提供的那些治病良方。本书同样可以作为大学高年级学生或研究生的教材。
对于不同的读者，这里提出了一些期望：
新手开发者或学生 如果你已经了解软件开发的基本机制，例如，编程语言和数据结构设计，理想情况下，已经学过通用的软件工程学课程，本书会为你介绍软件的特定模型，帮助你形成软件架构的概念模型。无须绘制大量图形、编写大量文档，这一模型就能帮助你从大型系统的混乱中走出来，理清思路。它还为你提供了诸如质量属性和架构风格等理念的初次体验。你可以学会如何从对小程序的理解，上升到对整个行业规模与质量的理解。它能加速你的成长，使你成为一位高效的、富有经验的开发者。
经验丰富的开发者 倘若你善于开发软件系统，可能会被频繁要求去指导别人。然而，你可能发现你所掌握的架构知识多少有些异于寻常，或许还使用了独一无二的图形标记或术语。本书将提高你指导他人的能力，理解为何你能够在别人苦苦挣扎的领域取得成功，并教给你标准的模型、标记与名称。
软件架构师 在你所在的软件组织中，一旦其他成员无法理解身为架构师的你究竟做了什么，以及为何要这样做，这个角色就会变得处境艰难。本书不仅教会你构建系统的技术，还提供了一些办法帮助你向团队解释你的工作内容与工作方式。或者，你甚至可以将本书分享给同事，使他们成为真正的团队伙伴，以便能够更好地完成工作。
学术研究人员 本书为软件架构领域做出了多个贡献。它引入了软件架构的风险驱动模型，这是一种决定为项目作出多少架构和设计工作的方法。它描述了三种架构方法：架构无关的设计、专注架构的设计与提升架构的设计。它还整合了软件架构的两种视角：功能视角与质量属性视角，从而形成一种单独的概念模型。本书还引入了架构明显的编程风格（architecturally-evident coding style）的理念，通过阅读源代码使架构显现。[1]