架构-案例-必背

质量属性效用树、质量属性判断

☆性能

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

可靠性

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

☆可用性

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

☆安全性

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

• 完整性【防止信息被篡改】
• 机密性【信息不泄露给未授权的用户】
• 不可否认性【不可抵赖】
• 可控性【对信息的传播及内容具有控制的能力】
  设计策略：入侵检测、用户认证、用户授权、追踪审计

  例如：

  1. 可抵御SQL注入攻击;
  2. 对计算机的操作都有完整记录;
  3. 用户信息数据库授权必须保证99.9%可用。

☆可修改性

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

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

功能性

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

例如：

1. 界面友好;
2. 新用户学习使用系统时间不超过2小时。

可变性

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

互操作性

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

必背概念

软件架构风格

架构风险

风险点与非风险点

敏感点

权衡点