学前说两句
这张是重中之重，你考的是什么，是不是系统架构师，这章节就是软件架构设计，这是最重要的一个章节。跨越综合知识、案例分析、论文三大主线，一定要在这里加大投入，其中质量属性、软件架构风格基本上是案例的第一题，你必须要会的，不会肯定是废了。反正这个章节就是核心，你要是这个z
知识体系
软件架构的概念 架构的介绍
软件架构在需求分析和软件设计范围之间，是软件设计能力强的人负责，用户将需求和软件设计链接起来，比如哪个需求放到哪个某块等等
D不是，软件架构不仅是功能性需求还有非功能性需求（比如服务扩展性等等），而且更加关注的是功能性需求。
软件架构设计与生命周期
需求分析阶段是将需求文档的逻辑模型转变为系统设计的物理模型
构建组装阶段比实现阶段更深一层。实现阶段将设计转化为实际的代码或组件，实现系统的具体功能。构建组件阶段将已实现的各个模块或组件集成在一起，形成一个完整的系统或子系统。
架构描述语言ADL
这里要把ADL的三个基本元素掌握，然后把一些常见的ADL语言掌握，具体语言是什么不用管，这个基本不常见的。
4+1视图
架构是复杂的，要想看懂架构，就要从架构的不同角度来看，就会产生不同的视图，要知道某个关键字描述的是哪些视图
过程视图和进程视图是一样的
基于架构的软件开发方法（ABSD) 概念
这里的概念都是精华，需要了解
质量需求是指并发量，极限响应时间等，所以需要在特定场景中来捕获需求
开发过程
软件重用：架构设计都是构件化，所以很好都可以做重用
递归细化：比如从架构复审到架构设计，架构复审如果发现问题都需要重新设计
架构需求
需求库是指所有的需求的集合，比如你之前做过的系统，都可以在这个需求库中
这里虽然是需求阶段，但是也会标识构件的
架构设计
架构文档化&架构复审
架构规格说明：这个架构的形态是什么样子的
测试：如何测试这个架构是否满足设计的形态
架构实现&架构演化
软件架构风格
数据流风格 (Data Flow)：
- 数据流风格强调数据的流动和处理过程。在这种架构中，数据通过一系列的处理步骤（或称为过滤器）进行转换和传输。
调用/返回风格 (Call/Return)：
- 这种风格是传统的过程化设计，其中主程序调用子程序，子程序执行完成后返回结果给主程序。
独立构件风格 (Independent Components)：
- 独立构件风格强调系统中各个组件的独立性和自主性。每个组件都可以独立地开发、测试和部署。
虚拟机风格 (Virtual Machine)：
- 虚拟机风格模拟了一个虚拟的计算机环境，允许在同一个硬件平台上运行多个不同的操作系统或应用程序。
以数据为中心的风格 (Data-centered)：
- 这种风格强调数据在系统中的核心地位。系统中的各个组件都围绕数据进行操作，数据是共享的且可以被多个组件访问和修改。
数据是数据，处理是处理，是分开的，所以满足高内聚，低耦合的
管道过滤器有点像流式的
管道-过滤器示例
管道是连接过滤器的
调用/返回风格（显式调用）
分层：系统过于复杂，所以考虑分层，将每个层完成自己的工作，但是不是独立的，而是调用，同时获取返回
不同层次之间耦合就不太好了，真正好的分层是TCP/IP模型
独立构件风格（隐式调用）
虚拟机风格
C语言编译出来的机器语言，根据操作系统的不同，会不同
不同操作系统上的虚拟机是不同的
虚拟机风格又分为两种
解释器风格的构成及各部分职能
规则系统风格的构成及各部分职能
以数据为中心【仓库风格】
黑板是中心数据源，黑板系统可以用数据库实现
闭环控制风格
C2架构风格
第二题中。主要是看定义了，所以就是解释器
第二题
集成开发环境;仓库风格
调试过程中：会有事件触发
但因为第三题选隐式调用了，所以第二题选择C
MDA
平台独立模型：不关注语言
平台相关模型：关注语言
PIM和PSM和CODE之间通过转换工具完成，保证不人为处理，这样可以减少很多问题。
软件架构服用
特定领域软件架构(DSSA) 概念
参与人员
比如在线教育领域中，基于在线教育的经验，构建出来一套领域架构，可以给其它进入本行业的公司进行参考复用
建立过程
三层次模型
软件产品线
核心就是在某一个领域内有了积累，然后构建出核心资源库，后面的人在开发的时候，只需要从核心资源库中拿出需要的，然后再此基础上进行开发
软件架构评估 质量属性
质量属性又可以分为开发期质量属性和运行器质量属性
性能
性能的提升有什么样的战术提升架构设计，有三个维度实现
可用性
隐藏接口的意思是，把一些字段私有化，提供标准化的方法
推迟绑定时间：动态绑定
安全性
可修改性
易用性和可测试性
最后一题比较难，关键理解防止99%的黑客攻击，系统中检测攻击指的是系统通过一系列技术手段，识别并判定存在针对自身的恶意行为或异常活动，检测到了就可以防止了
权限控制仅仅是控制，但是无法拦截攻击，无法防止
敏感点权衡点风险点与非风险点
例如一，影响了单一方面，所以是敏感点
二，是可以接受的，可以实现的，所以是非敏感点
三、敏感点关注构建过程中，风险点是设计中，所以是敏感点
四、一个往上走一个往下走，所以是权衡点
改变编码方式影响了两个部分，所以不是敏感点，改变编码会对性能和安全性有两个维度的不同的影响，此时就是权衡，为啥不是风险点呢，是设计中的隐患，这里没有描述设计中
权衡点中质量属性的相关性问题
-表示一个越高，另外一个就越低，权衡就是这样的
+表示一个越高，另外一个就越高
架构评估方法
质量属性场景
这个例子是性能质量属性场景，风险承担者是学员，因为如果系统出现问题，那么学院就无法正常使用了。一个质量属性的场景可以从六个角度来描述
可用性质量属性场景描述
可修改性质量属性场景描述
性能质量属性场景描述
可测试性质量场景描述
易用性质量属性场景描述
安全性质量属性场景描述
基于场景的评估方法 发展流程
SAAM
SAAM 接收问题描述、需求说明、架构描述。然后按照1、2、3、4、5的步骤进行评估
ATAM
ATAM评估架构不评估代码
ATAM只看架构是否满足需求，不看需求是否正确
ATAM还没有到测试环节呢
ATAM的时候很多信息还不是太明确，所以评估还是不太精准的
质量效用树
构件与中间件 基本概念 构建
构建的复用
构件的分类
中间件的分类
构件标准
远程调用CORBA，从客户端的角度，看起来就像是本地一样
软件架构层次 设计理论
这里的三个方面不只是层次软件架构的，而是所有软件架构都具备的影响。
C/S架构与B/S架构
两层：程序的开发都集中在客户的应用程序这里，升级就相当麻烦了
常用层次式架构
中间层：用来做业务的
访问层：用来做数据访问的
分层特别多的情况下，分层架构可能会让应用变得庞大
污水池反模式：从表现层到数据层之间没有业务处理，那么就要考虑设计这么多层有没有意义
表现层 MVC架构风格
MVC存在跨层访问的情况，两两之间都有数据传递
MVP架构风格
可以看到，不在两两相连了
MVVM 架构风格
这里的理念基础是，视图模型只要完成视图和模型的绑定，那么就可以了
富客户端 不要求下载客户端 但是实际使用时，会下载一个临时的客户端来使用，常用的技术就是Ajax、Flex、Bindows、HTML5、小程序
表现层UIP设计思想
除了MVC、MCVP、MVVM之外，在表现层还有一些框架和思想需要我们来了解一下，一种一个是UIP框架，基于UIP框架，可以把表现层进一步的细化，让各个层次有更加明确的目标
UIP框架通过将用户界面组件和用户界面流程组件分离，提高了界面的可维护性和扩展性；而表现层动态生成设计思想则利用XML技术实现了界面的灵活配置和动态生成，增强了界面的适应性和定制化能力。
中间层 业务逻辑层工作流设计
这张图展示的是业务逻辑层工作流设计的架构，其本质意义在于构建一个灵活、可扩展且易于管理的工作流管理系统，以实现业务流程的自动化和高效执行。
一般中间层都是针对某个业务逻辑写死，这里的思想是通过一种可配置的方式来构建中间层
业务逻辑层框架
访问层 数据访问模式
在线访问：一直和数据库进行连接
对象关系映射ORM
数据访问层设计
物联网层
大数据分层架构
基于服务的架构(SOA)
Web Service(WEB服务)
REST(表述性状态转移)
ESB 企业服务总线
服务和服务之间没有连接了，而是通过服务总线进行交互
A访问B，A不需要知道B部署地址，只需要通过总线就可以了，总线自己会找到B
微服务
云计算
云原生
从上云到云中产生的区别
原则的意义在于当满足这些原则的时候，一个云原生应用才是合格的
云远程架构模式是在云原生背景下解决某些问题的方法
Mesh就像一个超级中间件，所有和中间件关联的从中抽离出来，放到Mesh里面
Serverless无服务器机制，任何服务不依赖服务器环境
存储计算是数据和存储相分离
反模式 ：利用云原生来做一些事情的时候，有些问题可能把握不好，那么这些问题应该如何来把握呢?
容器技术
容器为程序提供了一种环境
- Docker：是一个开源的应用容器引擎，允许开发者将应用及其依赖打包到一个可移植的容器中，然后发布到任何流行的Linux机器上。Docker容器基于镜像运行，镜像包含了应用运行所需的所有文件和配置，确保了应用在不同环境中的一致性。
- Kubernetes：是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用。它可以管理大量的容器，并确保它们按照预期的方式运行，提供了服务发现、负载均衡、存储编排、自我修复等一系列功能。
云原生架构下，微服务应该满足的一些约束条件
传统应用部署和云原生应用部署的区别
传统开发和云原生的开发的区别
边缘计算
边缘计算和云计算是协作的关系，可以分为以上类别
大型网站系统架构演化
这是大型网站的目标
大型网站从不同角度涉及到的技术
第1阶段
第2阶段
第3阶段：使用缓存改善网站性能
常见的缓存技术
缓存与数据库的数据一致性问题
读的情况，要回写
写的时候，先写数据库再写缓存，或者删除缓存
Redis分布式存储方案
分布式存储方案有以上三种，哨兵存储方案相对于主动模式来说多了一个可以自动故障切换。
集群模式下如何切片？
集群模式下要考虑集群切分，这里介绍了三种常见方式，分别是客户端、中间件、客户端和中间件，也就是三个地方可以切。假设选择了一种地方了，下面开始介绍，具体怎么切呢？
Redis数据分片方案
Redis 数据类型
Redis数据淘汰算法
淘汰范围中一种是从所有key中淘汰，一种是从过期时间中淘汰，一种是不淘汰
Redis的持久化
Redis常见问题
布隆，不匹配肯定就没有 匹配可能有，这是因为不同的key可能会有相同的hash值。一种改进思想是，一个key计算出来三个hash值，这样就可以尽量降低重复了。
第4阶段：使用服务集群改善网站并发处理能力
集群带来的问题
问题一通过负载均衡解决
问题二是有状态和无状态的问题
负载均衡的引入
在OSI不同层有不同的负载均衡
负载均衡的技术
静态算法不考虑当前的现状，就算你的连接被打爆了，我也照样分配
有状态和无状态的问题
1、4有状态
session共享的方案有三种，第二种在集群很多的时候，是很难来实现的
第5阶段：数据库读写分离
第6阶段：使用反向代理和CDN加速网站响应
CDN是外网
第7阶段：使用分布式文件系统和分布式数据库系统
第8阶段：使用NoSQL和搜索引擎
第9阶段：业务拆分
第10阶段：分布式服务
WEB应用服务器
JWT
比如脉脉认证，会发到邮箱里面一个链接，这个链接就包含这个信息，然后从邮箱里面点击就可以，网站看到一模一样的JWT，就可以认证通过了
这个签名不是加密的，只不过是base64编码的
响应式Web设计
中台
思维导图
质量属性与架构评估思维导图
# 9️⃣ 架构评估 ## ├── 评估目标：非功能设计（质量属性） │ ├── 说明：在架构评估过程中，评估人员关注的是系统的质量属性 │ └── 主要质量属性包括 │ ├── 性能 │ ├── 可靠性 │ ├── 可用性 │ ├── 安全性 │ ├── 可修改性 │ ├── 功能性 │ ├── 可变性 │ └── 互操作性 ## ├── 质量属性 │ ├── 定义：是一个系统的可测量或者可测试的属性，用来描述系统满足利益相关者需求的程度 │ │ └── ISO/IEC 9126标准定义： 软件质量 为"软件系统与明确地和隐含地定义的需求相一致的程度" │ │ │ ├── 运行期质量属性（软件运行阶段关注） │ │ ├── 性能：指软件系统及时提供相应服务的能力（速度、 吞吐量 、持续高速性） │ │ │ ├── 定义：性能是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数 │ │ │ ├── 示例1：机器人在正常运动过程中如果发现前方2米内有人或者障碍物，应在1s内停止并在2s内选择一条新的运行路径 │ │ │ ├── 示例2：数据传递时延不大于1s，并提供相应的优先级管理 │ │ │ ├── 示例3：电子商务企业要求在线交易平台必须在800 ms内完成客户的交易请求 │ │ │ ├── 示例4：实时状态视频传输必须保证画面具有1024×768的分辨率，40帧/秒的速率 │ │ │ └── 性能战术 │ │ │ ├── 资源需求 │ │ │ │ ├── 提供计算效率 │ │ │ │ ├── 减少计算开销 │ │ │ │ ├── 管理事件率 │ │ │ │ └── 控制 采样频率 │ │ │ ├── 资源管理 │ │ │ │ ├── 引入并发（ 多线程 、多进程、异步IO） │ │ │ │ ├── 维持多个副本（数据复制、缓存副本） │ │ │ │ └── 增加可用资源（扩容、增加服务器） │ │ │ └── 资源仲裁 │ │ │ ├── 先进先出（FIFO） │ │ │ ├── 固定优先级 │ │ │ ├── 动态优先级 │ │ │ ├── 静态调用 │ │ │ └── 队列调度 │ │ │ │ │ ├── 安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力 │ │ │ ├── 示例：对机器人的 远程控制 命令应该进行加密，从而能够抵挡恶意的入侵破坏行为，并对攻击进行报警和记录 │ │ │ ├── 安全性组成 │ │ │ │ ├── 机密性：信息不泄漏给未授权用户 │ │ │ │ ├── 完整性：防止信息被篡改 │ │ │ │ ├── 不可否认性：不可抵赖 │ │ │ │ └── 可控性：对信息的传播及内容具有控制的能力 │ │ │ └── 安全性战术 │ │ │ ├── 抵抗攻击 │ │ │ │ ├── 身份验证 │ │ │ │ ├── 用户授权 │ │ │ │ ├── 数据加密 │ │ │ │ ├── 数据完整性 │ │ │ │ ├── 限制暴露 │ │ │ │ └── 限制访问 │ │ │ ├── 检测攻击 │ │ │ │ └── 入侵检测 │ │ │ └── 从攻击中恢复 │ │ │ ├── 识别：审计追踪 │ │ │ └── 恢复：冗余（与可用性重叠） │ │ │ │ │ ├── 易用性：指软件系统易于被使用的程度 │ │ │ ├── 定义：软件系统易于被使用的程度 │ │ │ └── 包含方面 │ │ │ ├── 学习系统特性：用户能够快速学习如何使用系统 │ │ │ ├── 有效使用系统：用户能够高效地完成目标任务 │ │ │ ├── 使错误的影响最低：系统能够帮助用户避免和纠正错误 │ │ │ ├── 适配系统：系统能够适应不同用户的需求和偏好 │ │ │ └── 对系统满意：用户对系统使用体验的满意度 │ │ │ │ │ ├── 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力 │ │ │ ├── 定义：软件系统中，当用户数和数据量增加时，软件系统维持高服务质量的能力 │ │ │ └── 说明：通过增加服务器等资源来提高系统处理能力 │ │ │ │ │ ├── 互操作性：与其他系统交换数据和相互调用服务的难易程度 │ │ │ │ │ ├── 可靠性：在一定的时间内无故障运行的能力 │ │ │ ├── 说明：可靠性是最重要的软件特性，通常用来衡量在规定的条件和时间内，软件完成规定功能的能力 │ │ │ ├── 衡量指标 │ │ │ │ ├── MTTF（Mean Time To Failure）：平均失效等待时间 │ │ │ │ └── MTBF（Mean Time Between Failures）：平均失效间隔时间 │ │ │ └── 定义：可靠性通常用平均失效等待时间（MTTF）和平均失效间隔时间（MTBF）来衡量 │ │ │ │ │ ├── 持续可用性：指系统长时间无故障运行的能力（常纳入可靠性） │ │ │ │ │ ├── 鲁棒性：指软件系统在非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等）下仍能够正常运行的能力 │ │ │ ├── 定义：软件系统在非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等）下仍能够正常运行的能力 │ │ │ └── 说明：也称健壮性或容错性 │ │ │ │ │ ├── 可修改性：指软件系统能够容易地进行修改以适应需求变化、环境变化或修复缺陷的能力 │ │ │ ├── 示例：系统完成上线后，少量的外围业务功能和界面的调整与修改不超过10人·月 │ │ │ ├── 四个方面内容 │ │ │ │ ├── 可维护性：指修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度 │ │ │ │ ├── 可扩展性 ：指软件因适应需求变化而增加新功能的能力（也称灵活性） │ │ │ │ ├── 结构重构：指在不改变系统外部行为的前提下，重新组织系统内部结构的能力 │ │ │ │ └── 可移植性：指将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度 │ │ │ └── 可修改性战术 │ │ │ ├── 局部化修改 │ │ │ │ ├── 维持语义一致性 │ │ │ │ ├── 预期期望的变更 │ │ │ │ ├── 泛化模块 │ │ │ │ ├── 限制可能的选择 │ │ │ │ └── 抽象通用服务、接口实现分离 │ │ │ ├── 防止连锁反应 │ │ │ │ ├── 隐藏信息 │ │ │ │ ├── 维持现有的接口 │ │ │ │ ├── 限制通信路径 │ │ │ │ └── 使用仲裁者 │ │ │ └── 推迟绑定事件 │ │ │ ├── 运行时注册 │ │ │ ├── 配置文件 │ │ │ ├── 多台 │ │ │ ├── 组件更换 │ │ │ └── 遵守已定义的协议 │ │ │ │ │ └── 可用性：系统在一定时间内正常工作的时间所占的比例 │ │ ├── 定义：可用性是指系统或服务在需要时能够正常工作的能力，通常与系统运行的可靠性、故障恢复时间等相关 │ │ ├── 关键指标 │ │ │ ├── 可用时间：系统能够正常运行的时间，通常以百分比表示（如 99.9% 可用性） │ │ │ ├── 可用时间间隔：系统在一段时间内连续可用的时间长度 │ │ │ ├── MTBF（Mean Time Between Failures）： 平均故障间隔时间 ，系统两次故障之间的平均时间 │ │ │ └── 说明：数据延迟时间不属于可用性指标 │ │ ├── 示例1：机器人系统主电源断电后，能够在10s内自动启动备用电源并进行切换，恢复正常运行 │ │ ├── 示例2：网络失效后，系统需要在10秒内发现错误并启用备用系统 │ │ └── 可用性战术 │ │ ├── 错误检测 │ │ │ ├── 命令/响应（ping/Echo） │ │ │ ├── 心跳 │ │ │ └── 异常 │ │ ├── 错误恢复 │ │ │ ├── 表决 │ │ │ ├── 选举 │ │ │ ├── 冗余（主动/被动） │ │ │ │ └── 主动冗余 │ │ │ └── 备件 │ │ └── 错误预防 │ │ ├── 进程监视器（Watchdog）：独立监控进程，定期检查被监控进程健康状态，检测到挂起/崩溃时自动重启或触发 故障转移 │ │ ├── 事务 │ │ └── 从服务器删除 │ │ │ └── 开发期质量属性（软件开发阶段关注） │ ├── 易理解性：指设计被开发人员理解的难易程度 │ ├── 可扩展性：软件因适应需求变化而增加新功能的能力（也称灵活性） │ ├── 可重用性：指重用软件系统或某一部分的难易程度 │ ├── 可测试性：对 软件测试 以证明其满足需求规范的难易程度 │ │ ├── 示例：系统需要为部署在远程PC机上的 智能家居系统 留有控制接口，并支持在智能家居系统中对该系统进行远程错误诊断与调试 │ │ └── 可测试性方法 │ │ └── 记录-回放：捕获真实输入/操作/状态并在测试时精确重现，使测试过程可重复、可自动化、可验证 │ ├── 可维护性：当需要修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度 │ └── 可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度 ## ├── 评估方法 │ │ │ ├── 相关概念 │ │ ├── 敏感点：影响某个质量属性的构件或关系特性 │ │ │ ├── 定义：敏感点是实现一个特定质量属性的关键特征，该特征为一个或多个软件构件所共有 │ │ │ ├── 说明：敏感点是一个或多个构件（和/或构件之间的关系）的特性，该特性对于达到特定的质量属性响应至关重要 │ │ │ ├── 核心理解：实现质量目标时应注意的点，是一个或多个构件的特性。它们的变化可能会显著影响系统的表现 │ │ │ ├── 设计建议：在进行系统架构设计时，设计师应特别关注敏感点，以确保系统的可扩展性 │ │ │ └── 示例 │ │ │ ├── 示例1：系统的 体系结构 对于某个质量属性的影响特别敏感，比如增加可用性需要增加冗余，增加性能需要增加缓存 │ │ │ ├── 示例2：对查询请求处理时间的要求将影响系统的数据 传输协议 和处理过程的设计 │ │ │ ├── 示例3：某系统为提高可用性，在多个 数据中心 部署冗余服务 │ │ │ ├── 示例4：系统需要支持的最大并发用户数量直接影响传输协议和数据格式 │ │ │ └── 示例5：提高加密子系统的加密级别将对系统的安全性和性能都产生非常大的影响（该子系统属于敏感点） │ │ ├── 权衡点：影响多个质量属性的特性，是多个敏感点的交汇点 │ │ │ └── 示例 │ │ │ ├── 示例1：更改系统加密的级别对安全性有所提升但是对性能会降低 │ │ │ ├── 示例2：改变业务数据编码方式会对系统的性能和安全性产生影响 │ │ │ └── 示例3：提高加密子系统的加密级别将对系统的安全性和性能都产生非常大的影响（该子系统属于权衡点） │ │ ├── 风险点：架构设计中潜在的、存在问题的决策，可能带来隐患 │ │ │ └── 示例："绿化报告生成"业务逻辑描述尚未达成共识，可能导致部分业务功能模块规则的矛盾，影响系统的可修改性 │ │ ├── 非风险点：不会带来隐患的架构决策（通常是可接受的要求） │ │ │ └── 示例：某系统采用模块化设计，各模块功能独立且接口清晰，这一设计决策属于非风险点 │ │ │ │ │ └── 场景 │ │ ├── 核心目的：在进行体系结构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准 │ │ ├── 定义：为得出这些目标而采用的机制叫作场景 │ │ ├── 来源：场景是从风险承担者的角度对与系统的交互的简短描述 │ │ │ └── 风险承担者定义：在系统架构评估中，对架构施加各种影响以保证自己目标能够实现的人 │ │ ├── 三要素描述方式：在体系结构评估中，一般采用刺激（Stimulus）、环境（Environment）和响应（Response）三方面来对场景进行描述 │ │ │ ├── 刺激（Stimulus）：到达系统时的条件 │ │ │ ├── 环境（Environment）：该刺激发生的条件，比如系统过载 │ │ │ └── 响应（Response）：激励到达后所采取的行动 │ │ └── 六个构成方面（完整定义） │ │ ├── 刺激源：生成该刺激的实体（人、计算机系统或者任何其他刺激器） │ │ │ ├── 定义：刺激源指的是某个生成该刺激的实体（如人、计算机系统或其他刺激器） │ │ │ ├── 可测试性场景示例：开发人员、增量开发人员、系统验证人员、客户 验收测试 人员、系统用户 │ │ │ ├── 性能场景示例：用户频繁刷新商品页面 │ │ │ └── 可修改性场景示例：最终用户、开发人员、系统管理员 │ │ ├── 刺激：当刺激到达系统时的条件 │ │ │ ├── 定义：刺激是指当刺激到达系统时需要考虑的条件 │ │ │ ├── 可修改性场景示例：系统进行 二次开发 │ │ │ └── 性能场景示例：用户发起高并发请求 │ │ ├── 环境：该刺激发生的条件，比如系统过载 │ │ │ ├── 定义：环境是指该刺激在某些条件内发生 │ │ │ ├── 可用性场景示例：系统内部故障 │ │ │ └── 性能场景示例：数据库 连接池 满载 │ │ ├── 制品：某个制品被激励 │ │ │ ├── 可测试性场景示例：待测试的 源代码 段 │ │ │ └── 可修改性场景示例：需要修改的业务逻辑模块 │ │ ├── 响应：激励到达后所采取的行动 │ │ │ ├── 定义：响应是指在激励到达后所采取的行动 │ │ └── 响应度量：响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试 │ │ ├── 典型响应度量包括 │ │ │ ├── 等待时间（Latency）：从发出请求到收到响应的时间间隔 │ │ │ ├── 吞吐量（Throughput）：单位时间内系统处理的请求数量 │ │ │ └── 抖动（Jitter）：响应时间的变化程度/延迟的波动范围 │ │ └── 说明：错误数量不属于典型的响应度量 │ │ │ ├── 评估方式 │ │ ├── 调查问卷 │ │ │ ├── 通用性：通用 │ │ │ ├── 架构了解程度：粗略了解 │ │ │ ├── 实施阶段：早 │ │ │ ├── 客观性：主观 │ │ │ └── 缺点：很大程度上依赖于评估人员的主观判断 │ │ ├── 检查表 │ │ │ ├── 通用性：特定领域 │ │ │ ├── 架构了解程度：无限制 │ │ │ ├── 实施阶段：中 │ │ │ ├── 客观性：主观 │ │ │ └── 缺点：很大程度上依赖于评估人员的主观判断 │ │ ├── 场景（特定系统） │ │ │ ├── 通用性：特定系统 │ │ │ ├── 架构了解程度：中等了解 │ │ │ ├── 实施阶段：中 │ │ │ └── 客观性：较主观 │ │ └── 度量 │ │ ├── 通用性：通用或特定领域 │ │ ├── 架构了解程度：精确了解 │ │ ├── 实施阶段：中 │ │ ├── 客观性：较客观 │ │ └── 三个基本活动 │ │ ├── 活动1：建立质量属性和度量之间的映射原则 │ │ │ └── 说明：确定怎样从度量结果推出系统具有什么样的质量属性 │ │ ├── 活动2：从软件体系结构文档中获取度量信息 │ │ │ └── 说明：提取架构文档中的相关度量数据 │ │ └── 活动3：根据映射原则分析推导出系统的某些质量属性 │ │ └── 说明：基于映射原则和度量信息进行推理分析 │ │ │ └── 基于场景的评估 │ ├── 过程 │ │ ├── 1. 确定 应用领域 的功能和软件架构的结构之间的映射 │ │ ├── 2. 设计用于体现待评估质量属性的场景 │ │ └── 3. 分析软件架构对场景的支持程度 │ │ │ └── 方法 │ ├── SAAM（软件架构 分析法 ） │ │ ├── 定义：软件架构分析法（SAAM）最初用于分析可修改性，后来扩展到可移植性、可扩展性等，是评估这些属性的最佳选择 │ │ ├── 主要目标：通过程序文档验证体系结构，注重发现潜在问题 │ │ ├── 关注质量属性：可修改性、可移植性、可扩展性等 │ │ ├── 输入 │ │ │ ├── 问题描述 │ │ │ ├── 问题说明 │ │ │ └── 架构描述文档 │ │ └── 分析过程 │ │ ├── 场景开发：体现系统所支持的各种活动 │ │ ├── 架构描述：体现系统的计算构件、数据构件以及构件之间的关系 │ │ ├── 单个场景评估：生成一个关于特定架构的场景描述列表 │ │ ├── 场景交互：分析场景对系统构件的影响 │ │ └── 总体评估 │ │ │ ├── ATAM（架构权衡分析法） │ │ ├── 定义：体系结构权衡分析方法（Architecture Tradeoff Analysis Method，ATAM）是在SAAM的基础上发展起来的，主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中 │ │ ├── 评估形式特点：ATAM并不是一种精确的评估方法，该方法表现的主要形式是 评审会 议 │ │ ├── 主要目标：确定在多个质量属性之间折中的必要性 │ │ ├── 核心理念：整个评估过程强调以属性作为架构评估的核心概念 │ │ ├── 核心工具：效用树（Utility Tree） │ │ │ ├── 结构：树根 → 质量属性 → 属性分类 → 质量属性场景（叶子节点） │ │ │ │ ├── 树根：代表整个系统的整体效用或价值 │ │ │ │ ├── 质量属性：如性能、安全性、可用性、可扩展性等 │ │ │ │ ├── 属性分类：对质量属性进一步细分 │ │ │ │ └── 质量属性场景：具体的、可测量的使用情境 │ │ │ └── 构建步骤 │ │ │ ├── 修剪树枝：保留重要场景（通常不超过50个） │ │ │ ├── 重要性打分：H（高）、M（中）、L（低） │ │ │ ├── 难度打分：H（难）、M（中）、L（易） │ │ │ └── 优先级对：(H,L)优先处理，(L,H)可能放弃 │ │ ├── 主要活动阶段 │ │ │ ├── 场景和需求收集：收集利益相关者的场景和质量需求 │ │ │ ├── 体系结构视图和场景实现：将场景映射到架构视图 │ │ │ ├── 属性模型构造和分析：构建质量属性模型并进行分析 │ │ │ ├── 场景评估：对多个场景进行综合评估 │ │ │ └── 架构决策识别、权衡点分析、 敏感性 点分析 │ │ └── 四个阶段 │ │ ├── 第一阶段：描述和介绍阶段 │ │ │ ├── 职责：负责介绍业务驱动因素和要评估的体系结构 │ │ │ ├── 介绍ATAM：这一步骤主要是向参与者提供ATAM评估过程的一般信息 │ │ │ ├── 描述商业目标：主要关注系统的业务视角 │ │ │ ├── 描述体系结构 │ │ │ │ ├── 体系结构本身（模块、组件、交互） │ │ │ │ ├── 时间可用性 │ │ │ │ └── 质量要求（性能、安全、可维护性等） │ │ │ └── 参与者 │ │ │ ├── 最终用户 │ │ │ ├── 架构师 │ │ │ └── 应用程序开发 人员 │ │ ├── 第二阶段：调查和分析阶段 │ │ │ ├── 标识体系结构步骤 │ │ │ ├── 产生质量属性树（效用树） │ │ │ ├── 分析体系结构步骤 │ │ │ │ ├── 调查架构方法 │ │ │ │ ├── 创建分析问题 │ │ │ │ ├── 分析问题的答案 │ │ │ │ └── 找出风险、非风险、敏感点和权衡点 │ │ │ └── 讨论质量需求的次序（头脑风暴三种场景） │ │ │ ├── 用例场景：最终用户的典型操作流程 │ │ │ ├── 增长场景：代表架构扩展的方式 │ │ │ └── 探索性场景：代表架构中极端的增长形式 │ │ ├── 第三阶段：测试阶段 │ │ │ ├── 原型验证 │ │ │ ├── 模拟测试 │ │ │ └── 压力测试 │ │ └── 第四阶段：报告阶段 │ │ └── 提交结果 │ │ ├── 架构的优势与劣势 │ │ ├── 已识别的风险与权衡点 │ │ ├── 建议的改进措施 │ │ └── 优先级排序后的质量属性场景 │ │ │ └── CBAM（成本效益分析法） │ ├── 定义：CBAM是在ATAM基础上构建的方法，其核心目的是对架构设计决策的成本和收益进行建模，并协助项目 干系人 根据投资回报（ROI）选择最适合的架构策略 │ ├── 核心活动流程 │ │ ├── 步骤1：整理场景 │ │ ├── 步骤2：确定优先级 │ │ ├── 步骤3：分配效用 │ │ └── 步骤4：根据场景优先级和效用分配表计算各架构策略的 总收益 │ └── 说明：在ATAM基础上建立，关注经济模型 ## └── 评估结果分析 └── 识别风险、非风险、敏感点、权衡点
热门跟贴