前言

内容：

质量属性
架构评估（重重点，选择题5分左右，论文5-10分）

中论

质量属性

开发期质量属性和运行期质量属性（了解）

软件系统的质量属性主要分为开发期质量属性和运行期质量属性

开发期质量主要指在软件开发阶段所关注的质量，主要包括6个方面：

（1）易理解性：设计被开发人员理解的难易程度。

（2）可扩展性：软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性。

（3）可重用性：重用软件系统或某一部分的难易程度。

（4）可测试性：对软件测试以证明其满足需求规范的难易程度。

（5）可维护性：当需要修改缺陷、增加功能、提高质量时，识别修改点并实施修改的难易程度。

（6）可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。
运行期质量主要指在软件运行阶段所关注的质量，主要包括7个方面：

（1）性能：是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。

（2）安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。

（3）可伸缩性：指当用户数和数据量增加时，软件系统维持高质量服务的能力。例如，通过增加服务器来提高能力。

（4）互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。

（5）可靠性：软件系统在一定的时间内持续无故障运行的能力。

（6）可用性：指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响。

（7）鲁棒性：是指软件系统在非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等）仍能够正常运行的能力，也称健壮性或容错性。

架构评估

质量属性（较重要）

性能：指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。设计策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。
可靠性：是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF、MTTR。设计策略：心跳、Ping/Echo、冗余、选举。
可用性：是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。设计策略：心跳、Ping/Echo、冗余、选举。
安全性：是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。设计策略：入侵检测、用户认证、用户授权、追踪审计。
可修改性：指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量。设计策略：接口-实现分类、抽象、信息隐藏。
功能性：是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
可变性：指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。
互操作性：作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。

质量属性场景

质量属性场景是一种面向特定质量属性的需求。

它由6部分组成：

刺激源（Source）：这是某个生成该刺激的实体（人、计算机系统或者任何其他刺激器）。
刺激（Stimulus）：该刺激是当刺激到达系统时需要考虑的条件。
环境（Environment）：该刺激在某些条件下发生。当激励发生时，系统可能处于过载、运行或者其他情况。
制品（Artifact)：某个制品被激励。这可能是整个系统，也可能是系统的一部分。
响应（Response）：该响应是在激励到达后所采取的行动。
响应度量（Measurement）：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。可修改性质量属性场景描述实例：

敏感点：是指为了实现某种特定的质量属性，一个或多个组件所具有的特性。

权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。

风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念，即可能导致风险的因素，可称为风险点；如果某个做法有隐患，有可能导致一些问题，则为风险点；而如果某个做法是可行的可接受的，则为非风险点。

软件架构评估在架构设计之后，系统设计之前，因此与设计、实现、测试都没有关系。评估的目的是为了评估所采用的架构是否能解决软件系统需求，而不是单纯的确定是否满足需求。

评估方式（重点）

基于调查问卷（检查表）的方式：类似于需求获取中的问卷调查方式，只不过是架构方面的问卷，要求评估人员对领域熟悉。
基于度量的方式：制定一些定量指标来度量架构，如代码行数等。要制定质量属性和度量结果之间的映射，要求评估人员对架构熟悉。
基于场景的方式：主要方法。首先要确定应用领域的功能和软件架构的结构之间的映射，然后要设计用于体现待评估质量属性的场景（即4+1视图中的场景），最后分析软件架构对场景的支持程度。要求评估人员既对领域熟悉，也对架构熟悉。从三个方面对场景进行设计：刺激（事件）；环境（事件发生的环境）；响应（架构响应刺激的过程）。

基于场景的架构分析方法SAAM

SAAM是一种非功能性质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法。

特定目标：SAAM的目标是对描述应用程序属性的文档，验证基本的架构假设和原则。
质量属性：这一方法的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。
架构描述：SAAM用于架构的最后一个版本，但早于详细设计。架构的描述形式应当被所有参与者理解。

功能、结构和分配被定义为描述架构的3个主要方面。

方法活动：SAAM的主要输入是问题描述、需求声明和架构描述。下图描绘了SAAM分析活动的相关输入及评估过程。包括5个步骤，即场景开发、架构描述、单个场景评估、场景交互和总体评估。

架构权衡分析法ATAM（十分重要）

架构权衡分析法ATAM，让架构师明确如何权衡多个质量目标，参与者有评估小组、项目决策者和其他项目相关人员。

ATAM被分为四个主要的活动领域，分别是

场景和需求收集、
体系结构视图和场景实现、
属性模型构造和分析、
折中。

整个评估过程强调以属性作为架构评估的核心概念。主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

成本效益分析法CBAM

成本效益分析法CBAM，用来对架构建立的成本来进行设计和建模，让决策者根据投资收益率来选择合适的架构，可以看做对ATAM的补充，在ATAM确定质量合理的基础上，再对效益进行分析。有以下步骤：

整理场景（确定场景，并确定优先级，选择三分之一优先级最高的场景进行分析）；
对场景进行细化（对每个场景详细分析，确定最好、最坏的情况）；
确定场景的优先级（项目干系人对场景投票，根据投票结果确定优先级）；
分配效用（对场景响应级别确定效用表，建立策略、场景、响应级别的表格）；
形成“策略-场景-响应级别的对应关系”；
确定期望的质量属性响应级别的效用（根据效用表确定所对应的的具体场景的效用表）；
计算各架构策略的总收益；
根据受成本限制影响的投资报酬率选择架构策略（估算成本，用上一步的收益减去成本，得出收益，并选择收益最高的架构策略）。

其他评估方法（了解）

SAEM方法。将软件架构视为最终产品以及设计过程中的一种中间产品，从外部质量和内部质量两个角度阐述其评估模型，旨在为软件架构的质量评估创建一个框架。外部属性指用户定义的质量属性，而内部属性指开发者决定的质量属性。

该软件架构评估模型包含以下几个流程。
- 对待评估的质量属性进行规约建模。
- 为外部和内部的质量属性创建度量准则，先从评估目的（如软件架构比较、最终产品的质量预测），评估角度（如开发者、用户、维护者），评估环境（架构作为最终产品或设计中间产品）出发来定义架构评估的目标，再根据目标相关的属性来提出问题，然后回答每个问题并提出相应的度量准则。
- 评估质量属性，包括数据收集、度量和结果分析3个活动。
SAABNet方法。是一种用来表达和使用定性知识以辅助架构的定性评估的方法。该方法来源于人工智能，允许不确定、不完整知识的推理。该方法使用BBN来表示和使用开发过程中的知识，包含定性和定量的描述，其中定性的描述是所有节点的图，定量的描述是每个节点状态相关的条件概率。
SACMM方法。是一种软件架构修改的度量方法。
SASAM方法。通过对预期架构（架构设计阶段的相关描述材料）和实际架构（源代码中执行的人工智能）进行映射和比较来静态地评估软件架构。
ALRRA方法。是一种软件架构可靠性风险评估方法，利用动态复杂度准则和动态耦合度准则来定义组件和连接件的复杂性因素。
AHP（层次分析法）方法。是对定性问题进行定量分析的一种简便、灵活而又实用的多准则决策方法。
COSMIC+UML方法。基于度量模型来评估软件架构可维护性，主要是为了辅助分析软件架构的演化方案是否可行，并在开源软件DCMMS的软件架构UML组件图上得以验证。

后记

桃花直透三层浪，桂子高攀第一枝。