A Survey on Software Architecture Analysis s译文.docx

638 IEEE软件工程学报 28卷 7号 2002年7月一份基于软件体系结构分析方法的调查报告Liliana Dobrica 、 Eila Niemela 计算机学会成员摘要对于一个软件系统的体系结构，评价它的目的在于分析架构，以识别其潜在的风险，并且证明在设计中已经达到了所需的质量要求。这份调查报告通过对八个最具代表性的架构分析方法的阐述和讨论，展示了在这个领域的现阶段研究状况。所选取的研究方法尽量覆盖了许多对于客观性思考的特色观点，这些观点都来自于普通的研究对象。讨论的作用在于，为选取一份架构评估过程最合适的方法提供指导。我们将专注于通过分类、比较与适当的研究，来发现这八种可行方法的相同点和不同点。关键词软件架构、分析技术和方法、质量属性、场景1.简介现今软件体系发展的一个最主要的问题就是质量问题。从一个更高级别的设计说明来预测软件产品的质量，这种想法并不新奇。在1972年，Parnas就描述出了利用模块化和信息隐藏来作为一种高级别的系统分解方法，以此来提高灵活性和可理解性。在1974年，Stevens等人介绍了模块耦合和内聚性的概念，用于评估程序分解的取舍性。在最近几年，软件体系架构作为解决软件质量的恰当方法出现，这是因为科学界和工业界已经认识到SA为软件质量起到的保护作用。 最近，对于使用设计样式和建筑风格所引起的并发症的系统化努力，常常以一种不正式的方法为设计的质量做了保证。人们也认识到，基于SA设计方法去测量最终系统的质量特性是不可能的。这也意味着，细节设计和实施展现出了一个对于构架的严格规划。分析一个软件系统构架的目的，是为了在其已经建立但是没有做精确的估计之前预测这个系统的质量，而不是去预测这个构架的主要影响。评估的目的就是去分析SA，从而去识别潜在的风险并且验证质量需求是否已经达到了设计标准。l L. Dobrica毕业于布加勒斯特政治大学自动控制和计算机学院Independentei 313, Sect. 6,罗马尼亚布加勒斯特77206号. 电子邮箱: lilianaciid.pub.ro.l E. Niemela 涉及领域包括软件体系架构、嵌入式软件、VTT电子。邮政信箱：芬兰奥卢1100 FIN-90571 电子邮箱: eila.niemelavtt.fi.2000.7.3截稿；2001.3.22修订；2001.7.9发表； D. Rosenblum提供建议。获取文章转载信息，请发送邮件至，并且参考IEEECS登录号112394。 更多的专业的努力都集中在了确保质量已经达到构建水平的问题上。不同的软件测量协会，场景基础协会，以及基于模型的分析师都已经发展出了他们自己的技术。软件测量协会已经使用模块耦合和衔接的概念去定义测量软件质量的方法。其他的方法，也包括对SA是如何实现域功能和其他非功能性特征的更加具体的评估。除了展示出预测性评估的考量标准，他们还举例讨论了是否需要进行更多的定性或定量的评价。自从在过去的几年里基于场景的方法被应用和验证后，这种方法就被认为已经足够成熟，但是基于模型属性的构建方法的发展仍然在继续。 未来的工作需要制定沟通软件体系的质量需求与其架构之间联系的系统性方法。一个开放性的问题是：如何更好地利用软件体系结构的概念，以一种系统且缜密的方式去分析软件系统的质量特性。作为一个新的研究领域，大多数评估SA质量的架构方法都已经发表在会议和期刊论文上。尽管与之相关的细化和一些试验方法的验证仍在进行中，但是这仍然值得我们的关注，因为他们对这样一个仍然不够成熟的领域的发展做出了贡献。因此我们决定去研究这些方法，以确保能够尽量覆盖许多来自于普通研究对象并且出于客观性思考的的观点。SA被认为是在架构基础体系的发展过程中的第一个产品，从这个观点来看，在这一层面的需求应该站在特定的利益相关者的角度，来揭示需求冲突和不完整的设计说明。分析应该与一个绿色软件体系架构的迭代性发展的设计相关联，或者也可以与一个已存在的架构的工程重组相关联。具有独立性的质量属性的预测方法，是为了从一种合适的层面上最大化的减少出于属性片面化的风险。如果一个系统的质量是由各种各样相互作用的特性展现出来的话，这可能就不够充分了，并且在它们之间还应该建立一种平衡。本文所讨论的方法包括基于场景的体系结构分析方法(SAAM)和它的三个特殊情况下的扩展。一种扩展建立在复杂情境下(SAAMCS)，另外两个扩展基于可重用性，ESAAMI和SAAMER，架构权衡分析方法(ATAM),基于场景的架构再造方案（SBAR)，软件维护的架构水平测试(ALPSM)和一个软件体系结构评估模型(SAEM)。本项调查通过回顾软件体系结构分析方法的现状，将所有的这些发展放在相同的视角。在课题的开始部分，专门定义了在这些方法中频繁出现的专业术语。基于这些普遍的元素和其他相关的方法论特性，我们定义了一个概念框架，用来介绍和比较这些分析方法，并且同时试图寻找：1）随着时间的发展其在细化方面的进展，2）其主要贡献，3）通过使用它们所获得优点。围绕在所选方法的讨论主要集中在：1）发现异同，2）分类、比较和适当的研究。最终，我们将从当前研究的实际水平，以及通过已提出的方法所确定的在当前领域未来的工作而推导出结论。2.主要术语的定义2.1.质量特性和质量模型质量属性是一个构成或一个系统的非功能性特征。在IEEE1061中的软件质量认证，代表了软件所拥有的所需属性组合的程度。另一个标准，ISO/IEC草案9126-1，定义了软件质量模型。据此，有六类特性(功能性，可靠性，自我能力，效率，可维护性和可移植性)又被进一步细化分类。它们借助于每一个软件系统的外在可观察特性而被定义。为了确保其能被普遍应用，相应标准并没有规定这些特性要如何与其下层特征相关联。 文件的调查显示，大量的质量特性的定义都与一个软件系统的相似功能相关联。例如，可维护性、灵活性和可修改性的定义被描述如下：可维护性是一系列特性，其对需要作出特定修改的工作具有包容 性。修改可能包括修正，改进或者改变软件在环境、需求和功能规格上的适应性。可变性是快速做出改变并且高性价比的一种能力。对一个系统的修改可以被分类成可延展性(获取新功能的能力)、删除不必要的功能(简化现有应用程序的功能)、可移植性(适应新的操作环境)、或者重组(合理化的系统服务，模块化，创建可重用的组件)。灵活性是指一种系统或者组件可以在应用程序或者环境中易于修改的特性，而不是那些为了某些系统专门设计的。尽管表达的方式不同，在其语义上的定义几乎是相同的。关于分析SA相关定义的局限性就是他们的范围太广，这个范围必须要在相关环境的基础上缩小。2.2.软件架构的定义和描述定义。一种对系统软件架构的定义表述为“结构或者包括软件组件的体系结构，这些组件的外部可见特性以及它们之间的关系。”这个定义只关注系统的内在方面，大多的分析方法都基于此。另一个由Garlan和Perry提出的简短的定义，表明了SA“程序或系统的组件架构和它们之间的内在联系，控制设计的原则和方向以及及时的改进。”这个以过程为中心的定义被SAEM所使用，因为它考虑了在体系结构的描述中，原则和指导方向的存在。对于灵活性的分析，外部环境和系统的内部实体一样重要。SA的定义应该由两部分组成，一部分是着重于系统环境的次体系结构，另一部分是涵盖了系统内部架构的次体系结构。描述。对SA描述领域的研究，使我们发现了一种架构可以拥有不同的视角。每种视角都被描述为一种视图。尽管现在还没有关于哪种视图是最有用的普遍协定，但是多种视图背后的原因总是相同的：将不同的方向分离成不同的视图能够帮助人们处理复杂度。有很多介绍大量应该在SA中被描述的视图的模型已经被提出来了。视图模型可以完成静态和动态结构，物理布局，以及系统的开发。 Bass等人将视图作为与架构搭建相类似的概念来介绍。一般情况下，决定使用哪种视图去描述SA应该是架构师的责任。 从在架构层面上质量分析的角度来看，可能的表述应该和质量预测和工作评估关系紧密(图1).一种评估方法可能需要某种结构，这种结构应该和功能的分解有关，其所需的功能包括产品所需要的支持，对于体系构建过程中概念抽象的细节设计的认知，逻辑并发，硬件，文件和目录。每种结构的组成和相互关系都是具有代表性的。例如，逻辑的并发性包含优化的线程和进程单元。它们的关系包括同步关系，高优先级关系，数据发送关系，运行中不可或缺关系等。这种架构的相关特性包括优先级，抢占和执行时间。图一 .体系结构描述和其与质量特性分析的关联。 由SA正式定义的直接特性的的分类(TOPSA)所衍生出来的第一种SA定义已经在14中给出了。TOPSA空间有三个维度：抽象层次(概念、实现)，活动状态(静态、动态)和聚集程度，其可以在SA的研发和改进的过程中对讨论起到帮助。TOPSA和基于多视图相互补充的架构表现(见图1)。每种不同的视图都提供了关于抽象性、活动状态和聚集维度的有价值的例子。分析方法可以借鉴以已经定义的一系列规则所决定的这些相互关系，对于一个给定的质量特性，其所陈述的视图在TOPSA空间中是最为合适的。关于组件类型和其布局之间的描述、关于数据类型和组件之间相互关系的控制的描述，以及使用它们的优点和缺点在架构风格49、16和设计样式19中同样有所记录。可能会在SA中被使用的样式组合，在32中以各种专业术语的形式被评估。2.3.在架构水平上的评估技术两个评估技术的基本要点质疑和测量，都在两个重要的调查报告1和7所定义的架构水平中有所提及。质疑技术产生了在架构中所要求的定性问题，并且它们可以适用于任何给定的性质。这一类包括场景，问卷和检验单。测量技术表明了在架构中被制定的定量测量方法。它们被用来解决特定的问题，处理特定的软件质量，因此，他们并不像质疑技术一样被广泛的使用。这一类包括度量，模拟，原型和经历。一般来讲，细节水平、阶段和所评估的内容一起展现出了一个关于这些技术的四维的比较框架。一般看来，技术可以作用于通用领域(调查问卷)、特定领域(清单，原型)，或者特定系统(场景)。细节水平(粗糙的，中等或者细腻的处理)暗示了为了进行评估，需要多少架构相关的信息。对于架构分析，有三个相关的阶段：早期，中期以及后期调度。这些阶段发生在最初的高级架构决策(问卷，原型)之后,发生在完成架构设计的一些成品(场景，清单)之后的任何时段，也在系统的设计，实施和部署已经完成的阶段。就定量和定性两方面而言，这两类技术都需要体系评估。在形式化方法中所表达的各种分析模型，都包含在定量技术中。定性评估表明了SA评估需使用方案。每一种情况所需要的的变化的描述，代表了一种定性的评价方法。从这个角度来看，对于预测和控制质量特性，方案是必须的但并不是充分的，它们必须被辅以其他评价方法，特别是定量解释的部分。例如，在方案中包含关于质量指标的问题，丰富了架构评估。方案评估的定量解释可以被排名，其排名介于方案的效果(即一个五层模型(+,+,+/-,-,-)或一个绝对的陈述，这个陈述估计了改进或不同标准的尺度，例如代码行，功能标识或目标标识。大多数经过仔细推敲的架构分析方法都使用了方案。现有的关于方案的的做法在30中被系统化的描述。方案是将独立的软件特性的解释综合成一个共同的视图。这种视图比一般的软件特性的定义更具体，并且它还包括了将要开发的系统的特性(即，它有更强的上下文敏感性)。表 1分析方法的特性描述和比较的架构要素场景是一组系统的假设性的使用或修改。对于一个或多个组件如何执行一个指定的活动，组件的附加部分如何去执行一些活动，现存组件之间附加的联系，或者这些因素的组合来说，修改都可能使它们有所改变。在创建和组织场景中，重要的是所有的角色都和被设定的系统相关，因为系统的设计可能就是用来适应所有的这些角色的。不同的角色代表不同的系统利益相关者。这些相关者可能是最终用户，其负责软件的执行；系统管理员负责管理系统所使用的数据库；开发人员负责修改系统运行时的功能；整个团队负责审批新的需求。2.4.用于分析方法的特性描述和比较的架构基于SA分析方法介绍与比较的框架，是由上述陈述的概念和方法论的刻画(表1)所描述和诱发而出的。方法包括一个预定义的且有组织的技术的集合。然而除了这一组技术，方法还应该包括一系列规则，这系列规则规定了如何完成以实现某种结果为确切目标的活动：规则由谁来制定，以何种顺序，以哪种方法去使用技术来完成目标方法。3.分析方法概述3.1.基于场景的架构分析方法(SAAM)在1993年，随着对架构概念的更好理解的潮流，作为证明软件系统不仅仅需要功能性需求2627的一个基础，SAAM出现了。因此，在一个系统发展的早期阶段，在不使用过高成本的情况下，改正出由分析所检测出的架构错误仍然是有可能的。主要方法的使用，在关于不同用户界面的可变性评估的架构文章中有所表述。28具体目标。SAAM的目标是验证基本架构的假设，以及验证描述一份应用所需性质的记录原则。此外，分析也对架构内在的风险评估起到作用。SAAM将架构检验的重点集中在潜在的隐患点上，例如需求冲突或者从特定相关者的视角而言的不完整设计规范。SAAM 通过特定系统所需的性质来评估架构适宜性的能力同样也能被用于比较不同的体系结构。技术评估。情景展现出了用于说明SA特性的基本内容。它们说明了系统必须支持的活动类型以及需要对系统所做的预先的修改类型。在分析过程中，一类情景是否需要对架构作出修改是具有决定性的。不需要修改的情景被称为直接情景，而那些不需要修改的情景被称为间接情景。质量属性。这种方法的基本特征是用场景的形式将任何质量特性具体化。然而，SAAM的分析仍然认为可修改性是质量特性。 相关者的加入。SAAM协调每个相关群体的各种利益，从而建立一个对SA的共同理解，并作为之后决策的基础。 SA描述。该方法被应用到一个SA的最终版本，但是在进行细节设计之前。对SA应该以一种能容易被所有利益相关者理解的方式描述。功能，架构和分工是限定的描述SA的三个角度。功能就是系统所做的内容；一个精简的专业词汇可以在普遍的理解水平上来描述架构，以及比较不同的架构。SA应该用一个静态表示(系统计算、数据组件、数据和控制连接)和一个动态表示系统是如何运作的。功能的分配结构确定软件结构域的功能是如何实现的。组件可以被描述为Parnas方法44的模块或合作顺序流程。方法的活动。SAAM的主要输入问题是问题描述、需求声明和体系结构描述。图2给出了输入SAAM相关的活动进行一个单个体系结构评估比较多个体系结构。对于一个SA分析,开发活动场景,SA描述,个人场景评估和场景交互。在发展的场景中,SAAM需要所有参与者的存在,来识别如上所述中可能的情况。SAAM方法认为场景开发的完成是当添加一个不再扰乱设计的新的场景。第二个活动,SA体系结构的描述建议与第一个活动模式进行迭代。SA的最终版本描述的场景会作为后续活动的输入方法。SAAM调查评估场景的架构元素受到这种情况的影响。表2是一个示例场景评估架构，包含组件A,B,C,D,E .单一架构分析,目的是确定哪些场景交互,即哪些是影响相同的组件。修改的成本清单与每个间接估计场景相关联的组件连接,然后影响计数的数量变化。如果执行分析的目的是选择几个架构, 最后，对场景和场景间的交互作一个总体的权衡和评价。为此,场景和场景交互加权是相对重要的。然后使用这个权重来确定候选人的综合评价体系结构。结果的解释。无关的场景的高交互性可能表明有一个可分离的功能。交互场景的相关指标与结构复杂、耦合、凝聚力等有关。因此,交互场景的数量是与最终产品的缺陷的数量。SAAM不能给出精确的测量或指标的有效性。结果是一组细化的指标,允许竞争的基础上，每一个场景的比较。目前知识库的可重用性：SAAM不考虑这个问题。方法验证。SAAM是一种成熟的方法，已被应用到众多系统中，这些系统包括空中交通管制、嵌入式音频系统、WRCS（修改控制系统）、KWIC8（根据上下文查找关键词系统）等。3.2 SAAM建立在复杂的场景（SAAMCS）SAAMCS认为场景的复杂性是风险评估 35 的最重要因素。SAAMCS贡献扩展了SAAM，一方面，针对寻找场景的途径，另一方面，对其影响进行评估。具体的目标。风险评估是SAAMCS唯一的目标。包括评估技术。SAAMCS寻找场景实现可能是复杂的。基于场景的发起者、SA的描述和版本冲突，提供了一个复杂的场景类型的列表。质量属性。SAAMCS分析的灵活性代表了质量。利益相关者参与。该方法赞赏利益相关者的参与，并确定了一个场景的发起者重要的作用。发起人在组织单位中是对实施方案最感兴趣的。SA的描述。SAAMCS应用体系结构的最终版本是足够详细的描述。在这种方法中，不孤立，而是在一个环境中集成的域内的系统的想法是先进的。因此，SA的描述分为宏观架构和微观架构。方法的活动。图3描述了输入和活动SAAMCS。在场景发展中，一个二维结构图（五类复杂的情况，四个来源的变化），可能有助于发现复杂场景的定义。来源的变化的功能要求、质量要求、外部组件和技术环境。复杂场景类别适应系统与外部的影响，对环境对和系统的影响，对宏观架构和微观架构，和版本冲突介绍。对于情况影响评价，SAAMCS介绍和使用测量仪器来表达情况的影响。定义的仪器包括影响场景复杂性的因素。确定了三个不同的因素：四个层次的影响的情况下（没有影响1），影响一个组件2），影响到3个组件，影响4），在信息系统和四个级别的存在版本冲突的所有者参与（没有问题的不同版本1），影响一个组件2），影响了3个组件，影响4），在信息系统和四个级别的存在版本冲突（没有问题是不可取的，而不是禁止2），创建相关的配置管理3个层次的所有者，创建冲突4个）。结果表示在一个类似于表3的表中。目前知识库的可重用性：SAAM不考虑这个问题。 方法验证。SAAMCS已被验证可应用于商业信息系统。3.3 在集成域中延展SAAMCS (ESAAMI)具体的目标。SAAM应用在以场景为中心的开发过程中，只考虑了问题的描述，要求语句和结构描述。 ESAAMI是一个组合的分析和再利用的概念，通过整合一起在特定领域的实现和基于开发过程 43 重用，重用的程度是由专注于域的改进。ESAAMI相似于SAAM，其中以评价技术、质量属性的利益相关者的参与，和SA的描述。然而，一个改进是在重用领域知识定义的SAs分析模板。图4描述了ESAAMI主要输入和它们之间的关系。一个可重用的SA被封装在一个定制的分析模板侧重于架构的特色。所有这些包都代表了一个可重用的架构选择过程的输入。所选择SA是一个起点的体系结构设计，正在调整和完善，以满足新的系统性能。 SA的描述。在ESAAMI新制度部署一个可重用的SA是第一步。必须确保为满足其要求的系统提供足够的基础。三个因素影响一个架构的可重用性。作者确定了一个共同的基础，在一个领域中的各种系统，有足够的灵活性以应付系统间的变化，并提供了文件的属性可供选择。 现有知识库的可重用性。ESAAMI提出分析模板、代表域的基本特征包。一种分析模板是制定在抽象级别上的共同定义域中没有参照系统的具体构架元素的方法。分析模板收集可重用的产品可部署在该方法的各个步骤中。这些产品是原始的场景、评估协议，原评估、构架的提示和权重。原始场景是系统的复用情况或相互作用的一般描述。这些都是用于体系结构分析选择和细化过程后的方案开发阶段。其他产品用于场景评价阶段，并确定在不同的项目的早期评估的协议，或者如何使用一组抽象的架构元素的描述的例子，并提示相关联的每一个场景表示，使场景方便处理。建立在旧的项目中的权重可以使分析结果能够进行比较。 方法的行为类似于SAAM，但他们考虑了一个可重用的知识库。现状分析的结果是新建成的系统的一部分。 方法验证。该方法仍在改进过程中。 3.4 软件体系结构分析方法的改进和重用(SAAMER) 具体的目标。从两个特定的质量属性、改进的角度和可重用性来看，SAAMER 41 扩展了SAAM。SAAMER更好的显示了系统可以支持的每个质量目标、改进的风险水平和如何使用它。 评价技术。情景是评价SA不同区域的主要驱动因素。它们描述了系统必须支持的一个重要功能，或者识别系统需要随时间变化的地方。场景的发展基于利益相关者和架构的目标，并考虑系统的基本用途。方案和结构视图能有效的识别需要修改的组件，或是有用的预防和自适应维护活动。 质量属性。改进和可重用性被认为是质量属性，演化集成了新的质量目标（可维护性、可修改性）领域的专家。 利益相关者的参与和SAAM类似。此外，被认为是2种来源的信息，所需的变化和领域专家的经验。 SA的描述。SAAMER认为以下的建筑观的关键：静态，动态，地图，和资源。静态视图集成和扩展SAAM解决系统的分类和泛化的组件和功能和组件之间的连接。这些扩展的便利或工作所需的成本估计的变化被制造的。动态视图的评估在控制和通信方面是适当的行为，以验证是否以一个预期的方式被处理。映射函数之间的组件和可揭示系统的凝聚力和耦合方面。 方法的活动。SAAMER的活动提供了一个框架是有用的分析过程。这个框架由四个活动组成:收集信息关于利益相关者13、SA、质量和场景;建模可用工件;分析;评估。最后两个活动类似于SAAM。然而,在SAAMER的场景开发阶段给出了关于何时停止生成场景的答案。两种技术应用：首先,场景生成各种类型的目标有着紧密的联系:利益相关者、架构和质量。基于目标和领域专家的知识来确定场景的识别和集群,以确保覆盖每个目标。第二技术验证相对于客观场景的平衡应用质量功能展开（QFD） 13 、 17 。一个级联的矩阵从利益相关者和建筑的目标、质量属性产生来显示的关系强度。最后,质量属性被转化为场景揭示每一个的覆盖范围。然后用每个质量属性除以覆盖的质量的优先级来计算出一个不平衡的因素。如果系数小于1,则应该开发更多的场景,来解决属性符合利益相关者、SA和质量的重要性。 结果解释。情景相互作用的分析被认为是一个关键的步骤，提供了分析结果。高度的相互作用可能表明一个组件是不分离。不过，SA表明可能这只是一个特定模式的本质。目前知识库的可重用性：SAAMER不考虑这个问题。该方法已被应用于电信软件系统。3.5构架权衡分析方法(ATAM)ATAM已经拓展为架构分析工作的特定质量属性:SAAM分析的可修改性、性能、可用性和安全性。ATAM被认为是1998年设计的螺旋模型29和1999年5月25螺旋模型的分析和设计,这也解释了它最近的演变和进步。具体的目标。ATAM的目标是提供一种相对于多个相互竞争的质量属性 5 理解SA的能力的原理和方法。ATAM确认多个软件质量之间的权衡的必要性，在系统开发之前指定一个系统的SA。质量属性。ATAM分析了多个存在冲突的质量属性。考虑到了开始的可修改性，安全性，性能和可用性。利益相关者的参与。ATAM要求收集所有相关的利益相关者的参与活动场景和需求。SA设计师也可以参与其中。SA描述。空间架构受制于遗留系统、互操作性和失败的项目。在SA五个基本结构的基础上,描述来自Kruchten的“4 + 1视图”33(他的逻辑视图分为函数和代码结构)。这些结构加上适当的映射它们之间完全可以描述一个架构。ATAM也需要几种不同的视图:一个动态视图,显示系统交流;系统视图,显示分配给硬件;软件源视图,显示组件和系统组成的对象。SA描述注释的消息序列图显示运行时交互和场景。ATAM由外部的分析师团队应用在SA设计或SA的最终版本。包括的评估技术。ATAM可以被认为是一个框架,用于不同的评估技术取决于质量属性。它用一中有效的和实际的方式 20 ， 42 ， 52 集成了每个考虑的属性的最佳的个体理论模型。 另一个评估技术是场景。三种类型的场景从不同的架构视图探测系统。这些是:包括典型系统的使用和利用信息抽取的用例;涵盖预期变化的增长情况;达到系统预期的“压力”，覆盖极端变化的探索性场景。在这种方法中，有一个三重场景的作用。这种技术有助于把模糊,没有量化需求约束下来。同时,场景促进利益相关者之间的沟通,因为能够将他们的需求变得一致。最后,场景探索空间定义为一个属性模型,用来帮助把模型参数不属于SA成具体的条款。 ATAM也考虑了定性分析的启发式算法，它是根据架构风格属性（ABAS） 32 的，并在一个精确的质量属性分析模型的建立时执行粗粒度的版本的分析。每个属性现有的分类是ATAM另一个基础。分类有助于确保属性的覆盖范围和要求引出的问题提供了理论基础。ATAM还筛选问题、指导或焦点于引出更多的“影响”SA的地方。这些服务将限制在审查中的架构的部分。问这些问题比建立属性的定量模型更实用。他们捕捉到的典型问题的本质，发现了更严格和正式的分析。 方法的活动。该方法被分为四个主要领域的活动或阶段 29 。这些都是场景和需求的收集、建筑的观点和场景的实现、属性模型的建立和分析以及权衡。图5为详细的活动，包括场景和图6描述了与每个阶段相关联的步骤和SA可能的迭代，用于模拟和分析改进。 属性专家独立创建和分析他们的模型,然后他们交换信息(澄清和创造新的需求)。属性分析是相互依存的，因为每一个属性都有对他人的影响。属性的相互作用被发现在2个方面：使用敏感性分析，找到权衡点并通过检查的假设。从知识库来看，未确定的敏感点是还没有被绑定到架构属性的非正式称谓。敏感点是一个或多个组件（和/或组件关系）的属性，对于实现特定的质量至关重要。因此，在实践中架构参数的变化显著影响着模拟值。这可以通过使用属性的分类 4 ， 5 的刺激和建筑参数分支得到。权衡点是敏感的多个架构元素。一个权衡点是一个影响多个属性的属性、一个至少有一个属性的敏感点。在这个构架设计中，ATAM提供一个迭代改进。除了需要通常来自通过与利益者相关的采访中产生的情况，还有假设关于行为模式和执行环境的要求。因为属性“权衡”相互对抗，每个假设都是经过检验，验证，并且质疑ATAM的结果。当这些所有的工作都完成了，与需求做对比。 如果系统测试的结果充分接近它的需求，设计师们师可以进行更详细的设计或实施水平。事件的分析揭示了一个问题，一个行动计划改变SA的模型或要求，这导致另外一个迭代方法。ATAM并不要求对所有的属性进行分析，所以设计师们只需要专注于一些主要的属性，然后再介绍其他的属性。这导致成本效益，因为这可能使昂贵的分析，二次属性不需要应用到不适合作为主要属性的构架上。 一个领域知识库的重要性主要在ABAS。ABAS有助于从结构风格的概念走向拥有能够思考，推理质量属性的具体模式。收集ABAS的目标是使结构设计更加常规化和可预测性，有一套标准的基于属性的分析问题，并且加强设计和分析之间的联系。该方法已被应用到多个软件系统，但仍在研究中。3.6基于场景的架构重组（SBAR）这种方法的贡献不仅体现在建筑设计中，也在基于场景的软件质量评价系统的详细体系结构中有所体现。具体的目标。SBAR估计设计的体系结构的潜力达到了对软件质量的要求。包括评估技术。确定质量属性的四种技术如下：场景，模拟，数学建模和基于经验的推理。对于每个质量属性，选择合适的技术。为质量属性的发展做的建议方案，如可维护性和可重用性，这是在本文中的例子的质量属性的方案 8 。选定的方案具体化属性的实际意义（即捕捉典型的需求变化的情况下，要求指定的可维护性）。通过分析评估了每个场景中定义的一个质量属性的体系结构的性能。仿真使这种方法更加完整，可用于评估软件质量等性能和容错性。数学模型允许静态评价的建筑设计模型，并且它是一种替代的模拟，所以这两种方法都是主要适用于评估业务软件质量。评价操作软件的质量，由不同研究团体为提供高性能50，高可靠性48和实时性39开发的现有的数学模型可以使用。基于经验的推理是建立在经验和逻辑推理的基础上。这一技术与其他不同，因为在直觉和经验等主观因素的基础上，这一技术是不太明确的，它利用了人们的隐性知识。质量属性。SBAR研究多个软件质量。一些质量属性研究社区已经提出了他们自己的方法开发实时的 39 ，高性能的 50 ，和可重用的系统 24 。所有这些方法都集中在一个单一的质量属性，如果有其他质量属性的话，就把这些属性作为次要考虑。SBAR认为这些方法不理想，因为在任何实际系统的设计中都需要对不同质量属性的平衡。利益相关者参与。SBAR不需要许多利益相关者的参与。计算器就是SA的设计师。SA的描述。这种方法的一个特殊之处在于：用于评估现有系统的体系结构，该系统本身可以使用。SBAR使用详细设计的SA。方法的活动。评估过程包括为每个软件质量定义一组场景，手动执行的架构和解释的结果（图7）。该方法可以在一个完整的或统计的方式进行。在第一种方法中，一组场景被定义和组合在一起，它们涵盖了软件质量的具体实例。如果所有的场景都没有问题，则该体系结构的质量属性是最佳的。二是定义一组不包括所有的有代表性的样本。场景处理的好与不好的构架的比例提供了如何架构实现软件质量要求的指示。这两种方法都有明显的缺点。第一种方法的缺点是，它通常是不可能定义一套完整的场景。一组有代表性的场景的定义是二种方法中的一个很弱的问题，因为目前还不清楚如何确定一个场景集是有代表性的。从每个分析的体系结构和场景的结果总结为整体的结果，例如，接受的情况下的数量与不接受情况下的数量。SBAR为SA提供改进指南，类似于像表4这样的结构来表达结果。设计和分析结合起来进行一系列的迭代，直到大多数情况下每个质量属性都是令人满意的为止。现有知识库的重要性。SBAR不用考虑这个问题。SBAR已经为一个测量软件系统所验证软件维护的建筑水平预测（ALPSM）具体目标。ALPSM通过看情景在SA水平10上的影响来分析一个软件系统的可维护性。类似于软件维护社区11，它通过尺寸的变换来预测需要做一点努力来适应系统。包括评价技术。ALPSM定义了一个维护的轮廓，就像是一系列的情景变化表示着具有完备性和适应性的维护任务。一个场景描述的一个动作或者即将发生的动作序列与这个系统有关。因此一个变化的场景描述了一个特定的维护任务。利益相关者的参与。只有设计师参与了该方法的活动。SA的描述。ALPSM用于SA的终极版本。方法的活动。该方法有许多输入参数：包括要求声明，构架的描述，来自软件工程师的专业知识和可能的历史维护数据（图8）。ALPSM包括下面六个步骤：1、维护任务类的识别，2、合成方案，3、对每一个场景权重的分配，4、对每个元素的大小的估计，5、描述场景6、预测维修工作量的计算，第一步先制定基于应用程序或者程序描述的预期变化的类，然后对于每一个维护任务，定义一个有代表性的场景。该场景被分配一个在特定的时间间隔内可能发生的概率的权重。能够确定评估变化的大小和该系统所有的组件大小。这三种技术之一都可以估计系统组件的大小：使用估计技术，面向对象适应程度的度量，或者当历史数据从类似的应用程序或早期版本中可使用，那现有的数据可以使用和外推到新的组件中。通过总结场景影响的大小乘以他们的概率来预测总体的维护工作。每个场景实现的影响大小是通过其受影响的组件和他们将改变的何种程度来计算出来的。知识库的重要性不被考虑，但类似的应用程序或早期版本中的历史数据是有必要的。我们可以从以前的数据外推到新的组件中去。这个方法已经应用于血液透析系统中。3.8一个软件体系结构评估模型（SAEM)对SA质量要求的评价过程是严格的形式化的，尤其是在关系到18中所描述的模型的指标。通常选择基于标准软件质量评估过程的质量模型被，并且建议一个涉及SA的质量要求，指标和内部属性和终极系统的概念框架。根据标准规范，一个软件系统质量评价所需的要素是一个质量模型，一种评估，度量方法和支持工具。具体目标。SAEM为SA的质量评估和最终系统质量预测建立基础。评价技术。SAEM试图定义基于目标问题度量的质量度量（GQM）技术。指标的目标是发现某些属性是否符合质量规范中规定的每一个软件特性的值。质量属性。质量规范分为外部和内部两类。外部质量是用来表示用户视图，内部质量是表示开发者的视图。内部质量属性是由特殊的元素（如功能元素或数据元素）表示质量特性和发展过程中产生的内在属性（如大小、模块性、复杂性、耦合和内聚）组成的。有必要建立一个内部属性和它的价值之间相对重要性，QFD 47 被推荐用于此目的的合适的技术。利益相关者的参与。专家知识和一个公司的累计数据被用于内部属性的质量要求的映射。SA的描述。要从开发者和用户这两个不同的角度来考虑SA。因此，SA要么是最终产品，要么是软件系统开发过程的中间产物。体系结构开发过程限制了内部属性，因此测量过程的结果可以作为反馈形式来提高体系结构。体系结构描述语言（ADL）模型应附上质疑或检测技术（如SA模型演练）来检测是否存在特殊元素的缺失。固有的特性只能通过适应于正式通过ADL的SA的检测技术检查出来。方法的活动。SAEM给了一个基于数据采集，测量和分析结果的质量评价模型。这个分析过程分为外部和内部过程，并且这个分析过程是从用户和开发者两个视角进行的。指定的质量要求被映射于将在SA中出现的内部属性，并且这些质量要求是建立在专家知识和公司积累数据之上的。不考虑现有知识库的可重用性。然而，评价模型假定存在一个以前的内部质量规范，它定义了预期的内部属性与他们的价值和评价程序。SAEM目前还没有在任何软件系统的验证。4. 讨论本次讨论的目的是提供指引相关的一个架构评估过程中的最合适的方法的选择。图9表明了主要检查的问题。在开始的时候侧重于研究集体目标的确定和这一目标在每个分析方法中如何划分。然后，建立几种分类的方法。包括评估技术，质量属性的数目，利益相关者的参与，和SA的描述，或者当方法被应用于基于体系结构的开发过程中，分类的主要标准。维护实例有针对性的探讨，我们认为只考虑最具代表性的方法。共同的活动，如情景的发展和他们关于何时停止生成场景以及如何对一个被考虑的体系结构中场景的影响的评估，都被确定在情景为基础的分析方法。最后一部分讨论从SAAM到ATAM的演变的特殊情况，以及如何利用现有的分析方法重用现有的知识。最后，我们总结归纳了所考虑的SA分析方法。4.1恰当学习方法的具体目标客观的意见被认为是建立分析方法最适合于一个架构评估过程的基础。虽然每一种方法都有其特殊性的定义，我们可以在其中确定一个共同的目标，一个在系统建立之前的质量预测的目标。在每一种方法中，这一目标在不同的角度和角度都体现出来。他们映射如下：指导SA的检查，聚焦于潜在的麻烦（SAAM,ESAAM）；风险（SAAMCS）；评价所设计的SA可能达到软件质量要求（SBAR，SAAMER）；预测基于架构的软件系统的质量属性（ALPSM）；建立了对SA最终系统质量进行评价和预测的基础(SAEM)；在SA中的定位和分析权衡，这些都是在一个构架中的组ui高危险区（ATAM）。目标的集中和特殊的特性导致所有这些方法的相似性和差异性。4.2分类方法基于评价技术，我们可以通过考虑他们实用的技术来建立一个分类的方法。从这一点来看，方法有如下几种：纯粹基于场景，例如SAAM；基于场景和属性模型的分析方法，如ATAM；根据不同属性提出各种评价方法，像SBAR，依靠相关的指标的评价方法，如SAEM。一种定量评价属性的质量模型在评估过程中以两种方式对待，但从这个角度去哦吗确定了不同的方法。SAEM试图定义基于GQM的技术指标，然而同时ATAM认为分析技术所固有的各种质量属性的社区可以提供用于进行SA评价基础。发明属性特定的技术和指标是没有必要的，但将现有的系统整合到系统的方法中还是很有必要的。ATAM提供在每个考虑属性的最佳个体理论模型集成的灵活性。在考虑到质量属性数的基础上，一些方法是集中在一个单一的质量属性的评价。然而，为了更好地了解复杂的实际系统和它的组成部分的优点和缺点，一个多属性分析的性能是有必要的。研究分析方法的一个重要特征是，质量属性的数量是一个方法的重点。我们能够区分多个质量属性（ATAM,SBAR）。例如，ATAM认为简直元素在多个属性相互作用，也有单质量属性（SAAM）和具体的质量模型（SAEM）。基于利益相关者的参与，虽然所有的利益相关者参与评估过程有利于他们之间的沟通，但是所有的方法都认为他们的存在是强制性的。ALPSM不同于SAAM，它不涉及所有利益相关者，因此，需要更少的资源和时间。相反，它为软件构架师提供了一个工具使他们在设计过程中能反复评估构架。由于利益相关者责任的需求，这种方法可以结合使用SAAM。在SAAM和ATAM中，架构的详细设计之前，与利益相关者合作分析评价，然而在SBAR中，详细设计体系结构时不需要利益相关者的参与。但同时提出了典型的质量问题。这种方法适用于什么时候？当考虑到基于体系结构的开发过程的时候，这个问题就会得到不同的回答。类似的方法，结合结构分析和设计为一个迭代改进过程，可以在ATAM和SBRA中得到鉴定。但是，尽管SBAR有为了满足一定的质量要求对如何变换结构有指导方针，而ATAM也只是集中在识别灵敏度和权衡点。然而，ATAM也可以应用到对SA最终版本的评价。SAAM, SAAMCS, ESAAMI, 和 SAAMER也应用于最后的版本。ALPSM应用于预测的自适应和完成软件维护的设计中。SAEM应用于最终版本，但是在这里，值得注意的是SA是从开发者和用户这两个角度来考虑评价模型的。因此，SA要么是最终产品，要么是系统开发过程中的哟个中间产物。SAEM的严密性使很难相信这将是适合于使用在一个迭代的SA设计过程。4.3常见的活动和基于场景的方法的不同的方法该方法的活动的复杂性和粒度/聚集程度不同。复杂性代表了难度、时间或其他工具或文档需要执行该活动的数量。所有的方法都是手动执行的，目前而言，对任何软件工具都没有任何要求。文档在一些方法和包含在可重用的知识基础上是有必要的。粒度/聚集水平意味着一个活动可以代表一组的子活动，或分步骤的一个阶段。例如，SAAMER定义4个活动的构架，其中包括SAAM中的所有活动。ATAM也分为4个阶段，每个阶段有多个步骤。基于场景的评估特别适合于软件开发的品质。软件的可重用性、可维护性等特点，可修改性，可移植性和适应性，可以很自然地通过改变场景表达出来。如Poulin46总结的那样，当考虑到可重用性时，没有主要的方法，以评估这种质量属性存在。评估架构的使用方案，建议作为一个最佳的工业实践 1 。为此，我们讨论在以下情况，不同的方案开发和场景的影响评价的建议。方案的发展。一种常见的基于场景的活动方法是场景开发。我们确定了不同的解决方法来试图回答这个问题，“在一个活动中何时停止场景的发展？”SAAM认为当另一个新的场景不去干扰设计的情况下，场景的集合是完整的。方案也引起考虑所有的利益相关者的意见。在SBAR中，对两种方法进行了讨论。一个是定义一个完整的集合，这是通常不可能的。另外一个就是定义代表集，然而它的弱点就是如何来定义这个代表集。最后一个是基于软件工程师的创造性和主观性。SAAMCS认为相关方案实现起来很复杂。一个有助于发现复杂情况下被定义为二维框架图（五类复杂情景，四个来源的变化）SAAMER定义了一个实用的两个步骤。第一步，得到覆盖全面的保障。这些情况基于目标和领域专家知识被确定和集中，检查覆盖面依赖于利益相关者，构架，质量的目标。第二步验证了相对于基于QFD技术的客观场景的平衡。制定更多的方案是基于对每个质量属性的计算出的不平衡系数的比较所决定的。ATAM使用一套标准的质量属性的具体问题来确保适当的覆盖属性。应该包含条件边界。一套标准的质量问题提供了获得需要的信息来分析质量的可预测性和可重复性性方式的可能性。ALPSM为每个预期的维护任务定义了一组有代表性的情形。方案的评价。有差异的情况下，考虑构架的影响评估。SAAM研究那些构架元素受到每一种情景的影响。与每个间接场景相关联的修改的成本由关系列表的组件和被影响的连接器，然后计数的变化的数量来估计的。在ALPSM，实施该方案所需要做的努力是由估计组件的大小和受影响的程度来预测的。这个活动可能需要历史维修数据。SAAMCS定义和使用一个测量仪来表达场景的效果。该仪器显示了一个场景的影响，无论所有者是否参与或者它是否会导致版本冲突。在saam,分类和泛化的架构元素促进所需的估计成本或工作的变化。那些所需的更改，特别是由场景和领域专家提出来的那些修改，建议了每个目标或者系统演进的风险或者跨应用程序的再使用应该怎么获得支持。最后,在SBAR,评价可以通过执行一个完整的或统计的方式进行。一个质量属性的最优化可以通过前一个的方法实现，而一个质量属性的完成只用后一个就可以得到。4.4方法演变的讨论定性和定量进展的一种特殊情况在ATAM中被关注。考虑到情景的用途，ATAM基于SAAM。不像SAAM，侧重于建筑修改评估的场景使用，ATAM侧重于从产品质量的角度在建筑中寻找折衷点。此外,ATAM规定了正式或非正式的分析模型来评估系统的质量属性,但每一种情形下的质量属性都依赖于这些技术的存在。在修改性的分析这种情形下,ATAM建立检验和审查方法，例如SAAM非正式模型。场景交互解释为灵敏度点。4.5一个现有知识库的可重用性粗粒级的相似之处也可以在ATAM和ESAAMI之间确定。这两种方法都基于SAAM。考虑到现有知识的可重用性，ATAM采用了ABASs和ESAMI提出了分析模板和可重复使用结构的架构包。然而，当我们谈论信息的系统化，没有进行比较的可能。ESAAMI允许使用直观的形式提供域各自特定架构的体验，而ATAM是锚定在一个很好的结构化知识库属性的社会团体和建筑风格。阿巴斯提供了一组分析预包装和问题，包括了常见问题解决方