软件架构设计 (2008 年度畅销榜NO.149 )

本书紧紧围绕“软件架构设计”这一主题，立足实践解析了软件架构的概念、阐述了切实可行的软件架构设计方法、提供了可操作性极强的完整的架构设计过程。另外，本书从思维方式的突破、面向对象设计、UML建模、过程与管理等关键过渡环节，为广大程序员的成长提供了切中肯綮的指导。本书可作为计算机软件专业本科生、研究生和软件工程硕士的软件架构设计教材，也可作为软件开发高级培训、软件开发管理培训的培训教材，更是第一线高级开发人员和开发管理人员的必备参考书。

第一部分 软件架构概念与思想篇\r\n 第1章 解析软件架构要领\r\n 第2章 子系、框架与架构\r\n 第3章 软件架构的作用\r\n第二部分 软件架构设计方法与过程篇\r\n 第4章 软件架色视图\r\n 第5章 架构设计的5视图法\r\n 第6章 从概念性架构到实际架构\r\n 第7章 如何进行成功的架构设计\r\n 第8章 软件架构要设计到什么程度\r\n 第9章 软件架构设计过程\r\n 第10章 需求分析\r\n 第11章 专题：用例技术及应用\r\n 第12章 领域建模\r\n 第13章 确定对软件架构关键的需求\r\n 第14章 概念性架构设计\r\n 第15章 质量属性分析\r\n 第16章 细化架构设计\r\n 第17章 实现并验证软件架构\r\n第三部分 程序员成长篇\r\n 第18章 MIME编码类案例：从面向过程到面向对象\r\n 第19章 突破OOP思维：继承在OOP中的应用\r\n 第20章 细向见真章：耦合其实东不空洞\r\n 第21章 敏捷设计：从理论到实践\r\n 第22章 基于角色的设计：从理论到实践\r\n 第23章 超越设计模式：理解和运用更多模式\r\n 第24章 如此轻松：立足图论学UML\r\n 第25章 理解软件过程：解析RUP核心概念\r\n 第26章 海阔凭鱼跃：通盘理解软件工程\r\n参考文献

我最早听说“软件架构”这个概念以及UML的名字，是在1999年的水木清华BBS上。当时有一篇文章介绍了软件架构作为一个相对独立的领域的发展情况，顺便提到在此前一年被接纳为OMG标准的UML。该文作者断言，UML的出现将能“彻底”改变软件开发的工作方式，甚至“若干年之后，不通UML者无法染指软件开发”。三年之后，《程序员》杂志专访Ivar Jacobson时，UML已经是尽人皆知。记得Jacobson在那次采访中劝告中国的开发者，赶快去学习RUP。从那时候起，越来越多的人顶上了“软件架构师”的头衔，张口模式闭口架构，一时间好不风光。然而最初的热乎劲过去之后，人们发现，“不通UML者无法染指软件开发”的预言似乎落了空，而一些软件架构师们似乎也并不那么神乎其技，很多时候反而不如那些实实在在写代码的人管用。他们所宣传的那些叠床架屋的抽象层，那些复杂精致的模式设计，看上去精美无比，柔性十足，然而实践当中一个出乎意料的小变更，便常常能把这一切打得粉碎。他们乐谈的松耦合，小接口，往往只是说起来好听，实际很难落实，或者代价过高，有的时候，反而是反其道而行之，才更“管用”。 为什么会出现这种情况？我想这里有客观和主观的原因。就客观原因来说，软件开发毕竟还是年轻的行业，各方面还在剧烈发展和变化中。如果把软件技术做一个层次划分的话，软件架构及设计属于上层建筑，而像程序设计语言、技术平台、数据管理技术、网络体系结构等，均在其之下，属于基础。这几年随着互联网的飞速发展，基础尚且在剧烈变化当中，上层建筑自然会摇摇晃晃，甚至赶不上趟。具体来说，当今的软件体系结构设计总体上是基于面向对象思想，而且是强类型语言时代的面向对象思想，而动态语言的出现和流行，实际上很大程度颠覆了传统面向对象思想的一些原则。例如，人们曾经认为封装非常重要，对象成员能够隐藏便应当尽量隐藏，但是Python和Ruby中public是常态，private反而是变态，实践当中也工作得很好，甚至更好。再例如，几年来人们津津乐道的设计模式，其中有很多在动态语言里毫无必要。而很多在关系数据库时代被视为瑰宝的数据存储与访问模式，放到后关系型数据库里就全无意义了。再诸如应用的Web化、RIA、SOA等基本思想的变迁，都是能引起整个软件技术格局强烈震荡的大事件，所有这些进行中的剧烈变化，不可能不对软件架构的设计产生影响，从而使得很多关于架构设计的思想迅速过时或者必须调整。如果架构师们不能够充分重视实践，与时俱进，那么就很有可能做出不合时宜的设计。 就主观原因来说，很多软件架构师走入了一个误区，即一旦升级为架构师，就可以脱离具体的代码实践，可以阳春白雪了。事实上，由于下层技术的变化迅速，架构师一旦脱离代码实践，脱离现实应用，很快就会与实实在在的软件开发工作产生距离感，忘却一线开发者需要面对的现实问题，做出一些不切实际的设计决策。这样的设计，或者执行不下去，或者执行下去也代价巨大，该解决的问题没解决，却在无关紧要的问题上大做文章。毫无疑问，这样的设计得不到一线开发者的衷心支持，得不到好的结果。然而，一部分架构师不去检讨自己脱离实践的设计，却搞起本本主义，硬拿书本教条死扣实际。相应地，相当多的开发者也不愿意提高对于软件架构设计的认识和理解。于是两个必要的角色之间产生矛盾。开发者抱怨架构设计华而不实，架构师抱怨开发者不严格按设计行事，进而相互质疑对方角色的必要性。开发者认为架构师没有存在的必要，而架构师则幻想有朝一日自动代码生成器能把这帮不听话的开发者赶出山门。 事实上，开发者和架构师都是软件开发中必不可少的角色，即使在单人开发的项目里，开发者本人也需要经常在这两个角色之间切换。两个角色的相互理解，和谐协作，才能够共同克服现实困难，开发成功的软件。在促进这种和谐的过程中，开发者应当积极学习架构设计的理论并充分实践，而架构师则需要本着务实的态度贴近一线。 因为从事技术媒体工作，我也确实结识了几个优秀的架构设计师，他们身上的共同特点就是务实。这些架构师都具有多年的软件开发经验，对软件本质的理解相当深入，本身就是开发高手。与一般开发高手不同的是，他们充分实践，但不宥于实践，而是积极地学习软件架构的理论，尝试用理论来指导实践。而与整天高谈阔论的理论架构师不同的是，他们掌握了理论之后，一定要亲自落实，用实践来检验。当理论与实践产生矛盾的时候，他们既不会轻易否定理论，更不会教条主义般地削足适履，而是认真分析矛盾产生的原因，研究可能的对策。在反复思考和实践之下，他们敢于做出“离经叛道”的结论，敢于质疑大师偶像的论断，更能够在错综复杂的实际中做出简单、可靠、灵活而便于实现的设计，并且向开发者传达意图，答疑解惑，实现整个团队的思想一致。他们做出的设计，开发者看得懂，做得出，自然会得到衷心的拥护。 温昱是《程序员》杂志的

温昱，资深咨询顾问，CSAI特聘高级顾问，软件架构专家，软件架构思想的传播者和积极推动者。十年系统规划、架构设计和研发管理经验，在金融、航空、多媒体、网络管理、中间件平台等领域负责和参与多个大型系统的规划、设计、开发与管理。在《程序员》杂志、IBM DeveloperWorks等媒体发表了《图论思想与UML应用》、《敏捷设计从理论到实践》、《随需而变的RUP》等文章数十篇。译著有《应用框架的设计与实现——NET平台》等。松耦合空间（www.ou-he.com）网站创办人。

方法如路标。如果地形复杂，我们会迷路，但有了路标，则有利于我们找到前进的方向。好的方法也是如此，它对实践者有启发和指引作用。 我们需要一种有条理的架构设计方法。 这种方法必须有针对性。如何应对需求变更？如何为非功能需求而设计？如何设计架构的不同方面？如何验证架构的可行性？解决这些问题的思路，必须被贯穿到架构设计方法之中，且要显而易见才好。 这种方法必须易于掌握。换句话说，技术要主流；如果都是一线软件人员不熟悉的阳春白雪级的东西，大家掌握起来就比较困难了。 这种方法不能太重。迭代可以为这种方法锦上添花，但不应成为掌握这种方法的障碍；建模也不应滥用，虽然建模不仅有用而且关键…… 本书紧紧围绕“软件架构设计”这一主题，立足实践解析了软件架构的概念，阐述了切实可行的软件架构设计方法，提供了可操作性极强的完整的架构设计过程。另外，本书从思维方式的突破、面向对象设计、UML建模、过程与管理等关键过渡环节，为广大程序员的成长提供了切中肯綮的指导。 理论与实践并重是本书的特点。架构设计要如何开展？架构设计要进行到什么程度？各类需求对架构设计的影响有何不同？关键需求决定架构的具体做法是什么？如何运用“属性—场景—决策”表规划非功能需求？如何运用OO原则进行敏捷设计？对这些问题书中都进行了深入阐述，并结合金融、航空、网络管理等行业软件的成功架构设计案例，将理性的思考和宝贵的实践经验奉献给读者。 感谢微软亚洲研究院的刘铁锋、《程序员》杂志的孟岩、BeyondSoft的夏桅（网络速马）、IBM developer Works中国网站的罗景文等朋友的大力支持，他们为本书的策划贡献了真知灼见。感谢我的妻子徐异婕，她对本书的内容、形式、案例均提出了大量宝贵意见和建议。感谢所有为本书提出建议的朋友。 感谢父母长久以来对我的鼓励。感谢岳父、岳母在整个漫长的写作过程中对宝宝无微不至的照顾，使我有更多精力投入在写作上。 由于作者水平有限，本书不足和错误之处在所难免，恳请专家和读者批评指正，欢迎来信（shanghaiwenyu@163.com）。本书的支持网站为松耦合空间（www.ou-he.com），提供与本书内容有关的资源、信息、课件等。 温 昱 2007.2.25 于上海浦东

无封面