1. ADD简介

属性驱动设计方法（ADD）把一组质量属性作为输入，并通过质量属性和体系结构之间的映射，对体系结构进行设计。属性驱动设计方法是对系统的一个递归的分解过程，每个阶段都需要选择战术和体系结构模式来满足一组质量属性场景。该方法的结果是一组视图，包括模块分解视图、并发视图、部署视图等，他并不包括视图的具体细节。系统被描述为功能和功能之间交互的一组容器。属性驱动对实现期望的质量属性来说是非常关键的，并且它为功能实现提供了一个框架。与其它设计方法一样，把功能需求和约束作为输入。然而，在处理质量需求的时候，属性驱动方法与其它方法不同，它要求把质量需求表示为一组系统特定的质量场景。

长期以来人们都认识到质量属性在很大程度上是由系统的软件体系结构决定的。这种识别是几种软件体系结构分析方法的基础。然而，这种识别方法在软件体系结构设计问题上的应用是最近的一个发展。ADD方法是设计过程基于软件必须满足的质量属性的一种系统架构设计的方法,所以,它可以完成RUP定义的功能候选架构，并依赖于对系统限制、功能和质量需求的理解。

ADD方法旨在实现两个主要目标：即在支持设计过程的早期阶段，在该阶段确定实现所需质量属性的能力，并允许设计足够早地开始以支持现代市场需求。

2. ADD的步骤

属性驱动方法主要步骤，如图1所示：

（样本输入环节应在主要步骤之前）

图1 属性驱动方法主要流程

1)  选择要分解的模块。要分解的模块通常是整个系统。该模块要求的所有输入都应该是可获得的（约束、功能需求和质量需求）。

2)  对模块进行求精。

a)  从具体的质量场景和功能需求集合中选择体系结构驱动因素。

b)  选择满足体系结构的模式。根据可以满足质量属性的战术来选择模式，并确定实现这些战术所需要的子模块。

c)  实例化模块并根据用例分配功能，使用多视图表示。

d)  定义子模块的接口。该分解提供了模块和对模块交互的限制。

e)  验证用例和质量场景并对其进行求精，使他们成为子模块的限制。

3)  对需要进一步分解的模块重复第一、第二两步。

选择体系结构模式这一步的目标是建立一个由模块类型组成的总体构架模式。该模式通过组合选定的战术满足了构架驱动因素。构架驱动因素本身和实现战术的模式对其它质量属性产生的副作用，这两个因素支配了战术的选择。例如：由于该系统要实现一个产品线，因此可修改性是它需要支持的一个重要质量属性；另外，在某些质量属性场景中要对刺激源有一定程度的反馈，因此性能也是它要满足的一个质量属性。针对可修改性，我们采用的战术就是“局部化变更”，具体战术为：语义一致性和信息隐藏。我们使用单独的模块来处理用户接口、通讯和传感器，这些模块被称为虚拟机。针对性能，我们采用提高计算效率和精心调度的战术来保证关键性能计算在规定的时间内完成。

对质量属性场景进行求精时，可以通过分解完全满足质量属性场景，再通过对子模块的有限制的分解来满足质量属性场景。要注意分解一定是中性的。如果质量属性场景不满意当前的分解，此时需要再分解。

3.概念架构和递归分解

“概念架构”这个属于被创造出来适用于描述初始设计阶段。概念架构直指系统目标的设计思想、重大选择，因而非常重要。而ADD其是一种设计概念架构的方法。概念架构满足"架构=组件+交互"且只关注高层组件，之后对齐进行笼统的界定，给为他们之间的关心，此外，概念架构不涉及接口细节。这儿需要牢记的是，重大需求塑造概念设计，这儿的重大需求就是预架构中的功能、质量及约束3类需求中的关键部分。如图2所示。

图2 概念架构

概念架构阶段一共有3个步骤 ：初步设计，高层分割，考虑非功能需求。

初步设计的主要任务是发现职责，可以借助"职责协调链"。在分析直接协调链时，首先需要引入一个工具，鲁棒图，其包含3中元素，分别是边界对象，控制对象和实体对象。高层分割则是首先一个系统分割为项目交互的几个系统，之后将每个系统分化为多个子系统（不要过度设计）。子系统通常就是分层。比如对于持续可用性的要求，就需要数据库服务器配置故障转移集群，Web服务器负载均衡，这就是考虑非功能需求。

ADD本身是一种递归分解方法。整个系统被分解为一组称为“概念子系统”的子系统，而这些子系统又被分解为“概念组件”。由于该方法是递归的，因此无论是应用于分解系统还是概念子系统，都会采用相同的步骤。理论上，这种方法也可以用于分解概念组件，但到目前为止，概念组件已经足够捕获概念架构。在方法的每个主要步骤中，识别被分解元素的体系结构驱动因素，分解元素，并根据表示基本功能的质量属性需求和用例验证分解。在每个主要步骤中也会检查约束。

由于添加方法在架构设计过程的初始部分范围很窄，因此它与关注生命周期其他部分（如需求收集或详细设计）的方法兼容。它已与几个不同的工具组一起使用。由于该方法基于质量属性目标的显式表达，因此它假定需求收集过程捕获了质量属性需求的抽象和具体表达式。

4.质量属性和可视化

ADD方法中使用了三个视图。它们是模块视图、组件和连接器视图以及部署视图。

模块分解视图主要展示模块的职责，通过该视图还可以定义模块之间的主要数据流和互操作接口；并发视图主要是对系统的动态方面建模，建立该模型有助于确定资源争用问题、可能出现的死锁情况、数据一致性问题等等；部署视图有助于确定和设计支持实现期望的质量属性的部署。

每个关注质量的实现部分取决于每个不同观点中的信息。例如，可修改性取决于元素的功能分配，这反映在模块视图中。它还可能依赖于对硬件的分配，这反映在部署视图中。例如，性能取决于满足职责（模块视图）、同步详细信息（组件和连接器视图）和分配到不同处理器（部署视图）所需的资源。

ADD的结果是架构的模块分解视图和其他视图的最初的几个层次，不是视图的所有细节都是通过ADD得到。ADD的结果是粗粒度的，由ADD得到的构架和已经为实现做好准备的构架之间的区别是：ADD需要做出更详细的设计决策。

5.从QAW到ADD

从上次作业的中可以看到，QAW的结果是系统的业务目标以及质量属性场景的集合,而ADD方法需要的是系统开发的限制、功能性需求以及质量需求。质量需求通常用系统的质量属性场景来描述。另外QAW主要关注诱导场景的信息以及系统的质量属性,而ADD方法则希望把QAW的结果作为架 构师开发软件架构的输入。事实上,QAW的输出和ADD方法的输入之间有很明显的匹配关系。但是, QAW的结果一般为描述面向系统的问题而不是软件相关的问题。所以, QAW的结果在运用到ADD方法之前需要先将这些面向系统的问题转化。

在QAW完成之后,还需要分析QAW的结果,并对某些场景进行必要的转化。在QAW完成时,质量属性相关的信息就产生了,而且有一定的优先级,但是,它并没有变成具体的内容。提供内容的第一步就是分析QAW的结果。分析可以按照以下建议的步骤进行:

(1) 根据质量属性建立一个实体树,来表示这些场景是如何组织的。

(2) 建立一个映射表,来描述这些场景和业务目标之间的映射关系,并明确在QAW结果中明显遗漏的业务目标。

(3) 建立一个表格描述场景和架构驱动之间的映射,明确遗漏的架构驱动。

(4) 建立一个表格描述使用的架构生命周期过程,以及它们与场景的关系。明确在场景中遗漏的步骤。

(5) 列出遗漏的业务目标、架构驱动和架构生命周期过程。注意要关注在前面定义的场景中没有覆盖到的所有业务目标、架构驱动和过程。

(6) 明确可能的风险、挑战或者难点。

从QAW得到的场景有一些可以直接在ADD中使用,还有一些则需要经过进一步的精化,然后分配到系统架构的硬件、软件、人或数据上。QAW得到的场景通常有两种类型:操作型场景和生命周期过程场景。其中,操作型场景主要描述在某工作负载的情况下,系统对刺激物的反应。而生命周期过程场景通常关注在系统中所需要的生命周期的过程。

QAW的场景通常不会区分操作人员的活动和系统操作,特别是在有多个操作人员的场景里面。在这样的情况下,架构师就需要去阅读已经存在哪些文档，并将原来的那些场景转换成为一组场景,这些场景组合在一起表示原来的那个场景。ADD方法有一个步骤是用来精化用例、限制、场景等,。需求和限制将从所选择的模块流向分解后的子模块,质量场景也经过精化并分配到其子模块上。

总的来说QAW和ADD集成方法主要用于质量属性场景的获取,对场景的精化,然后根据这些场景以及架构驱动来设计软件架构。

6. ADD的缺点

尽管ADD对于将质量属性链接到设计选择很有用，但它有几个需要解决的缺点：

（1）ADD指导架构师使用并组合策略和模式，以实现质量属性场景的满意度。然而，模式和策略都是抽象的，方法没有解释如何将这些抽象映射到具体的实现技术。

（2）ADD2.0版本是在敏捷方法被广泛采用之前发明的，因此，它没有为敏捷环境中的架构设计提供指导。

（3）ADD未提供有关如何开始设计过程的指导。虽然这种省略增强了它的可归纳性，但它给新手设计师带来了困难，他们通常不知道从哪里开始。ADD并没有明确地促进（重用）参考体系结构，这是许多架构师理想的起点。

（4）ADD没有明确考虑不同的设计目的。例如，可以将设计作为售前流程的一部分，或者作为构建的“标准”设计的一部分。不同的目的将导致添加的不同用途。

（5）ADD没有考虑到设计需要解决一些架构问题（即内部需求），不管它们是否在“传统”驱动因素（需求和约束）列表中表示。很少有用户会要求系统“可测试”或要求系统提供特殊的测试接口，但明智的架构师可能会选择包括这样的基础设施，特别是当系统很复杂并且在难以控制和复制的环境中使用时。

（6）ADD2.0包括了初始文档和分析，但它们不是设计过程的明确步骤。

ADD3.0版本对以上的问题做了改进。这种改进是演变而不是革命。

7. ADD和其他软件体系结构设计方法的对比

评估结果被分成4部分：上下文、用户、内容和确认。方法上下文意味着将应用方法的环境。需求被作为每一个方法的输入，但是在产品线架构设计之后，方法输出各不相同。

在方法内容的要素中，应能注意到，虽然在考虑软件架构时没有包含需求，但FORM方法仍规定还需要需求和架构设计之间的接口。在FORM中，接口是特征模型。如果不考虑这3个方法的步骤名称上的不一致，通常在这些步骤中所做的实际行为还是一样的。例如，COPA的平台工程开发一个可重用组件的平台，它用到FORM中的域组件和架构设计。通常情况下，现在也是，方法的工具支持都是一个开放问题，COPA定义使用下面的工具：字处理器、可视模型工具、代码生成器、（交叉）编译器、链接器、调试器和配置管理工具。FORM定义了一个特定开发工具，ASADAL，它明确支持FORM。为了证明一个方法对它所应用的领域是合适的，方法必需被确认和足够成熟。这个方面被作为评估的第4个要素：确认。在为评估所选择的这3个方法中，FORM是最长命的，可被应用到不同领域中的几个工业案例研究。COPA的确是它们中最成熟的，它由已有的（因此是成熟的）工程方法族组成，继承了这些方法的优点。所有这些方法或者已经被确认或者正在各种领域上进行确认。

8. 总结

ADD是以驱动程序为输入并生成体系结构的迭代体系结构设计方法。在每一次迭代中，结构都是通过细化在前一次迭代中标识的元素来生成的。这些结构主要是从设计概念中创建的，这些概念被选择并实例化，以处理为迭代选择的驱动程序的子集。

软件体系结构是决定软件系统成败的重要因素之一。在软件体系结构阶段进行分析与评价，识别体系结构设计中的潜在风险，验证系统的质量需求在设计中是否得到了体现，预测系统的质量，能够有效地提高软件系统的成功率。采用软件架构设计方法有几个好处：（1）通过规范的方法确保架构满足各种FR和NFR需求，最大限度减少架构设计的经验主义和机会主义；（2）通过系统地学习软件架构设计方法能够更有效地培养合格的软件架构师。

特别的，在产品线开发中应用产品线架构设计方法可以获得更多的好处：（1）已证明的核心资源的重用和开发的连贯性导致风险降低；（2）开发的连贯性减少了新开发的数量。因此，采用软件产品线的最终结果是产品数量增加，重复工作减少。

ADD方法已被罗伯特博世有限公司内的各个集团用于定义产品的概念架构，这些产品旨在为产品线提供基础。其中一些已定义的产品已经进入生产阶段。博世集团已经能够内化和应用该方法，是因为他们拥有经验非常丰富的设计师。故在几乎没有培训，ADD适用范围很窄的情况下，他们依然可以取得较好的效果。