软件体系结构第12章

软件设计和体系结构清华大学出版社1第12章软件体系结构评估清华大学出版社2内容提要12.1软件体系结构评估定义12.2SAAM软件架构分析方法12.3ATAM体系结构权衡分析方法12.4评估方法比较12.5小结清华大学出版社312.1软件体系结构评估定义12.1.1质量属性功能性可靠性可用性有效性可维护性可移植性清华大学出版社412.1软件体系结构评估定义12.1.2评估的必要性软件架构是软件工程早期设计阶段的产物，它对软件系统或软件项目的开发具有深远的影响。主要表现在以下两个方面不恰当的架构架构决定着项目的结构。清华大学出版社512.1软件体系结构评估定义12.1.3基于场景的评估方法基于场景的软件架构分析方法的基本观点是，大多数软件质量属性极为复杂，根本无法用一个简单的尺度来衡量。同时，质量属性并不是处于隔离状态，只有在一定的上下文环境中才能做出关于质量属性的有意义的评判。利用场景技术则可以具体化评估的目标，代替对质量属性（可维护性、可修改性、健壮性、灵活性等）的空洞表述，使对软件体系结构的测试成为可能。清华大学出版社6基于场景的软件架构分析方法步骤1、分析问题域，建立功能场景库。针对具体项目在应用领域中的定位，展开需求分析，汇总系统预期功能并按对功能进行分类以确保每项功能都能够得到详细描述，并为每个功能定义相应的场景，建立功能场景库。清华大学出版社7基于场景的软件架构分析方法步骤2、通过功能场景库测试评价软件架构对各功能的支持度，并针对支持度差的功能展开架构分析。支持度的评价涉及到架构是否满足功能场景、是否容易扩展该功能等。一旦发现支持度差的功能，则进一步分析是否是由架构设计导致的，从中发现可能的架构设计缺陷和不足。清华大学出版社8基于场景的软件架构分析方法步骤3、建立非功能指标参数树。选择一组感兴趣的非功能性指标，如可移植性、安全性、性能等，并详细定义每一个指标的衡量属性、期望值和相应的场景。清华大学出版社9基于场景的软件架构分析方法步骤4、应用指标参数树对软件架构进行非功能性分析。通过比较架构在场景中的实际输出值和期望值，来评价架构对各个指标的各个属性的支持度，并在该过程中发现软件架构的缺陷，找出风险决策、无风险决策、敏感点、权衡点。清华大学出版社10基于场景的评估方法的特征：场景是这类评估方法中不可缺少的输入信息，场景的设计和选择是评估成功与否的关键因素。这类评估是人工智力密集型劳动，评估质量在很大程度上取决于人的经验和技术。基于场景的评估方法是研究最广泛，应用最成熟，数量最多的一类软件体系结构评估方法。清华大学出版社11基于场景的评估方法的不足（1）评估的效果对评估师经验的依赖程度较高。（2）“重量级”的评估技术，成本较高。（3）没有考虑知识的积累和应用问题，造成资源的浪费。（4）缺乏实用的评估信息管理工具。清华大学出版社1212.2SAAM软件架构分析方法SAAM方法，是卡耐基梅隆大学软件工程研究所的Kazman等人于1983年提出的一种非功能质量属性的体系结构分析方法，是最早形成文档并被广泛使用的软件体系结构分析方法。清华大学出版社1312.2SAAM软件架构分析方法特定目标:SAAM的目标是对描述应用程序属性的文档，验证基本的体系结构假设和原则。此外，该分析方法有利于评估体系结构固有的风险。SAAM指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突，或仅从某一参与者的观点出发的不全面的系统设计。SAAM不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。评估技术:SAAM所使用的评估技术是场景技术。场景代表了描述体系结构属性的基础，描述了各种系统必须支持的活动和将要发生的变化。质量属性:这一方法的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。清华大学出版社1412.2SAAM软件架构分析方法风险承担者:SAAM协调不同参与者所感兴趣的方面，作为后续决策的基础，提供了对体系结构的公共理解。体系结构描述:SAAM用于体系结构的最后版本，但早于详细设计。体系结构的描述形式应当被所有参与者理解。功能、结构和分配被定义为描述体系结构的三个主要方面。方法活动:SAAM的主要输入问题是问题描述、需求声明和体系结构描述。清华大学出版社1512.2.1SAAM的一般步骤（1）场景形成。（2）描述软件体系结构（3）场景的分类和优先级划分（4）间接场景的单独评估（5）评估场景交互（6）形成总体评估清华大学出版社1612.2.2场景形成在形成场景的过程中，要注意全面捕捉系统的主要用途、系统用户类型、系统将来可能的变更、系统在当前及可预见的未来必须满足的质量属性等信息。形成场景的过程也是集中讨论的过程。清华大学出版社1712.2.3描述软件体系结构软件体系结构设计师应该采用参加评估的所有人员都能充分理解的形式，对待评估的体系结构进行适当的描述。清华大学出版社1812.2.4场景的分类和优先级确定评估人员通过对场景设置优先级，可保证在评估的有限时间内考虑最重要的场景。直接场景间接场景清华大学出版社1912.2.5间接场景的单独评估对于直接场景而言，体系结构设计师需要讲清楚所评估的体系结构如何执行这些场景对于间接场景而言，体系结构设计师应说明需要对体系结构做哪些修改才能适应间接场景的要求。清华大学出版社2012.2.6评估场景交互当两个或多个间接场景要求更改体系结构的同一个构件时，我们就称这些场景在这一组构件上相互作用。清华大学出版社2112.2.7形成总体评估形成总体评估，是SAAM评估方法的最后一个步骤。评估人员要对场景和场景之间的交互作一个总体的权衡和评价。这一评价反映该组织对表现在不同场景中的目标的考虑优先级。清华大学出版社2212.3ATAM体系结构权衡分析方法ATAM分析方法，是评估软件架构的一种综合全面的方法。这种方法不仅可以揭示出软件体系结构满足特定质量目标的情况，而且可以使我们更加清楚的认识到质量目标之间的联系。清华大学出版社2312.3.1ATAM参与人员3个小组参与合作。评估小组项目决策者涉众清华大学出版社2412.3.2ATAM结果一个简洁的体系结构描述。我们通常认为体系结构文档是由对象模型、接口及其签名的列表或其他冗长的列表组成的。但ATAM的一个要求就是在一个小时内表述体系结构，这样就得到了一个简洁而且通常是可理解的体系结构表述。表述清楚的业务目标。开发小组的某些成员通常是在ATAM评估上第一次看到表述清楚的业务目标。用场景集合捕获的质量需求。业务目标导致质量需求。一些重要的质量需求是用场景的形式捕获的。体系结构决策到质量需求的映射。可以根据体系结构决策所支持或阻碍的质量属性来解释体系结构决策。对于在ATAM期间分析的每个质量场景，确定那些有助于实现该质量场景的体系结构决策。清华大学出版社2512.3.2ATAM结果所确定的敏感点和权衡点集合。这些是对一个或多个质量属性具有显著影响的体系结构决策。例如，采用一个备份数据库很明显是一个体系结构决策，它影响了可靠性。因此，它是一个关于可靠性的敏感点。然而，保持备份将消耗系统资源，影响系统性能。因此它是可靠性和性能之间的权衡点。该决策是否有风险取决于在体系结构的质量属性需求的上下文中。有风险决策和无风险决策。ATAM中有风险决策的定义是，根据所陈述的质量属性需求，可能导致不期望的体系结构决策。无风险决策的定义与此类似，根据分析被认为是安全的体系结构决策。所确定的风险可以形成体系结构风险移植计划的基础。风险主题的集合。分析完成时，评估小组将分析所发现风险的集合，以寻找确定体系结构甚至体系结构过程和小组中的系统弱点。如果不采取相应的措施，这些风险主题将影响项目的业务目标。清华大学出版社2612.3.3ATAM的一般过程整个ATAM评估过程包括9个步骤，4个部分。ATAM方法的表述商业动机的表述架构的表述确定架构方法生成质量属性效用树分析架构方法集体讨论，确定场景优先级分析架构方法结果的表述。清华大学出版社2712.3.4ATAM评估阶段（1）第1阶段。为合作关系和准备阶段，评估小组负责人和主要项目决策者进行非正式会议，以确定此次评估的细节，项目代表向评估人简要概述项目，以使评估小组具备适当的专业技术人员的协助。另外对于会议的地点、时间以及后勤保障需要实现达成一致，对于需要什么样的架构文档也需要达成一致。（2）第2和第3阶段。为评估阶段，第2阶段，评估小组和项目决策者会晤（通常1天时间），以开始信息收集和分析工作。第3阶段，架构涉众加入到评估中，分析继续进行（一般用2天时间）。（3）第4阶段。小组需要生成一个最终的书面报告。在总结会议中，需要讨论哪些活动比较理想，还有什么需要自我检查和改进的问题，以使评估工作一次比一次更好。清华大学出版社2812.4评估方法比较12.4.1场景的生成方式不同SAAM方法采用头脑风暴（brainstorming）技术构建场景，要求风险承担者列举出若干场景，并将场景分为直接场景和间接场景两类，分别支持对体系的静态分析和动态分析。ATAM在具体评估中将场景分为三类：（a）用例场景（usecasescenario）。描述用户的期望与正在运行的系统交互，用于信息的获取。（b）生长场景（growthscenario）。预期的系统变更与质量属性关系。（c）探索场景（exploratoryscenario）。清华大学出版社2912.4.2风险承担者商业动机表述方式不同SAAM只是将不同组织的需求目标简单地联系在一起，评估中由开发人员、维护人员、用户和管理人员等风险承担者将其所关心的目标问题以场景形式提出这样不同领域的风险承担者根据自己领域特点及对软件的需要确定若干场景，评估小组根据他们确定的场景来评估软件系统特定方面的性能。清华大学出版社3012.4.2风险承担者商业动机表述方式不同ATAM建立在SAAM的基础上，借助于效用树（qualityattributeutilitytree）将风险承担者的商业目标转换成质量属性需求，再转换成代表自己商业目标的场景。清华大学出版社3112.4.3软件体系结构的描述方式不同ATAM方法中软件体系结构的描述采用PhilippeKruchten“4+1”视图模型，即从五个不同的视角点描述系统的体系结构，四个视图模型从特定的不同方面描述软件的体系结构，忽略与此无关的实体。清华大学出版社3212.4.3软件体系结构的描述方式不同SAAM则提倡使用非常单纯的体系结构要素。对体系结构的静态描述一般都要区别数据的连接（数据在组件之间的传递）和控制连接（一个组件调用另一个组件执行某个功能）对软件体系结构的动态描述主要描述系统在各个不同时间的行为，给出软件的体系结构。清华大学出版社3312.5小结软件体系结构的评估是一项实践性非常强的工作，因此应该与实践紧密联系起来。SAAM、ATAM都已经应用到若干个实际的系统中，并且在实践的过程中不断地得到改进。在很大程度上评估的质量与风险承担者的积极参与分不开，评估的过程同时也是风险承担者对于最终软件系统的认识交流与提高的过程。