架构设计笔记-8-系统质量属性与架构评估

知识要点

正确识别风险点、非风险点、敏感点和权衡点是进行软件架构评价的关键步骤，其中敏感点是实现一个特定质量属性的关键特征，该特征为一个或多个软件构件所共有。权衡点会影响一个或多个属性，并对于多个属性来说都是敏感点。基于该定义，可以看出“改变加密的级别可能会对安全性和性能都产生显著的影响” 正是一个对系统权衡点的描述。

基于场景的架构分析方法（Scenarios-based Architecture Analysis Method，SAAM）是卡耐基梅隆大学软件工程研究所的 Kazman 等人于 1983 年提出的一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法。SAAM 的主要输入是问题描述、需求说明和架构描述；其分析过程主要包括场景开发、架构描述、单个场景评估、场景交互和总体评估。

实现质量属性的一般策略：

可用性：错误检测（Ping/Echo，命令/响应、心跳、异常处理）、错误恢复（表决（通过冗余构件与表决器相联）、主动冗余、被动冗余、备件、状态再同步、检查点/回滚）、错误预防（从服务中删除、事务（事务保证一致性）、进程监视器等）。
安全性：入侵检测、用户认证、用户授权、追踪审计、限制访问；
可修改性：运行时注册；接口、实现分离；信息隐藏；
可靠性：主动冗余；
性能：队列调度，优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等；
可测试性：记录/回放。

ATAM 是在SAAM基础之上发展起来的，主要包括场景和需求收集、架构视图和场景实现、属性模型构造和分析、折中等 4 个阶段。ATAM 方法要求在系统开发之前，首先对这些质量属性进行评价和折中。

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

架构模式是软件设计中的高层决策，例如 C/S 结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策；

设计模式主要关注软件系统的设计，与具体的实现语言无关；

惯用法则是实现时通过某种特定的程序设计语言来描述构件与构件之间的关系，例如引用-计数就是 C++语言中的一种惯用法。

架构评估的方式主要有三种：基于调查问卷方式，基于场景的方式，基于度量的方式。

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

刺激是场景中解释或描述风险承担者怎样引发与系统的交互部分。例如：用户可能会激发某个功能、维护可能会做某个更改、测试人员可能会执行某种测试，这些都属于对场景的刺激。
环境描述的是刺激发生时的情况。例如：当前系统处于什么状态？有什么特殊的约束条件？系统的负载是否很大？某个网络通道是否出现了阻塞等。
响应是指系统是如何通过体系结构对刺激作出反应的。例如：用户所要求的功能是否得到满足？维护人员的修改是否成功？测试人员的测试是否成功等。

**MVP **是从经典的模式 MVC 演变而来，Presenter 负责逻辑的处理，Model 提供数据，View 负责显示。当然 MVP 与 MVC 也有一些显著的区别，MVC 模式中元素之间“混乱”的交互主要体现在允许 View 和 Model 直接进行“交流”，这在 MVP 模式中是不允许的。