软件体系结构分析和评估综述
软件体系结构评估
ATAM评估方法
ATAM：Architecture Tradeoff Analysis Method（体系结构 权衡分析方法） 特点
评估SA对特定质量目标的满足情况，揭示诸多质量目标之间 的相互作用和权衡 结构化的评估方法，可重复
方法来源
体系结构风格 质量属性分析方法
ATAM步骤简述(1/2)
21
ATAM步骤详述(5/13)
第5步：生成质量属性效用树 评估小组与项目决策者合作，共同确定出该系统的最重要的 质量属性目标，并设臵优先级，进行进一步的细化，该步指 导其他的分析 这种方式将所有风险承担者和评估小组的精力集中到对系统 的成功与否具有重要意义的体系结构的方面上 效用树为我们提供了一种直接而有效地将系统的商业驱动因 素转换为具体的质量属性场景的机制，该步骤的输出结果是 对具体质量属性需求（以场景形式实现）的优先级的确定
基于场景的评估方式(1)
基于场景的方式由SEI首先提出并应用在体系结构权 衡分析方法（ATAM）和软件体系结构分析方法 （SAAM）中。 这种软件体系结构评估方式分析软件体系结构对 场景也就是对系统的使用或修改活动的支持程度， 从而判断该体系结构对这一场景所代表的质量需求 的满足程度。例如，用一系列对软件的修改来反映 易修改性方面的需求，用一系攻击性操作来代表安 全性方面的需求等。
19
ATAM步骤详述(3/13)
第3步：体系结构陈述 在适合的细节层次上描述体系结构，体系结构信息直接影响 可能的分析及分析的质量。在进行更实质的分析之前，评估 小组通常需要询问更多的有关体系结构的信息
技术约束条件，诸如要求使用的操作系统、硬件、中间件等 该系统必须要与之交互的其他系统 用以满足质量属性需求的体系结构方法、样式、模式和采用 的机制 高层体系结构视图：功能、代码、并发、物理
软件体系结构的分析与评价
软件体系结构的分析与评价软件体系结构是一种高层抽象视角，用于描述系统的基本组成部分以及它们的相互作用。
它具有指导开发中正确把握系统需求、提高软件质量以及加速项目开发进程等许多优点。
然而，在这一领域，有很多方法来实现软件体系结构，因此，需要对这些方法进行分析和评价。
首先，可以从技术方法的角度来分析。
对于软件体系结构，一些重要的技术方法包括面向对象设计、面向服务架构、分层架构等等。
这些方法的选择应基于项目需求和开发者技能水平。
如果项目要求代码能够适应未来的变化，那么采用面向对象设计可能是最佳选择。
如果项目要求具备可重用性和松耦合的上下文，那么使用面向服务架构则可能更为合适。
分层架构则是其中一个通用的架构模式，可以轻松将系统划分成松散耦合的模块。
这些技术方法的选择应当基于具体的需求和项目特点。
其次，可以从软件质量的角度来评价。
软件质量通常包括功能性、可靠性、易用性、可维护性等方面。
软件体系结构在质量方面的影响主要与系统的系统属性有关，如可靠性、可扩展性和可维护性。
例如，如果系统使用分层架构，则将模块分到不同的层次中，可大大提高系统可维护性。
在这种架构中，即使要更改系统的一个模块也不可能将其他部分影响到，从而降低了系统的错误率，并增加了系统的可维护性。
软件体系结构的必要性在于通过对系统属性的优化来提高软件的质量。
此外，还应考虑软件开发的时间和资源管理方面，这个方面的考虑包括了如何缩短软件开发的周期、降低开发成本以及评估开发阶段的风险等方面。
软件体系结构可以帮助确保系统需求的完整性，从而降低开发阶段的风险。
此外，软件体系结构的规范化可以使团队成员更好地理解整个开发流程。
最后，可以从技术生命周期的角度来评估软件体系结构。
随着业务需求和技术的新变化，软件架构可能需要进行定期的更改。
随着时间的推移，软件发展的过程会对整体的体系结构产生重大的影响。
软件体系结构应该尽可能地灵活，对于这些变化要有很好的适应性。
此外，软件开发项目通常有不同的阶段，它的生命周期从需求分析经历到开发、测试和维护。
软件体系结构分析与评估综述
不仅可以揭示出构架满足特定质量目标的情况，而且可以
使我们更清楚地认识到质量目标之间的联系——即如何权衡诸多
质量目标。
ATAM方法
ATAM方法基于假设如下：
体系结构风格是体系结构质量属性最主要的限定，因此采
用ABASs(attribute-based architecture styles)来限定体系结构的描述形
5.3 场景不确定性的处理
由于基于场景的分析评价技术具有很多的不确定性， 包括如何根据某质量特征使场景具有代表性、场景的完 备性等，因此如何为场景的构造确定合适的边界条件， 以及如何确定场景构造的停止准则成为解决场景不确定 性的一种极好的手段。
5.4 度量的应用
在对体系结构的分析和评价中，大多采用基于场景
SAAM方法
SAAM方法有着以下缺陷： 没有提供体系结构质量属性的清晰的度量。
评估过程依赖专家经验等，只适合对体系结构的粗糙评价。
3.2 ATAM方法
ATAM方法
在SAAM的基础上，SEI于2000年提出ATAM方法。
ATAM是评价软件架构的一种综合全面的方法，它考虑了可
修改性、可靠性和安全性等多种质量属性。
SAAM方法
SAAM方法在改良事物性质的方面具有极大的功效。 SAAM方法是第1个被广泛接受的体系结构分析评价方法。
它适用于可修改下、可拓展性以及功能覆盖等质量属性。
SAAM方法
SAAM方法的过程
场景是常用的一种技术，由用户、外部激励等初始化，通常包括系统中的事件和触发该事件 的特定激励。SAAM方法采用大脑风暴技术构建场景，体系结构的描述采用自然语言或其他 形式表示。方法将场景归类为直接场景和简介场景，分别支持对体系结构的静态结构分析和 动态分析。
软件体系结构的设计与评估
软件体系结构的设计与评估随着计算机技术的发展，软件系统在我们的生活中扮演着越来越重要的角色。
由于软件系统的规模越来越大，模块越来越多，软件的结构设计和评估就变得尤为重要。
软件体系结构是指软件系统中各个模块之间相互关联的结构，设计和评估软件体系结构是确保软件系统的高性能和高稳定性的关键。
一、软件体系结构设计的重要性软件体系结构设计是软件开发的第一步。
它的目的是根据需求规格说明书确定软件系统的模块组成，进而确定模块之间的相互关系。
一个良好的软件体系结构应具备以下特点：1.可扩展性——软件体系结构应该可以很方便地扩展和修改，使得软件系统能够应对未来的需求变化。
2.可维护性——软件体系结构应该易于维护，使得开发人员能够很快地修复程序错误和漏洞。
3.可重用性——软件体系结构应该可以很容易地被复用，这可以大大提高软件开发的效率。
4.可移植性——软件体系结构应该很容易地在不同的操作系统和硬件平台上运行，以满足不同用户的需求。
设计一个良好的软件体系结构需要考虑多个因素，例如软件系统的规模、性能、可靠性等。
不同的因素需要不同的策略来解决，因此软件体系结构的设计是一个复杂而具有挑战性的任务。
二、软件体系结构设计的方法根据Martin Fowler的《企业应用架构模式》，软件体系结构设计可以分为以下四种方法：1.分层架构——将软件系统分为多个层次，每个层次都与下面的层次交互，从而促进模块化和可重用性。
2.分布式架构——将软件系统分成多个部分，每个部分都可以在不同的机器上运行，这可以大大提高系统的性能和可伸缩性。
3.面向服务架构——将软件系统分成多个服务，每个服务可以在不同的机器上运行，从而实现各个服务之间的相互调用。
4.事件驱动架构——在软件系统中使用事件来组织模块之间的通信。
以上四种架构方法都有各自的优缺点，开发人员需要根据需求选择最适用的方法。
三、软件体系结构评估的方法软件体系结构评估是指对软件体系结构进行评估和分析，以确定其是否满足设计要求，是否具有合理性、完备性和可行性。
软件体系结构11、软件体系结构评估
一定要确保架构是满足需要的架构，在每个基于架构 的开发方法中，都应该进行架构评估。 代价：（一个700人天的项目的基于ATAM的评审大约需要36人天）
评审者的时间 开发团队的时间和精力 其它涉众的时间
什么时候进行架构评估？
可供选择的时间
规则进行，作为一个迭代架构 设计过程的每一次迭代的一部 分 早期，评估项目的总体架构 开始主要的系统构造工作之前 确定如何解决架构问题时（可 能太晚了） 要集成、修改早期系统之时
ATAM评估小组的角色
评估小组负责人
准备评估；与评估客户协调；保证满足客户的需要；签署评估合同；组 建评估小组；负责检查最终报告的生成与提交
评估负责人
负责评估工作；促进场景的得出；管理场景的选择及设置优先级的过程； 促进对照构架的场景评估；为现场分析提供帮助
场景书记员
在得出场景的过程中负责将场景写到活动挂图上或白板上；务必用己达 成一 致的措辞来表述每个场景，如果还没有想出这样的措辞，先中止讨 论，直到想出来为止
可使用多种英文术语
Evaluation, assessment, analysis, review, validation, verification 但可能有轻微的区别，通过上下文判断
主要内容
架构评估概述 ATAM 小结
为什么要进行问题的成本 降低“灾难项目”的风险 增强对系统的理解并完善系统文档 能对需求分类并分配优先级 对系统进行有组织的学习
方式
正式或者是非正式的 计划内的或者是计划外的
谁参与架构评估？
可能的评审者
开发团队自身 同一组织的其它团队 外来的评审者
好处在于他们对评审的结果并不在乎
对评审者的要求
领域知识和经验 有对抗性思维 Competition 没有偏见
第9章-软件体系结构评估
❖ 阶段3：这个阶段以利益相关人员为中心。着重于 获得利益相关人员的观点然后验证第二个阶段的结 果。
❖ 阶段4：在这个阶段中产生最终的报告，计划接下 来的动作，然后评估组织更新其业绩记录和经验基 础。
2021/8/14
2021/8/14
42
第九章 软件体系结构评估
❖ 典型基于场景的评估方法
SAAM方法工作原理
1.形成场景
2.描述体系结构
3.对场景进行分类和确定优先级
4.对间接场景进行单个评估 5.评估场景的相互作用
6.形成总体评估
2021/8/14
43
形成场景
❖ 场景能够说明系统必须支持的活动 类型，同时还必须说明客户参与者 将给系统带来的变化类型。
输出：
predicting software qualty predicting software qualty
qualty predicting software
software qualty predicting
2021/8/14
50
输入
主控程序
循环转换
按字母顺序排序
2021/8/14
6
质量属性（2）
2.可靠性
定义：可靠性是软件系统在意外或错误使 用的情况下，仍然能够维持软件系统的功 能特性的基本能力，包括容错能力和健壮 性。
❖ 容错：在错误发生时确保系统正确的行为，并进行内部 “修复”；
❖ 健壮性：保护应用程序不受错误使用和错误输入的影响， 即在遇到意外错误事件时确保应用系统处于定义好的状 态。
第九章 软件体系结构评估
2021/8/14
软件体系结构综述
软件体系结构综述计算机应用专业赵诚 070321169随着计算机应用的日益普及，人们对软件的需求量急剧增加。
起初，人们把软件设计的重点放在数据结构和算法的选择上。
随着软件系统规模越来越大，越来越复杂，新的问题也随之而来, 大量实践统计表明:系统软件开发中，70%的错误是由软件设计阶段引入的; 而且错误在系统中存在的时间越长则越难发现, 解决这些错误的代价也越高，于是整个系统的结构和规格说明逐渐占有了重要的位置，软件体系结构这一概念也应运而生。
它成为了沟通软件需求和软件设计的一座桥梁。
1、软件体系结构的定义对于软件体系结构的定义，至今还没有一个统一的、得到广泛认可的解释，很多软件体系结构学者都提出了各自对体系结构的概念与定义。
软件体系结构的最核心概念有构件、连接件、配置、端口和角色。
构件是具有某种功能可重用的软件基本单元，表示软件系统中主要的计算元素和数据存储单元。
连接件表示了构件之间的交互，是构件与构件之间建立和维持行为关联和消息传递的途径。
包括实现构件之间的交互机制和管理这些交互的原则（协议）。
配置表示了构件和连接件之间的拓扑结构和逻辑约束，它是构件和连接件的集合。
总之，软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件体系结构不仅定义了系统的组织结构和拓扑结构，而且表示了系统的需求和构成系统的元素之间的对应关系提供了设计决策的基本原理和约束条件。
2、软件体系结构的风格软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统，按这种方式理解，软件体系结构风格定义了用于描述系统的术语表和一组指导构件系统的规则。
2.1数据流系统数据流是一种将数据从输入端显式的输送到输出端的体系结构风格。
数据流风格的构件是数据的处理单元，连接件是连接处理单元的通道。
软件架构综述论文
软件架构综述一、软件架构的定义1、软件架构的概念软件架构（software architecture）是一个系统的草图,是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
软件架构描述的对象是直接构成系统的抽象组件。
在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。
特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。
在“软件构架简介”一书中，David GArlan 和Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。
结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。
”2、与软件体系结构概念的细微区别目前，没有文献表明软件体系结构与软件架构的差别。
如果你强调方法论，应使用软件体系结构。
强调软件开发实践，应使用软件架构。
构架不仅是结构，IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。
构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。
它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。
在Rational Unified ProcESs 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
软件系统的架构是一个软件系统从整体到部分的最高层次的划分。
其有两个要素：元件划分和设计决定。
详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（TASk-flow）。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
3.2 ATAM方法
× ATAM方法基于假设如下： 体系结构风格是体系结构质量属性最主要的限定，因此采用 ABASs(attribute-based architecture styles)来限定体系结 构的描述形式。 × ATAM关注如何从商业目标获取体系结构的质量属性目标， 体系结构风格是如何协助达到这些目标。
5.1.3 执行场景评价
7. 辅助审查的内容发生改变，分两种情况： ①改动的内容能够用规定的文法来描述，则直接支持。 ②改动的内容不能够用规定的文法来描述．则间接支持。 8. XML采用的DTD结构政为SCHEMA结构：间接支持。需要改动的 模块是：XMLConv。 9. 移植到其他的操作系统之中：间接支持。改动所有调用， WIN32API的模块都需要改动。 10. 从对一个申请文档的编辑改为对一个申请项目工程的编辑：间 接支持。需要改动的模块是：MainProc．TmptManage。 11. 与一个新的开发工具结合：间接支持。需要把电子编辑器改为 可嵌入的服务器软件。需要改动的模块是：MalnProc。
3.1 SAAM方法
× SAAM方法在改良事物性质的方面具有极大的功效。 × SAAM方法是第1个被广泛接受的体系结构分析评价方法。 × 它适用于可修改性、可拓展性以及功能覆盖等质量属性。
3.1 SAAM方法
SAAM方法的过程
场景是常用的一种技术，由用户、外部激励等初始化，通常包括系统中 的事件和触发该事件的特定激励。SAAM方法采用大脑风暴技术构建场 景，体系结构的描述采用自然语言或其他形式表示。方法将场景归类为 直接场景和间接场景，分别支持对体系结构的静态结构分析和动态分析。
5.1.3 执行场景评价
× 对每一个场景，确定这个任务能否被直接支持(通过执行 该系统)或间接支持(通过修改该系统)。如果是间接支持，需 要确定需要改动的部件和关系数量，改变的多少，可以代表 系统的性能。改动越少，代表系统性能越好，反之，系统性 能越差。
5.1.3 执行场景评价
1. 支持其他不同格式的文档：间接支持，需要改动的模块足 DoctConv。 2. 改变文档结构索引表的显示风格：间接支持。需要改动的模块是 Ooclndex。 3. 增加对XML文件的辅助审查：间接支持。需要改动的是 MainProc，AsitCheck。MainProc模块需要增加进行XML文件辅 助审查的命令。AsitCheck需要增加对XML文件进行辅助审查功能。 4. 增加对化学公式和数学公式的支持：间接支持。需要改动的是 MainProc模块。需要增加一个处理数学与化学公式的模块。 5. 增加快速索引的功能：间接支持。需要改动的模块是MainProc。 6. 常用字处理组件WPTOOLS改为RICHEDIT：间接支持。需要改动 的模块是：MmnPmc，WordProc，AsitCheck，Doclndex。
× ALPSM包括六个步骤： 标志维护任务的分类 合成场景 为每个场景分配权重 估计所有元素的大小 为场景编写脚本 计算预测的维护成本
3.3 ALPSM方法
4 关键方法的比较
4 关键方法的比较
本部分主要对三个相对有代表性软件体系结构分析与评 估方法做了比较与讨论，通过图表的方式分辨从考察的属性， 适用的阶段，适用的评估技术以及风险承担者的参与等角度 进行概括与总结，使得读者能够更加清楚的了解到各种软件 评估方法的优点与缺点。
我们通过这些分析来评价该体系结构的质量。
1 发展现状 2 概念描述 3 关键技术与方法 4 关键方法的比较
目录
5 实例剖析 6 目前仍存在的问题讨论
7 发展趋势 8 总结
目录
1 发展现状
1 发展现状
20世纪90年代以来，软件体系结构的评估技术一直是研 究的热点问题。
一些软件体系结构的评估方法已经比较成熟并得到了应 用和验证，如基于场景的软件体系结构分析方法（SAAM）、 软件体系结构折中分析方法（ATAM）、利用软件性能工程 SPE对软件体系结构进行评估的方法（PASA），软件体系结 构层次可维护性预测方法（ALMA）等。
3.3 ALPSM方法
3.3 ALPSM方法
× ALPSM方法是BengtsSon和Bosch提出的在体系结构层 次预测系统可维护性的一种方法。 × ALPSM定义了可维护性框架，即一组表示维护任务的变 更场景。一个场景描述系统中可能发生的一个或一系列动作， 场景的变更就描述一个具体的维护任务。 × ALPSM以场景变更的规模作为可维护性的预测因子，通 过场景变更所需的维护代价分析体系结构可维护性。
软件体系结构分析与评估综述
Team#12 杨广 杨英达 曹海涛 李良 袁柱 王喆
研究背景
× 随着对软件体系结构的研究不断深化，诞生了软件体系结 构形式化描述、风格、规范、建模等一系列的概念，并且形 成了一个新的研究领域。 × 对于软件系统来说，软件质量变得更重要，大规模的复杂 软件系统更是如此。 × 高质量的软件在维护和测试阶段的开销较低，复用的潜力 大。
1 发展现状
人们逐步认识到软件体系结构的分析评估对保证软件质 量的重要性，在软件体系结构分析与评估这个新领域，许多 研究组织在各种杂志与会议上提出了许多新颖的结构化的评 估方法，并且对这些软件体系结构分析与评估的新方法的验 证与实现在不断的进行着。
2 概念描述
2 概念描述
在软件设计领域一般认为： 软件体系结构的分析评估，就是通过成本相对较低的活
3.2 ATAM方法
× ATAM方法的分析评价是一个迭代过程。 × 包括4个阶段：
准备 调查和分析 测试 报告
3.2 ATAM方法
× 实际应用中，ATAM借助调查表实现，它使用调查表来收 集影响体系结构质量属性的要素，描述质量属性的特征，并 将场景分为如下3类。
3.2 ATAM方法
1 Use case scenario
研究背景
人们已经认识到： 在软件生命周期的越早阶段对软件质量进行评价越能降
低整个开发的成本，在越早阶段对质量进行控制的效果也越 好。 × AT&T的报告显示，在早期阶段对软件质量进行评价可提 高10％的开发效率。
研究背景
对软件体系结构的分析包括有： 1 对其组成要素的分析 2 要素之间联系的分析
3.2 ATAM方法
× ATAM方法是被验证有效和广泛使用的一种方法，可以针 对实用性、可靠性和可修改性这些质量属性，在系统开发之 前对其进行分析和评价。 × 在评估活动结束以后，将评估的结果与实际需求相对比， 如果系统预期性能可以满足需求，设计工作就可以继续进行。 × 但它对质量属性并没有进行深入分析，缺少定量的数据来 支持分析的结果。
动来分析结构中可能存在的风险，发现软件体系结构中影响 系统质量的关键因素，并提出相应的改进措施，在此基础上 检验软件的性能需求是否得到满足。
3 关键技术与方法
3 关键技术与方法
× 软件体系结构的分析与评价方法主要可以从两个角度进行 分析，一是进行定性的分析，二是进行定量的分析。 × 定性的分析主要是采用基于checklist，questionnaire和 场景的分析评价技术。 × 定量的分析主要是采用基于度量指标、原型系统、数学模 拟、模拟、测量等技术的。 × 本部分将对国内外有代表性的几种分析评估方法进行讨论。
子程序调用 隐式调用
主控制
5.1.1 描述体系结构
模板制作 输 入
模板管理
文档结构索引 常用字处理
文档转换
ADL文件编辑 输 出
辅助审查
XML转换
Modify GetData
Init
模板库
数据存储类
XML文件库
软件体系结构图
5.1.2 开发任务场景
1. 打开其他格式的文档，比如原先不支持word97以上的文档格式、 WPS文档格式，现在要求支持WORD97以上的doc文档以及WPS文 档等。 2. 改变文档结构索引的显示风格，从树形改为列表形。 3. 增加对XMI文件的辅助审查。 4. 增加对数学公式、化学公式的支持。 5. 增加快速索引的功能，比如对于条目自动跳过。 6. 常用字处理模块采用的是WPTOOIs组件，如果WPTOOLs组件不 符台要求的话，对软件的设计有何影响。 7. 辅助审查的内容可以改变。 8. XML采用的结构从DTD改为SCHEMA，随之带来的XML标准也 要进行改变。
比较因素 评估方法
SAAM ATAM
ALPSM4 关键方法的比较考查的 质量属性使用阶段
使用的 评估技术
风险承担 者的参与
可修改性
多个质量属性 （侧重可修改 性、安全性、 性能和可用性 ）
SA的最终版 本
SA的最终版 本或设计的 重复改进过 程
场景
询问技术和度量技术（通过效用 树和对场景的集体讨论来理解质 量属性需求，通过对软件体系结 构方法的分析来确定敏感点、权 衡点和风险）
3.1 SAAM方法
3.1 SAAM方法
× SAAM法是把一个物体最丰要的属性列举出来，再用检查 表法把各个项目加以变化，并将其加以重新组合，然后再找 出其中可以实行而且也有效果的项目。 × 实质上是将列举法和检查表法互相配合使用。 × 在使用检查表法的时候，我们会发现被检查的事物范围太 大了。如用“替换”来变更设计时，是变更哪一部分的设计 就没有具体确定。。
4 关键方法的比较
× 从表中可以看出三种方法使用的阶段是不同的。 × 对于ALPSM来说，这种方法主要应用在设计过程，并且 考查软件系统的可维护性，该方法是基于场景（不同于用例 场景）的方式的，风险承担者的参与仅仅是设计师。
4 关键方法的比较
× 同样对于SAAM来讲，使用的评估技术也是基于场景的， 这种方法主要用来评估系统的可修改性，使用的阶段通常是 SA的最终版可修改性、安全性、可用性，使用阶段主要是SA 的最终版本或设计的重复改进本。 × 基于询问技术与度量技术的ATAM方法，可以检测多种质 量属性，其中包括过程，风险承担者的参与是所有的风险承 担者以及体系结构设计师。