《ASurveyonSoftwareArchitectureAnalysisMethods译文》由会员分享，可在线阅读，更多相关《ASurveyonSoftwareArchitectureAnalysisMethods译文（16页珍藏版）》请在金锄头文库上搜索。
1、638 IEEE 软件工程学报 28 卷 7 号 2002 年7 月一份基于软件体系结构分析方法的调查报告Liliana Dobrica 、 Eila Niemela 计算机学会成员摘要对于一个软件系统的体系结构，评价它的目的在于分析架构，以识别其潜在的风险，并且证明在设计中已经达到了所需的质量要求。这份调查报告通过对八个最具代表性的架构分析方法的阐述和讨论，展示了在这个领域的现阶段研究状况。所选取的研究方法尽量覆盖了许多对于客观性思考的特色观点，这些观点都来自于普通的研究对象。讨论的作用在于，为选取一份架构评估过程最合适的方法提供指导。我们将专注于通过分类、比较与适当的研究，来发现这八种可行
2、方法的相同点和不同点。关键词软件架构、分析技术和方法、质量属性、场景1.简介现今软件体系发展的一个最主要的问题就是质量问题。从一个更高级别的设计说明来预测软件产品的质量，这种想法并不新奇。在 1972 年，Parnas 就描述出了利用模块化和信息隐藏来作为一种高级别的系统分解方法，以此来提高灵活性和可理解性。在 1974 年，Stevens 等人介绍了模块耦合和内聚性的概念，用于评估程序分解的取舍性。在最近几年，软件体系架构作为解决软件质量的恰当方法出现，这是因为科学界和工业界已经认识到 SA 为软件质量起到的保护作用。最近，对于使用设计样式和建筑风格所引起的并发症的系统化努力，常常以一种不正
3、式的方法为设计的质量做了保证。人们也认识到，基于 SA 设计方法去测量最终系统的质量特性是不可能的。这也意味着，细节设计和实施展现出了一个对于构架的严格规划。分析一个软件系统构架的目的，是为了在其已经建立但是没有做精确的估计之前预测这个系统的质量，而不是去预测这个构架的主要影响。评估的目的就是去分析 SA，从而去识别潜在的风险并且验证质量需求是否已经达到了设计标准。 L. Dobrica 毕业于布加勒斯特政治大学自动控制和计算机学院Independentei 313, Sect. 6,罗马尼亚布加勒斯特 77206 号 . 电子邮箱 : lilianaciid.pub.ro. E. Nieme
4、la 涉及领域包括软件体系架构、嵌入式软件、VTT 电子。邮政信箱：芬兰奥卢 1100 FIN-90571 电子邮箱 : eila.niemelavtt.fi.2000.7.3 截稿； 2001.3.22 修订； 2001.7.9 发表； D. Rosenblum 提供建议。获取文章转载信息，请发送邮件至tsecomputer.org，并且参考 IEEECS 登录号 112394。J 更多的专业的努力都集中在了确保质量已经达到构建水平的问题上。不同的软件测量协会，场景基础协会，以及基于模型的分析师都已经发展出了他们自己的技术。软件测量协会已经使用模块耦合和衔接的概念去定义测量软件质量的方法。其
5、他的方法，也包括对 SA 是如何实现域功能和其他非功能性特征的更加具体的评估。除了展示出预测性评估的考量标准，他们还举例讨论了是否需要进行更多的定性或定量的评价。自从在过去的几年里基于场景的方法被应用和验证后，这种方法就被认为已经足够成熟，但是基于模型属性的构建方法的发展仍然在继续。未来的工作需要制定沟通软件体系的质量需求与其架构之间联系的系统性方法。一个开放性的问题是：如何更好地利用软件体系结构的概念，以一种系统且缜密的方式去分析软件系统的质量特性。作为一个新的研究领域，大多数评估 SA 质量的架构方法都已经发表在会议和期刊论文上。尽管与之相关的细化和一些试验方法的验证仍在进行中，但是这仍然
6、值得我们的关注，因为他们对这样一个仍然不够成熟的领域的发展做出了贡献。因此我们决定去研究这些方法，以确保能够尽量覆盖许多来自于普通研究对象并且出于客观性思考的的观点。SA 被认为是在架构基础体系的发展过程中的第一个产品，从这个观点来看，在这一层面的需求应该站在特定的利益相关者的角度，来揭示需求冲突和不完整的设计说明。分析应该与一个绿色软件体系架构的迭代性发展的设计相关联，或者也可以与一个已存在的架构的工程重组相关联。具有独立性的质量属性的预测方法，是为了从一种合适的层面上最大化的减J少出于属性片面化的风险。如果一个系统的质量是由各种各样相互作用的特性展现出来的话，这可能就不够充分了，并且在它们
7、之间还应该建立一种平衡。本文所讨论的方法包括基于场景的体系结构分析方法(SAAM)和它的三个特殊情况下的扩展。一种扩展建立在复杂情境下(SAAMCS)，另外两个扩展基于可重用性，ESAAMI 和 SAAMER，架构权衡分析方法(ATAM),基于场景的架构再造方案（SBAR)，软件维护的架构水平测试(ALPSM)和一个软件体系结构评估模型(SAEM)。本项调查通过回顾软件体系结构分析方法的现状，将所有的这些发展放在相同的视角。在课题的开始部分，专门定义了在这些方法中频繁出现的专业术语。基于这些普遍的元素和其他相关的方法论特性，我们定义了一个概念框架，用来介绍和比较这些分析方法，并且同时试图寻找：
8、1）随着时间的发展其在细化方面的进展，2）其主要贡献，3）通过使用它们所获得优点。围绕在所选方法的讨论主要集中在：1）发现异同，2）分类、比较和适当的研究。最终，我们将从当前研究的实际水平，以及通过已提出的方法所确定的在当前领域未来的工作而推导出结论。2.主要术语的定义2.1.质量特性和质量模型质量属性是一个构成或一个系统的非功能性特征。在IEEE1061 中的软件质量认证，代表了软件所拥有的所需属性组合的程度。另一个标准，ISO/IEC 草案 9126-1，定义了软件质量模型。据此，有六类特性(功能性，可靠性，自我能力，效率，可维护性和可移植性)又被进一步细化分类。它们借助于每一个软件系统的
9、外在可观察特性而被定义。为了确保其能被普遍应用，相应标准并没有规定这些特性要如何与其下层特征相关联。 文件的调查显示，大量的质量特性的定义都与一个软件系统的相似功能相关联。例如，可维护性、灵活性和可修改性的定义被描述如下：可维护性是一系列特性，其对需要作出特定修改的工作具有包容 性。修改可能包括修正，改进或者改变软件在环境、需求和 功能规格上的适应性。可变性是快速做出改变并且高性价比的一种能力。对一个系统的 修改可以被分类成可延展性 (获取新功能的能力 )、删除不必 要的功能 (简化现有应用程序的功能 )、可移植性 (适应新的 操作环境 )、或者重组 (合理化的系统服务，模块化，创建可 重用的
10、组件 )。灵活性是指一种系统或者组件可以在应用程序或者环境中易于 修改的特性，而不是那些为了某些系统专门设计的。尽管表达的方式不同，在其语义上的定义几乎是相同的。关于分析 SA 相关定义的局限性就是他们的范围太广，这个范围必须要在相关环境的基础上缩小。2.2.软件架构的定义和描述定义。一种对系统软件架构的定义表述为“结构或者包括软件组件的体系结构，这些组件的外部可见特性以及它们之间的关系。”这个定义只关注系统的内在方面，大多的分析方法都基于此。另一个由 Garlan 和Perry 提出的简短的定义，表明了 SA“程序或系统的组件架构和它们之间的内在联系，控制设计的原则和方向以及及时的改进。”这
11、个以过程为中心的定义被 SAEM 所使用，因为它考虑了在体系结构的描述中，原则和指导方向的存在。对于灵活性的分析，外部环境和系统的内部实体一样重要。SA 的定义应该由两部分组成，一部分是着重于系统环境的次体系结构，另一部分是涵盖了系统内部架构的次体系结构。J描述。对 SA 描述领域的研究，使我们发现了一种架构可以拥有不同的视角。每种视角都被描述为一种视图。尽管现在还没有关于哪种视图是最有用的普遍协定，但是多种视图背后的原因总是相同的：将不同的方向分离成不同的视图能够帮助人们处理复杂度。有很多介绍大量应该在 SA 中被描述的视图的模型已经被提出来了。视图模型可以完成静态和动态结构，物理布局，以及
12、系统的开发。 Bass 等人将视图作为与架构搭建相类似的概念来介绍。一般情况下，决定使用哪种视图去描述 SA 应该是架构师的责任。从在架构层面上质量分析的角度来看，可能的表述应该和质量预测和工作评估关系紧密(图 1).一种评估方法可能需要某种结构，这种结构应该和功能的分解有关，其所需的功能包括产品所需要的支持，对于体系构建过程中概念抽象的细节设计的认知，逻辑并发，硬件，文件和目录。每种结构的组成和相互关系都是具有代表性的。例如，逻辑的并发性包含优化的线程和进程单元。它们的关系包括同步关系，高优先级关系，数据发送关系，运行中不可或缺关系等。这种架构的相关特性包括优先级，抢占和执行时间。J图一 .
13、体系结构描述和其与质量特性分析的关联。由 SA 正式定义的直接特性的的分类(TOPSA)所衍生出来的第一种 SA 定义已经在14中给出了。TOPSA空间有三个维度：抽象层次(概念、实现)，活动状态(静态、动态)和聚集程度，其可以在 SA 的研发和改进的过程中对讨论起到帮助。TOPSA 和基于多视图相互补充的架构表现(见图 1)。每种不同的视图都提供了关于抽象性、活动状态和聚集维度的有价值的例子。分析方法可以借鉴以已经定义的一系列规则所决定的这些相互关系，对于一个给定的质量特性，其所陈述的视图在 TOPSA 空间中是最为合适的。关于组件类型和其布局之间的描述、关于数据类型和组件之间相互关系的控制
14、的描述，以及使用它们的优点和缺点在架构风格49、16和设计样式19中同样有所记录。可能会在 SA 中被使用的样式组合，在32中以各种专业术语的形式被评估。2.3.在架构水平上的评估技术两个评估技术的基本要点质疑和测量，都在两个重要的调查报告1和7所定义的架构水平中有所提及。质疑技术产生了在架构中所要求的定性问题，并且它们可以适用于任何给定的性质。这一类包括场景，问卷和检验单。测量技术表明了在架构中被制定的定量测量方法。它们被用来解决特定的问题，处理特定的软件质量，因此，他们并不像质疑技术一样被广泛的使用。这一类包括度量，模拟，原型和经历。一般J来讲，细节水平、阶段和所评估的内容一起展现出了一个
15、关于这些技术的四维的比较框架。一般看来，技术可以作用于通用领域(调查问卷)、特定领域(清单，原型)，或者特定系统(场景)。细节水平(粗糙的，中等或者细腻的处理)暗示了为了进行评估，需要多少架构相关的信息。对于架构分析，有三个相关的阶段：早期，中期以及后期调度。这些阶段发生在最初的高级架构决策(问卷，原型)之后,发生在完成架构设计的一些成品(场景，清单)之后的任何时段，也在系统的设计，实施和部署已经完成的阶段。就定量和定性两方面而言，这两类技术都需要体系评估。在形式化方法中所表达的各种分析模型，都包含在定量技术中。定性评估表明了 SA 评估需使用方案。每一种情况所需要的的变化的描述，代表了一种定
16、性的评价方法。从这个角度来看，对于预测和控制质量特性，方案是必须的但并不是充分的，它们必须被辅以其他评价方法，特别是定量解释的部分。例如，在方案中包含关于质量指标的问题，丰富了架构评估。方案评估的定量解释可以被排名，其排名介于方案的效果(即一个五层模型(+,+,+/-,-,-)或一个绝对的陈述，这个陈述估计了改进或不同标准的尺度，例如代码行，功能标识或目标标识。大多数经过仔细推敲的架构分析方法都使用了方案。现有的关于方案的的做法在30中被系统化的描述。方案是将独立的软件特性的解释综合成一个共同的视图。这种视图比一般的软件特性的定义更具体，并且它还包括了将要开发的系统的特性(即，它有更强的上下文敏感性)。J表 1分析方法的特性描述和比较的架构要素场
