架构-架构设计4-软件架构评估

质量属性

性能

指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。
设计策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。

例如

同时支持1000并发;

响应时间小于1s;

显示分辨率达到4K。

可靠性

是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF、MTTR。
设计策略：心跳、Ping/Echo、冗余、选举。
【容错】【健壮性】

可用性

是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。
设计策略：心跳、Ping/Echo、冗余、选举

例如：

主服务器故障，1分钟内切换至备用服务器

系统故障，1小时内修复;

系统支持7x24小时工作

安全性

是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。

完整性【防止信息被篡改】
机密性【信息不泄露给未授权的用户】
不可否认性【不可抵赖】
可控性【对信息的传播及内容具有控制的能力】
设计策略：入侵检测、用户认证、用户授权、追踪审计
例如：
1. 可抵御SQL注入攻击;
2. 对计算机的操作都有完整记录;
3. 用户信息数据库授权必须保证99.9%可用。

可修改性

指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量
包括4个方面：

【可维护性】：这主要体现在问题的修复上：在错误发生后“修复”软件系统。为可维护性做好准备的软件体系结构往往能做局部性的修改并能使对其他构件的负面影响最小化。
【可扩展性】：这一点关注的是使用新特性来扩展软件系统，以及使用改进版本来替换构件并删除不需要或不必要的特性和构件。为了实现可扩展性，软件系统需要松散耦合的构件。其目标是实现一种体系结构，它能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的体系结构中也是必要的。
【结构重组】：这一点处理的是重新组织软件系统的构件及构件间的关系，例如通过将构件移动到一个不同的子系统而改变它的位置。为了支持结构重组，软件系统需要精心设计构件之间的关系。理想情况下，它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。
【可移植性】：可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植，需要按照硬件无关的方式组织软件系统，其他软件系统和环境被提取出。可移植性是系统能够在不同计算环境下运行的能力。这些环境可能是硬件、软件，也可能是两者的结合。在关于某个特定计算环境的所有假设都集中在一个构件中时，系统是可移植的。如果移植到新的系统需要做些更改，则可移植性就是一种特殊的可修改性。
设计策略：接口-实现分类、抽象、信息隐藏。
例如：
1. 更改系统报表模块，必须在2人周内完成;
2. 对Web界面风格进行修改，修改必须在4人月内完成。

功能性

是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。

例如：

界面友好;

新用户学习使用系统时间不超过2小时。

可变性

指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，不在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。

互操作性

作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。

易用性

易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。

例如:

界面友好;

新用户学习使用系统时间不超过2小时

可测试性

软件可测试性是指通过测试揭示软件缺陷的容易程度。

例如：

提供远程调试接口，支持远程调试。

软件架构评估

系统架构评估是在对架构分析、评估的基础上对架构策略的选取进行决策。

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

【敏感点】：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。它能影响系统的某个质量属性
【权衡点】：是影响多个质量属性的特性，是多个质量属性的敏感点。

风险承担者或者称为利益相关人。系统的架构涉及很多人的利益，这些人都对架构施加各种影响以保证自己的目标能够实现。
在进行架构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该架构优劣的标准。为得出这些目标而采用的机制称之为场景。场景是从风险承担者的角度对与系统的交互的简短描述。在架构评估中，一般采用刺激、环境和响应三方面来对场景进行描述。

【风险点】是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
【非风险点】是指不会带来隐患，一般以“XXX要求是可以实现(或接受)的”方式表达。

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

例如：

对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计

假设每秒中用户交易请求的数量是10个，处理请求的时间为30毫秒，则“在1秒内完成用户的交易请求”这一要求是可以实现的;

目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复影响系统的可修改性;

更改加密的级别将对安全性和性能产生影响。

评估方法

三种常用的评估方式

基于调查问卷(检查表)的方式：类似于需求获取中的问卷调查方式，只不过是架构方面的问卷，要求评估人员对领域熟悉。
基于度量的方式：制定一些定量指标来度量架构，如代码行数等。要制定质量属性和度量结果之间的映射，要求评估人员对架构熟悉。
基于场景的方式：主要方法。首先要确定应用领域的功能和软件架构的结构之间的映射，然后要设计用于体现待评估质量属性的场景(即4+1视图中的场景)，最后分析软件架构对场景的支持程度。要求评估人员即对领域熟悉，也对架构熟悉。
- 【详见：质量属性场景】
- 【场景】是从风险承担者的角度与系统交互的简短描述场景可从六个方面进行描述:刺激源、刺激(事件)、制品、环境(事件发生的环境)、响应(架构响应刺激的过程)**、响应度量

基于场景的评估方法

架构分析方法SAAM

SAAM是一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法。【最初用于分析架构可修改性，后扩展到其他质量属性。】

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

架构权衡分析法ATAM

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

在SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

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

场景和需求收集、
体系结构视图和场景实现、
属性模型构造和分析、
折中。
整个评估过程强调以属性作为架构评估的核心概念。主要针对性能、可用性安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

方法

ATAM方法采用效用树(Utility tree)，这一工具来对质量属性进行分类和优先级排序。效用树的结构包括：树根-质量属性-属性分类-质量属性场景(叶子节点)。

场景设计：从不同的架构角度，有3种不同类型的场景，分别是用例(包括对系统典型的使用、引出信息)、增长场景(用于涵盖那些对它的系统的修改)、探测场景(用于涵盖那些可能会对系统造成过载的极端修改)

领域知识库通过基于属性的架构风格(ABAS)维护。

ATAM方法架构评估实践
注意：建议写这个主题论文的，重点看一下第二版教材第8.3节，第289页，书上给出了胡佛事件架构、银行事件架构这两个具体架构的详细描述，可作为大家写论文时的素材参考，不过书上写的比较多比较复杂，大家也要有选择性的参考。
用ATAM方法评估软件体系结构，其工作分为4个基本阶段，即演示、调查和分析、测试和报告ATAM

成本效益分析法CBAM

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

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

其他评估方法【了】

SAEM方法

将软件架构看作一个最终产品以及设计过程中的一个中间产品，从外部质量属性和内部质量属性两个角度来阐述它的评估模型，旨在为软件架构的质量评估创建一个基础框架。
外部属性指用户定义的质量属性，而内部属性指开发者决定的质量属性。该软件架构评估模型包含以下几个流程。

对待评估的质量属性进行规约建模。
为外部和内部的质量属性创建度量准则，先从评估目的(如软件架构比较、最终产品的质量预测)，评估角度(如开发者、用户、维护者)，评估环境(架构作为最终产品或设计中间产品)出发来定义架构评估的目标，再根据目标相关的属性来提出问题，然后回答每个问题并提出相应的度量准则。
评估质量属性，包括数据收集、度量和结果分析3个活动。

SAABNet方法

是一种用来表达和使用定性知识以辅助架构的定性评估。该方法来源于人工智能，允许不确定、不完整知识的推理。
该方法使用BBN来表示和使用开发过程中的知识，包含定性和定量的描述，其中定性的描述是所有结点的图，定量的描述是每个结点状态相关的条件概率。其中的变量可分为3 类，即架构质量属性变量(如可维护性、灵活性等)、质量属性的度量准则变量(如容错性、响应性等)和架构特征变量(如继承深度、编程语言等)，高层抽象的质量属性变量分解为低层抽象的度量准则变量，度量准则变量则分解为更低层抽象的架构特征变量。

SACMM方法

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

SASAM方法

通过对预期架构(架构设计阶段的相关描述材料)和实际架构(源代码中执行的架构)进行映射和比较来静态地评估软件架构。

ALRRA方法

是一种软件架构可靠性风险评估方法，该方法使用动态复杂度准则和动态耦合度则来定义组件和连接件的复杂性因素，其中，动态复杂度准则在某个场景的执行中分析组件的动态行为来度量组件的复杂性，动态耦合度准则在某个场景的执行中分析连接件的消息传递协议来度量连接件的复杂性。利用失效模式和影响分析(FMEA)技术。

AHP(层次分析法)方法

是对定性问题进行定量分析的一种简便、灵活而又实用的多准则决策方法。AHP方法的特点是把复杂问题中的各种因素通过划分为相联系的有序层次使之条理化，并在一般情况下通过两两对比，根据一定客观现实的主观判断结构，把专家意见和分析者的客观判断结果直接、有效地结合起来，将一定层次上元素的某些重要性进行定量描述，之后利用数学方法计算反映每一层次元素的相对重要性次序的权值，并最后通过所有层次之间的总排序计算所有元素的相对权重及对权重进行排序。