软件体系结构评估

《软件体系结构评估》由会员分享，可在线阅读，更多相关《软件体系结构评估（6页珍藏版）》请在装配图网上搜索。

1、计算机093 09416612 恽小燕软件体系结构评估近几年来,软件体系结构(Software Architecture ,SA)成为软件工程发展的一个热门 方向。随着对软件体系结构研究的深入开展, 逐渐形成了以软件系统的体系结构形式化描述、 风格、建模、评估、软件产品线以及基于软件体系结构的软件开发过程等为主要研究内容的 一个新领域。对一个系统的体系结构进行评估,是为了在系统被构建之前预测它的质量,并不 需要精确的评估结果，通过分析SA体系结构对于系统质量的主要影响，进而提出改进。因此， 软件体系结构评估的目的是分析潜在的风险,并检验设计中提出的质量需求。本文主要讨论 三种有代表性的方法,它

2、们可以指导评估人员成功地对系统的体系结构进行评估。这三种方 法是：基于场景的体系结构分析方法(SAAM)、体系结构权衡分析方法(ATAM)、体系结构级 别上的软件维护预测(ALPSM)。1. 主要的术语(1) 软件体系结构定义：软件体系结构定义很多, 本文采用为大多数人所接受的一种定义：“软件系统或计算 系统的软件体系结构就是系统的一个或多个结构,它包括软件组件,这些组件的外部可见属 性以及组件之间的相互关系”。这个定义仅仅关注系统内在的方面,而大多数的分析方法都 是基于这个定义的。这个定义具有如下的含义： SA是一个或多个系统的抽象。SA以抽象的组件(Com2ponent)来表示系统，这些组

3、件 具有外部可见属性，并且相互之间是有联系的，这种联系有时被称为连接件(Connector)。 SA是一种可重用、可传递的系统抽象，而组件的细节部分不属于体系结构的范畴。 系统由多个结构组成，通常也称为视图(View)。任何一个视图只能表示SA的部分内容, 而不是全部。(2) 质量属性质量属性是一个组件或一个系统的非功能性特征。软件质量在IEEE 1061中定义，它体现 了软件拥有所期望的属性组合的程度。另一个标准ISO/IEC Draft 91262 1定义了一个软件 质量模型。依照这个模型， 共有六种特征： 功能性、可靠性、可用性、有效性、可维护性和可 移植性， 并且它们被分成子特征， 根

4、据各个软件系统外部的可见特征来定义这些属性。(3) 风险承担者( Stakeholder)风险承担者就是对体系结构及根据该体系结构开发的系统有自己的要求的人员。风险承 担者涉及面很广， 可能是最终用户、开发人员、项目经理等。比较特殊的一类人员是项目决 策者， 即对评估结果感兴趣， 并有权作出影响项目未来开发决策的人。体系结构设计师也是很 特殊的一位风险承担者，一定要让他参加整个评估过程。(4) 场景( Scenario)场景就是对于风险承担者与系统的交互的简短描述。比如用户可能会描述如何使用该系 统来完成某项功能，这时场景就很类似于面向对象技术中的用例。在评估过程中，使用场景将 那些模糊的不适

5、用于分析的质量属性需求描述转换为具体的易于理解的表述形式。 评估技术在体系结构层次上有两类评估技术：询问和度量。本文讨论的评估方法都至少采用 了这两种技术中的一种,或是两种技术的结合(常同时混合使用,如下文讨论的ATAM就是一种 混合方法) 。a.询问技术。生成一个体系结构将要问到的质量问题，可适用于任何质量属性，并可用于 对开发中任何状态的任何部分进行调查。询问技术包括场景、调查表、检查列表。调查表是 通用的、可运用于所有软件体系结构的一组问题;而检查列表则是对同属一个领域的多个系 统进行评估,积累了大量经验后所得出的一组详细的问题。两种技术都是事先准备好的,由评 估人员用于搞清软件开发中反

6、复出现的问题。b.度量技术。采用某种工具对体系结构进行度量。它主要用于解答具体质量属性的具体 问题,并限于特定的软件体系结构,因此与询问技术的广泛适用有所不同。另外,度量技术还 要求所评估的软件体系结构已经有了设计或实现的产品,这也与询问技术不同。度量技术通 常包括指标(Metries)、模拟、原型和经验。2. 基于场景的体系结构分析方法( SAAM)SAAM于1983年提出，是最早形成文档并得到广泛使用的软件体系结构分析方法。它最初 用来分析SA的可修改性，后来实践证明也可用于其他的质量属性如可移植性、可扩充性等。 SAAM使用场景作为指定和评估质量属性的表述手段。如果是评估单个软件体系结构

7、SAAM将 指出体系结构中未能满足质量属性需求的地方,并提出改进的意见。而对于多个体系结构的 比较,则明确哪一个能更好地满足质量属性需求。图1描述的是SAAM的评估活动。图1SAA M的评估活动总的来说,SAAM评估分六个步骤：(1) 场景开发。通过集体讨论,风险承担者提出反映自己需求的场景。(2) SA描述。SAAM定义了功能性、结构和分配三个视角来描述SA。功能性指示系统做了 些什么,结构由组件和组件间的连接组成,而从功能到结构的分配则描述了域上的功能性是 如何在软件结构中实现的。场景的形成与SA的描述通常是相互促进的，并且需要重复的进 行。(3) 场景的分类。在分析过程中需要确定一个场景

8、是否需要修改该体系结构。不需要修 改的场景称为直接场景,需要修改的场景则称为间接场景。另一方面需要对场景设置优先级, 以保证在评估的有限时间内考虑最重要的场景。(4) 单个场景的评估。主要针对间接场景,列出为支持该场景所需要对体系结构做出的修 改, 并估计出这些修改的代价。而对于直接场景只需弄清体系结构是如何实现这些场景的。(5) 场景交互的评估。两个或多个间接场景要求更改体系结构的同一个组件就称为场景交 互。对场景交互的评估,能够暴露设计中的功能分配。(6) 总体评估。按照相对重要性为每个场景及场景交互设置一个权值,根据权值得出总体评 价。SAAM是一种成熟的方法,已被应用到众多系统中,这些

9、系统包括空中交通管制、嵌入式音 频系统、WRCS(修正控制系统)、KWIC(根据上下文查找关键词系统)等。3体系结构权衡分析方法(ATAM)ATAM是在SAAM的基础上发展起来的,SAAM考察的是软件体系结构单独的质量属性，而 ATA M提供从多个竞争的质量属性方面来理解软件体系结构的方法。使用ATA M不仅能看到体系 结构对于特定质量目标的满足情况，还能认识到在多个质量目标间权衡的必要性。在ATA M中， 体系结构设计师采用五个基本结构来描述SA ,即来源于Kruchten的4 + 1视图，只是将逻辑 视图分成了功能和代码结构,并且加上这些结构之间适当的映射关系。同时根据需要,还要采 用其他

10、的视图：动态视图,表明系统如何通信;系统视图,表明软件是如何分配到硬件的;源视 图,表明组件和系统如何组成了对象。ATAM的评估过程分为九个步骤。图2给出了每一个步曲段4跨声仙fM；1. /(堆4 休构、常川徇”威 丘瓯圧叫范処玲决策一嫩將&划 M史门;评估准备工忙枸收百 阶不述评骤,并将其分为四个阶段，图中循坏的箭头体现了SA设计和分析改进可能的迭代过程。RSi M风曉 朮抓吿为中D逬 rj-的 ih ”析枠系却耐勺汇I Appmarh)玳逊2 収悴 慕域构为屮也 曲亍莎析02 _电工吐1评估的步骤ATAM通过理解体系结构方法(Approach)来分析一个体系结构。体系结构方法是设计师 设计

11、过程中采用何种体系结构风格的决策,它体现了实现系统的质量属性目标的策略。在 ATAM 中，基于属性的体系结构风格(Att ribu te2 Based Arch it ec2 tural St yle ,ABAS)有助 于体系结构风格的概念转换为基于特定质量属性模型的推理。在步骤4 中就是通过设计师的 描述， 从而确定该体系结构为满足质量属性需求所使用的体系结构方法。 通过生成质量属性效用树，将商业驱动因素以场景的形式转换成具体的质量属性需求，并对 这些质量属性场景设置相对优先级。步骤6 中将步骤4 中确定的体系结构方法与生成效 用树得到的质量属性需求联系起来进行分析，从而确认与效用树中最高优

12、先级质量属性相联 系的体系结构方法，生成针对特定质量属性的提问，并且确认有风险决策、无风险决策、敏感 点和权衡点。风险承担者参与集体讨论场景并设置场景的优先级，再将这一组场景与效用树中生成的 场景进行对比。场景分为三类:用例场景(系统的典型使用，被用来获取信息) 、生长场景(预 料到的对系统的更改) 和探索场景(期望用来“压垮”系统的极端更改) 。使用不同类型的 场景， 可以从多个角度来考察体系结构。最终的评估结果所包含的内容也可以从图2 上看出来。在体系结构的设计过程中,ATA M提出了一种迭代的改进。当所有的评估活动结束后，将评 估的结果与需求作比较。如果系统预期的行为和需求能充分地接近，

13、设计者就可以继续进行 更高级别的设计或实现;如果分析发现了问题，就对所设计的SA、模型或需求进行修改，从而 开始了一次迭代的过程。随着发展, ATAM愈来愈成熟,被用到众多系统中。4体系结构级别上的软件维护预测(ALPSM)ALPSM方法通过在软件体系级别上考察场景的影响，来评估一个软件系统的可维护性。可 维护性在IEEE 610中定义。该方法采用场景来具体化可维护性需求，并且用来分析体系结构, 对于系统所需的维护性工作做出预测。预测的结果既可用来比较两个可供选择的体系结构， 也可用来平衡可维护性与其他的质量属性。图3给出了ALPSM评估方法的输入和输出。ALPSM方法包括如下六个步骤：(1)

14、 确认维护任务的分类。这种分类是基于应用或特定域的，因此并不抽象。(2) 合成场景。选择对于维护类别有代表性的场景，一般每一类选10个场景。这里的场景 与通常讲的描述系统行为的用例场景不同，它描述的是与系统相关的可能发生的活动或活 动的序列。一个变化场景则描述了系统的某个维护任务。(3) 给每个场景分配一个权值。定义权值为在某个特定间隔时间内，这个场景导致一个维护任务的相对概率。产生场景的权值要么使用历史维护数据来推断,要么由体系结构设计师 或域专家来估算。(4) 估算所有组件的大小。组件的大小影响在组件中实现一个改动所需的工作,因此通过 估算组件的大小来估算维护工作。(5) 分析场景。对于每

15、个场景,评估在体系结构及其组件中实现该场景带来的影响,最终 发现哪些场景受到影响及被改变到何种程度。(6) 计算所预计的维护工作。预测值是每个维护场景的工作的平均加权,体现了每个维护 任务的平均工作量。用下式来表示:P(Sn)场景n的概率权值；V(Sn ,Cm)场景n中受影响的组件m的数量；Ks =场景的 数目； Kc = 体系结构中组件的数目。、d C抄侔繼护输出,対堆护加:祥领段的绞骑n，丄哎肌方江;J工件的预测匕丈进尸逍那：图孑胚冋的输人和输出ALPSM方法适用于SA设计期间，而且还能在设计过程中反复地进行评估。它仅仅需要体 系结构设计人员参与,不需其他的风险承担者,而且还考虑到专家意见和历史数据的使用。此 方法已经用在一个血液渗析系统中。5.总结纵观本文介绍的三种有代表性的体系结构评估方法,SAAM以场景为中心，简单易用，但仅 仅是粗粒度的分析；而ATAM来源于SAAM、体系结构风格和质量属性，把对多个质量属性的权 衡放在首要位置，并结合场景;ALPSM则是一种轻巧灵活的方法，为设计师提供一个度量工具, 使得可以在设计期间重复地评估软件体系结构。SAAM，ATAM和ALPSM都是比较成熟的技术, 可以促进对于设计的体系结构的理解，更能提高体系结构设计的质量。