软件体系结构——7.4

1、7.4、评估方法比较 我们知道软件工程领域已经提出了一 些方法来揭示体系结构的潜在质量属 性、风险和缺陷。如SAAM、ATAM、 SABR等。 (1)为了搞清楚各种方法的特点。 (2)为了能判别在什么上下文环境使 用哪种方法。 (3)各种方法的关注点是什么。 我们需要提供一些准则。 7.4.1、比较框架 (1)在进行比较之前，我们需要构造一个 框架来规范化处理各种评估方法的特性， 否则就无法给出公正的评价。 (2)也就是我们必须首先找到共同的特征 和活动，然后建立比较的度量机制。 评估由涉众参与，基本上以会议的形式， 根据具体使用的方法参与者可以是全体或 部分涉众。 一般情况下，基于场景的评估

2、方法经历以 下4个阶段： 1、评估准备 2、场景生成 3、利用场景评估软件体系结构 4、解释结果并得到结论 评估准备 场景生成 利用场景评估 软件体系结构 解释结果并得 到结论 1、评估准备 (1)涉众需要一个统一的基础进行交流，这 样有助于在开始任何活动之前涉众很好的 熟悉待建系统和解决问题之间的关系，也 有助于涉众互相之间的理解。 (2)因为并不是每个参与后续过程的人都对 系统有基本的了解，也并不是每个人都清 楚评估时到底该做什么、什么样的想法和 建议会对评估结果有益。因此准备阶段是 必须的。 在这个阶段应该公开声明3类信息： (1)评估负责人应该准确的解释使用的评估 方法及其活动，力图设

3、定期望并回答可能 的问题。负责人引导大家避免，至少也要 减少不相干、无价值的讨论或其他异常情 况。 (2)需要介绍系统目标，通常这项工作由项 目经理或者客户代表来做。毕竟，参与者 需要知道主要是什么目标引导着系统的开 发、那些质量属性需要特别关注。 (3)架构师需要描述已有的体系结构，解释 满足系统目标的关键设计决定；这样要求 其实迫使使架构师尽量给出合格的体系结 构描述或文档，同时潜移默化地改进了设 计。 这一阶段结束时，每个人都因该清楚系统 的概要结构和驱动结构的目标。如果不是 这样，必然是准备材料中存在错误。 3、场景生成 本阶段的目的时生成尽可能多的有价值场 景为下一阶段准备。 (1)

4、提供一组场景相对容易。典型的策略是 鼓励涉及群众围坐在桌旁进行头脑风暴， 说出任何想说的建议。 (2)但是问题是什么时候结束场景生成， 还有怎样选择对矫正改进当前体系结构最 有益的场景。 （3）但是问题是什么时候结束场景生成， 还有怎样选择对矫正改进当前体系结构最 有益的场景。 有些方法以新场景总可以背旧市场景表示 或者新场景不再影响体系结构作为结束场 景生成标志。另一些方法采用启发模式的 策略来引导人们产生有效的场景。 一般来说，考虑到评估过程的时间消耗和 复杂度，如一个持续2-3天的评估会议仅 能对不超过20个场景进行评估。所以这就 意味着评估需要优先级机制。 输入 场景描述 软件体系 结

5、构描述 利用独立场景评估 体系结构 整体评估 输出 待解释的评估结果 3、利用场景评估软件体系 (1)这是基于场景型评估方法的核心阶段， 在涉众对系统构架的期望或怀疑与系统结 构和交互行为之间建立了桥梁。 (2)在这里对前一阶段的场景都必须澄清几 个问题： “此场景能直接被当前体系结构支持吗？” “如果体系结构必须更改才能满足新需求， 那么场景导致更改带来的开销又是多少？” “场景的影响是什么，又怎么测量它？” (3)架构师应该根据其经验和洞察力的估计 来阐明场景必将引发的变化，并就软件体 系结构相关的目标和风险提供建议。 (4)但一些情况值得重点关注，如“几个语 义不同的场景影响了同一构件”

6、，“多个 场景在本质上是截然对立”。而架构师则 通过寻找敏感点和权衡点来对体系结构调 整以满足各个互相冲突的目标。 总之，这个阶段输入是由场景生成阶段过滤 后的场景和软件体系结构描述。 输出是需要进一步解释的粗略的评选结果。 4、解释结果并得到结论 (1)我们知道第三阶段是把收集的信息整 理成表格或类似的形式，但这并不意味着 评估的结束。 (2)因为我们得到的信息还不是很清晰， 我们也无法得到其应有的益处。评估的结 果是给出最终文档，以便指导下一步的设 计改动和实现。 最终文档的要求是我们可以从中挖掘出3 类信息： (1)根据整体评估中的相对分数，可以选 出哪个候选体系结构最适合作为指导开发

7、的基本模型。每个体系结构都有自己的优 势和不足，评估可以清楚的反映每个候选 体系结构的特点。 (2) 通过对评估时编档过的提示进行整合 和组织，可以制定修改计划。最初的体系 结构是根据需求规格说明的要求设计的， 而在评估时由于引入的一些问题，可能就 不在适合了。 (3)可以积累评估的实际经验和技巧，帮 助调整改进，这样下次评估时就可以有更 好的效果。 7.4.27.4.2评估方法概览和比较评估方法概览和比较 1.SAAM:1.SAAM:基于场景的体系结构分析方法基于场景的体系结构分析方法 2.SAAMCS:2.SAAMCS:复杂场景的复杂场景的SAAM SAAM 3.ESAAMI:3.ESAA

8、MI:领域继承的领域继承的SAAMSAAM扩展扩展 4.SAAMER:4.SAAMER:用于演化和可复用性的用于演化和可复用性的SAAMSAAM 5.ATAM5.ATAM：体系结构权衡分析方法：体系结构权衡分析方法 6.SBAR6.SBAR：基于场景的体系结构再工程：基于场景的体系结构再工程 SAAMCS:SAAMCS:复杂场景的复杂场景的SAAMSAAM SAAMCS认为场景的复杂度是风险评估中最 重要的因素。SAAMCS对SAAM的扩展主要有两方 面:一方面是寻找场景的方式, 另一方面是评 估它们的影响。 特定目标：特定目标： SAAMCS的唯一目标是对系统可修改性进行风险评估 质量属性：

9、质量属性： 它分析的质量属性为系统的灵活性 涉及的涉众：涉及的涉众： SAAMCS把场景发起人定位为关键角色，所谓场景的发 起者，是指这样的组织单元，它最为关心该场景的实 现。 SAAMCS:SAAMCS:复杂场景的复杂场景的SAAMSAAM 体系结构的描述：体系结构的描述： SAAMCS被应用于有充分的细节描述的体系结构的最终 版本。根据系统与其外部环境的关系，系统的体系结 构描述可分为微观体系结构和宏观体系结构两类。 方法与活动：方法与活动： 复杂场景分类 微观/宏观体 系结构描述 测量手段 SAAMCS 体系结构描述 评估场景效果 场景生成 与 单个体系结构分析 SAAMCS:SAAMC

10、S:复杂场景的复杂场景的SAAMSAAM 复杂场景的定位复杂场景的定位二维框架图二维框架图 4类变更源：功能需求、质量需求、外部组件、技术环境 5类复杂场景：对有外部影响的系统的调整、对那些影响系统 系统的环境的调整、对宏观体系结构的调整、对微观体系结构 的调整、对引入版本冲突的调整 SAAMCSSAAMCS定义了复杂度的度量工具定义了复杂度的度量工具 变更源 场 景 复 杂 度 场景效果没有效果、影响一个构件、影响多个构件、影响体系结构 拥有者数量参与信息系统中的人中拥有者的数量 版本冲突不存在不同版本、存在不同版本，但冲突允许、导致配置管 理的复杂化、出现冲突 ESAAMI:ESAAMI:

11、领域继承的领域继承的SAAMSAAM扩展扩展 SAAM并没有专门考虑到评估复用的问题，因此不 能直接支持评估所用制品、场景、测量等的再次使用 。ESAAMI构造了一个为同一领域复用的评估框架，并 且建立了体系结构分析模板和重用知识库 特定目标：特定目标： ESAAMI是分析和重用概念的组合，它把SAAM集成在面 向特定领域、以重用为基础的开发过程中。由于集中 在一个领域内重用的程度得到改善。 质量属性：质量属性： ESAAMI涉及的质量属性和SAAM类似 注意注意：ESAAMI本身是可复用的，但不保证体系结构的 可复用性，体系结构的可复用性是本方法的输入或者 前提 ESAAMI:ESAAMI:

12、领域继承的领域继承的SAAMSAAM扩展扩展 可复用的评估方法和可复用的体系结构可复用的评估方法和可复用的体系结构 可复用的评估过程可以作为可复用的体系结构的附属物 第一，一个可复用的评估方法能在同一个领域内复用 第二，一个可复用的体系结构为衍生于此领域的各类应用提供了 一个共同的基础 第三，为了分析并保证体系结构的可复用，需要检查支持可复用 的因素是否存在 体系结构的抽象层次是否表征了领域的本质 体系结构的可修改处是否便于特定目标的定制 体系结构是否被充分清晰的编档 领域 可复用的 评估方法 可复用的 体系结构 包含 需要 ESAAMI:ESAAMI:领域继承的领域继承的SAAMSAAM扩展

13、扩展 体系结构描述：体系结构描述： ESAAMI需要一个可复用的体系结构框架作为输入， 该方法提出了识别可复用体系结构描述的3种特征： 该描述必须提供足够的通用信息； 必须足够灵活； 体系结构的属性必须足够详细的编档 场景生成：场景生成： 场景原型场景原型是可重用环境或系统交互的 通用描述 ，它传达的信息是领域内的共同使用情况 或变更情况，实际上，“场景原型”就是一个场景 模板。 ESAAMI:ESAAMI:领域继承的领域继承的SAAMSAAM扩展扩展 场景生成过程场景生成过程 场景原型 场景原型 选择和精化 场景抽取 场景候选场景选择 场景分类 输出评估 的场景 分类提示 ESAAMI:ES

14、AAMI:领域继承的领域继承的SAAMSAAM扩展扩展 评估过程：评估过程： SAAMERSAAMER：用于演化和可复用性的：用于演化和可复用性的SAAMSAAM 特定目标：特定目标： SAAMER关注系统演化和可复用性一个系统应 该怎样支持每一个质量目标，或者演化的风险级 别，或者怎样重用。此方法试图捕获特殊类场景 的潜在问题，评估这些场景的解决方案。 质量属性：质量属性： SAAMER主要关注演化和可复用性。演化集中了领 域专家提出的新的质量目标（可维护性、可修改 性）。 涉及的涉众：涉及的涉众： SAAMER中领域专家在场景开发和评估过程中扮演 重要角色。 SAAMERSAAMER：用于

15、演化和可复用性的：用于演化和可复用性的SAAMSAAM 体系结构描述：体系结构描述： 使用此方法需要4类体系结构视图： 静态视图提供系统元素的拓扑信息 映射视图将组件与其相应功能和特性联系起来 动态视图反映系统的行为方面 资源视图资源的使用 每种视图都由某些具体的制品作为载体 最后，SAAMER生成3个表格作为待解释总结的原始结 果，这3个表格分别是基于目标的分析结果、场景关 联总结和基于质量的总结 SAAMERSAAMER：用于演化和可复用性的：用于演化和可复用性的SAAMSAAM 场景开发：场景开发： SAAMER的一个突出特性就是它停止场景开发机制 一、目标+领域专家的经验 对场景分类

16、二、利用QFD（质量功能分布）实现不同目标 场景的平衡 不平衡因子=质量属性的场景覆盖率/质量属性 的优先级 SAAMERSAAMER：用于演化和可复用性的：用于演化和可复用性的SAAMSAAM SAAMERSAAMER评估框架：评估框架： SAAMERSAAMER：用于演化和可复用性的：用于演化和可复用性的SAAMSAAM 评估技术：评估技术： SAAMSAAMER 每个场景导致变更都要记录利用粗略估计和相关领域专 家经验扩展变更信息 无 场景关联分析 识别体系结构风格和设计中 不合理的部分 允许整体的一致性校验 SBAR:SBAR:基于场景的体系结构再工程基于场景的体系结构再工程 特殊目标

17、：特殊目标： SBAR的目标是从质量属性的角度驱动体系结构再设 计。用于评估所设计的软件体系结构是否具有达到 所需求的软件质量的潜力 质量属性：质量属性： SBAR涉及多个质量属性,实际上和ATAM很类似，并没 有为每个属性创造新的方法。 涉及的涉众：涉及的涉众： 此方法关注体系结构再工程，这决定了体系结构结 构的评估者就是软件体系结构的设计者 SBAR是一个评估详细体系结构的框架，引入了 质量评价和体系结构转换的迭代过程。 SBAR:SBAR:基于场景的体系结构再工程基于场景的体系结构再工程 体系结构描述：体系结构描述： SBAR方法使用软件体系结构的详细设计。 SBAR需要根据功能性需求创

18、建的初始体系结构描 述。因为此方法为帮助系统再工程而设计，应该 把细化后的体系结构反馈到随后的评估过程。 场景生成：场景生成： 1.完整的方式：定义一组场景并把它们组合起来 ，使其覆盖软件质量的具体实例。 2.统计的方式：SBAR需要一套有代表性场景使得 需要考虑的每个质量属性都具体化。 SBAR:SBAR:基于场景的体系结构再工程基于场景的体系结构再工程 SBARSBAR评估过程评估过程 场景、仿真、模 拟、数学建模和 经验推理 1.利用体系结构风格 2.利用体系结构模式 3.设计模式应用 4.把质量需求转化成功 能需求和需求合理化分 布 评估方法的比较评估方法的比较 SAAMSAAMCSE

19、SAAMISAAMERATAMSBAR 目标风险定义、 适用性分 析 预测相对 的适用性、 风险评估 分析适用 性和复用 性 评估体系 结构的复 用和演进 敏感点和 权衡点分 析 按照需求 的质量属 性评估体 系结构 质量属性可修改性适用性/ 可维护性 适用性、 复用性 复用性、 演进 多种属性多种属性 适用设计 阶段 功能分配体系结构 实现前 和SAAM一 样 实现体系 结构 体系结构 详细设计 后 系统执行 或再工程 阶段 活动数量636473 评估技术基于场景 的功能性 和变化分 析 复杂场景基于场景基于场景、 信息模型 问卷、度 量 多种方法 风险承担 者 所有参与者所有设计者、 管理

20、者、 用户 所有体系结构 设计者 验证多个领域商业信息 系统 无公开验 证记录 转换系统多个领域测量系统 ALPSM:ALPSM:软件可维护性体系结构的预测软件可维护性体系结构的预测 ALPSMALPSM方法通过在软件体系级别上考察场景的影响，方法通过在软件体系级别上考察场景的影响， 来评估一个软件系统的可维护性。来评估一个软件系统的可维护性。 采用场景来具体化可维护性需求，并且用来分析体采用场景来具体化可维护性需求，并且用来分析体 系结构，对系统所需的维护性工作做出预测。预测系结构，对系统所需的维护性工作做出预测。预测 结果可以用来比较两个可供选择的体系结构，也可结果可以用来比较两个可供选择

21、的体系结构，也可 以用来平衡可维护性与其他的质量属性。以用来平衡可维护性与其他的质量属性。 ALPSM 步骤：步骤： 1 1. .确定维护任务的分类确定维护任务的分类 2. 2.合成场景合成场景 3. 3.给每一个场景分配一个权值给每一个场景分配一个权值 4. 4.估算所有组件的大小估算所有组件的大小 5. 5.分析场景分析场景 6. 6.计算所预计的维护工作计算所预计的维护工作 ALPSM 特殊目标特殊目标：对一系列变更场景所需的维护工作量进 行估计，变化的幅度作为达到此目标的预测器 质量属性质量属性：根据其得到的所需维护的工作量可以间 接检查可维护性。 软件体系结构描述软件体系结构描述：需

22、要最终版本的体系结构的详 细描述 涉及的涉众涉及的涉众：仅需架构师、设计者领域专家和维护 人员的参与 场景的生成场景的生成：仅需变更场景做后续分析，该场景生 成是架构师或者是领域专家的工作，生成的场景 要均匀分布在典型的维护任务中，要对场景设置 优先级，场景发生的可能性越大，其权值越高。 ALPSM 评估技术： 需求规约 体系结构设计 软件工程领域的专家经验 历史维护数据 ALPSM(软件维 护方法） 对维护工作的 预测 验证验证：在某血红透析系统中有应用 支持工具支持工具：没有明确的支持此方法的工具 SAEM 软件体系结构评估模型 SAEM是一个基于质量模型标准和质量评估过 程的评估模型。相

23、对于一种具体的评估方 法，SAEM被看做是一种理解软件质量评估 的参考。 特殊目标特殊目标：SAEM构造了软件质量问题和评估 过程的基础。描述了什么是软件质量、分 析的通用策略和系统体系结构要实现什么 类别的质量，要实现到什么程度。 质量属性质量属性：质量属性分为“内在”和“外在” 两类。外在质量反映了使用者角度看到的 特征，内在质量反映了开发者角度看到的 特征，内在有开发者和使用者共同指定而 外在只能有开发者指定 SAEM 体系结构描述体系结构描述：软件；、体系结构也分为内部视图 和外部视图。SAEM推荐在体系结构描述之外还要 补充评估辅助问题或者审查技术。比如带形式化 模型的体系结构描述语

24、言 涉及的涉众涉及的涉众：并未明确规范什么什么人需要参加评 估过程，而是仅提到了系统专家负责评估的体系 结构 场景生成场景生成：并不仅仅关注场景的影响，基于场景的 方法应该只是其评估技术之一，其他使用的技术 还有检查表和调查表 SAEM 评估技术评估技术：是一个通用的模型评估，模型包括使用 者和开发者，他们的定义是从软件的内外特征的 角度出发的，系统专家利用专家知识和企业累计 的数据把质量属性和体系结构元素联系起来 验证验证：未在任何实际应用中验证，但是在某些具体 的评估方法中看到它的思想 支持工具支持工具：没有支持工具 PASA 软件体系结构的特征评估 亡羊补牢的做法对软件的性能性不通，软件

25、 设计必须一开始就要考虑到性能。 执行步骤： 可能的迭代 过程概览体系结构概览关键用例识别 选择关键 属性场景 识别性 能目标 体系结构澄清 和讨论 体系结构分析识别替代结果报告 可能的迭代 PASA 过程概览过程概览：帮助参与者熟悉他们该做什么、什么行 动对评估是合适的和有益的，避免做无意义的事。 体系结构概览体系结构概览：作为后续活动的基础，架构师必须 描述当前的体系结构，解释评估所需的关键结构和 行为概览 关键用例识别关键用例识别：试图找到外部可见的反应系统重要 行为的用例，尤其是与响应能力和系统可伸缩性密 切相关的用例 选择关键性能场景选择关键性能场景：利用上一步生成的关键用例， 识别

26、与重要性能有关的场景 识别性能指标识别性能指标：评估使用的每一个场景都应该是可 以度量的，因此，评估参与者必须定义针对每个关 键场景的性能指标 体系结构澄清与讨论体系结构澄清与讨论：更加深入的审查影响上述场 景实现的体系结构元素，参与者对体系结构深入讨 论返现问题 PASA 体系结构分析体系结构分析：针对每一个关键性能场景， 分析体系结构以搞清楚是否当前设计能否 支持对应的性能指标 识别替代识别替代：用能满足目标的结构替换存在问 题的部分结构 结果报告结果报告：报告是最终的评述定论，包括发 现的问题、体系结构修改计划、估计的修 改工作量和费用 PASA 特殊目标特殊目标：试图评估候选体系结构的

27、性能， 解决性能和其他质量属性之间的权衡问题 质量属性质量属性：性能是此方法目标质量属性的中 心，也考虑到了所有和性能关联的其他质 量属性 体系结构描述体系结构描述：需要非常详细的体系结构的 描述，需要第2-4步迭代保证体系结构信 息逐渐澄清 涉及的涉众涉及的涉众：架构师、项目经理、开发人员 和性能专家 PASA 场景的生成场景的生成：关键性能场景的识别来自从需 求文档和其他材料中收集的关键用例。要 保留的场景有两类：一类是频繁执行并反 映用户对性能的感觉，另一类是虽执行不 频繁但若性能低下会对系统影响严重。所 有场景都要附上一个或几个性能指标，记 录在增强的UML序列中 评估技术评估技术：在

28、体系结构方面，PASA吸收了基 于体系结构模式的技术，此方法能够识别 出对定型模模式或风格偏离并评估其对性 能的影响 PASA 验证验证：PASA在几个项目中有应用，包括基于 web的系统，实施系统和金融系统 支持工具支持工具：没有支持工具 ARID:Active Reviews for Intermediate Designs 中间设计的主动复查方法 对早期的设计或整个系统的某个部分进行复查， 这需要在没有体系结构完整信息的情况下复 查某些设计策略或者决定 “主动设计复查”以复查的风格为特色，给复 查者分配了精心设计的复查任务从而试图改 进效果。 召集各类涉众实行评估，中间设计也并不需要 复杂的评估技术。 ARID:Active Reviews for Intermediate Designs 中间设计的主动复查方法 阶段步骤 第一阶段：会议 前 第一步：识别复查人 第二步：准备复查报告 第三步：准备种子场景 第四步：准备复查会议 第二阶段：复查 会议 第五步：介绍ARID方法 第六步：介绍会议 第七步：头脑风暴和场景设置优 先级 第八步：进行复查 第九步：报告结论 ARID:Active Reviews for Intermediate Designs 中间设计的主动复查方法