软件体系结构笔记

Software Architecture

1.软件体系结构的定义
2.体系结构风格（适用场景、构件连接件、优缺点、典型应用实例）、大题选择一种应用
3.学会“4+1”模型、UML图的识别辨析
4.质量属性
描述刺激源、刺激、制品、环境、响应、响应衡量指标（质量属性场景）
对应的提升策略
5.软件体系结构评估
识别和描述风险，非风险，敏感点和权衡点
效用树构建

Introduction

1. 软件体系结构的发展史
   
2. 软件体系结构定义
   组成派关注于软件本身，将软件体系结构看做构件和交互的集合。
   决策派关注于软件架构中的实体（人），将软件体系结构视为一系列重要设计决策的集合。
   为软件体系结构是具有一定形式的结构化元素。
   处理元素负责对数据进行加工
   数据元素是被加工的信息
   连接元素把体系结构的不同部分组合连接起来
   组件（component）可以是一组代码，也可以是独立的程序；
   连接件（connector）用于表示组件之间的相互关系，可以是过程调用、管道和消息等；
   约束（constraint）为组件连接时的条件。
   包括软件构件，构件间的联系，构件与其环境间的联系.

架构是一系列重要决策的集合。

软件体系结构：软件体系结构由组件、连接件和属性组成，以组件和组件交互的方式定义系统，说明需求和成品系统之间的对应关系，描述系统级别的可伸缩性、能力、吞吐量、一致性和兼容性等属性。

软件体系结构风格：描述一类体系结构；独立于实际问题，强调了软件系统中通用的组织结构；在实践中被多次应用；是若干设计思想的综合；具有已经被熟知的特性，并且可以复用；

3. 软件体系结构的研究活动
   软件体系结构要解决的问题
   构件、连接件、形成的拓扑结构、典型应用、如何设计、如何修改、描述分析验证。
4. 软件体系结构的作用
   在sdlc的作用

Software Architecture Style

“风格”——经过长时间的实践，被证明具有良好的工艺可行性、性能与实用性，并可直接用来遵循与模仿 (复用)。

Data Flow Style

1. 数据流体系结构风格
   Components: data processing components(基本构件：数据处理)
   Connectors: data flow (stream) (连接件：数据流、单向，异步、有缓冲)

数据流风格的典型代表是数据流图（DFD），它通过节点（代表处理步骤）和边（代表数据流）来表示系统。

2. 批处理体系结构风格
   Components (processing steps) are independent programs (基本构件：独立的应用程序)
   Connectors are some type of media -traditionally tape (连接件：某种类型的媒质)
   Topology: Connectors define data flow graph (连接件定义了相应的数据流图，表达拓扑结构)

Processing steps are independent programs（每个处理步骤是一个独立的程序）
Each step runs to completion before next step starts（每一步必须在前一步结束后才能开始）
Data transmitted as a whole between steps（数据必须是完整的，以整体的方式传递）

【优点】
⚫ 无需考虑同步问题：数据是完整的，以整体的方式在组件之间进行传输，因此无需考虑
同步数据问题；
⚫ 可以随机存取数据：由于数据是完整传输的，因此在获取数据时，可以完整的存取所有
数据。
【缺点】
⚫ 计算效率低，系统性能差，无法并行计算：批处理的处理单元必须在前一个处理单元完
全处理完毕后再进行计算，因此系统计算效率低。
⚫ 无法实时计算：每个组件之间的计算顺序是固定的，因此若实时计算，会存在计算延时
现象
⚫ 交互性差：每个组件都对完整的数据进行计算，因此在处理数据过程中，用户不易交互。

应用实例：
基于Eclipse的代码重复检测工具

3. 管道-过滤器体系结构风格
   场境：数据源源不断的产生，系统需要对这些数据进行若干处理(分析、计算、转换等)。

Components: Filters — process data streams (构件：过滤器，处理数据流)
A filter encapsulates a processing step (algorithm or computation) (一个过滤器封装了一个处理步骤)
Data source and data end/sink are particular filters (数据源点和数据终止点可以看作是特殊的过滤器)
增删、转换、分解、合并，独立的实体

Connectors: A pipe connects a source and a end filter (连接件：管道，连接一个源和一个目的过滤器)
Pipes move data from a filter output to a filter input
Data may be a stream of ASCII characters
Topology: Connectors define data flow graph

应用实例：
Compiler (编译器)
Unix pipes (Unix管道)
Image processing (图像处理)
Signal processing (信号处理)
Voice and video streaming (声音与图像处理)

优缺点：

隐蔽型、高内聚、低耦合
支持复用
系统维护和增加功能简单
允许属性分析
支持并行

不适合交互
性能不高

Call/Return Style

1. 主程序/子程序风格
   System model: call and definition hierarchy, subsystems often defined via modularity
   Components: procedures and explicitly visible data
   Connectors: procedure calls and explicit data sharing
   Control structure: single thread

【优点】
⚫ 流程清晰，易于理解：主程序和子程序之间的调用具有一定的层次结构，层次结构使得系统符合功能分解，分而治之的思维，因此可以通过子程序的调用来清晰的理解系统的执行流程。
⚫ 具有强控制性：主程序和子程序风格具有严格的层次分解和控制权转移，在程序实际执行的过程中具备很强的控制能力。子程序的正确性决定了主程序的正确性。
【缺点】
⚫ 除了过程调用以外的连接件不易描述
⚫ 不易于描述大规模的软件：大规模的软件存在很多的子程序调用，会造成系统程序调用混乱。
⚫ 可复用的层次低：主程序和子程序风格不易于扩展和复用。
⚫ 可测试性差：当代码量过多时，系统不易于测试。

2. 数据抽象/面向对象
   – System model: localized state maintenance
   – Components: managers (e.g., servers, objects, abstract data types)
   – Connectors: procedure call
   – Control structure: decentralized, usually single thread

操作和数据绑定在一起，隐藏实现和其他秘密
封装、交互、多态和继承，支持复用和维护

选择面向对象系统的原因：构件：对象；连接件：消息和消息（过程）调用；适用：界面与实现分离的系统
面向对象的优缺点：1.优点：面向对象易维护，易复用；对象反映现实世界，容易分解一个系统；对象对客户实现了隐藏细节，所有可以在不影响其客户的情况下改变对象的实现 ；2.缺点：对象之间的耦合度较紧：一个对象和另一个对象进行交互时，必须知道对象的标识。只要一个对象的标识改变了，必须修改所有显式调用它的其它对象；

3. 层次风格
   – System model: hierarchy of opaque layers
   – Components: usually composites; composites are most often collections of procedures（过程的集合）
   – Connectors: depends on structure of components; often procedure calls under restricted （受限的过程调用）
   visibility, might also be client/server
   – Control structure: single thread

【优点】
⚫ 支持基于抽象程度递增的系统设计：有利于设计者对一个复杂系统进行分解
⚫ 局部依赖性：因为每一层至多和相邻的上下层交互，因此功能的改变通常影响相邻的上下层
⚫ 可复用性：若某层保证了功能完整性并提供文档化接口，便可以在多个语境中复用
⚫ 可替换性：当每一层的服务接口不变时，通过一组标准接口，可以实现相同接口，不同实现的互换使用。便于系统的开发
⚫ 标准化设计：具有抽象程度高且普遍适用的层次接口有利于标准化开发。
⚫ 可测试性：具有明确的层接口以及交换层接口，提高了系统的可测试能力
【缺点】
⚫ 不是每个系统都易于分层：即使一个系统的逻辑结构是层次化的，出于性能考虑，系统设计师需要将一些功能综合起来。
⚫ 系统效率低：分层系统的雄安率一般低于整体系统的效率；高层的服务可能会需要低层
功能的支持，因此需要等低层提供相关服务后才能进行高层的运转。
⚫ 难以找到正确层次抽样方法：层数太少，分层不能完全发挥风格的可复用性、可更改性和可移植性上的潜力；层数过多，则引入不必要的复杂性和层间隔离冗余以及层间传输开销

下层服务上层，上层调用下层，影响性能。

4. 客户端/服务器风格
   • 两层C/S结构
   服务器（后台）负责数据管理，客户机（前台）完成与用户的交互任务。

• 三层C/S结构
与二层C/S结构相比，增加了一个应用服务器
应用功能分为表示层、功能层、数据层三层
– 表示层是应用的用户接口部分。通常使用图形用户界面
– 功能层是应用的主体，实现具体的业务处理逻辑
– 数据层是数据库管理系统。
– 以上三层逻辑上独立。
– 通常只有表示层配置在客户机中

• B/S结构（浏览器/服务器风格）
B/S体系结构是三层C/S体系结构的特例

Virtual Machine Style

1. 虚拟机风格
2. 解释器风格（用作脚本翻译成机器的语言）
   System model: virtual machine
   – Components: one state machine (the execution engine) and three memories (current
   state of execution engine, program being interpreted, current state of program being
   interpreted)
   – Connectors: data access and procedure call
   – Control structure: usually state-transition for execution engine; input driven for selection of what to interpret
   系统模型:虚拟机
   -组件:一个状态机(执行引擎)和三个内存(当前执行引擎的状态，正在解释的程序，程序的当前状态
   解释)
   -连接器:数据访问和过程调用
   -控制结构:通常是执行引擎的状态转换;输入驱动的选择如何解读

解释器风格（Interpreter Style）是一种软件设计模式，它用于构建可以解释和执行特定语言程序的系统。这种风格的核心思想是将程序的逻辑和执行逻辑分离，通过定义一个解释器来解释和执行程序代码。解释器风格通常用于实现编程语言、脚本语言和各种 Domain-Specific Languages（DSLs）。
解释器风格的构件、连接件和约束包括：

1. 构件（Components）:
   • 抽象语法树（Abstract Syntax Tree, AST）：表示源代码结构的树形数据结构，每个节点代表源代码中的一个语法结构。
   • 解释器（Interpreter）：负责解释AST并执行相应的操作的组件。解释器通常会递归地遍历AST，对每个节点执行相应的动作。
   • 词法分析器（Lexer）：将源代码文本分解为标记（tokens）的组件。标记是源代码的基本语法单元，如关键字、操作符、标识符等。
   • 语法分析器（Parser）：将标记序列转换为AST的组件。语法分析器根据语言的语法规则构建AST。
   • 环境（Environment）：存储解释器执行时的状态信息，如变量值、函数定义等。
2. 连接件（Connectors）:
   • 规则（Rules）：定义了如何将源代码中的标记组合成AST节点的语法规则。
   • 操作（Operations）：定义了解释器在遍历AST时对每个节点执行的具体操作。
3. 约束（Constraints）:
   • 语法确定性：语言的语法必须是确定性的，即每个有效的源代码文本都应该有一个唯一的AST表示。
   • 封闭性：解释器应该能够处理所有可能的输入，不会因为输入的不同而需要修改解释器的代码。
   • 可扩展性：应该能够轻松地为语言添加新的功能和语法结构，而不需要重写解释器。
     解释器风格的优势在于其灵活性和可定制性。它可以轻松地实现特定的语言特性，并且可以动态地修改和扩展语言。此外，解释器风格的系统通常易于调试和维护。然而，解释器风格的一个缺点是性能。与编译器风格相比，解释器风格的执行速度通常较慢，因为它需要在运行时解释和执行代码。

【优点】
⚫ 功能：可以仿真自身不具有的功能。
⚫ 测试：可以进行测试，模拟“灾难”模式仿真不好的环境释放病毒来测试一些安全软件的功能(例如，安全关键的应用程序)
⚫ 灵活性：具有一定灵活性，是通用的工具。
【缺点】
⚫ 效率：增加了额外的一层，需要将运行的程序转入目标环境在进行运行，因此比硬件和编译好的系统慢的多，效率低
⚫ 测试：既需要测试程序本身的正确性，还需要测试额外虚拟环境，测试过程复杂

2. 规则系统
   Code to be executed (knowledge base)
   Interpretation engine (rule interpreter)
   Control state of interpreter (rule/data selection)
   Current state of the code (working memory)

•要执行的代码(知识库)
•解释引擎(规则解释器)
•解释器的控制状态(规则/数据选择)
•代码的当前状态(工作记忆)

• 许多产品规则系统的大脑实际上就是一个推理引擎，用于匹配事实
（Fact）和规则（Rule）
• 当匹配被找到，规则对应的动作（Action）会被触发（Fire）

【优点】
⚫ 降低了修改业务逻辑的成本
⚫ 缩短开发时间
⚫ 将规则外部化，可在多个应用之间共享
⚫ 对规则的改变将非常迅速并且具有较低的风险
【缺点】
⚫ 效率：增加了额外的一层，需要将运行的程序转入目标环境在进行运行，因此比硬件和编译好的系统慢的多，效率低
⚫ 测试：既需要测试程序本身的正确性，还需要测试额外虚拟环境，测试过程复杂

Data-centered Style

1. 数据为中心的体系结构风格
   Data-centered style architectures involve a shared data source approach to information passing

注册表、剪贴板

【优点】系统开放性高，耦合性低；生产者，消费者，修改这易于动态加入；当生产者，消费者，修改者发生故障时，系统不会受到影响。
【缺点】
⚫ 同步：当中心数据发生改变时，出现控制反转。最初生产者，消费者，修改者主动控制数据，中心数据被动改变，当中心数据修改后，需要告诉生产者，消费者，修改者其数据被改变。
⚫ 配置和管理：外挂注册中心，生产者，消费者，修改者需要先注册配置才能进入系统
⚫ 性能：各生产者，消费者，修改者之间无法直接通信，性能可能较低
⚫ 具有原子性，持久性，一致性的特点

2. 仓库体系结构风格
   components:
   ➢ A central data structure representing the current state; (中心数据结构，表示当前数据的状态)
   ➢ A collection of independent components operate on the central data store. (一组对中心数据进行操作的独立构件)

Connector: Interactions between the repository and its external components.(连接件：仓库与独立构件之间的交互)

Two major mechanisms: (存在两种交互机制)
➢ Database: 数据库方式
➢ Blackboard: 黑板结构

典型应用：数据库、带符号表和语法树的编译器
传统编译器：批处理或者管道

3. 黑板体系结构风格
   ➢ 一个大问题被分解为若干个子问题；
   ➢ 每个子问题的解决需要不同的问题表达方式和求解模型，分别设计求解程序；

全局数据库
解决问题过程中的状态数据，以层次形式组织起来
知识源对黑板进行修改，逐渐找到问题的解
各知识源之间的通讯和交互只通过黑板进行

Control 控制器
➢ 时刻监视黑板状态变化
➢ 对黑板上信息的当前状态进行判断和评价
➢ 当黑板的状态满足了知识源的执行条件时，该知识源被控制器触发并进行计算，然后将结果更新到黑板上
➢ 这种更新又导致其他知识源参与计算并更新黑板，直到找到问题解为止

黑板模型求解问题的推理机构，由监督程序和调度程序组成。
根据当前状态决定知识源的执行次序

知识源：独立的求解程序
每个知识源被组织成条件部分和动作部分

Event System Style

1. 事件

2. 事件系统
   

A component(Event Source) can annonce (or broadcast) one or more events. 一个组件可以广播一些事件。
➢ Other components(Event Handlers) in the system can register an interest in an event by associating a procedure with it. 系统中的其它构件可以注册自己感兴趣的事件，并将自己的某个过程与相应的事件进行关联。
➢ When the event is announced the system (Event Manager) itself invokes all of the procedures that have been registered for the event. 当一个事件被发布，系统自动调用在该事件中注册的所有过程。

事件源、事件管理器、事件处理器

Components of event systems: objects or processes whose interfaces provide both:
✓a collection of procedures (过程或函数，充当事件源或事件处理器的角色)
✓a set of events (事件)

Connectors of event systems : event-procedure bindings
✓ Procedures are registered with events (过程<事件处理器>向特定的事件进行注册)
✓ Components communicate by announcing events at “appropriate” times (构件<事件源>发布事件)
✓ when an event is announced the associated
procedures are (implicitly) invoked (当某些事件被发布时，向其注册的过程被隐式调用)
✓ Order of invocation is non-deterministic (调用的次序是不确定的)

注册、发布、隐式调用、调用次序

应用实例：调试器

事件系统的优缺点：1.优点：为软件重用提供了强大的支持；为改进系统带来了方便；2.缺点：事件的触发者并不知道哪些构件会被这些事件影响，相互保持独立；不能假定构件的处理顺序，甚至不知道哪些过程会被调用；各个构件之间彼此之间无连接关系，各自独立存在，通过对事件的发布和注册实现关联。3.应用实例：调试器中的断点处理；美团平台

优点：
1、问题分解：对象比显式调用更独立，交互策略可以从交互对象中分离出来，为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中
2、系统维护与复用：没有硬连接(静态)名称依赖，所以动态重新配置很容易-简化了系统演化，只需注册新对象就可以使用它们，简化了集成；为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其它构件的接口
3、性能：调用可以并行化
4、健壮性：一个组件的崩溃不会影响其他组件
缺点：
1、语义正确性问题：一个构件触发一个事件时，不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被调用的顺序；可能会出现函数语义问题和环路问题，正确性难以保证
2、数据交换问题：有时数据可能同时背多个事件进行传递，因此，基于事件的系统需要一个共享仓库进行数据的交互，此时系统的全局性能和资源管理存在问题。
3、性能：间接/通信意味着一些性能损失

3. 事件系统调度机制
   Two strategies
   ✓EventManager without a central dispatcher
   module (无独立调度派谴模块的事件管理器)

➢ This module is usually called Observable/Observer (被观察者/观察者).
➢ Each module allows other modules to declare interest in events that they are sending. (每一个模块都允许其他模块向自己所能发送的某些消息表明兴趣)
➢ Whenever a module sends an event, it sends that event to exactly those modules that registered interest in that event. (当某一模块发出某一事件时，它自动将这些事件发布给那些曾经向自己注册过此事件的模块)

✓EventManager with separated dispatcher module
(带有独立派谴模块的事件管理器)
➢ 全广播式(All broadcasting) ：派遣模块将事件广播到所有的模块，但只有感兴趣的模块才去取出事件并触发自身的行为；

➢ 选择广播式(Selected broadcasting) ：
派遣模块将事件送到那些已经注册的模块中。

Software Architecture Modeling and Documents

软件体系结构由一定形式的结构化元素组成，即是构件的集合。包括处理构件、数据构件和连接构件。处理构件负责加工数据，数据构件代表被加工的信息，连接构件则负责组合连接不同的构件。

软件体系结构描述

建立描述文档的基本原则

1. 从读者的角度写（易于查找）
2. 避免不必要的重复
3. 避免歧义（图形语言要有图例）
4. 使用标准组织结构（帮助浏览和查找）
5. 记录理由（记录驳回的备选方案）
6. 保持文档的时效性（但不要太频繁的修改）
7. 审查文档是否符合需求

软件体系结构建模

视图的概念
架构元素：软硬件中存在的实际元素
视图：相关者编写的连贯的架构元素的表示

类型：
分解视图
使用视图
分层视图
类/泛化视图

进程视图
并发视图
共享数据视图
客户端/服务器视图

部署视图
实施视图
工作分配视图

基于视图软件体系结构建模规范

4+1模型：
逻辑视图：支持行为要求（类图、对象图、状态图、协作图）
过程视图：解决并发和分发（活动图）
开发视图：组织开发单元（包图、组件图）
物理视图：映射到处理和通信节点（部署图）
用例视图（场景视图）：把其他视图映射到重要的用例（用例图、描述图、概述图）

UML（Unified Modeling Language，统一建模语言）是一种面向对象的标准化建模语言，用于软件工程的视觉化、规格化、构建和文档化。它提供了一组图形化的符号来表示软件系统的不同视图，包括结构视图和行为视图。

用例图（用例代表了系统的外部视图）
类图（表示了类之间的关系，静态结构的描述）
对象图（实例图，显示对象而不是类）
状态图（对象的所有可能状态）
协作图（对象之间的联系）
序列图（对象交互的一种表现方式，按照交互发生的顺序）
活动图（描述用例执行的活动）
包图（类似于文件夹的符号）
组件图（描述代码构件间的依赖关系）
部署图（软硬件的物理体系结构）
复合结构（分层的将类分为内部结构）
交互概述图（活动图和序列图的结合）
时序图（显示不同对象的时序约束）

Quality Attributes and Tactics

质量属性属于非功能性需求
先实现功能再谈质量属性

刺激源、刺激、制品、环境、响应、响应衡量指标

Availability and its Tactics

Availability = MTBF / (MTBF + MTTR)
MTBF：平均故障间隔时间 MTTR：平均修复时间
定义：当用户使用系统时，系统可用的概率。
关注点：是否故障，故障的后果
衡量指标：可用时间百分比、修复故障需要的时间
刺激源：故障的迹象
刺激：系统出错、系统崩溃、错误结果
制品：计算、存储、网络传输
环境：正常或亚健康
响应：错误报告、关闭系统等
响应衡量指标：故障时间百分比、平均无故障时间

提升可用性的策略：
目标：降低故障造成的影响

1. 故障检测
   ping/echo
   Heartbeat（被监控组件发出心跳消息）
   Exception（抛出+捕获+处理）
2. 故障恢复
   投票（冗余组件完成同一个任务、少数服从多数）
   主动冗余（A和B的状态时刻保持一致）
   被动冗余（一定时间内同步）
   内测
   检查点/回滚

主动冗余： 主动冗余涉及在系统中并行运行多个相同的组件或任务，并且至少有一个组件是活跃的。在主动冗余中，通常会有一个监控机制来检查各个组件的输出，并确保它们一致。如果不一致，系统会采取一定的策略来决定哪个组件的输出是可信的。

优点：

提高了系统的可靠性，因为即使一个或多个组件失败，系统仍然可以继续运行。
通常可以提供更好的性能，因为可以并行处理任务。
系统可以在不中断服务的情况下进行维护和升级。
缺点：

成本较高，因为需要额外的硬件和软件资源。
可能会增加系统的复杂性，因为需要管理多个并行组件。
可能导致资源浪费，因为在正常情况下并非所有组件都处于最大负荷状态。
被动冗余： 被动冗余涉及在系统中包含额外的备用组件，这些组件在主组件失败时才会被激活。在被动冗余中，备用组件通常是关闭的或者处于待机状态，直到需要时才启动。

优点：

成本相对较低，因为备用组件在正常情况下不消耗资源。
系统设计相对简单，因为备用组件在主组件正常工作时不需要参与。
可以提供与主动冗余相当的可靠性，尽管响应时间可能较长。
缺点：

可能会有较长的故障切换时间，因为需要识别故障并激活备用组件。
在备用组件被激活之前，系统可能会经历性能下降或服务中断。
需要定期对备用组件进行测试，以确保它们在需要时能够正常工作。

3. 故障避免
   服务下线
   事务
   进程监控

Performance and its Tactics

性能的含义：
关注点：系统响应时间的速度，和事件的数目和到达模式有关
事件来源：用户、系统内部、系统外部

刺激源：系统内部或系统外部
刺激：事件到来
制品：系统提供的服务
环境：系统处于不同的模式
响应：系统处理到来的事件，可能导致状态的变化
响应衡量指标：处理事件所花的时间、单位时间内处理事件的数目、错误率和丢失率

提升性能的策略：
目的：限定的时间响应事件

1. 资源的需求
   数据量不变，提高计算效率
   减少需要处理的数据量
   限制执行时间
   限制待处理事件队列长度

2. 资源的管理
   利用并发机制
   增加可用资源

3. 资源的仲裁
   先来先服务
   固定优先级调度
   动态优先级

Modifiability and its Tactics

可修改性的含义：
关注点：修改的成本、哪些部分修改、修改的时间、谁来修改
衡量指标：修改完成的时间、人力成本和经济成本

刺激源：谁进行修改（开发者/管理员/用户）
刺激：要进行的具体修改
制品：修改系统的功能
环境：什么时间进行的修改
响应：操作人员理解如何进行修改、进行修改操作、测试、部署
响应衡量指标：时间、成本

提升可修改性的策略：

目标：降低修改的时间和成本

1. 限制修改范围
   模块高内聚低耦合
   考虑到可能发生的修改
   让模块通用
   隐藏信息
   维持接口不变
   限制通信路径
   使用中介
   按需创建实例
   命名服务器

2. 延迟绑定时间
   配置文件
   发布-订阅模式
   多态

Security and its Tactics

安全性的含义：
关注点；合法使用系统的前提下，抵抗系统的攻击
攻击：试图突破系统安全性防护的尝试

刺激源：由人或系统发出的攻击
刺激：对系统的攻击
制品：系统提供的服务或系统中的数据
环境：系统可能处于不同的情况下
响应：合法用户正常使用，拒绝非法用户使用
响应衡量指标：发起攻击的难度，从攻击中恢复的难度

提升安全性的策略：

1. 抵抗攻击：
   用户的证实
   用户的授权
   维持数据的保密性
   减少暴露
   限制访问

2. 检测攻击
   软件和人结合

3. 从攻击中恢复
   恢复状态
   攻击者的识别

Testablility and its Tactics

可测试性的含义：让软件的bug容易被测试出来
验证软件产品和需求规格是否匹配
最小的成本和工作量验证软件的质量

刺激源：开发者、测试人员、用户
刺激：系统开发到达了里程碑、分析、设计、等阶段的结束，或者完成开发
制品：一个设计、一段代码、整个系统
环境：系统处在设计开发部署阶段
响应：理想响应：可以进行测试并观察到结果
响应衡量指标：白盒测试的覆盖率

提升可测试性的策略：

目标：让测试更轻松

1. 黑盒测试
   记录/回放
   把接口和实现分离开
   提供专用的测试路径

2. 白盒测试
   内部监控

Usability and its Tactics

易用性的含义：
关注点：让用户使用软件的难度降低
刺激源：用户
刺激：用户希望学习系统的使用，提高系统使用效率
制品：整个系统
环境：系统处于运行时或者配置时
响应：系统响应用户的要求
响应衡量指标：用户完成任务的时间、

提升易用性的策略：
目标：让用户轻松

1. 运行时策略
   系统猜测用户完成的任务
   系统给用户适当的反馈
   系统给用户一致的体验
   支持撤销操作
2. 设计时策略
   把用户界面和系统其它部分隔离开

Software Architecture Evaluation

Architecture Evaluation

Architecture evaluation is a development life-cycle
activitywherebyseveralstakeholders（项目干系人）
analyze the software architecture together in a
formalorinformal（正式或非正式）processusingan
assessment technique such as scenarios
架构评估是一个开发生命周期
各个利益相关者的活动(项目干系人)
一起分析软件体系结构
正式或非正式(正式或非正式)处理和
评估技术

Scenario-based Architecture Analysis Method (SAAM)
Architecture Trade-off Analysis Method (ATAM)
这是SAAM的后继产品，也得到了广泛的应用。该方法结合了质量属性实用树和
体系结构分析中的质量属性类别。尽管SAAM没有明确地处理质量属性之间的相互作用，但ATAM做到了。因此，权衡是
关于竞争性的质量属性。ATAM是SAAM的专业化，特别关注
可修改性、性能、可用性和安全性。
SAAM Founded on Complex Scenarios (SAAMCS)
Extending SAAM by Integration in the Domain (ESAAMI)
Software Architecture Analysis Method for Evolution and Reusability (SAAMER)
Scenario-Based Architecture Reengineering (SBAR)
Architecture Level Prediction of Software Maintenance (ALPSM )
SoftwareArchitectureEvaluationModel（SAEM）

ATAM

ATAM参与人员：
评估小组
项目决策者
架构涉众

阶段0:此阶段先于技术评估
阶段1:专注于引出细节架构信息和分析

1. The evaluation team presents an overview of the ATAM
2. The customer describes business drivers of the system.
3. Designer presents an overview of the architecture design.
4. Identify core architectural approaches.
5. Identify, prioritize, and refine the most important quality attribute goals by building a utility tree.
   

5、效用树：
（1）、效用树的驱动质量属性是高级节点（通常是性能、可修改性、安全
性和可用性）
（2）、场景是效用树的叶子节点
（3）、（重要性，实现难度）
（4）、输出：特定质量属性的特征描述和优先级排序

每个场景有一个优先级对：（重要度，难易度） 例如：（H，L）表示该场景重要且易实现

Present Architecture
Generate Quality Attribute utility tree.
Scenarios
Use case scenario - Remote user requests a database report via the Web during peak period and receives it
within 5 seconds.
• Growth scenario - Add a new data server to reduce latency in scenario 1 to 2.5 seconds within 1 person-week.
• Exploratory scenario
Half of the servers go down during normal

用例场景—远程用户在高峰期间通过Web请求数据库报告并接收它
5秒之内。
•增长场景-添加一个新的数据服务器，将场景1中的延迟减少到1人2.5秒的一周。
•探索性场景—正常情况下有一半的服务器宕机

6. Evaluation team probes architectural approaches from the point of view of specific quality attributes to identify risks.

Risks, Tradeoffs, Sensitivities, Non-Risks
风险，权衡点，敏感点，非风险点
风险点：是一个潜在的有问题的架构决策；failure
非风险点：是安全的良好架构决策分析，可以提高质量帮助实现目标的决策；e.g.假定消息的到达速率是每秒一次，一次处理的时间小于30ms。如果对一个更高优先级的处理的响应时间要求是1秒钟，此系统可行；
敏感点：是一个或多个组件的属性，对于实现特定的质量属性响应至关重要；e.g. 虚拟专用网络的保密级别可能对加密encryption的位数 bits很敏感；封装encapsulated维护maintain量大modify（小变化产生大影响）
权衡点：是影响多个属性的属性，是多个属性的敏感点；e.g.改变加密级别可能会对安全性security和性能performance产生重大影响

Phase 2: involves a larger group of stakeholders
阶段2:涉及更大的涉众群体
7. Stakeholders generate scenarios using a facilitated brainstorming process.
8. Identify the architectural approaches impacted by the scenarios generated in the previous step.
9. Recapitulate (IE) all the steps of the ATAM
and present the ATAM outputs.

Brainstorm and Prioritize Scenarios

阶段3:主要包括为客户生成最终报告，以及反思评估的质量
和ATAM材料。

ATAM是一种评估体系结构的方法
多质量属性Van有效的策略发现的后果
体系结构决策用于识别趋势的方法，而不是用于执行精确分析的方法