学前说两句
这张是重中之重，你考的是什么，是不是系统架构师，这章节就是软件架构设计，这是最重要的一个章节。跨越综合知识、案例分析、论文三大主线，一定要在这里加大投入，其中质量属性、软件架构风格基本上是案例的第一题，你必须要会的，不会肯定是废了。反正这个章节就是核心，你要是这个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设计
中台
思维导图
html
├── 1️⃣ 软件架构基础
│ ├── 软件架构概念
│ │ ├── 定义：系统的基础组织形式，体现在其构件、构件之间、与环境之间的关系，以及指导其设计与演化的原则中。
│ │ ├── 主要作用
│ │ │ ├── 软件架构是项目干系人进行交流的手段
│ │ │ ├── 软件架构是可传递和可复用的模型，通过研究软件架构可预测软件的质量
│ │ │ └── 软件架构使得推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础
│ │ └── 架构的本质
│ │ ├── 软件架构为软件系统提供了一个结构、行为和属性的高级抽象
│ │ └── 软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束
│ │ ├── 词汇表：包含构件和连接件类型
│ │ └── 约束：指如何将构件和连接件组合起来
│ ├── 架构知识管理
│ │ ├── 核心：是对架构设计中所隐含的决策来源进行文档化表示，这有助于维护人员理解和改进架构
│ │ └── 公式：架构知识 = 架构设计 + 架构设计决策
│ ├── 架构视图（4+1视图模型）
│ │ ├── 概念：从不同视角描述软件架构，每个视图关注不同利益相关者的关注点，体现了关注点分离的思想
│ │ ├── 注：展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性
│ │ ├── 逻辑视图
│ │ │ ├── 关注：从系统的静态结构和动态行为角度显示系统内部如何实现系统的功能
│ │ │ ├── 内容：对象模型和对象之间的关系
│ │ │ ├── 面向：最终用户、分析人员
│ │ │ └── 表示：类图、对象图、状态图
│ │ ├── 开发视图（实现视图）
│ │ │ ├── 关注：显示源代码以及实际执行代码的组织结构
│ │ │ ├── 面向：开发人员、项目经理
│ │ │ └── 表示：包图、组件图
│ │ ├── 过程视图（处理视图、进程视图）
│ │ │ ├── 关注：显示程序执行时并发的状态
│ │ │ ├── 面向：系统集成人员、性能工程师
│ │ │ └── 表示：时序图、活动图
│ │ ├── 物理视图（配置视图、物理视图、部署视图）
│ │ │ ├── 关注：软件到硬件的映射
│ │ │ ├── 面向：部署人员、运维人员
│ │ │ └── 表示：部署图
│ │ └── 场景视图（用例视图）
│ │ ├── 关注：外部参与者观察到的系统功能
│ │ ├── 作用：将四个视图串联起来，描述视图之间的交互关系
│ │ └── 表示：用例图
│ └── 架构描述语言（ADL）
│ ├── 定义：为软件系统的概念体系结构建模提供具体语法和概念框架的形式化语言。
│ ├── 主要特点：更关注构件间的互联机制（连接子）
│ ├── 常见ADL示例
│ │ ├── C2SADL：基于组件和消息的软件架构描述语言
│ │ ├── Wright：分布、并发类型的架构描述语言
│ │ ├── ACME：架构互换语言
│ │ ├── UniCon：基于组件和连接的架构描述语言
│ │ ├── Rapide：基于事件的架构描述语言
│ │ ├── Darwin、MetaH、Aesop、Weaves、SADL、xADL、C2
│ ├── OMG接口定义语言（IDL）
│ │ ├── 定义：OMG IDL是一种接口定义语言，用于描述分布式对象系统中的接口
│ │ ├── IDL文件包含的六种元素：接口描述、模块定义、类型定义、常量定义、异常、值类型
│ │ ├── 语言映射规则
│ │ │ ├── 模块定义映射为：Java包或C++命名空间
│ │ │ ├── 接口描述映射为：Java类或C++类（操作映射为成员函数）
│ │ │ └── IDL数据类型需与实现语言进行对应映射
│ │ └── 注：IDL本身只是定义接口契约，最终需要与具体编程语言对接实现
│ ├── 三个基本元素：构件、连接件、架构配置
│ └── 补充要素：构件接口
├── 2️⃣ 核心架构风格
│ ├── 什么是架构风格
│ │ ├── 软件架构风格的定义
│ │ ├── 架构风格的核心构成
│ │ ├── 架构风格的作用
│ │ ├── 实践价值
│ │ ├── 经验总结
│ │ └── 注：架构设计并不一定要基于某个特定的架构风格
│ ├── 数据流风格
│ │ ├── 特点概述
│ │ ├── 一、批处理序列
│ │ ├── 二、管道-过滤器架构
│ │ │ └── 典型实例：早期编译器（符号表独立）、网络报文处理、气象数据分析
│ │ ├── 优点：高内聚低耦合、重用性/可维护性好、可扩展、支持并行
│ │ └── 缺点：交互性较差、复杂性高、性能较差
│ ├── 调用/返回风格
│ │ ├── 主要思想：分而治之
│ │ ├── 交互方式：显示调用
│ │ ├── 子风格：主程序/子程序、面向对象、分层架构
│ │ └── 典型实例：银行ATM、医疗诊断系统、导弹弹道计算
│ ├── 独立构件风格
│ │ ├── 构件：独立的命名过程
│ │ ├── 连接件：消息传递
│ │ ├── 子风格：进程通信、事件驱动系统（隐式调用）
│ │ ├── 隐式调用特点：触发者不知道哪些构件会被事件影响
│ │ ├── 优点：松耦合、重用性/可修改性/可扩展性好
│ │ └── 典型实例：Windows图形界面、机器人远程任务、IDE环境
│ ├── 虚拟机风格
│ │ ├── 构件：虚拟机（解释器/规则引擎）
│ │ ├── 子风格：解释器、规则系统
│ │ ├── 优点：可以灵活应对自定义场景
│ │ ├── 缺点：复杂度较高
│ │ └── 典型实例：Java虚拟机、Web服务组合、机器人清洁任务
│ ├── 以数据为中心风格
│ │ ├── 核心共同特点：中央数据结构
│ │ ├── 子风格：数据库系统（仓库风格）、黑板系统、超文本系统
│ │ ├── 数据库系统典型实例：IDE、现代编译器（分析树作为共享数据）
│ │ ├── 黑板系统：知识源、黑板、控制机制，适用于语音识别、同声传译等
│ │ └── 超文本系统：节点、锚点、链接
│ ├── 闭环控制架构（过程控制）
│ │ ├── 构件：传感器、控制器、执行器、过程
│ │ ├── 连接件：反馈回路、控制信号
│ │ └── 典型应用：空调自动调温器
│ ├── C2风格
│ │ ├── 构件和连接件有顶部和底部，严格层次连接
│ │ └── 典型实例：大型在线游戏系统
│ └── 分布性问题与代理模式
│ ├── 定义：强调系统或构件在分布环境中相互通信的方式
│ ├── 两个核心元素：实体间连接方式、实体间通信的特性
│ ├── 常见解决方案：代理（Proxy）模式
│ └── 典型范例：CORBA是代理模式的一个范例
├── 3️⃣ 典型应用架构
│ ├── 层次架构
│ │ ├── 两层C/S（胖客户端-数据库）
│ │ ├── 三层C/S（瘦客户端-应用服务器-数据库）
│ │ ├── 三层B/S（浏览器-WEB服务器-数据库）
│ │ ├── 通用层次划分：表现层（MVC/MVP/MVVM）、中间层、访问层、数据层
│ │ └── 物联网分层架构（IoT）：感知层、网络层、平台层、应用层
│ ├── 面向服务架构（SOA）
│ │ ├── 核心：服务是业务需求的逻辑组合
│ │ ├── 服务内部结构：接口层、逻辑层、数据访问层
│ │ ├── 关键技术：UDDI、WSDL、SOAP、REST、ESB
│ │ └── ESB：实现服务请求者与提供者解耦
│ ├── 微服务架构
│ │ ├── 特点：很小的服务，面向对象架构的一种
│ │ ├── 模式方案：聚合器、链式、数据共享、异步消息传递
│ │ ├── 与SOA对比：去中心化、纵向拆分、无ESB、细粒度
│ │ └── 服务化架构实践要点
│ │ ├── 粒度划分：以应用模块为颗粒度
│ │ ├── 接口契约：以IDL定义业务关系
│ │ ├── 标准协议：HTTP、gRPC等
│ │ ├── 领域驱动设计（DDD）
│ │ ├── 测试驱动开发（TDD）
│ │ └── 容器化部署
│ ├── 云计算架构风格
│ │ ├── 第一层：云计算（SaaS/PaaS/IaaS，公有/私有/混合云）
│ │ ├── 第二层：云原生架构（服务化、弹性、可观测、韧性、自动化、零信任）
│ │ └── 第三层：容器技术（Docker、Kubernetes、Pod）
│ └── 边缘计算
│ ├── 定义：在数据源头侧提供计算、存储、网络服务
│ ├── 类型：云边缘、边缘云、边缘网关
│ └── 边云协同：资源协同、数据协同、智能协同、应用管理协同、业务管理协同、服务协同
├── 4️⃣ 特定领域软件架构（DSSA）
│ ├── 定义：以特定问题领域为对象，形成领域参考模型、参考需求、参考架构等开发基础架构
│ ├── 特征：领域性、普遍性、抽象性和可复用性
│ ├── 经验总结：DSSA是软件体系结构设计经验总结与重用的主要技术手段
│ ├── 从功能覆盖范围理解领域的含义（两种方法）
│ │ ├── 垂直域：定义特定系统族，导出通用软件架构，聚焦行业特性
│ │ └── 水平域：定义多系统功能区域的共有部分，聚焦各行业共性
│ ├── 基本活动
│ │ ├── 核心流程：领域分析 → 领域设计 → 领域实现
│ │ ├── 领域分析：获得领域模型
│ │ ├── 领域设计：获得DSSA
│ │ ├── 领域实现：开发和组织可重用信息
│ │ ├── 领域工程：建立基本能力与必备基础
│ │ ├── 领域模型：反映深层次领域知识
│ │ └── 目标：构建既有深度又有广度的可复用软件架构
│ ├── 领域分析机制
│ │ ├── 领域专家：关注业务/应用领域真实需求
│ │ ├── 领域分析人员：控制分析过程，进行知识获取
│ │ ├── 领域设计人员：设计可复用架构
│ │ └── 领域实现人员：关注编码、组装、测试、部署
│ ├── 三层次模型
│ │ ├── 领域开发环境
│ │ ├── 领域特定的应用开发环境
│ │ └── 应用执行环境
│ └── 建立过程（螺旋模型）
│ ├── 阶段一：定义领域范围
│ ├── 阶段二：定义领域特定的元素
│ ├── 阶段三：定义领域特定的设计和实现需求约束
│ ├── 阶段四：定义领域模型和架构
│ ├── 领域分析：识别边界、共性需求和可变点
│ ├── 领域设计：定义架构、构件和连接件
│ ├── 领域实现：开发构件和框架
│ └── 应用开发：基于领域架构开发具体应用
├── 5️⃣ 软件产品线
│ ├── 定义：产品集合，共享公共可管理的特征集
│ ├── 核心组成：核心资源 + 产品集合
│ ├── 核心特点：过程驱动、特定领域、以技术支持、以架构为中心
│ ├── 过程模型：双生命周期模型、SEI模型、三生命周期模型
│ ├── 核心活动：核心资产开发、产品开发
│ ├── 组织结构类型：独立核心资源小组、非独立、动态结构
│ ├── 应用场景：产品线演化
│ ├── 与DSSA的关系：DSSA是产品线开发的技术基础
│ ├── 实施成功条件
│ │ ├── A. 对该领域产品开发具备长期积累的深入经验（必要条件）
│ │ ├── B. 建立好的核心资源库以支持更高程度的过程规范（必要条件）
│ │ ├── C. 创建稳定可靠的产品线架构以及将架构作为产品蓝图的能力（必要条件）
│ │ └── D. 产品线更强调的是在软件资源、人员组织和过程等方面获得良好的管理支持
│ └── 产品配置
│ ├── 定义：基于核心资产生成具体产品的过程
│ ├── 核心要素：配置知识、配置工具、配置产物
│ ├── 配置方式：编译时配置、部署时配置、运行时配置
│ └── 典型技术：Helm、Kustomize、Spring Cloud Config、Apollo、Feature Toggle
├── 6️⃣ 基于架构的软件设计（ABSD）
│ ├── 以架构为核心的开发方法概述
│ │ ├── 核心理念：架构用来激发和调整设计策略
│ │ ├── 视图作用：不同的视图用来表达与质量目标有关的信息
│ │ ├── 过程特点：架构设计是一个迭代过程
│ │ ├── 初期关键：选择合适架构风格是首要的
│ │ ├── 目标建立：通过架构模型获得属性理解，为演化建立目标
│ │ └── 定位：ABSD的核心思想体现
│ ├── 1. ABSD与传统软件设计的区别
│ ├── 2. ABSD的开发过程
│ │ ├── 基础介绍：支持软件重用，自顶向下递归细化
│ │ ├── 架构需求过程
│ │ ├── 架构设计过程
│ │ ├── 架构文档化
│ │ ├── 架构复审
│ │ ├── 架构实现过程
│ │ └── 架构演化过程
│ ├── 3. 架构需求过程
│ │ ├── 需求获取
│ │ ├── 来源：系统质量目标、商业目标、开发人员商业目标
│ │ ├── 标识构件：生成类图→分组→打包成构件
│ │ └── 需求评审
│ ├── 4. 架构设计过程
│ │ ├── 1. 提出架构模型（选风格）
│ │ ├── 2. 映射构件
│ │ ├── 3. 分析构件相互作用
│ │ ├── 4. 产生构件
│ │ ├── 5. 设计评审
│ │ └── 注：多视图表示属于设计阶段
│ ├── 5. 架构文档化
│ │ ├── 输出：体系结构规格说明、质量设计说明书
│ │ ├── 核心价值：文档完整性和质量是关键
│ │ ├── 三大注意事项：从使用者角度编写、分发给开发人员、保持稳定性
│ │ └── 软件结构化设计
│ │ ├── 定义：包括体系结构设计、接口设计、数据设计和过程设计
│ │ ├── 体系结构设计：定义各主要部件之间的关系
│ │ ├── 数据设计：将模型转换成数据结构定义
│ │ ├── 接口设计：软件内部、软系统之间、人机通信
│ │ └── 过程设计：确定算法及内部数据结构，选定过程表达形式
│ ├── 6. 架构复审
│ │ ├── 目的：识别潜在风险，及早发现缺陷
│ │ ├── 复审内容：架构能否满足需求、质量体现、层次清晰、构件划分等
│ │ └── 参与人员：用户代表、领域专家
│ ├── 7. 架构实现过程
│ │ ├── 输入：复审后的体系结构说明书
│ │ ├── 过程：分析与设计→构件实现→构件组装→系统测试
│ │ └── 输出：可运行的软件系统
│ └── 8. 架构演化过程
│ ├── 输入：需求变化归类
│ ├── 配置管理：记录产品演化过程
│ ├── 过程：演进计划→构件变动→更新相互作用→组装与测试→技术评审
│ └── 输出：演化后的架构
├── 7️⃣ 属性驱动的软件设计方法（ADD）
│ ├── 定义：属性驱动的软件设计方法（ADD）
│ └── 主要输入：质量属性场景
├── 8️⃣ 模型驱动架构（MDA）
│ ├── 定义：由OMG提出的软件开发框架，以模型为中心
│ ├── 核心理念：将业务逻辑与技术实现分离
│ ├── 核心模型
│ │ ├── CIM（计算无关模型）：关注业务领域、业务流程、业务规则
│ │ ├── PIM（平台无关模型，实现无关）：独立于任何实现技术
│ │ └── PSM（平台相关模型）：为特定技术量身定做
│ └── 转换流程：PIM → PSM → CODE
├── 9️⃣ 架构评估
│ ├── 评估目标：非功能设计（质量属性）
│ ├── 价值模型
│ │ ├── 定义：用于分析需求、价值和环境影响的三种基本形式
│ │ ├── 价值期望值：表示对特定功能的需求，包括内容、满意度和实用性
│ │ ├── 反作用力：实现某种价值期望值的难度
│ │ └── 变革催化剂：导致价值期望值发生变化的事件
│ ├── 质量属性
│ │ ├── 运行期质量属性：性能、安全性、易用性、可伸缩性、互操作性、可靠性、鲁棒性、可修改性、可用性等
│ │ └── 开发期质量属性：易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性
│ ├── 评估方法
│ │ ├── 相关概念：敏感点、权衡点、风险点、非风险点、场景
│ │ ├── 评估方式：调查问卷、检查表、场景、度量
│ │ └── 基于场景的评估
│ │ ├── SAAM（软件架构分析法）：最早，关注可修改性、可移植性
│ │ ├── ATAM（架构权衡分析法）
│ │ │ └── 核心工具：效用树（树根→质量属性→属性分类→场景）
│ │ └── CBAM（成本效益分析法）
│ │ ├── 定义：在ATAM基础上建立，关注经济模型
│ │ └── 步骤说明
│ │ ├── 第1步：整理场景
│ │ ├── 第5步：形成"策略-场景-响应级别"对应关系
│ │ ├── 第6步：使用内插法确定期望效用
│ │ ├── 第7步：计算各架构策略的总收益
│ │ └── 第8步：根据受成本影响的ROI选择架构策略
│ └── 评估结果分析：识别风险、非风险、敏感点、权衡点
├── 🔟 构件与中间件
│ ├── 构件
│ │ ├── 定义
│ │ ├── 原子构件：最小组成单元（模块+资源）
│ │ ├── 构件、对象、模块对比
│ │ ├── 构件标准
│ │ │ ├── CORBA（公共对象请求代理体系结构）
│ │ │ │ ├── 定义：OMG组织制定的分布式对象计算标准
│ │ │ │ ├── 本质：代理模式
│ │ │ │ ├── 核心组件
│ │ │ │ │ ├── 伺服对象（Servant）：CORBA对象的真正实现，负责完成客户端请求
│ │ │ │ │ ├── 对象适配器：屏蔽ORB内核细节，提供抽象接口
│ │ │ │ │ ├── 对象请求代理（ORB）：解释调用并查找实现对象，客户方无需了解细节
│ │ │ │ │ ├── 客户端存根（Stub）
│ │ │ │ │ ├── 服务端框架（Skeleton）
│ │ │ │ │ └── IDL（接口定义语言）
│ │ │ │ ├── 工作流程：客户端调用存根→ORB定位服务→骨架接收请求→调用服务→返回
│ │ │ │ └── 特点：平台无关、语言无关、支持分布式异构环境
│ │ │ ├── J2EE（Java 2 Platform Enterprise Edition）
│ │ │ │ ├── 定义：Java平台企业版
│ │ │ │ ├── EJB：会话Bean、实体Bean、消息驱动Bean
│ │ │ │ ├── 特点：跨平台、企业级服务、容器管理
│ │ │ │ └── 基于JavaEE平台集成遗产系统的关键技术
│ │ │ │ ├── JDBC：关系型数据库集成
│ │ │ │ ├── JCA：企业信息系统（EIS）集成
│ │ │ │ ├── Java IDL：CORBA对象集成
│ │ │ │ └── JMS：异步通信（非遗产集成首选）
│ │ │ └── DNA 2000：Microsoft分布式互联网应用架构
│ │ ├── 构件分类：独立成熟、有限制、适应性、装配、可修改
│ │ └── 构件复用
│ │ ├── 复用过程：检索与提取、理解与评价、修改、组装
│ │ └── 组装失配问题：构件、连接子、全局假设冲突
│ └── 中间件
│ ├── 定义：独立系统软件，帮助分布式应用共享资源
│ ├── 本质：中间件是一类构件
│ └── 采用优点：面向需求集中业务逻辑、设计实现隔离、隔离复杂系统资源、提供标准交互模型、支持复用、提供管理
├── 1️⃣1️⃣ 软件架构复用
│ ├── 定义：多次开发过程中重复使用相同或相似软件元素
│ ├── 软件元素：需求文档、设计、代码、测试用例、领域知识
│ ├── 一般形式：函数、库、类、接口、包
│ ├── 历史发展：函数库→类库→构件库→服务库
│ ├── 复用过程
│ │ ├── 1. 构造/获取可复用资产
│ │ ├── 2. 管理资产（构件库、分类、检索）
│ │ └── 3. 选择可复用部分
│ ├── 可复用资产范围：需求、架构设计、元素、测试、规划等
│ ├── 复用类型：机会复用、系统复用
│ └── 复用维度：水平复用（通用）、垂直复用（特定行业）
├── 1️⃣2️⃣ 现代架构演化与支撑技术
│ ├── 软件架构演化和定义的关系
│ │ ├── 定义SA={组件，连接件，约束}，演化关注三要素的增删改
│ │ ├── 演化类型：设计时演化、运行前演化、有限制运行时演化、运行时演化
│ │ └── 演化步骤：需求变化归类→计划→构件变动→更新相互作用→组装测试→评审
│ ├── 面向对象软件架构演化过程
│ │ ├── 设计模型：包图、交互图、类图、状态图、活动图
│ │ ├── 复合片段：alt、loop、opt等
│ │ └── 演化操作：FCC、AO操作等
│ ├── 大型网站架构演化（十个阶段）
│ │ ├── 第一阶段：单体架构
│ │ ├── 第二阶段：垂直架构（应用与数据库分离）
│ │ ├── 第三阶段：使用缓存（MemCache、Redis）
│ │ ├── 第四阶段：服务集群（负载均衡）
│ │ ├── 第五阶段：数据库读写分离
│ │ ├── 第六阶段：反向代理和CDN
│ │ ├── 第七阶段：分布式文件系统和分布式数据库
│ │ ├── 第八阶段：NoSQL和搜索引擎
│ │ ├── 第九阶段：业务拆分
│ │ └── 第十阶段：分布式服务
│ ├── 大数据分层架构：采集→存储→处理→分析→应用
│ ├── 响应式Web设计：流式布局、弹性化设计、响应式图片
│ └── 中台：业务中台、数据中台、技术中台
├── 1️⃣3️⃣ 软件文档
│ ├── 用户文档：功能描述、安装文档、使用手册、参考手册、操作员指南
│ └── 系统文档：从问题定义到验收测试计划的系列文档
├── 1️⃣4️⃣ 形式化规格说明语言：Z语言
│ ├── 概述与定位
│ │ ├── Z语言是基于"状态-操作"风格的形式化规格说明语言
│ │ ├── 用途：精确描述状态、操作及约束
│ │ └── 地位：与VDM、B方法并列
│ ├── 语言基础
│ │ ├── 数学基础：集合论、数理逻辑
│ │ ├── 类型系统：强类型
│ │ └── 表示风格：模式（Schema）为核心
│ ├── 核心构造：模式（Schema）
│ │ ├── 定义：带名字的框，含声明和谓词
│ │ ├── 组成：变量声明、谓词
│ │ ├── 组合：Δ/Ξ约定、继承、模式运算
│ │ └── 示例：状态模式、操作模式
│ ├── "状态-操作"风格特征
│ │ ├── 显式建模系统状态和状态变化
│ │ ├── 操作语义：输入`?`、输出`!`、旧状态、新状态`'`
│ │ └── 优势：无歧义、可推理、支持形式化验证
│ ├── 可读性与工具支持
│ │ ├── 自然语言融合
│ │ ├── 工具：Z/EVES、Fuzz、ProofPower、LaTeX宏包
│ │ └── 与ADL互补使用
│ ├── 应用实例：IBM CICS、伦敦地铁信号系统、安全关键系统
│ └── 优缺点：精确可证明但学习曲线陡峭、数学背景要求高
├── 1️⃣5️⃣ 新旧系统转换
│ ├── 概述：从旧架构迁移至新架构
│ ├── 转换策略与模式
│ │ ├── 一次性切换（Big Bang）
│ │ ├── 增量切换（Strangler Fig Pattern，绞杀者模式）
│ │ ├── 双轨运行（Parallel Running）
│ │ └── 适配器/防腐层模式（Anti-Corruption Layer）
│ ├── 数据迁移
│ │ ├── 数据清洗、映射
│ │ ├── 方式：全量迁移、批量分片、实时同步（CDC）
│ │ └── 数据校验
│ ├── 流量切换与发布策略
│ │ ├── 金丝雀发布（Canary）
│ │ ├── 灰度发布（Gray Release）
│ │ ├── A/B测试
│ │ └── 回滚机制
│ ├── 转换过程的关键活动
│ ├── 常见挑战与应对
│ └── 典型工具与技术：DataX、Flink CDC、Nginx灰度、SkyWalking、Apollo
├── 1️⃣6️⃣ 传统软件工程方法学------结构化设计（SD）
│ ├── 定义：采用结构化设计方法，从工程管理角度分为两步
│ ├── 第一步：概要设计
│ │ ├── 任务：将软件需求转化为数据结构和软件系统结构
│ │ └── 输出：系统模块结构图、数据字典
│ └── 第二步：详细设计
│ ├── 任务：过程设计，通过对结构细化，得到软件详细数据结构和算法
│ └── 输出：详细设计说明书、算法流程图、伪代码等
├── 1️⃣7️⃣ 面向对象设计中的三种类（构造型）
│ ├── 定义：UML中的三种构造型，用于不同职责的建模
│ ├── 实体类（Entity Class）
│ │ ├── 定义：对必须存储的信息和相关行为建模
│ │ ├── 用途：保存和更新事件、人员或现实对象信息
│ │ └── 特点：永久性，属性和关系长期需要
│ ├── 边界类（Boundary Class）
│ │ ├── 定义：对系统外部环境与内部运作之间的交互建模
│ │ ├── 交互内容：转换事件、记录系统表示方式变更
│ │ ├── 常见边界类：窗口、通信协议、打印机接口、传感器、终端
│ │ └── 其他作用：帮助获取非面向对象的API接口（如遗留代码）
│ └── 控制类（Control Class）
│ ├── 定义：对一个或几个用例特有的控制行为建模
│ ├── 特点：控制其他对象，行为具有协调性质
│ └── 作用：将用例的特有行为进行封装
└── 1️⃣8️⃣ 面向对象分析（OOA）与设计模型（OOD）
├── 定义与关系
│ ├── OOA：运用面向对象方法进行需求分析，建立分析模型
│ └── OOD：将分析模型转换为设计模型（第1️⃣7️⃣章三种类是设计模型的重要组成部分）
├── 面向对象分析模型（OOA模型）
│ ├── 1. 顶层架构图
│ ├── 2. 用例与用例图
│ └── 3. 领域概念模型（领域模型）
├── 面向对象设计模型（OOD模型）
│ ├── 1. 以包图表示的软件体系结构图
│ ├── 2. 以交互图表示的用例实现图（顺序图/协作图）
│ ├── 3. 完整精确的类图
│ ├── 4. 针对复杂对象的状态图
│ └── 5. 用以描述流程化处理过程的活动图
└── 注：分析模型关注问题域（做什么），设计模型关注解域（怎么做）
html
### 软件架构设计
├── 1️⃣ 软件架构基础
│ ├── 软件架构概念
│ │ ├── 定义：系统的基础组织形式，体现在其构件、构件之间、与环境之间的关系，以及指导其设计与演化的原则中。
│ │ ├── 主要作用
│ │ │ ├── 软件架构是项目干系人进行交流的手段
│ │ │ ├── 软件架构是可传递和可复用的模型，通过研究软件架构可预测软件的质量
│ │ │ └── 软件架构使得推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础
│ │ └── 架构的本质
│ │ ├── 软件架构为软件系统提供了一个结构、行为和属性的高级抽象
│ │ └── 软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束
│ │ ├── 词汇表：包含构件和连接件类型
│ │ └── 约束：指如何将构件和连接件组合起来
│ ├── 架构知识管理
│ │ ├── 核心：是对架构设计中所隐含的决策来源进行文档化表示，这有助于维护人员理解和改进架构
│ │ └── 公式：架构知识 = 架构设计 + 架构设计决策
│ ├── 架构视图（4+1视图模型）
│ │ ├── 概念：从不同视角描述软件架构，每个视图关注不同利益相关者的关注点，体现了关注点分离的思想
│ │ ├── 注：展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性
│ │ ├── 逻辑视图
│ │ │ ├── 关注：从系统的静态结构和动态行为角度显示系统内部如何实现系统的功能
│ │ │ ├── 内容：对象模型和对象之间的关系
│ │ │ ├── 面向：最终用户、分析人员
│ │ │ └── 表示：类图、对象图、状态图
│ │ ├── 开发视图（实现视图）
│ │ │ ├── 关注：显示源代码以及实际执行代码的组织结构
│ │ │ ├── 面向：开发人员、项目经理
│ │ │ └── 表示：包图、组件图
│ │ ├── 过程视图（处理视图、进程视图）
│ │ │ ├── 关注：显示程序执行时并发的状态
│ │ │ ├── 面向：系统集成人员、性能工程师
│ │ │ └── 表示：时序图、活动图
│ │ ├── 物理视图（配置视图、物理视图、部署视图）
│ │ │ ├── 关注：软件到硬件的映射
│ │ │ ├── 面向：部署人员、运维人员
│ │ │ └── 表示：部署图
│ │ └── 场景视图（用例视图）
│ │ ├── 关注：外部参与者观察到的系统功能
│ │ ├── 作用：将四个视图串联起来，描述视图之间的交互关系
│ │ └── 表示：用例图
│ └── 架构描述语言（ADL）
│ ├── 定义：为软件系统的概念体系结构建模提供具体语法和概念框架的形式化语言。
│ ├── 主要特点：更关注构件间的互联机制（连接子）
│ ├── 常见ADL示例
│ │ ├── C2SADL：基于组件和消息的软件架构描述语言
│ │ ├── Wright：分布、并发类型的架构描述语言，支持体系结构构件之间交互的说明和分析
│ │ ├── ACME：架构互换语言，用于不同 ADL 之间的转换与互操作
│ │ ├── UniCon（Unicon）：基于组件和连接的架构描述语言，支持异构的构件和连接类型，并提供了关于体系结构的高层编译器
│ │ ├── Rapide：基于事件的架构描述语言，支持体系结构设计的模拟，并提供了分析模拟结果的工具（强调事件驱动与时序）
│ │ ├── Darwin：其他类别
│ │ ├── MetaH：为设计者提供了关于实时电子控制软件系统的设计指导
│ │ ├── Aesop：支持体系结构风格的应用（如管道-过滤器、客户-服务器等架构风格）
│ │ ├── Weaves：其他类别
│ │ ├── SADL：提供了关于体系结构加细的形式化基础（支持逐步细化设计）
│ │ ├── xADL：其他类别
│ │ └── C2：支持基于消息传递风格的用户界面系统的描述
│ ├── 三个基本元素
│ │ ├── 构件：计算或数据存储单元
│ │ ├── 连接件：用于构件之间交互建模的体系结构构造块及其支配交互的规则
│ │ └── 架构配置：描述体系结构的构件与连接件的连接图
│ └── 补充要素：构件接口（ADL的组成部分通常包括组件、组件接口、连接件和架构配置）
├── 2️⃣ 核心架构风格
│ ├── 什么是架构风格
│ │ ├── 软件架构风格的定义
│ │ │ ├── 描述某一特定应用领域中系统组织方式的"惯用模式"
│ │ │ └── 定义一个"系统家族"，即一组具有相似结构和语义特性的系统
│ │ ├── 架构风格的核心构成
│ │ │ ├── 包含一个"词汇表"（构件与连接件类型）和一组"约束"（如何组合这些构件与连接件）
│ │ │ └── 反映领域内众多系统的共性结构与语义特征
│ │ ├── 架构风格的作用
│ │ │ ├── 指导模块与子系统如何组织成完整系统
│ │ │ ├── 促进设计重用（通过成熟、经过验证的解决方案）
│ │ │ └── 可靠地解决领域内反复出现的问题
│ │ ├── 实践价值
│ │ │ ├── 对架构风格的研究与实践有助于提升系统设计效率与质量
│ │ │ └── 提供可复用的解决方案模板，降低开发风险
│ │ ├── 经验总结：体系结构风格和特定领域的架构（DSSA）是软件体系结构设计经验总结与重用的主要技术手段
│ │ └── 注：架构设计并不一定要基于某个特定的架构风格。虽然架构风格可以为设计提供指导和模式，但实际的架构设计往往是多种风格的结合，灵活应对具体的需求和约束条件
│ ├── 数据流风格
│ │ ├── 特点概述："每个阶段产生的结果作为下一个阶段的输入"是典型的数据流架构风格的特点
│ │ ├── 一、批处理序列（Batch Processing Sequence）
│ │ │ ├── 构件：一系列固定顺序的计算单元
│ │ │ ├── 连接件：临时存储介质（如磁带、磁盘文件）
│ │ │ ├── 特点：全部的、高潜伏性的、输入时可随机存取、无合作性、无交互性的
│ │ │ ├── 注：批处理风格本身主要强调的是顺序执行，并非并行
│ │ │ └── 典型实例：交易网站的用户行为分析需要分析离线用户行为日志，适宜采用的软件架构风格是批处理风格
│ │ ├── 二、管道-过滤器架构（Pipe-and-Filter Architecture）
│ │ │ ├── 构件：过滤器
│ │ │ ├── 连接件：管道
│ │ │ ├── 特点：递增的、数据结果延迟小、输入时处理局部化、有反馈、可交互的
│ │ │ ├── 注：在管道-过滤器风格中，过滤器之间可以并行处理数据
│ │ │ └── 典型实例：传统编译器（包括词法分析、语法分析、语义分析和代码生成）一个阶段的输出是另一个阶段的输入，符合管道过滤器风格的特点；某软件开发公司负责开发一个Web服务器服务端处理软件，其核心部分是对客户端请求消息的解析与处理，包括HTTP报头分离、SOAP报文解析等功能适合管道过滤器（HTTP协议体中包含整个SOAP消息内容），因此需要数据内容的逐步分解与分阶段处理；早期的编译器采用管道一过滤器架构风格，并且大多数编译器在词法分析时创造独立的符号表，在其后的阶段会不断修改符号表，因此符号表并不是程序数据的一部分；早期的编译器采用管道一过滤器架构风格，以文本形式输入的代码被逐步转化为各种形式，最终生成可执行代码
│ │ ├── 优点：高内聚低耦合、重用性/可维护性好、可扩展、支持并行
│ │ ├── 缺点：交互性较差、复杂性高、性能较差（解析与合成数据开销）
│ │ └── 典型实例：传统编译器、网络报文处理、某公司欲实现一个数据处理软件，该软件需要从网络接收一组复杂的数据，然后分步进行解析和处理。适合管道过滤器风格、气象数据分析系统需要对大量的气象数据进行清洗、转换和存储，适宜数据流风格
│ ├── 调用/返回风格
│ │ ├── 主要思想：采用分而治之的策略，将复杂系统分解为子系统
│ │ ├── 交互方式：显示调用
│ │ │ ├── 定义：调用方明确知道被调用方是谁，并且等待其返回结果
│ │ │ ├── 特点：调用关系在代码中显式体现
│ │ │ ├── 与隐式调用的区别：隐式调用中调用方不知道哪些构件会响应
│ │ │ └── 注：显式调用策略替换为隐式调用策略能够提高系统的灵活性，但会降低系统的性能，所以显示调用关注实时
│ │ ├── 优点
│ │ │ ├── 良好的重用性，只要接口不变可用在其它处
│ │ │ ├── 可维护性好
│ │ │ ├── 可扩展性好
│ │ │ └── 支持递增设计
│ │ ├── 缺点
│ │ │ ├── 并不是每个系统都方便分层
│ │ │ ├── 很难找到一个合适的、正确的层次抽象方法
│ │ │ └── 不同层次之间耦合度高的系统很难实现
│ │ ├── 子风格一：主程序/子程序
│ │ │ ├── 定义：主程序/子程序风格中构件为主程序和子程序
│ │ │ ├── 构件：主程序和子程序
│ │ │ └── 连接件：过程调用（显示调用）
│ │ ├── 子风格二：面向对象
│ │ │ ├── 定义：面向对象风格建立在数据抽象和面向对象的基础上，其核心构建单元是对象，或者说是抽象数据类型的实例
│ │ │ ├── 构件：对象
│ │ │ ├── 连接件：函数或者过程调用（显示调用）
│ │ │ └── 注：如果引入对象管理层会降低系统性能
│ │ ├── 子风格三：分层架构
│ │ │ ├── 构件：各层（如表示层、业务逻辑层、数据访问层）
│ │ │ ├── 连接件：协议（定义层与层之间的交互规则和通信方式，如API接口、函数调用、网络协议等），采用显示调用方式
│ │ │ ├── 注：层次型风格中相邻层之间的交互方式是调用返回
│ │ │ ├── 注：层次型体系结构中，连接件由定义层间交互的协议来确定
│ │ │ └── 注：层次系统中，每一层既为上层提供服务，也作为下层的客户
│ │ └── 典型实例：客户可以通过银行ATM机发起请求办理各类业务，并将结果返回，适宜采用的软件架构风格是调用返回风格、医疗诊断系统需要根据患者的症状和历史数据判断疾病，适宜采用调用返回风格、导弹弹道计算需要实时得知结果，及时采取纠偏手段，适宜采用的软件架构风格是调用/返回风格，实时是关键
│ ├── 独立构件风格
│ │ ├── 构件：独立的命名过程
│ │ ├── 连接件：消息，进程通信风格的典型连接件是消息传递
│ │ ├── 子风格：进程通信、事件驱动系统（隐式调用）
│ │ ├── 进程通信体系结构风格
│ │ │ ├── 构件：独立的过程
│ │ │ ├── 连接件：消息传递
│ │ │ └── 消息传递方式：包括点到点、异步或同步方式及远程过程调用等
│ │ ├── 事件驱动架构（EDA，Event-Driven Architecture）主要特征
│ │ │ ├── 1. 独立性：构件（组件）之间是独立的，它们彼此不知道对方的存在。消息通过事件总线或中间件传递，而不是直接发送给其他构件
│ │ │ └── 2. 非耦合性：组件之间通过事件解耦，没有直接依赖关系。消息的发送者和接收者彼此独立，降低了系统的耦合性
│ │ ├── 隐式调用（事件系统）特点
│ │ │ ├── 核心特征：触发者不知道哪些构件会被事件影响，这提高了系统的灵活性和可扩展性
│ │ │ ├── 构件放弃了对系统计算的控制
│ │ │ ├── 触发事件时不能确定其他构件是否会响应及调用顺序
│ │ │ ├── 数据交换和正确性推理存在问题
│ │ │ ├── 系统由若干子系统构成，有主从之分，有自己的事件收集和处理机制
│ │ │ ├── 注：事件驱动系统中，一个事件的发生可能会影响另一个事件
│ │ │ └── 注：对于采用隐式调用架构风格的系统，可以通过处理函数的并发调用提高系统处理性能，如果处理函数是性能瓶颈的话
│ │ ├── 优点：松耦合、重用性/可修改性/可扩展性好
│ │ ├── 适用场景：某公司拟开发一个新闻系统，该系统可根据用户的注册兴趣，向用户推送其感兴趣的新闻内容，该系统应该采用事件驱动架构风格最为合适
│ │ ├── 典型实例一：Windows操作系统在图形用户界面处理方面采用的是典型的"事件驱动"的架构风格
│ │ ├── 典型实例二：从地球发布的任务需要经过几分钟之后才能到达。机器人接受任务后，需要根据自身状态和外界环境进行动态调整，最终自动完成任务并返回结果。"从地球发布的任务需要经过几分钟之后才能到达"因此不可能是主程序-子程序，机器人在接受任务之后自行处理，最终返回结果，最合适的是异步的隐式调用风格
│ │ ├── 典型实例三：IDE环境是一种交互式编程，用户在修改程序代码后，会同时触发语法高亮显示、语法错误提示、程序结构更新等多种功能的调用与结果呈现。在做一件事情时，同时触发一系列的行为，这是典型的隐式调用风格（事件驱动系统）
│ │ └── 典型实例四：一家软件公司正在开发一款图形编辑软件，该软件允许用户通过直观的用户界面进行图像编辑，而无需直接编写代码。软件需要能够自动识别用户的操作意图，并调用相应的底层图像处理功能适合隐式调用
│ ├── 虚拟机风格
│ │ ├── 构件：虚拟机（解释器/规则引擎）
│ │ ├── 连接件：虚拟机与外部环境之间的交互协议（如数据流、控制指令、规则匹配等）
│ │ ├── 优点：可以灵活应对自定义场景
│ │ ├── 缺点：复杂度较高
│ │ ├── 适用场景：某公司拟开发一个VIP管理系统，系统需要根据不同商场活动，不定期更新VIP会员的审核标准和VIP折扣系统（随时改变，灵活定义），这种最适合虚拟机风格了
│ │ ├── 子风格：解释器、规则系统
│ │ ├── 解释器
│ │ │ ├── 定义：为特定领域提供抽象的执行环境
│ │ │ ├── 适用场景：适用于自定义规则的场合
│ │ │ ├── 构成
│ │ │ │ ├── 一个完成解释工作的解释引擎
│ │ │ │ ├── 一个包含被解释的代码的存储区
│ │ │ │ ├── 一个记录解释引擎当前工作状态的数据结构
│ │ │ │ └── 一个记录源代码被解释执行的进度的数据结构
│ │ │ ├── 优点：安全性好、扩展性强
│ │ │ ├── 缺点：执行效率比较低
│ │ │ ├── 典型实例一：Java语言宣传的"一次编写，到处运行"的特性是虚拟机风格
│ │ │ └── 典型实例二：某企业内部现有的主要业务功能已封装成为Web服务。为了拓展业务范围，需要将现有的业务功能进行多种组合，形成新的业务功能。适合解释器风格（要求对业务功能灵活组合形成新的业务功能，就是有自定义类型的业务。自定义的业务能正常执行，需要有虚拟机架构的支撑）
│ │ └── 规则系统
│ │ ├── 定义：基于规则的系统，用于AI和决策支持系统
│ │ ├── 核心特点：强调"自定义"就是规则风格
│ │ ├── 适用场景：适用于专家系统（解释推理过程）、以规则为中心的虚拟机风格适合于实现专家系统
│ │ ├── 决策支持系统（DSS）：核心功能是辅助决策，尤其针对半结构化及非结构化问题
│ │ ├── 构成
│ │ │ ├── 规则集：存储规则
│ │ │ ├── 规则解释器：负责解释执行规则
│ │ │ ├── 规则/数据选择器：主要功能是选择适当的规则和数据进行处理
│ │ │ └── 工作内存：用于存储当前工作状态和中间结果
│ │ └── 典型实例：机器人的控制者首先定义清洁任务和任务之间的关系，机器人接受任务后，需要响应外界环境中触发的一些突发事件，根据自身状态进行动态调整，最终自动完成任务。适合采用规则系统（要求机器人的控制者首先定义清洁任务和任务之间的关系，然后由机器人执行，这说明机器人能对自定义的一些逻辑进行解析，这是虚拟机风格的一大特色）
│ ├── 以数据为中心风格
│ │ ├── 核心共同特点：仓库结构有一个中央数据结构（仓库），用于说明当前数据的状态；黑板结构有一个中央数据结构（黑板数据结构），用于组织解决问题的数据。这是两种结构的核心共同特点
│ │ ├── 子风格：数据库系统、黑板系统、超文本系统
│ │ ├── 数据库系统（仓库风格）
│ │ │ ├── 构件
│ │ │ │ ├── 第一类：中央共享数据源，保存当前系统的数据状态
│ │ │ │ └── 第二类：多个独立处理单元，对数据元素进行操作，独立构件在中央数据存储上执行
│ │ │ ├── 连接件：数据访问协议（如SQL、JDBC、ODBC等）
│ │ │ └── 典型实例：公司拟开发一套针对该编程语言的集成开发环境，包括代码编辑、语法高亮、代码编译、运行调试等功能。适合仓库风格、现代编译器的集成开发环境则采用数据共享风格架构、IDE是一种集成式的开发环境，在这种环境中，多种工具是围绕同一数据进行处理，这种情况适合用数据共享架构风格、现代的编译器采用以数据共享为中心的架构风格，分析树是在语法分析阶段结束后才产生作为语义分析的输入，分析树是数据中心中重要的共享数据，为后续的语义分析提供了帮助
│ │ ├── 黑板系统
│ │ │ ├── 构件：知识源（Knowledge Sources）
│ │ │ │ └── 说明：知识源是黑板架构中进行数据处理和计算的核心构件。每个知识源都具备特定的领域知识和处理能力，它能够从黑板（中央数据结构）中获取所需的数据，运用自身的算法和规则对这些数据进行处理和计算，然后将新的结果或信息写回到黑板上
│ │ │ ├── 连接件
│ │ │ │ ├── 黑板（Blackboard）：全局数据库，传递状态和数据，是知识源之间交互的唯一媒介
│ │ │ │ └── 控制机制（Control）：监控和驱动黑板状态变化，协调知识源的响应时机。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识
│ │ │ ├── 核心特点
│ │ │ │ ├── 构件（知识源）之间不直接交互
│ │ │ │ ├── 所有通信和协作都通过连接件（黑板）进行
│ │ │ │ └── 控制机制决定哪个知识源在何时激活
│ │ │ ├── 定义：多个独立的"知识源"通过共享的"黑板"数据仓库进行协作
│ │ │ ├── 组成部分
│ │ │ │ ├── 知识源（Knowledge Sources）
│ │ │ │ │ ├── 包含若干独立计算的单元
│ │ │ │ │ ├── 提供解决问题的知识
│ │ │ │ │ ├── 响应黑板状态变化，也只修改黑板内容
│ │ │ │ │ └── 不直接相互作用，仅通过黑板间接协作
│ │ │ │ ├── 黑板（Blackboard）
│ │ │ │ │ ├── 是一个全局数据库
│ │ │ │ │ ├── 存储问题求解过程中的全部状态
│ │ │ │ │ └── 是知识源之间相互作用的唯一媒介
│ │ │ │ └── 控制机制（Control）
│ │ │ │ ├── 负责协调知识源何时响应、如何响应
│ │ │ │ └── 通过监控和驱动黑板状态的变化来实现控制
│ │ │ └── 应用场景
│ │ │ ├── 适用于没有确定性算法的问题求解领域
│ │ │ ├── 黑板风格是问题求解模型，常应用于信号处理（如语音识别、模式识别）领域
│ │ │ ├── 典型应用：信号处理、问题规划、编译器优化等
│ │ │ ├── 对于语音识别、知识推理等问题复杂、解空间很大、求解过程不确定的这一类软件系统通常采用黑板风格
│ │ │ ├── 同声传译软件需要实时接收语音，并将接收的语音流分配给不同的翻译构件翻译成指定的语言，适合黑板架构风格
│ │ │ ├── 在线语言翻译需要同时考虑多种语言甚至方言的可能性，适宜采用的软件架构风格是黑板风格
│ │ │ └── 黑板风格适合于自然语言处理、语音处理、模式识别、图像处理
│ │ └── 超文本系统
│ │ ├── 构件
│ │ │ ├── 节点（Node）：信息的基本单元，包含文本、图像、视频等内容
│ │ │ └── 锚点（Anchor）：节点内可链接的位置或区域
│ │ ├── 连接件
│ │ │ ├── 链接（Link）：建立节点之间的关联，支持用户导航和跳转
│ │ │ └── 超链接（Hyperlink）：点击后跳转到其他节点
│ │ └── 核心特点
│ │ ├── 节点之间通过链接相互关联
│ │ ├── 支持非线性导航和信息访问
│ │ └── 用户可以根据需要自由跳转，不遵循固定顺序
│ ├── 闭环控制架构（过程控制）
│ │ ├── 构件
│ │ │ ├── 传感器（Sensor）：测量系统输出或环境状态
│ │ │ ├── 控制器（Controller）：比较设定值与实际值，计算控制量
│ │ │ ├── 执行器（Actuator）：执行控制指令，调整系统行为
│ │ │ └── 过程（Process）：被控制的系统或对象
│ │ ├── 连接件
│ │ │ ├── 反馈回路（Feedback Loop）：将输出信号传回控制器，形成闭环
│ │ │ └── 控制信号（Control Signal）：控制器向执行器发送的指令
│ │ ├── 特点：通过反馈循环来调整系统行为，使其维持在设定点
│ │ ├── 适用场景：闭环结构通常适用于处理简单任务（如机器装配等），并不适用于复杂任务
│ │ └── 典型应用：空调自动调温器（常用于嵌入式系统），温器需要实时获取外界的温度信息，并与用户定义的温度进行比较并做出动作适合过程控制架构风格
│ └── C2风格
│ ├── 构件：构件（Component）
│ ├── 连接件：连接件（Connector）
│ ├── 基本规则
│ │ ├── 构件和连接件都有顶部和底部
│ │ ├── 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连
│ │ ├── 一个连接件可以和任意数目的其他构件和连接件连接
│ │ └── 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部
│ ├── 核心特点：严格的层次化连接规则，构件之间不直接通信，所有交互通过连接件完成
│ ├── 定义：C2架构风格是一种专注于松耦合、异步通信的分布式系统架构风格，主要应用于用户界面管理、分布式交互系统、可视化系统等复杂应用
│ ├── 核心描述：通过连接件将并行构件绑定在一起按照规则运作：这准确描述了C2风格的核心特征
│ └── 典型实例：大型在线游戏系统需要处理玩家的实时操作和状态更新适合C2
├── 3️⃣ 典型应用架构
│ ├── 层次架构
│ │ ├── 两层C/S（胖客户端-数据库）
│ │ │ ├── 特点：客户端承担业务逻辑和界面展示，直接访问数据库
│ │ │ └── 缺点：客户端臃肿，升级维护困难
│ │ ├── 三层C/S（瘦客户端-应用服务器-数据库）
│ │ │ ├── 特点：客户端只负责界面，应用服务器承担业务逻辑
│ │ │ └── 优点：可维护性高，业务逻辑集中管理
│ │ ├── 三层B/S（零客户端，浏览器-WEB应用服务器-数据库）
│ │ │ ├── 特点：浏览器作为客户端，无需安装，通过WEB服务器访问
│ │ │ └── 优点：跨平台，部署维护方便
│ │ ├── 通用层次划分
│ │ │ ├── 表现层：用户界面展示
│ │ │ │ ├── MVC（Model-View-Controller）
│ │ │ │ │ ├── 模型（Model）：应用问题域中包含的抽象领域知识（业务逻辑和数据，如Entity Bean、Session Bean）
│ │ │ │ │ ├── 视图（View）：将应用问题域中包含的抽象领域知识呈现给用户的方法；一个模型可以用于多个视图（用户界面展示，如JSP）
│ │ │ │ │ └── 控制器（Controller）：用户界面对用户输入的响应方式（接收输入，调用模型和视图，如Servlet）
│ │ │ │ ├── MVP（Model-View-Presenter）
│ │ │ │ │ ├── 模型（Model）：业务逻辑和数据
│ │ │ │ │ ├── 视图（View）：用户界面展示
│ │ │ │ │ ├── 主持者（Presenter）：处理视图逻辑，连接模型和视图
│ │ │ │ │ └── 优点：模型与视图完全分离，便于测试
│ │ │ │ └── MVVM（Model-View-ViewModel）
│ │ │ │ ├── 模型（Model）：业务逻辑和数据
│ │ │ │ ├── 视图（View）：用户界面展示
│ │ │ │ ├── 视图模型（ViewModel）：数据绑定，连接模型和视图
│ │ │ │ └── 特点：完成数据的双向绑定
│ │ │ ├── 中间层：业务逻辑处理
│ │ │ ├── 访问层：数据访问封装
│ │ │ │ └── ORM（对象关系映射）：将数据库表映射为对象，简化数据访问
│ │ │ └── 数据层：数据存储
│ │ └── 物联网分层架构（IoT）
│ │ ├── 感知层：识别物体、采集信息
│ │ │ ├── 功能：识别物体、采集信息
│ │ │ └── 技术示例：二维码、RFID、摄像头、传感器
│ │ ├── 网络层：传递信息和处理信息
│ │ │ ├── 功能：传递信息和处理信息
│ │ │ └── 技术示例：通信网与互联网的融合网络、网络管理中心、信息中心和智能处理中心
│ │ ├── 平台层：IoT连接管理（IoT Agent）
│ │ └── 应用层：解决信息处理和人际交互的问题
│ │ ├── 功能：解决信息处理和人际交互的问题
│ │ └── 业务应用：能源管理、娱乐、健康、监控和安全
│ ├── 面向服务架构（SOA）
│ │ ├── 核心：服务是一种满足业务需求的操作、规则的逻辑组合
│ │ ├── 服务内部结构（三层结构）
│ │ │ ├── 服务接口层：共同的封装、共同的语言格式、共同的安全和容错处理
│ │ │ ├── 逻辑层：业务逻辑处理
│ │ │ └── 数据访问层：数据访问封装
│ │ ├── 核心特点对比（服务 vs 传统构件）
│ │ │ ├── 标准化程度更高：服务是更标准化的构件
│ │ │ ├── 粗粒度：服务比传统构件粒度更大
│ │ │ ├── 接口标准化：服务主要采用 WSDL 接口；传统构件常以具体 API 形式出现
│ │ │ ├── 语言无关性：服务实现与编程语言无关；传统构件绑定特定语言
│ │ │ └── 松耦合控制：服务可通过构件容器提供 QoS（服务质量）；传统构件由程序代码直接控制，耦合紧密
│ │ ├── 关键技术
│ │ │ ├── 发现服务
│ │ │ │ ├── UDDI（Universal Description, Discovery and Integration）：Web 服务集成的体系框架，包含服务描述与发现的标准规范
│ │ │ │ └── DISCO：Web 服务发现协议
│ │ │ ├── 描述服务
│ │ │ │ └── WSDL（Web Services Description Language）：基于 XML 的语言，用于描述 Web 服务（功能、如何访问、服务位置等）
│ │ │ ├── 消息格式层
│ │ │ │ ├── SOAP：基于 XML 的协议，用于分布式环境交换信息
│ │ │ │ │ ├── 四个组成部分
│ │ │ │ │ │ ├── SOAP 封装：定义消息内容、发送者、接收者
│ │ │ │ │ │ ├── SOAP 编码规则：定义数据类型实例的编码机制
│ │ │ │ │ │ ├── SOAP RPC：定义远程过程调用和应答协定
│ │ │ │ │ │ └── SOAP 绑定：定义使用底层协议交换信息的方式
│ │ │ │ │ └── 特点：基于 XML，与平台和语言无关
│ │ │ │ └── REST（Representational State Transfer）：表述性状态转移架构风格
│ │ │ │ ├── 核心：RESTful架构风格的核心是资源抽象，将系统中的每一个实体抽象成一种资源
│ │ │ │ ├── 五个核心原则
│ │ │ │ │ ├── 网络上的所有事物都被抽象为资源
│ │ │ │ │ ├── 每个资源对应一个唯一的资源标识
│ │ │ │ │ ├── 通过通用的连接件接口对资源进行操作
│ │ │ │ │ ├── 对资源的各种操作不会改变资源标识
│ │ │ │ │ └── 所有的操作都是无状态的
│ │ │ ├── 编码格式层：XML（DOM、SAX）
│ │ │ └── 传输协议层：HTTP、TCP/IP、SMTP
│ │ └── ESB（企业服务总线）
│ │ ├── 定义：是面向服务架构的一种实现方式，实现服务请求者与提供者解耦
│ │ └── 核心功能
│ │ ├── 提供位置透明性的消息路由和寻址服务
│ │ ├── 提供服务注册和命名的管理功能
│ │ ├── 支持多种的消息传递范型
│ │ ├── 支持多种可以广泛使用的传输协议
│ │ ├── 支持多种数据格式及其相互转换
│ │ └── 提供日志和监控功能
│ ├── 微服务架构
│ │ ├── 特点：很小的服务，面向对象架构的一种（雕版印刷 vs 活字印刷）
│ │ ├── 微服务架构模式方案
│ │ │ ├── 1. 聚合器微服务：通过聚合器将多个微服务的结果组合返回给客户端
│ │ │ ├── 2. 链式微服务：服务按顺序调用，形成处理链
│ │ │ ├── 3. 数据共享微服务：多个微服务共享同一数据源
│ │ │ └── 4. 异步消息传递微服务：通过消息队列实现异步通信
│ │ ├── 与SOA对比
│ │ │ ├── 管理方式：微服务是去中心化管理；SOA是集中式管理
│ │ │ ├── 核心思想：微服务强调拆分；SOA强调整合
│ │ │ ├── 拆分方式：纵向拆分
│ │ │ ├── 组织方式：独立组织负责
│ │ │ ├── 粒度：细粒度
│ │ │ ├── 通信方式：轻量级通信（如HTTP/REST）
│ │ │ ├── 总线：无ESB
│ │ │ ├── 业务划分：微服务是按业务领域垂直划分（如用户服务、订单服务、支付服务等），每个服务内部可能包含完整的三层架构（表示层、业务逻辑层、数据访问层），即"垂直切片"；SOA也可以按业务划分
│ │ │ ├── 适用范围：微服务是团队级
│ │ │ └── SOA适用范围：企业级
│ │ └── 微服务设计约束
│ │ ├── 1. 微服务个体约束：微服务都是独立的，修改一个微服务不能影响另外一个
│ │ ├── 2. 微服务与微服务之间的横向关系：通过第三方服务注册中心来满足服务的可发现性
│ │ ├── 3. 微服务与数据层之间的纵向约束：访问数据需要通过微服务
│ │ └── 4. 全局视角下的微服务分布式约束：高效运维整个系统
│ ├── 云计算架构风格
│ │ ├── 第一层：云计算
│ │ │ ├── 定义：集合了大量计算设备和资源，对用户屏蔽底层差异的分布式处理架构，其用户与提供实际服务的计算资源是相分离的
│ │ │ ├── 优点
│ │ │ │ ├── 超大规模
│ │ │ │ ├── 虚拟化
│ │ │ │ ├── 高可靠性
│ │ │ │ ├── 高可伸缩性
│ │ │ │ ├── 按需服务
│ │ │ │ └── 成本低（前期投入低、综合使用成本也低）
│ │ │ ├── 分类（按服务类型）
│ │ │ │ ├── SaaS（软件即服务）：基于多租户技术实现，直接提供应用程序
│ │ │ │ ├── PaaS（平台即服务）：虚拟中间件服务器、运行环境和操作系统
│ │ │ │ └── IaaS（基础设施即服务）：包括服务器、存储和网络等服务
│ │ │ └── 分类（按部署方式）
│ │ │ ├── 公有云：面向互联网用户需求，通过开放网络提供云计算服务
│ │ │ ├── 私有云：面向企业内部提供云计算服务
│ │ │ └── 混合云：兼顾以上两种情况的云计算服务
│ │ ├── 第二层：云原生架构
│ │ │ ├── 定义：是基于分布部署和统一运管的分布式云，以容器、微服务、devops 等技术为基础建立的一套云技术产品体系
│ │ │ ├── 云原生架构设计原则
│ │ │ │ ├── 服务化原则：使用微服务
│ │ │ │ ├── 弹性原则：可根据业务变化自动伸缩
│ │ │ │ ├── 可观测原则：通过日志、链路跟踪和度量
│ │ │ │ ├── 韧性原则：面对异常的抵御能力
│ │ │ │ ├── 所有过程自动化原则：自动化交付工具
│ │ │ │ ├── 零信任原则：默认不信任网络内部和外部的任何人/设备/系统
│ │ │ │ └── 架构持续演进原则：业务高速迭代情况下的架构与业务平衡
│ │ │ └── 云原生架构分层
│ │ │ ├── 管理层：提供对所有层次云计算服务的管理功能
│ │ │ ├── 用户访问层：方便用户使用云计算服务所需的各种支撑服务，针对每个层次的云计算服务都需要提供相应的访问接口
│ │ │ ├── 应用层：提供软件服务，如：财务管理、客户关系管理、商业智能
│ │ │ ├── 平台层：为用户提供对资源层服务的封装，使用户可以构建自己的应用
│ │ │ └── 资源层：提供虚拟化的资源，从而隐藏物理资源的复杂性，如：服务器、存储
│ │ └── 第三层：容器技术
│ │ ├── 定位：实现云原生的关键技术手段
│ │ ├── 核心价值：一次构建，到处运行；环境一致性；资源隔离
│ │ ├── 关键技术组件
│ │ │ ├── Docker：容器化技术，打包应用及依赖
│ │ │ ├── Kubernetes（K8s）：容器编排平台，管理容器集群
│ │ │ │ ├── 核心能力
│ │ │ │ │ ├── 资源调度：根据请求资源量在集群中选择合适的节点来运行应用
│ │ │ │ │ ├── 应用部署与管理：支持应用的自动发布与应用的回滚
│ │ │ │ │ ├── 自动修复：当宿主主机或者 OS 出现故障时，节点健康检查会自动进行应用迁移
│ │ │ │ │ ├── 服务发现与负载均衡：结合 DNS 和负载均衡机制，支持容器化应用之间的相互通信
│ │ │ │ │ ├── 弹性伸缩：可以对这个业务进行自动扩容
│ │ │ │ │ ├── 扩展式 API：开发者可以关注于应用自身，而非系统执行细节
│ │ │ │ │ ├── 可扩展性架构：所有 K8s 组件都是基于一致的、开放的 API 实现和交互
│ │ │ │ │ └── 可移植性：K8s 通过一系列抽象如 Load Balance Service（负载均衡服务）、CNI（容器网络接口）、CSI（容器存储接口），帮助业务应用可以屏蔽底层基础设施的实现差异，实现容器灵活迁移的设计目标
│ │ │ └── 与虚拟机对比：镜像更小、启动更快、资源粒度更细
│ │ └── 容器：容器技术的具体运行单元（容器镜像、容器实例、Pod）
│ └── 边缘计算
│ ├── 定义：在数据源头侧提供计算、存储、网络服务
│ ├── 本质：计算处理职能的本地化
│ ├── 类型：云边缘、边缘云、边缘网关
│ └── 边云协同分类
│ ├── 资源协同：边缘节点有基础设施资源的调度管理能力，可与云端协同
│ ├── 数据协同：边缘节点采集数据并初步分析，再发给云端做进一步处理
│ ├── 智能协同：分布式智能，云端集中式模型训练，再将模型下发到边缘节点
│ ├── 应用管理协同：边缘节点提供应用部署与运行环境，云端主要提供应用开发、测试环境
│ ├── 业务管理协同：边缘节点提供规模化、微服务化的应用/数字孪生/网络等应用实例；云端主要提供按照客户需求实现应用/数字孪生/网络等的业务编排能力
│ └── 服务协同：边缘节点按照云端策略实现部分 ECSaaS 服务，通过 ECSaaS 与云端 SaaS 的协同实现面向客户的按需 SaaS 服务；云端主要提供 SaaS 服务在云端和边缘节点的服务分布策略，以及云端承担的 SaaS 服务能力【主区和边缘共同提供服务，同时主区还要控制哪些功能在云端跑】
├── 4️⃣ 特定领域软件架构（DSSA）
│ ├── 定义：特定领域软件架构以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，其目标是支持一个特定领域中多个应用的生成
│ ├── 特征：领域性、普遍性、抽象性和可复用性。DSSA核心特征强调领域通用性而非专用性，其必须包含明确的问题域/解域定义、领域构件抽象模型、可重用元素
│ ├── 经验总结：体系结构风格和特定领域的架构（DSSA）是软件体系结构设计经验总结与重用的主要技术手段
│ ├── 基本活动
│ │ ├── 核心流程：领域分析 → 领域设计 → 领域实现
│ │ ├── 领域分析：主要目的是获得领域模型，领域模型描述领域中系统之间共同的需求，即领域需求
│ │ ├── 领域设计：主要目的是获得DSSA，DSSA描述领域模型中表示需求的解决方案。领域设计活动的主要目的是为了获得DSSA
│ │ ├── 领域实现：主要目标是依据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。领域实现是为了特定领域软件架构
│ │ ├── 领域工程：领域工程正是为一组相近或相似的应用建立基本能力与必备基础的过程，它覆盖了建立可重用软件元素的所有活动
│ │ ├── 领域模型：领域模型是由开发人员与领域专家协作构建出的一个反映深层次领域知识的模型
│ │ ├── 领域类型
│ │ │ ├── 垂直域（行业专属）：针对特定行业领域的架构复用。垂直域定义一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件架构
│ │ │ └── 水平域（跨行业通用）：适用于多个行业的通用架构能力。水平域则定义了在多个系统和多个系统族中功能区域的共有部分
│ │ └── 目标：构建既有深度又有广度的可复用软件架构
│ ├── 领域分析机制
│ │ ├── 领域专家
│ │ │ ├── 关注焦点：关注"业务/应用领域的真实需求与实现知识"
│ │ │ ├── 角色说明：有经验的用户通常担任领域专家角色，负责需求分析和项目管理
│ │ │ ├── 任务：提供关于领域中系统的需求规约和实现的知识
│ │ │ ├── 产出物：提供原始需求、案例、行业惯例、验收标准
│ │ │ └── 能力要求：行业经验 + 业务理解力
│ │ ├── 领域分析人员
│ │ │ ├── 关注焦点：控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中，如何将需求抽象为领域模型
│ │ │ ├── 角色说明：具有知识工程背景的有经验的系统分析员最适合担任领域分析师
│ │ │ ├── 产出物：产出领域模型、领域字典、一致性验证报告
│ │ │ └── 能力要求：抽象建模能力 + 知识获取/表示技术 + 沟通能力
│ │ ├── 领域设计人员
│ │ │ ├── 关注焦点：根据领域模型如何设计可复用的架构（DSSA），并对DSSA的准确性和一致性进行验证
│ │ │ ├── 角色说明：有经验的软件设计人员通常担任领域设计人员角色
│ │ │ ├── 产出物：产出DSSA（领域特定软件架构）、设计模式、模板
│ │ │ └── 能力要求：软件架构设计能力 + 复用设计方法 + 领域理解
│ │ └── 领域实现人员
│ │ ├── 关注焦点：关注"如何编码、组装、测试、部署可复用构件"
│ │ ├── 角色说明：有经验的程序设计人员通常担任领域实现人员角色
│ │ ├── 产出物：产出可复用构件库、可配置系统实例、复用指南
│ │ └── 能力要求：编程能力 + 复用技术 + 工程化实现经验
│ ├── 三层次模型
│ │ ├── DSSA通常是一个具有三个层次的系统模型，包括领域开发环境、领域特定应用开发环境和应用执行环境，其中应用工程师主要在领域特定应用开发环境中工作
│ │ ├── 领域开发环境：面向领域架构师，负责构建领域架构
│ │ ├── 领域特定的应用开发环境：面向应用工程师，负责基于领域架构开发具体应用
│ │ └── 应用执行环境：面向操作员，负责应用的部署和运行
│ └── 建立过程
│ ├── 过程模型：DSSA的建立过程采用的模型是螺旋模型，DSSA的建立过程并不是线性顺序的，而是强调并发、递归和反复迭代，因为不同阶段（如领域分析、体系结构设计、验证等）通常需要交替进行，反复优化以适应领域需求
│ ├── 阶段一：定义领域范围
│ │ └── 说明：这个阶段主要输出领域中的应用需要满足的用户需求，不涉及领域字典的编译
│ ├── 阶段二：定义领域特定的元素
│ │ └── 说明：这个阶段的主要任务包括编译领域字典和领域术语的同义词词典，对于确保在整个DSSA过程中术语的一致性和清晰性至关重要
│ ├── 阶段三：定义领域特定的设计和实现需求约束
│ │ └── 说明：这个阶段关注的是设计和实现的约束，而非术语定义
│ ├── 阶段四：定义领域模型和架构
│ │ └── 说明：这个阶段侧重于模型和架构的定义，不涉及术语字典的编译
│ ├── 领域分析：识别领域边界、共性需求和可变点
│ ├── 领域设计：定义领域架构、构件和连接件
│ ├── 领域实现：开发领域构件和框架
│ └── 应用开发：基于领域架构开发具体应用
├── 5️⃣ 软件产品线
│ ├── 定义：软件产品线是一个产品的集合，这些产品共享一个公共的、可管理的特征集，能满足特定领域的特定需求
│ ├── 核心组成：核心资源 + 产品集合
│ ├── 核心特点
│ │ ├── 过程驱动：强调规范化的开发过程
│ │ ├── 特定领域：针对特定业务领域而非通用
│ │ ├── 以技术支持：依托先进技术手段
│ │ └── 以架构为中心：架构是产品线的核心基础
│ ├── 过程模型
│ │ ├── 软件产品线的过程模型主要有：双生命周期模型、SEI模型和三生命周期模型
│ │ └── 双生命周期模型：分成两个重叠的生命周期，分别是领域工程和应用工程
│ ├── 核心活动
│ │ ├── 核心资产开发
│ │ └── 产品开发
│ ├── 组织结构类型
│ │ └── 产品线实施可以采用不同的组织结构类型，包括设立独立的核心资源小组、不设立独立的核心资源小组或采用动态的组织结构
│ ├── 应用场景
│ │ └── 某公司决定将其现有的多个独立软件产品整合成一个软件产品线。这种做法属于产品线演化，用软件产品线替代现有产品集
│ └── 与DSSA的关系：DSSA是产品线开发的技术基础
├── 6️⃣ 基于架构的软件设计（ABSD）
│ ├── 1. ABSD与传统软件设计的区别
│ │ ├── 核心驱动力不同
│ │ │ ├── ABSD：业务[商业] + 质量 + 功能需求共同驱动架构，架构是三大需求组合的结果
│ │ │ └── 传统设计：功能需求主导设计，先实现功能，质量属性后期补救
│ │ ├── 设计起点不同
│ │ │ ├── ABSD：从整体架构视角出发，先定结构，再填充细节
│ │ │ └── 传统设计：从模块/代码层面出发，自底向上或逐层细化
│ │ ├── 设计基础不同
│ │ │ ├── ABSD：三大基础（功能分解、架构风格选择、软件模板复用）
│ │ │ │ ├── 第一个基础：功能分解，在功能分解中使用已有的基于模块的内聚和耦合技术
│ │ │ │ ├── 第二个基础：通过选择体系结构风格来实现质量和商业需求
│ │ │ │ └── 第三个基础：软件模板的使用
│ │ │ └── 传统设计：依赖经验、设计模式、UML建模，缺乏系统性架构决策框架
│ │ ├── 质量属性处理不同
│ │ │ ├── ABSD：显式建模，通过"刺激-环境-响应"场景捕获质量需求
│ │ │ └── 传统设计：隐式处理，质量属性常在测试或运维阶段暴露
│ │ ├── 需求获取方式不同
│ │ │ ├── ABSD：用例捕获功能需求 + 特定场景捕获质量需求
│ │ │ └── 传统设计：需求规格说明书、用户访谈、问卷调查、原型演示、文档分析
│ │ ├── 视图管理不同
│ │ │ ├── ABSD：强调多视角+多视图，满足不同干系人需求
│ │ │ └── 传统设计：通常只关注开发者视角（类图、时序图）
│ │ ├── 首要目标不同
│ │ │ ├── ABSD：满足非功能性需求（质量属性）+ 业务[商业]目标
│ │ │ └── 传统设计：实现功能正确性，"能跑就行"
│ │ ├── 变更适应性不同
│ │ │ ├── ABSD：设计时预留扩展点，适应业务变化
│ │ │ └── 传统设计：功能固化后难改，重构成本高
│ │ ├── 团队协作不同
│ │ │ ├── ABSD：支持跨角色协作，通过不同视图沟通
│ │ │ └── 传统设计：主要面向开发人员，其他角色参与度低
│ │ ├── 工具与技术不同
│ │ │ ├── ABSD：架构描述语言（ADL）、视图建模工具、场景分析工具
│ │ │ └── 传统设计：UML建模工具、IDE内置设计功能
│ │ ├── 复用机制不同
│ │ │ ├── ABSD：强调架构模板、参考架构、模式库复用
│ │ │ └── 传统设计：强调代码复用、设计模式复用
│ │ └── 适用场景不同
│ │ ├── ABSD更适合：大型复杂系统、长期演进系统
│ │ └── 传统设计更适合：小型简单系统、初创项目/MVP
│ ├── 2. ABSD的开发过程
│ │ ├── 基础介绍
│ │ │ ├── 支持软件重用
│ │ │ ├── 自顶向下，递归细化，直到产生软件构件和类
│ │ │ ├── 使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，并且设计活动的开始并不意味着需求抽取和分析活动可以终止，而是应该与设计活动并行
│ │ │ ├── 采用视角和视图来描述软件架构
│ │ │ ├── 采用用例和质量场景来描述需求：用例描述功能需求，质量场景描述质量需求
│ │ │ ├── 注：对于软件项目开发来说，设计和实现是交替进行的
│ │ │ └── 注：ABSD方法不直接产生代码，而是细化到能产生软件构件和类的程度
│ │ ├── 架构需求过程
│ │ ├── 架构设计过程
│ │ │ ├── 定义补充：软件架构设计主要关注软件构件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。
│ │ │ ├── 三大核心维度
│ │ │ │ ├── 结构：构件（模块/服务）的组织方式与层级关系（如分层架构、微服务划分）
│ │ │ │ ├── 属性：系统的质量特性（非功能性需求），如可扩展性、可靠性、性能
│ │ │ │ └── 交互作用：构件间的通信机制与协作模式（如API调用、消息队列、事件驱动）
│ │ │ ├── 架构设计主要关注：系统的高层次结构和整体设计，分别对应解决复杂需求分析、非功能属性设计和系统整体结构问题，不关注编码这种低层次的问题，并通过多种视图全面描述特定系统的架构
│ │ │ ├── 主要目标：获得一个满足功能性需求和非功能性需求的软件系统框架模型
│ │ │ ├── 概述：是软件架构研究关注最早和最多的阶段，主要包括软件架构模型的描述、设计与分析方法，以及对软件架构设计经验的总结与复用
│ │ │ ├── 注：软件架构设计不能捕获需求，软件架构设计是在需求捕获并进行分析之后开展的工作
│ │ │ ├── 为什么软件架构与用户对系统的功能性需求没有直接的对应关系？
│ │ │ │ ├── 类比：盖房子
│ │ │ │ │ ├── 用户功能性需求：我要卧室、厨房、卫生间、客厅
│ │ │ │ │ ├── 建筑师考虑的结构：承重墙在哪里？梁和柱怎么布局？
│ │ │ │ │ ├── 建筑师考虑的属性：采光、隔音、防水
│ │ │ │ │ ├── 建筑师考虑的交互：水管怎么走？电路怎么布线？门窗怎么开？
│ │ │ │ │ └── 结论：用户说的"我要卧室"与建筑师画的"承重墙位置"没有直接的对应关系
│ │ │ │ ├── 架构需求过程的作用
│ │ │ │ │ ├── 用户说"我要卧室" → 建筑师分析：卧室需要多大面积？窗户朝哪边？隔音要求多高？
│ │ │ │ │ ├── 用户说"我要厨房" → 建筑师分析：厨房需要上下水、排烟、燃气管道
│ │ │ │ │ └── 需求是输入，需要经过分析、转换、抽象，才能变成架构设计
│ │ │ │ └── 结论：软件架构与用户对系统的功能性需求没有直接的对应关系
│ │ │ ├── 架构设计过程的特点：一般在设计软件架构之初，会根据用户需求，确定多个候选架构，并从中选择一个较优的架构，并随着软件的开发，对这个架构进行微调，以达到最佳效果，所以不是一下子就完美的
│ │ │ ├── 软件架构设计的作用：需要满足系统的质量属性，如性能、安全性和可修改性等，软件架构设计需要确定组件之间的依赖关系，支持项目计划和管理活动，软件架构能够指导设计人员和实现人员的工作
│ │ │ └── 体系结构设计是一个迭代过程，如果要开发的系统能够从已有的系统中导出大部分，则可以使用已有系统的设计过程
│ │ ├── 架构文档化
│ │ ├── 架构复审
│ │ ├── 架构实现过程
│ │ └── 架构演化过程
│ ├── 3. 架构需求过程
│ │ ├── 需求获取：获取用户需求
│ │ ├── 架构需求获取的来源有三方面：系统质量目标、系统商业目标、开发人员商业目标
│ │ │ ├── 系统的质量目标：质量目标（如性能、可靠性、可扩展性等）是软件系统成功的重要指标。体系结构设计需要确保这些质量属性在开发中被满足
│ │ │ ├── 系统的商业目标：商业目标决定了系统开发的总体方向和优先级，如降低成本、缩短上市时间、增加市场竞争力等
│ │ │ └── 系统开发人员的商业目标：开发人员的目标可能包括技术可行性、开发效率、代码可复用性等，与商业目标和质量目标密切相关
│ │ ├── 如何根据需求模型构建软件架构模型，以及如何保证模型转换的可追踪性
│ │ ├── 标识构件[构件库]
│ │ │ ├── 生成类图：生成对应的类图（UML类图），体现系统静态结构
│ │ │ ├── 对类进行分组：目的是为后续打包成构件做准备，提高内聚性、降低耦合
│ │ │ └── 把类打包成构件：构件是架构的基本单元，具有明确接口和职责，可独立部署或复用
│ │ └── 需求评审：评审不通过则重新进行需求获取
│ ├── 4. 架构设计过程
│ │ ├── 1. 提出架构模型（选择一个合适的架构风格）
│ │ ├── 2. 映射构件（将架构需求阶段已标识的构件映射到架构中，并分析这些构件之间的关系）
│ │ ├── 3. 分析构件相互作用
│ │ ├── 4. 产生构件（并不意味着开发实现这些构件）
│ │ ├── 5. 设计评审：评审不通过则重新进行映射构件，需要邀请独立于系统开发的外部人员对系统进行评审
│ │ └── 注：软件架构的多视图表示主要属于设计阶段的研究内容
│ ├── 5. 架构文档化
│ │ ├── 输出结果
│ │ │ ├── 体系结构规格说明
│ │ │ └── 测试架构需求的质量设计说明书
│ │ ├── 核心价值：文档的完整性和质量是软件架构成功的关键
│ │ ├── 三大注意事项
│ │ │ ├── 1. 文档要从使用者的角度进行编写
│ │ │ ├── 2. 文档分发给所有系统有关的开发人员
│ │ │ └── 3. 架构文档要保持较新，但不要随时保证文档最新，要保持文档的稳定性
│ │ └── 软件结构化设计
│ │ ├── 定义：软件结构化设计包括体系结构设计、接口设计、数据设计和过程设计
│ │ ├── 体系结构设计：定义软件系统各主要部件之间的关系
│ │ ├── 数据设计：将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性
│ │ ├── 接口设计（人机界面设计）：软件内部，软件和操作系统间以及软件和人之间如何通信
│ │ ├── 过程设计：系统结构部件转换成软件的过程描述。确定软件各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法
│ │ └── 外部设计与内部设计
│ │ ├── 外部设计（概要设计）：设计各个部分的功能、接口、相互如何关联
│ │ └── 内部设计（详细设计）：设计具体一个模块的实现
│ ├── 6. 架构复审
│ │ ├── 概述：体系结构设计、文档化和复审是一个迭代过程
│ │ ├── 目的：识别潜在的风险，及早发现体系结构设计中的缺陷和错误
│ │ ├── 复审内容包括但不限于
│ │ │ ├── 体系结构能否满足需求
│ │ │ ├── 质量需求是否在设计中得到体现
│ │ │ ├── 层次是否清晰
│ │ │ ├── 构件划分是否合理
│ │ │ ├── 文档表达是否明确
│ │ │ └── 构件设计是否满足功能与性能的要求等
│ │ └── 参与人员：用户代表和领域专家[外部人员]
│ ├── 7. 架构实现过程
│ │ ├── 概述：所谓"实现"就是要用实体显示出一个软件体系结构，即要符合体系结构描述的结构性设计决策，分割成规定的构件，按规定的方式互相交互
│ │ ├── 输入：以复审后的文档化的体系结构说明书为基础，每个构件必须满足软件体系结构中说明的对其他构件的责任
│ │ ├── 主要研究方向
│ │ │ ├── A：基于软件架构的开发过程支持是实现阶段研究的一个主要方向，包括项目组织结构、配置管理等
│ │ │ ├── B：从软件架构向实现过渡的途径是实现阶段的另一个重要研究方向，包括将程序设计语言元素引入软件架构阶段、模型映射等
│ │ │ └── C：基于软件架构的测试技术也是实现阶段研究的一个主要方向
│ │ ├── 过程
│ │ │ ├── 分析与设计（构件库）
│ │ │ ├── 构件实现（构件库）
│ │ │ ├── 构件组装（构件库）
│ │ │ └── 系统测试：包括单个构件的功能性测试和被组装应用的整体功能和性能测试
│ │ └── 输出：可运行的软件系统
│ └── 8. 架构演化过程
│ ├── 输入：需求变化归类
│ ├── 配置管理：配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置
│ ├── 过程
│ │ ├── 架构演进计划
│ │ ├── 构件变动（构件库）
│ │ ├── 更新构件相互作用
│ │ ├── 构件组装与测试
│ │ └── 技术评审：评审失败则回到架构演进计划
│ └── 输出：演化后的架构
├── 7️⃣ 属性驱动的软件设计方法（ADD）
│ ├── 定义：属性驱动的软件设计方法（ADD）
│ └── 主要输入：质量属性场景
├── 8️⃣ 模型驱动架构（MDA）
│ ├── 定义：由OMG（对象管理组织）提出的软件开发框架，以模型为中心，通过模型转换实现软件开发
│ ├── 核心理念：将业务逻辑与技术实现分离，提高软件的可移植性、互操作性和可重用性
│ ├── 核心模型
│ │ ├── CIM（计算无关模型）
│ │ │ ├── 定义：对某具体行业内一个项目的业务需求及其系统功能需求进行分析，有时被称为领域模型
│ │ │ ├── 关注点：业务领域、业务流程、业务规则
│ │ │ ├── 面向人员：业务专家、领域专家
│ │ │ └── 表现形式：业务用例图、业务流程图、领域模型
│ │ ├── PIM（平台独立模型）
│ │ │ ├── 定义：具有高抽象层次、独立于任何实现技术的模型
│ │ │ ├── 关注点：系统功能、结构、行为
│ │ │ ├── 面向人员：系统分析员、架构师
│ │ │ └── 表现形式：UML类图、状态图、活动图、顺序图
│ │ ├── PSM（平台相关模型）
│ │ │ ├── 定义：为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型
│ │ │ ├── 关注点：特定平台的技术实现细节
│ │ │ ├── 面向人员：开发人员、平台专家
│ │ │ └── 表现形式：EJB模型、.NET模型、Web服务模型
│ │ └── Code（代码）
│ │ ├── 定义：用源代码对系统的描述（规约）
│ │ ├── 转换：每个PSM都将被变换成代码
│ │ └── 产出：可执行的应用程序
│ └── 转换流程：PIM → PIM变换工具 → PSM → PSM变换工具 → CODE
├── 9️⃣ 架构评估
│ ├── 评估目标：非功能设计（质量属性）
│ ├── 质量属性
│ │ ├── 定义：是一个系统的可测量或者可测试的属性，用来描述系统满足利益相关者需求的程度
│ │ ├── 运行期质量属性（软件运行阶段关注）
│ │ │ ├── 性能：指软件系统及时提供相应服务的能力（速度、吞吐量、持续高速性）
│ │ │ │ └── 性能战术
│ │ │ │ ├── 资源需求
│ │ │ │ │ ├── 提供计算效率
│ │ │ │ │ ├── 减少计算开销
│ │ │ │ │ ├── 管理事件率
│ │ │ │ │ └── 控制采样频率
│ │ │ │ ├── 资源管理
│ │ │ │ │ ├── 引入并发
│ │ │ │ │ ├── 维持多个副本
│ │ │ │ │ └── 增加可用资源
│ │ │ │ └── 资源仲裁
│ │ │ │ └── 资源仲裁策略（先进先出、固定优先级、动态优先级、静态调用）
│ │ │ ├── 安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力
│ │ │ │ ├── 安全性组成
│ │ │ │ │ ├── 机密性：信息不泄漏给未授权用户
│ │ │ │ │ ├── 完整性：防止信息被篡改
│ │ │ │ │ ├── 不可否认性：不可抵赖
│ │ │ │ │ └── 可控性：对信息的传播及内容具有控制的能力
│ │ │ │ └── 安全性战术
│ │ │ │ ├── 抵抗攻击
│ │ │ │ │ ├── 身份验证
│ │ │ │ │ ├── 用户授权
│ │ │ │ │ ├── 数据加密
│ │ │ │ │ ├── 数据完整性
│ │ │ │ │ ├── 限制暴露
│ │ │ │ │ └── 限制访问
│ │ │ │ ├── 检测攻击
│ │ │ │ │ └── 入侵检测
│ │ │ │ └── 从攻击中恢复
│ │ │ │ ├── 识别：审计追踪
│ │ │ │ └── 恢复：冗余（与可用性重叠）
│ │ │ ├── 易用性：指软件系统易于被使用的程度
│ │ │ ├── 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力
│ │ │ ├── 互操作性：与其他系统交换数据和相互调用服务的难易程度
│ │ │ ├── 可靠性：在一定的时间内无故障运行的能力
│ │ │ ├── 持续可用性：指系统长时间无故障运行的能力。与可靠性相关联，常将其纳入可靠性中
│ │ │ ├── 鲁棒性：是指软件系统在一些非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等）下仍能够正常运行的能力。也称健壮性或容错性
│ │ │ ├── 可修改性
│ │ │ │ ├── 可维护性
│ │ │ │ ├── 可扩展性
│ │ │ │ ├── 结构重组
│ │ │ │ ├── 可移植性
│ │ │ │ └── 可修改性战术
│ │ │ │ ├── 局部化修改
│ │ │ │ │ ├── 维持语义一致性
│ │ │ │ │ ├── 预期期望的变更
│ │ │ │ │ ├── 泛化模块
│ │ │ │ │ ├── 限制可能的选择
│ │ │ │ │ └── 抽象通用服务、接口实现分离
│ │ │ │ ├── 防止连锁反应
│ │ │ │ │ ├── 隐藏信息
│ │ │ │ │ ├── 维持现有的接口
│ │ │ │ │ ├── 限制通信路径
│ │ │ │ │ └── 使用仲裁者
│ │ │ │ └── 推迟绑定事件
│ │ │ │ ├── 运行时注册
│ │ │ │ ├── 配置文件
│ │ │ │ ├── 多台
│ │ │ │ ├── 组件更换
│ │ │ │ └── 遵守已定义的协议
│ │ │ └── 可用性：系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响
│ │ │ └── 可用性战术
│ │ │ ├── 错误检测
│ │ │ │ ├── 命令/响应（ping/Echo）
│ │ │ │ ├── 心跳
│ │ │ │ └── 异常
│ │ │ ├── 错误恢复
│ │ │ │ ├── 表决
│ │ │ │ ├── 选举
│ │ │ │ ├── 冗余（主动/被动）
│ │ │ │ └── 备件
│ │ │ └── 错误预防
│ │ │ ├── 进程监视器
│ │ │ ├── 事务
│ │ │ └── 从服务器删除
│ │ └── 开发期质量属性（软件开发阶段关注）
│ │ ├── 易理解性：指设计被开发人员理解的难易程度
│ │ ├── 可扩展性：软件因适应需求变化而增加新功能的能力。也称为灵活性
│ │ ├── 可重用性：指重用软件系统或某一部分的难易程度
│ │ ├── 可测试性：对软件测试以证明其满足需求规范的难易程度
│ │ ├── 可维护性：当需要修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度
│ │ └── 可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度
│ ├── 评估方法
│ │ ├── 相关概念
│ │ │ ├── 敏感点：影响某个质量属性的构件或关系特性
│ │ │ ├── 权衡点：影响多个质量属性的特性，是多个敏感点的交汇点
│ │ │ ├── 风险点：架构设计中潜在的、存在问题的决策，可能带来隐患
│ │ │ ├── 非风险点：不会带来隐患的架构决策（通常是可接受的要求）
│ │ │ └── 场景
│ │ │ ├── 定义：在进行体系结构评估时，一般要精准的得出具体的质量目标，将其评判标准，为了得到目标的机制叫做场景。从风险承担者的角度与系统交互的简短描述，主要用刺激、环境、响应三部分来描述
│ │ │ └── 六个构成方面
│ │ │ ├── 刺激源：生成该刺激的实体（人、计算机系统或者任何其他刺激器）
│ │ │ ├── 刺激：当刺激到达系统时的条件
│ │ │ ├── 环境：该刺激发生的条件，比如系统过载
│ │ │ ├── 制品：某个制品被激励
│ │ │ ├── 响应：激励到达后所采取的行动
│ │ │ └── 响应度量：响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试
│ │ ├── 评估方式
│ │ │ ├── 调查问卷
│ │ │ │ ├── 通用性：通用
│ │ │ │ ├── 架构了解程度：粗略了解
│ │ │ │ ├── 实施阶段：早
│ │ │ │ └── 客观性：主观
│ │ │ ├── 检查表
│ │ │ │ ├── 通用性：特定领域
│ │ │ │ ├── 架构了解程度：无限制
│ │ │ │ ├── 实施阶段：中
│ │ │ │ └── 客观性：主观
│ │ │ ├── 场景（特定系统）
│ │ │ │ ├── 通用性：特定系统
│ │ │ │ ├── 架构了解程度：中等了解
│ │ │ │ ├── 实施阶段：中
│ │ │ │ └── 客观性：较主观
│ │ │ └── 度量
│ │ │ ├── 通用性：通用或特定领域
│ │ │ ├── 架构了解程度：精确了解
│ │ │ ├── 实施阶段：中
│ │ │ └── 客观性：较客观
│ │ ├── 基于场景的评估
│ │ │ ├── 过程
│ │ │ │ ├── 1. 确定应用领域的功能和软件架构的结构之间的映射
│ │ │ │ ├── 2. 设计用于体现待评估质量属性的场景
│ │ │ │ └── 3. 分析软件架构对场景的支持程度
│ │ │ └── 方法
│ │ │ ├── SAAM（软件架构分析法）
│ │ │ │ ├── 定义：最早，关注可修改性、可移植性
│ │ │ │ ├── 输入
│ │ │ │ │ ├── 问题描述
│ │ │ │ │ ├── 问题说明
│ │ │ │ │ └── 架构描述文档
│ │ │ │ └── 分析过程
│ │ │ │ ├── 场景开发
│ │ │ │ ├── 架构描述
│ │ │ │ ├── 单个场景评估
│ │ │ │ ├── 场景交互
│ │ │ │ └── 总体评估
│ │ │ ├── ATAM（架构权衡分析法）
│ │ │ │ ├── 定义：由SAAM发展，关注性能、可用性、安全性、可修改性，在系统开发之前进行权衡分析
│ │ │ │ ├── 核心理念：整个评估过程强调以属性作为架构评估的核心概念
│ │ │ │ ├── 核心工具：效用树（Utility Tree）
│ │ │ │ │ ├── 结构：树根 → 质量属性 → 属性分类 → 质量属性场景（叶子节点）
│ │ │ │ │ │ ├── 树根：代表整个系统的整体效用或价值
│ │ │ │ │ │ ├── 质量属性：如性能、安全性、可用性、可扩展性等
│ │ │ │ │ │ ├── 属性分类：对质量属性进一步细分
│ │ │ │ │ │ └── 质量属性场景：具体的、可测量的使用情境
│ │ │ │ │ └── 构建步骤
│ │ │ │ │ ├── 修剪树枝：保留重要场景（通常不超过50个）
│ │ │ │ │ ├── 重要性打分：H（高）、M（中）、L（低）
│ │ │ │ │ ├── 难度打分：H（难）、M（中）、L（易）
│ │ │ │ │ └── 优先级对：(H,L)优先处理，(L,H)可能放弃
│ │ │ │ ├── 主要活动阶段
│ │ │ │ │ ├── 场景和需求收集：收集利益相关者的场景和质量需求
│ │ │ │ │ ├── 体系结构视图和场景实现：将场景映射到架构视图
│ │ │ │ │ ├── 属性模型构造和分析：构建质量属性模型并进行分析
│ │ │ │ │ ├── 场景评估：对多个场景进行综合评估
│ │ │ │ │ └── 架构决策识别、权衡点分析、敏感性点分析
│ │ │ │ ├── 四个阶段
│ │ │ │ │ ├── 第一阶段：描述和介绍阶段
│ │ │ │ │ │ ├── 介绍ATAM方法
│ │ │ │ │ │ ├── 描述商业目标
│ │ │ │ │ │ │ ├── 最终用户
│ │ │ │ │ │ │ ├── 架构师
│ │ │ │ │ │ │ └── 应用程序开发人员
│ │ │ │ │ │ └── 描述体系结构
│ │ │ │ │ │ ├── 体系结构本身（模块、组件、交互）
│ │ │ │ │ │ ├── 时间可用性
│ │ │ │ │ │ └── 质量要求（性能、安全、可维护性等）
│ │ │ │ │ ├── 第二阶段：调查和分析阶段
│ │ │ │ │ │ ├── 标识体系结构步骤
│ │ │ │ │ │ ├── 产生质量属性树（效用树）
│ │ │ │ │ │ ├── 分析体系结构步骤
│ │ │ │ │ │ │ ├── 调查架构方法
│ │ │ │ │ │ │ ├── 创建分析问题
│ │ │ │ │ │ │ ├── 分析问题的答案
│ │ │ │ │ │ │ └── 找出风险、非风险、敏感点和权衡点
│ │ │ │ │ │ └── 讨论质量需求的次序（头脑风暴三种场景）
│ │ │ │ │ │ ├── 用例场景：最终用户的典型操作流程
│ │ │ │ │ │ ├── 增长场景：代表架构扩展的方式
│ │ │ │ │ │ └── 探索性场景：代表架构中极端的增长形式
│ │ │ │ │ ├── 第三阶段：测试阶段
│ │ │ │ │ │ ├── 原型验证
│ │ │ │ │ │ ├── 模拟测试
│ │ │ │ │ │ └── 压力测试
│ │ │ │ │ └── 第四阶段：报告阶段
│ │ │ │ │ └── 提交结果
│ │ │ │ │ ├── 架构的优势与劣势
│ │ │ │ │ ├── 已识别的风险与权衡点
│ │ │ │ │ ├── 建议的改进措施
│ │ │ │ │ └── 优先级排序后的质量属性场景
│ │ │ └── CBAM（成本效益分析法）：在ATAM基础上建立，关注经济模型
│ └── 评估结果分析
│ └── 识别风险、非风险、敏感点、权衡点
├── 🔟 构件与中间件
│ ├── 构件
│ │ ├── 定义
│ │ │ ├── 定义1：构件是一种组装单元，它具有规范的接口规约和显式的语境依赖，可以独立地被部署并由第三方组装
│ │ │ ├── 定义2：构件是某系统中有价值、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某清晰的功能
│ │ │ ├── 定义3：构件是一个独立发布的功能部分，可以通过其接口访问它的服务
│ │ │ └── 一句话总结：构件 = 独立发布 + 接口规范（可访问） + 可替换的功能模块
│ │ ├── 原子构件
│ │ │ ├── 定义：一组通常需要同时部署的原子构件，是构件的最小组成单元，原子构件是部署、版本控制和替换的基本单位
│ │ │ ├── 理解：一个"大构件"（比如"用户管理系统"）是由多个"小构件"（比如"登录模块"、"注册模块"、"密码重置模块"）组成的
│ │ │ ├── Java视角解释
│ │ │ │ ├── Class文件 = 原子构件：一个.java文件编译后的.class文件是独立编译单元，可被JVM加载执行
│ │ │ │ ├── JAR包 = 构件/模块：将多个.class文件打包成JAR，是一个可独立部署和复用的单元
│ │ │ │ └── Java包 ≠ 模块：包只是命名空间组织方式，不具备独立的部署和版本控制能力
│ │ │ ├── 原子构件与构件的区别：大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族
│ │ │ ├── 组成
│ │ │ │ ├── 模块：一组类和可能的非面向对象的结构体（如过程或函数）
│ │ │ │ └── 资源：一个类型化的项的固定集合，包含代码资源
│ │ │ └── 特点：原子构件通常属于某个特定的"构件家族"，不太会跨家族共享
│ │ ├── 构件、对象、模块对比
│ │ │ ├── 模块的特性
│ │ │ │ └── 结构化开发的产物
│ │ │ ├── 对象的特性
│ │ │ │ ├── 一个实例单元，具有唯一的标识
│ │ │ │ ├── 可能具有状态，此状态外部可见
│ │ │ │ └── 封装了自己的状态和行为
│ │ │ └── 构件的特性
│ │ │ ├── 独立部署单元
│ │ │ ├── 作为第三方的组装单元
│ │ │ └── 没有（外部的）可见状态
│ │ ├── 构件标准
│ │ │ ├── CORBA（公共对象请求代理体系结构）
│ │ │ │ ├── 定义：OMG组织制定的分布式对象计算标准
│ │ │ │ ├── 本质：代理模式
│ │ │ │ ├── 核心组件
│ │ │ │ │ ├── 伺服对象（Servant）
│ │ │ │ │ │ └── CORBA对象的真正实现，负责完成客户端请求
│ │ │ │ │ ├── 对象适配器（Object Adapter）
│ │ │ │ │ │ └── 用于屏蔽 ORB 内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用 ORB 内核的某些功能
│ │ │ │ │ ├── 对象请求代理（Object Request Broker，ORB）
│ │ │ │ │ │ └── 解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制
│ │ │ │ │ ├── 客户端存根（Stub）：客户端的代理对象
│ │ │ │ │ ├── 服务端框架（Skeleton）：服务端的代理对象
│ │ │ │ │ └── IDL（接口定义语言）：定义跨语言的接口规范
│ │ │ │ ├── 工作流程：客户端调用存根 → ORB定位服务 → 骨架接收请求 → 调用实际服务 → 返回结果
│ │ │ │ └── 特点：平台无关、语言无关、支持分布式异构环境
│ │ │ ├── J2EE（Java 2 Platform Enterprise Edition）
│ │ │ │ ├── 定义：Java平台的企业版，提供企业级应用开发规范
│ │ │ │ ├── EJB（Enterprise JavaBean）
│ │ │ │ │ ├── 会话Bean（Session Bean）：负责完成服务端与客户端的交互
│ │ │ │ │ ├── 实体Bean（Entity Bean）：实现O/R映射，简化数据库开发
│ │ │ │ │ └── 消息驱动Bean（Message-Driven Bean）：处理并发与异步访问
│ │ │ │ └── 特点：跨平台、企业级服务、容器管理
│ │ │ ├── DNA 2000
│ │ │ │ ├── 定义：Microsoft的分布式互联网应用架构
│ │ │ │ └── 特点：Windows平台、COM/DCOM技术、与操作系统深度集成
│ │ │ └── 服务端构件模型的典型解决方案
│ │ │ ├── 适用于应用服务器的构件模型
│ │ │ │ ├── EJB模型（Sun公司J2EE的一部分）
│ │ │ │ └── COM+模型（微软公司）
│ │ │ ├── 适用于Web服务器的构件模型
│ │ │ │ ├── servlet模型（基于Sun公司JSP技术）
│ │ │ │ └── Visual Basic及其他微软的技术（基于微软公司ASP技术）
│ │ │ └── .NET框架：引入了一种新的同时适用于客户端和服务端的基于CLI（Command Line Interface）的构件模型
│ │ ├── 构件分类
│ │ │ ├── （1）独立而成熟的构件：独立而成熟的构件得到了实际运行环境的多次检验，该类构件隐藏了所有接口，用户只需用规定好的命令进行使用。例如，数据库管理系统和操作系统等。
│ │ │ ├── （2）有限制的构件：有限制的构件提供了接口，指出了使用的条件和前提，这种构件在装配时，会产生资源冲突、覆盖等影响，在使用时需要加以测试。例如，各种面向对象程序设计语言中的基础类库等。
│ │ │ ├── （3）适应性构件：适应性构件进行了包装或使用了接口技术，把不兼容性、资源冲突等进行了处理，可以直接使用。这种构件可以不加修改地使用在各种环境中。例如ActiveX等。
│ │ │ ├── （4）装配的构件：装配（assemble）的构件在安装时，已经装配在操作系统、数据库管理系统或信息系统不同层次上，使用胶水代码（glue code）就可以进行连接使用。目前一些软件商提供的大多数软件产品都属这一类。
│ │ │ └── （5）可修改的构件：可修改的构件可以进行版本替换。如果对原构件修改错误、增加新功能，可以利用重新"包装"或写接口来实现构件的替换。这种构件在应用系统开发中使用得比较多。
│ │ ├── 构件复用
│ │ │ ├── 定义：多次不同的软件开发过程中重复使用相同或相似软件元素的过程
│ │ │ │ └── 软件元素包含：需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识
│ │ │ ├── 构件复用过程
│ │ │ │ ├── 检索与提取
│ │ │ │ │ ├── 基于关键字的检索（刻面检索法）
│ │ │ │ │ │ └── 说明：多角度精细筛选，就像在招聘网站上筛简历------选"行业=互联网"+"职位=前端"+"经验=3年以上"
│ │ │ │ │ ├── 刻面检索法
│ │ │ │ │ │ └── 说明：按目录找，用关键字树形检索，就像在超市里按"饮料 → 碳酸饮料 → 可乐"一路找下去
│ │ │ │ │ └── 超文本检索法
│ │ │ │ │ └── 说明：随便输几个词就搞定，就像在微信里搜聊天记录，输入"会议"就能找到所有提到"会议"的地方
│ │ │ │ ├── 理解与评价
│ │ │ │ │ └── 说明：用好别人写的代码模块，前提是看懂它、遵守规矩、文档要写得明明白白
│ │ │ │ ├── 修改构件
│ │ │ │ │ └── 说明：设计构件抽象化、通用化、参数化，让人能轻松调整；调整不了就查文档改；实在不行就重做，别浪费大家时间
│ │ │ │ └── 组装构件
│ │ │ │ ├── 三种组装方式
│ │ │ │ │ ├── 功能法：按"任务"切分 → 做功能模块
│ │ │ │ │ ├── 数据法：按"数据结构"切分 → 围着数据写程序
│ │ │ │ │ └── 对象法：按"现实对象"切分 → 用类和对象复用代码
│ │ │ │ └── 组装失配问题
│ │ │ │ ├── 构件引起的失配
│ │ │ │ │ └── 说明：构件本身的设计有问题，比如它依赖的基础设施（如数据库）、控制逻辑（比如怎么启动）、数据模型（比如存什么字段）和其他构件冲突了
│ │ │ │ ├── 连接子引起的失配
│ │ │ │ │ └── 说明："连接子"就是构件之间的"接口"或"桥梁"。比如两个构件之间用的通信协议、数据格式、调用方式不一致，导致连不上或传错数据
│ │ │ │ └── 系统成分对全局体系结构的假设冲突
│ │ │ │ └── 说明：某个构件以为整个系统是小型的、单机的，结果实际是分布式、高并发的 → 它的假设错了 → 系统崩溃或性能差
│ │ └── 组装失配问题：由构件、连接子或系统对全局架构的假设冲突引起
│ └── 中间件
│ ├── 定义：中间件是一种独立的系统软件或服务程序，可以帮助分布式应用软件在不同的技术之间共享资源
│ ├── 本质：中间件是一类构件
│ ├── 采用优点
│ │ ├── 面向需求，集中业务逻辑
│ │ ├── 设计与实现隔离
│ │ ├── 隔离复杂系统资源
│ │ ├── 提供标准交互模型
│ │ ├── 支持软件复用
│ │ └── 提供对应用构件的管理
├── 1️⃣1️⃣ 软件架构复用
│ ├── 定义：软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程
│ ├── 软件元素包括：需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识等
│ ├── 一般形式的复用包括：函数的复用、库的复用、面向对象开发中的类、接口和包的复用
│ ├── 复用的历史发展路线
│ │ ├── 结构化时代：函数库
│ │ └── 面向对象时代：类库 → 构件库 → 服务库
│ ├── 软件架构复用的过程
│ │ ├── 1. 构造/获取可复用的软件资产
│ │ │ └── 要求：这些资产必须是可靠的、可被广泛使用的、易于理解和修改的
│ │ ├── 2. 管理这些资产
│ │ │ ├── 主要依赖：构件库
│ │ │ ├── 核心活动
│ │ │ │ ├── 构件分类
│ │ │ │ │ └── 说明：构件分类是指将数量众多的构件按照某种特定方式组织起来
│ │ │ │ ├── 构件检索
│ │ │ │ │ └── 说明：构件检索是指给定几个查询需求，能够快速准确地找到相关构件
│ │ │ │ └── 注：管理可复用资产过程中，存在两个关键问题------构件分类和构件检索
│ │ │ └── 注：管理可复用资产最重要的是构件库
│ │ └── 3. 针对特定的需求，从这些资产中选择可复用部分（使用可复用资产）
│ │ ├── 定义复用资产修改、扩展、配置
│ │ └── 组装集成系统
│ ├── 可复用资产范围
│ │ ├── 需求
│ │ ├── 架构设计
│ │ ├── 元素
│ │ ├── 建模与分析
│ │ ├── 测试
│ │ ├── 项目规划
│ │ ├── 过程、方法和工具
│ │ ├── 人员
│ │ ├── 样本系统
│ │ └── 缺陷消除
│ ├── 架构复用类型
│ │ ├── 机会复用
│ │ │ └── 开发过程中发现可以复用就复用
│ │ └── 系统复用
│ │ └── 开发之前就规划好可以复用哪些
│ └── 复用维度
│ ├── 水平复用
│ │ └── 说明：不分行业领域，通用。横向重用是指重用不同应用领域中的软件元素，例如数据结构、分类算法、人机界面构件等。通用算法库也是一种横向重用机制。水平式重用指的是通用领域的重用，如标准函数库，可以在任何软件项目中使用，不限于特定行业或领域
│ └── 垂直复用
│ └── 说明：分行业领域，专用。垂直式重用是指局限于某一垂直领域的重用，如电力系统专用构件
├── 1️⃣2️⃣ 现代架构演化与支撑技术
│ ├── 软件架构演化和定义的关系
│ │ ├── 在软件架构定义SA={组件，连接件，约束}中，约束组件和连接件之间的拓扑关系和配置
│ │ ├── 软件架构定义为SA={组件，连接件，约束}，其演化主要关注这三个要素的添加、修改与删除
│ │ ├── 软件架构的演化涵盖了软件架构的全生命周期，包括需求获取、建模、文档、实现和维护等阶段
│ │ ├── 软件架构演化的主要目的是为了使软件能够适应环境的变化而进行的纠错性修改和完善性修改
│ │ ├── 软件架构演化方式的分类
│ │ │ ├── A. 设计时演化：发生在体系结构模型和相关代码编译之前
│ │ │ ├── B. 运行前演化：在编译之后、执行之前
│ │ │ ├── C. 有限制运行时演化：是在系统运行时，在预设条件下进行的演化
│ │ │ ├── D. 运行时演化：在系统运行时进行的演化，包括添加、删除、升级替换组件等
│ │ │ └── 静态演化：设计时演化需求和运行前演化需求
│ │ ├── 软件的静态演化：软件理解步骤包括查阅软件文档，分析软件架构，识别系统组成元素及其之间的相互关系，提取系统的抽象表示形式
│ │ ├── 体系结构演化步骤：包含六个步骤，按顺序分别为需求变化归类、制订体系结构演化计划、修改、增加或删除构件、更新构件的相互作用、构件组装与测试、技术评审
│ │ ├── 演化成本：CoE << CoRD，其中CoE为演化成本，CoRD为重新开发成本
│ │ ├── 进度可控原则的度量方案：ttask = |Ttask - T`task|，其中ttask表示某个演化任务的实际完成时间与预期完成时间的时间差
│ │ ├── 主体维持原则：在软件架构演化过程中，主体维持原则要求软件演化的平均增量增长须保持平稳，以保证软件系统主体行为稳定。该原则的度量方案AIG（对称稳定增长）的计算公式是AIG = 主体规模的变更量 / 主体的规模
│ │ ├── 演化过程未知时的评估：在系统架构演化评估中，当演化过程未知时，评估人员主要采用的方法是根据架构演化前后的度量结果逆向推测架构变化
│ │ ├── 演化过程已知时的评估：在系统架构演化评估中，演化过程已知的评估主要通过比较架构内部结构差异和外部质量属性变化
│ │ └── 可维护性度量：包含6个子度量指标：圈复杂度、扇入扇出度、模块间耦合度、模块的响应、紧内聚度和松内聚度
│ │ ├── 扇入扇出度（FFC）：评估组件与其他组件之间接口关联或依赖关联的程度
│ │ ├── 模块间耦合度（CBO）：用于评估模块与其他模块交互频繁程度的度量指标
│ │ ├── 圈复杂度（CCN）：主要评估系统的复杂程度和控制流复杂性
│ │ ├── 模块的响应（RFC）：度量组件执行所需功能的数量
│ │ └── 建立隔离区域：主要目的是保障该区域中的修改对系统其他部分的影响最小化，甚至没有影响
│ ├── 面向对象软件架构演化过程
│ │ ├── 面向对象的设计模型包含：以包图表示的软件体系结构图，以交互图表示的用例实现图，完整精确的类图，针对复杂对象的状态图和用以描述流程化处理的活动图等
│ │ ├── 复合片段
│ │ │ ├── 定义：它是UML顺序图里的核心元素，用来描述对象间交互的控制逻辑（比如分支、循环、条件判断等），可以表示不同场景下的交互流程
│ │ │ ├── 示例：alt（分支）、loop（循环）、opt（可选）都属于复合片段
│ │ │ └── 序列片段中对象之间的消息类型包括：同步消息、异步消息、返回消息、参与者创建消息、参与者销毁消息
│ │ ├── FCC（Fragment Condition Change）
│ │ │ ├── 全称：Fragment Condition Change，复合片段条件变更
│ │ │ └── 定义：是软件架构演化里的一种操作，用来修改复合片段里的执行条件（比如把"条件A"改成"条件B"）
│ │ ├── 约束演化
│ │ │ └── 定义：就是系统升级、迭代时，对这些约束条件进行修改、增删的过程
│ │ ├── AO操作（Add Object）
│ │ │ ├── 全称：Add Object，在顺序图中添加新对象的系统演化操作
│ │ │ └── 示例：原来的订单流程只有「用户」和「订单系统」两个对象，现在为了做风控，新增了「风控系统」这个对象，这就是典型的AO操作
│ │ └── 消息演化操作对系统约束的影响划分
│ │ ├── 第1类演化：消息的增删改操作，不会直接影响或破坏现有的约束条件，属于"无约束影响"的演化
│ │ └── 第2类演化：消息的增删改操作，直接破坏了原有的约束条件，导致约束不再满足，属于"有约束影响"的演化
│ ├── 大型网站架构演化
│ │ ├── 阶段
│ │ │ ├── 第一阶段：单体架构
│ │ │ ├── 第二阶段：垂直架构（应用服务器与数据库分离）
│ │ │ ├── 第三阶段：使用缓存（MemCache、Redis、Squid）
│ │ │ ├── 第四阶段：使用服务集群（负载均衡）
│ │ │ │ ├── 负载均衡算法：静态（轮转、加权轮转、散列）、动态（最小连接数、加权最小连接数）
│ │ │ │ ├── 有状态 vs 无状态服务
│ │ │ │ └── Session共享方案：Cookie、服务器间同步、集中存储（Redis）
│ │ │ ├── 第五阶段：数据库读写分离
│ │ │ ├── 第六阶段：使用反向代理和CDN
│ │ │ ├── 第七阶段：分布式文件系统和分布式数据库
│ │ │ ├── 第八阶段：使用NoSQL和搜索引擎
│ │ │ ├── 第九阶段：业务拆分
│ │ │ └── 第十阶段：分布式服务
│ │ ├── 关键技术点
│ │ │ ├── 缓存与数据一致性（写数据库后更新/删除缓存）
│ │ │ ├── 缓存问题
│ │ │ │ ├── 雪崩（大部分缓存失效）：设置不同失效时间、加锁、二级缓存
│ │ │ │ ├── 穿透（查询无数据）：设置默认值、布隆过滤器
│ │ │ │ ├── 预热：上线时预加载
│ │ │ │ ├── 更新：定时清理、请求时判断
│ │ │ │ └── 降级：保证核心服务可用
│ │ │ ├── CDN：主要解决数据访问延迟问题
│ │ │ ├── Squid：实际上支持HTTPS协议。它是一个高性能的代理缓存服务器，支持FTP、gopher、HTTPS和HTTP协议
│ │ │ ├── 数据库拆分手段：是使用分布式数据库
│ │ │ ├── 数据库分片
│ │ │ │ ├── 范围分片
│ │ │ │ ├── 哈希分片
│ │ │ │ └── 一致性哈希分片
│ │ │ ├── 主从复制：Master写binlog → Slave读并写入中继日志 → Slave执行
│ │ │ ├── 无状态服务：不依赖其他请求，如身份认证、资源检索
│ │ │ ├── 有状态服务：依赖其他请求，如在线编辑
│ │ │ └── JWT：JSON Web Token，无状态认证，由头部、载荷、签名组成
│ ├── 大数据分层架构
│ │ └── 数据采集、存储、处理、分析、应用
│ ├── 响应式Web设计
│ │ ├── 理念：智能地根据用户行为和设备环境进行布局
│ │ └── 方法：流式布局、弹性化设计、响应式图片
│ └── 中台
│ ├── 定义：将企业核心能力以共享服务形式沉淀的架构和机制
│ ├── 类型：业务中台、数据中台、技术中台
│ └── 目的：支持前台业务快速创新
├── 1️⃣3️⃣ 软件文档
│ ├── 用户文档
│ │ ├── 定义：用户文档至少应该包括下述5方面的内容
│ │ ├── ① 功能描述：说明系统能做什么
│ │ ├── ② 安装文档：说明怎样安装这个系统以及怎样使系统适应特定的硬件配置
│ │ ├── ③ 使用手册：简要说明如何着手使用这个系统（通过丰富的例子说明怎样使用常用的系统功能，并说明用户操作错误是怎样恢复和重新启动的）
│ │ ├── ④ 参考手册：详尽描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）
│ │ └── ⑤ 操作员指南（如果需要有系统操作员的话）：说明操作员应如何处理使用中出现的各种情况
│ └── 系统文档
│ └── 定义：系统文档是从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是非常重要的质量属性与架构评估思维导图
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基础上建立，关注经济模型
└── 评估结果分析
└── 识别风险、非风险、敏感点、权衡点