软件架构设计方法综述.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方法的基础是以下思想： 基于耦合和内聚的思想进行功能分解； 通过选择架构风格实现质量和商业需求； 使用软件模板描述特定类型的软件系统。 ABD方法的步骤如下： 功能分解； 选择架构风格； 为架构风格分配功能； 精化模板； 验证功能； 生成并发视图； 生成部署视图； 验证质量场景； 验证其它约束条件。 2.1.3 属性驱动的设计方法 属性驱动的设计ADD (Attribute Driven Design)方法把一组质量属性场景作为输入，利用对质量属性实现与构架设计之间的关系的了解，对构架进行设计。 ADD是一种定义软件构架的方法， 该方法将模块分解过程建立在软件必须满足的质量属性之上。它是一个递归的分解过程，其中在每个阶段都选择构架模式和战术来满足一组质量属性场景，然后对功能进行分配，以实例化有该模式所提供的模块类型。