1.4 ADD发展史

虽然软件架构师有许多职责和责任，但是在本书中，我们把重点放在设计过程上，这对于一个要被称为“软件架构师”的软件工程师来说可说是必须掌握的一个最重要的技能。为了使软件架构设计更易于处理和重复，本书中我们将重点介绍属性驱动的设计方法（ADD）。它一步一步地指导我们如何迭代地执行图1.1中所示的设计活动。第3章详细介绍了ADD的最新版本，版本3.0。所以在这里我们为那些熟悉之前ADD版本的读者提供了一点背景。ADD的第一个版本（ADD 1.0，原来被称为ABD，表示“基于软件架构的设计”）于2000年1月发布，第二版（ADD 2.0）发布于2006年11月。《Software Architecture in Practice》的第3版中介绍了精减了步骤的这个方法。然而本书与其说是介绍了ADD的一个新版本，不如说是一个总结了该方法实际步骤的重新包装的版本。

据我们所知，ADD是最全面、最广泛使用的有文档记录的软件架构设计方法。（我们在第7章提供了一些可供选择的设计方法的概述。）当ADD出现时，它是第一个特别侧重于质量属性并通过创建软件架构的结构来实现它们、通过视图来表示它们的设计方法。ADD的另一个重要贡献是它把软件架构分析和文档作为设计过程的一个主要组成部分。在ADD中，设计活动包括提炼早期设计迭代过程中创建的草图来产生一个更详细的架构，并不断对设计进行评估。

虽然ADD 2.0对于如何将质量属性和设计选择关联起来非常有用，但是它依然有几个需要解决的缺点：

❑ ADD 2.0指导软件架构师使用并将策略和模式组合在一起以实现令人满意的质量属性场景。但是模式和策略是抽象的，该方法并没有解释如何把这些抽象映射成具体的实现技术。

❑ 因为被广泛采用，ADD 2.0在敏捷开发方法之前发布，因此它并没有为敏捷开发环境中的软件架构设计提供指导。

❑ ADD 2.0没有提供关于如何开始设计过程的指导。虽然这种省略提高了它的普遍性，但是对新手设计师造成了困扰，因为他们往往不知道从哪里开始。具体而言，ADD 2.0并没有显式地推广使用（重用）参考架构，对很多软件架构师来说这是一个理想的起点，正如我们将在本书后面讨论的。

❑ ADD 2.0没有明确考虑不同的设计目标。例如，一个人所做的设计可能是作为一个售前过程的一部分，或作为“标准”构造设计的一部分。这些设计的目标差别很大，并且对ADD的用法也不尽相同。

❑ ADD 2.0没有考虑软件架构设计需要处理一些软件架构的关注点（即内部要求）要不要在“传统”的驱动因子（需求和约束）的列表中表现出来。很少有用户会要求一个系统是“可测试的”或需要系统提供特殊的测试接口，但是一个明智的设计师或许会选择包括这样一个基础软件设施，特别是当系统比较复杂并且用于难以控制和复制的环境中时。

❑ ADD 2.0的迭代总是由软件架构元素的选择和分解来驱动。这是因为ADD 2.0指导我们首先一定要选择一个需要分解的元素，然后再确定它的驱动因子。在ADD 3.0中，我们认识到有时一个设计步骤是由关键的软件架构需求来驱动的，它会指导我们进行元素的选择和分解。

❑ ADD 2.0包括（初始的）文档和分析，但它们不是设计过程的显式步骤。

ADD 3.0解决了所有这些缺点。可以肯定的是，ADD 3.0是进化，而不是革命。它由ADD 2.5的建立催化而来，ADD 2.5本身是在真实世界的不同环境中尝试使用ADD的产物。

我们在2013年发布了ADD 2.5。在那个版本中，我们提倡使用JSF、Spring、Hibernate等应用框架作为一流的设计理念。这种变化的目的是要解决ADD 2.0太抽象以至于难以实现的缺点。ADD从驱动因子开始，系统地将它们关联到设计决策，然后将这些决策关联到可用的实现选项，包括外部开发的组件。对于敏捷开发来说，ADD 3.0推广的是快速设计迭代，在每个迭代中做出少量的设计决策，然后可能是一个实现的重建增量。此外，ADD 3.0显式地推广了（重新）使用参考架构，并与“设计概念目录”配对，该目录中包括一个各种战术、模式、框架、参考架构和技术的选集（参看附录A）。