2025系统架构师（一考就过）：案例之四：架构复用、架构评估、特定架构（DSSA）、架构开发方法（ABSD）

二、软件架构复用

◆软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理复用、集成新的系统。

◆软件架构复用的类型包括机会复用和系统复用。机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。
◆可复用的资产包括:需求、架构设计、元素、建模与分析、测试、项目规划、过程方法和工具、人员、样本系统、缺陷消除。
◆复用的基本过程主要包括3个阶段: 首先构造/获取可复用的软件资产，其次管理这些资产
(构件库)
最后针对特定的需求，从这些资产中选择可复用的部分，以开发满足需求的应用系统

软件复用过程的主要阶段包括（ ）。

A：分析可复用的软件资产、管理可复用资产和使用可复用资产

B：构造／获取可复用的软件资产、管理可复用资产和使用可复用资产

C：构造／获取可复用的软件资产和管理可复用资产

D：分析可复用的软件资产和使用可复用资产

答案：B

解析：

软件复用是指系统化的软件开发过程：开发一组基本的软件构造模块，以覆盖不同的需求/体系结构之间的相似性，从而提高系统开发的效率、质量和性能。

复用的基本过程主要包含3个阶段：首先构造/获取可复用的软件资产，其次管理这些资产，最后针对特定的需求，从这些资产中选择可复用的部分，以开发满足需求的应用系统。

三、DSSA（特定领域软件架构）

DSSA（Domain Specific Software Architecture）就是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构，实施DSSA的过程中包含了一项基本的活动。其中，领域模型是（ ）阶段的主要目标。

A：领域设计 B：领域实现

C：领域分析 D：领域工程
答案：C

特定领域软件架构（ Domam Specifie Sottware Architecture . DSSA ）是指特定应用领域中为一组应用提供组织结构参考的标准软件架构。从功能覆盖的范围角度，(1）定义了一个特定的系统族，包含整个系统族内的多个系统，可作为该领城系统的可行解决方案的一个通用软件架构；(2）定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统族的特定部分功能。

1-A:垂直域

1-B:水平域

1-C:功能域

1-D:属性域

2-A:垂直域

2-B:水平域

2-C:功能域

2-D:属性域

答案：A、B

◆DSSA就是专用于一类特定类型的任务(领域)的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合
◆DSSA就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成。
◆垂直域: 在一个特定领域中的通用的软件架构，是一个完整的架构。
◆水平域: 在多个不同的特定领域之间的相同的部分的小工具(如购物和教育都有收费系统，收费系统即是水平域)

◆DSSA的三个基本活动：分析、设计、实现
①领域分析:这个阶段的主要目标是获得领域模型(领域需求)。识别信息源，即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。
②领域设计: 这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计（特定领域软件架构）。建立了领域模型之后，就可以派生出满足这些被建模的领域需求DSSA。
③领域实现: 这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。

◆参与DSSA的四种角色人员：
领域专家: 包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品，等等

领域分析人员：由具有知识工程背景的有经验的系统分析员来担任。控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中。
领域设计人员: 由有经验的软件设计人员来担任。根据领域模型和现有系统开
发出DSSA，并对DSSA的准确性和一致性进行验证。
领域实现人员: 由有经验的程序设计人员来担任。根据领域模型和DSSA，开发
构件。

◆建立DSSA的过程：
定义领域范围: 领域中的应用要满足用户一系列的需求。
定义领域特定的元素: 建立领域的字典，归纳领域中的术语，识别出领域中相同和不相同的元素。
定义领域特定的设计和实现需求的约束: 识别领域中的所有约束，这些约束对领域的设计和实现会造成什么后果。
定义领域模型和架构: 产生一般的架构，并描述其构件说明
产生、搜集可复用的产品单元: 为DSSA增加复用构件，使可用于新的系统。

以上过程是并发的、递归的、反复的、螺旋型的。

三层次模型
◆领域开发环境: 领域架构师决定核心架构，产出参考结构、参考需求、架构、领域模型、开发工具。
◆领域特定的应用开发环境: 应用工程师根据具体环境来将核心架构实例化。
◆应用执行环境: 操作员实现实例化后的架构。

这里领域开发环境面向的是整个领域，比如通用的教育行业的领域；领域应用开发环境是特定的领域：比如教育行业下特定的盲人教育领域；

DSSA是在一个特定应用领域中为一组应用提供组织结构参考的软件体系结构，参与DSSA的人员可以划分为4种角色，包括领域专家、领域设计人员、领域实现人员和()，其基本活动包括领域分析、领域设计和()。
A.领域测试人员 B.领域顾问 C.领域分析师 D.领域经理
A.领域建模 B.架构设计 C.领域实现 D.领域评估

答案：C、C

特定领域软件架构(Domain specific Software Architecture,DSSA)以一个特定问题领域为对象，形成由领域参考模型，参考需求，()等组成的开发基础架构，支持一个特定领域中多个应用的生成。DSSA的基本活动包括领域分析、领域设计和领域实现。其中领域分析的主要目的是获得()，从而描述领域中系统之间共同的需求，即领域需求；领域设计的主要目标是获得()，从而描述领域模型中表示需求的解决方案;领域实现的主要目标是开发和组织可重用信息，并实现基础软件架构。

A.参考设计 B.参考规约 C.参考架构 D.参考实现

A.领域边界 B.领域信息 C.领域对象 D.领域模型

A.特点领域软件需求 B.特定领域软件架构 C.特定领域软件设计模型 D.特定领域软件重用模型

答案：C、D、B

四、ABSD（基于架构的软件开发）

ABSD 方法是一个自顶向下、递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。

◆ABSD方法是架构驱动，强调由业务、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。进一步来说，用例描述的是功能需求，质量属性场景描述的是质量需求(或侧重于非功能需求)。

◆使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成，就开始了软件设计。
◆ABSD方法有三个基础。

第一个基础是功能的分解，使用已有的基于模块的内聚和耦合技术;

第二个基础是通过选择架构风格来实现质量和业务需求;

第三个基础是软件模板的使用，软件模板利用了一些软件系统的结构。
◆ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，有助于降低架构设计的随意性。

注意：RUP（统一过程） 是用例驱动，ABSD是架构驱动。

用例：反映了大的方向的功能，比较泛，比如图书馆管理系统的管理员可以查询图书这个功能，那么查询书籍就是一个用例（这个用例没有详细的说怎么查等等）；场景：反映了具体的流程，比较细，而查询书籍这个用例的场景就是比如：需要先登录账户、然后输入要查询的内容、查询到之后要2-3秒之内给个反馈等等。

所以用例更偏向于功能的描述，场景就相当于对用例的更详细的描述。

基于架构的软件开发过程可分为下列六步：架构需求、架构设计、架构文档化、架构复审、架构实现、架构演化（优化）

(1)架构需求:重在掌握标识构件的三步，如下左图。
(2)架构设计:将需求阶段的标识构件映射成构件进行分析，如下右图。
(3)架构(体系结构)文档化:主要产出两种文档，即架构(体系结构)规格说明，测试架构(体系结构)需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败。

(4)架构复审:由外部人员(独立于开发组织之外的人，如用户代表和领域专家等)参加的复审，复审架构是否满足需求，质量问题，构件划分合理性等。若复审不过，则返回架构设计阶段进行重新设计、文档化，再复审。
(5)架构实现:用实体来显示出架构。实现构件，构件组装成系统，如下左图:
(6)架构演化:对架构进行改变，按需求增删构件，使架构可复用，如下右图:

在基于体系结构的软件设计方法中，采用()来描述软件架构，采用()来描述功能需求，采用()来描述质量需求,
A.类图和序列图 B.视角与视图 C.构件和类图 D.构件与功能
A.类图 B.视角 C.用例 D.质量场景
A.连接件 B.用例 C.质量场景 D.质量属性

答案：B、C、C

体系结构文档化有助于辅助系统分析人员和程序员去实现体系结构。体系结构文档化过程的主要输出包括()。
A.体系结构规格说明、测试体系结构需求的质量设计说明书
B.质量属性说明书、体系结构描述
C.体系结构规格说明、软件功能需求说明
D.多视图体系结构模型、体系结构验证说明

答案：A

基于体系结构的软件设计(Architecture-Based Software Design,ABSD)方法是体系结构驱动，是指构成体系结构的（1）的组合驱动的。 ABSD 方法是一个自顶向下、递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生（2）。

1-A：产品、功能需求和设计活动

1-B：商业、质量和功能需求

1-C：商业、产品和功能需求

1-D：商业、质量和设计活动

2-A：软件产品和代码

2-B：软件构件和类

2-C：软件构件和连接件

2-D：类和软件代码

答案：1-B、2-B

五、架构评估

1、质量属性

系统（1）是指在规定的时间内和规定条件下能有效地实现规定功能的能力。它不仅取决于规定的使用条件等因素，还与设计技术有关。常用的度量指标主要有故障率（或失效率）、平均失效等待时间、平均失效间隔时间和可靠度等。其中，(2）是系统在规定工作时间内无故障的概率。

1-A：可靠性

1-B：可用性

1-C：可理解性

1-D：可测试性

2-A：失效率

2-B：平均失效等待时间

2-C：平均失效间隔时间

2-D：可靠度

答案：1-A、2-D

解析：

可靠性（Reliability）是指产品在规定的条件下和规定的时间内完成规定功能的能力。

常用的度量指标主要有故障率（或失效率）、平均失效等待时间、平均失效间隔时间和可靠度等。

可靠度就是软件系统在规定的条件下、规定的时间内不发生失效的概率。

效用树是采用架构权衡分析方法（Architecture Tradeoff Analysis Method,ATAM）进行架构评估的工具之一，其树形结构从根部到叶子节点依次为（ ）。

A：树根、属性分类、优先级、质量属性场景

B：树根、质量属性、属性分类、质量属性场景

C：树根、优先级、质量属性、质量属性场景

D：树根、质量属性、属性分类、优先级

答案：B

解析：

形成的一棵质量属性效用树结构为：树根-质量属性-属性细分（分类）-质量属性场景（叶子）

软件系统质量属性（Quality Attribute）是一个系统的可测量或者可测试的属性，它被用来描述系统满足利益相关者需求的程度，其中，(1）关注的是当需要修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度，（2）关注的是当用户数和数据量增加时，软件系统维持高服务质量的能力。

1-A：可靠性 1-B：可测试性

1-C：可维护性 1-D：可重用性

2-A：可用性 2-B：可扩展性

2-C：可伸缩性 2-D：可移植性

答案：C、C

1、性能:指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。
设计策略:优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。
2、可靠性:是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF、MTTR。
设计策略:心跳、Ping/Echo、冗余（备份）、选举
3、可用性:是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。
设计策略:心跳（检测主机是否坏了，然后备份机及时顶上）、Ping/Echo、冗余（备份）、选举。
4、安全性:是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。
设计策略:入侵检测、用户认证、用户授权、追踪审计。

在可用性、可靠性两者比较模糊时，优先考虑可用性方面。

可靠性：有了错误能不能恢复；可用性：故障间隔时间，系统正常使用的时间比例。

5、可修改性:指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量。
设计策略:接口-实现分类、抽象、信息隐藏。
6、功能性:是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
7、可变性(可扩展性):指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。
8、互操作性:作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。

可以将软件系统质量属性分为运行期质量属性与开发期质量属性。

运行期质量属性：

1. 性能：指软件系统及时提供相应服务的能力。（速度、吞吐量、持续高速性）
2. 安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
3. 易用性：指软件系统易于被使用的程度。
4. 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
5. 互操作性：与其他系统交换数据和相互调用服务的难易程度。
6. 可靠性：在一定的时间内无故障运行的能力。
7. 持续可用性：指系统长时间无故障运行的能力。与可靠性相关联，常将其纳入可靠性中。
8. 鲁棒性：是指软件系统在一些非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等）下仍能够正常运行的能力。也称健壮性或容错性。

开发期质量属性：

1. 易理解性：指设计被开发人员理解的难易程度。
2. 可扩展性：软件因适应需求变化而增加新功能的能力。也称为灵活性。
3. 可重用性：指重用软件系统或某一部分的难易程度。
4. 可测试性：对软件测试以证明其满足需求规范的难易程度。
5. 可维护性：当需要修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度。
6. 可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

2、质量属性场景

质量属性场景是一种面向特定质量属性的需求。它由6 部分组成:
①刺激源(Source):这是某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)
②刺激(stimulus):该刺激是当刺激到达系统时需要考虑的条件。
③环境(Environment):该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
④制品(Artifact):某个制品被激励。这可能是整个系统，也可能是系统的一部分。
⑤响应(Response):该响应是在激励到达后采取的行动。
⑥响应度量(Measurement):当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

可修改性质量属性场景描述实例:

刺激源在一定环境下对制品进行刺激；制品对于该刺激进行响应并进行响应度量。

为了精确描述软件系统的质量属性，通常采用质量属性场景（Quality Attribute Scenario）作为描述质量属性的手段。质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述，它由刺激源、刺激、环境、制品、(1）六部分组成。其中，想要学习系统特性、有效使用系统、使错误的影响最低、适配系统、对系统满意属于（2）质量属性场景的刺激。

1-A：响应和响应度量 1-B：系统和系统响应

1-C：依赖和响应 1-D：响应和优先

2-A：可用性 2-B：性能

2-C：易用性 2-D：安全性

答案：1-A、2-C

解析：

质量属性场景由刺激源、刺激、环境、制品、响应和响应度量六部分组成。

质量属性场景主要关注可用性、可修改性、性能、可测试性、易用性和安全性等6类质量属性。

3、软件架构评估

改变加密级别可能会对安全性和性能产生非常重要的影响，因此在软件架构评估中，该设计决策是一个（ ）。

A：敏感点

B：风险点

C：权衡点

D：非风险点

答案：C

解析：

系统架构评估中有一个重要概念，就是敏感点（Sensitivity Point）与权衡点（Tradeoff Point），其是关键的架构决策。

敏感点是一个或多个构件（和/或构件之间的关系）的特性。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

题干中，改变加密等级，影响了多个属性，就是属于权衡点。

在进行架构评估时，首先要明确具体的质量目标，并以之作为判定该架构优劣的标准。为得出这些目标而采用的机制叫做场景，场景是从（）的角度对与系统的交互的简短措述。

A：用户 B：系统架构师

C：项目管理者 D：风险承担者

答案：D

解析：

场景（scenarios）：在进行架构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。为得出这些目标而采用的机制做场景。场景是从风险承担者的角度对与系统的交互的简短描述。在体系结构评估中，一般采用刺激（stimulus）、环境（environment）和响应（response）三方面来对场景进行描述。

◆敏感点:是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
◆权衡点:是影响多个质量属性的特性，是多个质量属性的敏感点。
◆风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念，即可能引起风险的因素，可称为风险点。某个做法如果有隐患，有可能导致一些问题，则为风险点;而如果某件事是可行的可接受的，则为非风险点。
◆软件架构评估在架构设计之后，系统设计之前，因此与设计、实现、测试都没有关系。评估的目的是为了评估所采用的架构是否能解决软件系统需求，但不是单纯的确定是否满足需求（还要满足质量要求、成本要求等）。

比如为了实现某个功能，该功能要设计的考虑性能优先或安全优先，或者性能和安全并列优先。这里的性能、安全就是特性、敏感点；而既要考虑安全又要考虑性能（安全基本就要牺牲一定性能，性能基本就要牺牲一定安全）这就是权衡点。

1、三种常用的架构评估方式

◆基于调查问卷(检查表)的方式:类似于需求获取中的问卷调查方式，只不过是架构方面的问卷，要求评估人员对领域熟悉。
◆基于度量的方式:制定一些定量指标来度量架构，如代码行数、如几秒要打开等。要制定质量属性和度量结果之间的映射，要求评估人员对架构熟悉。

◆基于场景的方式:主要方法。首先要确定应用领域的功能和软件架构的结构之间的映射，然后要设计用于体现待评估质量属性的场景(即4+1视图中的场景)，最后分析软件架构对场景的支持程度。要求评估人员即对领域熟悉，也对架构熟悉。从三个方面对场景进行设计:刺激(事件);环境(事件发生的环境);响应(架构响应刺激的过程)

2、基于场景的架构分析方法的三种方法

1、SAAM（了解即可）

◆基于场景的架构分析方法SAAM
SAAM是一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法，
◆特定目标。SAAM的目标是对描述应用程序属性的文档，验证基本的架构假设和原则。
◆质量属性。这一方法的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。
◆架构描述。SAAM 用于架构的最后版本，但早于详细设计。架构的描述形式应当被所有参与者理解。
◆功能、结构和分配被定义为描述架构的3个主要方面。
◆方法活动。SAAM的主要输入是问题描述、需求声明和架构描述。下图描绘了SAAM分析活动的相关输入及评估过程。包括5个步骤，即场景开发、架构描述、单个场景评估、场景交互和总体评估。

2、ATAM（掌握）

◆架构权衡分析法ATAM，让架构师明确如何权衡多个质量目标，参与者有评估小组、项目决策者和其他项目相关人。
◆ATAM被分为四个主要的活动领域，分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。整个评估过程强调以质量属性作为架构评估的核心概念。主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

描述ATAM方法：描述规则；描述业务动机：描述需求；描述架构：描述架构；

生成质量属性效用树例子：

3、CBAM（了解即可）

◆成本效益分析法CBAM，用来对架构建立的成本来进行设计和建模，让决策者根据投资收益率来选择合适的架构，可以看做对ATAM的补充，在ATAM确定质量合理的基础上，再对效益进行分析。有下列步骤:
◆整理场景(确定场景，并确定优先级，选择三分之一优先级最高的场景进行分析)
◆对场景进行细化(对每个场景详细分析，确定最好、最坏的情况)
◆确定场景的优先级(项目干系人对场景投票，根据投票结果确定优先级)
◆分配效用(对场景响应级别确定效用表，建立策略、场景、响应级别的表格);
◆形成“策略-场景-响应级别的对应关系“
◆确定期望的质量属性响应级别的效用(根据效用表确定所对应的具体场景的效用表)
◆计算各架构策略的总收益;
◆根据受成本限制影响的投资报酬率选择架构策略(估算成本，用上一步的收益减去成本，得出收益，并选择收益最高的架构策略)

某公司欲开发一个在线交易网站，在架构设计阶段，公司的架构师识别出3个核心质量属性场景。"应该在3秒内完成"主要与(58)质量属性相关，通其中"网站正常运行时，用户发起的交易请来常 可采用(59 )架构策略实现该性;"在线交易主站宕机后，能够在3秒内自动切换至备用站点并恢 复正常运行"主要与(60 )质量属 性相关，通常可采(61)架构策略实现该属性;"系统应该具备一 定的安全保护措施，从而能够抵拦恶意的入侵破坏行为，并对所有针对网站的攻击行为进行报警和 记录“主要与(62)质量属性相关，通常可采用(63)架构策略实现该属性。

(58) A.可用性 B.性能 C.易用性 D.可修改性

(59) A.抽象接口 B.信息隐藏 C.主动冗余 D.资源调度

(60) A.可测试性 B.易用性 C.可用性 D.互操作性
(61) A.记录/回放 B.操作串行化 C.心跳 D.增加计算资源

(62) A.可用性 B.安全性 C.可测试性 D.可修改性

(63) A.追踪审计 B.Ping/Echo C.选举 D.维护现有接口

答案：A、D C、C B、A

架构权衡分析方法(Architecture Tradeoff Analysis Method，ATAM)是一种系统架构评估方法，主要在系统开发之前，针对性能、(57)、安全性和可修改性等质量属性进行评价和折中。ATAM可以分为4个主要的活动阶段，包括需求收集、(58)描述、属性模型构造和分析、架构决策与折中，整个评估过程强调以(59)作为架构评估的核心概念。某软件公司采用ATAM进行软件架构评估，在评估过程中识别出了多个关于质量属性的描述。其中，“系统在进行文件保存操作时应该与Windows系统的操作方式保持一致，主要与(60)质量属性相关；“系统应该提供一个开
放的API接口，支持远程对系统的行为进行控制与调试，主要与(61)质量属性相关。在识别出上述描述后，通常采用(62)对质量属性的描述进行刻画与排序。在评估过程中，(63)是一个会影响多个质量属性的架构设计决策

(57) A.可测试性 B.可移植性 C.可用性 D.易用性

(58) A.架构视图 B.架构排序 C.架构风格 D.架构策略

(59) A.用例 B.视图 C.属性 D.模型

(60) A.可测试性 B.互操作性 C.可移植性 D.易用性

(61) A.可测试性 B.互操作性 C.可移植性 D.易用性

(62) A.期望管理矩阵 B.决策表 C.优先队列 D.效用树
(63) A.风险点 B.决策点 C.权衡点 D.敏感点

答案：(57)C (58)A (59)C (60)D (61)A (62)D (63) C

4、其他评估方法（了解即可）

1、SAEM方法。将软件架构看作一个最终产品以及设计过程中的一个中间产品，从外部质量属性（用户定义的质量属性）和内部质量属性（开发者决定的质量属性）来评估。

2、SAABNet方法。是一种用来表达和使用定性知识以辅助架构的定性评估，来源于人工智能允许不确定、不完整知识的推理。

3、SACMM方法。是一种软件架构修改的度量方法。

4、ALRRA方法。是一种软件架构可靠性风险评估方法。

5、AHP（层次分析法）方法。是对定性问题进行定量分析的一种简便、灵活而又实用的多准则决策方法。

7、COSMIC+UML方法。基于度量模型来评估软件架构可维护性的方法。