软件架构设计：实用方法及实践.html.pdf

译者序 为什么要翻译这本书 从机械工业出版社华章公司王春华老师那里获知有一本有关软件架构设计的图书正在征集译者，作为软件从业人员，我表示 出极大的兴趣。在看过英文版并试译完样章后，我和几位志同道合的软件工程师一起开始了本书的翻译工作。 在此要感谢机械工业出版社的关敏老师、王春华老师给予我们的支持和信任。因为这份信任，我们才有机会来翻译这本关于 软件架构设计的书籍。 本书系统地讲解了一个通常我们认为很复杂的问题软件架构设计，里面提供的案例有很强的可参照性，所涉及的工具也 具有很好的可操作性。 书中介绍了架构的设计过程以及设计方法：属性驱动设计（ADD）。利用ADD，可以帮助使用者在设计过程中不断重构设 计。作者通过介绍ADD的概念和ADD的几个应用实例，展示了如何执行架构设计，如何重用设计概念，即借用其他成熟的解决 方案。本书特别适合想要“从入门到精通”掌握软件架构设计的读者。 在介绍架构设计的概念、方法、流程和理论时，本书结合了非常新鲜、实用的实例，一步一步演示使用ADD方法完成架构 设计的方方面面，通俗易懂。在学习理论方法的同时，还能够了解时下广泛发展的一些框架和技术，相信读者会从本书中学习到 翔实的架构知识，从而受益匪浅。 作为软件从业人员，我参与过软件开发、测试和项目管理，在实际工作中深刻地认识到好的软件架构对于软件产品的决定性 意义。参与翻译本书的过程也是一次满足自己好奇心和求知欲的过程。希望读者在阅读本书的过程中也能获得和我一样的愉快体 验。 最后，由于译者水平有限，书中难免出现疏漏之处，恳请读者批评指正。 读者对象 本书适合以下几类读者阅读： ·软件架构师 ·有志于成为软件架构师的软件从业人员 ·计算机相关专业的在读学生 勘误支持 虽然译者试图努力保证本书中不出现错误，但鉴于译者的知识水平和视角，本书中难免出现用词错误或者技术问题。在此， 恳请读者不吝指教，指出错误。请读者发送邮件到cy.yss163.com，帮助我们修正错误。 译者分工 本书由来自IBM中国开发中心的软件工程师及项目经理联合翻译完成。其中刘旭斌翻译了第1章、第7章和第9章；陈瑶翻译 了第2章和第3章；邵元英翻译了第4章和第8章；栾云杰翻译了第5章、第6章和第10章。附录部分由上面四位共同负责。 致谢 感谢华章公司引进本书的中文版版权，这是本书中文版得以面市的核心要素。 感谢华章公司的关敏和王春华老师，她们专业的编辑水平为本书提供了重要的质量保证。 感谢本次翻译组的小伙伴，他们的热忱使翻译过程变得有趣而且顺畅。 前言 提起软件架构，人们常常会想到模型模型表示构成软件架构的基本结构。偶尔，人们才会思考这些结构产生的过程，到 底经过什么样的思考过程才有了这些结构，也就是说，设计的过程是什么。设计是一种完成起来很复杂的活动，关于设计的主题 也比较复杂，不容易写清楚，因为这需要针对系统的方方面面来考虑并做出决策。这些方面往往很难表达，尤其当它们来自于以 往实战性的软件开发项目时，从这样的项目中得来的经验和知识是很难言传的。尽管如此，因为设计行为本身是建立软件架构的 基础，所以它亟待被解释。虽然经验很难通过一本书来传授，但是我们可以通过分享一种方法，来帮助读者以系统化的方式完成 设计过程。 本书的主旨是介绍设计过程和一种特殊的设计方法，这种方法称为属性驱动设计（Attribute-Driven Design，ADD）。我 们相信这种方法非常有效，能帮助读者以有原则、有纪律和可重复的方式完成设计。在本书中，列举了属性驱动设计及现实生活 中的几个有关属性驱动设计的真实案例。我们将通过这些案例演示如何进行架构设计。即便你目前没有足够的设计经验，我们会 举例说明如何借助该方法来复用设计概念，即那些历经考验的经典方案。 尽管属性驱动设计十多年前已经提出，关于它的文字资料却很少，也很少有资料可以提供属性驱动设计的实例并对其具体实 现过程加以解释。因为公开信息的缺乏，人们很难使用该方法或将该方法传授给他人。此外，一些已经发表的关于属性驱动开发 的文档也都比较概括，很少涉及架构师日常使用的概念、实践和技术。 我们已经跟职业架构师一起工作了多年，曾指导他们如何进行设计，以及如何在设计过程中学习。同时我们也学到了很多， 例如，我们了解到职业架构师在设计过程的早期会考虑哪些技术因素，这一点在之前的属性驱动设计版本中是没有的。就因为这 个原因，该方法被很多实践者认为跟实际脱节。本书提供了一个修正过的属性驱动设计新版本。在该版本中，我们试图不遗余力 地在理论和实践之间架设桥梁，缩小理论和实践之间的差距。 虽然我们已经教授了多年软件架构和设计软件，但是一路走来我们认识到，对没有经验的人来说，软件架构和软件设计太难 了。这种认识促使我们去创建设计路线图，可以肯定的是，这样可以有效引导人们完成相关设计过程。我们同时设计了一种针对 软件设计教学的游戏，可以作为本书的配套部分。 本书面向的读者首先是那些对软件架构设计感兴趣的人，尤其是那些必须展开这项设计任务现阶段却不得不使用某些临时性 方案的行业内人士，本书定会对他们别有益处。而对于有经验的软件架构设计者来说，他们已经有了一套逐步建立起来的设计方 法，相信这些读者也能通过本书找到新的思路。例如，如何用看板（Kanban）追踪设计进度，如何利用基于策略的问卷调查分 析一个设计理念，如何通过设计方法完成早期的评估预测。再者，对于已经在软件工程学院熟知其他架构方法的读者，则可以得 到属性驱动设计与其他设计方法的关联信息。例如，与质量属性工作坊（Quality Attribute Workshop，QAW），与架构权衡 分析方法（Architecture Tradeoff Analysis，ATAM），以及与成本效益分析方法（Cost Benefit Analysis Method，CBAM）之间的联系。最后，本书也适合计算机科学或者软件工程专业的学生和老师阅读。我们深信本书中列举的案 例研究可以帮助读者理解如何更轻松地完成一系列的设计过程。可以肯定的是，我们已经在课程中运用了相似的案例，并且效果 显著。就像爱因斯坦所说的，“举例不是教学时可供选择的方式，而是唯一的方式。” 我们期望本书能够让读者明白，设计其实是有套路可依的，按照这样的方法或者套路，你能够在今后的软件架构设计中设计 出更优秀的软件产品。 本书各章内容如下： ·第1章简明地介绍了软件架构和属性驱动设计方法。 ·第2章讨论软件架构设计的细节，设计过程的主要输入架构驱动因子，以及设计的概念，这些概念会帮助你明白如何利 用已经过验证的方案来理清这些驱动因子有哪些。 ·第3章详细介绍属性驱动设计方法。重点讨论属性驱动设计方法的各个步骤，以及能够用来完成这些步骤的多项技术。 ·第4章解释了“绿地”（greenfield）系统的开发实例。在该案例研究中，我们尽力解释如何将第3章描述的大多数概念运用 到设计过程中，因此，你可以自然地认为该案例研究比较“学术”（虽然该案例源于真实存在的系统）。 ·第5章阐述第二个案例研究，该案例是与职业软件架构师合作完成的，因而更加专业、更加详细。它将以翔实的细节展示 属性驱动设计如何应用于涉及多种技术的大数据系统的设计中。该案例展示了如何在“新”领域中开发系统，而不是在第4章提 到的传统领域。 ·第6章是一个较短的案例研究，展示如何将属性驱动设计应用于常见的遗留（或棕地，brownfield）系统的扩展设计中。该 实例说明架构设计并非是在系统开发第一版时一次完成的，而是在开发过程的不同阶段实施的。 ·第7章展示了其他一些设计方法。在属性驱动设计的修正版本中，我们采纳了其他设计过程研究者的想法，在此简要总结 了他们的方法，在向他们的工作致敬的同时，也比较了属性驱动设计与其方法的不同。 ·第8章深入讨论了分析这个主题（尽管这是一本关于设计的书）。分析本来就是设计的一部分，所以本章讲述了一些技 巧，它们既可以用于设计过程当中，又可以用于部分设计完成后。我们专门介绍了基于策略问卷调查方法的使用，该方法能帮助 我们简单有效地理解设计过程中的种种决定。 ·第9章展示了设计过程如何适应组织级别的应用。例如，在项目周期的最早期进行一些架构设计有助于评估目标。同时， 还展示了属性驱动设计如何与其他软件开发方法协同工作。 ·第10章总结了全书内容。 本书附有两个附录。附录A给出了各种设计概念的目录，这些设计概念可用于特定的应用领域。该目录集合了我们从各处收 集的设计概念，反映了现实中那些经验丰富、训练有素的架构师是如何工作的。目录包含了第4章案例研究中使用的设计概念的 样本。附录B针对7个最常见的质量属性提供了一套基于策略的问卷调查（详见第8章），同时针对DevOps额外提供了一份问卷 调查。 致谢 希望能够在此表达我们对审阅人员Marty Barrett、Roger Champagne、Siva Muthu、Robert Nord、Vishal Prabhu、 Andriy Shapochka、David Sisk、Perla Velasco-Elizondo和Olaf Zimmermann的感谢，感谢他们慷慨地提出他们的观点和意 见。我们也要感谢Serge Haziyev和Olha Hrytsay，他们帮助我们完成了本书第5章。此外，如果漏掉Serge、Olha和Andriy在 内的许多Softserve的架构师就是我们失职了，他们对整本著作提供了很多帮助。 Humberto希望感谢Quarksoft公司的主管和架构师小组。关于修改属性驱动设计的很多想法和本书中的一个案例研究都来 源于该方法在这家公司的实践。感谢我有幸合作过和交换过意见的其他公司的架构师及开发者，我从他们身上学到了很多。我也 希望感谢软件工程学院，他们多年来一直邀请我和其他学者参加他们的精英教育研讨会（ACE Educators Workshop）。我还 要感谢我的母校，墨西哥首都伊斯塔帕拉帕自治大学，它一直在支持我。感谢我的同事Perla Velasco-Elizondo和Luis Castro， 他们已经在架构之旅中陪伴我多年。感谢Alonso Leal，是他在多年前给了我成为一个职业架构师的机会。感谢Richard S.Hall， 他教了我许多写作本书时很有价值的技巧。最后，我要感谢我的合作者Rick，他是个好人，也是个好同事，很高兴能和他一起工 作并交换意见。 Rick希望感谢软件工程学院的James Ivers和他的研究小组。我还要特别感谢Rod Nord悉心的审校和宝贵的建议。我也要感 谢我的长期合作者和导师Len Bass，在许多年前他引领我开启了软件架构之旅。没有Len，我不知道自己今天会在哪里。此外， 我要感谢Linda Northrop，她多年来一直大力支持我的研究，并提供给我许多宝贵的机会。最后，我要感谢我的合作者 Humberto，他总是朝气蓬勃，和他共事是一件真正的乐事。 第1章 引言 在本章中我们会概述软件架构这一主题。我们会简要探讨架构是什么以及为什么必须在软件系统开发时考虑它。我们还会探 讨同软件架构开发相关的不同活动和行为，架构设计本书的主旨可以理解为以这些活动为背景进行。我们也会简要地讨论 架构师这个角色，该角色负责创建设计。最后，我们会引入属性驱动设计（Attribute-Driven Design，ADD）方法，并在本书 中大量讨论该架构设计方法。 1.1 写作动机 本书的目标是教会你如何通过一种系统化的、可预测的、可重复的、高性价比的方法进行软件架构设计。如果你正准备读这 本书，那说明你或许对架构设计感兴趣并有志成为一名架构师。好消息是：你的目标并不遥远。要就这一点说服你，我们会花些 功夫来谈论设计的想法针对任何事物的设计然后我们都会明白架构设计在如何做上是一致的，在为何做上也是一致的。在 很多领域，“设计”包含相同的挑战和思考满足利益干系人的需求，坚守预算和进度，处理约束条件，等等。尽管因为所涉 及领域的不同，涉及的基本事物和设计工具也可能不同，但是设计的目标和步骤却并无差异。 这是个令人鼓舞的好消息，因为这意味着设计不只是行家的专有领地。也就是说，设计既可以教，也可以学。大多数设计， 特别是在工程领域，由已知的（有时是创新的）基本设计组成，这些设计可以实现可预见的成果。当然，细节最令人头疼，但这 就是我们的方法存在的意义。起初这似乎很难想象，像设计这种创造性的工作可以用一种循序渐进的方法来实现；然而，这不仅 可能而且还是有价值的，如同Parnas和Clements在他们的论文A Rational Design Process：How and Why to Fake It中 讨论的那样。当然，不是每个人都可以成为伟大的设计师，就像不是每个人都可以是托马斯·爱迪生、勒布朗·詹姆斯或罗纳尔多 一样。我们要说的是，每个人都可以成为更好的设计师，本书提供了结构化的方法，这些方法源于一些可重用的设计知识，可以 帮助你从平凡走向卓越。 我们为什么要写一本关于软件架构设计的书呢？虽然已经有很多关于通用设计的著作，也已经有一些关于软件架构设计的著 作，但是还没有一本专门致力于架构设计的书。此外，大多数已有的关于架构设计的书都比较抽象。 我们写这本书的目标是提供一种实用的方法，可以由任何一个称职的软件工程师来执行，也（同样重要的）提供了一系列丰 富的案例研究来帮助你了解该方法。阿尔伯特·爱因斯坦曾经说过，“举例不是教学时可供选择的方式，而是唯一的方式”。我 们坚信是这样的。对大多数人来说，比起从规则或步骤或原则中学习，从实例中学习的效果会更好。当然，我们需要用步骤、规 则和原则指导我们的行为来创建实例，这些例子围绕着我们日常所关心的事情，并帮助我们把步骤具体化。 这并不意味着架构设计永远都那么简单。如果你正在构建一个复杂的系统，那么你可能正试图平衡多个相互竞争的力量，如 上市时间、成本、性能、可进化性、可用性、可靠性等。如果你正在调整任何一个维度的边界，那么你作为一个架构师的工作将 更加复杂。不只软件，任何工程学科都是如此。如果你研究的是建造大型船舶、摩天大楼或其他复杂的“系统”的历史，你会看 到这些系统的架构师如何艰难地做出适当的决策和取舍。的确，架构设计可能始终是困难的，但我们的目的是对于训练有素、受 过良好教育的软件工程师来说，让架构设计易于处理和实现。 1.2 软件架构 关于什么是软件架构已经有很多论述。在这里我们采用Software Architecture in Practice（第3版）中软件架构的定 义： 一个系统的软件架构是构成该系统所需结构的组合，它们由软件元素、元素之间的关系以及元素和关系两者的属性组成。 正如你将要看到的，我们的设计方法结合了这一定义，并帮助设计者创建出一个具有理想属性的软件架构。 1.2.1 软件架构的重要性 关于软件架构的重要性也已经有很多论述。同样，我们还是采用Software Architecture in Practice中的论述。我们注 意到软件架构之所以重要有各种各样的原因，以及类似的多种多样的来自这些原因的各种后果： ·架构会妨碍或支持系统质量属性的实现。 ·在架构中做出的决定允许你在系统发展的过程中分析改变的原因并管理它们。 ·对软件架构的分析使我们可以在系统开发的早期预测系统的质量。 ·书面记录的架构加强了利益相关者之间的沟通。 ·软件架构是最早的设计决策的载体，这些设计决策也是最基本、最难修改的。 ·软件架构定义了一系列的约束条件以及后续的实现。 ·软件架构会影响一个组织的结构，反之亦然。 ·软件架构能够为可改进甚至是一次性的原型设计提供基础。 ·软件架构是架构师和项目经理估算成本和进度的关键工件。 ·软件架构可以作为一个可转移、可重复使用的模型，该模型可以构成产品线的核心。 ·基于架构的开发专注于组件的组装，而不仅仅关注它们的创建过程。 ·通过限制软件架构的备选方案，架构师可以激发开发人员的创造性，减少设计和系统的复杂度。 ·软件架构可以为培养新的团队成员打基础。 如果一个软件架构因为以下这些原因而变得重要：它会影响组织的结构、系统的质量，以及参与它的创建者和改进者，那么 一定要在设计这个关键工件时非常小心。可悲的是，大多数情况下往往不是这样的。软件架构经常“演变”或“突现”。虽然我 们并不反对演变或突现，且强调不主张“大规模预先设计”，但除非是最简单的项目，不设计任何软件架构往往都是非常危险 的。你愿意开车经过一座没有经过仔细设计的桥吗？或者你愿意坐在一架没有经过仔细设计的喷气式飞机上吗？当然不。但你每 天使用的软件都是充满缺陷、昂贵、不安全、不可靠、容易出错和缓慢的，许多这些讨厌的特性本来都是可以避免的！ 本书的核心信息是，软件架构设计不一定是困难或可怕的，它并不只是行家的专有领地。它不一定是昂贵的，不一定需要预 先把所有的事情做完。我们的工作就是告诉你应该怎么做并让你相信这么做是在你的能力范围以内的。 1.2.2 生命周期活动 软件架构设计是软件架构生命周期的活动之一（图1.1）。在任何一个软件项目的生命周期中，该活动关注的都是将需求转 化成设计然后再转化成实现。具体来说，软件架构师需要操心以下问题： ·架构需求。在所有的需求中，有些需求在软件架构方面特别重要。这些软件架构方面的重要需求（architecturally significant requirement，ASR）不仅包含系统最重要的功能和需要考虑的约束条件，也包含了最重要的一点质量属性，如高性能、高可用 性、容易改进和铁甲一样的安全性。这些需求，以及一个明确的设计目的和其他可能永远不会被写下来或可能对外部利益相关者 来说不可见的与软件架构有关的问题，将指导你对软件架构的结构和组件做出选择。我们将把这些软件架构方面的重要需求和关 注点作为驱动因子，因为可以说是它们在驱动设计。 ·架构设计。设计是一种从需要的世界（需求）到解决方案的世界的转化。它在结构方面由代码、框架和组件组成。一个好 的设计是满足了驱动因子的设计。软件架构设计是本书的关注点。 图1.1 软件架构生命周期的活动 ·架构文档。结构的一些初步文件（或草图）应该作为软件架构设计的一部分来创建。然而，这个活动是指通过这些草图创 建出一个更正式的文档。如果该项目比较小并且有一个先例，那么软件架构文档可能非常小的。与此相反，如果该项目比较大或 者是需要分布式团队合作，又或者存在重大的技术挑战，那么在架构文档这个活动中的付出将会得到足够的回报。程序员经常拒 绝和嘲笑编写文档，但是在其他工程领域，这是一个标准的、不容讨价还价的交付产出。如果你的系统足够大并且是任务关键 的，它就应该被记录下来。在其他工程学科，一份“蓝图”一些被记录下来的设计，是一个通往实现阶段和投入资源的绝对必 要的步骤。 ·架构评估。与架构文档一样，如果你的项目不是一个简单的项目，那么无论是对自己还是对利益相关者，你都有义务来评 估软件架构。这是为了确保做出的决策对于解决关键的需求是恰当的。你会提供代码而不测试吗？当然不会。同样地，你为什么 会没有先“测试”设计就投入庞大的资源来充实你的软件架构呢？你可能需要在首次创建系统或者要对系统做一个大规模的重构 时这么做。典型的架构评估是非正式和内部的，但对于真正重要的项目，最好是有一个由外部团队完成的正式的架构评估。 ·架构实现/一致性检查。最后，你需要实现你创建过（并且评估过的）的软件架构。作为一个软件架构师，你可能需要根 据系统的发展和需求的演变来调整设计。这是正常的。除此之外，在实现过程中你的主要职责是保证代码与设计的一致性。如果 开发人员没有切实地实现架构，他们可能会破坏你所设计的质量要求。让我们再一次参考一下其他工程领域是怎么做的。当我们 浇筑一个新建筑物的混凝土地基时，直到地基首先被测试通过，我们才会修建地基以上的部分。这个测试通常是通过测试一个核 心样本，以确保它足够强大、足够致密、没有水和燃气的泄漏以及其他问题。如果没有一致性检查，我们没有办法确保随后构建 的产品的质量。 请注意，我们并没有在图1.1中提出一个特定的生命周期方法。模板只是意味着一个活动一定要在之后的活动 之前做。例如，如果你不了解需求，就不能进行设计活动，如果你还没有先做一些设计决策，就无法评估一个软件架构。 今天，大多数商业软件是使用某种形式的敏捷开发方法来开发的。上面提到的这些软件架构的活动都与敏捷开发实践兼容。 软件架构师的问题不是“我应该使用敏捷开发还是做软件架构？”而是“有多少软件架构的工作我应该提前做好，有多少应该推 迟到该项目的需求已经在一定程度上确定以后？”和“有多少软件架构需要我正式用文档记录，在什么时候记录？”在许多软件 项目中敏捷开发和软件架构是一对快乐的伙伴。 我们将在第9章讨论架构设计以及各种软件生命周期的方法和过程模型，包括迭代开发之间的关系。 1.3 架构师的角色 一个软件架构师比“仅仅是”一个设计师意味着更多的东西。这个可以由单人或多人承担的角色有一个冗长的职责、技能和 知识的列表。一个成功的软件架构师必须满足这些条件。这些先决条件包括以下几点： ·领导力：工作指导、团队建设、建立愿景、组织培训。 ·沟通：技术和非技术的沟通、鼓励合作。 ·谈判：处理内部和外部的利益相关者和他们之间相互冲突的需求和期望。 ·技术技能：生命周期技能、专业技术知识、持续学习、编码能力。 ·项目技能：预算、人员、进度管理、风险管理。 ·分析能力：软件架构分析、项目管理和测量的常规分析思维（参看下面的引文“分析的含义”） 成功的设计不是一个“贴在墙上”的静态文档。也就是说，软件架构师不仅要做好设计，而且必须密切参与项目的每一个方 面，从概念和业务论证到设计与建立，直到运营、维护，最终到项目结束为止。 分析的含义 在韦氏词典中，分析这个词的定义如下： ·仔细研究一些事物来了解它的构成部分、各部分的作用，以及它们是如何相互关联的。 ·对事物的性质和意义的解释。 在本书中，分析这个词被用做不同的用途，这两个定义都适用。例如，作为软件架构评估活动的一部分，分析一个现有的架 构以评估它是否是适当的，能够满足与其相关的驱动因子。在设计过程中，对输入进行分析以做出设计决策。创建原型也是一种 分析形式。事实上，分析在设计过程中非常重要，所以我们将第8章专门讨论这个话题。在这里，我们还会更详细地讨论分析和 评价之间的关系。在本书中，我们主要关注设计活动，与设计活动相关的技术技能，设计活动与开发生命周期的整合。对于一个 架构师生涯的其他方面更加详尽的论述，我们建议你阅读一本更通用的关于软件架构的书，如Software Architecture in Practice 或Just Enough Software Architecture。 1.4 ADD发展史 虽然软件架构师有许多职责和责任，但是在本书中，我们把重点放在设计过程上，这对于一个要被称为“软件架构师”的软 件工程师来说可说是必须掌握的一个最重要的技能。为了使软件架构设计更易于处理和重复，本书中我们将重点介绍属性驱动的 设计方法（ADD）。它一步一步地指导我们如何迭代地执行图1.1中所示的设计活动。第3章详细介绍了ADD的最新版本，版本 3.0。所以在这里我们为那些熟悉之前ADD版本的读者提供了一点背景。ADD的第一个版本（ADD1.0，原来被称为ABD，表 示“基于软件架构的设计”）于2000年1月发布，第二版（ADD2.0）发布于2006年11月。Software Architecture in Practice的第3版中介绍了精减了步骤的这个方法。然而本书与其说是介绍了ADD的一个新版本，不如说是一个总结了该方法 实际步骤的重新包装的版本。 据我们所知，ADD是最全面、最广泛使用的有文档记录的软件架构设计方法。（我们在第7章提供了一些可供选择的设计方 法的概述。）当ADD出现时，它是第一个特别侧重于质量属性并通过创建软件架构的结构来实现它们、通过视图来表示它们的 设计方法。ADD的另一个重要贡献是它把软件架构分析和文档作为设计过程的一个主要组成部分。在ADD中，设计活动包括提 炼早期设计迭代过程中创建的草图来产生一个更详细的架构，并不断对设计进行评估。 虽然ADD2.0对于如何将质量属性和设计选择关联起来非常有用，但是它依然有几个需要解决的缺点： ·ADD2.0指导软件架构师使用并将策略和模式组合在一起以实现令人满意的质量属性场景。但是模式和策略是抽象的，该 方法并没有解释如何把这些抽象映射成具体的实现技术。 ·因为被广泛采用，ADD2.0在敏捷开发方法之前发布，因此它并没有为敏捷开发环境中的软件架构设计提供指导。 ·ADD2.0没有提供关于如何开始设计过程的指导。虽然这种省略提高了它的普遍性，但是对新手设计师造成了困扰，因为 他们往往不知道从哪里开始。具体而言，ADD2.0并没有显式地推广使用（重用）参考架构，对很多软件架构师来说这是一个理 想的起点，正如我们将在本书后面讨论的。 ·ADD2.0没有明确考虑不同的设计目标。例如，一个人所做的设计可能是作为一个售前过程的一部分，或作为“标准”构 造设计的一部分。这些设计的目标差别很大，并且对ADD的用法也不尽相同。 ·ADD2.0没有考虑软件架构设计需要处理一些软件架构的关注点（即内部要求）要不要在“传统”的驱动因子（需求和约 束）的列表中表现出来。很少有用户会要求一个系统是“可测试的”或需要系统提供特殊的测试接口，但是一个明智的设计师或 许会选择包括这样一个基础软件设施，特别是当系统比较复杂并且用于难以控制和复制的环境中时。 ·ADD2.0的迭代总是由软件架构元素的选择和分解来驱动。这是因为ADD2.0指导我们首先一定要选择一个需要分解的元 素，然后再确定它的驱动因子。在ADD3.0中，我们认识到有时一个设计步骤是由关键的软件架构需求来驱动的，它会指导我们 进行元素的选择和分解。 ·ADD2.0包括（初始的）文档和分析，但它们不是设计过程的显式步骤。 ADD3.0解决了所有这些缺点。可以肯定的是，ADD3.0是进化，而不是革命。它由ADD2.5的建立催化而来1，ADD2.5本 身是在真实世界的不同环境中尝试使用ADD的产物。 我们在2013年发布了ADD2.5。在那个版本中，我们提倡使用JSF、Spring、Hibernate等应用框架作为一流的设计理念。 这种变化的目的是要解决ADD2.0太抽象以至于难以实现的缺点。ADD从驱动因子开始，系统地将它们关联到设计决策，然后将 这些决策关联到可用的实现选项，包括外部开发的组件。对于敏捷开发来说，ADD3.0推广的是快速设计迭代，在每个迭代中做 出少量的设计决策，然后可能是一个实现的重建增量。此外，ADD3.0显式地推广了（重新）使用参考架构，并与“设计概念目 录”配对，该目录中包括一个各种战术、模式、框架、参考架构和技术的选集（参看附录A）。 1 这是我们自己的编号，2.5 这个数字在其他地方并没有用到。 1.5 小结 前面介绍了我们的动机和背景，现在来讨论本书的心脏和灵魂。在接下来的几章中，我们会通过设计，特别是软件架构设计 来描述我们的意图。我们会讨论ADD并且提供三个案例研究，详细说明如何在现实世界中使用ADD。我们还会讨论分析在设计 过程中发挥的关键作用并提供在设计产品中如何进行分析的例子。 1.6 扩展阅读 Fred Brooks写了一系列很有思想性的关于设计本源的文章，反映了他作为一个设计师和研究人员的50年经验：The Design of Design：Essays from a Computer Scientist（Addison-Wesley出版社2010年出版）。 用文档来记录设计和其他开发活动的过程的用途在D.Parnas和P.Clements所著的A Rational Design Process：How and Why to Fake It（IEEE Transactions on Software Engineering1986年2月刊）中讨论过。 本书使用的软件架构的定义以及软件架构的重要性和软件架构师的角色的观点，都来自于L.Bass、P.Clements和R.Kazman 所著的Software Architecture in Practice（第3版由Addison-Wesley出版社2012年出版）。 有几本书涵盖了软件架构在开发生命周期中的不同活动，包括G.Fairbanks所著的Just Enough Software Architecture：A Risk Driven Approach（Marshall&Brainerd出版社2010年出版），以及那些在第7章将要提到的设计方法 的著作。 对于ADD的第一个版本的早期参考可以参阅F.Bachmann、L.Bass、G.Chastek、P.Donohoe和F.Peruzzi所著的The Architecture Based Design Method，CMU/SEI-2000-TR-001。第二版的ADD在F.Bachmann、L.Bass、R.Wojcik、 P.Clements、P.Merson、R.Nord和W.Wood所著的Attribute-Driven Design（ADD）2.0版（CMU/SEI-2006-TR-023） 中描述。这个版本的ADD，就是我们这里所说的ADD2.5，发表在H.Cervantes、P.Velasco-Elizondo和R.Kazman所著的A Principled Way of Using Frameworks in Archite-ctural Design（IEEE Software2013年3月/4月刊，P4653）中。 第2章 架构设计 我们现在开始学习软件架构设计的过程：它是什么，它为什么重要，它是如何工作的（在一个抽象的水平上）以及它涉及的 主要概念和活动。我们首先讨论软件架构的驱动因子：“驱动”设计决策的各种因素，其中一些被记录为需求，但有许多没有被 记录。此外，我们会提供一个关于设计概念的概述你会选择、组合、实例化、分析和记录它作为设计过程的主要构建块。 2.1 通用设计 设计是一个动词，也是一个名词。设计是一个过程，一个活动，因此可以被看作是一个动词。该过程的结果是创建一个设计 一个对理想的最终状态的描述。因此，设计过程的输出是一件事物、名词，是你最终会实现的产品。设计意味着做出决策来 达到目标并满足要求和约束。设计过程的输出是这些目标、要求和约束的直接反映。例如，我们可以参考一下房子是如何设计 的。为什么中国传统民居的外观不同于瑞士或阿尔及利亚的？为什么蒙古包看起来像蒙古包，而不同于雪屋或者木屋呢？ 这些风格的房屋的建筑架构已经发展了几个世纪以反映它们独特的目标、需求和约束。中国式房屋的特色包括对称的围墙， 增加通风的天井，用来采光和御寒的朝南的庭院，等等。木房子有陡峭的一直延伸到地面的坡屋顶，这意味着最小面积的油漆和 在大雪中的保护（雪会滑落到地面上）。雪屋用冰建成，这反映出除了冰雪以外其他建筑材料的相对匮乏，以及时间的限制（一 个小雪屋可以在一个小时内建成）。 在每一种情况下，设计的过程中都会涉及一些解决方法的选择和采纳。即使是雪屋的设计也可以有变化。有些雪屋很小，就 是一个临时旅行的避难所。有的雪屋很大，往往由几个建筑连接在一起，可以供整个团体开会使用。有的是简单朴实的小雪屋， 有的里面挂着毛皮，用冰来做“窗户”，并用动物的皮做门。 在每一种情况下，设计过程平衡着设计师面对的各种“力量”。有些设计需要相当高的技巧来执行（例如，雕刻和堆积雪 块，用这样一种方式来做出一个自支撑的圆顶）。有的相对来说需要比较少的技巧几乎任何人都可以用树枝和树皮建成一座 单坡屋顶小房。但这些建筑所表现出来的质量也可能有很大的不同。从原理上讲单坡屋顶小房提供保护的很少，很容易被破坏。 但雪屋可以抵御北极的风暴而且屋顶可以承担一个人站立的重量。 设计“困难”吗？嗯，是也不是。新兴领域的设计是很难的。如何设计一个普通的自行车对我们来说非常清楚，但平衡车的 设计则开辟了一个新的天地。幸运的是，大多数设计都不新奇，因为大多数时候我们的需求都不新奇。大多数人想要的都是一辆 能可靠地从一个地方骑到另一个地方的自行车。这在每一个领域都是相同的。以房子为例，生活在菲尼克斯的大多数人都想要一 个可以很容易、很经济地保持凉爽的房子，而在埃德蒙顿的大多数人主要想要的是一个可以保持温暖的房子。相反，生活在日本 和洛杉矶的人想要的是能抵御地震的建筑。 对你（一个软件架构师）来说有一个好消息，有丰富的已经过验证的设计和设计片段，或者我们称之为设计概念的构建块， 可以重复使用并组合来可靠地实现这些目标。如果你的设计真的很新奇如果你正在设计下一个悉尼歌剧院，那么设计过程将 很可能是“困难”的。例如，悉尼歌剧院的预算是最初预算的14倍，而且比预计的时间晚落成了十年。软件架构的设计也是如 此。 2.2 软件架构中的设计 软件系统的架构设计与一般的设计没有什么不同：它涉及做出决策，使用可用的技能和材料以满足需求和约束。在软件架构 设计中，我们做出决策来把设计的目的、需求、约束和架构方面关心的问题（我们称之为架构驱动因子），转化为结构，如图 2.1所示。然后我们用这些结构来指导项目。它们指导分析和构建，并为培训一个新的项目成员打好基础。它们还指导成本和进 度的评估、团队的形成、分析和降低风险，当然，还有实现。 图2.1 架构设计活动概述（架构师图像© Brett Lamb | Dreamstime.com） 因此，软件架构设计是一个实现产品和项目目标的关键步骤。有些目标是技术性的（例如，视频游戏或一个电子商务网站实 现较低并且可预见的延迟），有些是非技术性的（例如，保持雇佣劳动力，进入一个新的市场，在最终期限前完成）。作为一个 软件架构师，你的决定将影响这些目标的实现，并且在某些情况下可能造成矛盾。一个特定的参考架构（例如，富客户端应用程 序）的选择可能会为实现你的延迟目标以及为留住你的员工提供一个良好的基础，因为他们已经熟悉了这个参考架构及其配套的 技术堆栈。但这种选择可能不会帮助你进入一个新的市场，如手机游戏市场。 在做设计时，一般情况下为了实现一个质量属性而在某些结构上所做的变化将对其他的质量属性产生负面影响。这些取舍是 每一个领域里每一个执业架构师无法改变的事实。我们将在本书的例子和案例研究中一遍又一遍地看到它。因此，软件架构师的 工作不是找到一个最佳的解决方案，而是找到一个令人满意的方案通过搜索一个也许很大的设计方案和决策的空间来找到一 个可以接受的解决方案。 2.2.1 架构设计 Grady Booch曾经说过，“所有架构都是设计，但并非所有设计都是架构。”那么是什么让一个决策成为“架构”的呢？ 如果一个决策有非局部的影响并且会影响架构驱动因子的达成，我们就说它是架构的。因此，没有一个决策本质上就是架构的或 者非架构的。一个单个要素的缓冲策略的选择可能对系统的其他部分没有什么影响，在这种情况下它是一个实现细节，除了该元 素的实现者和维护者外没有人会关注它。另一方面，缓冲策略可能对性能（如果缓冲影响延迟或吞吐量或抖动的目标的实现）、 可用性（缓冲区可能不够导致信息丢失）或可修改性（如果我们想在不同的部署或环境中灵活地改变缓冲策略）产生巨大的影 响。缓冲策略的选择，与许多设计的选择一样，既不是天生就是架构的也不是非架构的。这个差别完全依赖于当前和预期的架构 驱动因子。 2.2.2 元素交互设计 软件架构设计通常只识别一个元素的子集，该子集是系统结构的一部分。这是可以预料的，因为在最初的架构设计中架构师 将专注于系统的主要功能。一个用例如何成为主要的用例？业务的重要性、风险和复杂性的考虑组合被加入到这个设计中。当 然，对你的用户来说，一切都是当务之急和重中之重。更现实地说，少量的用例提供了最基本的业务价值或体现了最大的风险 （如果它们被错误使用），所以