软件体系结构第12章

1、清华大学出版社1清华大学出版社2内容提要内容提要p12.1软件体系结构评估定义软件体系结构评估定义p12.2SAAM软件架构分析方法软件架构分析方法p12.3ATAM体系结构权衡分析方法体系结构权衡分析方法p12.4评估方法比较评估方法比较p12.5小结小结清华大学出版社312.1软件体系结构评估定义软件体系结构评估定义p12.1.1 质量属性质量属性l功能性l可靠性l可用性l有效性l可维护性l可移植性 清华大学出版社412.1软件体系结构评估定义软件体系结构评估定义p12.1.2 评估的必要性评估的必要性p软件架构是软件工程早期设计阶段的产物，软件架构是软件工程早期设计阶段的产物，它对软件系

2、统或软件项目的开发具有深远它对软件系统或软件项目的开发具有深远的影响。主要表现在以下两个方面的影响。主要表现在以下两个方面l不恰当的架构l架构决定着项目的结构。 清华大学出版社512.1软件体系结构评估定义软件体系结构评估定义p12.1.3 基于场景的评估方法基于场景的评估方法l基于场景的软件架构分析方法的基本观点是，大多数软件质量属性极为复杂，根本无法用一个简单的尺度来衡量。同时，质量属性并不是处于隔离状态，只有在一定的上下文环境中才能做出关于质量属性的有意义的评判。l利用场景技术则可以具体化评估的目标，代替对质量属性（可维护性、可修改性、健壮性、灵活性等）的空洞表述，使对软件体系结构的测试

3、成为可能。 清华大学出版社6基于场景的软件架构分析方法步骤基于场景的软件架构分析方法步骤 p1、分析问题域，建立功能场景库。、分析问题域，建立功能场景库。l针对具体项目在应用领域中的定位，展开需求分析，汇总系统预期功能并按对功能进行分类以确保每项功能都能够得到详细描述，并为每个功能定义相应的场景，建立功能场景库。清华大学出版社7基于场景的软件架构分析方法步骤基于场景的软件架构分析方法步骤 p2、通过功能场景库测试评价软件架构对、通过功能场景库测试评价软件架构对各功能的支持度，并针对支持度差的功能各功能的支持度，并针对支持度差的功能展开架构分析。展开架构分析。l支持度的评价涉及到架构是否满足功能

4、场景、是否容易扩展该功能等。一旦发现支持度差的功能，则进一步分析是否是由架构设计导致的，从中发现可能的架构设计缺陷和不足。清华大学出版社8基于场景的软件架构分析方法步骤基于场景的软件架构分析方法步骤 p3、建立非功能指标参数树。、建立非功能指标参数树。l选择一组感兴趣的非功能性指标，如可移植性、安全性、性能等，并详细定义每一个指标的衡量属性、期望值和相应的场景。清华大学出版社9基于场景的软件架构分析方法步骤基于场景的软件架构分析方法步骤 p4、应用指标参数树对软件架构进行非功、应用指标参数树对软件架构进行非功能性分析。能性分析。l通过比较架构在场景中的实际输出值和期望值，来评价架构对各个指标的

5、各个属性的支持度，并在该过程中发现软件架构的缺陷，找出风险决策、无风险决策、敏感点、权衡点。 清华大学出版社10基于场景的评估方法的特征：基于场景的评估方法的特征：p场景是这类评估方法中不可缺少的输入信场景是这类评估方法中不可缺少的输入信息，场景的设计和选择是评估成功与否的息，场景的设计和选择是评估成功与否的关键因素。关键因素。p这类评估是人工智力密集型劳动，评估质这类评估是人工智力密集型劳动，评估质量在很大程度上取决于人的经验和技术。量在很大程度上取决于人的经验和技术。l基于场景的评估方法是研究最广泛，应用最成熟，数量最多的一类软件体系结构评估方法。 清华大学出版社11基于场景的评估方法的不

6、足基于场景的评估方法的不足 p（1）评估的效果对评估师经验的依赖程）评估的效果对评估师经验的依赖程度较高。度较高。p（2）“重量级重量级”的评估技术，成本较高。的评估技术，成本较高。p（3）没有考虑知识的积累和应用问题，）没有考虑知识的积累和应用问题，造成资源的浪费。造成资源的浪费。 p（4）缺乏实用的评估信息管理工具。）缺乏实用的评估信息管理工具。 清华大学出版社1212.2SAAM软件架构分析方法软件架构分析方法pSAAM方法，是卡耐方法，是卡耐基梅隆大学软件工程基梅隆大学软件工程研究所的研究所的Kazman等等人于人于1983年提出的年提出的一种非功能质量属性一种非功能质量属性的体系结构

7、分析方法，的体系结构分析方法，是最早形成文档并被是最早形成文档并被广泛使用的软件体系广泛使用的软件体系结构分析方法。结构分析方法。 清华大学出版社1312.2SAAM软件架构分析方法软件架构分析方法p特定目标特定目标: lSAAM的目标是对描述应用程序属性的文档， 验证基本的体系结构假设和原则。此外， 该分析方法有利于评估体系结构固有的风险。SAAM指导对体系结构的检查，使其主要关注潜在的问题点， 如需求冲突， 或仅从某一参与者的观点出发的不全面的系统设计。SAAM不仅能够评估体系结构对于特定系统需求的使用能力， 也能被用来比较不同的体系结构。p评估技术评估技术: lSAAM所使用的评估技术是

8、场景技术。场景代表了描述体系结构属性的基础， 描述了各种系统必须支持的活动和将要发生的变化。p质量属性质量属性:l这一方法的基本特点是把任何形式的质量属性都具体化为场景， 但可修改性是SAAM分析的主要质量属性。清华大学出版社1412.2SAAM软件架构分析方法软件架构分析方法p风险承担者风险承担者: lSAAM协调不同参与者所感兴趣的方面，作为后续决策的基础， 提供了对体系结构的公共理解。p体系结构描述体系结构描述:l SAAM用于体系结构的最后版本， 但早于详细设计。体系结构的描述形式应当被所有参与者理解。功能、结构和分配被定义为描述体系结构的三个主要方面。p方法活动方法活动: lSAAM

9、的主要输入问题是问题描述、需求声明和体系结构描述。清华大学出版社1512.2.1 SAAM的一般步骤的一般步骤p（1）场景形成。）场景形成。p（2）描述软件体系结构）描述软件体系结构p（3）场景的分类和优先级划分）场景的分类和优先级划分p（4）间接场景的单独评估）间接场景的单独评估p（5）评估场景交互）评估场景交互p（6）形成总体评估）形成总体评估清华大学出版社1612.2.2 场景形成场景形成p在形成场景的过程中，要注意全面捕捉系在形成场景的过程中，要注意全面捕捉系统的主要用途、系统用户类型、系统将来统的主要用途、系统用户类型、系统将来可能的变更、系统在当前及可预见的未来可能的变更、系统在当

10、前及可预见的未来必须满足的质量属性等信息。必须满足的质量属性等信息。 p形成场景的过程也是集中讨论的过程。形成场景的过程也是集中讨论的过程。 清华大学出版社1712.2.3 描述软件体系结构描述软件体系结构p软件体系结构设计师应该采用参加评估的软件体系结构设计师应该采用参加评估的所有人员都能充分理解的形式，对待评估所有人员都能充分理解的形式，对待评估的体系结构进行适当的描述。的体系结构进行适当的描述。 清华大学出版社1812.2.4场景的分类和优先级确定场景的分类和优先级确定p评估人员通过对场景设置优先级，可保证评估人员通过对场景设置优先级，可保证在评估的有限时间内考虑最重要的场景。在评估的有

11、限时间内考虑最重要的场景。 l直接场景 l间接场景清华大学出版社1912.2.5 间接场景的单独评估间接场景的单独评估p对于直接场景而言，体系结构设计师需要对于直接场景而言，体系结构设计师需要讲清楚所评估的体系结构如何执行这些场讲清楚所评估的体系结构如何执行这些场景景p对于间接场景而言，体系结构设计师应说对于间接场景而言，体系结构设计师应说明需要对体系结构做哪些修改才能适应间明需要对体系结构做哪些修改才能适应间接场景的要求。接场景的要求。 清华大学出版社2012.2.6 评估场景交互评估场景交互p当两个或多个间接场景要求更改体系结构当两个或多个间接场景要求更改体系结构的同一个构件时，我们就称这

12、些场景在这的同一个构件时，我们就称这些场景在这一组构件上相互作用。一组构件上相互作用。清华大学出版社2112.2.7 形成总体评估形成总体评估p形成总体评估，是形成总体评估，是SAAM评估方法的最后评估方法的最后一个步骤。一个步骤。p评估人员要对场景和场景之间的交互作一评估人员要对场景和场景之间的交互作一个总体的权衡和评价。个总体的权衡和评价。p这一评价反映该组织对表现在不同场景中这一评价反映该组织对表现在不同场景中的目标的考虑优先级。的目标的考虑优先级。 清华大学出版社2212.3ATAM体系结构权衡分析方法体系结构权衡分析方法pATAM分析方法，是评估软件架构的一种分析方法，是评估软件架构

13、的一种综合全面的方法。综合全面的方法。l这种方法不仅可以揭示出软件体系结构满足特定质量目标的情况，而且可以使我们更加清楚的认识到质量目标之间的联系。清华大学出版社2312.3.1 ATAM参与人员参与人员p3个小组参与合作。个小组参与合作。l评估小组l项目决策者l涉众清华大学出版社2412.3.2 ATAM结果结果p一个简洁的体系结构描述。一个简洁的体系结构描述。l我们通常认为体系结构文档是由对象模型、接口及其签名的列表或其他冗长的列表组成的。但ATAM的一个要求就是在一个小时内表述体系结构，这样就得到了一个简洁而且通常是可理解的体系结构表述。p表述清楚的业务目标。表述清楚的业务目标。l开发小

14、组的某些成员通常是在ATAM评估上第一次看到表述清楚的业务目标。p用场景集合捕获的质量需求。用场景集合捕获的质量需求。l业务目标导致质量需求。一些重要的质量需求是用场景的形式捕获的。p体系结构决策到质量需求的映射。体系结构决策到质量需求的映射。l可以根据体系结构决策所支持或阻碍的质量属性来解释体系结构决策。对于在ATAM期间分析的每个质量场景，确定那些有助于实现该质量场景的体系结构决策。清华大学出版社2512.3.2 ATAM结果结果p所确定的敏感点和权衡点集合。所确定的敏感点和权衡点集合。l这些是对一个或多个质量属性具有显著影响的体系结构决策。例如，采用一个备份数据库很明显是一个体系结构决策

15、，它影响了可靠性。因此，它是一个关于可靠性的敏感点。然而，保持备份将消耗系统资源，影响系统性能。因此它是可靠性和性能之间的权衡点。该决策是否有风险取决于在体系结构的质量属性需求的上下文中。p有风险决策和无风险决策。有风险决策和无风险决策。lATAM中有风险决策的定义是，根据所陈述的质量属性需求，可能导致不期望的体系结构决策。无风险决策的定义与此类似，根据分析被认为是安全的体系结构决策。所确定的风险可以形成体系结构风险移植计划的基础。p风险主题的集合。风险主题的集合。l分析完成时，评估小组将分析所发现风险的集合，以寻找确定体系结构甚至体系结构过程和小组中的系统弱点。如果不采取相应的措施，这些风险

16、主题将影响项目的业务目标。 清华大学出版社2612.3.3 ATAM的一般过程的一般过程p整个整个ATAM评估过程包括评估过程包括9个步骤，个步骤，4个部分。个部分。lATAM方法的表述l商业动机的表述l架构的表述l确定架构方法l生成质量属性效用树l分析架构方法l集体讨论，确定场景优先级l分析架构方法l结果的表述。 清华大学出版社2712.3.4 ATAM评估阶段评估阶段p（1）第）第1阶段。阶段。l为合作关系和准备阶段，评估小组负责人和主要项目决策者进行非正式会议，以确定此次评估的细节，项目代表向评估人简要概述项目，以使评估小组具备适当的专业技术人员的协助。另外对于会议的地点、时间以及后勤保

17、障需要实现达成一致，对于需要什么样的架构文档也需要达成一致。p（2）第）第2和第和第3阶段。阶段。l为评估阶段，第2阶段，评估小组和项目决策者会晤（通常1天时间），以开始信息收集和分析工作。第3阶段，架构涉众加入到评估中，分析继续进行（一般用2天时间）。p（3）第）第4阶段。阶段。l小组需要生成一个最终的书面报告。在总结会议中，需要讨论哪些活动比较理想，还有什么需要自我检查和改进的问题，以使评估工作一次比一次更好。 清华大学出版社2812.4评估方法比较评估方法比较p12.4.1场景的生成方式不同场景的生成方式不同lSAAM方法采用头脑风暴（brainstorming）技术构建场景，要求风险承

18、担者列举出若干场景，并将场景分为直接场景和间接场景两类，分别支持对体系的静态分析和动态分析。lATAM在具体评估中将场景分为三类：（a）用例场景（use case scenario）。描述用户的期望与正在运行的系统交互，用于信息的获取。（b）生长场景（growth scenario）。预期的系统变更与质量属性关系。（c）探索场景（exploratory scenario）。 清华大学出版社2912.4.2风险承担者商业动机表述风险承担者商业动机表述方式不同方式不同lSAAM只是将不同组织的需求目标简单地联系在一起，评估中由开发人员、维护人员、用户和管理人员等风险承担者将其所关心的目标问题以场景

19、形式提出l这样不同领域的风险承担者根据自己领域特点及对软件的需要确定若干场景，评估小组根据他们确定的场景来评估软件系统特定方面的性能。 清华大学出版社3012.4.2风险承担者商业动机表述风险承担者商业动机表述方式不同方式不同lATAM建立在SAAM的基础上，借助于效用树（quality attribute utility tree）将风险承担者的商业目标转换成质量属性需求，再转换成代表自己商业目标的场景。 清华大学出版社3112.4.3软件体系结构的描述方式软件体系结构的描述方式不同不同pATAM方法中软件体系结构的描述采用方法中软件体系结构的描述采用Philippe Kruchten“4+1”视图模型，视图模型，即从五个不同的视角点描述系统的体系结即从五个不同的视角点描述系统的体系结构，四个视图模型从特定的不同方面描述构，四个视图模型从特定的不同方面描述软件的体系结构，忽略与此无关的实体。软件的体系结构，忽略与此无关的实体。 清华大学出版社3212.4.3软件体系结构的描述方式软件体系结构的描述方式不同不同pSAA