软件体系结构知识点
软件体系结构知识点分析
前言
题量不大
- 简答题(pipe-and-filter常考)
- 选择题(给定拓扑结构问是哪个style；给UML问是什么UML) ，有五道左右的选择题
- 描述需求选择style；场景；tactics；适合用什么style；效用（调用？）树；敏感点 & 权衡点 & 风险点 等的定义以及划分。
Introduction
考点：
体系结构产生的背景
- 软件体系结构的定义
软件体系结构包括构成系统的设计元素的描述，设计元素之间交互模式，以及在这些模式中的约束，即软件体系结构由组件、连接件和约束组成 Software Architecture = Components + Connectors + Constrains
作用和意义：
- 是风险承担者进行交流的手段
- 是早期设计决策的体现，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性，通过评价软件体系结构，可预测软件的质量
- 是可传承、可重用的模型
体系结构描述语言（ADL）
- ADL是在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。基于底层语义的工具为体系结构的表示、分析、演化、细化、设计过程等提供支持。其三个基本元素是：构件、连接件、体系结构配置
Style设计模式和连接件 组件 约束
考点：
- 优缺点与适用场合
- 给定拓扑结构问是哪个style
- 描述体系结构的风格
- 描述一类体系结构
- 独立于实际问题，强调软件系统中通用组织结构
- 在实践中被多次设计、应用
- 是若干设计思想的综合
- 具有已经被熟知的特性，并且可以复用
- 描述系统组织方式的惯用范例，强调组织方式和惯用范 例。精简为构件/连接件，拓扑和约束
- 给一个架构，为什么可以满足需求，以及为什么该架构的缺点是可容忍的
共性的优点：高内聚，低耦合（可修改性），模块的可修改，重用性【数据流中，基于规则的系统】
可重用、可复制的，一个软件可对应多个style; style之间存在重叠，并非完全独立
data flow数据流系统
数据流：由数据控制计算，系统结构由数据在处理之间的有序移动决定；强调线性；
优点：
- 模块易于替换
- 系统易于维护、理解
缺点：
- 流程基本固定，交互性不强
- 限制了系统的拓扑结构，只能是线性序列
适用场合：适用于数据主导的任务，并且呈现出了明显的数据（线性）关系
组件：处理数据的过程/工序/工具
连接件：数据流（单向的）
batch sequential批处理系统
特点：
每个处理步骤是一个独立的程序；
每一步必须在前一步结束后才能开始（有次序）；
数据必须是完整的，以整体的方式传递
应用：compilers，Computer Aided Software Engineering
pipes & filters管道/过滤器
递增地转化数据，数据“边到来，边处理”，在输入被完全处理之前，输出便产生了
过滤器之间是独立的
优点/特点：
- 使得软件具有良好的隐蔽性和*高内聚、低耦合的特点
- 便于设计者*理解
- 支持功能*模块的重用
- 系统*易于维护和扩展：新的过滤器容易加入到系统中，旧的过滤器也可被改进的过滤器替换
- 支持某些*特定属性的分析，如吞吐量和死锁检测
- 支持多个过滤器的*并发执行，适合多核/多线程环境
- 可将整个系统的I/O出特性理解为各个过滤器功能的简单合成
- 任意两个过滤器只要相互间所传输的数据格式上达成一致，就可以连接在一起
注：理想情况是组件之间只有“数据依赖”
缺点：
- *不适合于交互性很强的应用
- 在数据传输上没有通用的标准，[每个过滤器都增加了解析数据的工作，]导致系统性能的下降，[也会增加编写过滤器的复杂性 （*数据格式转换与映射）]
- 处理两个独立但相关的数据流可能会遇到困难，如*需要处理同步等问题
- 某些filter可能需要大尺寸cache（如排序组件）
- 通常导致进程成为批处理的结构
适用场合：
- Unix Shell
- they permit reuse and reconfiguration of filters
- generally easy to reason about
- reduce system testing
- may allow incremental AND parallel processing
| Batch Sequential | Pipe/Filter |
|---|---|
| total | incremental |
| High latency (real-time is hard) | Results start immediately |
| Random access to input | Processing localized in input |
| No concurrency | Feedback loops possible |
| Non-interactive | Often interactive, awkwardly |
Procedure control
根据系统实际值和目标值而改变，如空调
一个控制持续过程的软件体系结构模式可基于过程控制模型
Set point：受控变量的参考值（理想值）
Sensors：获得控制所需的过程变量值
适用场合
- the task involves continuous action, behavior, changing state
任务包含连续的动作、行为、状态的改变 - when open loop control systems are inadequate 不适合人参与的情况
- software can be reasonably be embedded in a physical system（一般是软硬件结合的系统）
闭环控制器有两种通用形式：反馈控制和前馈控制
- 反馈控制器根据受控变量的测量值来调整过程
- 通过测量其他过程变量，来预计输入变量对被控变量将产生的影响。前馈控制基于这些变量来调整过程。在实际中更有价值
反馈：开车上坡，眼睛紧盯速度表，根据车速的下降来加大油门
前馈：在看到坡以后，还未开始上坡之前，提前加速，使上坡过程顺利。
- the task involves continuous action, behavior, changing state
call/return调用/返回系统
main program & subroutine主/子程序系统
大任务化成子任务，层次性
依据功能分解的编程模型
优点：
*逐步分解，易于调试，易于理解，子程序可复用
*单线程控制
- *子程序正确性受主程序正确性影响
缺点：
*只适用于可以定义为一系列步骤的问题
*子系统结构不清晰
适用场合：能够分层的结构，强调层次的结构
系统模块：层次化地调用和定义
组件：procedures and explicitly visible data 过程和显式可见的数据
连接件：过程调用和数据共享
控制结构：单线程
object oriented面向对象系统
封装（限制对某些信息的访问）、交互（通过过程调用或者类似的协议）、多态（在运行时选择具体的操作）、继承（对共享的功能保持唯一的接口）、复用和维护（利用封装和聚合提高生产力）
优点/特点：
- 对象抽象，使得组件和组件之间的操作以黑箱的方式进行
- 封装性使得细节内容对外部环境得以良好的隐藏，对象之间的访问是通过方法调用来实现的
- 封装完成了相关功能和属性的包装，并由对象来对它们进行管理
- 使用某个对象提供的服务并不需要知道服务内部是如何实现
多线程
易于理解；易于设计
缺点：
- 高耦合，过程调用等进行交互，必须知道对象的标识；如果对象的标识换了，则必须修改所有显式调用它的其他对象，消除由此带来的一些副作用
- 过多的对象难以维护
- 过多的交互难以维护
适用场合：中心问题是识别和保护相关信息，特别是表示信息的应用。现实世界；游戏；教务系统
系统模块：局部状态维护
组件：对象、抽象数据类型
连接件：过程调用
控制结构：分散的，多线程的
layered
优点：
- 大的问题分解为小问题逐步解决，降低了复杂度
- 每一层只为上一层提供服务，使用下一层服务
- 修改一层，最多影响两层
缺点：
- 层层相调，影响性能
- 上层必须知道下层的身份
- 不能调整层与层之间的顺序
- 修改一层可能会导致级联的修改
适用场合：适用于涉及不同类服务的应用程序，并且可以按层次排列。 通常有基本系统级服务的层，适用于许多实用程序，以及应用程序的特定任务。B/S，C/S ，基于.NET平台
系统模块：不透明的层结构
组件：层
连接件：层与层的调用；层与层之间的交互
控制结构：单线程
一般会有客户层，web层（业务层，数据与企业信息集成层）
C/S
基于资源不对等，且为实现共享而提出
有三个主要组成部分：数据库服务器、客户端、网络
缺点：
- 对客户端软硬件配置要求较高，客户端臃肿
- 客户端设计复杂
- 数据安全性不好，客户端程序可以直接访问数据库服务器
- 信息内容和形式单一
- 用户界面风格不一，使用繁杂，不利于推广使用
- 软件维护升级困难，每个客户机上的软件都需要维护
三层C/S，增加了应用服务器，应用功能分为三层：表示层、功能层、数据层
B/S
客户端为浏览器的C/S特例
优点：跨平台；版本升级简单；对客户硬件要求较低
缺点：安全性难以控制；数据查询等响应速度低于C/S体系结构；服务器的负荷大，客户机的资源浪费
服务提供者：提供服务，并进行注册以使服务可用。
服务代理：中介作用，它是服务的注册场所，充当服务提供者和服务请求者之间的媒介
服务请求者：在应用程序中通过向服务代理请求服务，调用所需服务。
data-centered/shared data
数据为中心：数据的增删改查；特点：数据共享
优点：很容易增加数据的生产者和消费者
缺点：
- 同步问题
- 配置和管理
- 原子性
- 一致性
- 持久性
- 性能
适用场合：收集、操作、存储大量的数据；迫切需要数据即时存取
repository仓库
通常需要数据库等特定软件的支持
优点：
- 并行操作，更快的更新速度
- 很容易增加数据的生产者和消费者
缺点：
- 同步问题
- 配置和管理问题
- 原子性问题
- 一致性问题
- 持久性问题
- 性能问题
适用场合：需要建立，扩张和维护一个复杂的数据体，信息能以多种方式操作，数据必须需要长期的持久化，例如：数据库，剪贴板，注册表
系统模块：以数据为中心
组件：共享的内存/存储器和多个纯计算进程/处理器
连接件：计算进程的内存访问、直接数据访问或过程调用
集成多个数据库，在查询/更新操作中，增加过滤器/包装器来匹配不同的视图；但是查询分解和结果合并很难
blackboard
黑板风格是仓库风格的变种，核心是一个以数据为中心的系统，用户只能通过共享的知识存储“黑板”进行交互
黑板属于仓库的变种，黑板的作用相当于共享内存
问题比较复杂，就像有多位不同专长的专家在同一块黑板上交流思想，每位专家都可以利用自己的专长去解决问题
考试时与仓库难以区分，会标出ks(knowledge source)，注意知识源与黑板之间是双向箭头
黑板的状态触发进一步的操作，而仓库操作的执行次序是预先确定的
黑板的组成部分：
知识源(专家)：
知识源之间的通讯只通过黑板来完成，无法与其他知识源交互；
代表整个问题求解中的独立子任务；】
每个知识源被组织成一个条件部分和一个动作部分，条件部分规定什么时候知识源可用；动作部分负责处理相关的黑板元素并产生新的元素
黑板结构数据：知识源相互作用的唯一媒介；全局共享数据，包含域的全部状态
控制(仲裁者)：控制完全由黑板的状态驱动，监控黑板的变化和负责计算的优先次序
特点：
- 没有直接的算法可解，需要多个领域的专门知识协作解决
- 不确定性，数据和解决方法可能错误或者变化，数据中的信噪比、算法会变化
- 没有唯一的答案，正确的答案会变化
优点：
- 可更改性和可维护性
- 可重用的知识源
- 容错性和健壮性
缺点：
- 测试困难
- 不能保证有好的解决方案
- 难以建立好的控制策略，问题解答的不确定性
- 抵效
- 开发困难
- 缺少并行机制
适用场合：
- 适用于解决无确定性策略问题(摸着石头过河)
- 不成熟的领域，其中没有相近的方法
- 在合理的时间内，解空间的完全求解不可行
- 由于领域不成熟，模块应易于替换以便试验
- 对子问题的求解可以有多种方法
- 例如：信号处理，专家系统，模式识别等领域
组件：黑板、知识源、控制（仲裁者）
连接件：调用
解决方案：
- 设计公共数据结构
- 设计多个专用组件，每个组件解决任务的一个特定部分
- 每个组件可以对公共数据结构进行添加、修改、删除
- 仲裁者组件对每个组件的工作结果的进行评估，协调各组件的工作
vitual machine
一种软件，创建了虚拟的环境，屏蔽了底层平台
分类：
系统级(硬件虚拟机)：可以把一台电脑虚拟为运行不同os的多台电脑
进程级(应用程序虚拟机)：JVM
机器聚合：云计算
Interpreter
解释器是用来“执行其他程序的程序”，即程序源代码直接被解释执行（不需编译），浏览器也是典型的解释器
优点：
功能性：可以测试非本机功能
测试：可以模拟一些“故障”模式
灵活：非常通用的工具
缺点：
效率低：比硬件慢，执行速度比编译系统慢
测试：附加软件层需要被验证
适用场合：
- 解释型语言
- 通信协议
- 用户输入
组件：【1+3】 一个状态机（解释引擎）+三个存储区（ 解释器内部状态引擎，被解释执行的程序，程序执行的当前状态）
连接件：对存储区的数据访问和过程调用
控制：状态转移
rule-based system
考试时与解释器不一样，会标出rule
一种特殊的虚拟机，使用模式匹配搜索来寻找规则，并在正确时机应用正确的规则
仍然是1引擎+3存储区的结构【解释引擎+（工作存储器，知识库「规则库，事实库」+规则/数据元素选择器）】
常见的规则：
- 用户界面输入的合法性检查
- 安全规则/权限控制规则
- 业务策略（如VIP折扣策略等）
优点：
降低修改业务逻辑的成本与风险
缩短开发时间
规则可以在多个应用中共享
缺点：
- 难以观察单条规则对整个决策的作用
- 低效的搜索策略；基于规则的大型系统不适用于实时应用
- 没有学习能力，无法打破规则
适用场合：
- 当业务规则很复杂时，不宜用if-else结构表示
- 可变部分多的，需要把可变部分和不变部分分离的
组件：
连接件：
与解释器风格的不同：
- 解释器：在高级程序语言与os/硬件平台间建立虚拟机
- 基于规则的系统：在自然语言/XML规则和高级程序语言间建立虚拟机
independent components
communicating process
组件间相对独立，依靠“发消息”通信
消息长了错误率高，消息短了效率低
This pattern is suiteable for applications that involve a collection of distinct, largely independent computations whose execution should proceed independently. The computations invovle coordination of data or control at discrete points in time. As result, correctness of the system requires attention to the routing and synchronization of the messages.
此模式适用于涉及一系列不同的基本上独立计算的应用程序，这些计算的执行应独立进行。 离散时间点调整数据或控制的协调。系统的正确性需要注意消息的路由和同步。
组件：收发消息的过程
连接件：消息
约束：线程的控制
event systems
Implicit invocation 公众号
事件的触发者不知道哪些构件会被事件影响
当一个事件被宣布时，（隐式）调用相关的程序调用顺序是非确定性的
核心思想：系统分解为多个低耦合的模块
优点：
- 为软件重用提供了强大的支持，当需要一个构件加入现存系统中时，只需将它注册到系统的事件中
- 为改进系统带来了方便，当用一个构件代替另一个构件时，不会影响到其它构件的接口
- 将问题分解了
- 一个构件崩溃之后不会影响其他构件
- 调用可以并行
缺点：
- 构件放弃了对系统计算的控制：一个构件触发一个事件时，不能确定其他构件是否会响应它；无法控制调用的顺序
- 数据交换的问题：在一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互，出现了全局性能和资源管理的问题(递归多次转发导致信息多次发送)
- 过程的语义必须依赖于被触发事件的上下文约束，信息广播的正确性很难保证
- 间接通信可能导致性能的下降
适用场合：频繁变化的系统；涉及于松散耦合组件集合的应用程序
组件：（在不知道信号接收者的情况下）发出重大事件信号的过程
连接件：自动调用已注册对事件感兴趣的进程；事件过程绑定
质量属性&Tactics
考点：
- 给出八个需求，要求判断分别是什么质量属性；一般有两个是功能需求
- 给出质量属性，写出其场景
- 给出tactics（满足特定质量属性的具体设计手段）判断提升了什么质量属性
- 给出质量属性写出两个tactics
QAW(Quality Attributes Workshop)【在软件体系结构创建前使用】
输入：Stakeholders的需求
输出：按优先级排序的质量属性ADD(Attribute-Driven Design method)质量属性驱动的设计方法
质量属性驱动的设计方法（ADD）是一个逐步的方法，用来系统化地为一个系统生成第一个体系结构设计
输入：质量属性需求、功能需求、约束、架构师所掌握的策略与风格
输出：初步设计的体系结构
ATAM(Architecture Tradeoff Analysis Method)质量属性评估
主要任务：对产生的软件体系结构进行评估，判断其是否合理，是否达到我们所希望的目的
输入：软件体系结构和业务需求
输出：绩效树、场景、风险点、非风险点、敏感点和权衡点
质量属性：主要用来描述软件的非功能性需求，主要包括可用性、性能、安全性、可修改性、可测试性和易用性六个方面
非功能性需求；功能特性并不是软件体系结构中唯一要考虑的特性；如果仅考虑功能特性甚至不需要软件体系结构
尽早了解各方涉众的需求和观点，pattern/style和tatics分别处理高层和具体细节
必须结合设计、实现、部署三方面才能满足质量属性
属性之间相互影响，甚至相互抑制
分为：System Quality attribute、Business Quality attribute、Architecture Quality attribute
质量属性场景（描述系统如何对刺激做出反应）分为六个部分:
质量属性场景是用来描述软件质量的方法，是一个具体的质量属性需求，场景就是风险承担者与系统交互的简短陈述
- 刺激源：可以是一些实体，如人，计算机系统或者其他的刺激源
- 刺激：到达系统的刺激是一个需要被考虑的情况
- 制品artifact(指刺激是影响在哪一个部分上的)：某些制品被激发，可能是整个系统或者其中的一部分
- 环境(当前系统处于什么样的状态)：刺激在一定的条件下发生
- 响应/反应：反应是刺激达到后所产生的活动
- 响应/反应测量：当反应发生的时候，必须可被测量，从而需求也可被检测
U-STAMP
易用性usability
- 最终用户容易使用和学习
- 方便用户入门；提高使用效率；降低用户出错造成的影响；让软件适应用户的需求；提高用户的自信和舒适度
- 易用性关注一个用户完成需要的工作的容易程度和系统提供的用户支持的种类，包括：
- 学习系统特性：如果用户对某一特定系统或者系统的特定方面不熟悉，系统应该怎样使得学习变得容易
- 高效地使用系统：系统在帮助用户更高效操作方面能做什么
source of stimulus
终端用户
stimulus
最终用户对有效地使用系统，容易学习使用系统，最小化错误的影响，能够调整系统，对系统感到舒适的希望
artifact
系统
environment
运行时或系统配置时
response
为用户提供所需的功能或预测用户的需求
response measure
通过任务时间，错误数量，解决的问题数量，用户满意度，用户知识获取程度，成功操作与总操作的比率，发生错误时丢失的时间/数据量来衡量
Tactics：仿照现有的工具，和环境统一的界面外观，和工具统一风格的帮助，统一的系统模型，允许用户定制
- 自动存档、网络同步、词语联想
- 运行时策略
- 维护任务模型，系统猜测用户要完成的任务
- 维护用户的模型，确定用户对系统的了解程度，在预期响应时间的行为：网站调整鼠标的滚轮速度
- 维护系统的模型，确定预期的系统行为，以便可以向用户提供适当的反馈：在copy文件时提示预估的剩余时间，浏览器打开页面时显示进度
- 设计时策略
- 模型-视图-控制器
- 表示-抽象-控制
- 将用户界面与业务逻辑分开Seeheim
- Arch/Slinky
安全性security
- 在对合法用户提供服务的同时，阻止未授权用户的使用企图【合法用户可用，非法用户不可用】
- 特点：nonrepudiation(不可否认), confidentiality(机密性), integrity(完整性), assurance(保证性)【–你的成绩单会被确保寄到家长手里】, availability(可用性), and auditing(审计)【银行对每笔转账都有监控，利用数据库log进行恢复】
source of stimulus
人或其他系统（可能已被识别或当前未知）
stimulus
攻击或企图破坏安全的事件（未经授权的人或系统，试图显示信息，更改或删除信息，介入系统服务或降低系统服务的可用性）
artifact
攻击的目标，如系统的服务或数据。
environment
系统的状态（联机/脱机，连接网络/断开网络，防火墙打开/打开网络）
response
授权合法用户并授予他们访问数据和服务的权限，支持授予或撤销访问权限。
拒绝未经授权的用户，拒绝他们访问，并报告未经授权的访问
审计跟踪来引起对惩罚的恐惧（审计跟踪对于纠正成功的攻击也很有用）【ATM机监控摄像】response measuer
增加攻击的难度以及增加从攻击中恢复的能力，如：入侵检测，入侵容忍，多机备份……
Tactics：入侵监测，防火墙，加密，提供最少的入口（用户权限）
- 抵抗攻击
- 验证用户：密码
- 授权用户：经过身份验证的用户有权访问或修改数据或其它服务
- 维护数据的机密性：网银常用https来提高保密性
- 维护完整性：软件公布自己的MD5码防止被篡改
- 限制暴露的信息：关闭无用端口、自启动的服务、无线路由SSID等等
- 限制访问：无线路由设置MAC过滤
- 在外部用户和提供服务的系统之间认证服务器
- 把要保护的系统置于通讯防火墙之后
- 在某个可信内核的基础上构建系统，由该内核提供安全
- 检测攻击
- 通过入侵检测系统（IDS）来检测攻击：将流量模式与已知攻击的历史模式进行比较，必须过滤数据包才能进行比较。。。
- 从攻击中恢复
- 恢复状态：从不一致的状态恢复到一致的状态
- 识别攻击者：保持审计跟踪；审计跟踪=交易副本+识别信息
可测试性testability
- 让软件容易被证明是错的，易于发现错误的能力（不是让软件没有错误）
source of stimulus
单元测试人员，集成测试人员，系统测试人员或客户端执行人员（测试团队与开发团队未必是一组人）
stimulus
开发过程的一个阶段结束（里程碑），可能是分析/设计/编码/集成阶段的结束，或系统完全开发结束
artifact
被测试的部分：设计或一段代码或整个系统
environment
设计时，开发时，编译时或部署时
response
控制系统以执行期望的测试，并且可以观察每个测试的结果
response measure
语句覆盖率
最长测试链的长度（衡量执行测试的难度）
发现其他故障的可能性
Tactics：自检、捕获、回放（playback）、故障注入和报告，一致的错误处理方式
- 黑盒测试
- 记录/重放：半自动化/自动化测试
- 分离实现和接口
- 提供特殊的界面/接口专门用于测试
- 提供输入捕获输出
- 白盒测试
- 内部监控：IDE中设置断点
可用性availability
能长时间正确运行，并可迅速从错误状态恢复到正确状态
关心系统的故障和与故障关联的结果，每周停机维护不算在故障中
可用性是软件质量属性中的一种，它所关心的是系统故障和它所带来的后果
保持系统一直正常运作（24小时监控）也属于可用性的范畴，因为需要预防故障的产生
source of stimulus
内部和外部的故障或故障指示（遗漏、奔溃、超时、无响应、错响应）
stimulus：
组件无法响应输入；组件反复出现错误；组件响应但响应过早或过晚；组件响应的值不正确。
artifact
高可用性所需要的资源，如：处理器，通信通道，进程，存储器
environment
正常或者降级的操作系统
response
记错误日志
通知用户或其他系统
切换到安全模式
关闭外部系统
在修理期间不可用response measure
可用性百分比
指定修复时间
系统必须可用的持续时间Tactics：尽可能地降低“故障”所造成的影响
- 故障检测
- ping/echo：监控组件向关键组件发出ping消息，关键组件收到ping后返回；echo根据是否收到echo消息以及延时长短，来做出反应消息，监控组件
- heartbeat心跳：保持间歇的通信信号（即心跳信号），周期性的检测各个节点的状态
- exceptions异常：异常的抛出、捕获、处理
- 故障恢复
- 表决：多机投票出结果
- 双机热备系统、热重启、主动冗余：A，B服务器运行同样的服务，某一个时刻B坏了，切换到A；备份组件的状态和工作组件的状态是一致的
- 双机备份系统、温重启、被动冗余：A完成运算后，将自己的状态告知B，B才开始更新
- 备件：备份盘
- Shadow操作：内部测试服务器上进行测试，确认无误后再将补丁公开
- 状态再同步：恢复提供服务前的状态
- 检查点/回滚：Word每隔5分钟进行自动保存，出错意外关闭后，重新打开时会提示是否恢复已保存的文档
- 故障预防
- 从服务中移除：惹不起躲得起
- 事务：数据库常用
- 进程监控器：任务管理器关闭程序
可修改性modifiability
关于修改的成本和时间，两个关心的方面：改变什么，什么时候和谁改变
系统会与很多种不同类型的设备进行交互属于可修改性的范畴
source of stimulus
进行更改的人员：开发人员，系统管理员或最终用户
stimulus
希望添加/删除/修改/变更功能、质量属性、容量
artifact
要更改的内容：系统的功能，平台，用户界面，环境或与其互操作的其他系统
environment
何时可以进行更改：设计时间，编译时间，构建时间，启动时间或运行时（修改的时间越迟越不利）
response
进行更改的人必须了解如何修改，然后进行修改，测试，部署（不仅仅是修改）
response measure
时间和成本
Tactics：控制实现、测试和部署更改的时间和成本
- 本地化修改/局部修改
- 维持语义的一致性：尽量把对程序的修改控制在一个模块内；要求程序内的多个模块是高内聚低耦合的，不同模块完成相对单一的功能
- 预计期望的变更：单一职责原则
- 泛化模块：使模块更通用，根据输入可以计算更广泛的功能
- 限制可能的选择：限制选项可以减少修改的影响
- 防止连锁效应：模块间依赖的种类是不同的（语法【参数类型】、语义【参数意义】、顺序、接口、地点【运行时地点和假设一致】、数据的质量、A的存在、A的资源行为）
信息隐藏：选择哪些信息私有以及哪些信息公开
维护现有接口：语法允许可以保持不变（电话订餐，只要电话号码（接口）不发生变化，则搬店不会影响）
控制通信路径：限制给定模块与之共享数据的模块，减少“多对多”的关系，让模块间的数据联系简单化
使用中介
A运行时的位置：IP地址改变，但是还可以通过名称服务器来访问
A的存在：B的行为依赖A的存在
A的资源行为或A控制的资源：由资源管理器来调配资源
- 推迟绑定时间
- 运行时注册：支持即插即用操作，但需要额外的管理注册开销
- 发布/订阅注册：可以在运行时或加载时实现。
- 配置文件：用于在启动时设置参数，可以避免把数据写入代码
- 多态：允许方法调用的后期绑定
- 组件更换：允许加载时绑定
- 遵守已定义的协议：允许独立进程运行时绑定
性能performance
系统的响应时间，硬件资源的占用率，速度
使性能变得复杂的一个因素是事件源的数量和到达模式（周期性的或随机的）
例子：大门开关侦测到有障碍的时候需要立刻停止（一种响应）
source of stimulus
外部（可能是多个）或内部
stimulus
周期事件到达、偶然事件到达、随机事件到达
artifact
系统的服务
environment
各种操作模式，例如正常，紧急或过载
response
处理到达的事件（可能导致系统环境的改变）
response measure
处理事件所花的时间，一定时间内处理事件的个数，处理的错误率/丢失率Tactics：在一定时间限制内生成对到达系统的事件的响应；分而治之，监测与调节，简单的资源申请与释放机制，给予充足的资源；用资源+等资源
- 资源需求：改进关键区域中使用的算法将减少延迟。
- 减少处理一个事件所需要的资源：提高计算效率，减少计算开销
- 减少需要同时处理事件的数量：管理事件的速率（外部生成时间的采样频率），控制采样频率（对排队请求的采样频率，可能导致请求丢失）
- 控制资源的使用：限制执行时间（控制迭代的轮数，绑定队列大小），限制队列大小（例如私家菜馆一天只接受5桌）
- 资源管理
- 引入并发：并发, 多机、多进程、多线程
- 维护数据或计算的多个副本：客户端 - 服务器模式中的客户端是计算的副本
- 增加可用资源：添加硬件
- 资源仲裁
- 先来先服务
- 固定优先级
- 动态优先级调度
循环法：餐馆厨师依次给每一桌客人上一道菜，而不是给一桌彻底做完再开始做第二桌。
最早的截止日期优先：优先级可以动态改变（急诊室根据病人的病情，优先重伤的病人A.但当新来更严重的病人乙时，会优先救治乙） - 静态调度：顺序执行，并且顺序是离线确定，不改变（急诊室根据现有病人情况指定救治顺序，顺序制定后不再变更，就算新来更严重的病人也只能等待现有病人都得到救治后才能施救）
质量评估
- ATAM体系结构折衷分析是一种通过业务驱动，质量属性、情景等方面进行软件体系结构评估的方法，帮助参与者来发现架构设计决策中潜在的问题和风险，预测架构决策和系统属性之间的关系
- ATAM所带来的利益：
- 标示风险
- 阐明质量属性需求
- 改进架构文档
- 为架构决策准备好文档化的基础
- 增加投资者之间的通信
- 其交互过程如下图：
- 从题目的表述当中描述属于一下四个中的某一个
- 风险：可能在将来损害某些质量属性的方案
- 非风险：可以提高质量、帮助实现目标的决策
- 关键点/敏感点sensitivity points：方案中一个小小的变化，就可能对某些质量属性有很大的影响
- 权衡点tradeoffs：影响一个以上质量属性的决策
生成质量属性效率树,给出四点的定义；给出每个涉及什么质量属性；画出效用树
从叶结点开始描绘；主要看质量属性与最后的叶结点对应，其他的就算没有对上也无所谓。
同时叶结点的边应该标上二元组(重要程度，实现难易程度)，每一程度有三类H, M, L，分别表示高中低
- 根Utility/实体
- 第一层结点：质量属性（从叶子开始写，总结）
- 第二层结点：具体细节
- 叶子：题目描述
- 叶子上有二元组
（重要性, 实现难度） - 分别用H,M,L来表示高中低
- Scenario场景
- Use case： 用户常用的场景
- growth：系统可能变化的场景
- Exploratory：计划外（意外，如故障）的场景
- 叶子上有二元组
UML
考点：
大概占十分，给UML问是什么UML
UML中图的区分：用例图以及类图的区分
要做什么事，应该选用什么图
选择适合目标系统的视图（cost, benefit, requires)
每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容
“4+1”视图模型是用于描述软件体系结构的方式，主要用5个不同的视图：逻辑视图、开发视图、进程视图、场景视图、物理视图来描述软件体系结构；每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。
use case view：All of the other views rely on the use case view to guide them that’s why the model
is called 4+1. 用例图
Logical View逻辑视图
- 静态结构
- 类图
- 对象图
- 动态结构
- 状态图
- 协作图
- 序列图
Development view 开发视图
- 静态结构
- 包图
- 组件图
Process View 进程视图
- 动态结构
- 活动图
Physical view 物理视图
- 动态结构
- 部署图
场景视图
- 静态结构
- 用例图
use case view
用例：use case，对系统如何反应外界请求的描述
用例图是用来理解系统的功能性需求的。包含了三部分：actor、system、use case
看系统对外提供了什么“有价值的功能”
Use case diagrams 用例图
要会画图，前面说明人头的这些东西进行信息交互，然后说明要完成的事情；然后画图，注意include和extend
用于显示若干角色以及这些角色与系统提供的用例之间的连接关系。用例是系统提供的功能的描述，用例描述系统对外提供的“价值”；主要给客户看，让客户了解
- Understand the functional requirements of a system
- external view of the system从外部视角来看系统，不关心系统内部
Logical View逻辑视图 静态结构
Describes the abstract descriptions of a system’s parts
系统各部分的抽象描述
Class 类图
表示系统中的类和类与类之间的关系，它是对系统静态结构的描述
类之间的关系有：继承，组合。
每个类在图中有三部分组成：类名、属性、方法
backbone of the UML
Object 对象图
Snapshot of the objects in a system at a point in time描述系统运行时刻的状态；也称 instance diagram
整体是一个树的结构。结点下面有具体的对象。
showing examples of objects connected together
注：和类图区别
State machine 状态图
描述类的对象所有可能的状态以及事件发生时状态的转移条件；通常，状态图是对类图的补充
就是编译原理里面的有限状态机。
活动图与状态图十分相似，唯一的区别在于状态之间的是否存在转移条件(trigger)
- 用于描述一个对象在不同用例中的状态变化
- 不用画所有的类，只需画感兴趣的类，适合UI和控制类对象
Interaction/Communication diagrams协作图、通信图
描述对象间的协作关系，与序列图类似，显示对象间的动态合作关系。
显示对象间的动态合作关系，但强调联系
交互图包含序列图和协作图
Sequence Diagram 序列图
显示对象间的动态协作关系，但强调时间
用来反映若干个对象之间的动态协作关系，即随着时间的推移，对象之间是如何交互的。箭头表示“一个类调用另一个类的方法”。
特别关注先后顺序。
一个用例或者一个业务或者一个功能可以对应一个序列图。如果说用例是黑盒，那么这里就是白盒，指导了应该如何实现功能。
- 序列图描绘了多个对象如何协作来完成一个用例
- 不适合精确定义对象的行为
- 如果想看单独对象在多个用例之间的行为，则使用状态图state machine
- 如果想看多个用例和线程的时候，则使用活动图Activity diagrams
Process View 进程视图 动态结构
系统完成业务的过程
- Activity diagrams 活动图
描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动
很像一个流程图
Development view 开发视图 静态结构
系统各部分是如何组织的
很像计网里面的拓扑结构。定义了系统中软硬件的物理体系结构。
Package 包图
Package is a grouping construct that allows you to take any construct in the UML and group its elements together into higher-level units.
像文件夹一样
Component diagrams 组件图
描述代码构件的物理结构各构件之间的依赖关系
Physical view 物理视图 动态结构
系统的设计是如何对应到实际的
现实世界中的实体（物理层面）
Deployment diagrams 部署图
定义系统中软、硬件的物理体系结构
转载请注明出处，谢谢。
愿 我是你的小太阳
