软件架构设计方法综述.doc

软件架构设计方法综述李志杰技术架构部E-Mail: lizhijie@1 引言软件架构的设计是指通过一系列的设计活动，获得满足系统功能性需求（functional requirement，简称 FR） ，并且符合一定非功能性需求（non-functional requirement，简称NFR，与质量属性有相似涵义）约束的软件架构模型软件架构设计过程的本质在于：将系统分解成相应的组成成分（如构件、连接件） ，并将这些成分重新组装成一个系统现阶段，软件架构设计方法大多侧重对系统 NFR 的考虑，往往和软件架构分析方法结合使用，希望能够在软件生命周期前期发现潜在的风险本文介绍一些经典的软件架构设计方法，并分析其异同点： Bosch 方法 [1] 基于架构的设计（ABD, Architecture Based Design）方法 [2] 属性驱动的设计（ADD, Attribute-Driven Design method）方法 [3][4] 面向特征的领域分析（FODA, Feature-Oriented Domain Analysis Method）方法 [5] 面向产品线的抽象、规范与转换（FAST, Family-Oriented Abstraction, Specification, and Translation）方法 [6] 面向构件的平台架构（COPA, Component-Oriented Platform Architecting）方法 [7] 面向特征的重用 FORM（Feature-Oriented Reuse Method）方法 [8] 质量驱动的架构设计与质量分析 QADA（Quality-driven Architecture Design and quality Analysis）方法 [9] KobrA 方法 [10]2 软件架构设计方法概述根据软件架构设计方法所面向的目标不同，可以将软件架构设计方法分为面向单系统的架构设计方法、面向产品线的架构设计方法和同时支持单系统和产品线的架构设计方法。

2.1 面向单系统的架构设计方法2.1.1 Bosch 方法Jan Bosch 方法认为架构设计过程，可以看作解决一个最优化问题，输入需求规格书，输出架构设计的过程第一步，根据功能需求产生第一个版本的架构，但不考虑质量需求；然后，基于质量需求对该设计进行评估，针对每一个质量属性都给定一个评估值这些值与质量需求规格书的相应值进行比较如果所有的质量属性评估值都达到或高于需求，则架构设计过程结束否则，从初始的架构开始新一轮的变换，通过架构变换，使某些质量属性评估值提高对新的架构设计再一次评估，并重复同样的过程，直到所有的质量需求得当满足，或者发现某些需求不存在可行的解决方案（在这种情况下，架构师需要与客户协商需求） 每一次变换（质量属性优化方案）通常会提升一个或多个质量属性，但同时会对其它质量属性产生负面影响Jan Bosch 方法需要一个形式化或半形式化的架构描述规范，例如使用架构描述语言ADL(Architecture Definition Language)这种情况下才可能模拟架构的运行时行为2.1.2 基于架构的设计方法基于架构的设计 ABD（Architecture Based Design）方法提供一个产生系统概念性架构的结构。

概念性架构描述系统的主要设计元素以及它们之间的联系概念性架构代表开发过程的第一步设计选择，为实现目标功能奠定一个至关重要的基础ABD 方法确定系统的架构驱动因素（即那些影响架构的商业、质量和功能需求的组合） 一旦确定了系统的架构驱动因素，ABD 设计活动就开始这并不意味者需要预先完成所有的需求分析、规格书编写工作需求分析可以与 ABD 活动并行进行有些应用不可能预先确定所有的需求，例如具有很长生命周期的系统或产品线，因此快速启动设计的可能性就非常重要ABD 方法的基础是以下思想：1) 基于耦合和内聚的思想进行功能分解；2) 通过选择架构风格实现质量和商业需求；3) 使用软件模板描述特定类型的软件系统ABD 方法的步骤如下：1) 功能分解；2) 选择架构风格；3) 为架构风格分配功能；4) 精化模板；5) 验证功能；6) 生成并发视图；7) 生成部署视图；8) 验证质量场景；9) 验证其它约束条件2.1.3 属性驱动的设计方法属性驱动的设计 ADD (Attribute Driven Design)方法把一组质量属性场景作为输入，利用对质量属性实现与构架设计之间的关系的了解，对构架进行设计。

ADD 是一种定义软件构架的方法， 该方法将模块分解过程建立在软件必须满足的质量属性之上它是一个递归的分解过程，其中在每个阶段都选择构架模式和战术来满足一组质量属性场景，然后对功能进行分配，以实例化有该模式所提供的模块类型ADD 的结果是架构的模块分解视图和其他视图的最初的几个层次，不是视图的所有细节都是通过 ADD 得到ADD 的结果是粗粒度的，由 ADD 得到的构架和已经为实现做好准备的构架之间的区别是：需要做出更详细的设计决策ADD 方法的步骤如下：1) 样本输入2) 选择要分解的模块3) 根据下列步骤对模块进行求精：a. 从具体的质量场景和功能需求集合中选择构架驱动因素b. 选择满足构架驱动因素的构架模式c. 实例化模块并根据用例分配功能，使用多个视图进行表示d. 定义子模块的接口e. 验证用例和质量场景并对其进行求精，使它们成为子模块的限制4) 对需要进一步分解的每个模块重复上述步骤2.2 面向产品线的架构设计方法2.2.1 面向特征的领域分析方法卡内基·梅隆大学的软件工程研究所(CMU/SEI) 提出了面向特征的领域分析方法FODA（ Feature-Oriented Domain Analysis Method）方法。

它支持对某领域中系统共性和个性的发现、分析和文档记录FODA 的过程分为三个阶段：上下文分析(Context Analysis) 、领域建模(Domain Modeling)、构架建模 (Architecture Modeling)1) 上下文分析：上下文分析的目标是定义领域的范围在这个阶段要分析领域与外部元素间的关系，例如不同的操作环境，不同的数据需求等，还要对可变性进行评价上下文分析的结果是上下文模型2) 领域建模：领域的范围确定后，领域建模阶段提供了一些步骤来分析领域中的应用的共同性和差异，并产生领域模型领域建模阶段主要包含三种行为： 特征分析(Feature Analysis)在特征分析阶段，要获得客户或最终用户对一类系统的一般能力的理解，即特征特征描述了领域应用的上下文、需要的操作和属性、以及表示的变化 信息分析(Information Analysis)在信息分析中，要定义和分析为实现领域中应用所需的领域知识和数据需求信息分析的目标是用领域实体及其相互之间的关系表示领域知识，并使它们在操作分析和构架建模中可以用来派生对象和数据定义 操作分析(Operational Analysis)。

在操作分析中，要识别领域中应用的行为特性，例如数据流和控制流的共同性和差异、有限状态自动机模型等3) 构架建模：这个阶段为领域中的应用提供软件解决方案在这个阶段中开发出构架模型，即领域中应用的高层设计这个阶段的焦点是识别并发进程和面向领域的共同模块这个阶段中定义进程，并将定义在领域模型中的特征、功能和数据对象分配到进程和模块中FODA 方法已成功地应用于美国空军运动控制等领域2.2.2 面向产品线的抽象、规范与转换面向产品线的抽象、规范与转换 FAST（Family-Oriented Abstraction, Specification, and Translation）的核心是通常所说的共性分析活动该活动依照通用的文本式语句的形式，标识了系统族中的共性系统族成员之间的不同之处也以相似的文本形式体现，并产生一个文档，即通常所说的领域模型，该模型刻画了产品系中的共性和差异这个领域模型作为“实现该领域”的基础来使用，其中包括了创建特定于领域的语言、架构和产生器等等，以便于只需较少的工作就能创建产品系中的新成员一旦可以获得合适的、特定于领域的应用工程环境，那么毫无疑问就可以大大地简化创建产品系中新成员所需要的工作量。

然而，开发这样一个环境本身就包含相当多的工作，不仅在最初创建环境时需要做很多工作，而且接下来维护中也有很多工作因此，它代表了一个高风险的“前期”投资，而许多组织不能够或者不愿意承担这个投资FAST 方法中的另一个问题是，它所解决的产品线问题仅仅位于非常高的抽象级别上，类似于传统开发方法中的分析层而关键性的，与具体实现技术的结合并没有直接解决而且，针对与领域分析过程而给出的准则很含糊而且没有规定性尽管存在这些问题，但 FAST 方法清晰地陈述一些关键特征，它们用于区分成功的产品线方法和传统的单系统方法它们主要是共性分析的思想，用于将产品系中成员之间的共性及其之间的差异显示标识成领域描述的一部分FAST 方法还提升了这样一个概念，即当需求下移到实现层时，对共性和差异进行持续地管理2.2.3 面向构件的平台架构面向构件的平台架构 COPA（Component-Oriented Platform Architecting）方法是飞利浦研究实验室为软件密集型的电子产品族而开发的COPA 方法的具体目标是在业务、架构、过程和组织中达到最佳的可适应性架构设计的具体目标就是在基于构件和以架构为中心的方法之间找到平衡，基于构件是依赖于组合机制的自底向上方法，而以架构为中心是依赖于变化的自顶向下方法。

COPA 覆盖了产品线的以下方面：业务、架构、过程和组织在此处，我们评估集中于架构和过程方面；（ ）COAP 方法应用的案例研究包括：在无线通讯基础设施系统、医药领域和软件密集型的电子产品领域在这些领域，COPA 有助于设计产品族产品族意味着一个由组件驱动的、自底向上的、部分机会主义的软件开发方法（尽可能地复用组织内现有软件创造产品）所开发的产品家族的广泛多样性COPA 方法从分析客户需求开始，具体点说，此方法的架构阶段输入是涉众期望、已存在的架构和关于架构的直觉；COPA 方法的架构阶段的输出是一个轻量级架构，它仅仅是关于架构的指导方针而不是传统意义上的软件分解COPA 方法的架构涉众包括顾客、供应商、商务经理和工程师COPA 采用多视角架构分别面向这四种主要的涉众运用 COPA 的主要动机是对降低管理复杂度和规模、获得高质量、管理多样性和缩减时间的承诺2.2.4 面向特征的重用方法Kyo C.Kang 和他韩国 Pohang 理工大学的同事们，提议把面向特征的重用FORM（Feature-Oriented Reuse Method）方法作为对面向特征的领域分析方法（FODA ）的一种扩展。

FORM 扩展 FODA 到软件设计和实现阶段，规定了如何用特征模型开发域架构和重用组件FORM 对如何在具有明确指导方针的可重用和可适配域组件工程中应用域分析结果（可变的和通用的）有明确的目标FORM 方法的应用领域是电信领域和信息领域然而，这种特征在任何应用域中都存在如果能从应用领域中获取特征模型，则 FORM 就适合该特定域的需要FORM 以特征模型开始，去发现、理解、捕获一个产品线的共性和差异性领域工程从软件开发的起点——上下文分析开始主要输入是关于共享一组通用功能和数据的系统的信息领域工程创建特征模型，输出参考架构和可重用组件从特征模型中选择好特征之后，应用工程创建应用软件，然后从参考架构中选择架构，从可重用组件中选择可重用组件FORM 面向大范围的领域和应用工程，包括可重用架构和编码组件的开发，它被用在许多工业领域。