# 架构
**Repository Path**: hey_hh/architecture
## Basic Information
- **Project Name**: 架构
- **Description**: 软考 - 架构设计师 知识点总结
- **Primary Language**: Unknown
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No
## Statistics
- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-04-08
- **Last Updated**: 2026-05-25
## Categories & Tags
**Categories**: Uncategorized
**Tags**: None
## README
# 软件架构概述
**架构是为完成某个特定任务所提供的软件规范，属于系统的顶层设计。**
## 架构的分类
### 按软件层划分
- 网络架构
- 系统架构
- 数据架构
- 业务架构
- 应用架构
- 平台架构
### 按解决的问题领域划分
- 电商架构
- 支付架构
- 搜索架构
- 安全架构
- 性能架构
- 游戏架构
- 多媒体架构
- 等
### 按工作深度划分
- 集成架构
- 业务架构
- 模块架构
- 框架架构
- 中间件架构
- 软件架构
- 引擎架构
- 服务器架构
- 编程语言架构
## 架构设计类型
架构设计可分为：
- 集中式架构
- 分层架构
- 分布式架构
- SOA架构
- 面向资源架构
## 进程间通信（IPC）
**进程间通信（IPC，Inter-Process Communication）** 指至少两个进程或线程间传送数据或信号的一些技术或方法。进程是计算机系统分配资源的最小单位。每个进程都有自己的一部分独立的系统资源，彼此是隔离的。为了能使不同的进程互相访问资源并进行协调工作，才有了进程间通信。这些进程可以运行在同一计算机上或网络连接的不同计算机上。
IPC 技术包括：
- 消息传递
- 同步
- 共享内存
- 远程过程调用
IPC 是一种标准的 Unix 通信机制。
### IPC 的两种类型
1. **本地过程调用（LPC）**
- 用于多任务操作系统中，使得同时运行的任务能互相会话。
- 这些任务共享内存空间使任务同步和互相发送信息。
2. **远程过程调用（RPC）**
- 类似于 LPC，但在网络上工作。
- 最初出现在 Sun 微系统公司和 HP 公司的 UNIX 操作系统中。
通过 IPC 和 RPC，程序能利用其它程序或计算机处理的进程。客户机/服务器模式计算把远程过程调用与消息传递等技术作为系统间通信的一种机制。
## 架构设计的目的
架构设计的主要目的是解决软件系统复杂度带来的问题。
## 网关扩展与任务分发
单个网关扩展成多个后，需要将任务分发给不同的网关。常见方法包括：
- DNS 轮询
- 智能 DNS
- CDN（内容分发网络）
- GSLB 设备（全局负载均衡）
## 高可用性
高可用通过**冗余备份**和**失效转移**实现。
## 设计原则
- 合适
- 简单
- 演化
## 微服务能力要求
每个微服务都应具备以下能力：
- 稳定性
- 可靠性
- 伸缩性
- 容错能力
- 高性能
- 可监控
- 文档化
- 灾备能力
## 补充说明
Kafka 支持消息顺序，但一台 Broker 宕机后会产生消息乱序。
# 软件架构核心模式精要
## 架构模式概览
| 架构模式 | 核心思想 | 优点 | 缺点 | 适用场景 |
| :--- | :--- | :--- | :--- | :--- |
| **单体架构** | 所有功能高度耦合，集中部署 | 简单、直接 | 难维护、难扩展 | 小型应用或初期项目 |
| **分层架构** | 按职责水平分离，上层调用下层 | 结构清晰、易管理 | 易产生层级耦合 | 传统企业级应用 |
| **微服务架构** | 按业务拆分为自治服务，松耦合 | 弹性、可扩展、技术灵活 | 分布式系统复杂 | 复杂的大型系统 |
| **事件驱动架构** | 组件通过事件异步通信 | 高扩展性、高响应性 | 最终一致性、复杂度高 | 实时系统、数据流处理 |
| **微核架构** | 核心系统 + 插件模块，动态扩展 | 灵活性好、隔离性强 | 契约设计复杂 | IDE、浏览器、可扩展应用 |
| **无服务器架构** | 函数为单位，事件触发，云托管 | 零运维、按需付费 | 冷启动、厂商锁定 | 事件驱动、突发任务 |
| **云架构** | 云环境设计原则集合，多模式综合 | 全球部署、高可用性 | 云厂商依赖 | 需要横向扩展的现代应用 |
## 详细说明
### 1. 单体架构
- **核心**: 所有功能模块高度耦合，集中开发、部署为一个整体
- **优点**: 简单、直接
- **缺点**: 难维护、难扩展
- **适用**: 小型应用或初期项目
### 2. 分层架构
- **核心**: 按职责（表现层、业务层、数据层）水平分离，上层调用下层。层之间通过接口通信。
- **优点**: 结构清晰、易管理
- **缺点**: 易产生层级耦合
- **适用**: 传统企业级应用
### 3. 微服务架构
- **核心**: 按业务能力拆分为小规模、自治的服务，松耦合、独立部署。常见模式：restful api模式、restful应用模式、集中消息模式
- **优点**: 弹性、可扩展、技术灵活
- **缺点**: 分布式系统复杂（网络、数据、运维）
- **适用**: 复杂的大型系统
### 4. 事件驱动架构
- **核心**: 组件通过事件异步通信，高度解耦。主要部件：事件、事件队列、分发器、事件通道、事件处理
- **优点**: 高扩展性、高响应性
- **缺点**: 最终一致性、复杂度高
- **适用**: 实时系统、数据流处理
### 5. 微核架构
- **核心**: 最小核心系统（插件引擎）+ 多个功能插件模块
- **优点**: 极强的灵活性和可扩展性
- **缺点**: 核心与插件契约设计复杂
- **适用**: IDE、浏览器、需要第三方扩展的应用
### 6. 无服务器架构
- **核心**: 以函数为单位运行，由事件触发，云平台托管基础设施
- **优点**: 零运维、按需付费、自动伸缩
- **缺点**: 冷启动、厂商锁定
- **适用**: 事件驱动型、突发负载任务
### 7. 云架构
- **核心**: 云环境中构建应用的设计原则集合，多模式综合。主要部分：处理单元、虚拟中间件
- **优点**: 全球部署、高可用性、成本优化
- **缺点**: 云厂商依赖、网络延迟
- **适用**: 需要横向扩展的现代应用
## 系统架构的常用建模方法
可以将分成4种:结构型、框架模型、动态模
型和过程模型。
1) **结构模型**:这是一个最直观、最普遍的建模方法。此方法以架构的构件、连接件和其他概念来刻画结构。通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格和性质。**研究结构模型的核心是架构描述语言。**
2) **框架模型**:框架模型与结构模型类似，但它不太侧重描述结构的细节，而**更侧重整体的结构**。框架模型主要以一些特殊的问题为目标建立只针对和适应问题的结构。
3) **动态模型**:动态模型是对结构或框架模型的补充，主要研究**系统的“大颗粒”行为的性质**。例如，描述系统的重新配置或演化。这里的动态可以是指系统总体结构的配置、建立或拆除通信或计算的过程这类系统模型常是激励型的。
4) **过程模型**:过程模型是研究构造系统的**步骤和过程**，其结构是遵循某些过程脚本的结果。
### 架构风格
| 架构风格 | 适用场景 |
| :------------------------------- | :----------------------------------------------------------------------- |
| 管道-过滤器风格 | 用于将系统分成若干独立的步骤 |
| 主程序/子系统和面向对象的架构风格 | 用于对组件内部进行设计 |
| 虚拟机风格 | 用于构造解释器或专家系统 |
| C/S和B/S风格 | 适合于数据和处理分布在一定范围,通过网络连接构成系统 |
| 平台/插件风格 | 用于具有插件扩展功能的应用程序 |
| MVC风格 | 用于用户交互程序的设计 |
| SOA风格 | 用在企业集成等方面 |
| C2风格(Component-Connector（组件-连接器）架构风格) | **用于GUI软件开发**,用以构建灵活和可扩展的应用系统等 |
### C2架构风格解析
| 特性维度 | 详细说明 |
| :--- | :--- |
| **全称** | Component-Connector（组件-连接器）架构风格 |
| **核心思想** | 通过严格的**组件层级规则**和**异步消息机制**实现松耦合 |
| **基本组成** | **组件**（独立计算单元） + **连接器**（消息路由组件） |
| **通信方式** | 组件间通过连接器进行**异步消息通知**（非直接调用） |
| **关键约束** | 1. 顶层组件不允许直接通信
2. 底层组件通信必须通过上层连接器
3. 组件间保持松耦合关系 |
| **主要优势** | • 极高的系统灵活性
• 良好的可扩展性
• 组件可独立替换和修改
• 支持并发处理 |
| **典型应用** | • **GUI应用程序开发**
• 需要高度灵活性的软件系统
• 可扩展应用框架 |
> C2风格通过严格的分层消息传递机制，为GUI系统提供了高度灵活和可扩展的架构解决方案，特别适合需要频繁交互和动态扩展的图形化应用场景。
### 安全攸关软件的安全性设计
**主要因素：目标、过程、数据**
#### 目标
| 等级 | 失效状态 | 简要说明 | 目标数量 |
| :--- | :----------- | :----------------------------------------------------------------------- | :------- |
| A级 | 灾难性的 | 软件异常会导致的后果是：航空器无法安全飞行和着陆 | 66 |
| B级 | 危害性的 | 软件异常会导致的后果是：严重降低了航空器或机组在克服不利运行情况时的能力 | 65 |
| C级 | 严重的 | 软件异常会导致的后果是：显著降低了航空器或机组在克服不利运行情况时的能力 | 56 |
| D级 | 不严重的 | 软件异常会导致的后果是：轻微降低了航空器或机组在克服不利运行情况时的能力 | 28 |
| E级 | 没有影响的 | 软件异常会导致的后果是：不会影响航空器或机组任何能力 | 0 |
#### 过程
* 软件计划过程(需求过程、设计过程、编码过程、集成过程)
* 软件开发过程
* 软件综合过程(验证过程、配置管理过程、质量保证过程、审定联络过程)
#### 数据
将生命周期中产生的**文档、代码、报表、记录**等所有产品统称为软件生命周期数据。
### 计算机网络
#### 功能
* 数据通信
* 资源共享
* 管理集中化
* 分布式处理
* 负载均衡
#### 指标
1. 性能指标
* 速率
* 带宽
* 吞吐量
* 时延(发送时延、传播时延、处理时延、排队时延)
* 往返时间(RTT)
* 利用率(信道利用率、网络利用率)
2. 非性能指标
* 费用
* 质量
* 标准化
* 可靠性
* 可扩展和可升级性
* 易管理性和维护性
# 通信技术
## 信道
* 物理信道 - 由传输介质和设备组成 - 有线信道、无线信道
* 逻辑信道 - 发送端、接收端间的虚拟线路
## 信道容量
```math
C = B*log_{2}(1+S/N)
```
- **C**代表信道容量，单位是 b/s
- **B**代表信号带宽，单位是 Hz
- **S**代表信号平均功率，单位是 W
- **N**代表噪声平均功率，单位是 W
- **S/N**代表信噪比，单位是 dB(分贝)
# 以太网
* 最大帧长1518字节(最大数据帧1500字节、最小帧长64字节-不足时加入填充位)
* 帧头设有32位用于CRC32校验(参与校验的是帧头中除前导字段和帧起始符之外的部分)
DMAC(目的MAC地址) - SMAC(源MAC地址) - Length/Type(2字节数据,值大于1500时代表数据帧类型,值小于1500则代表数据帧的长度) - Data/Pad(数据/填充字符) - FCS(帧校验字符)
# 无线局域网(WLAN)
* 以微波、激光、红外线等无线电波作为传输介质
* 假设WLAN需无线网卡和访问接入点AP
* 安装便捷、使用灵活、经济节约、易于扩展
# 广域网(WAN)
# 城域网(MAN)
* 主要技术:DQDB(由双总线构成) - IEEE802.6
## 5G
* 高速率、低时延、大连接
* 网络切片
## OSI
* 应用层
* 表示层
* 会话层
* 传输层 - TCP、UDP
* 网络层 - 路由器 - IP、ICMP、IGMP、ARP、RARP
* 数据链路层 - 网桥、交换机(自动寻址与交换、避免端口冲突、提高网络吞吐)
* 物理层 - 中继器(识别信号然后再生信号，可以连接不同物理介质)
## TCP/IP
* 应用层(应用层、表示层、会话层)
* 传输层(传输层)
* 网络层(网络层)
* 网络接口层(数据链路层、物理层)
## 交换机 - 数据链路层
### 功能
* 集线功能
* 中继功能 - 转发帧时重新生成不失真的信号
* 桥接功能
* **隔离冲突域**
### 原理
* 转发路径学习 - 记录数据帧中的源MAC地址建立MAC地址表
* 数据转发 - 根据MAC地址表进行转发
* 数据泛洪 - MAC地址表不存在时想所有端口转发(不包含源端口)
* 链路地址更新 - MAC地址表每隔一定时间更新一次(如300s)
### 协议
* 生成树协议STP - 避免环路
* 链路聚合 - 提高带宽、提升链路可靠性
## 路由器 - 网络层
* 在多个网络上交换和路由数据包
* 根据信道情况自动选择和设定路由
* 按最佳路径、先后顺序发送信号
* 路由表 - 包含网络目的地址、端口、下一跳地址、发送代价
### 协议
* 内部网关协议IGP
* RIP-1、RIP-2 路由信息协议，基于距离矢量算法的路由协议，利用跳数作为计量标准
* IGRP - 内部网关路由协议 - 思科的专有协议
* EIGRP - 增强型IGRP，拓扑结构变化时才发送路由更新
* IS-IS - 中间系统到中间系统，基于链路状态路由协议
* OSPF - 开放式最短路径优先，属于链路状态路由协议。提出了区域的概念
* 外部网关协议EGP
* BGP协议
# 网络工程
* 网络规划
* 网络设计
* 网络实施
# UML
## 常用图
* 用例图
由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述**系统功能**的视图。用例之间的关系有包含、扩展、泛化。
* 类图
展现了一组**对象、接口、协作**和它们之间的关系。类之间的关系有**关联、依赖、实现、泛化**。
* 对象图
描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的**静态快照**。
* 构件图
描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的**内部结构**。
* 组合结构图
用于画出**结构化类**的内部内容。
* 顺序图（序列图）
由一组对象或参与者以及它们之间可能发送的消息构成。强调消息的**时间次序**的交互图。
* 通信图
强调收发消息的对象或参与者的结构组织。强调的是对象之间的**组织结构（关系）**。
* 定时图
强调消息跨越不同对象或参与者的**实际时间**，而不仅仅只是关心消息的相对顺序。
* 状态图
用来描述一个特定的对象所有可能的状态，以及由于各种事件的发生而引起的**状态**之间的**转移**和变化。
* 活动图
将进程或其他计算的结构展示为计算**内部**一步步的**控制流和数据流**。可并行。
* 部署图
软件和硬件组件之间的**物理关系**以及处理节点的组件分布情况。
* 制品图
描述计算机中一个系统的**物理结构**通常与部署图一起使用。
* 包图
描述由模型本身**分解**而成的组织单元，以及它们之间的依赖关系。
* 交互概览图
是活动图和顺序图的**混合物**
## UML系统架构视图与对应图表
| 视图 | 要点描述 | 图形表示 | 关心人员 |
| :--- | :--- | :--- | :--- |
| **用例视图** | 描述系统的***功能需求***，系统功能模型 | 用例图 | 客户、分析者、设计者、开发者和测试者 |
| **逻辑视图** | 描述如何实现系统内部的功能，系统的**静态结构**和应发送消息而出现的动态协作关系 | 类图、对象图、状态图、顺序图、协作图和活动图 | 系统分析和设计人员 |
| **进程视图** | 描述系统的***并发性***，并处理这些线程间的通信和同步；它将系统分割成并发执行的控制线程及处理这些线程的通信和同步 | 状态图、顺序图、协作图、活动图、构件图和部署图 | 开发者和系统集成者 |
| **实现视图** | 描述系统代码构件组织和实现模块及它们之间的依赖关系 | 构件图 | 设计者、开发者和测试者 |
| **部署视图** | 定义系统中软硬件的物理体系结构及连接、哪个程序或对象驻留在哪台计算机上执行 | 部署图 | 开发者、系统集成者和测试者 |
> **注**：用例视图是系统的中心视图，它定义了系统的外部行为，是其他视图的核心和基础。
# 多媒体概述
**媒体**是承载信息的载体，即信息的表现形式（如文字、声音、图像、动画、视频等）。
媒体分为以下五类：
### ① 感觉媒体
- **定义**：指用户接触信息的感觉形式，直接作用于人的感官，产生感觉（视、听、嗅、味、触觉）的媒体。
- **举例**：视觉、听觉、触觉。
### ② 表示媒体
- **定义**：指信息的表示形式。感觉媒体转换成表示媒体后，能够在计算机上进行加工处理和传输。
- **举例**：图像、声音、视频等。
### ③ 表现媒体（显示媒体）
- **定义**：表现和获取信息的物理设备。
- **分类举例**：
- **输入表现媒体**：键盘、鼠标、扫描仪、话筒、数码相机、摄像机。
- **输出表现媒体**：显示器、打印机、音箱、投影仪。
### ④ 存储媒体
- **定义**：用于存储表示媒体的物理介质。
- **举例**：硬盘、软盘、光盘、ROM 及 RAM 等。
### ⑤ 传输媒体
- **定义**：传输表示媒体（即数据编码）的物理介质。
- **举例**：电缆、光缆、电磁波等。
-
# 系统工程
**为了最好地实现系统，对系统组成要素、组织结构、信息流、控制机构等进行分析研究的科学方法**
## 目的
* 最优规划
* 最优设计
* 最优管理
* 最优控制
## 系统工程方法
* 霍尔的三维结构：用于组织喝管理大型工程建设项目
* 时间维度：系统工程活动从开始到结束按时间顺序排列的全过程
* 规划
* 拟定方案
* 研制
* 生产
* 安装
* 运行
* 更新
* 逻辑维度：时间维度的每个阶段内要进行的工作内容喝应该遵循的思维程序
* 明确问题
* 确定目标
* 系统综合
* 系统分析
* 优化
* 决策
* 实施
* 知识维度：专业科学知识
* 切克兰德方法
P.切克兰德把霍尔方法论称为“硬科学”方法论，他自己的方法论称为“软科学”方法论。 **其核心不是“最优化”，而是“比较”与“探寻”。**
* 工作过程
* 认识问题
* 根底定义
* 建立概念模型
* 比较及探寻
* 选择
* 设计与实施
* 评估与反馈。
* 并行工程方法：对产品及相关过程进行并行、集成化处理的系统方法和综合技术
* 产品的设计开发期间，以最快的速度按要求的质量完成。
* 各项工作由此相关的项目小组完成，对出现的问题协调解决。
* 依据适当的信息系统工具
* 综合集成法：分为简单系统和巨系统
* 整体论原则
* 相互联系原则
* 有序性原则
* 动态原则
* WSR系统方法：物理、事理、人理方法论的简称
* 理解意图
* 制定目标
* 调查分析
* 构造策略
* 选择方案
* 协调关系
* 实现构想
## 生命周期
* 探索性研究阶段 — 识别利益攸关者的需求，探索创意和技术。
* 概念阶段 — 细化利益攸关者的需求，探索可行概念，提出有望实现的解决方案。
* 开发阶段 — 细化系统需求，创建解决方案的描述，构建系统，验证并确认系统。包括详细计划、开发和验证与确认（V&V）活动。完全自主地选择开发模型，并不局限于瀑布或其他计划驱动的方法。
* 生产阶段 — 生产系统并进行检验和验证。
* 使用阶段 — 运行系统以满足用户需求。
* 保障阶段 — 提供持续的系统能力。
* 退役阶段 — 存储、归档或退出系统。
# 计算机性能评估方法
## 时钟频率法
- 计算机的时钟频率在一定程度上反映了机器速度
- 对同一种机型的计算机，时钟频率越高，计算机的工作速度就越快
## 指令执行速度法
- 用加法指令的运算速度来衡量计算机的速度
- 表示机器运算速度的单位是MIPS
## 等效指令速度法
- 考虑指令比例不同，也称为吉普森或混合比例算法
- 通过各类指令在程序中所占的比例进行计算后得到的计算机运算速度
## 数据处理速率法（PDR）
- 采用计算PDR值的方法来衡量机器性能，PDR值越大，机器性能越好
- PDR与每条指令和每个操作数的平均位数以及每条指令的平均运算速度有关
- PDR主要对CPU和主存储器的速度进行度量
- 不适合衡量机器的整体速度
- 不能全面反映计算机的性能
- 没有涉及Cache、多功能部件等技术对性能的影响
- 考虑：CPU+存储器
## 综合理论性能法
- 首先计算出处理部件每个计算单元的有效计算率
- 按不同字长加以调整，得出该计算单元的理论性能
- 所有组成该处理部件的计算单元的理论性能之和即为最终的计算机性能
## 基准程序法
- 经典评估方法主要是针对CPU（有时包括主存）的性能
- 没有考虑诸如I/O结构、操作系统、编译程序的效率等对系统性能的影响
- 难以准确评估计算机系统的实际性能
- 把应用程序中用得最多、最频繁的那部分核心程序作为评估计算机系统性能的标准程序
- 这类标准程序称为基准测试程序（benchmark）
- 是目前一致承认的测试系统性能的较好方法
# 系统工程
## 生命周期阶段及方法
* 计划驱动方法 -- 系统化方法
* 需求
* 设计
* 构建
* 测试
* 部署范式
* 渐进迭代式开发（IID）
* 允许为项目提供初始能力，随之提供连续交付以达到期望的系统
* 目标在于**快速生产价值**并**提供快速响应能力**。
* 需求不清晰不确定或客户希望在系统中引入新技术时可以使用IID方法。基于一系列最初的假设开发候选的系统，然后对其评估以确定是否满足用户需求。**若不满足则开启另一轮演进**，直到交付的系统满足利益攸关者的要求。
* **适用于较小的、不太复杂的系统**。
* 精益开发
* 聚焦于向客户交付最大价值并使浪费活动最小化
* 动态的、知识驱动的、以客户为中心的过程，通过这一过程使特定企业的所有人员以创造价值为目标不断地消除浪费。
* 敏捷开发
* 关键目标在于**灵活性**
## 基于模型的系统工程(MBSE)
建模方法的形式化应用，以使建模方法支持系统需求、分析、设计、验证和确认等活动，这些活动从概念性设计阶段开始，**持续贯穿到设计开发以及后来的所有生命周期阶段。**
系统工程过程的三个阶段分别产生三种图形
需求分析阶段，产生需求图、用例图、包图
功能分析阶段与分配阶段，产生顺序图、活动图、状态机图
设计综合阶段，产生模块定义图、内部块图、参数图等
**MBSE的三大支柱分别是建模语言、建模工具、建模思路。**
## 阿姆达尔方法：采用了某种部件后取得的加速比
加速比=未使用增强部件时执行时间/使用增强组件后的执行时间。
例：某一功能执行时间为整个系统运行时间的60%，若使改功能的处理速度提高五倍，根据阿姆达尔定律，整个系统的处理速度可以提高1.923倍。
```math
\frac{1}{\frac{0.6}{5} + 0.4} = 1.923
```
## 性能指标
### 服务器性能指标
| 单位名称 | 缩写 | 数值（次/秒） | 中文读法 | 典型应用场景 |
|:---|:---|:---|:---|:---|
| **FLOPS** | FLOPS | 10⁰ | 次 | 单个运算的基础单位 |
| **千FLOPS** | KFLOPS | 10³ | 千次 | 早期计算器、简单微控制器 |
| **百万FLOPS** | MFLOPS | 10⁶ | 百万次 | 早期个人电脑、嵌入式系统 |
| **十亿FLOPS** | GFLOPS | 10⁹ | 十亿次 | 现代消费级CPU、智能手机 |
| **万亿FLOPS** | TFLOPS | 10¹² | 万亿次 | **现代高性能GPU、游戏主机、AI入门卡** |
| **千万亿FLOPS** | PFLOPS | 10¹⁵ | 千万亿次 | 2010年代的大型超级计算机、大型AI训练集群 |
| **百亿亿FLOPS** | EFLOPS | 10¹⁸ | 百亿亿次 | **当前（2020年代中期）最先进的E级超级计算机** |
| **十万亿亿FLOPS** | ZFLOPS | 10²¹ | 十万亿亿次 | 规划中的下一代超算与AI集群（如华为Atlas 960） |
| **一亿亿亿FLOPS** | YFLOPS | 10²⁴ | 一亿亿亿次 | 远期未来概念 |
#### 注解
* FLOPS单位的递增采用10³（即1000倍）
* 国际标准规定：对于所有表示速率的单位，国际标准（如ISO/IEC 80000）明确规定必须使用国际单位制（SI）的词头，即基于10的幂次（千-K, 兆-M, 吉-G...艾-E），也就是10³的倍数递增。这保证了全球科学和工程领域的一致性。
#### 存储容量单位问题
存储容量用1024（2¹⁰）作为进率，并创造了KiB、MiB等二进制单位，导致了长期的混淆。
如今，标准做法是：
存储容量：严格区分 SI十进制单位（KB, MB, GB， 基于1000）和 二进制单位（KiB, MiB, GiB， 基于1024）。硬盘厂商通常使用十进制，而操作系统可能显示为二进制。
### OPS和FLOPS核心区别
| 特性 | **OPS** | **FLOPS** |
| :--- | :--- | :--- |
| **核心衡量对象** | **整数操作**（如INT8, INT4） | **浮点数运算**（如FP32, FP16, FP64） |
| **主要应用场景** | AI推理、专用加速芯片
（如NPU、TPU、自动驾驶芯片） | 科学计算、图形渲染、AI训练
（如CPU、GPU） |
| **关键特点** | 贴近AI模型的低精度整数计算，一次乘加(MAC)常计为2次操作，能直接反映AI任务执行速度。 | 衡量计算精度的传统标准，在需要高数值精度的场景中至关重要。 |
**主要结论**：
- **OPS衡量“操作数”（主整数），FLOPS衡量“浮点运算数”**。
- 在**AI推理**和**专用加速芯片**领域，**TOPS**是更直接、更相关的性能指标，因为低精度整数计算可在保证精度的同时显著提升能效。
# 补充 - 进程状态
## 一、进程的三态模型
指进程在内存中的三种基本状态及其转换：
| 状态 | 说明 |
|------|------|
| **运行态 (Running)** | 进程正在 CPU 上执行 |
| **就绪态 (Ready)** | 进程已具备运行条件，等待分配 CPU |
| **阻塞态 (Blocked)** | 进程因等待某事件（如 I/O）而暂停执行 |
### 状态转换与触发条件：
- **就绪 → 运行**：进程调度程序选中（分配 CPU）
- **运行 → 就绪**：时间片用完、或被更高优先级进程抢占
- **运行 → 阻塞**：请求资源未到位、等待 I/O 完成等
- **阻塞 → 就绪**：所等待的事件发生（如 I/O 完成）
---
## 二、进程的五态模型
在三态基础上增加 **新建 (New)** 与 **终止 (Terminated)** 状态，有时还包含 **挂起 (Suspend)** 相关状态（图中涉及中级调度与挂起）：
| 状态 | 说明 |
|------|------|
| **新建** | 进程刚被创建，尚未进入就绪队列 |
| **就绪** | 同三态模型 |
| **运行** | 同三态模型 |
| **阻塞** | 同三态模型 |
| **终止** | 进程执行结束，等待系统回收资源 |
### 扩展状态（涉及挂起）：
- **就绪/挂起**：进程被调到外存，但仍具备运行条件
- **阻塞/挂起**：进程被调到外存，且仍在等待事件
### 五态转换常见触发：
- **新建 → 就绪**：系统完成进程创建并加入就绪队列
- **运行 → 终止**：进程执行结束或强制终止
- **挂起相关转换**：通常由中级调度（内存兑换）引起
---
## 三、三级调度与状态模型的关系
### 1. 高级调度（作业调度）
- **作用**：从外存后备队列中选择作业调入内存，为其创建进程。
- **适用系统**：**批处理系统**（作业需先驻留外存，再调入内存）。
- **分时/实时系统**：通常不需要高级调度。
### 2. 中级调度（内存调度）
- **作用**：将进程在内存与外存之间交换（挂起/激活），以平衡系统负载。
- **与五态模型的关系**：涉及 **挂起状态**（就绪挂起、阻塞挂起）的转换。
### 3. 低级调度（进程调度）
- **作用**：从就绪队列中选择进程分配 CPU。
- **与状态模型的关系**：负责 **就绪 → 运行** 的转换，是三态模型中的核心调度。
三态模型是在内存中的模型，如果任务比较简单、数量少可以存储在内存中使用三态模型即可。 在多道程序的模型中使用五态模型更清晰，避免资源混乱。在内存、外存中分别存储活跃、不活跃的数据，这样可以加载更多的任务。
# 流水线问题整理
## 1. 吞吐率
吞吐率 (Throughput) 指单位时间内流水线完成的任务数量。
**公式：**
吞吐率=指令条数/流水线执行时间
其中：
- 指令条数：完成的任务总数
- 流水线执行时间：完成所有任务所用的总时间
## 2. 最大吞吐率
最大吞吐率是当任务数趋于无穷大时，流水线所能达到的极限吞吐率，也就是cycle(时钟周期（每段最长操作时间）)的倒数。
**公式：**
$TP_{\max} = \lim_{n \to \infty} \frac{n}{(k + n - 1) \Delta t} = \frac{1}{\Delta t}$
其中：
- $TP_{\max}$：最大吞吐率
- $n$：任务数
- $k$：流水线的段数
- $\Delta t$：时钟周期（每段最长操作时间）
## 3. 加速比
加速比 (Speedup) 用于衡量流水线相对于顺序执行带来的性能提升效果。
**定义：**
$S = \frac{\text{不使用流水线执行时间}}{\text{使用流水线执行时间}}$
- $S$：加速比
- 该比值越大，说明流水线带来的性能提升越显著。
## 4. 超标量流水线
超标量流水线是一种并行处理技术，通过**重复设置多个功能部件**，使得在一个时钟周期内可以并发执行多条指令。
**关键点：**
- 一般为 **m度** 的流水线，即有多个指令发射通道。
- 相当于多条流水线同时运作，提高了指令级的并行性。
## 5. 流水线的效率
流水线的效率 (Efficiency) 反映了流水线中各部件的利用率。
**定义：** 流水线的设备利用率。在时空图上，效率 $E$ 的计算公式为：
$E = \frac{n\text{个任务占用的时空区}}{k\text{个流水段的总时空区}}$
其中：
- $n$：任务数
- $k$：流水线段数
- 效率的值在0到1之间，值越高表示流水线设备的利用率越高。
# CISC和RISC
| 指令系统类型 | 指令 | 寻址方式 | 实现方式 | 其它 |
| --- | --- | --- | --- | --- |
| CISC（复杂） | 数量多，使用频率相差很大、可变定长 | 多种寻址方式 | 微程序控制技术 | 周期长，指令直接在主存处理，执行速度慢 |
| RISC（精简） | 数量少，使用频率相近，定长格式，大部分为单周期指令，只有LOAD/Store操作内存 | 支持方式少 | 增加了通用寄存器；硬布线逻辑控制为主；适合采用流水线。 | 优化编译，对编译的要求高，支持高级语言 |
# 校验码
## 海明码的原理
在数据中间加入几个校验码，码距均匀拉大，当某一位出错时，会引起几个校验位的数值发生变化
### (1) 海明不等式：
2^r>=r+m+1
- r 为校验码的位数
- m 为信息位的个数
- r+m 为编码后数据的总长度
如果满足不等式，那么理论上 k 个校验码就可以判断是哪一位出现了问题
### (2) 海明码的编码规则
校验码存放在 2^n 的位置（1、2、4、8等），其余位置为信息位。
# 海明码计算示例
## 示例：对信息位`1010`进行海明编码
### 已知条件
- 信息位（Data bits）: 4位 (m = 4)，具体为 `D3 D2 D1 D0 = 1 0 1 0`
- 根据海明不等式 2^r>=r+m+1 得，需要校验位 r = 3
- 总码长：`n = m + r = 7` 位
### 第一步：确定校验位位置
- 校验位（Parity bits）`P1, P2, P3` 放在 $2^n$ 的位置，即第1、2、4位。
- 位置编号（从1到7）：
位置: 1 2 3 4 5 6 7
归属: P1 P2 D3 P4 D2 D1 D0
数值: ? ? 1 ? 0 1 0
*注：有时校验位用$P_i$表示，有时用位置号表示，此处P4即校验位P3。*
### 第二步：计算每个校验位的监督范围
校验位负责监督其位置号在二进制表示中“某一位为1”的所有位置。
- **P1 (位置1，二进制001)**：监督所有位置号二进制**第0位为1**的位置（即奇数位）。
- 位置：1, 3, 5, 7
- 监督的数据位：`D3`(位3=1), `D2`(位5=0), `D0`(位7=0)
- 计算P1（偶校验）：`P1 ⊕ D3 ⊕ D2 ⊕ D0 = 0`
`P1 ⊕ 1 ⊕ 0 ⊕ 0 = 0` -> `P1 = 1`
- **P2 (位置2，二进制010)**：监督所有位置号二进制**第1位为1**的位置。
- 位置：2, 3, 6, 7
- 监督的数据位：`D3`(位3=1), `D1`(位6=1), `D0`(位7=0)
- 计算P2（偶校验）：`P2 ⊕ D3 ⊕ D1 ⊕ D0 = 0`
`P2 ⊕ 1 ⊕ 1 ⊕ 0 = 0` -> `P2 = 0`
- **P4/P3 (位置4，二进制100)**：监督所有位置号二进制**第2位为1**的位置。
- 位置：4, 5, 6, 7
- 监督的数据位：`D2`(位5=0), `D1`(位6=1), `D0`(位7=0)
- 计算P4（偶校验）：`P4 ⊕ D2 ⊕ D1 ⊕ D0 = 0`
`P4 ⊕ 0 ⊕ 1 ⊕ 0 = 0` -> `P4 = 1`
### 第三步：得到完整海明码
将校验位填入：
位置: 1 2 3 4 5 6 7
归属: P1 P2 D3 P4 D2 D1 D0
数值: 1 0 1 1 0 1 0
**最终7位海明码为：`1 0 1 1 0 1 0`**
### 第四步：检错与纠错（示例）
若接收到的码字为 `1 0 1 1 0 0 0`（假设第6位`D1`出错，由1变0）。
1. 重新计算校验和（偶校验）：
- **S1 = P1 ⊕ D3 ⊕ D2 ⊕ D0** = `1 ⊕ 1 ⊕ 0 ⊕ 0 = 0`? 计算：`1⊕1=0`, `0⊕0=0`, `0⊕0=0`。正确，应为0。
- **S2 = P2 ⊕ D3 ⊕ D1 ⊕ D0** = `0 ⊕ 1 ⊕ 0 ⊕ 0 = 1`
- **S4 = P4 ⊕ D2 ⊕ D1 ⊕ D0** = `1 ⊕ 0 ⊕ 0 ⊕ 0 = 1`
2. 组成错误字 `S4 S2 S1 = 1 1 0` (二进制)，对应十进制为 **6**。
3. 这表明**第6位**出错，将其取反即可纠正。
- 第6位是`D1`，从0纠正为1，得到正确码字 `1 0 1 1 0 1 0`。
**总结**：通过三个校验位，该(7,4)海明码可以检测并纠正任意1位错误。
# CRC 循环冗余校验码
## 1. 基本概念
- **全称**：Cyclic Redundancy Check
- **本质**：一种基于多项式除法的差错检测方法
- **用途**：主要用于**检错**，检错能力极强，不用于纠错
- **特点**：检测突发错误能力强，计算效率高
## 2. 核心计算步骤（二进制模2运算）
**模2运算规则**：
- 加减法 = 异或（XOR，⊕），不进位，不借位
- 乘法 = 与运算，加法用异或
- 除法是核心运算
---
## 3. 详细计算步骤
### 第1步：确定生成多项式
将生成多项式转换为二进制形式
- 例如：`G(x) = x^4 + x + 1`
- 对应二进制：`1·x^4 + 0·x^3 + 0·x^2 + 1·x^1 + 1·x^0`
- 二进制表示：`10011`（5位）
### 第2步：在数据后补0
- 补0个数 = 生成多项式位数 - 1
- 数据 D = `110101`，G = `10011` (5位)
- 补0个数 = 5 - 1 = 4
- 补0后：`1101010000`
### 第3步：模2除法运算
### 第4步：得到CRC码
- 余数 R = `0011`（4位）
- 发送码 = 数据 + CRC码 = `1101010011`
### 第5步：接收端验证
接收端用同样的生成多项式除接收到的数据
- 余数为0：数据正确
- 余数不为0：数据有误
---
## 4. 常见生成多项式标准
| 名称 | 多项式表示 | 二进制/十六进制 | 应用领域 |
| :--- | :--- | :--- | :--- |
| **CRC-4** | x⁴ + x + 1 | 0x3 | ITU-T G.704 |
| **CRC-8** | x⁸ + x² + x + 1 | 0x107 | ATM头部校验 |
| **CRC-12** | x¹² + x¹¹ + x³ + x² + x + 1 | 0x180F | 字符流传输 |
| **CRC-16-IBM** | x¹⁶ + x¹⁵ + x² + 1 | 0x8005 | Modbus, USB |
| **CRC-16-CCITT** | x¹⁶ + x¹² + x⁵ + 1 | 0x1021 | Bluetooth, X.25 |
| **CRC-32** | x³² + x²⁶ + x²³ + ... + 1 | 0x04C11DB7 | Ethernet, ZIP, PNG |
| **CRC-32C** | x³² + x²⁸ + x²⁷ + ... + 1 | 0x1EDC6F41 | iSCSI, SCTP |
---
## 5. 检错能力分析
| 错误类型 | 检测能力 |
| :--- | :--- |
| **单比特错误** | 100%检测 |
| **双比特错误** | 100%检测（如果生成多项式有(x+1)因子） |
| **奇数个错误** | 100%检测（如果生成多项式有(x+1)因子） |
| **突发错误** | 长度 ≤ (k-1) 的突发错误：100%检测 |
| **较长突发错误** | 长度 > (k-1) 的突发错误：检测概率 1-2⁻⁽ᵏ⁻¹⁾ |
**注**：
- k = 生成多项式的阶数（位数-1）
- 对于CRC-32，未检测出的错误概率约为 2⁻³¹ ≈ 4.66×10⁻¹⁰
---
## 6. 实际应用注意事项
### 6.1 常见变体参数
实际CRC计算可能包含以下参数：
- **初始值**：计算前的寄存器初值
- **输入反转**：输入数据是否反转
- **输出反转**：计算结果是否反转
- **异或输出**：最终结果是否与特定值异或
### 6.2 优化实现
1. **查表法**：预先计算好的256项查找表，大幅提升计算速度
2. **硬件加速**：现代CPU有CRC指令（如x86的`crc32`指令）
3. **并行计算**：多位同时计算
## 7. 关键要点总结
1. **核心原理**：基于模2除法，在数据后附加校验码
2. **核心公式**：
- 发送端：`T(x) = D(x)·x^k + R(x)`
- 接收端：计算 `T'(x) mod G(x) = 0` 则正确
3. **余数位数** = 生成多项式位数 - 1
4. **补0个数** = 余数位数
5. **计算规则**：模2运算（异或运算）
6. **主要用途**：检错，不纠错
7. **选择依据**：
- 数据长度
- 检错要求
- 计算资源
- 标准兼容性
# 输入输出问题
## I/O 工作方式对比
| 工作方式 | 子类型 | 特点 |
| :--- | :--- | :--- |
| **程序控制**（占用CPU时间最长） | 无条件传送 | I/O端口总是准备好，CPU在需要时，随时直接利用访问相应的I/O端口。 |
| | 程序查询 | CPU必须不停地测试I/O设备的状态端口。CPU与I/O设备是串行工作的。 |
| **中断** | — | 某个进程要启动某个设备时，CPU就向相应的设备控制器发出一条设备I/O启动指令，然后CPU又返回做原来的工作。CPU与I/O设备可以并行工作。 |
| **DMA（直接内存存取）** | — | 为了在主存与外设之间实现高速、批量数据交换而设置。通过DMA控制器直接进行批量数据交换，除了在数据传输开始和结束时，整个过程无须CPU的干预。 |
## 通道方式与 I/O 处理机
- **定义**：I/O通道控制方式是一种特殊的**处理机**，它具有执行I/O的能力。
- **功能特点**：
- 功能比较单一，只执行I/O操作。
- 通道没有自己的内存，与CPU共享内存。
- **三种通道类型**：
1. 字节多路通道
2. 数组选择通道
3. 数组多路通道
# 补充-网络规划设计
## 一、网络规划设计阶段划分
网络规划设计分为 **5个核心阶段**，按顺序推进，将需求逐步转化为可实施的物理网络：
`需求分析` → `通信规范分析` → `逻辑网络设计` → `物理网络设计` → `实施阶段`
## 二、各阶段详细说明
### 1. 需求分析阶段
- **核心目标**：明确网络的多维度需求（业务、用户、应用、平台、通信等）。
- **主要内容**：
- 业务需求：网络需支撑的业务场景（如办公、生产、娱乐等）。
- 用户需求：不同角色用户的使用诉求（如访问速度、并发量、权限等）。
- 应用需求：业务应用对网络的要求（如低延迟、高带宽、可靠性等）。
- 计算机平台需求：服务器、终端等硬件/软件平台的适配需求。
- 网络通信需求：带宽、时延、吞吐量、拓扑结构等通信指标。
- **产物**：`需求规范（需求说明书）`
### 2. 通信规范分析阶段
- **核心目标**：分析现有网络体系，评估通信量与设备利用率，为后续设计提供数据支撑。
- **主要内容**：
- 现有网络体系分析：梳理当前网络架构、设备、协议等。
- 通信量估计：预测业务高峰、日常流量的规模与分布。
- 设备利用率测量：评估现有网络设备的负载能力（如交换机、路由器的CPU/带宽占用率）。
- **产物**：`通信规范`
### 3. 逻辑网络设计阶段
- **核心目标**：将抽象需求转化为**网络逻辑结构**（拓扑、协议、IP规划等），不涉及物理位置。
- **主要内容**：
- 设计网络逻辑架构（如星型、环型、树型拓扑）。
- 确定网络协议（如TCP/IP、OSPF、VLAN等）、IP地址规划、子网划分策略。
- 规划网络安全、QoS（服务质量）、路由策略等逻辑层面设计。
- 输出内容需包含：
① 逻辑网络设计图；
② IP 地址方案；
③ 安全方案；
④ 具体的软件、硬件、广域网连接设备和基本的服务；
⑤ 雇佣和培训新网络员工的具体说明；
⑥ 初步对软件、硬件、服务、网络雇佣员工和培训的费用估计。
- **产物**：`逻辑设计文档`
### 4. 物理网络设计阶段
- **核心目标**：将逻辑设计落地到**物理空间**，确定实际的网络物理结构（设备、布线、安装等）。
- **主要内容**：
- 确定网络设备选型（如交换机、路由器、服务器、终端等）。
- 设计物理拓扑（如机房布局、线缆走向、设备安装位置）。
- 规划传输介质（如光纤、双绞线、无线频段）、电源、散热等物理资源。
- 输出内容需包含：
① 物理网络图和布线方案；
② 设备和部件的详细列表清单；
③ 软件、硬件和安装费用的估计；
④ 安装日程表（详细说明实际和服务中断的时间及期限）；
⑤ 安装后的测试计划；
⑥ 用户培训计划。
- **产物**：`物理结构设计文档`
### 5. 实施阶段
- **核心目标**：实现物理网络设计，完成网络的安装、调试与维护。
- **主要内容**：
- 按照物理设计文档采购、安装设备和布线。
- 进行网络调试、测试，确保逻辑与物理设计的一致性。
- 上线运行后，持续监控、维护和优化网络。
## 三、逻辑与物理设计阶段对比
| 阶段 | 核心关注点 | 是否涉及物理位置 | 输出重点 |
|------|------------|------------------|----------|
| 逻辑网络设计 | 网络行为、性能、数据传输逻辑 | 否 | 逻辑架构、IP方案、安全策略、服务规划、人员培训及费用估计 |
| 物理网络设计 | 物理实现（设备、布线、安装） | 是 | 物理拓扑、设备清单、费用估计、安装计划、测试与培训计划 |
# 网络规划设计：分层设计
## 网络分层架构
现代网络常采用分层架构设计，各层分工明确，协同工作。典型的层次结构（从上至下/从外至内）为：
`出口层` → `核心层` → `汇聚层` → `接入层`。
数据流动通常从 **接入层** 的用户端发起，向上经过 **汇聚层** 聚合，由 **核心层** 高速转发，最终通过 **出口层** 访问外部互联网（ISP）。
## 各层功能详解
| 层级 | 主要功能 | 说明与特点 |
| :--- | :--- | :--- |
| **出口层** | 连接不同的互联网服务提供商（ISP）。 | 网络对外的总出口，实现与Internet的互联。通常采用多ISP链路以实现冗余和负载均衡，提高出网的可靠性与性能。 |
| **核心层** | 高速数据交换、高速数据传输、出口路由，常采用冗余机制。 | 网络的骨干和中枢，专注于高速、可靠的数据转发。设计强调高带宽、低延迟和高可用性（如设备冗余、链路冗余），通常在此层避免复杂的策略控制，以保证交换效率。 |
| **汇聚层** | 网络访问策略控制、数据包处理/过滤、寻址、策略路由、广播域定义。 | 承上启下的中间层，负责汇聚多个接入层的流量，并实施区域性的、精细化的网络策略（如VLAN间路由、访问控制列表ACL、流量整形）。是策略执行的关键层面。 |
| **接入层** | 用户接入、计费管理、MAC地址认证或过滤、收集用户信息。 | 最靠近终端用户的层级，负责连接用户设备（如PC、打印机、无线AP）。主要实现用户接入控制、身份识别和基本的安全防护。 |
## 架构关键点与数据流向
* **核心连接**：**服务器群**通常直接连接到**核心层**，以便为全网用户提供高速、稳定的数据访问服务。
* **典型流向**：用户数据流通常遵循 **接入层 → 汇聚层 → 核心层 → 出口层 → ISP** 的路径。
* **冗余设计**：核心层与出口层是网络可靠性的关键，必须采用冗余设计（如双机热备、多链路捆绑）以防止单点故障。
* **层次化优点**：这种设计使网络易于扩展、管理和故障排查，各层功能聚焦，变更影响范围可控。
# 补充 - IPv6
## 一、IPv6地址类型
IPv6有三种主要的地址类型，用于不同模式的网络通信。
| 地址类型 | 描述 | 关键特点与示例前缀 |
| :--- | :--- | :--- |
| **单播** | 唯一标识一个IPv6节点的接口，用于点对点通信。 | **可聚合全球单播地址**：前缀为 `001` (例如 `2000::/3`)
**本地单播地址**：
- **链路本地**：前缀 `1111111010` (`FE80::/10`)，用于同一链路上节点间通信。
- **站点本地**：前缀 `1111111011` (`FEC0::/10`)，已被唯一本地地址取代。 |
| **多播** | 标识一组IPv6节点的接口，用于一对多通信。 | 前缀固定为 `11111111` (`FF00::/8`)。 |
| **任播** | 指派给多个节点的接口，发往任播地址的数据包只会被路由到其中“最近”的一个接口。 | 地址从单播地址空间分配，格式上无区别，路由协议负责定位“最近”节点。 |
## 二、IPv6的优势 (相比IPv4)
IPv6的设计解决了IPv4的诸多限制，主要优势包括：
* **更大的地址空间**：地址长度从32位扩展到**128位**，地址数量扩大了2^96倍。
* **简化的报文头格式**：IPv6报文头格式更灵活且固定，提高了路由器处理效率。
* **增强的扩展与选项支持**：通过扩展头部实现更多服务类型，协议易于演变以适应新技术。
* **内置的安全性**：**IPSec** 协议套件是IPv6的强制实现项，为网络层通信提供了身份认证和加密等安全保障。
## 三、IPv4 / IPv6 过渡技术
为了在IPv4向IPv6演进过程中保证业务共存与平滑过渡，主要采用以下技术：
### 1. 双协议栈技术
* **原理**：网络节点同时运行IPv4和IPv6两套协议栈。
* **作用**：使节点既能与IPv4主机通信，也能与IPv6主机通信，是实现共存的基础。
### 2. 隧道技术
* **原理**：将IPv6数据包作为载荷封装在IPv4数据包中，通过现有的IPv4网络进行传输，实现IPv6网络的互连。
* **具体隧道类型**：
* **6to4 隧道**
* **6over4 隧道**
* **ISATAP 隧道**
### 3. NAT-PT 技术
* **原理**：通过专门的网关设备实现IPv4与IPv6网络之间的协议转换和地址映射。
* **作用**：使得纯IPv6节点与纯IPv4节点能够直接相互访问。
根据图片内容整理的 RAID 级别对比笔记如下（Markdown 格式）：
# RAID 级别对比
| RAID 级别 | 数据存储方式 / 原理 | 主要特点与适用场景 |
| :--- | :--- | :--- |
| **RAID 0** | 无冗余和无校验的数据分块 | - **I/O 性能最高**，磁盘空间利用率 100%
- 无冗余，安全性低 |
| **RAID 1** | 磁盘镜像阵列（每个工作盘对应一个镜像盘） | - 安全性最高
- 磁盘空间利用率 50%
- 适合存放重要文件 |
| **RAID 2** | 采用纠错海明码的磁盘阵列，增加校验盘提供单纠错和双验错功能 | - 适合大数据量场景，不适合小数据 |
| **RAID 3 / RAID 4** | 采用奇偶校验码，校验码存放在独立校验盘
- RAID 3：位交叉奇偶校验码
- RAID 4：块交叉奇偶校验码 | - RAID 3 适用于大型文件且 I/O 需求不频繁的应用
- RAID 4 适用于大型文件的读取 |
| **RAID 5** | 无独立校验盘，校验信息分布在组内所有盘上 | - 大批量和小批量数据的读写性能都较好
- 磁盘空间利用率 = (n-1)/n |
| **RAID 6** | 具有独立的数据硬盘与两个独立的分布式校验方案，设置专用异步校验盘 | - 可快速访问，但性能改进有限，成本较高
- 磁盘空间利用率 = (n-2)/n |
| **RAID 10** | 结合 RAID 1（镜像）与 RAID 0（分块），即 RAID 0+1 | - 兼具高读写效率与高数据保护/恢复能力
- 性价比较高 |
# OSI/RM 七层协议笔记
## 1. 概览
* **层级概览**（自顶向下）：
1. **应用层**
2. **表示层**
3. **会话层**
4. **传输层**
5. **网络层** (又称: 网际层)
6. **数据链路层**
7. **物理层** (又称: 网络接口层)
## 2. 各层详细说明
| OSI 层级 | 主要功能 | 详细说明与协议示例 |
| :--- | :--- | :--- |
| **应用层**
(Application) | 处理网络应用 | 直接为端用户服务，提供各类应用过程的接口。例如：**HTTP**、**FTP**、**SMTP**、**Telnet**、**NFS** 等。 |
| **表示层**
(Presentation) | 数据表示 | 确保应用层能够理解数据的含义，负责数据格式转换、加密/解密、压缩/解压缩等。例如：**JPEG**、**ASCII**、**GIF**、**DES**、**MPEG** 等。 |
| **会话层**
(Session) | 互连主机通信 | 负责建立、管理和终止应用程序之间的对话（会话）。例如：**RPC**、**SQL** 等。 |
| **传输层**
(Transport) | 端到端连接 | 实现端到端的可靠或不可靠数据传输，负责流量控制、差错控制等。服务访问点为**端口**。例如：**TCP**、**UDP**、**SPX** 等。 |
| **网络层**
(Network) | 分组传输和路由选择 | 负责将数据包从源节点路由到目标节点，处理寻址、拥塞控制和异构网络互联。服务访问点为**逻辑地址（IP地址）**。例如：**IP**、**IPX** 等。 |
| **数据链路层**
(Data Link) | 传送以帧为单位的信息 | 在相邻节点间建立可靠的数据链路，进行帧的封装、差错控制、流量控制等。分为 MAC 和 LLC 子层。服务访问点为**物理地址（MAC地址）**。例如：**IEEE 802.3/2**、**HDLC**、**PPP**、**ATM** 等。 |
| **物理层**
(Physical) | 二进制位传输 | 定义物理介质的机械、电气、功能和规程特性，负责比特流的透明传输。例如：**RS-232**、**V.35**、**RJ-45**、**FDDI** 等。 |
## 3. 补充说明
* **数据单元**：各层处理的数据单元不同，从上至下一般为：报文/数据流 → 数据段 → 数据包 → 帧 → 比特。
* **与TCP/IP模型对应**：OSI模型是一个理论参考模型。在实际中广泛使用的 TCP/IP 模型可近似对应为：
* **应用层** (对应 OSI 的应用层、表示层、会话层)
* **传输层** (对应 OSI 的传输层)
* **网际层** (对应 OSI 的网络层)
* **网络接口层** (对应 OSI 的数据链路层和物理层)
# 常见网络协议速查表
| 协议名 | 要点 | 协议名 | 要点 |
| :--- | :--- | :--- | :--- |
| **FTP** | 文件传输协议
数据：20端口
控制：21端口 | **TCP** | 可靠的文件传输协议
面向连接 |
| **TFTP** | 简单文件传输协议
端口号：69 | **UDP** | 不可靠文件传输协议
不面向连接 |
| **HTTP** | 超文本传输协议
建立在TCP之上
端口号：80 | **DHCP** | 动态主机配置协议
端口号：67 |
| **SMTP** | 简单邮件传输协议
用于发送邮件
端口号：25 | **ICMP** | 网络控制协议 |
| **POP3** | 邮件的收取协议
端口号：110 | **IGMP** | 组播协议 |
| **Telnet** | 远程登录协议
端口号：23 | **ARP** | 地址解析协议
实现IP到MAC地址的映射 |
| **SNMP** | 简单网络管理协议
端口号：161 | **RARP** | 反向地址解析协议
实现MAC地址到IP地址的映射 |
| **DNS** | 域名解析协议
实现域名和IP地址的映射
端口号：53 | **IMAP** | 电子邮件访问协议
端口号：143 |
# 信息系统概念与生命周期
## 1. 信息系统定义
**信息系统**是由**计算机硬件、网络和通信设备、计算机软件、信息资源、信息用户和规章制度**组成的，以处理信息流为目的的**人机一体化系统**。
## 2. 信息系统的基本功能
信息系统的五个基本功能为：**输入、存储、处理、输出**和**控制**。
## 3. 信息系统生命周期（开发阶段）
信息系统从概念到验收通常经历以下六个阶段，其核心是从 **“做什么”（逻辑模型）** 到 **“怎么做”（物理模型）** 的实现过程。
| 阶段 | 核心任务与产出 |
| :--- | :--- |
| **1. 概念阶段 (需求分析)** | **核心任务**：明确系统“做什么”。
**主要活动**：提出初步想法，进行详细的**需求调研与分析**。
**产出**：需求规格说明书。 |
| **2. 总体规划** | **核心任务**：制定项目蓝图和行动指南。
**主要内容**：信息系统的**开发目标、总体架构、组织结构与管理流程、实施计划、技术规范**等。 |
| **3. 系统分析** | **核心任务**：建立系统的**逻辑模型**，即业务逻辑。
**主要内容**：对**组织结构及功能、业务流程、数据和数据流程**进行分析，形成**系统初步方案**。 |
| **4. 系统设计** | **核心任务**：将逻辑模型转化为**物理模型**，即技术实现方案。
**主要内容**：包括**系统架构设计、数据库设计、处理流程设计、功能模块设计、安全控制方案设计、系统组织与队伍设计、管理流程设计**等。 |
| **5. 系统实施** | **核心任务**：将设计转化为可运行的实体系统。
**关键点**：**具体实现**，并**强调用户参与**（如培训、测试）。 |
| **6. 系统验收** | **核心任务**：确认系统符合要求并交付使用。
**关键点**：系统经过**试运行**后，进入正式验收阶段。 |
> **关键提示**：
> - **概念阶段**是起点，决定了项目的方向和范围，**需求分析**是此阶段的核心。
> - **系统分析**与**系统设计**是两个关键环节，分别对应解决 **“业务问题”（逻辑）** 和 **“技术实现”（物理）** 。
> - **系统实施**阶段必须重视**用户参与**，这是项目成功的重要保障。
# 信息系统开发方法对比
| 开发方法 | 特点 |
| :--- | :--- |
| **结构化法** | - **核心思想**：**自顶向下，逐步求精**。
- **主要特点**：
• **模块化**开发。
• 开发目标清晰化。
• 工作阶段程式化。
• 开发文档规范化。
• 设计方法结构化。 |
| **原型法** | - **适用场景**：**需求不明确**的情况。
- **开发过程**：用户提出需求 → 快速构建系统模型 → 与用户反复交流迭代。
- **原型分类**：
• **按功能分**：**水平原型**（界面原型）、**垂直原型**（复杂算法原型）。
• **按结构分**：**抛弃型原型**、**演化型原型**。 |
| **面向对象 (OO)** | - **核心思想**：**自底向上**，通过**抽象对象**来提高复用性，构造问题域的模型。
- **基本构成**：**对象 → 类 → 类库**。
- **主要优势**：更符合人类的思维习惯。 |
| **面向服务的方法 (SOA)** | - **演进路径**：将相关**对象和类**按业务功能分组形成**构件**，通过标准化的**接口**实现分离。
- **核心特点**：**粗粒度**、**松耦合**、**标准化**。
- **抽象级别**：**操作 → 服务 → 业务流程**。 |
# 信息系统的分类 - 业务处理系统 (TPS)
## 1. 基本概念
- **全称**：业务处理系统 (Transaction Processing System, TPS)
- **别称**：电子数据处理系统 (Electronic Data Processing System, EDP)
- **定位**：计算机在管理领域早期应用的**最初级形式**。
## 2. 作用与特点
- **服务层级**：组织管理层次中的**最底层、最基础**。
- **解决问题**：**结构化程度很高**的常规管理问题。
- **核心目的**：
1. 减轻作业层管理人员处理原始数据的负担。
2. 提高具体事务的处理效率。
- **基础性**：TPS是企业其他高级信息系统（如MIS、DSS）的**数据基础**。
## 3. 数据处理流程
TPS的核心是对业务数据进行收集、存储、计算和输出，其典型流程如下：
[数据输入]
↓
[数据处理] → (批处理 / 联机实时处理)
↓
[数据库维护] → (更新、存储)
↓
[文件、报表生成] [查询处理]
↓ ↓
输出结果 响应查询
**流程详解**：
1. **数据输入 (Data Entry)**：从销售点、终端等渠道采集原始业务数据。
2. **数据处理 (Processing)**：
- **批处理 (Batch Processing)**：定期（如每日）集中处理累积的数据。
- **联机实时处理 (Online Real-time Processing)**：业务发生时立即处理（如ATM取款）。
3. **数据库维护 (Database Maintenance)**：将处理后的数据更新并存储到数据库中。
4. **输出与查询 (Output & Inquiry)**：
- **生成文件与报表**：如生成销售日报、库存清单。
- **查询处理**：响应用户对当前数据的实时查询请求（如查询账户余额）。
# 信息系统的分类 - 管理信息系统 (MIS)
## 1. 基本概念
- **全称**：管理信息系统 (Management Information System, MIS)
- **起源**：由**业务处理系统 (TPS)** 发展而成。
- **核心思想**：在TPS的基础上，运用大量**管理方法**对企业整体信息进行综合处理。
- **核心目的**：利用处理后的信息进行**预测、控制、计划**，以辅助企业的全面管理。
## 2. 系统组成
管理信息系统由四大核心部件构成：
1. **信息源**：信息的来源。
2. **信息处理器**：负责信息的**收集、存储、处理、传输**等功能。
3. **信息用户**：信息的使用者（各级管理人员）。
4. **信息管理者**：负责系统的设计、实现、运行和维护。
## 3. 系统结构类型
MIS根据其决策过程中的信息反馈机制，可分为两种基本结构：
| 结构类型 | 核心特点 | 执行流程 | 示例 |
| :--- | :--- | :--- | :--- |
| **开环结构**
(开环MIS) | **单向执行，不根据反馈调整**。在执行决策的过程中**不收集外部信息**，也不根据信息改变当前决策。事后的评价仅供后续决策参考。 | `输入 → 处理 → 输出`
(决策执行完毕后才进行效果评估) | 批量生产、订单执行 |
| **闭环结构**
(闭环MIS) | **双向循环，动态调整**。在决策执行过程中**不断收集外部信息**，并及时反馈给决策者，用于调整和优化当前的决策活动。 | `输入 → 处理 → 输出 → 反馈 → 调整输入...`
(形成一个包含实时反馈的循环) | 库存控制、过程控制系统 |
**简单对比**：
- **开环结构**：决策 → 执行 → 结束 → 事后评估。
- **闭环结构**：决策 → 执行 → 实时监控与反馈 → 调整决策 → 继续执行…… 形成一个持续优化的管理闭环。
# 信息系统的分类 - 决策支持系统 (DSS)
## 1. 基本定义
**决策支持系统 (Decision Support System, DSS)** 是一个由**语言系统、知识系统和问题处理系统**三个互相关联的部分组成的，基于计算机的信息系统。
## 2. 核心特征
1. **数据和模型是主要资源**：以数据和模型库为核心，支持决策分析。
2. **支持而非代替决策**：旨在**辅助**决策者，而非完全自动化地**替代**其判断。
3. **面向半/非结构化问题**：主要用于解决**半结构化**及**非结构化**的管理决策问题。
4. **追求有效性而非效率**：核心目标在于提高决策的**质量和有效性**，而非单纯提升决策过程的**速度或效率**。
## 3. 基本结构形式
DSS主要有两种基本结构形式：
- **两库结构**：通常指包含**数据库**和**模型库**的系统结构。
- **基于知识的结构**：更强调**知识系统**（或知识库）的核心作用。
## 4. 主要特点
1. **面向决策者**：系统设计以服务决策者为中心。
2. **支持半结构化问题**：核心应用场景是规则不明确、需要人机协同的问题。
3. **辅助与支持**：定位是决策者的“帮手”和“智库”。
4. **体现动态性**：能够反映并适应决策过程的动态变化。
5. **提倡交互式处理**：强调通过人机对话方式，迭代式地探索解决方案。
## 5. 组成内容
DSS的构建通常涉及以下关键技术或组成部分：
1. **数据的重组和确认**
2. **数据字典的建立**
3. **数据挖掘和智能体**（涉及分类、聚类等算法）
4. **模型建立**
# 信息系统的分类 - 专家系统 (ES)
## 1. 基本定义
**专家系统 (Expert System, ES)** 是一种智能的计算机程序，该程序使用**知识与推理过程**，求解那些需要**资深专家的专门知识**才能解决的高难度问题。
## 2. 核心组成（三要素与三级知识）
专家系统的核心架构由三个要素构成，分别对应三级知识：
| 系统要素 | 对应知识级别 | 功能描述 |
| :--- | :--- | :--- |
| **综合数据库** | 数据级 | 描述和存储问题的当前状态和事实。 |
| **知识库** | 知识库级 | 存放领域专家的**启发式经验知识**（规则、案例等）。 |
| **推理机** | 控制级 | 对知识库中的知识进行推理和问题求解的控制机制。 |
> **关键对比**：专家系统具备**数据、知识库、控制**三级结构，而传统应用程序通常只有**数据和程序**两级结构。
## 3. 主要特点（与传统程序及AI程序的五大区别）
专家系统不同于传统的应用程序，也不同于其他类型的人工智能程序，主要体现在以下五个方面：
1. **问题类型与求解方法**
* **专家系统**：属于**人工智能**范畴，解决**半结构化或非结构化**问题，应用**启发式方法**或弱方法。
* **传统程序**：解决**结构化**问题，应用**算法**。
2. **模拟对象**
* **专家系统**：模拟**人类专家在问题领域的推理过程**。
* **传统程序**：通过建立**数学模型**去模拟问题领域本身。
3. **系统结构**
* **专家系统**：具有**综合数据库、知识库、推理机**三要素，结构清晰，**灵活性高**。
* **传统程序**：将过程性计算信息与控制性判断信息**合而为一地编码在程序中**，结构相对僵化。
4. **问题性质**
* **专家系统**：处理**实际问题**，需要人类专家的大量专门知识，而非纯学术问题。
5. **性能与通用性**
* **专家系统**：通过将问题领域**局限在狭窄的特定领域**来获得高性能，其性能取决于**启发式知识的数量和质量**。因此，其问题求解的**通用性较差**。
* **传统/AI程序**：可能更强调通用算法或广泛的适用性。
# 企业资源规划 (ERP)
## 1. 基本概念
- **企业的所有资源**包括三大流：**物流**、**资金流**和**信息流**。
- **ERP**是建立在信息技术基础上，利用现代企业的先进管理思想，全面地集成了企业的所有资源信息，并为企业提供**决策**、**计划**、**控制**与**经营业绩评估**的全方位和系统化的管理平台。
- **ERP系统**是一种**管理理论**和**管理思想**，而不仅仅是信息系统。
## 2. 结构原理
ERP系统的结构原理通常包括以下几个关键步骤：
1. **生产预测**
- 对市场进行预测，强调计划。
2. **生产计划大纲**
- 根据经营计划的生产目标制定，是对企业经营计划的细化。
- 描述在可用资源条件下，在一定时期内的产量计划。
3. **主生产计划**
- 是对企业生产计划大纲的细化。
- 说明在一定时期内的计划：**生产什么**、**生产多少**和**什么时候交货**。
4. **物料需求计划**
- 主生产计划的各个项目所需的**全部制造件**和**全部采购件**的网络支持计划和时间进度计划。
5. **能力需求计划**
- 对物料需求计划所需能力进行核算。
6. **车间作业计划**
- 零部件的生产计划以订单的形式下达给适当的车间。
# 企业信息化方法
| 方法 | 核心要点 |
| :--- | :--- |
| **1. 业务流程重构方法** | 核心思想是 **“彻底的、根本性的”重新设计** 业务流程，而非渐进改良。 |
| **2. 核心业务应用方法** | 企业信息化必须围绕并服务于自身的 **核心业务**，以此为主要推动力。 |
| **3. 信息系统建设方法** | 信息系统的建设是实施企业信息化的 **重点和关键** 环节。 |
| **4. 主题数据库方法** | 建立面向企业核心业务的 **主题数据库**，旨在整合数据，**消除“信息孤岛”**。 |
| **5. 资源管理方法** | 利用计算机与网络技术增强企业资源管理能力，典型应用如 **ERP（企业资源规划）、SCM（供应链管理）** 等。 |
| **6. 人力资本投资方法** | 将一部分优秀员工视作 **“资本”**（而不仅是资源），认为对其投资可以获得收益，这是与“人力资源”概念的主要区别。 |
# 补充：系统需求层次
系统需求通常分为三个相互关联的层次，它们从宏观战略逐步落实到具体运作与技术层面。
## 1. 战略需求
* **核心目标**：组织信息化的根本目的是**提升组织的竞争能力**，并为组织的**可持续发展**提供支持环境。
* **关键定位**：**信息化战略是企业战略的重要组成部分，是企业竞争的基础**。
## 2. 运作需求
运作需求是连接战略与具体实施的**关键环节**，包含以下三方面内容：
1. **实现战略目标的需要**：确保信息化建设直接服务于并推动总体战略的实现。
2. **运作策略的需要**：满足组织日常业务流程和管理活动对信息系统的具体要求。
3. **人才培养的需要**：为信息化系统的有效使用和持续发展配备、培养相应的人才。
## 3. 技术需求
技术需求源于实际开发与运行过程中产生的问题，主要关注：
* **驱动因素**：由于系统开发周期、技术迭代等原因，在**信息技术层面上**对系统提出了持续改进的要求。
* **主要内容**：包括对现有系统的**完善、升级、集成和整合**等需求。
---
### 需求层次关系概览
| 需求层次 | 关注焦点 | 核心内容 |
| :--- | :--- | :--- |
| **战略需求** | **为什么做** (Why) | 提升竞争力，支持可持续发展 |
| **运作需求** | **做什么** (What) | 实现战略、支持运作、培养人才 |
| **技术需求** | **如何做/如何改进** (How) | 系统的完善、升级与集成 |
# 补充：系统规划的三个阶段
信息系统规划的方法和核心目标随着企业发展不断演变，主要可分为以下三个阶段：
| 阶段 | 规划核心 | 关注焦点 | 主要规划方法 |
| :--- | :--- | :--- | :--- |
| **第一阶段** | **数据处理** | 围绕**职能部门**的需求 | 企业系统规划法 (BSP)
关键成功因素法 (CSF)
战略集合转化法 (SST) |
| **第二阶段** | **企业内部管理信息系统 (MIS)** | 围绕**企业整体**的需求 | 战略数据规划法 (SDP)
信息工程法 (IE)
战略栅格法 |
| **第三阶段** | **集成** | 综合考虑企业内外环境，围绕**企业战略**需求 | 价值链分析法
战略一致性模型 (SAM) |
**演变脉络总结**：
1. **从部门到整体**：焦点从满足单个部门职能，扩展到服务企业整体运营。
2. **从内部到战略**：视角从企业内部管理，提升到与外部环境结合的战略层面。
3. **从孤立到集成**：目标从建设独立系统，转变为实现信息、流程和资源的全面集成。
# 补充：系统规划方法详解
| 方法名称 | 简称 | 核心思想与关键步骤 | 主要特点与要点 |
| :--- | :--- | :--- | :--- |
| **企业系统规划法** | BSP | **核心**：自上而下规划，自下而上实现。
**四步骤**：1. 定义管理目标；2. 定义管理功能；3. 定义数据分类；4. 定义信息结构（**CU矩阵**）。 | 主要用于大型信息系统开发。 |
| **关键成功因素法** | CSF | **核心**：识别影响目标达成的关键因素，据此确定信息需求与开发次序。
**步骤**：确定目标 → 识别CSF → 明确信息需求（定义性能指标与数据字典）。 | 通过识别CSF来确定系统开发的优先次序。 |
| **战略集合转化法** | SST | **核心**：将企业战略（使命、目标、战略、管理水平、环境约束等）视为一个“信息集合”，并将其转化为信息系统的战略目标。 | 强调整体性，将企业战略直接映射为信息系统战略。 |
| **战略数据规划法** | SDP | **核心**：自顶向下全局规划，自底向上详细设计，以建立**主题数据库**为主要特征。
**主题数据库特征**：面向业务、信息共享、一次一处输入、由基本表组成。
**四类数据环境**：文件环境、应用数据库环境、主题数据库环境、信息检索系统环境。 | 旨在挖掘数据和信息的规律，规划稳定的数据结构。 |
| **信息工程方法** | IE | **核心**：围绕企业整体需求，以管理信息系统为核心进行规划。认为信息系统由**信息、技术和过程**三要素构成。
**四阶段**：规划、分析、设计、构建。 | 强调三要素，采用明确的阶段化开发过程。 |
| **战略栅格法** | - | **核心**：创建一个2x2战略栅格矩阵，从战略影响维度评估企业现有及未来的信息系统组合，分析它们对企业生存与竞争地位的影响。 | 用于评估信息系统投资组合的战略价值。 |
| **价值链分析法** | - | **核心**：将企业活动视为一系列输入、转换与输出的价值创造链。通过分析每个环节，识别哪些活动**增值**，哪些**减值**，从而确定信息化可优化的环节。 | 从价值创造角度分析信息化机会，增强企业竞争地位。 |
| **战略一致性模型** | SAM | **核心**：分析企业战略与信息化战略的匹配关系。模型分为内、外两大部分：
**外部**：企业面临的竞争环境（如市场）。
**内部**：企业组织结构、信息架构和业务流程等。 | 用于评估和确保企业战略与IT战略之间的一致性。 |
# 补充：客户关系管理 (CRM)
## 1. 核心定义与目标
**客户关系管理 (Customer Relationship Management, CRM)** 通过将企业的**人力资源、业务流程与专业技术**进行有效整合，最终在涉及客户或消费者的各个领域提供**完美集成**。
其核心目标是：
* **以更低成本、更高效率满足客户需求**。
* 与客户建立起基于**学习型关系**的**一对一营销模式**。
* **最大程度地提高客户满意度与忠诚度**。
## 2. 主要功能模块
一个典型的CRM系统主要包含以下四个模块：
1. **销售自动化 (SFA)**
* **定位**：CRM系统**最基本**的模块。
* **功能**：覆盖销售全过程，包括线索管理、商机管理、联系人管理、报价、订单管理等。
2. **营销自动化 (MA)**
* **功能**：支持市场活动的策划、执行、分析与评估，管理营销内容，进行客户细分和精准营销。
3. **客户服务与支持 (CSS)**
* **功能**：管理客户服务请求、投诉、咨询，通常包含服务台、案例管理、知识库等功能。
4. **商业智能 (BI)**
* **功能**：对客户数据进行深度分析，生成报表和可视化洞察，用于支持决策，发现销售趋势与客户行为模式。
## 3. 四大核心功能
CRM 系统主要包含以下四大核心功能，它们相互关联，共同构成完整的客户管理闭环。
| 核心功能 | 核心描述与价值 | 关键活动与说明 |
| :--- | :--- | :--- |
| **客户服务** | **CRM的关键内容**，通过提供优质服务提高客户满意度和忠诚度。 | 处理客户咨询、投诉、支持请求，是建立长期客户关系的基础。 |
| **市场营销** | 负责商机挖掘与管理，是企业赢利的**核心驱动因素**。 | 包括：
• **商机产生、获取与管理**
• **商业活动管理**（如市场活动策划）
• **电话营销**
• 核心是将**潜在客户**发展为**忠诚客户**。 |
| **共享的客户资料库** | 连接市场营销与客户服务的**基础与依托**，是企业重要的信息资源。 | 统一存储客户信息、交互历史、交易记录等，确保各部门信息一致，打破数据孤岛。 |
| **分析能力** | 使**客户价值最大化**的关键，通过对客户数据的深度分析，支持智能决策。 | 对共享资料库中的数据进行统计分析、建模，以识别客户行为模式、细分客户群体、预测趋势，并评估营销活动效果。 |
## 4. 一个有效的CRM解决方案应具备的要素
一个成功的CRM系统不仅是一套软件，更是一套整合了策略、流程和技术的解决方案。其核心要素包括：
| 要素 | 核心描述与作用 |
| :--- | :--- |
| **畅通有效的客户交流渠道
(触发中心)** | 建立多样、便捷的沟通渠道（如电话、邮件、社交媒体、在线客服），作为与客户互动、获取需求与反馈的**“触发”起点**。 |
| **对所获信息进行有效分析
(挖掘中心)** | 对从各渠道收集的客户数据进行深度分析与挖掘，转化为商业洞察，以支持精准营销、个性化服务和战略决策。 |
| **与ERP系统良好集成** | CRM必须能与**企业资源规划(ERP)系统**无缝集成，实现客户信息、订单、库存、财务等数据的贯通，打破信息孤岛，形成业务闭环。 |
> **提示**：图中特别用红色强调了 **“触发中心”**、**“挖掘中心”** 和 **“与ERP集成”** 这三个关键点，它们是评估CRM解决方案有效性的核心。
## 5. CRM的实现过程
CRM的实施与应用是一个持续的价值创造过程，主要围绕以下三个核心环节展开：
| 过程环节 | 核心目标与活动 |
| :--- | :--- |
| **客户服务与支持** | **核心**：通过控制与服务品质，赢得顾客的忠诚度。
**活动**：处理咨询、投诉、提供售后支持，确保客户问题得到及时有效解决，提升客户满意度与黏性。 |
| **客户群维系** | **核心**：通过与现有顾客的持续交流与关系维护，实现新的销售（交叉销售与向上销售）。
**活动**：进行客户关怀、满意度回访、个性化推荐，将一次性客户转化为长期忠诚客户。 |
| **商机管理** | **核心**：利用客户数据库开展销售，将潜在需求转化为实际交易。
**活动**：管理销售线索、跟踪商机进程、分析客户购买行为，赋能销售团队，提升成交率与销售效率。 |
# 供应链管理 (SCM)
## 1. 定义
**供应链管理 (Supply Chain Management, SCM)** 是一种集成的管理思想和方法。其核心是在满足既定的服务水平要求的同时，为了使系统总成本达到最低，而采用的将**供应商、制造商、仓库和商店**有效地结合成一体来生产商品，并有效地控制和管理各种**信息流、资金流和物流**，最终实现把正确数量的商品在正确的时间配送到正确地点的一套管理方法。
## 2. 主要特点
| 特点 | 核心描述 |
| :--- | :--- |
| **以客户为中心** | SCM追求的首要目标是满足客户需求。衡量其绩效的最重要指标是**客户满意度**。 |
| **集成化管理** | SCM的本质在于**集成化管理**，强调对供应链上各环节与资源的协同与整合。 |
| **扩展性管理** | 现代的SCM促使传统的企业向**扩展性企业（Extended Enterprise）** 发展，其管理范围超越了企业自身的边界。 |
| **合作管理** | 非常强调企业之间的**合作**，打破传统的封闭经营意识，在供应链各节点企业之间建立起**新型的合作关系**。 |
| **多层次管理** | 其管理活动涵盖**战略、战术和作业**三个层次。主要目标是通过系统的观点，对各职能和各层级的供应商进行整合。 |
## 3. 供应链节点
供应链是由一系列相互关联的实体组成的网络，主要节点包括：
- 供应商
- 制造商
- 分销商
- 零售商
- 仓库
- 配送中心
- 客户
## 4. SCM的五大基本内容
供应链管理包括计划、采购、制造、配送、退货五大基本活动，其核心说明如下：
| 组成部分 | 核心说明 |
| :--- | :--- |
| **计划** | 这是SCM的**策略部分**。企业需要一个策略来管理所有资源，以满足客户对产品的需求。好的计划建立一系列方法来监控供应链。 |
| **采购** | 核心任务是**选择合适的供应商**，为企业提供产品和服务。 |
| **制造** | 安排生产、测试、打包和准备送货所需的活动。是供应链中**测量内容最多的部分**。 |
| **配送** | **即物流**。包括调整用户订单、建立仓库网络、安排提货送货、建立计价系统、接收付款等活动。 |
| **退货** | 是供应链中的**问题处理部分**。 |
# 补充：企业应用集成 (EAI)
## 1. 基本概念
**企业应用集成 (Enterprise Application Integration, EAI)** 是指对企业内部或企业间多个独立的应用系统进行整合，以实现数据、流程和功能的共享与协同。
- **适用范围**：适用于大多数要实施电子商务的企业，以及企业之间的应用集成。
- **核心价值**：打破“信息孤岛”，提升整体业务效率和响应能力。
## 2. 主要集成方式
| 集成方式 | 别称 | 集成层次 | 主要特点与说明 | 典型例子 |
| :--- | :--- | :--- | :--- | :--- |
| **表示集成** | 界面集成、黑盒集成 | **用户界面层** | 最原始、浅层的集成。将多个系统的用户界面**统一入口**，提供一个看上去统一但由多个后台系统组成的应用。 | 企业门户、统一桌面 |
| **数据集成** | 白盒集成 | **数据层** | 将不同来源、格式的数据在逻辑或物理上有机集中，实现**全面的数据共享**。 | ETL工具、数据仓库、联邦数据库 |
| **控制集成** | 功能集成、应用集成、黑盒集成 | **业务逻辑层** | 将多个应用系统的功能（业务逻辑）进行绑定与调用，使其像一个实时系统一样协同工作。 | 远程过程调用(RPC)、面向消息的中间件(MOM)、钉钉（集成多个应用功能） |
| **业务流程集成** | 过程集成 | **业务流程层** | **最彻底、最综合**的集成。超越单个系统和数据，通过一系列基于标准、统一格式的**工作流**将多个应用串联，实现端到端的自动化流程。 | 跨系统审批流、供应链协同流程 |
| **门户集成** | - | **表示层/应用层** | 将内部应用系统的功能和数据**对接到互联网**，通过统一门户（如企业门户网站、移动APP）向外部用户或合作伙伴提供访问。 | 企业客户门户、供应商自助平台 |
## 3. 关键对比与说明
- **集成深度**：从**表示集成**（最浅）到**业务流程集成**（最深），集成层次逐步深入，复杂度与价值也相应提高。
- **“黑盒”与“白盒”**：
- **黑盒集成**（如表示、控制集成）：不关心或无法修改被集成系统的内部实现，只通过标准接口交互。
- **白盒集成**（如数据集成）：需要了解甚至直接访问被集成系统的内部数据结构或逻辑。
- **门户集成**可视为一种特殊形式的**表示集成**，但其核心特点是面向**互联网**，实现了内外系统的连接。
## 4. EAI 的四个服务层次
EAI 从底层到顶层，依次提供以下四个层次的服务：
| 层次 (从下至上) | 服务名称 | 核心作用 |
| :--- | :--- | :--- |
| **第一层** | 通讯服务 | 为系统间集成提供基础的数据传输通道。 |
| **第二层** | 信息传递与转化服务 | 负责数据的路由、格式转换与传递。 |
| **第三层** | 应用连接服务 | 直接连接和调用不同应用系统的具体功能。 |
| **第四层** | 流程控制服务 | 最高层服务，协调和管理跨系统的业务流程。 |
## 5. 核心原则
EAI 的核心活动是在各个应用系统的接口之间**共享数据和功能**。其基本原则是：**集成多个系统，并保证被集成的系统之间互不干扰，即保持各自的独立性**。
## 6. 企业内部的信息集成
企业内部的信息集成通常按照集成内容与层次，自底向上分为以下四个方面：
| 集成层次 | 核心目标与内容 |
| :--- | :--- |
| **技术平台的集成** | 实现系统底层**体系结构、软件、硬件以及异构网络**的整合，为上层集成提供统一、稳定的技术基础。 |
| **数据的集成** | 解决**数据和数据库的集成问题**，实现不同系统间的数据交流与共享。这是进行更深入集成（应用、流程）的**基础**。 |
| **应用系统的集成** | 实现不同应用系统之间的**互操作**，使它们能够共享数据和方法。为更高层的**业务流程集成**奠定基础。 |
| **业务过程的集成** | 最高层次的集成。确保不同应用系统中的**业务流程能够无缝连接**，实现流程的协调运作与流程信息的充分共享。 |
**核心演进**：四个层次呈现出自底向上、从技术到业务的递进关系，共同构成企业内部信息集成的完整框架。
## 7. 企业外部的信息集成
企业外部的信息集成主要关注与外部实体的连接与协同，包含以下两个部分：
| 集成部分 | 核心目标与方式 |
| :--- | :--- |
| **与公众及客户的集成** | 通过**企业门户网站和互联网**，实现与公众、社会团体、客户等的互动，促进**内外部信息资源的有效交流与集成**。 |
| **与合作伙伴的集成** | 通过与**合作伙伴信息系统的直接对接**，建立动态的企业联盟，发展基于合作竞争机制的虚拟企业，以此**重塑企业的战略模式和竞争优势**。 |
# 补充 - 数据挖掘算法
## 1. 数据挖掘定义
**数据挖掘** 是从海量数据中提取或“挖掘”知识的过程。
其重要的功能包括：**分类、聚类、关联规则和离群点分析**。
## 2. 主要功能与对应算法
### 2.1 分类 (Classification)
- **核心目标**：找出描述和区分数据类别的模型，用于预测未知类别的对象。
- **典型方法**：
- **决策树**：如 ID3、C4.5 算法。
- **K-最近邻 (K-NN)**
- **贝叶斯分类**
- **人工神经网络 (ANN)**
- **支持向量机 (SVM)**
### 2.2 聚类 (Clustering)
- **核心思想**：“物以类聚”，将数据对象分组，使得**组内对象尽可能相似**，组间对象尽可能不同。
- **常见算法**：
- **K-means**：发现相关的观测值组群。
- **Apriori** (通常用于关联分析，图中提及可能为扩展或误列)。
### 2.3 序列模式分析 (Sequential Pattern Analysis)
- **侧重点**：分析数据之间的**前后因果关系**或时间顺序模式。
### 2.4 关联分析 (Association Analysis)
- **核心目标**：挖掘隐藏在数据间的**相互关系或关联规则**。
- **关联规则挖掘算法**：例如 Apriori 算法。
### 2.5 离群点分析 (Outlier Analysis)
- **核心目标**：**异常检测**，旨在发现与大部分其他对象显著不同的对象。
### 2.6 回归分析 (Regression Analysis)
- **核心目标**：确定两种或两种以上变量间**相互依赖的定量关系**的一种统计分析方法。
### 2.7 决策树 (Decision Tree)
- **核心方法**：通过构建**树状结构**（包含根节点、内部节点和叶节点）来进行分析和预测。
### 2.8 神经网络 (Neural Networks)
- **功能类比**：可以实现类似于统计学中的**判别分析、回归分析、聚类**等多种功能。
### 2.9 遗传算法 (Genetic Algorithms)
- **三个基本过程**：
1. **繁殖（选择）**
2. **交叉**
3. **变异**
- **核心思想**：模拟自然进化过程来寻找最优解。
# 计算机信息系统安全保护等级
| 级别 | 名称 | 要点 |
| :--- | :--- | :--- |
| **第1级** | 用户自主保护级 | 通过隔离用户与数据，使用户具备**自主安全保护**的能力。为用户提供访问控制手段，保护用户和用户组信息，避免其他用户对数据的非法读写与破坏。 |
| **第2级** | 系统审计保护级 | 实施**更细粒度**的自主访问控制。通过登录规程、**审计安全性相关事件**和隔离资源，使用户对自己的行为负责。 |
| **第3级** | 安全标记保护级 | 具备第2级所有功能，并增加：
1. 提供安全策略模型、**数据标记**以及**主体对客体的强制访问控制**的非形式化描述。
2. 具有准确标记输出信息的能力。
3. 消除通过测试发现的任何错误。 |
| **第4级** | 结构化保护级 | 将第3级中的**自主和强制访问控制扩展到所有主体与客体**，并考虑**隐蔽通道**。此外：
1. 加强鉴别机制。
2. 支持系统管理员和操作员的职能。
3. 提供可信设施管理。
4. 增强配置管理控制。
5. 系统具有**相当的抗渗透能力**。 |
| **第5级** | 访问验证保护级 | **满足访问监控器需求**。访问监控器仲裁主体对客体的全部访问，其本身是**抗篡改的**，且必须足够小以能够分析和测试。此外：
1. 排除非必要代码，复杂性最低。
2. 支持安全管理员职能。
3. 扩充审计机制（安全事件告警）。
4. 提供系统恢复机制。
5. 系统具有**很高的抗渗透能力**。 |
**安全级别核心演进总结**：
- **控制力度**：从 **用户自主控制 (1级)** → **增加审计 (2级)** → **引入强制访问控制 (3级)** → **扩展到所有主体/客体并结构化 (4级)** → **由访问监控器统一仲裁 (5级)**。
- **安全保障**：从基础隔离到具备高抗渗透能力，系统的可信性和恢复能力逐级增强。
- **设计要求**：高级别系统（尤其是5级）强调设计的**最小化、可验证性及抗篡改性**。
# 开发模型 - 敏捷模型
敏捷模型是一组以**轻量、快速、灵活、协作**为核心的软件开发方法集合。其核心思想是**拥抱变化，快速响应**，通过短周期的迭代交付可工作的软件，并强调人员协作和客户反馈。
## 1. 主要敏捷模型与方法
| 模型/方法 | 核心思想与特点 |
| :--- | :--- |
| **极限编程 (XP)** | - **价值观**：交流、朴素、反馈、勇气。
- **开发模式**：近螺旋式的开发方法，将复杂过程分解为简单的小周期。
- **关键实践**：通过**积极的交流**与**持续的反馈**来推进。 |
| **水晶方法 (Crystal)** | - **核心**：提倡“**机动性**”，认为不同项目需要不同的方法。
- **特点**：包含一系列具有共性的核心元素（角色、模式、工作产品等），形成“Crystal家族”。团队可根据项目类型和环境选择最合适的成员方法。 |
| **SCRUM** | - **侧重点**：侧重于**项目管理**。
- **过程模型**：是一个**迭代式增量**的软件开发过程。通过固定时长的“Sprint”迭代交付增量产品。 |
| **特征驱动开发 (FDD)** | - **核心理念**：有效的软件开发需要**人、过程和技术**三大要素。
- **关键角色**：定义了6种关键项目角色（如项目经理、首席架构师、主程序员等）。
- **核心过程**：包含5个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计、特征构建。计划基于特征间的依赖关系。 |
## 2. 其他敏捷相关方法
- **开放源码 (Open Source)**：开发人员通常**地域分布广泛**，基于社区协作。
- **自适应软件开发 (ASD)**：核心是三个**非线性、重叠**的开发阶段：**猜测 (Speculate)、合作 (Collaborate)、学习 (Learn)**。
- **动态系统开发方法 (DSDM)**：倡导以**业务为核心**，确保开发活动与业务目标紧密对齐。
---
**总结**：敏捷模型并非单一方法，而是一系列具有共同价值观（个体和互动高于流程和工具、可工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划）的方法论集合，旨在应对快速变化的需求。
# 开发模型 - 敏捷模型：原则、方法与最佳实践
## 一、 敏捷模型基本原则
敏捷开发强调轻量、快速响应和团队协作，其日常实践遵循以下基本原则：
- √ **短平快的会议**
- √ **小型版本发布**
- √ **较少的文档**（重可工作软件，轻完备文档）
- √ **合作为重**
- √ **客户直接参与**
- √ **自动化测试**
- √ **适应性计划调整**
- √ **结对编程**
- √ **测试驱动开发 (TDD)**
- √ **持续集成 (CI)**
- √ **重构**
## 二、 主要敏捷方法
敏捷开发包含一系列具体的方法论，常见的有：
- √ **自适应开发 (ASD)**
- √ **水晶方法 (Crystal)**
- √ **特征驱动开发 (FDD)**
- √ **SCRUM**
- √ **极限编程 (XP)**
## 三、 极限编程 (XP) 的核心
### 1. 四大价值观
- **沟通**
- **简单**
- **反馈**
- **勇气**
### 2. 五个原则
- **快速反馈**
- **简单性假设**
- **逐步修改**
- **提倡更改**
- **优质工作**
### 3. 十二个最佳实践
1. **计划游戏**（快速制定计划，随业务需求变化而调整）
2. **小型发布**（高频率发布小版本）
3. **隐喻**（通过公共比喻描述系统，达成共识）
4. **简单设计**（只满足当前需求，不过度设计）
5. **测试先行**（先写测试代码，再编写实现代码）
6. **重构**（在不改变外部行为的前提下改进代码结构）
7. **结对编程**
8. **集体代码所有制**（任何开发者可修改任何代码）
9. **持续集成**
10. **每周工作40小时**（保持可持续的工作节奏）
11. **现场客户**（客户代表全程参与）
12. **编码标准**（遵守统一的编码规范，提升可读性与一致性）
---
**总结**：敏捷模型通过其价值观、原则和一系列具体的最佳实践，构建了一个以人为核心、迭代快速、能灵活响应变化的软件开发框架。
# 开发模型 - 构件组装模型 (CBSD)
## 1. 基本定义
**构件组装模型**，即**基于构件的软件开发 (Component-Based Software Development, CBSD)** 模型，是一种利用模块化方法，通过复用和组合预先构建好的软件构件来构造应用系统的过程。
## 2. 核心思想与特点
- **模块化与复用**：将整个系统模块化，并在特定构件模型的支持下，**复用构件库中已有的一个或多个软件构件**。
- **高效高质量**：通过组合手段，旨在**高效率、高质量**地构造应用软件系统。
- **演化与迭代**：该模型融合了**螺旋模型**的许多特征，**本质上是演化型的**，其开发过程是**迭代的**。
## 3. 开发阶段
基于构件的软件开发主要包含以下五个阶段：
| 阶段 | 主要任务 |
| :--- | :--- |
| **1. 需求分析和定义** | 明确系统的功能与非功能需求。 |
| **2. 体系结构设计** | 设计系统的整体结构，确定构件间的接口与协作关系。 |
| **3. 构件库的建立** | 创建、获取或管理可复用的软件构件库。 |
| **4. 应用软件构建** | 通过选择、适配和组装构件库中的构件来构建应用系统。 |
| **5. 测试和发布** | 对组装后的系统进行测试，并最终发布。 |
# 开发模型 - 快速应用开发 (RAD) 模型
## 1. 基本定义
**快速应用开发 (Rapid Application Development, RAD)** 模型是一种 **增量型** 的软件开发过程模型。它强调 **极短的开发周期**，通过 **大量使用可复用构件** 和 **基于构件的建造方法** 来赢得快速开发。
## 2. 核心特点与适用场景
- **核心目标**：**快速交付**可工作的系统。
- **关键手段**：
1. 采用 **基于构件的建造方法**。
2. 大量复用已有的 **可复用构件**。
- **适用条件**：当项目的 **模块化程度要求较高** 时，此模型尤为有效。
## 3. 开发流程
RAD模型通常包含以下五个顺序阶段：
1. **业务建模 (Business Modeling)**
* **任务**：定义业务功能、信息流及其相互依赖关系。
2. **数据建模 (Data Modeling)**
* **任务**：在业务建模的基础上，细化并建立支持业务所需的数据对象和数据关系。
3. **过程建模 (Process Modeling)**
* **任务**：描述如何通过数据处理来实现业务功能，定义数据对象的增、删、改、查等操作。
4. **应用生成 (Application Generation)**
* **任务**：利用自动化工具和可复用构件，**快速构建**出整个应用系统。
5. **测试与交付 (Testing and Turnover)**
* **任务**：由于大量使用已有构件，测试重点侧重于 **新组装的部分** 和 **所有接口**，然后交付给用户。
---
**总结**：RAD模型的核心是利用复用和自动化工具，将需求、设计、构建阶段高度压缩并迭代进行，以实现快速交付。
# 能力成熟度模型 CMMI
CMMI（能力成熟度模型集成）是一个过程改进框架，用于帮助组织提升其开发和管理产品与服务的过程能力。
| 级别 | 要点 |
| :--- | :--- |
| **初始级** | 过程是无秩序且混乱的。项目的成功**高度依赖**于个人的努力和机遇。 |
| **已管理级** | 建立了基本的项目管理过程。能够对成本、进度和功能进行跟踪，**类似的项目可复现成功**。 |
| **已定义级** | 软件过程均已实现**文档化、标准化**，并整合成为整个组织统一的标准软件过程。所有项目均使用经批准、剪裁的组织标准过程来开发和维护软件。 |
| **量化管理级** | 对软件过程和产品质量建立了**详细的量化度量标准**，并运用统计技术进行定量过程管理。 |
| **优化级** | 专注于过程的**持续改进**。能够利用来自过程和创新的量化反馈，通过增量式和创新式的技术进步，持续地优化过程性能。 |
**成熟度演进**：从 **依赖个人** → **项目可控** → **过程标准化** → **量化管理** → **持续优化**。高级别包含低级别的所有特征。
# 需求分类
软件需求可以从两个不同的维度进行分类：一是按需求内容的性质，二是从客户（或用户）的价值感知角度。
## 一、按需求内容分类
此分类方式关注需求的来源、抽象层次和具体内容。
| 需求类别 | 定义与描述 | 说明与示例 |
| :--- | :--- | :--- |
| **1. 业务需求** | 由客户或高层提出的**宏观**功能与目标需求，反映了组织或业务的高层目标。 | 具有**整体性和全局性**，例如“建设一个在线商城以提升销售额”。 |
| **2. 用户需求** | 设计人员通过调研，获得的系统中每个**具体用户**（或角色）所需要完成的任务或期望。 | 是业务需求的细化，描述了用户希望通过系统“做什么”，例如“作为买家，我希望能够搜索商品”。 |
| **3. 系统需求** | 对用户需求进行**分析、整合与细化**后形成的最终技术性需求规格。它详细定义了系统必须实现什么。 | 通常包含以下子类：
• **功能需求**：软件必须完成的具体动作或服务。
• **性能需求**：软件需要满足的静态或动态数值指标，如响应时间、吞吐量、并发用户数等。
• **设计约束**：受外部标准、硬件或其它系统限制而必须遵守的条件，如必须运行在Linux系统上、必须使用特定数据库等。 |
## 二、从客户（用户）角度分类 (基于Kano模型思想)
此分类方式关注功能对客户满意度的不同影响。
| 需求类别 | 定义与对满意度的影响 | 客户心理与开发考量 |
| :--- | :--- | :--- |
| **1. 基本需求** | 需求中**明确规定**的、必须实现的功能。 | **客户认为“必须有”**。如果缺失会导致客户极度不满；但即使完美实现，也仅能消除不满，不会提升满意度。是项目的“及格线”。 |
| **2. 期望需求** | 除了明文规定的基本需求外，客户**认为理所应当包含**的功能。 | **客户认为“应该有”**。这类需求的实现程度与客户满意度呈线性正比关系。实现得越好，客户越满意。是竞争的关键。 |
| **3. 兴奋需求** | 客户**并未明确要求**的额外功能或特性。 | **客户“没想到但很喜欢”**。如果实现，能带来惊喜并显著提升满意度；如果不实现，客户也不会不满。需要注意的是，过度开发此类需求**可能浪费项目时间和成本**。 |
**总结**：第一种分类（按内容）主要用于**需求分析与文档化**的过程管理；第二种分类（按客户角度）则更侧重于**需求优先级排序与产品策略规划**，以最大化客户价值和满意度。
# 软件设计 - 结构化设计 (SD)
## 1. 概述
- **定义**：结构化设计 (Structured Design, SD) 是一种**面向数据流**的设计方法。
- **输入**：以**软件需求规格(SRS)** 和**结构化分析(SA)** 阶段产生的**数据流图(DFD)** 和**数据字典(DD)** 等文档为基础。
- **过程特点**：是一个**自顶向下、逐步求精和模块化**的过程。
## 2. 设计过程的两个阶段
结构化设计过程通常分为概要设计和详细设计两个阶段：
| 阶段 | 主要任务 | 核心产出 |
| :--- | :--- | :--- |
| **概要设计**
(总体设计/架构设计) | 确定软件系统的**整体结构**，进行**模块划分**，明确每个模块的**功能、接口**以及模块间的**调用关系**。 | 软件系统结构图、模块说明书 |
| **详细设计**
(过程设计) | 为**每个模块**设计具体的实现细节，即“如何做”。 | 详细的模块算法描述、流程图、伪代码等 |
## 3. 核心概念：模块
- **定义**：模块是实现功能的基本单位，是组成系统的基本构件。
- **特点**：可以**组合、分解和更换**。系统中的任何一个处理功能都可以看作一个模块。
- **模块的三要素**：
1. **功能**：描述模块“**做什么**”。
2. **逻辑**：描述模块内部“**怎么做**”。
3. **状态**：描述模块使用时的**环境和条件**。
## 4. 主要设计原则
### (1) 信息隐藏与抽象
- **信息隐藏**：采用**封装**技术，将模块的实现细节（内部过程或数据）隐藏起来。其他模块只能通过简单、明确的接口进行访问，而无法直接接触其内部细节。
- **目的**：降低模块间的依赖性，提高独立性和可维护性。
### (2) 模块化
- **核心思想**：将系统分解为一组**高内聚、低耦合**的模块。
- **优点**：使得系统结构清晰，易于设计、开发、测试和维护。
### (3) 高内聚、低耦合 (核心设计原则)
- **内聚 (Cohesion)**：
- **定义**：衡量一个**模块内部**各个元素（语句、程序段）之间彼此结合的紧密程度。
- **目标**：追求**高内聚**，即模块内部各成分关联性强，功能单一。
- **内聚性从高到低**：功能内聚 > 顺序内聚 > 通信内聚 > 过程内聚 > 时间内聚 > 逻辑内聚 > 偶然内聚。
- **耦合 (Coupling)**：
- **定义**：衡量**不同模块之间**相互依赖（连接）的紧密程度。
- **目标**：追求**低耦合**（或松耦合），即模块间接口简单、清晰，依赖性小。
- **耦合性从低到高**：非直接耦合 > 数据耦合 > 标记耦合 > 控制耦合 > 外部耦合 > 公共耦合 > 内容耦合。
> **总结**：优秀的结构化设计追求模块内部“抱团紧”（高内聚），模块之间“联系松”（低耦合）。
# 软件设计 - 结构化设计 (SD) 之内聚详解
## 1. 内聚的概念
- **定义**：内聚表示**一个模块内部**各组成部分（代码、数据）之间相互关联的紧密程度。
- **设计目标**：一个理想的高内聚模块应该**专注且只做好一件事情**，即功能单一、明确。
## 2. 内聚的类型（从高到低）
内聚性由高到低排列，高内聚是优秀设计的追求目标。
| 内聚类型 | 描述 | 内聚性评价 |
| :--- | :--- | :--- |
| **功能内聚** | 模块内所有部分协同工作，共同完成**一个且仅一个**独立、完整的功能。 | **最高**。是最理想的内聚类型。 |
| **顺序内聚** | 模块内的处理元素**相关**，且必须**按特定顺序依次执行**，通常前一个处理的输出是下一个处理的输入。 | **高**。 |
| **通信内聚** | 模块内的所有处理元素都**操作于同一个数据结构**或数据区域上。 | **中**。 |
| **过程内聚** | 模块内的处理元素**相关**，并且必须**按照特定的过程次序（流程）执行**。 | **中**。 |
| **时间内聚** | 模块内的处理元素**必须在同一时间间隔内执行**（如初始化、结束处理），但彼此逻辑关联不强。 | **低**。 |
| **逻辑内聚** | 模块完成一组在逻辑上相关（相似）但功能不同的任务，通过调用时传入的参数来决定具体执行哪一项。 | **低**。 |
| **偶然内聚** | 模块内的任务之间**没有实质联系**，关系松散，只是为了某种方便（如节省空间）而组合在一起。 | **最低**。应避免。 |
**核心设计原则**：在结构化设计中，应致力于实现**高内聚**（特别是功能内聚）的模块，这有助于提高模块的独立性、可理解性和可维护性。
# 软件设计 - 结构化设计 (SD) 之耦合详解
## 1. 耦合的概念
- **定义**：耦合表示**模块之间**相互依赖（连接）的紧密程度。
- **设计目标**：追求**低耦合**（或称松耦合），即模块间的接口应尽可能简单、清晰，依赖性小。低耦合能显著提高模块的独立性、可理解性、可维护性和可测试性。
## 2. 耦合的类型（从低到高）
耦合性由低到高排列，低耦合是优秀设计的追求目标。
| 耦合类型 | 描述 | 耦合性评价与说明 |
| :--- | :--- | :--- |
| **非直接耦合** | 两个模块之间**没有直接关系**，它们之间的联系完全是通过**主模块（上级模块）的控制和调用来实现**的。 | **最低**。模块独立性最强，是最理想的耦合形式。 |
| **数据耦合** | 一组模块之间只通过**参数表传递简单的数据值**（而非控制信息或复杂结构）。 | **低**。模块间接口清晰，是一种良好的耦合形式。 |
| **标记耦合**
(特征耦合) | 一组模块通过参数表传递的是**记录、数组、对象等复杂的整体数据结构**。虽然传递的是数据，但由于接收模块可能只使用其中一部分，会造成隐含的依赖。 | **中**。增加了模块间不必要的连接，应控制其使用。 |
| **控制耦合** | 模块之间传递的信息中包含了**用于控制对方内部逻辑的信号或参数**（如标志、开关值）。 | **中/高**。一个模块的行为会直接影响另一个，降低了接收模块的独立性。 |
| **外部耦合**
(图中为通信耦合) | 一组模块**共享同一组输入数据**，或者它们的输出需要**组合**才能形成完整的输出数据集。 | **较高**。模块通过共享的输入/输出区域产生间接关联，结构不清晰。 |
| **公共耦合** | 多个模块都访问**同一个公共数据环境**（如全局变量、共享的数据库、公共内存区）。 | **高**。对公共数据的修改会影响所有相关模块，难以控制和追踪错误。 |
| **内容耦合** | 一个模块**直接访问另一个模块的内部数据**；或**不通过正常入口（如跳转）进入另一个模块**；或**代码重叠**；或**一个模块有多个入口**。 | **最高**。严重破坏了模块的封装性和独立性，是**必须避免**的耦合形式。 |
**核心设计原则**：在结构化设计中，应致力于实现**低耦合**（特别是非直接耦合和数据耦合）的模块间关系。结合**高内聚**原则，共同构成优秀模块化设计的基础。
**内聚与耦合的关系**：**高内聚**往往有助于达成**低耦合**。一个功能单一的模块（高内聚）通常只需要通过简单的接口与其他模块通信（低耦合）。
# 结构化设计
## 1. 结构化编程
- **核心方法**：采用**自顶向下、逐步求精**的设计方法。
- **模块连接**：各个模块通过“**顺序、选择、循环**”三种基本控制结构进行连接，且每个模块**只有一个入口和一个出口**。
- **程序构成原则**：程序 = (算法) + (数据结构)。
- 算法与数据结构各自为独立的整体，设计时两者分开，并以**算法（函数/过程）为主**。
- **设计原则（32字口诀）**：
> 自顶向下，逐步细化；清晰第一，效率第二；书写规范，缩进格式；基本结构，组合而成。
## 2. 数据库设计
- **设计阶段**：数据库设计主要包括以下阶段：
1. 需求分析
2. 概念结构设计
3. 逻辑结构设计
4. 物理设计
5. 数据库的实施
6. 数据库的运行和维护
- **核心工具 - E-R图**：在**概念结构设计阶段**使用**E-R图**描述现实世界的概念模型。
- **实体 (Entity)**：客观上可以相互区分的事物，可以是具体的人、物，也可以是抽象的概念与联系。
- **属性 (Attribute)**：实体所具有的某一特性，一个实体由若干属性来刻画。
- **联系 (Relationship)**：也称关系，反映实体内部或实体之间的关联。
# 面向对象分析 (OOA)
## 1. 核心思想
面向对象开发方法认为：
- **客观世界由对象组成**。
- 对象由**对象名、属性和操作（方法）** 三要素构成。
- 对象可按其属性进行**分类**。
- 对象之间的联系通过**传递消息**来实现。
- 对象具有**封装性、继承性和多态性**三大特性。
## 2. 开发过程特点
面向对象开发是一个：
- **以用例驱动的**
- **以体系结构为中心的**
- **迭代的和渐增式的**
开发过程。主要包括以下四个阶段：
1. 需求分析
2. 系统分析
3. 系统设计
4. 系统实现
## 3. 面向对象分析 (OOA) 模型
OOA模型由**5个层次**和**5个活动**构成。
| 5个层次 (构成) | 5个活动 (过程) | 说明 |
| :--- | :--- | :--- |
| **主题层** | 定义主题 | 控制复杂性，提供系统概貌。 |
| **对象类层** | 标识对象类 | 识别与问题域相关的对象类。 |
| **结构层** | 标识结构 | 识别对象类之间的分类结构与组装结构。 |
| **属性层** | 定义属性 | 定义对象类的数据特征。 |
| **服务层** | 定义服务 | 定义对象类的操作或方法。 |
## 4. 对象类结构
OOA中定义了两种对象类之间的结构：
| 结构类型 | 描述 |
| :--- | :--- |
| **分类结构** | 表示对象类之间 **“一般与特殊”** 的关系（即继承关系）。 |
| **组装结构** | 表示对象之间 **“整体与部分”** 的关系（即组合/聚合关系）。 |
# 补充 - UML (统一建模语言)
UML 是一种标准化的建模语言，用于对软件密集系统进行可视化、详述、构造和文档化。下图汇总了UML 2.x中定义的13种图形。
| UML图 | 描述与用途 |
| :--- | :--- |
| **用例图** | 由**参与者 (Actor)**、**用例 (Use Case)**、边界以及它们之间的关系构成，用于描述系统的功能需求。用例之间的关系有**包含、扩展、泛化**。 |
| **类图** | 展现一组**对象、接口、协作**以及它们之间的关系。描述系统的静态结构。类之间的关系有**关联、依赖、实现、泛化**。 |
| **对象图** | 描述一组对象及它们之间的关系。可以看作是**类图在某一时刻的实例**（静态快照）。 |
| **构件图** | 描述一个封装的**构件**和它的**接口、端口**，以及由内嵌的构件和连接件构成的内部结构。 |
| **组合结构图** | 用于描述**结构化类**（如构件或类）的内部内容，包括其组成部分以及它们之间的协作关系。 |
| **顺序图**
(序列图) | 一种交互图，由一组**对象或参与者**以及它们之间可能发送的**消息**构成，**强调消息的时间次序**。 |
| **通信图**
(协作图) | 一种交互图，强调**收发消息的对象或参与者的结构组织**，侧重于对象间的链接关系。 |
| **定时图** | 一种交互图，**强调消息跨越不同对象或参与者的实际时间**，而不仅仅是相对顺序。 |
| **状态图** | 描述一个特定对象在其生命周期中**所有可能的状态**，以及由**事件**引起的状态之间的转移和变化。 |
| **活动图** | 将进程或计算的结构展示为**一步步的控制流和数据流**，可用于描述业务流程或算法流程。支持**并行、分支、合并**。 |
| **部署图** | 描述**软件制品**（如可执行文件、库）在**硬件节点**上的物理部署情况，展现软件和硬件的物理关系。 |
| **制品图** | 描述系统的**物理结构**，即软件**制品**（如源码文件、可执行文件、脚本等）以及它们之间的关系。通常与部署图一起使用。 |
| **包图** | 描述由模型本身分解而成的**组织单元（包）** 以及它们之间的**依赖关系**。用于对模型元素进行分组管理。 |
| **交互概览图** | 是**活动图和顺序图的混合物**，它以活动图的框架为基础，但其中的节点是交互图（如顺序图），用于概述控制流。 |
**常见分类**：
* **静态图（结构图）**：描述系统静态结构，如**类图、对象图、构件图、部署图、制品图、包图、组合结构图**。
* **动态图（行为图）**：描述系统动态行为，如**用例图、顺序图、通信图、定时图、状态图、活动图、交互概览图**。
# 软件测试 - 逻辑覆盖
## 1. 逻辑覆盖定义
**逻辑覆盖**是以程序**内部逻辑**为基础的测试技术，属于**白盒测试**的范畴。其核心是通过设计测试用例，运行程序以覆盖其内部的逻辑结构。
## 2. 覆盖标准类型与强度
常用的逻辑覆盖标准及其**发现错误的能力**从弱到强依次为：
**语句覆盖 → 判定覆盖 → 条件覆盖 → 判定/条件覆盖 → 条件组合覆盖 → 路径覆盖**
## 3. 各覆盖标准详解
| 覆盖标准 | 核心要求 | 说明 |
| :--- | :--- | :--- |
| **语句覆盖** | 每条可执行语句**至少执行一次**。 | 最弱的覆盖标准，仅覆盖语句，不关注判断逻辑。 |
| **判定覆盖**
(分支覆盖) | 每个判定的**每个分支**（“真”分支和“假”分支）**至少执行一次**。 | 比语句覆盖强，覆盖了所有的判断结果。 |
| **条件覆盖** | 每个判定中的**每个条件**（简单布尔表达式）应取到**各种可能的值**（真/假）。 | 关注判定中每个条件的取值，但不保证覆盖所有判定结果。 |
| **判定/条件覆盖** | 同时满足**判定覆盖**和**条件覆盖**的要求。 | 覆盖了所有分支以及所有条件的取值，是两者的结合。 |
| **条件组合覆盖**
(图片中红圈强调) | 每个判定中**各条件的每一种可能组合**（真/假值的组合）**至少出现一次**。 | 覆盖强度高，能暴露复杂的条件交互错误。 |
| **路径覆盖** | 使程序中的**每一条可能的执行路径**（从入口到出口）**至少执行一次**。 | 最强的逻辑覆盖标准，但路径数量可能非常多，甚至无限，难以实现完全覆盖。 |
# 净室软件工程 (CSE)
## 1. 概述
- **定义**：净室软件工程 (Cleanroom Software Engineering, CSE) 是一种应用**数学与统计学理论**，以经济的方式生产高质量软件的工程技术。
- **核心目标**：通过严格的工程化软件过程，达到开发中的**零缺陷或接近零缺陷**。
- **核心理念**：与“先制作再修补”的传统方式不同，净室方法强调在**规约和设计阶段**就消除错误，以“净”的方式构建软件，从而降低开发风险，以合理成本开发出高质量软件。
## 2. 理论基础
净室软件工程的理论基础是**函数理论**和**抽样理论**。
### 2.1 函数理论
- **核心思想**：将一个程序视作一个**函数**，该函数定义了从**定义域**（所有可能输入的集合）到**值域**（所有对应输出的集合）的映射。因此，程序规约就是函数规约。
- **明确定义的函数应具备以下特性**，这些特性对应了程序设计的正确性验证：
- **✓ 完备性**：定义域中每个元素在值域中至少有一个对应元素。对程序而言，每种可能的输入都必须有定义且对应一个输出。
- **✓ 一致性**：值域中最多有一个元素与定义域中的同一元素对应。对程序而言，每个输入只能对应一个确定的输出。
- **✓ 正确性**：函数的正确性可由完备性和一致性判断。对程序而言，设计的正确性可基于此理论进行推理验证。
### 2.2 抽样理论
- **核心思想**：由于无法对软件所有可能的使用场景进行穷尽测试，将“所有可能的使用情况”视为**总体**。
- **方法**：通过**统计学手段**从总体中抽样，并对样本（测试用例）进行测试，然后根据测试结果来分析和推断软件的**整体性能与可靠性**（如预计的出错率）。
## 3. 方法与实践要点
- **建模方法**：使用**盒结构规约**进行分析和设计建模。
- **核心机制**：强调将**正确性验证**（而非传统测试）作为发现和消除错误的主要机制。
- **测试作用**：使用**统计测试**来获取评估软件可靠性所必需的量化信息，以支持交付决策。
---
**核心总结**：净室软件工程是一种**以数学为基础、以预防缺陷为核心、以统计验证为评估手段**的高质量软件开发范式。
# 净室软件工程 (Cleanroom Software Engineering, CSE)
## 1. 概述
- **定义**：净室软件工程是一种应用**数学与统计学理论**，以经济的方式生产高质量软件的工程技术。
- **核心目标**：通过严格的工程化软件过程，达到开发中的**零缺陷或接近零缺陷**。
- **核心理念**：强调在**规约和设计阶段**就消除错误，以“净”的方式构建软件，从而降低开发风险，以合理成本开发出高质量软件。
## 2. 理论基础
净室软件工程的理论基础是**函数理论**和**抽样理论**。
### 2.1 函数理论
- **核心思想**：将程序视作一个**函数**，定义了从**定义域**（输入）到**值域**（输出）的映射。程序规约就是函数规约。
- **正确性特性**：
- **✓ 完备性**：每种可能的输入都必须有定义。
- **✓ 一致性**：每个输入只能对应一个确定的输出。
### 2.2 抽样理论
- **核心思想**：将“所有可能的使用情况”视为**总体**。通过**统计学手段**抽样测试，根据结果推断软件的**整体性能与可靠性**。
## 3. 核心技术手段
净室软件工程通过以下四种关键技术手段实现其高质量目标：
### 3.1 统计过程控制下的增量式开发
- **核心**：将整个开发过程划分为一系列**较小的、累积的增量**。
- **优点**：开发小组在任何时刻只需专注于当前增量的工作，**无需一次考虑所有事情**，降低了认知复杂度，便于过程控制和质量管理。
### 3.2 基于函数的规范与设计（盒结构方法）
按照函数理论，使用盒结构方法在三种抽象层次上进行规约与设计：
| 抽象层次 | 视图类型 | 核心描述与关注点 |
| :--- | :--- | :--- |
| **黑盒 (Black Box)** | 行为视图 | 刻画系统或部件的外部**行为**。定义一组“激发(输入)-反应(输出)”的变迁规则，不关心内部状态与实现。 |
| **状态盒 (State Box)** | 有限状态机视图 | 以类似对象的方式**封装状态数据和服务(操作)**。在此视图中，明确标出状态盒的输入(激发)和输出(反应)，并揭示其内部状态数据。 |
| **清晰盒 (Clear Box)** | 过程视图 | 定义状态盒内部蕴含的**具体变迁过程（即过程设计）**。清晰盒包含了实现状态盒功能所需的详细逻辑与潜在的子盒结构。 |
**应用顺序**：规约从**黑盒**开始，逐步精化为**状态盒**，最后细化为**清晰盒**的设计。
### 3.3 正确性验证
- **核心地位**：是净室软件工程**最核心**的技术。
- **方法**：对盒结构规约和设计，应用**严格的数学推理和形式化验证技术**来证明其正确性（符合函数理论的要求）。
- **目标**：在代码实现之前，**在规约和设计层最大限度地消除逻辑缺陷**，这是软件质量得以极大提高的根本原因。
### 3.4 统计测试和软件认证
- **测试理念**：基于**统计学抽样原理**。由于无法进行穷尽测试，需构建代表系统所有可能使用场景的**使用模型**（作为总体）。
- **测试过程**：从使用模型中**随机生成测试用例**（作为样本）进行测试。
- **认证目标**：根据样本测试结果，进行有效的**统计推导**，以评估和认证软件在预期操作环境中的**可靠性、性能**等质量指标，为软件发布提供量化依据。
---
**总结**：净室软件工程是一种**以数学为基础、以缺陷预防为核心、以统计验证为评估手段**的严谨开发范式。它通过**增量开发**控制过程，通过**盒结构**进行严格规约与设计，通过**正确性验证**在早期消灭缺陷，最后通过**统计测试**进行科学认证，从而系统性地保障软件的高质量。
# 补充：净室软件工程 (CSE) 的缺点
净室软件工程虽然强调通过数学和统计学方法生产高质量软件，但其在实际应用中存在一些明显的局限性和挑战。
## 主要缺点
| 序号 | 缺点描述 | 具体说明与挑战 |
| :--- | :--- | :--- |
| **①** | **过于理论化，实施成本高** | - 需要开发人员具备较多的**数学知识**。
- 正确性验证的步骤**比较困难且耗时**。
- 要求掌握增量式开发、盒结构、统计测试等特定方法，**普通工程师需加强训练**才能掌握，导致**开发成本比较高昂**。 |
| **②** | **跳过传统模块测试不现实** | - 认为不进行传统的模块测试是**不现实的**。
- 工程师可能对**编程语言和开发环境还不熟悉**。
- **编译器或操作系统的Bug**也可能导致未预期的错误，而这些在净室方法的早期验证中可能难以发现。 |
| **③** | **未能完全摆脱传统弊端** | - CSE毕竟**脱胎于传统软件工程**，不可避免地**带有传统软件工程的一些弊端**。其理想化的流程在复杂、多变的现实开发环境中可能难以完全贯彻。 |
## 总结
净室软件工程（CSE）是一种以**严格验证和缺陷预防**为核心的高质量软件开发范式。其**优点**在于理论上能极大降低缺陷数，但其**缺点**也很突出：理论复杂、实施成本高、对环境和人员要求苛刻，且在实践中可能难以完全规避传统工程方法的问题。因此，它更适合于对**可靠性要求极高、预算和周期相对充裕**的关键系统开发。
# 基于构件的软件工程 (CBSE)
## 1. 概述
- **全称**：基于构件的软件工程 (Component-Based Software Engineering, CBSE)
- **本质**：一种基于**分布对象技术**，强调通过**可复用构件**来设计与构造软件系统的软件复用途径。
- **核心哲学**：体现了 **“购买而不是重新构造”** 的思想。将开发重点从程序编写转移到了基于已有构件的**组装**，以达成以下目标：
1. **更快地**构造系统。
2. **减轻**系统的维护负担。
3. **降低**软件开发的费用。
## 2. 构件
### 2.1 定义
构件是一个**独立的软件单元**，可以与其他构件组合构成一个软件系统。系统中的构件可以是：
- **COTS构件**：商用现货构件。
- **自行开发构件**。
### 2.2 构件的五大特征
一个合格的构件应具备以下特征：
| 特征 | 核心要求与说明 |
| :--- | :--- |
| **(1) 可组装性** | 所有外部交互都必须通过**公开定义的接口**进行。 |
| **(2) 可部署性** | 必须是**自包含**的独立实体，能以**二进制形式**在构件平台上直接运行，**无须在部署前编译**。 |
| **(3) 文档化** | 必须提供完全文档，用户据此判断构件是否满足需求。 |
| **(4) 独立性** | 应能独立组装和部署。如需其他构件服务，必须**显式声明**依赖。 |
| **(5) 标准化** | 必须符合某种**标准化的构件模型**。 |
## 3. 主流构件模型
目前主流的构件模型主要包括以下三种：
1. **Web Services 模型**
2. **Sun公司的 EJB (Enterprise JavaBeans) 模型**
3. **微软的 .NET 模型**
---
**总结**：CBSE通过使用符合标准、具备可组装、可部署等特征的预制构件，改变了传统的软件开发模式，致力于提升开发效率、降低成本和改善可维护性。
# 基于构件的软件工程 (CBSE) - 过程与组装
## 1. CBSE 开发过程
基于构件的软件工程遵循一个系统的、以构件为核心的开发流程，主要包括以下六个步骤：
| 步骤 | 核心任务与说明 |
| :--- | :--- |
| **1. 系统需求概览** | 对系统进行整体需求分析，明确目标和范围。 |
| **2. 识别候选构件** | 根据需求，在构件库或市场中寻找、评估和选择潜在的可用构件。 |
| **3. 根据发现的构件修改需求** | 基于实际可用构件的功能和约束，**调整和细化**原始需求，使需求更贴合可复用资产。 |
| **4. 体系结构设计** | 设计系统的整体结构，确定所选构件如何组织、交互以及如何与可能的新开发部分集成。 |
| **5. 构件定制与适配** | 对选定的构件进行必要的修改、配置或包装，以满足系统的特定集成要求。 |
| **6. 组装构件创建系统** | 将定制后的构件通过“胶水代码”或集成框架连接起来，构建出完整的可运行系统。 |
## 2. 构件组装
### 2.1 定义
构件组装是指将多个构件**相互集成**，或通过专门编写的 **“胶水代码”** 将它们整合在一起，从而创造出一个新系统或一个更大构件的**过程**。
### 2.2 常见组装方式
常见的构件组装主要有三种方式：**顺序组装、层次组装、叠加组装**。下图详细说明了其中一种基础且重要的方式：
#### **顺序组装**
- **核心思想**：通过**按顺序调用**已存在的构件，来创造一个新的构件。
- **适用场景**：适用于作为**程序元素**的构件或作为**服务**的构件。
- **关键要求**：需要编写特定的“胶水代码”，以确保两个被组装的构件能够正确协作。此代码的核心任务是保证：
> **上一个构件的输出** 与 **下一个构件的输入** 相兼容。
---
**流程总结**：CBSE过程从需求出发，经历“寻找构件-调整设计-集成组装”的迭代，最终通过构件组装（尤其是顺序调用配合胶水代码）实现系统构建，体现了“购买而非构造”的核心理念。
# 基于构件的软件工程 (CBSE)
## 1. 概述
- **全称**：基于构件的软件工程 (Component-Based Software Engineering, CBSE)
- **本质**：一种基于**分布对象技术**，强调通过**可复用构件**来设计与构造软件系统的软件复用途径。
- **核心哲学**：体现了 **“购买而不是重新构造”** 的思想。将开发重点从程序编写转移到了基于已有构件的**组装**，以达成以下目标：
1. **更快地**构造系统。
2. **减轻**系统的维护负担。
3. **降低**软件开发的费用。
## 2. 构件
### 2.1 定义
构件是一个**独立的软件单元**，可以与其他构件组合构成一个软件系统。系统中的构件可以是：
- **COTS构件**：商用现货构件。
- **自行开发构件**。
### 2.2 构件的五大特征
一个合格的构件应具备以下特征：
| 特征 | 核心要求与说明 |
| :--- | :--- |
| **(1) 可组装性** | 所有外部交互都必须通过**公开定义的接口**进行。 |
| **(2) 可部署性** | 必须是**自包含**的独立实体，能以**二进制形式**在构件平台上直接运行，**无须在部署前编译**。 |
| **(3) 文档化** | 必须提供完全文档，用户据此判断构件是否满足需求。 |
| **(4) 独立性** | 应能独立组装和部署。如需其他构件服务，必须**显式声明**依赖。 |
| **(5) 标准化** | 必须符合某种**标准化的构件模型**。 |
## 3. 主流构件模型
目前主流的构件模型主要包括以下三种：
1. **Web Services 模型**
2. **Sun公司的 EJB (Enterprise JavaBeans) 模型**
3. **微软的 .NET 模型**
## 4. CBSE 开发过程
基于构件的软件工程遵循一个系统的、以构件为核心的开发流程，主要包括以下六个步骤：
| 步骤 | 核心任务与说明 |
| :--- | :--- |
| **1. 系统需求概览** | 对系统进行整体需求分析，明确目标和范围。 |
| **2. 识别候选构件** | 根据需求，在构件库或市场中寻找、评估和选择潜在的可用构件。 |
| **3. 根据发现的构件修改需求** | 基于实际可用构件的功能和约束，**调整和细化**原始需求，使需求更贴合可复用资产。 |
| **4. 体系结构设计** | 设计系统的整体结构，确定所选构件如何组织、交互以及如何与可能的新开发部分集成。 |
| **5. 构件定制与适配** | 对选定的构件进行必要的修改、配置或包装，以满足系统的特定集成要求。 |
| **6. 组装构件创建系统** | 将定制后的构件通过“胶水代码”或集成框架连接起来，构建出完整的可运行系统。 |
## 5. 构件组装
### 5.1 定义
构件组装是指将多个构件**相互集成**，或通过专门编写的 **“胶水代码”** 将它们整合在一起，从而创造出一个新系统或一个更大构件的**过程**。
### 5.2 常见组装方式
常见的构件组装主要有三种方式：
#### **(1) 顺序组装**
- **核心思想**：通过**按顺序调用**已存在的构件，来创造一个新的构件。
- **适用场景**：适用于作为**程序元素**的构件或作为**服务**的构件。
- **关键要求**：需要编写特定的“胶水代码”，以确保两个被组装的构件能够正确协作。此代码的核心任务是保证：
> **上一个构件的输出** 与 **下一个构件的输入** 相兼容。
#### **(2) 层次组装**
- **核心思想**：一个构件**直接调用**由另一个构件所提供的服务。
- **角色关系**：被调用的构件为调用的构件提供所需的服务。
- **接口要求**：被调用构件的 **“提供”接口** 必须和调用构件的 **“请求”接口** 兼容。
- **胶水代码**：如果接口不匹配，则需要编写专门的**胶水代码**来实现转换。
#### **(3) 叠加组装**
- **核心思想**：将两个或两个以上构件放在一起，**合并其功能**，从而**创建一个新构件**。
- **接口变化**：新构件对外**提供新的接口**，外部应用通过这个新接口来间接调用原有构件的功能。
- **原有构件关系**：原有构件之间**不互相依赖，也不互相调用**，彼此独立。
---
**总结**：CBSE通过使用符合标准、具备可组装、可部署等特征的预制构件，并运用顺序、层次、叠加等方式进行灵活组装，改变了传统的软件开发模式，致力于提升开发效率、降低成本和改善可维护性。
# 软件项目管理
## 一、项目管理概述
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对**人员(People)、产品(Product)、过程(Process)和项目(Project)**进行分析和管理的活动。
## 二、进度管理
进度管理是为了确保项目按期完成所需要的管理过程。其主要活动包括以下六个步骤：
1. **活动定义**：识别为完成项目可交付成果而需采取的具体行动。
2. **活动排序**：识别和记录项目活动之间的逻辑关系与依赖。
3. **活动资源估算**：估算每项活动所需的人员、材料、设备等资源类型和数量。
4. **活动历时估算**：根据资源估算结果，估算完成单项活动所需的工作时段数。
5. **制定进度计划**：分析活动顺序、持续时间、资源需求和进度制约因素，创建项目进度模型（如甘特图）。
6. **进度控制**：监督项目状态，更新项目进展，管理进度基准的变更。
## 三、工作分解结构
**工作分解结构 (Work Breakdown Structure, WBS)** 是把一个项目，按一定的原则分解成**任务**，任务再分解成一项项**工作**，再把工作分配到每个人的**日常活动**中。
其核心分解路径为：**项目 → 任务 → 工作 → 日常活动**。
在软件项目中，这通常体现为：**软件系统 → 子系统/组件 → 功能模块 → 具体编程/测试活动**。WBS是进行估算、制定预算、规划进度和分配资源的基础。
# 项目管理
## 一、项目管理概述
**软件项目管理**是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对以下四个核心要素进行分析和管理的活动：
- **人员 (People)**
- **产品 (Product)**
- **过程 (Process)**
- **项目 (Project)**
## 二、进度管理（时间管理）
进度管理是确保项目按期完成所需要的管理过程。其主要包含以下六个活动过程：
| 序号 | 主要活动 | 说明 |
| :--- | :--- | :--- |
| 1 | **活动定义** | 识别为完成项目可交付成果而需采取的具体行动。 |
| 2 | **活动排序** | 识别和记录项目活动之间的逻辑关系与依赖。 |
| 3 | **活动资源估算** | 估算每项活动所需的人员、材料、设备等资源的类型和数量。 |
| 4 | **活动历时估算** | 根据资源估算结果，估算完成单项活动所需的工作时段数。 |
| 5 | **制定进度计划** | 分析活动顺序、持续时间、资源需求和进度制约因素，创建项目进度模型。 |
| 6 | **进度控制** | 监督项目状态，更新项目进展，管理进度基准的变更。 |
## 三、工作分解结构
**工作分解结构 (Work Breakdown Structure, WBS)** 是把一个项目，按一定的原则分解，其路径为：
**项目 → 任务 → 工作 → 日常活动**。
在软件项目中，这通常体现为：**软件系统 → 子系统/组件 → 功能模块 → 具体编程/测试活动**。WBS是进行项目估算、计划、控制和分配工作的基础。
# 项目管理 - 工作分解与活动图
## 1. 工作分解结构的基本要求（原则）
进行工作分解时，应遵循以下基本原则以确保分解的有效性：
1. **可控可管理**：WBS中的工作包必须是**可控和可管理的**，不能过于复杂。
2. **粒度适中**：任务分解**不能过细**，一般原则是WBS的树形结构不超过**6层**。
3. **明确交付物**：每个工作包都必须有**一个明确的交付成果**。
4. **明确完成标准**：每个任务都必须有**明确定义的完成标准**。
5. **利于责任分配**：WBS的结构必须**有利于责任的分配**，确保每项工作都能落实到具体的个人或小组。
## 2. 任务活动图
### 2.1 活动定义
活动定义是指确定为完成项目的各个交付成果所必须进行的各项具体活动。其核心是明确每个活动的：
- **前驱活动**（哪些活动必须先完成）
- **持续时间**
- **必须完成日期**
- **关联的里程碑或交付成果**
### 2.2 任务活动图的表示方法
主要有两种图形化表示方法用于描述活动顺序和依赖关系：
| 方法 | 别称 | 核心特点 |
| :--- | :--- | :--- |
| **前导图法** | 单代号网络图法 | 用**节点（框）**表示活动，用**箭线**表示活动之间的逻辑关系。 |
| **箭线图法** | 双代号网络图法 | 用**箭线**表示活动，用**节点（通常为圆圈）**表示事件的开始或完成。 |
# 软件配置管理 (SCM)
## 1. 定义与目标
- **定义**：软件配置管理 (Software Configuration Management, SCM) 是一种**标识、组织和控制修改**的技术。
- **应用范围**：应用于整个软件工程过程。
- **产生的背景**：在软件构建过程中，变更是不可避免的，而变更加剧了开发者之间的混乱。
- **核心目标**：
1. **标识变更**
2. **控制变更**
3. **确保变更正确实现**
4. **向其他有关人员报告变更**
- **根本目的**：使错误降至最小，并最有效地提高生产效率。
## 2. 核心内容
软件配置管理的核心内容包括以下两部分：
| 核心内容 | 说明 |
| :--- | :--- |
| **版本控制 (Version Control)** | 对软件资产（如源代码、文档）的不同版本进行标识、存储和管理。 |
| **变更控制 (Change Control)** | 对变更进行管理，**目的并非阻止变更发生**，而是**确保变更有序进行**。它为变更请求提供标准化的流程（如提交、评估、批准、实施、验证）。 |
## 3. 项目中引起变更的因素
变更请求主要来源于两个方面：
| 因素来源 | 具体描述 | 处理难度比较 |
| :--- | :--- | :--- |
| **外部变更要求** | 来自客户或外部干系人，如修改工作范围、需求等。 | **最难处理**。因为IT项目需求变更概率大，且引发的工作量也大，尤其在项目后期。 |
| **内部变更要求** | 来自开发过程内部，如为解决测试中发现的错误而修改源码或设计。 | 相对可控。 |
> **总结**：SCM通过系统的版本管理和严格的变更控制流程，应对软件开发中必然出现的变更，特别是难以应对的外部需求变更，以保障项目在受控状态下有序推进。
# 软件配置管理 (SCM) - 完整知识
## 1. 定义与目标
- **定义**：软件配置管理是一种**标识、组织和控制修改**的技术，应用于整个软件工程过程。
- **核心目标**：
1. **标识变更**
2. **控制变更**
3. **确保变更正确实现**
4. **向其他有关人员报告变更**
- **根本目的**：使错误降至最小，并最有效地提高生产效率。
## 2. 核心内容
软件配置管理的核心内容包括以下两部分：
| 核心内容 | 说明 |
| :--- | :--- |
| **版本控制 (Version Control)** | 对软件资产（如源代码、文档）的不同版本进行标识、存储和管理。 |
| **变更控制 (Change Control)** | 对变更进行管理，**目的并非阻止变更发生**，而是**确保变更有序进行**。它为变更请求提供标准化的流程。 |
## 3. 配置库 (Configuration Library)
配置库是存储和管理所有配置项及其版本的仓库。根据对配置项的控制级别，通常分为三类：
| 库类型 | 别称 | 主要用途与特点 | 访问与修改控制 |
| :--- | :--- | :--- | :--- |
| **动态库**
(Development Library) | 开发库、程序员库、工作库 | 保存开发人员**当前正在开发**的配置实体（如正在编写的代码模块）。 | 开发人员可**随意修改**，是私有的或小组共享的工作区。 |
| **受控库**
(Controlled Library) | 主库、系统库 | 管理**当前基线**和控制对基线的变更。包含已被提升并集成的配置项，用于创建测试版本或发布构建。 | 可自由**复制/读取**。但**必须经过授权流程**（如变更控制委员会批准）才能进行修改。 |
| **静态库**
(Static Library) | 软件仓库、软件产品库 | 用于**存档**各种已广泛使用的、**已发布的基线**（如正式发布的版本）。 | **只读**。存档的基线**不能修改**，用于发布、回滚或作为历史记录。 |
**流程关系**：代码通常在**动态库**中开发，达到一定稳定状态后提升至**受控库**形成基线，经测试和批准后，最终发布版本存入**静态库**。
## 4. 项目中引起变更的因素
变更请求主要来源于两个方面：
| 因素来源 | 具体描述 | 处理难度比较 |
| :--- | :--- | :--- |
| **外部变更要求** | 来自客户或外部干系人，如修改工作范围、需求等。 | **最难处理**。因为IT项目需求变更概率大，且引发的工作量也大，尤其在项目后期。 |
| **内部变更要求** | 来自开发过程内部，如为解决测试中发现的错误而修改源码或设计。 | 相对可控。 |
> **总结**：SCM通过**版本控制、变更控制**以及**动态、受控、静态三库**的体系，系统性地管理软件开发中的变更与资产，保障项目在受控状态下有序推进，并维护产品的完整性和可追溯性。
# 软件质量管理
## 1. 软件质量保证 (SQA) 的关注点与目标
软件质量保证的关注点集中于**一开始就避免缺陷的产生**，而非事后检查。其主要目标包括：
| 目标 | 核心思想 |
| :--- | :--- |
| **① 事前预防** | 着重于**缺陷预防**，而不是缺陷检查。 |
| **② 早期捕获** | 力求在缺陷**刚刚被引入时**就将其发现并纠正，防止其扩散到后续阶段。 |
| **③ 作用于过程** | 关注**改进软件过程本身**，而非仅仅检查最终产品。这能带来更广泛的影响和更大的收益。 |
| **④ 全面贯穿** | 质量保证活动应**贯穿于所有开发活动之中**，而不是只集中在某个特定点。 |
## 2. 软件质量保证的主要任务
软件质量保证主要包含以下三个方面的工作：
| 任务 | 具体内容与原则 |
| :--- | :--- |
| **① SQA审计与评审** | 对**软件工作产品、工具和设备**进行审计，评估其是否符合组织规定的标准。 |
| **② SQA报告** | 记录工作结果并生成报告。报告发布需遵循三条原则：
1. SQA与高级管理者之间应有**直接沟通渠道**。
2. 报告必须发布给**软件工程组**，但不必发布给项目管理人员。
3. 在可能的情况下，向所有关心软件质量的人员发布。 |
| **③ 处理不符合问题** | 这是SQA的一项重要任务，即跟踪和处理审计中发现的不符合标准或规范的问题。 |
## 3. 软件质量认证
目前国内软件企业主要采用的质量认证模式有两种：
1. **ISO 9000** 系列标准
2. **能力成熟度模型 (Capability Maturity Model, CMM)**
---
**核心总结**：软件质量管理通过**以预防为核心、过程为导向**的质量保证活动，并借助审计、报告和问题处理等任务，系统性地提升软件质量。最终可通过国际或行业标准（如ISO 9000、CMM）进行能力认证。
# 软件风险管理
## 1. 核心定义
**项目风险**是一种不确定的事件或条件，一旦发生，会对项目目标产生某种正面或负面影响。
## 2. 风险管理的主要活动过程
风险管理是一个系统性的过程，主要包括以下六个活动：
| 序号 | 活动过程 | 核心任务与目标 |
| :--- | :--- | :--- |
| 1 | **风险管理计划编制** | 定义如何实施项目风险管理活动，制定风险管理的整体方案和计划。 |
| 2 | **风险识别** | 判断哪些风险可能影响项目，并将其特征记录在案。 |
| 3 | **风险定性分析** | 评估并综合分析风险的发生概率和影响，对风险进行优先级排序。 |
| 4 | **风险定量分析** | 就已识别的风险对项目整体目标的（数值化）影响进行定量分析。 |
| 5 | **风险应对计划编制** | 针对项目目标，制定提高机会、降低威胁的方案和措施。 |
| 6 | **风险监控** | 在整个项目生命周期中，跟踪已识别的风险、监测残余风险、识别新风险，并评估风险过程有效性。 |
# 补充 - 逆向工程
## 1. 概述
逆向工程源于硬件领域，在软件工程中，其核心思想类似于“分析现有系统以理解其设计”。它是指**分析已有程序**，旨在寻求比源代码更高层次的抽象表现形式，从而理解、恢复或改进系统的过程。
## 2. 核心概念
| 概念 | 定义与说明 |
| :--- | :--- |
| **逆向工程** | 分析目标系统，以识别其组件及相互关系，并**创建更高抽象层次**的系统表示（如设计模型、架构图）。 |
| **重构** | 在**同一抽象级别**上，转换系统的描述形式（如代码），以改善其内部结构，但不改变其外部行为。 |
| **设计恢复** | 借助工具从已有程序中**抽象出有关数据设计、总体结构设计和过程设计**等信息。这是逆向工程的核心活动之一。 |
| **再工程** | 对现有系统进行**重新开发**的完整过程。旨在结合新技术和新需求，全面提升系统。它包括三个关键步骤：**逆向工程、新需求的考虑过程和正向工程**。 |
| **正向工程** | 不仅从现有系统中恢复设计信息，而且**使用该信息去改变或重构现有系统**，以改善其整体质量。通常是从需求或设计出发，生成代码的传统过程。 |
## 3. 概念间的关系
再工程是一个综合性的循环改进过程，其典型流程可以概括为：
[现有系统] → (逆向工程) → [理解与抽象] → (结合新需求) → (正向工程) → [新/改进的系统]
## 4. 逆向工程的完备性分级
逆向工程所能恢复的信息层次和完整性有所不同，从具体到抽象可分为以下四级：
| 级别 | 包含的信息 | 说明 |
| :--- | :--- | :--- |
| **实现级** | 程序的抽象语法树、符号表、过程的设计表示。 | 最具体的级别，接近代码本身的结构。 |
| **结构级** | 反映程序分量之间相互依赖关系的信息，如**调用图、结构图、程序和数据结构**。 | 描述了模块/组件间的静态关系。 |
| **功能级** | 反映程序段功能及程序段之间关系的信息，如**数据和控制流模型**。 | 描述了系统的动态行为与逻辑。 |
| **领域级** | 程序分量或程序实体与应用领域概念之间对应关系的信息，如**实体关系模型**。 | 最高、最抽象的级别，关联了代码与业务知识。 |
**总结**：逆向工程是从具体实现（代码）向抽象设计乃至业务领域概念进行回溯和理解的关键技术，是系统维护、演化与再工程的基础。
# 面向对象设计原则
面向对象设计有一些被广泛认可的基本原则，遵循这些原则有助于构建出灵活、可维护、可扩展的软件系统。以下是七大核心设计原则：
| 设计原则 | 核心思想与重要特性 |
| :--- | :--- |
| **单一职责原则 (SRP)** | 一个类应该**只负责一项职责**，不能将太多的职责放在一个类中。目标是设计功能单一的类。 |
| **开闭原则 (OCP)** | 对**扩展开放**，对**修改关闭**。即软件实体（类、模块、函数等）应该**在不修改原有代码的基础上**，通过扩展来实现新的功能。 |
| **里氏替换原则 (LSP)** | 所有引用基类（父类）的地方必须能**透明地使用其子类的对象**。子类可以完全替换父类。具体要求：
1. 子类可以增加自己特有的方法。
2. 子类重载父类方法时，**前置条件（输入参数）应更宽松**。
3. 子类实现父类抽象方法时，**后置条件（返回值）应更严格**。 |
| **依赖倒转原则 (DIP)** | 针对**接口（抽象）编程**，而不要针对实现（具体的类）编程。即高层模块不应依赖低层模块，二者都应依赖其抽象。 |
| **接口隔离原则 (ISP)** | 使用**多个专门的、细粒度的接口**，而不使用单一的、臃肿的总接口。客户端不应该被强迫依赖它不用的接口。 |
| **合成复用原则 (CRP)** | 在系统中应**尽量多使用组合(has-a)/聚合(contains-a)关系**，**少使用继承(is-a)关系**。因为继承带来的父子强耦合会降低灵活性。组合关系更松散。 |
| **迪米特法则 (LoD)**
(最少知识原则) | 一个对象应该**对其他对象保持最少的了解**（“不要和陌生人说话”）。只与直接的朋友通信，降低类之间的耦合度。 |
**核心总结**：
这些原则共同的目标是降低系统的耦合度，提高内聚性，增强可维护性和可扩展性。其中，**开闭原则**是面向对象设计的终极目标，而**依赖倒转原则**是实现开闭原则的主要手段。
# 补充 - 软件维护
在系统运行过程中，软件需要维护的原因多样。根据维护的原因不同，可以将软件维护分为以下4种类型。
| 维护类型 | 核心原因与目的 | 形象比喻 |
| :--- | :--- | :--- |
| **改正性维护** | 为了**识别和纠正软件错误**、改正软件性能上的缺陷、排除实施中的误使用。 | **知错能改** |
| **适应性维护** | 为适应变化的外部环境（新的硬、软件配置）或数据环境（数据库、数据格式、存储介质等）。 | **与时俱进** |
| **完善性维护** | 为满足用户提出的**新功能与性能要求**，扩充功能、增强性能、提高效率或可维护性。 | **锦上添花** |
| **预防性维护** | **预先**提高软件的可维护性、可靠性等，为未来改进打下基础。即“把今天的方法学用于昨天的系统以满足明天的需要”。 | **防患于未然** |
**总结**：软件维护并非只是“修bug”，它是一个持续的质量与价值提升过程，涵盖了从纠正错误、适应环境、增强功能到前瞻性优化的全部活动。
# 补充 - 系统转换
## 1. 定义
**系统转换**是指新系统开发完毕、投入运行，以取代现有（旧）系统的过程。这是一个关键阶段，需要考虑多方面问题，以确保新旧系统平稳交接。
## 2. 三种主要转换计划
系统转换主要有以下三种计划，各有其适用场景和特点：
| 转换计划 | 核心描述 | 适用场景 | 优点 | 缺点与风险 |
| :--- | :--- | :--- | :--- | :--- |
| **直接转换**
(直接切换) | 在某一确定时间点，**现有系统被新系统直接、完全取代**。 | 新系统不复杂，或现有系统已经完全不能使用的情况。 | **节省成本**，实施过程简单直接。 | **风险极大**。一旦新系统出现问题，业务将面临中断，无回退方案。 |
| **并行转换** | 新系统与老系统**并行工作一段时间**，新系统经过充分试运行后再完全取代旧系统。 | 适用于**大型、关键**的信息系统。 | **风险极低**。新系统有问题不影响业务运行；可比较新旧系统性能，验证结果。 | **耗费大量人力和时间资源**（需两套系统同时维护）；难以控制两个系统间的数据转换与同步。 |
| **分段转换**
(逐步转换) | 分期分批逐步转换。是直接和并行转换的结合，将大型系统划分为多个子系统，依次试运行和转换。 | 适用于**大型、复杂**的项目，允许分阶段实施和验证。 | **风险可控**，每次只转换一个子系统，影响范围小；资金和人力可分阶段投入。 | **更耗时**（整体转换周期长）；新旧系统在过渡期混合运行，**需要协调好接口与数据一致性问题**，管理复杂度高。 |
## 3. 总结与选择要点
- **风险与成本权衡**：**直接转换**风险最高但成本最低；**并行转换**风险最低但成本最高；**分段转换**是折中方案，在风险、成本和时间之间取得平衡。
- **关键考量因素**：选择转换计划时，应综合考虑**系统规模与复杂性、业务连续性要求、可用资源（时间、人力、预算）以及技术可行性**。
> **核心提示**：对于重要业务系统，**并行转换**因其安全性常被优先考虑；而对于模块化清晰的大型系统，**分段转换**是更可行和稳妥的策略。
# 补充 - 遗留系统改造
## 1. 遗留系统的定义
**遗留系统**指的是任何基本上**不能进行修改和演化**以满足新的、变化了的业务需求的信息系统。
## 2. 遗留系统的特点
1. **功能不全**：系统虽然完成企业中的许多重要业务管理工作，但是**不能全部满足**要求。
2. **技术落后**：系统在性能上已经落后，采用的**技术已经过时**。
3. **维护困难**：通常是**大型的软件系统**，已经融入企业的业务运作和决策管理机制之中，维护工作十分困难。
4. **文档缺失**：没有使用现代信息系统建设方法进行管理和开发，现在**基本上已经没有文档**，很难理解。
## 策略详解
- **高水平，高价值 (改造)**：系统技术基础好且业务关键。**策略**：在现有基础上优化、增加功能或重构，是改造的**首选目标**。
- **低水平，高价值 (继承)**：系统业务关键但技术落后。**策略**：需要**全面重新开发**，在继承功能的同时采用新技术。
- **高水平，低价值 (集成)**：系统技术较好但业务价值不高。**策略**：将其功能**封装**并**集成**到新架构中，不再对其本身做大改。
- **低水平，低价值 (淘汰)**：系统两方面价值都低。**策略**：**停止使用**，相关功能由新系统替代或废弃。
> **核心**：该模型为决策者提供了清晰的系统评估与处置框架。
# 补充 - 遗留系统改造策略
## 1. 淘汰策略
- **适用条件**：遗留系统的**技术含量较低**，且具有**较低的商业价值**。
- **核心思想**：对遗留系统的完全淘汰是资源浪费，应善于 **“变废为宝”**。
- **具体措施**：通过理解与借鉴遗留系统的功能，可以帮助新系统的设计，从而**降低新系统开发的风险**。
## 2. 继承策略
- **适用条件**：遗留系统**技术含量较低**，但能满足企业运作要求，且具有**较高的商业价值**，业务紧密依赖该系统。
- **核心思想**：开发新系统时，需**完全兼容**遗留系统的功能模型和数据模型。
- **具体措施**：为保证业务连续性，新老系统必须**并行运行**一段时间，再逐渐切换到新系统。
## 3. 改造策略
- **适用条件**：遗留系统具有**较高的业务价值**，能基本满足企业业务运作和决策支持需要（可能建成时间较短）。
- **核心思想**：在原有系统基础上进行演化改造。
- **改造方向**：
1. **系统功能增强**：增加新的应用需求，对遗留系统本身不做改变。
2. **数据模型改造**：将遗留系统的旧数据模型向新的数据模型转化。
## 4. 集成策略
- **适用条件**：遗留系统**技术含量较高**，但**业务价值较低**，可能只完成某个部门（或子公司）的业务管理。
- **核心问题**：此类系统在局部工作良好，但在企业层面会形成多个基于不同平台、不同数据模型的 **“信息孤岛”**。
- **核心思想**：通过集成，解决信息孤岛问题，实现系统间的互联与数据共享。
# 数据库系统结构 - 三级模式与两级映像
## 1. 概述
数据库系统的三级模式（外模式、概念模式、内模式）与两级映像是实现**数据独立性**和**多用户共享**的核心架构。它有效地将用户的应用程序与数据库的物理存储分离开来。
## 2. 三级模式详解
| 模式层级 | 别称 | 定义与描述 | 数量说明 |
| :--- | :--- | :--- | :--- |
| **外模式** | 子模式、用户模式 | 数据库用户（包括应用程序员和最终用户）能够看见和使用的**局部数据的逻辑结构和特征的描述**。 | 一个数据库可有**多个**外模式，每个用户或用户组对应一个。 |
| **概念模式** | 模式、逻辑模式 | 数据库中**全体数据的逻辑结构和特征的描述**，是所有用户的公共数据视图。 | 一个数据库只有**一个**概念模式。 |
| **内模式** | 存储模式 | 数据**物理结构和存储方式的描述**，是数据在数据库内部的表示方式（如存储记录类型、索引组织方式等）。 | 一个数据库只有**一个**内模式。 |
## 3. 两级映像与数据独立性
两级映像是连接三个抽象级别的桥梁，是**实现数据独立性的关键**。
| 映像 | 作用 | 保障的独立性 | 机制说明 |
| :--- | :--- | :--- | :--- |
| **外模式/概念模式映像** | 定义了**外模式与概念模式**之间的对应关系。 | **逻辑独立性** | 当**概念模式**改变时（如增加新关系、新属性），由数据库管理员修改此映像，可使**外模式保持不变**，从而基于外模式的应用程序也无需修改。 |
| **概念模式/内模式映像** | 定义了**概念模式与内模式**之间的对应关系。 | **物理独立性** | 当**内模式**改变时（如存储结构、存储设备变化），由数据库管理员修改此映像，可使**概念模式保持不变**，从而应用程序同样无需改变。 |
## 4. 访问流程示意
用户或应用程序访问数据库的典型路径如下：
根据您提供的关于数据库“三级模式两级映像”架构的PPT图片，已为您整理出清晰的结构化笔记。
# 数据库系统结构 - 三级模式与两级映像
## 1. 概述
数据库系统的三级模式（外模式、概念模式、内模式）与两级映像是实现**数据独立性**和**多用户共享**的核心架构。它有效地将用户的应用程序与数据库的物理存储分离开来。
## 2. 三级模式详解
| 模式层级 | 别称 | 定义与描述 | 数量说明 |
| :--- | :--- | :--- | :--- |
| **外模式** | 子模式、用户模式 | 数据库用户（包括应用程序员和最终用户）能够看见和使用的**局部数据的逻辑结构和特征的描述**。 | 一个数据库可有**多个**外模式，每个用户或用户组对应一个。 |
| **概念模式** | 模式、逻辑模式 | 数据库中**全体数据的逻辑结构和特征的描述**，是所有用户的公共数据视图。 | 一个数据库只有**一个**概念模式。 |
| **内模式** | 存储模式 | 数据**物理结构和存储方式的描述**，是数据在数据库内部的表示方式（如存储记录类型、索引组织方式等）。 | 一个数据库只有**一个**内模式。 |
## 3. 两级映像与数据独立性
两级映像是连接三个抽象级别的桥梁，是**实现数据独立性的关键**。
| 映像 | 作用 | 保障的独立性 | 机制说明 |
| :--- | :--- | :--- | :--- |
| **外模式/概念模式映像** | 定义了**外模式与概念模式**之间的对应关系。 | **逻辑独立性** | 当**概念模式**改变时（如增加新关系、新属性），由数据库管理员修改此映像，可使**外模式保持不变**，从而基于外模式的应用程序也无需修改。 |
| **概念模式/内模式映像** | 定义了**概念模式与内模式**之间的对应关系。 | **物理独立性** | 当**内模式**改变时（如存储结构、存储设备变化），由数据库管理员修改此映像，可使**概念模式保持不变**，从而应用程序同样无需改变。 |
## 4. 访问流程示意
用户或应用程序访问数据库的典型路径如下：
[用户/应用程序] (通过 主语言 + DML)
↓
[外模式] (用户特定的数据视图)
↓ (通过 外模式/概念模式映像 转换)
[概念模式] (全局逻辑视图，由DBMS管理)
↓ (通过 概念模式/内模式映像 转换)
[内模式] (物理存储视图)
↓
[物理数据库]
**核心总结**：三级模式**抽象**了数据的不同层次，两级映像**解耦**了这些层次。该架构确保了数据的物理存储和组织变动、全局逻辑结构的扩充，都不会影响到上层的应用程序，极大地增强了系统的稳定性和可维护性。
# 关系代数 - 集合运算符
关系代数是一种用于对关系（表）进行各种操作的抽象查询语言。其运算符主要分为**集合运算符**和**专门的关系运算符**两大类。以下重点介绍四种基础的集合运算符。
| 类别 | 运算符 | 含义 | 名词解释（定义与结果） |
| :--- | :--- | :--- | :--- |
| **集合运算符** | **∪** (并) | 并 | 关系R与S的**并**是由**属于R或属于S**的元组（行）构成的集合。 |
| | **－** (差) | 差 | 关系R与S的**差**是由**属于R但不属于S**的元组构成的集合。 |
| | **∩** (交) | 交 | 关系R与S的**交**是由**属于R同时又属于S**的元组构成的集合。 |
| | **×** (笛卡尔积) | 笛卡尔积 | 两个元组分别为n目和m目的关系R和S的**笛卡尔积**是一个 **(n+m) 列**的元组的集合。结果中每个元组的前n列来自R的一个元组，后m列来自S的一个元组。 |
**使用前提（并、差、交运算）**：关系R和S必须具有相同的属性个数（目数），且相应的属性取自同一个域（数据类型兼容），即两者是“并相容”的。
# 关系代数 - 专门的关系运算符
关系代数中，除了通用的集合运算符，还定义了对关系（表）本身进行操作的专门运算符。下表列出了其核心的三种运算符。
| 分类 | 运算符 | 含义 | 名词解释 |
| :--- | :--- | :--- | :--- |
| **专门的关系运算符** | **σ** (Sigma) | 选择 | 取得关系R中**符合指定条件**的行。 |
| | **π** (Pi) | 投影 | 取得关系R中**符合条件的列**（属性子集）。 |
| | **(=、⋈)** | 连接 | 连接关系R和S，主要分为两类：
1. **等值连接**：取关系R和S的笛卡尔积中，在**指定属性上取值相等**的元组。
2. **自然连接⋈**：一种特殊的等值连接，它要求**比较的属性列必须是相同的属性组**，并且会在**结果中去掉重复的属性列**。
**注意**：连接操作与简单的笛卡尔积有区别。 |
**核心总结**：
- **选择 (σ)**：对**行**进行筛选，操作的对象是**元组**。谓词为“**满足什么条件**”。
- **投影 (π)**：对**列**进行筛选，操作的对象是**属性**。谓词为“**包含哪些列**”。
- **连接*：将**两个关系**基于共同属性结合起来，生成一个新关系。其中**自然连接**是最常用的一种，它会自动处理同名属性的等值比较并消除重复列。
# 关系代数除法运算 R ÷ S 详解
**关系代数除法 R ÷ S 精要**
**1. 本质**
查找在关系 R 中，能“配齐”关系 S 中所有公共属性值的元组。
**形式**：R(X, Y) ÷ S(Y, Z)，Y 为公共属性，X 为专属属性。
**2. 核心步骤**
① **求象集**：找出 R 中每个 X 值对应的所有 Y 组合。
② **取投影**：获取 S 在 Y 上的所有值组合（去重）。
③ **判包含**：若某 X 的象集**包含** S 的 Y 投影，则该 X 入选结果。
**3. 关键与特例**
- 比较对象是 **X 的象集** 与 **S 在 Y 上的投影**。
- 特例：若 S 的 Y 投影为空，则结果为 R 中所有 X 值。
**4. 典型应用**
用于查询“具有所有…”的问题，如“选修了全部课程的学生”、“供应了所有零件的供应商”。
# 规范化理论 - Armstrong 公理系统
## 1. 概述
**Armstrong公理**是从已知的一组函数依赖（Functional Dependencies, F）出发，推导出蕴含于其中的其他函数依赖的一套形式化推理规则。该公理系统是数据库模式规范化的理论基础。
## 2. 基本推理规则 (Armstrong 公理)
设关系模式 R(U, F)，其中 U 是属性全集，F 是 U 上的一组函数依赖。以下是三条基本的 Armstrong 公理：
| 规则 | 名称 | 内容 | 简述 |
| :--- | :--- | :--- | :--- |
| **A1** | **自反律**
(Reflexivity) | 若 $Y \subseteq X \subseteq U$，则 $X \rightarrow Y$ 为 F 所蕴含。 | 属性集总能决定其自身的任何子集。 |
| **A2** | **增广律**
(Augmentation) | 若 $X \rightarrow Y$ 为 F 所蕴含，且 $Z \subseteq U$，则 $XZ \rightarrow YZ$ 为 F 所蕴含。 | 函数依赖两边可同时增加相同的属性集。 |
| **A3** | **传递律**
(Transitivity) | 若 $X \rightarrow Y$ 且 $Y \rightarrow Z$ 为 F 所蕴含，则 $X \rightarrow Z$ 为 F 所蕴含。 | 函数依赖具有传递性。 |
> **核心**：这三条规则是**正确且完备**的，即所有成立的函数依赖均可从F出发，仅用这三条规则推导出来。
## 3. 导出推理规则
根据上述三条基本公理，可以推导出以下三个常用的实用规则：
| 规则 | 名称 | 内容 | 说明与用途 |
| :--- | :--- | :--- | :--- |
| **合并规则**
(Union Rule) | 若 $X \rightarrow Y$ 且 $X \rightarrow Z$，则 $X \rightarrow YZ$ 为 F 所蕴含。 | 将具有相同左部的函数依赖的右部合并。 |
| **伪传递规则**
(Pseudo Transitivity Rule) | 若 $X \rightarrow Y$ 且 $WY \rightarrow Z$，则 $XW \rightarrow Z$ 为 F 所蕴含。 | 传递律的增强形式，允许在传递过程中增加条件。 |
| **分解规则**
(Decomposition Rule) | 若 $X \rightarrow Y$ 且 $Z \subseteq Y$，则 $X \rightarrow Z$ 为 F 所蕴含。 | 函数依赖的右部可以分解，是其逆过程。合并与分解规则共同表明 $X→Y$ 等价于 $X→Y$ 中Y的每一个属性。 |
**总结**：Armstrong公理系统为函数依赖的逻辑推导提供了严格的基础。其中，**A1（自反）、A2（增广）、A3（传递）** 是三条**基本公理**，而**合并、伪传递、分解**规则是由基本公理推导出的**有用定理**，它们简化了推导过程。
# 规范化理论 - 范式详解
规范化是数据库设计中的重要过程，旨在通过分解关系模式来消除数据冗余和操作异常。范式是衡量关系模式规范化程度的标准。
| 范式等级 | 核心定义与要求 | 关键条件与说明 |
| :--- | :--- | :--- |
| **第一范式 (1NF)** | 关系模式R的**每一个分量（属性）都是不可再分的数据项**。 | 这是最基本的要求，不满足1NF的关系不能称为关系。属于原子性约束。 |
| **第二范式 (2NF)** | 若关系模式 R ∈ 1NF，且**每一个非主属性都完全函数依赖于主键**，则R属于2NF。 | 消除了**非主属性对主键的部分函数依赖**。满足1NF是前提。 |
| **第三范式 (3NF)** | 若关系模式 R ∈ 2NF，且**消除了非主属性对候选码的传递函数依赖**，则R属于3NF。 | 消除了非主属性之间的间接依赖，进一步减少了冗余和更新异常。 |
| **BC范式 (BCNF)** | 关系模式R中，若F（依赖集）中**每一个函数依赖的决定因素都包含R的某个候选码**，则R属于BCNF。 | 比3NF更严格，消除了**主属性**对候选码的部分和传递依赖。可理解为：在BCNF中，每一个“因”都必须是候选码。 |
**范式间的递进关系**：
`1NF ⊂ 2NF ⊂ 3NF ⊂ BCNF`
高级别的范式自动满足低级别范式的要求。规范化过程就是通过模式分解，从低级别范式向高级别范式转化的过程。
**核心概念**：
- **完全函数依赖**：非主属性不能仅依赖于主键的一部分属性。
- **传递函数依赖**：存在非主属性A依赖于非主属性B，而B又依赖于候选码的情况。
- **决定因素**：函数依赖 `X → Y` 中，`X` 称为决定因素。
# 事务管理 - 事务的ACID属性
## 1. 事务的定义
数据库系统运行的基本工作单位是**事务**。事务是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。事务相当于操作系统中的进程。
## 2. ACID属性详解
为了保证数据的正确性与一致性，数据库事务必须满足以下四个核心属性（ACID）：
| 属性 | 英文 | 核心要求与解释 |
| :--- | :--- | :--- |
| **原子性**
(Atomicity) | **A**tomicity | 事务中包含的所有操作被视为一个**不可分割的整体**。这些操作**要么全部成功执行**，**要么全部不执行**（回滚到事务开始前的状态）。 |
| **一致性**
(Consistency) | **C**onsistency | 事务的执行必须使数据库从一个**一致性状态**转变到另一个**一致性状态**。即事务的执行结果必须保证数据库中的数据满足所有的完整性约束。 |
| **隔离性**
(Isolation) | **I**solation | 一个事务的**执行过程不能被其他并发事务干扰**。多个并发事务的执行应当相互隔离，使得每个事务都感觉不到有其他事务在同时执行。 |
| **持久性**
(Durability) | **D**urability | 也称为**永久性**。一旦一个事务**成功提交**，它对数据库所做的任何**改变就是永久性的**，即使后续系统发生故障，这些改变也不会丢失。 |
**核心总结**：ACID属性共同构成了数据库事务处理的可靠性与正确性的基石。其中：
- **原子性** 是基础，由**恢复管理子系统**保证。
- **一致性** 是最终目标，由应用程序和数据库的完整性约束共同保证。
- **隔离性** 是并发控制的核心，由**并发控制子系统**保证。
- **持久性** 是结果的保证，由**恢复管理子系统**保证。
# 事务管理 - 封锁技术
## 1. 概述
在多用户并发访问数据库的环境下，为了保证事务的**隔离性**（ACID特性之一）和数据的一致性，数据库系统采用**封锁**作为实现并发控制的主要技术。
## 2. 封锁类型详解
主要有两种基本的封锁类型，其核心区别在于允许的“读/写”权限不同。
| 封锁类型 | 简称 | 核心定义与规则 | 允许的操作 | 核心特性与目的 |
| :--- | :--- | :--- | :--- | :--- |
| **排他型封锁**
(Exclusive Lock) | **X封锁** | 如果事务T对数据A实现了X封锁，那么**只允许事务T读取和修改数据A**。 | T: 可读、可写
其他事务: 不可读、不可写 | **排他性、独占性**。在T释放X锁之前，其他任何事务**不能**对A加任何类型的锁。用于**修改数据**的场景，保证数据在修改期间不被其他事务干扰。 |
| **共享型封锁**
(Shared Lock) | **S封锁** | 如果事务T对数据A实现了S封锁，那么**允许事务T读取数据A，但不能修改数据A**。 | T: 可读、不可写
其他事务: 可加S锁读、不可加X锁写 | **共享性**。允许多个事务并发读取同一数据。但在**所有S封锁解除之前**，绝不允许任何事务对数据A实现X封锁。用于**只读查询**，提高并发度。 |
**封锁对象 (数据A)**：可以是一个数据项、一条记录、一个数据集，乃至整个数据库。
## 3. 核心总结
- **X锁 (写锁)**：用于**写操作**。是**独占锁**，一个数据对象在任一时刻最多只能被一个事务持有X锁。
- **S锁 (读锁)**：用于**读操作**。是**共享锁**，一个数据对象可以被多个事务同时持有S锁。
- **相容性规则**：
- X锁与X锁**互斥**。
- X锁与S锁**互斥**。
- S锁与S锁**相容**。
> **目的**：通过这两种锁及其相容性控制，封锁技术能够有效协调并发事务的交叉执行，防止**丢失修改、读“脏”数据、不可重复读**等问题，从而保障事务的隔离性与数据一致性。
# 事务管理 - 封锁协议详解
锁的使用规则称为**封锁协议**。不同级别的协议规定了何时申请锁、何时释放锁，以及持有锁的时长，这直接决定了事务的隔离级别和数据一致性保障程度。下表详细对比了三个级别的封锁协议。
| 封锁协议级别 | 核心内容 (加锁规则) | 优点 (解决的问题) | 缺点 (仍存在的问题) |
| :--- | :--- | :--- | :--- |
| **一级封锁协议** | 事务在**修改数据之前**，必须对该数据加**X锁**，直到事务结束才释放。
对**只读数据可以不加锁**。 | 防止 **“丢失修改”** (Lost Update) | 对不加锁的只读事务，可能 **“读脏数据”** (Dirty Read) 或 **“不可重复读”** (Non-repeatable Read)。 |
| **二级封锁协议** | 在一级协议基础上，增加：
事务在**读取数据之前**，必须对该数据加**S锁**，**读完后即可释放S锁**。
（X锁仍需保持到事务结束） | 防止 **“丢失修改”**
防止 **“读脏数据”** | 对加了S锁的事务，由于S锁提前释放，在其事务周期内仍可能 **“不可重复读”**。 |
| **三级封锁协议** | 在一级协议基础上，增加：
事务在**读取数据之前**，必须对该数据加**S锁**，并且**直到事务结束时才释放S锁**。
（X锁与S锁均保持到事务结束） | 防止 **“丢失修改”**
防止 **“读脏数据”**
防止 **“不可重复读”** | 并发度最低，对系统性能影响最大。 |
**各级协议核心与演进总结**：
- **一级协议**：只对**写操作**进行约束（加X锁），解决了最基础的写冲突。
- **二级协议**：在**一级基础上**增加对**读操作**的临时约束（加S锁，读完就放），解决了脏读问题。
- **三级协议**：在**一级基础上**增加对**读操作**的最严格约束（加S锁，事务结束放），解决了不可重复读问题，实现了完全的隔离。
> **关键理解**：封锁协议的级别越高，规则越严格，能防止的并发问题越多，但事务的**并发度也越低**，系统开销越大。这是一个在**数据一致性和系统性能**之间进行权衡的过程。
# 分布式数据库
## 1. 模式结构
分布式数据库系统通过增加**分布透明性**，在传统集中式数据库的三级模式（外模式、模式、内模式）基础上进行了扩展，形成了典型的**六层模式结构**。
| 模式层级 | 描述 | 说明 |
| :--- | :--- | :--- |
| **1. 全局外模式** | 全局应用的用户视图，是**全局概念模式的子集**。 | 代表终端用户看到的逻辑数据结构。 |
| **2. 全局概念模式** | 定义了分布式数据库中**所有数据的整体逻辑结构**，如同一个集中式数据库的概念模式。 | 描述了数据本身，不涉及数据的分布细节。 |
| **3. 分片模式** | 描述了**全局数据如何被划分和逻辑分段**（分片）的过程。每个全局关系可以被划分为若干互不重叠的部分（分片）。 | **分片原则**：完备性、可重构、不相交。 |
| **4. 分布模式** | 描述了**逻辑片段在物理上被分配到各个场地（站点）** 的映像关系。一个片段在物理上可以存放于一个或多个场地。 | 定义了分片的物理存储位置。 |
| **5. 局部概念模式** | 定义在**每个场地**上的局部数据的逻辑结构，是其局部数据库的概念模式。 | 是全局概念模式被分段和分配在该场地的结果映射。 |
| **6. 局部内模式** | 描述**每个场地**上局部数据的物理存储结构。 | 与传统数据库的内模式定义相同。 |
**结构关系**：`全局外模式 → 全局概念模式 → 分片模式 → 分布模式 → 局部概念模式 → 局部内模式`
## 2. 数据分片
数据分片是将全局数据进行逻辑划分。分片时必须遵循三个基本原则：
- **完备性**：所有全局数据必须映射到某个片段中，不允许有数据不属于任何片段。
- **可重构**：所有片段必须能够通过某种操作（如并操作）重建出完整的全局数据。
- **不相交**：不同片段之间不应包含重复的数据（主键数据除外，为垂直分片所需）。
## 3. 数据分配策略
数据分配是指将分片后得到的**逻辑片段**具体分配到网络中各场地的过程。主要有四种策略：
| 分配策略 | 核心描述 | 特点 |
| :--- | :--- | :--- |
| **集中式** | 所有的数据片段都安排在**同一个场地**上。 | 本质上非分布式，无冗余，可靠性低，依赖中心节点。 |
| **分割式** | 所有数据只有一份，被分割成若干逻辑片段，**每个片段被指派到一个特定的、互不重复的场地**。 | 无冗余，易实现，但存在数据访问的局部性。 |
| **全复制式** | 数据在每个场地**重复存储**，每个场地都拥有一个完整的数据副本。 | 冗余度最高，可靠性高，但同步更新开销大。 |
| **混合式** | 介于分割式和全复制式之间，数据被分片后，**各片段按需被复制并分配到多个场地**。 | 兼顾了可靠性与存储开销，是实际中最常用的策略。 |
**总结**：分布式数据库通过**六级模式**实现了从全局逻辑到局部物理的映射与透明性，并通过**分片**与**分配**策略，在数据管理的集中统一性与物理存储的分布局部性之间取得平衡。
# 基于架构的软件开发方法
## 1. 概述
- **全称**：基于体系结构的软件设计 (Architecture-Based Software Design, **ABSD**) 方法。
- **核心驱动**：是**体系结构驱动**的，即由构成体系结构的**商业、质量和功能需求**的组合共同驱动。
## 2. 核心描述与特点
- **描述方法**：
- 采用**视角与视图**来描述软件架构。
- 采用**用例 (Use Case)** 来描述功能需求。
- 采用**质量场景 (Quality Scenario)** 来描述质量需求。
- **开发过程特点**：是一个**自顶向下、递归细化**的方法。软件系统的体系结构通过该方法被逐步细化，直至能够推导出具体的软件构件和类。
## 3. ABSD方法的三个基础
ABSD方法建立在以下三个基础之上：
| 基础 | 核心内容与说明 |
| :--- | :--- |
| **1. 功能的分解** | 在功能分解中，ABSD方法使用已有的、基于模块的**内聚和耦合**技术。 |
| **2. 选择体系结构风格** | 通过**选择特定的体系结构风格**来实现既定的**质量属性**和**商业需求**。 |
| **3. 软件模板的使用** | 利用一些软件系统固有的、可复用的**结构模式（软件模板）** 来指导和加速设计。 |
## 4. 六个核心子过程
| 序号 | 子过程 | 核心任务与产出 |
| :--- | :--- | :--- |
| 1 | **体系结构需求** | 明确并定义驱动体系结构设计的商业、质量与功能需求。 |
| 2 | **体系结构设计**
**（图中标红）** | 基于需求，选择体系结构风格，定义系统的高层结构、组件及其交互关系。 |
| 3 | **体系结构文档化**
**（图中标红）** | 将设计决策、体系结构视图和组件规格等正式记录下来，形成可供沟通和评估的文档。 |
| 4 | **体系结构复审**
**（图中标红）** | 评估体系结构设计方案是否满足需求，特别是质量属性（如性能、安全性），并识别潜在风险。 |
| 5 | **体系结构实现**
**（图中标红）** | 依据已确定的体系结构，进行具体设计与编程，将体系结构转化为具体的**软件构件和类**。 |
| 6 | **体系结构演化**
**（图中标红）** | 在系统运行和维护阶段，对体系结构进行调整和优化，以适应新的需求或环境变化。 |
**总结**：ABSD是一种以软件体系结构为核心、受多类需求驱动、并遵循自顶向下递归细化过程的系统化设计方法。其三大基础确保了从需求到设计的可追踪性和设计决策的有效性。
# 基于架构的软件开发方法 (ABSDM) - 完整流程详解
## 1. 概述
- **全称**：基于体系结构的软件设计方法 (Architecture-Based Software Design Method, **ABSDM**)。
- **核心驱动**：是**体系结构驱动**的，由**商业、质量和功能需求**的组合共同驱动。
- **过程特点**：是一个**自顶向下、递归细化**的迭代过程，将高层需求逐步转化为具体的软件构件和类。
## 2. 六个核心子过程详解
ABSDM模型将开发过程清晰地划分为六个子过程，它们顺序执行但也允许迭代。
### 2.1 体系结构需求
- **目标**：明确并定义驱动体系结构设计的商业、质量与功能需求。
- **过程特点**：需求受**技术环境**和**体系结构设计师的经验**影响。
- **关键活动**：
1. **获取用户需求**。
2. **标识系统中要用到的构件**。
- **效率技巧**：若存在类似系统的需求，可以从**需求库**中取出、修改和复用，以节省时间、减少重复劳动、提高开发效率。
### 2.2 体系结构设计
- **目标**：基于需求，选择体系结构风格，定义系统的高层结构、组件及其交互关系。
- **具体步骤**：
1. **提出架构模型**。
2. **映射构件**（将需求映射到具体的构件）。
3. **分析构件相互作用**。
4. **产生架构**（输出具体的架构设计方案）。
5. **设计评审**。
### 2.3 体系结构文档化
- **目标**：将设计决策、体系结构视图和组件规格等正式记录下来，形成可供沟通和评估的文档。
- **主要产出文档**：
1. **体系结构规格说明**。
2. **测试体系结构需求的质量设计说明书**。
- **文档的重要性**：文档是所有人员通信的手段，**关系开发的成败**。
- **文档注意事项**：
1. **必须从使用者的角度编写**。
2. **必须分发给所有与系统有关的开发人员**。
3. **必须保持开发者手上的文档是最新的**。
### 2.4 体系结构复审
- **目的**：
- 标识潜在的风险。
- 发现架构中的缺陷和错误。
- **参与人员**：由**外部人员**（独立于开发组织之外，如用户代表和领域专家）参加。
- **复审内容**：架构是否满足需求、质量属性、构件划分的合理性等。
- **复审结果处理**：若**复审不通过**，则返回 **“体系结构设计”** 阶段进行**重新设计、文档化，再复审**。
### 2.5 体系结构实现
- **目标**：依据已确定的体系结构，进行具体设计与编程，将体系结构转化为具体的**软件构件和类**。
- **实现步骤**：
1. **分析与设计**：用实体来显示出架构。
2. **构件实现**：实现具体的构件。
3. **构件组装**：将构件组装成系统。
4. **系统测试**。
- **支持条件**：此过程**需要构件库的支持**。
### 2.6 体系结构演化
- **目标**：在系统运行和维护阶段，对体系结构进行调整和优化，以适应新的需求或环境变化。核心是**对架构进行改变，按需求增删构件，使架构可复用**。
- **演化操作步骤**：
1. **需求变化分类**。
2. **制定架构演化计划**。
3. **构件变动**（修改、增加或删除）。
4. **更新构件的相互作用**。
5. **构件组装与测试**。
6. **技术评审**。
7. **产生演化后的架构**。
## 3. 总结
ABSDM是一个严谨的、以架构为中心的开发框架。它通过 **“需求→设计→文档化→复审→实现→演化”** 的闭环流程，确保了软件系统从概念到实现再到维护的整个生命周期都处于受控状态，并能灵活应对变化，最终目标是构建出高质量、可维护、可演化的软件系统。
# 软件架构风格
## 软件架构风格概述
**软件架构风格**是描述某一特定应用领域中**系统组织方式的惯用模式**。
### 核心定义
- 一种架构风格定义了一个**系统家族**，即：
- 一个**词汇表**：包含一些**构件**和**连接件**类型。
- 一组**约束**：规定系统应如何将这些构件和连接件**组合**起来。
### 价值与作用
- 反映了特定领域中众多系统所共有的**结构和语义特性**。
- 指导如何将各个**模块和子系统**有效地组织成一个完整的系统。
- 对架构风格的研究和实践能**促进对设计的重用**，使一些经过实践验证的解决方案可以可靠地用于解决新的问题。
### 核心构成
- 架构风格为系统描述提供了**术语表**。
- 为系统构建提供了一组**指导规则**。
### 核心目标
- 软件架构设计的核心目标之一是实现**架构级的软件复用**。
## 2. 通用架构风格的分类
以下是五种主要的通用软件架构风格及其典型实例：
| 风格类别 | 核心思想 | 典型实例 |
| :--- | :--- | :--- |
| **数据流风格** | 以**数据流动**为主要驱动力，构件是过滤器，连接件是管道。 | 批处理序列、管道/过滤器 |
| **调用/返回风格** | 通过明确的**调用机制**来控制系统逻辑流。 | 主程序/子程序、面向对象风格、层次结构、客户端/服务器 |
| **独立构件风格** | 构件是独立的进程或对象，通过**消息传递**或**事件**进行通信。 | 进程通信、事件系统 |
| **虚拟机风格** | 通过一个“虚拟机”或解释器来**执行自定义的指令或规则**。 | 解释器、基于规则的系统 |
| **仓库风格** | 围绕一个**中心数据仓库**（如数据库、黑板）来组织构件，构件通过该仓库进行交互。 | 数据库系统、超文本系统、黑板系统 |
**总结**：不同的架构风格为软件系统提供了不同的高层组织模式、交互范式和约束规则，是架构师在设计系统时进行选择和决策的重要基础。
# 软件架构风格详解
## 1. 概述
- **定义**：软件体系结构（架构）风格是描述某一特定应用领域中**系统组织方式的惯用模式**。
- **核心要素**：
- **词汇表**：包含一些**构件**和**连接件**类型。
- **约束**：规定系统应如何将这些构件和连接件**组合**起来。
- **核心价值**：反映了领域中众多系统共有的**结构和语义特性**，指导如何将模块和子系统组织成完整的系统。
## 2. 数据流风格
以**数据流动**为主要驱动力，构件是过滤器，连接件是管道。
### 2.1 批处理体系结构风格
- **核心思想**：每个处理步骤是一个**单独的程序**，每一步必须在前一步结束后才能开始，数据以**整体方式**传递。
- **基本构件**：独立的应用程序。
- **连接件**：定义数据流图的某种媒介。
### 2.2 管道-过滤器体系结构风格
- **核心思想**：将系统分解为几个**序贯的处理步骤**，步骤间通过数据流连接。一个步骤的输出是另一个步骤的输入。
- **基本构件**：**过滤器 (Filter)**，负责数据处理。
- **连接件**：**管道 (Pipe)**，负责在过滤器间传输数据流。
- **典型实例**：UNIX Shell程序、传统编译器、网络报文处理。
### 2.3 数据流风格的优缺点
| 优点 | 缺点 |
| :--- | :--- |
| 1. 高内聚、低耦合 | 1. 交互性差 |
| 2. 良好的重用性/可维护性 | 2. 复杂性较高 |
| 3. 可扩展性（标准接口适配） | 3. 性能差（每个过滤器都需解析与合成数据） |
| 4. 良好的隐蔽性 | |
| 5. 支持并行处理 | |
## 3. 调用/返回风格
通过明确的**调用机制**来控制系统逻辑流，是一种“分而治之”的策略。
### 3.1 主程序/子程序风格
- **核心思想**：单线程控制，采用**过程调用**作为交互机制（连接件）。
- **构件**：主程序和子程序（可合成为模块）。
- **特点**：调用关系具有层次性，主程序的正确性依赖于子程序的正确性。
### 3.2 面向对象风格
- **核心思想**：建立在**数据抽象和面向对象**基础上，将数据及其操作封装在**对象**或抽象数据类型中。
- **构件**：对象（抽象数据类型的实例）。
- **连接件**：对象间的**函数/方法调用**。
### 3.3 层次型体系结构风格
- **核心思想**：系统组成一个层次结构，每一层为上层**服务**，并作为下层的**客户**。内部层接口通常只对相邻层可见。
- **构件**：实现特定功能的层（可看作虚拟机）。
- **连接件**：定义层间如何交互的**协议**。
- **优点**：良好的重用性、可维护性、可扩展性，支持递增设计。
- **缺点**：并非所有系统都方便分层；难找合适的抽象层次；耦合度高时难以实现。
### 3.4 客户端/服务器风格 (C/S)
- **核心思想**：基于资源不对等，为实现共享而提出。
- **两层C/S结构**：
- **构件**：数据库服务器、客户应用程序、网络。
- **特点**：“胖客户机，瘦服务器”。服务器管数据，客户机负责交互。
- **三层C/S结构**：
- **构件**：增加**应用服务器**。
- **特点**：“瘦客户机”。应用逻辑驻留在应用服务器，客户机仅保留表示层。
## 4. 仓库风格 (以数据为中心)
围绕一个**中心数据仓库**来组织构件，构件通过该仓库进行交互。
### 4.1 仓库体系结构风格
- **核心构件**：
1. **中央数据结构（仓库）**：存储和维护数据的中心场所，保存系统当前状态。
2. **独立构件**：对中央数据进行操作。
- **典型实例**：数据库系统（如Oracle）。
### 4.2 黑板体系结构风格
- **适用场景**：解决复杂的**非结构化问题**，需综合多种知识源（如信号处理、专家系统）。
- **系统组成**：
1. **知识源**：独立的、与应用相关的知识模块，彼此不直接通信。
2. **黑板数据结构**：按层次组织的、共享的问题求解数据。
3. **控制机制**：由黑板状态驱动，决定使用哪个知识源。
### 4.3 超文本系统
- **核心思想**：以非线性的网状结构组织信息，通过链接关联相关内容。
## 5. 虚拟机风格
通过一个“虚拟机”或解释器来**执行自定义的指令或规则**。
### 5.1 解释器体系结构风格
- **核心思想**：构建一个运行环境（虚拟机），以弥合程序语义与硬件语义的差异。
- **基本构件**：
- 解释引擎
- 存储被解释代码的区域
- 记录引擎状态的数据结构
- 记录执行进度的数据结构
- **缺点**：执行效率较低。
- **典型实例**：专家系统、需要“自定义规则”的场合。
### 5.2 规则系统体系结构风格
- **核心思想**：在解释器基础上，引入基于经验规则的问题求解机制。
- **基本构件**：规则集、规则解释器、规则/数据选择器、工作内存。
- **适用场景**：专家系统。
### 5.3 虚拟机风格的优缺点
| 优点 | 缺点 | 要点 |
| :--- | :--- | :--- |
| 可以灵活应对自定义场景 | 复杂度较高 | 1. **解释器**：适用于需要“自定义规则”的场合。
2. **规则为中心**：在解释器基础上增加经验规则，适合于专家系统。 |
## 6. 独立构件风格
### 6.1 概述
该风格主要强调系统中的每个构件都是相对独立的个体，它们之间不直接通信，以降低耦合度，提升灵活性。
### 6.2 主要类别
| 类别 | 核心描述 | 连接件 | 特点 |
| :--- | :--- | :--- | :--- |
| **进程通信风格** | 构件是独立的过程。 | 消息传递 | 构件是命名过程，消息传递方式多样（点到点、异步/同步、远程过程调用）。 |
| **事件系统风格**
(隐式调用) | 构件不直接调用过程，而是**触发或广播一个或多个事件**。系统自动调用在该事件中注册的所有过程。 | 事件触发与响应 | 触发者不知哪些构件会受影响，不能假定处理顺序。常包含**显式调用**作为补充。涉及事件源、事件、事件管理器、事件处理器等角色。 |
### 6.3 优缺点总结
| 优点 | 缺点 |
| :--- | :--- |
| 1. **松耦合**。 | 1. 构件**放弃了对系统计算的控制**。 |
| 2. 良好的**复用性/可修改性/可扩展性**。 | 2. **数据交换问题**。 |
| | 3. 过程语义依赖于被触发事件的**上下文约束**，**正确性推理困难**。 |
## 7. 闭环风格 (控制环风格)
### 7.1 概述
- **核心思想**：当软件用于操作物理系统时，软件与硬件之间构成一个**反馈循环**。它接收输入，确定输出，最终使环境达到新状态。
- **适用场景**：适合于**嵌入式系统**，涉及连续的动作与状态控制。
- **典型实例**：空调的恒温控制机制。
### 7.2 控制系统对比
- **开环控制系统**：`给定值 → 控制器 → 执行器 → 被控对象`
- **闭环控制系统**：在开环基础上增加**反馈环节**，形成闭环：`给定值 → 比较器 → 控制器 → 执行器 → 被控对象 → (反馈量) → 比较器`
## 8. C2风格
### 8.1 概述
C2风格可以概括为：**通过连接件绑定在一起的、按照一组规则运作的并行构件网络**。
### 8.2 系统组织规则
1. 系统中的**构件**和**连接件**都有一个**顶部**和一个**底部**。
2. 构件的**顶部**应连接到某连接件的**底部**，构件的**底部**则应连接到某连接件的**顶部**。**构件与构件之间禁止直接连接**。
3. 一个连接件可以和任意数目的其它构件和连接件连接。
4. 当两个连接件进行直接连接时，必须由其中一个的**底部**连接到另一个的**顶部**。
## 9. MDA风格 (模型驱动架构)
### 9.1 概述
MDA (Model-Driven Architecture) 是OMG提出的一种基于模型的软件开发框架，其核心是通过不同抽象级别的模型来驱动开发。
### 9.2 三层核心模型
| 模型层级 | 全称 | 描述 |
| :--- | :--- | :--- |
| **PIM** | 平台独立模型
(Platform Independent Model) | 具有**较高抽象层次**，**独立于任何具体实现技术**的模型。 |
| **PSM** | 平台相关模型
(Platform Specific Model) | 为**某种特定实现技术**量身定做的模型，用该技术的可用构造来描述系统。**PIM会被变换成一个或多个PSM**。 |
| **Code** | 代码 | 用**源代码**对系统进行的具体描述。**每个PSM都会被变换成代码**。 |
**核心转换关系**：`PIM → (通过映射Mappings) → PSM → Code`
# 软件架构风格总结 (备考与实例速查)
该表格对常见软件架构风格进行了归纳总结，特别突出了常考的关键字、典型实例及其核心思想，便于快速回顾与区分。
| 架构风格类别与名称 | 常考关键字与典型实例 | 核心简介 |
| :--- | :--- | :--- |
| **数据流风格** | | 以**数据流动**为主要驱动力。 |
| 数据流 - 批处理 | 传统编译器；每个阶段的结果作为下一阶段的输入；**区别在于数据以整体为单位**处理。 | 处理步骤**一个接一个**顺序执行，数据是**一批一批**地传递。 |
| **调用/返回风格** | | 通过明确的**调用机制**来控制系统逻辑流。 |
| 调用/返回 - 主程序/子程序 | | **显式调用**，主程序直接调用子程序。 |
| 调用/返回 - 面向对象 | | 对象是构件，通过对象调用其封装的**方法和属性**。 |
| 调用/返回 - 层次结构 | 分层，每层最多影响其上下两层，有调用关系。 | 系统组织成层次结构，上层使用下层的服务。 |
| **独立构件风格** | | 构件相对独立，通过间接机制通信。 |
| 独立构件 - 进程通信 | 进程间独立的消息传递，可以是同步或异步的。 | 构件是独立的进程，通过**消息传递**进行通信。 |
| 独立构件 - 事件系统
(事件驱动/隐式调用) | 事件触发推动动作；实例：程序语言的**语法高亮、语法错误提示**。 | 构件不直接调用，而是**发布或订阅事件**，由事件驱动后续动作。 |
| **虚拟机风格** | | 通过一个“解释器”或“引擎”来执行自定义的指令或规则。 |
| 虚拟机 - 解释器 | 自定义流程，按流程执行；规则可随时改变，灵活定义，业务灵活组合。 | 包含**解释引擎、存储区、数据结构**，用于解释执行自定义的规则或语言。 |
| 虚拟机 - 规则系统 | 用于**决策支持系统(DSS)、人工智能和专家系统**。 | 包含**规则集、规则解释器、选择器和工作内存**，基于规则进行推理。 |
| **仓库风格**
(以数据为中心) | | 围绕一个**中心数据仓库**来组织构件。 |
| 仓库 - 数据库 | 现代编译器的集成开发环境(IDE)。 | **中央共享数据源**（数据库），配合多个独立的处理单元。 |
| 仓库 - 超文本 | IDE，以数据为中心。 | 通过**网状链接**组织信息，多用于互联网。 |
| 仓库 - 黑板 | 又称**数据共享风格**；用于语音识别、知识推理等**问题复杂、解空间很大、求解过程不确定**的软件系统。 | 包含三个核心部分：**黑板**（共享数据）、**知识源**（独立求解模块）、**控制**（协调机制）。 |
| **闭环风格**
(控制环风格) | | 适用于需要根据反馈进行自动调节的系统。 |
| 闭环 - 过程控制 | 实例：**汽车巡航定速、空调温度调节**；设定参数，并不断调整。 | 系统**发出控制命令并接受反馈**，循环往复以达到并维持设定的状态（平衡）。 |
| **C2风格** | 构件和连接件、顶部和底部。 | 通过连接件绑定在一起的、按照一组规则运作的**并行构件网络**。构件间通过连接件的顶部和底部规则连接。 |
---
**总结归类**：
- **关注数据流动**：数据流风格（批处理、管道-过滤器）。
- **关注调用控制**：调用/返回风格（主程序/子程序、OO、层次、C/S）。
- **关注间接通信**：独立构件风格（进程通信、事件驱动）。
- **围绕数据中心**：仓库风格（数据库、超文本、黑板）。
- **关注灵活执行**：虚拟机风格（解释器、规则系统）。
- **关注自动调节**：闭环风格（过程控制）。
- **关注特定规则**：C2风格。
# 软件架构复用
## 1. 定义与分类
### 1.1 定义
软件复用是一种**系统化**的软件开发过程，其核心在于：
- **活动**：识别、开发、分类、获取和修改软件实体。
- **目的**：在不同的软件开发过程中**重复使用**这些实体。
### 1.2 复用范围的演变
- **早期**：主要是**代码级复用**，被复用的实体专指程序。
- **现今**：范围已扩大到包括**领域知识、开发经验、体系结构、需求、设计、测试、代码和文档、过程方法和工具**等一切有关方面。
### 1.3 复用类型
| 类型 | 核心描述 | 特点 |
| :--- | :--- | :--- |
| **机会复用**
(或称**偶然复用**) | 在开发过程中，**只要发现有可复用的资产，就对其进行复用**。 | 自发的、非计划性的复用。 |
| **系统复用**
(或称**有规划复用**) | 在开发之前，**就要进行规划**，以决定哪些部分需要复用、如何复用。 | 有计划的、系统性的复用，是更高级的形态。 |
## 2. 软件架构复用的原因（价值与优势）
1. **提高效率与生产力**：减少开发工作量、缩短开发时间、降低开发成本。
2. **提升质量**：提高软件产品的质量，并使其具备更好的互操作性。
3. **简化维护**：使产品的后续维护变得更加简单。
## 3. 软件架构复用的基本过程
复用的实施是一个持续循环的过程，主要包含以下三个阶段：
[阶段1：构造/获取可复用资产]
↓ (入库)
[阶段2：管理可复用资产] → (形成) → [可复用资产库]
↓ (选择/定制/组装)
[阶段3：使用可复用的资产]
**流程详解**：
1. **构造/获取可复用资产**：通过开发新资产或获取（购买、开源）现有资产来积累可复用资源。
2. **管理可复用资产**：对资产进行**分类、描述、存储和维护**，形成组织级的**可复用资产库**，这是实现高效复用的基础。
3. **使用可复用的资产**：在新项目开发中，从资产库中**选择**合适的资产，并可能对其进行**定制**和**组装**，以构建新系统。
**核心思想**：软件架构复用不仅是一种技术，更是一种需要系统化管理和持续积累的工程实践。
# 特定领域软件架构 (DSSA)
## 1. 核心定义
- **全称**：特定领域软件架构 (Domain-Specific Software Architecture, DSSA)
- **定位**：在一个特定领域中，为一组应用提供组织结构参考的**标准软件框架**。
- **核心目标**：支持在**一个特定领域**中，**多个应用的生成**。
## 2. DSSA中“领域”的含义
在DSSA上下文中，“领域”有垂直和水平两种含义，代表了复用的不同方向与层次。
| 领域类型 | 核心描述 | 特点与区别 |
| :--- | :--- | :--- |
| **垂直域** | 定义一个**特定的系统族**，包含整个系统族内的多个系统。其结果是可在该领域中作为系统可行解决方案的**一个通用软件架构**。 | **相同领域，深入**
针对同一个业务领域内部，提供完整的、通用的解决方案框架。 |
| **水平域** | 定义在**多个系统**和**多个系统族**中，功能区域的**共有部分**。它在子系统级上涵盖多个系统族的特定功能，**无法为整个系统提供完整的通用架构**。 | **不同领域，平移**
关注跨不同业务领域的、可共享的通用子功能或模块。 |
## 3. DSSA的三个基本活动
DSSA的建设与应用主要包含以下三个顺序且迭代的基本活动：
| 活动 | 主要目标 | 核心产出与描述 |
| :--- | :--- | :--- |
| **领域分析** | 获得**领域模型** | 描述**领域中系统之间的共同需求**（领域需求）。 |
| **领域设计** | 获得**DSSA**本身 | 描述针对领域模型所表达需求的**解决方案**。它不是单个系统的设计，而是能够适应领域中**多个系统需求的一个高层次设计**。 |
| **领域实现** | 开发和组织**可重用信息** | 依据领域模型及DSSA，进行具体的开发，并构建和组织可复用的资产（如构件、代码、文档等）。 |
---
**总结**：DSSA是一种针对特定问题域（如金融、电信、医疗）的系统化复用方法。它通过**垂直/水平**两种方式界定复用范围，并通过**分析→设计→实现**的活动循环，构建可支持该领域内多个应用快速开发的高层通用架构（DSSA）及可复用资产库。
# 特定领域软件架构 (DSSA) - 角色与过程
## 1. 核心定义
- **全称**：特定领域软件架构 (Domain-Specific Software Architecture, DSSA)
- **定位**：在一个特定领域中，为一组应用提供组织结构参考的**标准软件框架**。
- **核心目标**：支持在**一个特定领域**中，**多个应用的生成**。
## 2. 参与DSSA的人员与角色
DSSA的建立和应用需要不同专长的人员协同工作，各角色及其职责如下：
| 角色 | 人员背景/要求 | 主要职责 |
| :--- | :--- | :--- |
| **领域专家** | 有经验的用户，或从事该领域中系统的需求、设计、实现及项目管理的**有经验的软件工程师**。 | 提供深入的领域知识，确保DSSA符合真实的业务需求与约束。 |
| **领域分析师** | 由具有**知识工程背景**的有经验的系统分析员担任。 | 负责领域分析，识别和定义领域内的共同需求和概念，建立领域模型。 |
| **领域设计人员** | 由有经验的**软件设计人员**担任。 | 负责领域设计，基于领域模型创建或精化DSSA（即领域通用的高层次设计）。 |
| **领域实现人员** | 由有经验的**程序设计人员**担任。 | 负责领域实现，根据DSSA开发、获取和组织可复用的产品单元（如构件、代码、工具）。 |
## 3. DSSA的建立过程
DSSA的建立是一个**并发的、递归的、反复的螺旋式**过程，通常包含以下5个阶段：
| 阶段 | 核心任务与输出 |
| :--- | :--- |
| **阶段1：定义领域范围** | 明确DSSA所覆盖的领域边界。**主要输出**是领域内应用需要满足的一系列用户需求。 |
| **阶段2：定义领域特定的元素** | 识别和标准化领域内的核心概念与术语。**主要活动**是编撰**领域字典**和**领域术语的同义词词典**。 |
| **阶段3：定义领域特定的设计和实现需求约束** | 明确在该领域内进行系统设计和实现时必须遵循的**特定约束与规则**。 |
| **阶段4：定义领域模型和架构** | 创建**领域模型**（描述领域概念与关系）和**DSSA**本身（描述通用的解决方案架构）。这是将需求转化为设计的关键阶段。 |
| **阶段5：产生、搜集可重用的产品单元** | 基于已定义的DSSA，实际开发、获取或搜集具体的可复用资产，如构件库、代码框架、生成工具等。 |
**过程特点**：这五个阶段并非严格线性，而是**并发、递归和反复**的。在实践中，团队可能需要根据后续阶段的发现，回溯并调整前一阶段的产出，形成一个不断迭代和深入的“螺旋”式演进过程。
---
**总结**：DSSA的成功依赖于**领域专家、分析师、设计人员和实现人员**的紧密协作，并通过一个**非线性的、五阶段的螺旋过程**，逐步明确范围、统一语言、定义约束、建立架构，并最终产出可复用的资产，从而系统化地支持特定领域内的高效开发。
# 特定领域软件架构 (DSSA) - 核心过程与角色分工
## 1. 核心定义
**特定领域软件架构 (DSSA)** 是一个针对特定问题领域的、标准化的软件框架，旨在支持该领域内一系列应用的快速开发。
## 2. 两个核心过程
DSSA的实施包含两个相辅相成的工程过程：
| 过程 | 核心目标 | 主要活动与产出 |
| :--- | :--- | :--- |
| **领域工程**
(Domain Engineering) | 为一组**相近或相似的应用**建立基本能力和必备基础。 | 覆盖**建立可重用软件元素的所有活动**，产出领域通用的资产（如架构、模型、构件、工具）。 |
| **应用工程**
(Application Engineering) | 通过重用领域工程产生的软件资源，开发出满足具体用户需求的应用软件。 | 以**领域通用体系结构为框架**，进行具体应用的开发、测试与部署。 |
**关系**：领域工程**生产**可复用资产，应用工程**消费**这些资产。两者共同构成DSSA的完整生命周期。
## 3. 参与角色与工作环境
示意图清晰地展示了DSSA中三类核心角色及其所处的环境与工作内容：
| 角色 | 工作环境 | 核心职责与工作内容 |
| :--- | :--- | :--- |
| **领域构架师**
(领域工程师) | **领域开发环境** | 负责领域工程。工作围绕**领域模型、参考需求、参考结构（构架）** 展开，并产出**开发工具**等可复用资产。 |
| **应用工程师** | **领域特定的应用开发环境** | 负责应用工程。在领域构架师提供的环境下，将领域通用体系结构**实例化**，开发出具体的应用。 |
| **操作员**
(最终用户) | **应用执行环境** | 使用应用工程师交付的、最终部署在运行环境中的具体应用系统。 |
---
**总结**：DSSA通过**领域工程**构建可复用的领域资产库和通用架构，再通过**应用工程**高效地复用这些资产生产具体应用。**领域构架师、应用工程师、操作员**在**开发、应用、运行**三个不同环境中各司其职，协同完成从领域知识到具体软件产品的转化。
# UML 事务 (Things)
UML 模型由**事务 (Things)**、**关系 (Relationships)** 和**图 (Diagrams)** 三大要素构成。其中，**事务**是UML模型中最基本的构成元素，代表了被抽象化的模型概念。UML 中共有4种基本的事务类型。
## 1. 结构事务 (Structural Things)
- **定义**：UML模型的**静态部分**，描述模型中的概念或物理元素。
- **主要分类**：
| 事务 | 描述 |
| :--- | :--- |
| **类 (Class)** | 描述具有相同属性、方法、关系和语义的一组对象。 |
| **接口 (Interface)** | 描述一个类或构件所提供服务的操作集合。 |
| **协作 (Collaboration)** | 定义一组角色及其交互，共同完成某个特定功能。 |
| **用例 (Use Case)** | 定义一组动作序列，描述系统与参与者交互所产生的、对参与者有价值的结果。 |
| **主动类 (Active Class)** | 其对象至少拥有一个进程或线程的类，能够发起控制活动。 |
| **构件 (Component)** | 系统中可替换的物理部分，实现一组接口。 |
| **制品 (Artifact)** | 软件开发过程中的物理实体（如源码文件、可执行文件、脚本等）。 |
| **结点 (Node)** | 运行时存在的物理计算资源（如服务器、硬件设备）。 |
## 2. 行为事务 (Behavioral Things)
- **定义**：UML模型的**动态部分**，描述跨越时间和空间的行为。
- **主要分类**：
- **交互 (Interaction)**：由一组对象在特定上下文中，为完成某个任务而进行的一系列消息交换。
- **状态机 (State Machine)**：描述一个对象在其生命周期中，响应事件所经历的状态序列及对这些事件的响应。
- **活动 (Activity)**：描述计算机过程或业务流程的步骤序列，强调步骤间的控制流和数据流。
## 3. 分组事务 (Grouping Things)
- **定义**：UML模型的**组织部分**，用于对模型元素进行分组管理。
- **主要事务**：
- **包 (Package)**：最主要的分类事务。是把**结构事务、行为事务甚至其他分组事务**组织成组的通用机制，类似于文件系统中的文件夹。
## 4. 注释事务 (Annotational Things)
- **定义**：UML模型的**解释部分**，用于对模型中的任何元素进行描述、说明或标注。
- **主要事务**：
- **注解 (Note)**：附加注释的图形符号，其中包含文字或图形解释。
---
**总结**：四种事务分别从**静态结构**、**动态行为**、**逻辑组织**和**辅助说明**四个维度，共同构成了描述软件系统所需的完整概念集合。
# UML 关系 (Relationships)
UML 模型由**事务 (Things)**、**关系 (Relationships)** 和**图 (Diagrams)** 三大要素构成。其中，**关系**是描述事务之间如何相互联系和协作的基本方式。UML 中定义了四种基本关系。
## 1. 四种基本关系概览
| 关系名称 | 核心解释 | 典型举例 | 图形表示 |
| :--- | :--- | :--- | :--- |
| **依赖**
(Dependency) | 一个事物（源）的语义变化依赖于另一个事物（目标）的语义。是**最弱**的一种关系。只要有使用关系就算依赖。 | 人 依赖 食物 | `-----→`
（虚线箭头） |
| **关联**
(Association) | 两个类之间存在某种语义上的联系。描述了对象之间的一组连接（链）。 | 人 和 公司 之间存在雇佣关联 | 实线（可带箭头、多重性） |
| **泛化**
(Generalization) | 一种特殊/一般关系，即**继承**关系。描述父类与子类之间的关系。 | 老师 是一种特殊的 人 | `─────▶`
（实线空心三角箭头） |
| **实现**
(Realization) | 规定**接口**和**实现该接口的类或组件**之间的关系。 | 类 实现 某个接口 | `-------`
（虚线空心三角箭头） |
## 2. 关联关系的子类型详解
关联关系（整体与部分的关系）根据**耦合强弱**，可进一步细分为三种：
| 关联子类型 | 核心解释 | 耦合强度 | 典型举例 | 图形表示 |
| :--- | :--- | :--- | :--- | :--- |
| **普通关联**
(Association) | 类之间的一种语义联系，描述了一组对象之间的连接。 | 一般 | 学生 选修 课程 | `──` 或 `─→` |
| **聚合**
(Aggregation) | **整体与部分**的关系，但**部分可以脱离整体而独立存在**。 | 较弱 | 狼 是 狼群 的一部分 | `──◇`
（实线空心菱形箭头） |
| **组合**
(Composition) | **整体与部分**的关系，且**部分不能脱离整体而独立存在**，生命周期一致。 | **最强** | 车轮 是 汽车 的一部分 | `──◆`
（实线实心菱形箭头） |
> **关键对比**：
> 1. **依赖 vs. 关联**：依赖是临时性的“使用”关系（如参数传递）；关联是结构性的“拥有”关系（如类的属性）。
> 2. **聚合 vs. 组合**：都是“has-a”关系。**聚合是松散的**（电脑和其外设），**组合是紧密的、共生的**（公司与部门）。**组合的耦合度比聚合更强**。
---
**总结**：理解这四种关系及其强弱（依赖<关联<聚合<组合<泛化/实现），是绘制准确UML图、进行面向对象设计的基础。其中，**泛化**是“is-a”关系，**聚合/组合**是“has-a”关系。
# UML 中的 5 种视图 (4+1 视图模型)
UML 采用“4+1”视图模型来描述一个系统的不同侧面。每种视图从特定角度关注系统，并使用不同的 UML 图进行建模。
| 视图 | 核心关注点 | 描述 | 包含的主要 UML 图 |
| :--- | :--- | :--- | :--- |
| **用例视图**
(Use Case View) | **功能需求** | 描述系统应该提供的功能，是从最终用户（外部参与者）角度看到的外部行为。是需求分析的起点和核心。 | 用例图 |
| **逻辑视图**
(Logical View) | **静态结构与动态行为** | 描述系统内部如何实现功能，聚焦于系统的逻辑组成、对象协作和状态变化。也称为设计视图。 | 类图、对象图、状态图、顺序图、通信图、活动图 |
| **进程视图**
(Process View) | **并发性、同步与通信** | 描述系统的并发性 aspects，如线程、进程及其之间的交互、同步和通信机制。关注运行时行为。 | 状态图、顺序图、通信图、活动图、构件图、部署图 |
| **实现视图**
(Implementation View) | **代码构件的组织** | 描述程序代码的物理组织结构，以及模块、库、构件之间的编译依赖关系。 | 构件图 |
| **部署视图**
(Deployment View) | **软硬件的物理架构** | 定义系统在运行时的物理拓扑结构，描述硬件节点、软件制品（如可执行文件）的部署位置及连接。 | 部署图 |
**核心思想**：这五种视图共同构成了对软件系统完整、多角度的描述。**用例视图**是驱动其他视图的“+1”视图，确保系统满足用户需求；其余四种视图（逻辑、进程、实现、部署）则分别从结构、并发、实现和物理层面详细阐述系统的构建与运行方式。
# 设计模式 - 要素与分类
## 1. 设计模式概述
- **模式定义**：模式是针对**特定问题**的解决方案。
- **设计模式核心**：提供了相关问题的解决方案，使人们可以更加简单方便地**复用成功的设计和体系结构**。
- **价值来源**：是前人通过开发经验对特定的代码进行设计、编写，总结出来的一套解决特定问题的方案。
- **核心目标**：提高代码的**可维护性、可重用性、可理解性、可靠性**等。
## 2. 设计模式的四个基本要素
一个完整的设计模式描述通常包含以下四个基本要素：
| 要素 | 描述 |
| :--- | :--- |
| **① 模式名称** | 一个助记名，用于描述设计模式、解决方案和效果。帮助思考、交流和记录设计。 |
| **② 问题** | 描述了模式的应用场景，即在何种情况下、面对何种设计问题时使用该模式。 |
| **③ 解决方案** | 描述了设计的组成部分、职责、协作关系。通常不针对具体情景，而是一个通用的、可复用的设计方案模板。 |
| **④ 效果** | 描述了应用该模式带来的结果、权衡（优缺点）及应考虑的约束。 |
## 3. 设计模式的分类
经典的GoF设计模式共有**23种**，可以从两个不同维度进行分类：
### 3.1 按目的划分（模式的作用）
根据模式的主要目的和应用场景，可分为三类：
| 类别 | 核心关注点 | 说明 |
| :--- | :--- | :--- |
| **创建型模式**
(Creational Patterns) | 与**对象的创建**有关。 | 将对象的创建与使用分离，使系统在对象创建时更加灵活、独立。 |
| **结构型模式**
(Structural Patterns) | 处理**类或对象的组合**。 | 描述如何将类或对象按某种布局组成更大的结构，以获得更灵活、高效的架构。 |
| **行为型模式**
(Behavioral Patterns) | 对**类或对象怎样交互和怎样分配职责**进行描述。 | 关注对象间的通信、职责委派，以及算法和控制的流程。 |
### 3.2 按范围划分（模式的主要应用对象）
根据模式是主要作用于类还是对象，可分为两类：
| 类别 | 核心应用对象 | 说明 |
| :--- | :--- | :--- |
| **类设计模式**
(Class Patterns) | 主要处理**类与子类**之间的关系。 | 这些关系通过**继承**建立，是静态的，在编译时便已确定。 |
| **对象设计模式**
(Object Patterns) | 主要处理**对象**之间的关系。 | 这些关系通过**组合或关联**实现，具有动态性，可以在运行时改变。 |
> **注意**：大部分设计模式属于**对象设计模式**。
# 创建型设计模式
创建型设计模式关注对象的创建机制，旨在将对象的创建与使用分离，使系统在对象构造时更加灵活和独立。以下是五种经典的创建型设计模式及其核心定义。
| 模式名称 | 核心定义 |
| :--- | :--- |
| **抽象工厂模式 (Abstract Factory)** | 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 |
| **生成器模式 (Builder)** | 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 |
| **工厂方法模式 (Factory Method)** | 定义一个用于创建对象的接口，让子类决定实例化哪一个类。使一个类的实例化延迟到其子类。 |
| **原型模式 (Prototype)** | 用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。 |
| **单例模式 (Singleton)** | 保证一个类只有一个实例，并提供一个访问它的全局访问点。 |
# 结构型设计模式
结构型设计模式主要关注如何将**类**和**对象**按某种布局组成更大的结构，以获得更灵活、更高效的架构。下表汇总了七种经典的结构型设计模式及其核心定义。
| 模式名称 | 核心定义 |
| :--- | :--- |
| **适配器模式 (Adapter)** | 将一个类的接口转换成客户希望的另一种接口。它使得原本由于**接口不兼容**而不能一起工作的那些类可以一起工作。 |
| **桥接模式 (Bridge)** | 将**抽象部分**与其**实现部分**分离，使它们都可以独立地变化。 |
| **组合模式 (Composite)** | 将对象组合成**树形结构**以表示“部分-整体”的层次结构，它使得用户对单个对象和组合对象的使用具有一致性。 |
| **装饰模式 (Decorator)** | **动态地**给一个对象添加一些额外的职责。 |
| **外观模式 (Facade)** | 为子系统中的一组接口提供一个**一致的界面（高层接口）**，这个接口使得这一子系统更加容易使用。 |
| **享元模式 (Flyweight)** | 运用**共享技术**来有效地支持大量**细粒度**的对象。 |
| **代理模式 (Proxy)** | 为其他对象提供一种**代理**，以控制对这个对象的访问。 |
# 行为型设计模式
行为型设计模式主要关注对象之间的**职责分配、通信和协作**，描述类或对象怎样交互以及怎样分配职责。下表汇总了11种经典的行为型设计模式及其核心定义。
| 模式名称 | 核心定义 |
| :--- | :--- |
| **责任链模式 (Chain of Responsibility)** | 使多个对象都有**机会**处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象**连成一条链**，并沿着这条链传递该请求，直到有一个对象处理它为止。 |
| **命令模式 (Command)** | 将一个**请求封装为一个对象**，从而使得可以用不同的请求对客户进行参数化；支持对请求排队、记录请求日志，以及支持可撤销的操作。 |
| **解释器模式 (Interpreter)** | 给定一个语言，定义它的**文法的一种表示**，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。 |
| **迭代器模式 (Iterator)** | 提供一种方法**顺序访问**一个聚合对象中的各个元素，且**不需要暴露该对象的内部表示**。 |
| **中介者模式 (Mediator)** | 用一个**中介对象**来封装一系列的对象交互。它使各对象不需要显式地相互引用，从而使其**耦合松散**，而且可以独立地改变它们之间的交互。 |
| **备忘录模式 (Memento)** | 在**不破坏封装性**的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将对象**恢复**到原先保存的状态。 |
| **观察者模式 (Observer)** | 定义对象间的一种**一对多**的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。 |
| **状态模式 (State)** | 允许一个对象在**其内部状态改变时改变它的行为**。 |
| **策略模式 (Strategy)** | 定义一系列的算法，把它们**一个个封装起来**，并且使它们可以**相互替换**。它使得算法可以独立于使用它的客户而变化。 |
| **模板方法模式 (Template Method)** | 定义一个操作中的**算法骨架**，而将一些步骤**延迟到子类中**实现。它使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 |
| **访问者模式 (Visitor)** | 表示一个作用于某对象结构中的各元素的**操作**。它允许在不改变各元素的类的前提下**定义作用于这些元素的新操作**。 |
# 设计模式分类 (GoF 23种模式)
以下是经典的 GoF 设计模式按照其**范围**（类/对象）和**目的**（创建型/结构型/行为型）两个维度的分类总览。
| 范围 | 创建型 | 结构型 | 行为型 |
| :--- | :--- | :--- | :--- |
| **类** | 工厂方法模式 | 适配器模式（类） | 解释器模式
模板方法模式 |
| **对象** | 抽象工厂模式
生成器模式
原型模式
单例模式 | 适配器模式（对象）
桥接模式
组合模式
装饰模式
外观模式
享元模式
代理模式 | 责任链模式
命令模式
迭代器模式
中介者模式
备忘录模式
观察者模式
状态模式
策略模式
访问者模式 |
**说明**：
- **范围**：指模式主要用于处理类之间的关系（通过继承）还是对象之间的关系（通过组合）。
- **目的**：创建型（对象创建）、结构型（类/对象组合）、行为型（职责分配与交互）。
- **适配器模式**是唯一在“类”和“对象”范围下都出现的模式，分别对应类适配器和对象适配器两种实现方式。
# 9.1 信息安全基础
## 9.1.1 信息安全的概念
信息安全旨在保护信息系统及其处理、传输、存储的信息免受未经授权的访问、使用、披露、破坏、修改或销毁。
# 9.1 信息安全基础
## 9.1.1 信息安全的概念
信息安全旨在保护信息系统及其处理、传输、存储的信息免受未经授权的访问、使用、披露、破坏、修改或销毁。
### 1. 信息安全的五个基本要素
| 要素 | 核心定义与要求 |
| :--- | :--- |
| **机密性** | 确保信息**不暴露给未授权的实体或进程**。 |
| **完整性** | 确保只有得到允许的人才能修改数据，并且能够判别出数据是否已被篡改。 |
| **可用性** | 确保得到授权的实体在需要时可以访问数据，攻击者不能占用所有资源而阻碍授权者的工作。 |
| **可控性** | 可以控制授权范围内的信息流向及行为方式。 |
| **可审查性** | 对出现的信息安全问题提供调查的依据和手段。 |
### 2. 信息安全的主要范围
信息安全的范围通常包括物理设备、数据、内容与行为四个层面的安全。
| 安全层面 | 核心定义与所包含的方面 |
| :--- | :--- |
| **设备安全** | 信息系统设备的安全是信息系统安全的**物质基础**。它包含以下三个方面：
1. **稳定性**：设备在一定时间内不出故障的概率。
2. **可靠性**：设备能在一定时间内正常执行任务的概率。
3. **可用性**：设备可以正常使用的程度。 |
| **数据安全** | 采取措施确保数据免受**未授权的泄露、篡改和毁坏**。它包含三个方面，与信息安全基本要素相对应：
1. **秘密性 (机密性)**
2. **完整性**
3. **可用性** |
| **内容安全** | 信息安全在**政治、法律、道德层次**上的要求。它主要关注信息内容本身，包括三个方面：
1. **信息内容在政治上健康**
2. **符合国家法律法规**
3. **符合道德规范** |
| **行为安全** | 信息系统的服务功能最终通过行为提供给用户，确保信息系统**行为的安全**是最终保障。其特性包括：
1. **行为的秘密性**
2. **行为的完整性**
3. **行为的可控性** |
> **总结**：信息安全是一个多层次的概念。**设备安全**是基础，**数据安全**是核心（对应机密、完整、可用），**内容安全**是信息的社会性规范，**行为安全**是系统服务功能的最终保障。它们共同构成了完整的信息安全体系。
# 9.1.2 信息存储安全
## 1. 概述
**信息存储安全**是指为确保存储在信息系统中的数据免遭破坏、泄露、篡改和未授权访问而采取的一系列技术和管理的综合性措施。
## 2. 核心内容
信息存储安全主要涵盖以下五个方面：
| 方面 | 核心要求与措施 |
| :--- | :--- |
| **信息使用的安全** | 1. **用户的标识与验证**：确保访问者的身份真实可信。
2. **用户存取权限限制**：根据用户角色和最小权限原则，严格控制其对数据的访问和操作范围。 |
| **系统安全监控** | 1. 建立**安全监控系统**，全面监控系统活动，实时检查使用情况，以便及时发现非法入侵。
2. 建立**完善的审计系统和日志管理系统**，利用日志和审计功能跟踪、记录和审查所有安全相关事件，以确定和填补安全漏洞。 |
| **计算机病毒防治** | 1. 在**网络服务器上**必须加装**网络病毒自动检测系统**。
2. 必须**定期更新**网络病毒检测系统，以防范新型计算机病毒的侵袭。 |
| **数据的加密** | 对敏感或重要数据进行加密存储，确保即使数据被非法获取，也无法被直接识别和利用。 |
| **防止非法的攻击** | 采取防火墙、入侵检测/防御系统（IDS/IPS）等技术手段，主动抵御和防范来自外部的恶意攻击。 |
> **总结**：信息存储安全是一个多层次的防御体系，它融合了**身份认证、访问控制、实时监控、病毒防护、数据加密和攻击防御**等多种手段，共同保障存储数据的机密性、完整性和可用性。
# 9.2 信息安全系统的组成框架
## 9.2.1 技术体系
从实现技术层面看，一个完整的信息安全系统涉及以下关键技术和组件：
| 技术领域 | 核心描述与关键技术 |
| :--- | :--- |
| **基础安全设备** | 包括**密码芯片、加密卡、身份识别卡**等核心硬件，并延伸到**物理安全**层面的技术，如满足防护要求的机房环境、硬件设备、电力供应保障，以及抗电磁干扰和防电磁泄漏的防护措施。 |
| **计算机网络安全** | 保障信息在**网络传输过程**中的安全，防止和监控对数据的未授权破坏、更改和盗取。主要技术包括：
• **网络隔离**：物理隔离、防火墙、访问控制。
• **传输保护**：加密传输、认证、数字签名、摘要、VPN隧道技术。
• **威胁防范**：病毒防范、上网行为管理。
• **审计追溯**：安全审计。 |
| **操作系统安全** | 确保操作系统自身**无错误配置、无漏洞、无后门、无木马**，并能防止非法用户对计算机资源的非法存取。其安全机制主要包括：
• **标识与鉴别机制**
• **访问控制机制**
• **最小特权管理**
• **可信通路、运行保障、存储保护、文件保护机制**
• **安全审计机制** |
| **数据库安全** | 可大致分为**数据库管理系统(DBMS)安全**和**数据库应用系统安全**。关键技术涉及：
• **完整性**：物理数据库与逻辑数据库的完整性。
• **元素安全性、可审计性**
• **访问控制、身份认证、可用性**
• **推理控制、多级保护、消除隐通道** |
| **终端安全设备** | 从**电信网终端设备**的角度划分，主要包括：**电话密码机、传真密码机、异步数据密码机**等。 |
**总结**：信息安全技术体系是一个涵盖**物理、网络、系统、数据、终端**多个层次的纵深防御体系，各部分协同工作，共同构成整体的安全保障能力。
# 10.1.2 信息系统的发展 - 诺兰模型
## 1. 模型概述
- **名称**：**诺兰模型** (Nolan Stage Model)
- **定位**：一个著名的、描述**信息系统进化阶段**的经典模型。
- **核心内容**：该模型将计算机信息系统在一个组织（通常指企业）中的发展道路划分为**六个顺序阶段**。
## 2. 六个发展阶段详解
下表详细说明了诺兰模型的六个阶段及其核心特征：
| 阶段 | 核心特征 | 关键说明与问题 |
| :--- | :--- | :--- |
| **1. 初始阶段** | 计算机作为办公设备引入，应用稀少。 | 计算机初次进入企业，通常只用于**财务部门**等特定领域，属于尝试和启蒙时期。 |
| **2. 传播阶段** | 应用扩散，盲目投入，效率不高。 | 企业对计算机有了初步了解，开始尝试用其解决更多问题（如数据处理）。**软件投入大幅增加**，但因缺乏规划，易产生投资浪费、使用效率不高等新问题。 |
| **3. 控制阶段** | 从整体上控制发展，解决数据共享问题。 | 意识到盲目发展的弊端，开始**从组织层面进行协调与控制**，重点解决数据共享问题。此阶段系统呈现**单点、分散**的特点，资源利用率仍不理想。是**从计算机管理转向数据管理的关键阶段**。 |
| **4. 集成阶段** | 重新规划，建立统一系统，实现集成共享。 | 在控制的基础上，企业开始**重新进行顶层设计与规划**，建立**基础数据库**和**统一的管理信息系统**，初步实现人、财、物等信息在企业的集成共享，提升了IT系统和资源的利用效率。 |
| **5. 数据管理阶段** | 信息成为战略资源，实现平台统一与资源整合。 | 企业高层真正认识到信息的战略价值。信息化建设进入真正的**数据处理阶段**，通过**统一平台**，基本实现各部门、各系统的**资源整合与信息共享**。 |
| **6. 成熟阶段** | IT与管理和深度结合，内外部资源充分整合利用。 | 信息系统已能全面满足企业各层次需求（从事务处理到决策支持）。企业真正将**IT与管理过程深度融合**，实现对组织内、外部资源的**充分整合和利用**。 |
## 3. 总结
诺兰模型揭示了信息系统在组织内部发展的一种**渐进式、阶段性的演化规律**，从一个技术引入的初始点，经历扩散、控制、整合，最终走向与战略和管理深度融合的成熟状态。它对于组织理解自身信息化所处阶段、预见未来挑战和制定发展战略具有重要的指导意义。
# 信息系统战略规划 (ISP)
## 1. 概述
- **定义**：信息系统战略规划 (ISP) 是从**企业战略**出发，构建企业基本的信息系统架构，对企业内、外信息资源进行统一规划、管理与应用的过程。
- **核心目的**：利用信息系统控制企业行为，辅助企业进行决策，**帮助企业实现战略目标**。
## 2. 企业信息系统战略规划的三大阶段
企业信息系统的战略规划可划分为以下三个阶段，其核心焦点和方法论各有不同：
| 阶段 | 规划核心 | 主要规划方法 |
| :--- | :--- | :--- |
| **第一阶段** | 以**数据处理**为核心，围绕**职能部门**需求 | 关键成功因素法 (CSF)
战略目标集转化法 (SST)
企业系统规划法 (BSP) |
| **第二阶段** | 以**企业内部管理信息系统 (MIS)** 为核心，围绕**企业整体**需求 | 战略数据规划法 (SDP)
信息工程法 (IE)
战略栅格法 |
| **第三阶段** | 综合考虑企业内外环境，围绕**企业战略**需求 | 价值链分析法
战略一致性模型 (SAM) |
> **提示**：本笔记根据图片内容，主要整理详述了**第一阶段**的三种方法。
## 3. 第一阶段核心方法详解
### 3.1 关键成功因素法 (CSF)
- **核心思想**：在影响系统目标实现的诸多变量中，识别出若干个**关键和主要的因素**（即关键成功因素）。
- **规划路径**：通过对CSF的识别，找出实现目标所需的关键信息集合，从而**确定系统开发的优先次序**。
- **方法流程**：
组织的目标 → 分解与识别CSF → 识别性能指标 → 产生数据字典
### 3.2 战略目标集转化法 (SST)
- **核心思想**：将整个组织战略目标视为一个 **“信息集合”** ，这个集合由**使命、目标、战略**等组成。
- **规划过程**：管理信息系统的规划过程，即是**把组织的战略目标转变成为管理信息系统的战略目标**的过程。
### 3.3 企业系统规划法 (BSP)
- **核心思想**：**自上而下**地识别企业目标、企业过程和数据，然后**对数据进行分析**，再**自下而上**地设计信息系统。
- **显著特点**：**重视数据的创建和使用**，以数据的创建和使用为归类标准。
- **主要产出**：提供一个信息系统规划，并建立 **CU矩阵（创建/使用矩阵）** 来描述数据与业务流程之间的关系。
---
**总结**：第一阶段（数据处理为核心）的三种方法为信息系统规划奠定了方法论基础。**CSF** 用于确定开发重点，**SST** 用于确保IT战略与业务战略对齐，**BSP** 则通过系统性的数据分析和流程梳理，为构建集成的信息系统提供蓝图。
# 信息系统战略规划 (ISP) - 三阶段方法论详解
## 1. 概述
- **定义**：信息系统战略规划 (ISP) 是从**企业战略**出发，构建企业基本的信息系统架构，对企业内、外信息资源进行统一规划、管理与应用的过程。
- **核心目的**：利用信息系统控制企业行为，辅助企业进行决策，**帮助企业实现战略目标**。
## 2. 企业ISP演进的三大阶段
企业信息系统的战略规划可划分为以下三个递进的阶段，其核心焦点和方法论各有不同：
| 阶段 | 规划核心 | 主要规划方法 |
| :--- | :--- | :--- |
| **第一阶段** | 以**数据处理**为核心，围绕**职能部门**需求 | 关键成功因素法 (CSF)
战略目标集转化法 (SST)
企业系统规划法 (BSP) |
| **第二阶段** | 以**企业内部管理信息系统(MIS)**为核心，围绕**企业整体**需求 | 战略数据规划法 (SDP)
信息工程法 (IE)
战略栅格法 (SG) |
| **第三阶段** | 综合考虑企业内外环境，以**集成**为核心，围绕**企业战略**需求 | 价值链分析法 (VCA)
战略一致性模型 (SAM) |
## 3. 第一阶段核心方法 (数据处理为核心)
### 3.1 关键成功因素法 (CSF)
- **核心**：识别影响目标达成的关键因素，据此确定信息需求与开发次序。
### 3.2 战略目标集转化法 (SST)
- **核心**：将企业战略（使命、目标、战略等）视为一个“信息集合”，并将其转化为信息系统的战略目标。
### 3.3 企业系统规划法 (BSP)
- **核心**：自上而下规划，自下而上实现。通过**CU矩阵**描述数据与流程关系。
## 4. 第二阶段核心方法 (企业MIS为核心)
### 4.1 战略数据规划法 (SDP)
- **核心**：**自顶向下全局规划，自底向上详细设计**，以建立**主题数据库**为主要特征。
- **核心思想**：
- 强调建立**企业模型**和**主题数据库**（面向业务主题，服务于整个企业的稳定数据结构）。
- 认为**数据类基本上是稳定的**，而**业务和流程是多变的**。通过稳定数据结构来适应变化的业务流程。
### 4.2 信息工程法 (IE)
- **核心**：**第一次提出以工程的方法来建立信息系统**，是一种**以数据为中心**的开发方法。
- **核心三要素**：认为与企业的信息系统密切相关的三要素是：**企业的各种信息、企业的业务过程、企业采用的信息技术**。
- **四个实施阶段**：自上而下将整个信息系统开发过程划分为：
1. **信息规划阶段**
2. **业务领域分析阶段**
3. **系统设计阶段**
4. **系统构建阶段**
### 4.3 战略栅格法 (SG)
- **核心**：建立一个**2x2的矩阵**，每个矩阵元素代表业务过程对数据类的**创建和使用**等关系。
- **作用**：通过这个“栅格”（矩阵）来划分和评估现有及未来的信息系统组合，分析它们对企业生存与竞争地位的影响。
## 5. 第三阶段核心方法 (企业战略为核心)
### 5.1 价值链分析法 (VCA)
- **核心**：将企业活动视为一系列创造价值的链式活动。分析其中每个可能对企业造成**增值**的信息活动，**识别对企业增值最大的环节**，从而确定信息化投资和建设的重点。
### 5.2 战略一致性模型 (SAM)
- **核心**：用于分析和确保**企业战略**与**信息系统战略**之间的一致性（或称“战略匹配”）。
- **目标**：保证IT投资和建设能够有效支撑并推动企业总体战略的实现，避免战略脱节。
---
**总结**：ISP方法论从早期的**部门级数据处理**（第一阶段），演进到关注**企业级集成管理**（第二阶段），最终发展为与**企业总体战略深度融合**（第三阶段）。其规划焦点从技术实现层面，逐步提升至业务整合与战略驱动层面。
# 11.1 软件架构概念
## 11.1.1 软件架构的定义
### 1. 核心定义
- **软件架构 (Software Architecture, SA)** 是指一个程序或计算系统的软件体系结构，即系统的一个或多个结构。
- **结构的组成**：包括软件的**构件**、构件的**外部可见属性**以及构件之间的**相互关系**。
- **阶段定位**：是从**需求分析到软件设计之间的过渡过程**。
> **关键理解**：软件架构是一种**表达**或**蓝图**，而非可运行软件本身。它定义了系统的高层组织结构和关键决策。
### 2. 软件架构的作用 (Why Architecture?)
架构作为一种表达，使软件工程师能够：
| 作用 | 核心价值 |
| :--- | :--- |
| **(1) 分析有效性** | 分析设计在**满足所规定的需求**方面的有效性。 |
| **(2) 评估选择方案** | 在**设计变更相对容易的阶段**，考虑体系结构可能的不同选择方案。 |
| **(3) 降低风险** | 降低与**软件构造**相关联的风险。 |
### 3. 软件架构设计活动
- **主要活动**：包括**提出架构模型、产生架构设计、进行设计评审**等活动。
- **过程特性**：是一个**迭代的过程**。
- **关注焦点**：主要关注**软件构件的结构、属性和交互作用**。
- **描述方式**：通过**多种视图**（如逻辑视图、开发视图、进程视图、物理视图等）来全面描述特定系统的架构。
### 4. 软件架构的意义
软件架构在软件开发中扮演着至关重要的角色，其意义体现在以下几个方面：
| 意义层面 | 具体说明 |
| :--- | :--- |
| **交流的手段** | 是**项目干系人**（如客户、管理者、开发人员）进行交流的共同语言和手段。 |
| **实现的约束** | 明确了对**系统实现**的约束条件。 |
| **组织的影响** | 决定了**开发和维护组织的组织结构**。 |
| **质量的制约** | **制约着系统的质量属性**（如性能、安全性、可修改性）。 |
| **根本目的** | 研究软件架构的根本目的是解决好软件的**复用、质量和维护**问题。 |
| **预测模型** | 软件架构是**可传递和可复用的模型**，通过研究软件架构可以**预测软件的质量**。 |
---
**总结**：软件架构是系统设计的顶层抽象，它连接需求与实现，是进行技术决策、风险评估、团队协作和质量保障的核心基础。一个良好的架构是构建成功软件系统的基石。
# 11.1.2 软件架构设计与生命周期
软件架构的设计贯穿于软件生命周期的多个阶段，其中**需求分析**和**设计**是两个尤为关键的阶段。
## 1. 需求分析阶段
- **核心矛盾**：需求分析和架构设计面对的是**不同的对象**。需求分析面向**问题空间**（要解决什么），而架构设计面向**解空间**（如何解决）。
- **关键转换**：从软件需求模型向软件架构模型的转换，主要关注两个核心问题：
1. **如何根据需求模型构建SA模型**。
2. **如何保证模型转换的可追踪性**，确保架构设计能追溯到原始需求。
## 2. 设计阶段
设计阶段是软件架构研究关注最早、最多的核心阶段，主要包括三方面内容：
| 研究方面 | 核心内容与说明 |
| :--- | :--- |
| **SA模型的描述** | 研究如何表达和记录软件架构，分为三个层次：
1. **基本概念**：如构件、连接子。
2. **体系结构描述语言(ADL)**：专门用于描述软件架构的形式化语言。
3. **SA模型的多视图表示**：从不同视角描述系统。 |
| **SA模型的设计与分析方法** | 研究如何进行架构设计、评估和验证其质量属性的方法与技术。 |
| **SA设计经验的总结与复用** | 对成功的架构设计模式、风格、策略进行总结，以支持在新项目中复用。 |
### 2.1 多视图表示与“4+1”视图模型
- **核心思想**：**多视图体现关注点分离(SOC)的思想**。从不同视角（如逻辑、开发、运行、物理）描述系统，每个视图只关心系统的一个侧面，多个视图共同构成完整的架构描述。
- **典型模型**：Philippe Kruchten提出的 **“4+1”视图模型**。该模型从5个视角描述软件架构：
| 视图 | 核心关注点 | 描述内容 |
| :--- | :--- | :--- |
| **逻辑视图** | 功能需求 | 系统的静态结构，如对象、类、包及其关系。面向最终用户。 |
| **开发视图** | 软件开发 | 软件在开发环境中的静态组织，如模块、组件、源码结构。面向开发者。 |
| **进程视图** | 运行特性 | 系统的并发、同步、通信等运行时行为。面向集成人员。 |
| **物理视图** | 系统部署 | 软件到硬件（节点、网络）的映射。面向系统工程人员。 |
| **场景** (统一的+1) | 重要用例 | 通过一组关键用例（场景）将上述四个视图有机地串联起来，验证和阐明它们。 |
> **总结**：需求分析阶段完成从“问题”到“解决方案”的跨越，设计阶段则通过**多视图建模**等方法，将解决方案具体化为可指导实现的、全面的软件架构蓝图。
# 11.1.2 软件架构设计与生命周期 - 4+1视图模型
## 1. 概述
“4+1视图模型”是Philippe Kruchten提出的一种描述软件架构的经典方法。它从**五个不同的视角**来刻画一个软件系统，实现了**关注点分离**，使得不同干系人能专注于系统的特定方面。其中，**场景**作为“+1”视图，是连接和验证其他四个视图的纽带。
## 2. 五种视图详解
下表详细说明了“4+1”模型中每种视图的核心关注点、面向对象和描述内容：
| 视图 | 别称 | 核心关注点 | 面向对象 | 描述内容与侧重点 |
| :--- | :--- | :--- | :--- | :--- |
| **逻辑视图** | 设计视图 | **系统的功能需求**，即软件如何实现用户功能。 | 最终用户、设计人员 | 描述系统的**静态结构**，如对象、类、包、子系统及其关系。 |
| **进程视图** | 过程视图 | **系统的非功能性需求**，如性能、可用性、并发、容错等。 | 集成人员、系统工程师 | 描述系统的**动态行为**，强调并发性、分布性、集成性、进程/线程间的交互与通信。 |
| **开发视图** | 实现视图 | **软件在开发环境中的静态组织**，便于程序设计、实现与管理。 | 开发人员、项目经理 | 侧重于软件模块、组件、库、框架的组织结构，源码的目录划分与依赖关系。 |
| **物理视图** | 部署视图 | **软件到硬件（计算节点）的映射**，即系统在物理上的部署与运行。 | 系统工程师、运维人员 | 描述硬件节点、网络拓扑、软件制品（可执行文件等）的安装位置及节点间的物理连接。 |
| **场景** | 用例视图 | **关键的系统活动**，作为统一线索串联和验证其他视图。 | 所有干系人（尤其是架构师） | 抽象一组最重要的用例或用**例场景**，用以驱动架构设计，并验证构件及其交互关系是否满足核心需求。 |
## 3. 核心总结
- **静态与动态**：**逻辑视图**和**开发视图**主要描述系统的**静态结构**；**进程视图**和**物理视图**主要描述系统的**动态结构**与运行时行为。
- **应用侧重**：不同系统类型的侧重点不同：
- **管理信息系统 (MIS)**：侧重于**逻辑视图**和**开发视图**。
- **实时控制系统**：侧重于**进程视图**和**物理视图**。
- **场景的作用**：**场景**是连接四个视图的“粘合剂”，它确保架构设计能追溯到最重要的用户需求，是验证架构有效性的关键。
> **模型价值**：“4+1视图模型”提供了一个全面、多维的架构描述框架，是沟通、设计和文档化复杂软件系统的强大工具。
# 11.1.2 软件架构设计与生命周期 (完整版)
## 1. 需求分析阶段
- **核心矛盾**：需求分析和架构设计面对的是**不同的对象**。需求分析面向**问题空间**（要解决什么），而架构设计面向**解空间**（如何解决）。
- **关键转换**：从软件需求模型向软件架构模型的转换，主要关注两个核心问题：
1. **如何根据需求模型构建SA模型**。
2. **如何保证模型转换的可追踪性**，确保架构设计能追溯到原始需求。
## 2. 设计阶段
设计阶段是软件架构研究关注最早、最多的核心阶段，主要包括三方面内容：
| 研究方面 | 核心内容与说明 |
| :--- | :--- |
| **SA模型的描述** | 研究如何表达和记录软件架构，分为三个层次：
1. **基本概念**：如构件、连接子。
2. **体系结构描述语言(ADL)**：专门用于描述软件架构的形式化语言。
3. **SA模型的多视图表示**：从不同视角描述系统。 |
| **SA模型的设计与分析方法** | 研究如何进行架构设计、评估和验证其质量属性的方法与技术。 |
| **SA设计经验的总结与复用** | 对成功的架构设计模式、风格、策略进行总结，以支持在新项目中复用。 |
### 2.1 多视图表示与“4+1”视图模型
- **核心思想**：**多视图体现关注点分离(SOC)的思想**。从不同视角（如逻辑、开发、运行、物理）描述系统，每个视图只关心系统的一个侧面，多个视图共同构成完整的架构描述。
- **典型模型**：Philippe Kruchten提出的 **“4+1”视图模型**。该模型从5个视角描述软件架构：
| 视图 | 核心关注点 | 描述内容 |
| :--- | :--- | :--- |
| **逻辑视图** | 功能需求 | 系统的静态结构，如对象、类、包及其关系。面向最终用户。 |
| **开发视图** | 软件开发 | 软件在开发环境中的静态组织，如模块、组件、源码结构。面向开发者。 |
| **进程视图** | 运行特性 | 系统的并发、同步、通信等运行时行为。面向集成人员。 |
| **物理视图** | 系统部署 | 软件到硬件（节点、网络）的映射。面向系统工程人员。 |
| **场景** (统一的+1) | 重要用例 | 通过一组关键用例（场景）将上述四个视图有机地串联起来，验证和阐明它们。 |
## 3. 实现阶段
- **早期局限性**：早期的SA研究通常只关注**较高层次**的系统设计、描述和验证，与具体实现之间存在鸿沟。
- **核心目标**：研究如何将SA设计模型有效地转化为实际可运行的系统。
- **主要研究方向**：
1. **开发过程支持**：研究基于SA的**项目组织结构、配置管理**等开发过程支持技术。
2. **过渡途径**：寻求从SA向实现过渡的有效途径，主要包括：
- 将**程序设计语言元素**引入SA阶段。
- **模型映射** (从架构模型到实现模型的转换)。
- **构件组装**。
- **复用中间件平台** (如应用服务器)。
3. **测试技术**：研究基于SA的测试技术，确保实现符合架构设计。
## 4. 构件组装阶段
- **核心思想**：在**SA设计模型**的指导下，通过组装可复用构件来实现系统。这种方法能够在较高抽象层次上构建系统，并**大幅提高实现效率**。
- **SA的作用**：在构件组装过程中，SA设计模型起到了 **“系统蓝图”** 的关键作用，为构件选择、集成和交互提供了顶层设计约束与指导。
- **核心问题与挑战**：在构件组装阶段，需要解决以下关键问题：
1. **如何支持可复用构件的互联**：即对SA设计模型中规约的**连接子(Connector)**的实现提供支持。
2. **如何检测并消除体系结构失配(Architectural Mismatch)问题**：这是组装过程中的主要挑战。常见的失配问题包括：
- **由构件引起的失配**
- **由连接子引起的失配**
- **由于系统成分对全局体系结构的假设存在冲突引起的失配**
## 5. 部署阶段
- **SA在部署阶段的作用**：软件架构模型在系统部署时发挥重要的指导作用，主要体现在以下两个方面：
1. **提供高层的体系结构视图来描述部署阶段的软硬件模型**，使部署决策基于清晰的系统蓝图。
2. **基于SA模型可以分析不同部署方案的质量属性**（如性能、可靠性、可伸缩性），从而在多个备选方案中选择出**最合理的部署方案**。
## 6. 后开发阶段
- **定义**：指软件**部署安装之后**的阶段，包括软件的运行、维护、演化和复用。
- **研究核心**：此阶段的SA研究主要围绕**系统的维护、演化、复用**等方面来进行。
- **典型研究方向**：主要包括**动态软件体系结构**和**体系结构恢复与重建**。
### 6.1 动态软件体系结构
- **背景与现实**：现实中的软件系统具有**动态性**，其体系结构会在**运行时**发生改变。
- **运行时变化的两种类型**：
1. **内部执行导致的变化**：由软件系统**内部的执行过程**所引发的体系结构改变。
2. **外部请求导致的重配置**：由软件系统**外部的请求**对软件进行的运行时重新配置。
- **研究的两个关键部分**：
1. **体系结构设计阶段的支持**：在架构设计时就考虑并支持未来的动态变化。
2. **运行时刻基础设施的支持**：提供在系统运行时能够安全、可靠地执行架构变更的底层支撑平台和机制。
### 6.2 体系结构恢复与重建
- **背景与问题**：对于**现有系统在开发时没有明确考虑SA**的情况，需要从这些已存在的系统中**恢复或重构出**其体系结构模型。
- **目的**：帮助理解遗留系统、支持维护、演化或进行再工程。
- **体系结构重建的四类方法**（从人工到自动）：
1. **手工体系结构重建**：完全依靠专家经验手动分析系统，重建架构。
2. **工具支持的手工重建**：利用辅助工具（如代码分析、可视化工具）来支持专家进行手工重建。
3. **通过查询语言来自动建立聚集**：使用特定查询语言来自动分析和聚合系统元素，形成高层抽象。
4. **使用其他技术**：如应用**数据挖掘、机器学习**等技术从代码仓库、执行日志等数据中自动发现和重建架构模式。
# 构件 (Component)
## 1. 核心定义
- **构件**是**面向软件体系架构的可复用软件模块**。
- 它是可复用的软件组成成份，可被用来构造其他软件。
- 其具体形态可以是：**被封装的对象类、功能模块、软件框架(Framework)、中间件**等。
## 2. 核心特性
1. **独立可交付的功能单元**：构件是一个自包含的、提供特定功能的单元。
2. **通过接口提供服务**：外界只能通过其**公开定义的接口**来访问构件内部封装的功能和服务。
3. **可复用**：核心价值在于可以被多次、在多个不同上下文中复用，以构造新的软件系统。
## 3. 组成结构
- 一个构件由一组**通常需要同时部署的原子构件 (Atomic Component)** 组成。
- **原子构件**：
- 是**模块和一组资源**的集合。
- 是**部署、版本控制和替换的基本单位**。
- 通常**成组部署**（属于一个构件家族），但理论上**可以被单独部署**。
## 4. 核心概念对比
| 概念 | 定义与说明 | 关键区别 |
| :--- | :--- | :--- |
| **构件** | 由一组原子构件组成的、独立可交付的复用单元。 | 侧重于**复用和功能服务**，是逻辑上的高级单元。 |
| **原子构件** | 构件的基本组成单位，是部署和版本控制的基本单元。 | 侧重于**物理部署和构成**。与构件的核心区别在于：原子构件**通常不被单独部署**，而是作为构件家族的一部分整体部署。 |
| **模块** | 一种特殊的原子构件，是**不带单独资源的原子构件**。 | 本质上是**一组类和/或过程/函数**的集合，是代码的组织单位，不包含独立的资源文件。 |
---
**总结**：在软件架构中，**构件**是高层级的、可复用的功能单元；它由多个可部署的**原子构件**组成；而**模块**是一种更纯粹、无资源的代码级原子构件。理解这三者的层次与关系对于基于构件的软件开发至关重要。
# 构件与对象的特性对比
| 对比维度 | 构件 (Component) | 对象 (Object) |
| :--- | :--- | :--- |
| **单元性质** | 独立部署单元，具有原子性，是不可拆分的。 | 一个实例单元，具有唯一的标志。 |
| **组装角色** | 作为第三方的组装单元。 | (未在图中明确对应) |
| **状态可见性** | 没有外部的可见状态。 | 可能具有状态，此状态外部可见。 |
| **封装内容** | | 封装了自己的状态和行为。 |
> **说明**：一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。
# 构件核心概念
## 1. 构件接口
- **核心**：接口的**标准化**。
- **标准化对象**：关注对接口中**消息的格式、模式和协议**的标准化。
- **关键强调**：其重点**不是**将接口格式化为参数化操作的集合，而是强调当机器在网络中互连时，**标准的消息模式、格式、协议的重要性**。
## 2. 面向构件的编程 (COP)
- **核心关注点**：如何支持建立**面向构件的解决方案**。
- **四大基本支持**：
1. **多态性**（可替代性）
2. **模块封装性**（高层次信息的隐藏）
3. **后期的绑定和装载**（部署独立性）
4. **安全性**（类型和模块安全性）
# 构件技术与主流标准
## 1. 构件技术概述
**构件技术**是利用编程手段，将一些需要但又不便由最终用户直接操作的细节进行**封装**，并对各种**业务逻辑规则**进行实现，从而处理系统内部操作细节的技术。
## 2. 国际三大主流构件标准
目前国际上广泛采用的构件标准主要分为以下三大流派：
| 流派/标准 | 制定方 | 核心组成/内容 | 主要特点与说明 |
| :--- | :--- | :--- | :--- |
| **EJB**
(Enterprise Java Bean) | Sun 公司 | 包含三种类型的EJB：
1. **会话Bean (Session Bean)**
2. **实体Bean (Entity Bean)**
3. **消息驱动Bean (Message-driven Bean)** | 用于实现企业级应用中的**关键业务逻辑**，创建基于构件的应用程序。 |
| **COM / DCOM / COM+**
(Component Object Model) | 微软公司 | 1. **COM**：组件对象模型基础。
2. **DCOM**：COM的分布式扩展，具有**位置独立性和语言无关性**。
3. **COM+**：COM的**新发展或更高层次应用**，并非简单的新版本。 | 构成了微软平台的构件技术体系，从本地调用演进到分布式支持。 |
| **CORBA**
(Common Object Request Broker Architecture) | 对象管理组 (OMG) | 分为三个层次：
1. **对象请求代理 (ORB)**：底层“软总线”，实现对象通信与互操作。
2. **公共对象服务**：提供并发、事务、安全等公共服务。
3. **公共设施**：定义业务对象协作的组件框架与协定规则。 | 一种**面向对象的分布式应用程序体系规范**，强调跨语言、跨平台的互操作性。 |
**总结**：EJB是Java企业级应用的核心标准；COM系列是微软Windows平台构件技术的基石；CORBA则是旨在实现跨平台、跨语言互操作的开放分布式对象规范。这三大标准构成了构件化企业软件开发的主要技术选择。
# 11.2 基于架构的软件开发方法 (ABSD)
## 11.2.1 概述
基于架构的软件设计 (Architecture-Based Software Design, ABSD) 是一种以架构为核心的软件开发方法。
### 1. 核心驱动与描述方式
- **驱动方式**：由**架构驱动**，具体由构成架构的**商业、质量和功能需求**的组合共同驱动设计。
- **描述方法**：
- 采用**视角和视图**来描述软件架构。
- 采用**用例**来描述功能需求。
- 采用**质量属性场景**来描述质量需求（非功能需求）。
### 2. 设计活动的启动时机
- 使用ABSD方法，设计活动可以从**项目总体功能框架明确时就开始**。
- 这意味着在**需求获取与分析尚未完成**时，软件设计工作就可以启动。
### 3. 三个基础
ABSD方法建立在以下三个基础之上：
1. **功能的分解**：使用已有的基于模块的**内聚和耦合**技术。
2. **选择架构风格**：通过选择特定的体系结构风格来实现**质量属性**和**商业需求**。
3. **软件模板的使用**：利用一些软件系统固有的、可复用的**结构模式（软件模板）**。
### 4. 过程特点
- ABSD方法是**递归的**，并且迭代的每一个步骤都是**清晰定义**的。
- 因此，无论设计是否完成，系统的**架构都是清晰的**，这有助于**降低架构设计的随意性**。
---
**总结**：ABSD是一种**架构先行、需求驱动**的方法。它允许设计与需求分析并行，并通过**功能分解、风格选择和模板复用**三个坚实基础，以**递归、迭代**的清晰步骤，系统化地推导出稳定的软件架构。
# 11.2.2 概念和术语 - ABSD 设计元素
## 1. 方法概述
ABSD方法是一个**自顶向下，递归细化**的方法。软件系统的体系结构通过该方法被逐步细化，直到能够推导出具体的**软件构件和类**。
## 2. 核心设计元素
ABSD方法中使用的设计元素及其分解关系如下图所示，遵循**自顶向下、逐层分解**的原则。
### 顶层分解
- 在最顶层，整个系统被分解为：
1. **若干概念子系统**
2. **一个或若干个软件模板**
### 第二层分解
- 在第2层，**概念子系统**又被进一步分解为：
1. **概念构件**
2. **一个或若干个附加软件模板**
**关键概念定义**：
- **概念子系统**：代表系统中一个主要的、高层级的功能或责任区域。
- **概念构件**：是概念子系统内部的、更具体的功能单元或模块。
- **软件模板**：是可复用的、预先定义好的**结构模式**，用于指导和加速系统的设计。
**总结**：ABSD通过将系统逐层分解为**概念子系统 → 概念构件**，并结合可复用的**软件模板**，以递归的方式系统地完成从高层架构到具体设计与实现元素的推导。
# 11.2.2 概念和术语 (续) - 视角、视图、用例与质量场景
## 2. 视角与视图
在考虑软件体系结构时，需要从不同的**视角 (Perspective)** 来观察，以全面描述和评估架构设计。
- **核心思想**：不同的视角关注架构的不同属性，共同构成完整的架构描述。
- **主要分类**：
| 视角类型 | 关注核心 | 用于判断的特性 | 典型视图举例 |
| :--- | :--- | :--- | :--- |
| **静态视角** | 展示系统的**功能组织**与结构。 | **质量特性** (如可维护性、可扩展性) | 逻辑视图、配置视图 |
| **动态视角** | 展示系统的**并发行为**与运行时交互。 | **系统行为特性** (如性能、可靠性) | 进程视图、实现视图 |
- **逻辑视图的作用**：常用来记录设计元素的**功能**和**概念接口**。设计元素的功能定义了它在系统中的**角色**，这些角色包括功能、性能等。
## 3. 用例与质量场景
ABSD方法使用两种不同的“场景”来分别捕获功能需求和非功能（质量）需求。
| 场景类型 | 用途 | 核心描述 |
| :--- | :--- | :--- |
| **用例 (Use Case)** | 捕获 **功能需求** | 是系统的一个**给予用户一个结果值的功能点**。它描述了系统在特定情境下为达成用户目标而执行的一系列动作。 |
| **质量场景 (Quality Scenario)** | 捕获 **质量需求** (非功能需求) | 通过定义具体的、可验证的**场景**来明确系统的质量属性要求，如性能、安全性、可用性等。 |
**总结**：在ABSD中，**视角与视图**提供了多维度描述架构的框架，而**用例**与**质量场景**则是将**功能性**与**非功能性**需求具体化、场景化的重要工具，共同驱动架构的设计与评估。
# 11.2.3 基于架构的开发模型
ABSD 方法定义了一个结构化的、以架构为核心的软件开发模型。该模型将传统以功能实现为中心的线性过程，转变为以架构设计和演化为驱动的迭代过程。
## 1. 传统软件开发过程
一个典型的传统软件开发过程通常包含以下顺序阶段：
1. **问题定义**
2. **需求分析**
3. **软件设计**
4. **实现**
5. **测试**
## 2. ABSD 的六个核心步骤
ABSD 模型将整个软件过程明确划分为以下六个步骤，架构活动贯穿始终：
| 步骤 | 核心任务 |
| :--- | :--- |
| **1. 架构需求** | 明确并定义驱动体系结构设计的商业、质量与功能需求。 |
| **2. 架构设计** | 基于需求，选择体系结构风格，定义系统的高层结构、组件及其交互关系。 |
| **3. 架构文档化** | 将设计决策、体系结构视图和组件规格等正式记录下来，形成架构文档。 |
| **4. 架构复审** | 评估体系结构设计是否满足需求与质量属性，识别潜在风险。 |
| **5. 架构实现** | 依据已确定的体系结构，进行具体设计与编程，实现系统。 |
| **6. 架构演化** | 在系统运行和维护阶段，对体系结构进行调整和优化，以适应变化。 |
**模型核心**：这六个步骤构成了一个从需求到实现再到演化的完整闭环。它强调**架构先行**，并通过**文档化**和**复审**确保架构设计的可见性与正确性，最终支持系统的可持续**演化**。
# 11.2.3 基于架构的开发模型 (ABSD) - 核心步骤详解
基于架构的软件开发 (ABSD) 模型将开发过程划分为六个清晰、顺序与迭代相结合的核心子过程。以下是每个步骤的详细说明、关键活动和产出。
## 1. 架构需求
- **核心目标**：明确并定义驱动体系结构设计的商业、质量与功能需求。
- **需求来源**：主要来自三个方面：
1. **系统的质量目标**
2. **系统的商业目标**
3. **系统开发人员的商业目标**
- **关键活动 (标识构件的三步)**：
1. **需求获取**：从各相关方收集原始需求。
2. **生成类图**：对需求进行分析，初步抽象出系统中的关键类及其关系。
3. **对类进行分组**：将具有紧密关联的类**打包**，形成**构件**，并为其**标识接口**。
## 2. 架构设计
- **核心目标**：基于需求，选择体系结构风格，定义系统的高层结构、组件及其交互关系。
- **核心活动**：将需求阶段标识出的**构件**映射到具体的**构件实现**，并进行深入分析。
- **设计过程步骤**：
1. **提出架构模型**
2. **映射构件**
3. **分析构件相互作用**
4. **产生架构**（输出具体的设计方案）
5. **设计评审**
## 3. 架构文档化
- **核心目标**：将设计决策、体系结构视图和组件规格等正式记录下来，形成可供沟通、评估和实现的文档。
- **主要产出文档**：
1. **体系结构规格说明**
2. **测试体系结构需求的质量设计说明书**
- **文档的重要性**：文档是**所有人员通信的手段**，**关系开发的成败**。撰写时需注意：
- 必须从**使用者的角度**编写。
- 必须**分发给所有与系统有关的开发人员**。
- 必须保持**开发者手上的文档是最新的**。
## 4. 架构复审
- **目的**：评估体系结构设计方案是否满足需求与质量属性，并**标识潜在的风险、缺陷和错误**。
- **参与人员**：由**外部人员**（独立于开发组织之外的人，如用户代表和领域专家）参加。
- **复审内容**：
- 架构能否满足需求。
- 质量需求是否在设计中得到体现。
- 构件的划分是否合理等。
- **复审结果处理**：若**复审不通过**，则返回 **“架构设计”** 阶段，进行**重新设计、文档化，再复审**。
## 5. 架构实现
- **核心目标**：依据已确定的体系结构，进行具体设计与编程，将架构转化为可运行的软件实体。
- **实现过程步骤**：
1. **分析与设计**：用实体（如类、模块）来具体化架构。
2. **构件实现**：实现具体的软件构件。
3. **构件组装**：将构件组装成完整的可运行系统。
4. **系统测试**。
## 6. 架构演化
- **核心目标**：在系统运行和维护阶段，**对架构进行改变**，按需求**增删构件**，使架构能够持续适应变化，**提高可复用性**。
- **演化操作步骤**：
1. **需求变化归类**
2. **制定架构演化计划**
3. **修改、增加或删除构件**
4. **更新构件的相互作用**
5. **构件组装与测试**
6. **技术评审**
7. **产生演化后的架构**
---
**总结**：ABSD 开发模型通过 **“需求→设计→文档化→复审→实现→演化”** 六个步骤，构建了一个严谨的、以架构为核心的软件开发生命周期闭环。它强调早期关注架构、持续验证与复审，并支持系统在生命周期内的持续演化，从而系统性地保障软件的质量、可维护性与适应性。
# 12.1 软件系统质量属性
## 12.1.1 质量属性概念
### 1. 核心定义
- **软件系统质量属性 (Quality Attribute)** 是一个系统的**可测量或可测试**的属性，用于描述系统**满足利益相关者 (Stakeholders) 需求**的程度。
### 2. 质量属性分类
基于软件系统的生命周期，质量属性可分为以下两大类：
| 类别 | 核心描述 |
| :--- | :--- |
| **开发期质量属性** | 在**软件开发阶段**所关注的质量属性。 |
| **运行期质量属性** | 在**软件运行阶段**所表现和关注的质量属性。 |
> **注**：本笔记主要详述开发期质量属性。运行期质量属性通常包括性能、安全性、可用性、可靠性等，将在后续部分介绍。
### 3. 开发期质量属性详解
开发期质量属性主要包含以下六个方面：
| 属性 | 核心定义与说明 |
| :--- | :--- |
| **易理解性** | 指**软件的设计**被开发人员理解的难易程度。 |
| **可扩展性**
(灵活性) | 软件因**适应新需求或需求变化**而增加新功能的能力。 |
| **可重用性** | 指**重用软件系统或其某一部分**的难易程度。 |
| **可测试性** | 对软件进行测试，以**证明其满足需求规范**的难易程度。 |
| **可维护性** | 当需要修改缺陷、增加功能、提高质量属性时，**识别修改点并实施修改**的难易程度。 |
| **可移植性** | 将软件系统从一个**运行环境转移到另一个不同运行环境**的难易程度。 |
**总结**：开发期质量属性聚焦于软件**构建、演化和维护过程**的效率与成本。它们直接影响开发团队的生产力和软件产品的生命周期总成本。良好的开发期质量是构建高质量运行期系统的基础。
# 12.1.1 质量属性概念 (续) - 运行期质量属性
## 2. 运行期质量属性
- **核心定义**：指在**软件运行阶段**所关注的质量属性。
- **主要内容**：运行期质量属性主要包含以下七个方面：
| 属性 | 核心定义与说明 |
| :--- | :--- |
| **性能** | 软件系统**及时提供相应服务**的能力。包括对**速度、吞吐量和容量**等指标的要求。 |
| **安全性** | 软件系统**同时兼顾向合法用户提供服务**，以及**阻止非授权使用**的能力。 |
| **可伸缩性**
(可扩展性) | 当**用户数和数据量增加**时，软件系统**维持高服务质量**的能力。例如，通过增加服务器来提升系统处理能力。 |
| **互操作性** | 本软件系统**与其他系统交换数据**和**相互调用服务**的难易程度。 |
| **可靠性** | 软件系统在**一定的时间内持续无故障运行**的能力。 |
| **可用性** | 系统在**一定时间内正常工作的时间所占的比例**。会受到系统错误、恶意攻击、高负载等问题的影响。 |
| **鲁棒性**
(健壮性/容错性) | 软件系统在**非正常情况下**（如用户进行了非法操作、相关的软硬件系统发生了故障等）仍能够**正常运行**的能力。 |
**总结**：运行期质量属性关注软件在**生产环境中的行为表现**。它们共同决定了系统在面对真实用户、数据和复杂环境时的**稳定性、效率和安全**水平，是终端用户最能直接感知到的软件质量维度。
# 12.1.2 面向架构评估的质量属性
在软件架构评估过程中，通常关注以下八种核心质量属性。
| 属性 | 核心定义 | 关键要点与细分 |
| :--- | :--- | :--- |
| **(1) 性能** | 指系统的**响应能力**。即要经过多长时间才能对某个事件做出响应，或者在某个时间段内系统所能处理的事件个数。 | **衡量指标**：响应时间、吞吐量。
**设计策略**：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。 |
| **(2) 可靠性** | 是软件系统在应用或系统错误面前，在意外或错误使用的情况下，维持其功能特性的基本能力。 | **衡量指标**：平均失效等待时间（MTTF）、平均失效间隔时间（MTBF）。在失效率为常数和修复时间很短的情况下，两者几乎相等。
**两个层面**：
• **容错**：错误发生时确保系统行为正确，并进行内部“修复”。
• **健壮性**：使系统不受错误使用和错误输入的影响，能按既定程序忽略错误。
**设计策略**：冗余、心跳、选举、Ping/Echo。 |
| **(3) 可用性** | 是系统能够正常运行的时间比例。经常用两次故障之间的时间长度，或在出现故障时系统能够恢复正常的速度来表示。 | **衡量指标**：如故障间隔时间。
**设计策略**：冗余、心跳、选举、Ping/Echo。 |
| **(4) 安全性** | 是指系统在向合法用户提供服务的同时，能够阻止非授权用户使用的企图或拒绝服务的能力。 | **可细分为**：
• **机密性**：保证信息不泄露给未授权的用户、实体或过程。
• **完整性**：保证信息的完整和准确，防止信息被非法修改。
• **不可否认性**：信息交换的双方不能否认其在交换过程中发送或接收信息的行为。
• **可控性**：保证对信息的传播及内容具有控制的能力，防止为非法者所用。
**设计策略**：入侵检测、用户认证、用户授权、追踪审计。 |
| **(5) 可修改性** | 指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考查这些变更的代价来衡量。 | **可细分为**：
• **可维护性**：在错误发生后“修复”软件系统的难易程度。
• **可扩展性**：软件为适应新需求或需求变化而增加新功能的能力。
• **结构重组**：重新组织软件系统的构件及构件之间的关系的难易程度。
• **可移植性**：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。
**设计策略**：接口-实现分离、抽象、信息隐藏。 |
| **(6) 功能性** | 是系统所能完成所期望的工作的能力。 | **核心**：一项任务的完成需要系统中许多或大多数构件的相互协作。 |
| **(7) 可变性** | 指架构经扩充或变更而成为新架构的能力。这种新架构应该符合预先定义的规则，在某些具体方面不同于原有的架构。 | **应用场景**：当要将某个架构作为一系列相关产品的基础时，可变性很重要。 |
| **(8) 互操作性** | 作为系统组成部分的软件通常需要与其他系统或自身环境相互作用。 | **核心要求**：为了支持互操作性，软件架构必须为**外部可视的功能特性和数据结构**提供精心设计的软件入口。
**典型问题**：程序和用其他编程语言编写的软件系统的交互作用就是互操作性问题，这种互操作性也影响应用的软件架构。 |
# 12.1.3 质量属性场景描述
## 1. 概念引入
为了精确描述软件系统的质量属性，通常采用**质量属性场景 (Quality Attribute Scenario)** 作为描述和定义质量需求的具体手段。它是一种**面向特定质量属性**的、结构化的需求描述方式。
## 2. 质量属性场景的六个组成部分
一个完整的质量属性场景由以下六个部分构成，它们共同定义了一个具体的、可评估的质量需求实例。
| 组成部分 | 核心定义 |
| :--- | :--- |
| **刺激源 (Source)** | 产生该刺激的实体，可以是人、计算机系统或任何其他刺激器。 |
| **刺激 (Stimulus)** | 当刺激到达系统时，所需考虑的具体条件或事件。 |
| **环境 (Environment)** | 刺激发生时，系统所处的特定条件（如正常运行、过载、维护等）。 |
| **制品 (Artifact)** | 被刺激的对象，可能是整个系统，也可能是系统的某个特定部分。 |
| **响应 (Response)** | 刺激到达后，系统（或制品）所必须采取的行动。 |
| **响应度量 (Response Measure)** | 用于对响应进行度量的具体指标，以便对该需求进行验证和测试。 |
## 3. 实例：可修改性质量属性场景（以淘宝APP为例）
以下以“淘宝APP功能更新”为例，展示一个可修改性质量属性场景的具体应用。
| 场景组成部分 | 对应实例描述 |
| :--- | :--- |
| **刺激源** | 淘宝APP的开发团队（开发人员修改代码）。 |
| **刺激** | 淘宝APP需要进行版本更新，以**增加新功能**或**修复已知问题**。 |
| **环境** | APP运行平台（如iOS、Android的应用商店发布环境）。 |
| **制品** | 新版本的淘宝APP安装包。 |
| **响应** | 成功发布新版本，**增添了计划中的功能**或**修复了特定的BUG**。 |
| **响应度量** | 用户可以观察到：过去的某个BUG**已消失**，或者应用中**出现了承诺的新功能**。 |
---
**总结**：质量属性场景通过**刺激-响应**模型，将抽象的质量属性（如可修改性、性能、安全性等）转化为包含**具体角色、条件、对象、行动和验收标准**的实例。这种描述方法使质量需求变得**具体、可评估、可测试**，是架构设计与评估的重要沟通与验证工具。
# 12.1.3 质量属性场景描述 - 可修改性场景实例
## 可修改性质量属性场景描述实例
下表展示了一个完整的、用于描述“可修改性”质量属性的通用场景模板。它通过定义场景的六个要素及其可能的具体情况，为评估系统的可修改性提供了清晰的分析框架。
| 场景要素 | 可能的情况 / 描述 |
| :--- | :--- |
| **刺激源** | 最终用户、开发人员、系统管理员 |
| **刺激** | 希望增加、删除、修改、改变功能、质量属性、容量等 |
| **环境** | 系统设计时、编译时、构建时、运行时 |
| **制品** | 系统用户界面、平台、环境或与目标系统交互的系统 |
| **响应** | 查找架构中需要修改的位置，进行修改且不会影响其他功能，对所做的修改进行测试，部署所做的修改 |
| **响应度量** | 根据所影响元素的数量度量的成本、努力、资金；该修改对其他功能或质量属性所造成影响的程度 |
**实例应用说明**：
- 此模板定义了评估系统“可修改性”时需考虑的核心维度。
- 在实际分析中，可根据具体变更需求（刺激），选择或组合“可能的情况”来构建一个具体的评估场景。
- 例如，当“开发人员”（刺激源）在“编译时”（环境）希望“增加一个新功能”（刺激）时，评估其“响应”（如定位、修改、测试的难易程度）和“响应度量”（如修改所影响的代码模块数、所需人天）即可形成一个具体的可修改性评估用例。
# 12.1.3 质量属性场景描述
质量属性场景主要用于描述和定义系统的特定质量需求。它主要关注以下六类质量属性，并明确了每类属性在场景描述中需要考察的核心方面。
| 质量属性 | 场景主要关注点 |
| :--- | :--- |
| **可用性** | 系统故障发生的频率、故障发生时的表现、允许系统非正常运行的时间长度、何时可以安全地出现故障、如何防止故障发生以及故障发生时的通知要求。 |
| **可修改性** | 系统在改变功能、质量属性时需要付出的成本和难度。此类场景可能发生在系统设计、编译、构建、运行等多种情况和环境下。 |
| **性能** | 系统的响应速度，可通过效率、响应时间、吞吐量、负载等指标客观评价性能的好坏。 |
| **可测试性** | 系统测试过程中的效率，以及发现系统缺陷或故障的难易程度。 |
| **易用性** | 用户使用系统时的容易程度，包括系统的学习曲线、完成操作的效率、用户对使用过程的满意程度等。 |
| **安全性** | 系统在向合法用户提供服务的同时，阻止非授权用户使用的能力。 |
**总结**：质量属性场景是一种结构化的需求描述方法，它将抽象的、非功能性的质量要求（如“系统要可靠”、“界面要友好”）转化为针对具体属性、包含明确关注点的、可评估和验证的具体场景，从而为架构设计和测试提供明确的依据。
# 12.2 系统架构评估
## 12.2.1 系统架构评估中的重要概念
### 1. 系统架构评估定义
系统架构评估是在**对架构分析、评估**的基础上，**对架构策略的选取进行决策**的过程。
### 2. 三个核心概念
#### (1) 敏感点与权衡点
- **核心定义**：是关键的架构决策。
- **敏感点**：指为了实现**某种特定的质量属性**，**一个或多个构件所具有的特性**。
- **权衡点**：是**影响多个质量属性**的特性，是多个质量属性的敏感点。
- **典型示例 (加密级别)**：
- 提高加密级别可以提高**安全性**，但可能需要耗费更多的处理时间，从而影响**性能**。
- 如果对机密消息的处理有严格的时间延迟要求，则加密级别就可能成为一个**权衡点**。
#### (2) 风险承担者 (利益相关人)
- **核心定义**：系统的架构涉及很多人的利益，这些人都对架构施加各种影响，以保证自己的目标能够实现。
- **核心角色 - 软件系统架构师**：
- 是风险承担者之一。
- 职责是负责在**软件架构的质量需求间进行权衡**。
- 所关心的问题是对**其他风险承担者提出的质量需求进行折中和调停**。
#### (3) 场景
- **核心作用**：在进行架构评估时，一般首先要精确地得出具体的**质量目标**，并以之作为判定该架构优劣的标准。为得出这些目标而采用的机制称之为**场景**。
- **核心描述**：
- 是从**风险承担者的角度**，对与系统的交互所做的简短描述。
- 在架构评估中，一般采用**刺激、环境和响应**三方面来对场景进行描述。
---
**总结**：理解**敏感点/权衡点**有助于识别关键设计决策；明确**风险承担者**及其目标（特别是架构师的调和角色）是评估的社会维度；运用**场景**则是将抽象的质量目标具体化、可评估化的核心方法。三者共同构成了进行有效架构评估的基础认知框架。
# 12.2.1 系统架构评估中的重要概念
## 1. 评估的时间点与目的
- **时间点**：系统架构评估通常位于**架构设计之后**，**系统设计之前**。
- **关联性**：因此，它与后续的设计、实现、测试阶段没有直接关系。
- **核心目的**：评估所采用的架构是否足以**解决软件系统的需求**。
## 2. 系统架构评估的三种方法
| 评估方法 | 核心特点与描述 | 关键要素/备注 |
| :--- | :--- | :--- |
| **(1) 基于调查问卷或检查表的方法** | 类似于需求获取中的问卷调查，但侧重于架构方面。 | **要求**：评估人员必须对评估的领域非常熟悉。 |
| **(2) 基于场景的评估方法** | **主要方法**。通过分析架构对特定**场景**（使用或修改活动）的支持程度，来判断其对质量需求的满足度。 | **场景设计三要素**：
1. **刺激**（事件）
2. **环境**（事件发生条件）
3. **响应**（架构应对过程）
**应用**：ATAM（架构权衡分析方法）、SAAM（软件架构分析方法）。 |
| **(3) 基于度量的评估方法** | 制定定量指标（如代码行数）来直接度量架构。 | **核心活动**：
1. 建立质量属性与度量间的**映射原则**；
2. 从文档中获取**度量信息**；
3. 分析推导出系统质量属性。
**要求**：评估人员需对架构熟悉。 |
# 12.2.2 系统架构评估方法
## 1. 基于场景的架构分析方法 SAAM
SAAM (Software Architecture Analysis Method) 是一种针对非功能质量属性的架构分析方法，是最早形成文档并得到广泛使用的软件架构分析方法。
### (1) 特定目标
对描述应用程序属性的文档进行审查，以**验证基本的架构假设和原则**。
### (2) 评估技术
- 采用的核心技术是**场景技术**。
- 场景代表了描述架构属性的基础，详细描述了各种系统必须支持的活动和可能存在的状态变化。
### (3) 质量属性
- 该方法的基本特点是把任何形式的质量属性都具体化为场景。
- **可修改性**是 SAAM 分析的主要质量属性（核心关注点）。
### (4) 风险承担者
- SAAM 旨在协调不同参与者（风险承担者）之间感兴趣的共同方面。
- 作为后续架构决策的基础，以达成对架构的共识。
### (5) 架构描述
- **时间点**：SAAM 通常在架构的**最后版本**确定后使用，但早于详细设计阶段。
- **形式要求**：架构的描述形式应当被所有参与者理解。
- **描述维度**：架构的**功能**、**结构**和**分配**被定义为描述架构的 3 个主要方面。
### (6) 方法活动
- **主要输入**：**问题描述**、**需求声明**和**架构描述**。
- **分析流程**：SAAM 分析评估架构的过程包括以下 5 个步骤：
1. **场景开发**
2. **架构描述**
3. **单个场景评估**
4. **场景交互评估**
5. **总体评估**
- **逻辑关系**：
- “场景开发”通过迭代生成“体系结构描述”。
- “单个场景评估”与“场景交互评估”通过逻辑或（OR）汇聚为“单个体系结构评估”。
- 结合比较多个体系结构的需求，最终输出“总体评估”。
### (7) 已有知识库的可重用性
- SAAM **不考虑**这个问题。
### (8) 方法验证
- SAAM 是一种成熟的方法，已被广泛应用到众多系统中，包括但不限于：
- 空中交通管制系统
- 嵌入式音频系统
- WRCS（修正控制系统）
- KWIC（根据上下文查找关键词系统）
# 12.2.2 系统架构评估方法
## 2. 架构权衡分析方法 ATAM
ATAM (Architecture Tradeoff Analysis Method) 是在 SAAM 的基础上发展起来的，主要针对性能、安全性、可修改性和可用性，在系统开发之前，对这些质量属性进行评价和折中。
### 核心目标与参与者
- **核心目标**：让架构师明确如何权衡多个质量目标。
- **主要参与者**：评估小组、项目决策者和其他项目相关人。
### 四大活动领域
ATAM 被分为四个主要的活动领域，整个评估过程强调以质量属性作为架构评估的核心：
1. 场景和需求收集
2. 体系结构视图和场景实现
3. 属性模型构造和分析
4. 折中
### ATAM 分析评估过程（九步法）
ATAM 的评估过程通常分为四个阶段，共包含九个具体步骤：
- **阶段1：场景和需求收集**
1. 收集场景
2. 收集需求约束环境
- **阶段2：体系结构视图和场景实现**
3. 描述体系结构视图
4. 实现场景
- **阶段3：属性模型构造和分析**
5. 特定属性分析（优秀的分析理论）
- **阶段4：折中**
6. 标志敏感度
7. 标志折中
8. 产生分析
- **最终输出**
- 形成**行动计划**
# 12.2.2 系统架构评估方法
## 2. 架构权衡分析方法 ATAM（续）
### 补充：ATAM 方法的评估实践阶段划分
用 ATAM 方法评估软件架构，其工作分为 4 个基本阶段，即演示、调查和分析、测试和报告。
#### (1) 阶段1：演示（Presentation）
这是使用 ATAM 评估软件体系结构的初始阶段。
- **① 介绍 ATAM**：描述 ATAM 的评估过程。
- **② 介绍业务驱动因素**：着重业务视角，提供有关系统功能、主要利益相关方、业务目标和其他限制等信息。
- **③ 介绍要评估的体系结构**：侧重可用性以及体系结构的质量要求。
#### (2) 阶段2：调查和分析（Investigation and Analysis）
在这个阶段，人们对评估期间需要重点关注的一些关键问题进行彻底调查。
- **① 确定架构方法**：涉及能够理解系统关键需求的关键架构方法。
- **② 生成质量属性效用树**：确定最重要的质量属性，并确定有限次序。
- **③ 分析体系结构方法**：
- 彻底调查和分析，找出处理相应质量属性架构的方法。
- **包括4个主要阶段**：调查架构方法 -> 创建分析问题 -> 分析问题的答案 -> 找出风险、非风险、敏感点和权衡点。
#### (3) 阶段3：测试
- **① 头脑风暴和优先场景**：将头脑风暴的优先列表与生成质量属性效用树中所获取的优先方案进行比较。
- **② 分析架构方法**。
#### (4) 阶段4：报告 ATAM
- 提供评估期间收集的所有信息，呈现给利益相关者。
# 12.2.2 系统架构评估方法
## 质量属性效用树 (Utility Tree)
ATAM 方法采用 **效用树（Utility tree）** 这一工具来对质量属性进行分类和优先级排序。
- **效用树的结构**：
- **树根**：质量属性
- **下一层**：属性分类
- **叶子节点**：质量属性场景
- **ATAM 主要关注的质量属性**：
ATAM 主要关注以下 4 类质量属性，因为这 4 个质量属性是利益相关者最为关心的：
1. **性能 (Performance)**
2. **安全性 (Security)**
3. **可修改性 (Modifiability)**
4. **可用性 (Usability)**
# 12.2.2 系统架构评估方法
## 3. 成本效益分析法 CBAM
### 基本概念
- **全称**：Cost-Benefit Analysis Method。
- **基础**：在 ATAM 的基础上构建。
- **核心目的**：对架构设计决策的成本和收益进行建模，让决策者根据 **投资回报率 (ROI)** 来选择合适的架构。
- **应用时机**：在 ATAM 确定质量合理的基础上，再对效益进行分析。
### 分析流程（8个步骤）
1. **整理场景**
- 确定场景，并确定优先级。
- 选择优先级最高的 **1/3** 场景进行分析。
2. **对场景进行细化**
- 对每个场景进行详细分析。
- 确定最好、最坏的情况。
3. **确定场景的优先级**
- 项目干系人对场景投票。
- 根据投票结果生成场景的权值。
4. **分配效用**
- 对场景响应级别确定效用表。
- 建立策略、场景、响应级别的表格。
5. **形成“策略-场景-响应级别”的对应关系**
6. **使用内插法确定期望的质量属性响应级别的效用**
- 根据效用表确定所对应的具体场景的效用表。
7. **计算各架构策略的总收益**
8. **根据受成本限制影响的投资回报率 ROI 选择架构策略**
- 估算成本。
- 用上一步的收益减去成本，计算 ROI 并排序。
- 从而选择收益最高的架构策略。
# 中间件
## 1. 定义
中间件是指在一个分布式系统环境中处于**操作系统**和**应用程序**之间的系统级软件。它可以在不同的技术之间共享资源，将不同的操作系统、数据库、异构的网络环境以及若干应用结合成一个有机的协同工作整体。
## 2. 位置与特点
中间件位于客户机/服务器的操作系统之上，管理计算机资源和网络通信。
- **(1) 软件类别**：中间件是**一类软件**，而非一种软件。
- **(2) 核心功能**：不仅仅实现互连，还要实现应用之间的**互操作**。
- **(3) 架构特性**：基于分布式处理的软件，最突出的特点是其**网络通信功能**。
## 3. 任务
中间件的任务是使应用程序开发变得更容易，通过提供统一的程序抽象，**隐藏异构系统和分布式系统下低级别编程的复杂度**。
## 4. 架构图示
- **分层结构**：
- **顶层**：应用（...）
- **中间层**：中间件（分布式系统服务）
- **底层**：操作系统（...）、网络、数据库
## 5. 支持的两方面内容
中间件提供的支持通常包括两方面：
### (1) 交互支持
- **作用**：协调系统中不同组件之间的通信和数据交换。
- **机制**：
- 消息队列
- 远程过程调用（RPC）
- 对象请求代理（ORB）
- **目的**：实现分布式环境中的进程间通信（IPC）。
- **优势**：使得应用程序不必关心底层网络细节，能够更专注于业务逻辑。
### (2) 提供公共服务
- **服务内容**：中间件提供对服务的可复用的实现，如：
- 事务管理
- 安全服务
- 命名和目录服务
- 持久化服务
- 负载均衡
- 故障恢复和容错能力等。
- **解决问题**：有助于解决分布式系统中常见的问题，如一致性、可用性和伸缩性。
# 中间件
## 中间件的功能
1. **负责连接与通信**：
- 负责客户机与服务器之间的连接和通信。
- 负责客户机与应用层之间的高效率通信机制。
2. **提供互操作与控制机制**：
- 提供应用层不同服务之间的互操作机制。
- 提供应用层与数据库之间的连接和控制机制。
3. **提供开发与运行平台**：
- 提供多层架构的应用开发和运行的平台。
- 提供应用开发框架，支持模块化的应用开发。
4. **屏蔽底层差异**：
- 屏蔽硬件、操作系统、网络和数据库的差异。
5. **提供高级管理与安全功能**：
- 提供应用的负载均衡和高可用性。
- 提供安全机制与管理功能。
- 提供交易管理机制，保证交易的一致性。
6. **提供通用服务**：
- 提供一组通用的服务去执行不同的功能。
- 避免重复的工作，使应用之间可以协作。
-
# 中间件
## 中间件的分类
1. **通信处理（消息）中间件**
* **功能**：保证系统能在不同平台之间通信，利用消息传递机制实现分布式系统中可靠的、高效的、实时的跨平台数据传输。
* **示例**：IBM 的 MQSeries。
2. **事务处理（交易）中间件**
* **功能**：实现协调处理顺序、监视和调度、负载均衡等功能。
* **示例**：BEA 的 Tuxedo。
3. **数据存取管理中间件**
* **功能**：为不同种类数据的读写和加解密提供统一的接口。
* **示例**：Windows 平台的 ODBC 和 Java 平台的 JDBC 等。
4. **Web 服务器中间件**
* **功能**：提供 Web 程序执行的运行时容器。
* **示例**：Tomcat、JBOSS 等。
5. **安全中间件**
* **功能**：用中间件屏蔽操作系统的缺陷，提升安全等级。
* **示例**：Kerberos、SSL/TLS。
6. **跨平台和架构的中间件**
* **功能**：用于开发大型应用软件。
* **示例**：CORBA、JavaBeans、COM+模型。
7. **专用平台中间件**
* **功能**：为解决特定应用领域的开发设计问题提供构件库。
* **示例**：Android SDK、iOS SDK。
8. **网络中间件**
* **功能**：包括网管、接入、网络测试、虚拟社区和虚拟缓冲等，也是当前最热门的研发项目。
* **示例**：TCP/IP协议栈、HTTP服务器。
# 13.1 软件可靠性基本概念-13.1.1 软件可靠性定义
## 1. 软件可靠性定义
软件可靠性（Software Reliability）是软件产品在**规定的条件下**和**规定的时间区间**完成**规定功能**的能力。
## 2. 软件可靠性和硬件可靠性区别
- **(1) 复杂性**：
- 软件复杂性比硬件高。
- 大部分失效来自于软件失效。
- **(2) 物理退化**：
- 软件不存在物理退化现象。
- 硬件失效主要是由于物理退化所致。
- **(3) 唯一性**：
- 软件是唯一的，每个复制版本都一样。
- 两个硬件不可能完全一样。
- **(4) 版本更新周期**：
- 硬件较慢。
- 软件较快。
-
# 13.1.2 软件可靠性的定量描述
## 1. 规定时间
* 自然时间
* 运行时间
* 执行时间（占用CPU）
## 2. 失效概率
* 软件运行初始时刻失效概率为0，随着时间增长单调递增，不断趋向于1。
## 3. 可靠度
* **定义**：软件系统在规定的条件下、规定的时间内不发生失效的概率。
* **计算公式**：等于1 - 失效概率。
## 4. 失效强度
* 单位时间软件系统出现失效的概率。
## 5. 平均失效前时间 (MTTF)
* **定义**：平均失效等待时间，即系统从开始运行到发生第一次故障所经历的平均时间。
## 6. 平均恢复前时间 (MTTR)
* **定义**：平均修复时间，即从出现故障到修复成功的时间。
## 7. 平均故障间隔时间 (MTBF)
* **定义**：平均失效间隔时间，即失效或维护中所需的平均时间，包括故障时间以及检测和维护设备的时间。（系统两次连续故障之间的平均时间）。
* **公式**：`MTBF = MTTF + MTTR`
* **系统可用性公式**：`系统可用性 = MTTF / (MTTF + MTTR) * 100%`
# 13.1.2 软件可靠性的定量描述
## 串并联系统可靠性
无论什么系统，都是由多个设备组成，并协同工作，而这多个设备的组合方式可以是串联、并联，也可以是混合模式。假设每个设备的可靠性为 $R_1, R_2 \cdots R_n$，则：
### 1. 串联系统可靠性
- **公式**：$R = \prod_{i=1}^{n} R_i$
- **模型说明**：输入依次经过 $R_1, R_2 \cdots R_n$ 处理后输出。只要其中一个设备失效，整个系统就会失效。
### 2. 并联系统可靠性
- **公式**：$R = 1 - \prod_{i=1}^{n} (1 - R_i)$
- **模型说明**：输入同时分发至 $R_1, R_2 \cdots R_n$ 进行处理后汇总输出。只有当所有设备都失效时，系统才会失效。
# 13.1.4 可靠性测试的意义
## 可靠性测试的意义
1. **灾难性后果**：软件失效可能造成灾难性的后果。
2. **高占比**：软件的失效在整个计算机系统失效中的比例较高。
3. **技术不成熟**：软件可靠性技术很不成熟，加剧了软件可靠性问题的重要性。
4. **成本增加**：软件可靠性问题是造成软件费用增长的主要原因之一。
5. **依赖性增强**：系统对于软件的依赖性越来越强，软件对生产活动和社会生活的影响越来越大，从而增加了软件可靠性问题在软件工程领域乃至整个计算机工程领域的重要性。
## 可靠性测试的目的
1. **发现缺陷**：发现软件系统在需求、设计、编码、测试和实施等方面的各种缺陷。
2. **提供数据**：为软件的使用和维护提供可靠性数据。
3. **确认达标**：确认软件是否达到可靠性的定量要求。
# 13.2 软件可靠性模型
## 13.2.1 影响软件可靠性的因素
- **软件可靠性模型定义**：为预计或估算软件的可靠性所建立的可靠性框图和数学模型。
- **主要影响因素**（从技术角度）：
- 运行剖面（环境）
- 软件规模
- 软件内部结构
- 软件的开发方法和开发环境
- 软件的可靠性投入
## 13.2.2 软件可靠性的建模方法
- **模型组成部分**：
- **(1) 模型假设**：模型是实际情况的简化或规范化，总要包含若干假设，例如测试的选取代表实际运行剖面（环境），不同软件失效独立发生等。
- **(2) 性能度量**：软件可靠性模型的输出量就是性能度量，如失效强度、残留缺陷数等。在软件可靠性模型中性能度量通常以数学表达式给出。
- **(3) 参数估计方法**：某些可靠性度量的实际值无法直接获得（例如残留缺陷数），这时需通过一定的方法估计参数的值，从而间接确定可靠性度量的值。
- **(4) 数据要求**：一个软件可靠性模型要求一定的输入数据，即软件可靠性数据。
- **绝大多数模型包含的3个共同假设**：
- **(1) 代表性假设**：是指可以用测试产生的软件可靠性数据预测运行阶段的软件可靠性行为。
- **(2) 独立性假设**：此假设认为软件失效是独立发生于不同时刻，一个软件失效的发生不影响另一个软件失效的发生。
- **(3) 相同性假设**：此假设认为所有软件失效的后果（等级）相同，即建模过程只考虑软件失效的具体发生时刻，不区分软件的失效严重等级。
# 13.3 软件可靠性管理
## 1. 基本概念
- **定义**：软件可靠性管理是软件工程管理的一部分，它以全面提高和保证软件可靠性为目标，以软件可靠性活动为主要对象，是把现代管理理论用于软件生命周期中的可靠性保障活动的一种管理形式。
- **核心内容**：包括软件工程各个阶段的可靠性活动的目标、计划、进度、任务和修正措施等。
## 2. 各阶段可靠性活动
- **需求分析阶段**：
- 确定可靠性目标
- 分析影响因素
- 确定验收标准
- 制定管理框架
- 制定文档编写规范
- 制定活动初步计划
- 确定数据收集规范
- **概要设计阶段**：
- 确定可靠性度量
- 制定详细验收方案
- 可靠性设计
- 收集可靠性数据
- 调整活动计划
- 明确后续阶段详细计划
- 编制文档
- **详细设计阶段**：
- 可靠性设计
- 可靠性预测
- 调整活动计划
- 收集可靠性数据
- 明确后续阶段详细计划
- 编制文档
- **编码阶段**：
- 可靠性测试（含于单元测试）
- 排错
- 调整活动计划
- 收集可靠性数据
- 明确后续阶段详细计划
- 编制文档
- **测试阶段**：
- 可靠性测试（含于集成测试、系统测试）
- 排错
- 可靠性建模
- 可靠性评价
- 调整活动计划
- 收集可靠性数据
- 明确后续阶段详细计划
- 编制文档
- **实施阶段**：
- 可靠性测试（含于验收测试）
- 排错
- 收集可靠性数据
- 调整模型
- 可靠性评价
- 编制文档
# 13.4 软件可靠性设计
## 1. 可靠性控制的最佳阶段
实践证明，保障软件可靠性最有效、最经济、最重要的手段是在软件设计阶段采取措施进行可靠性控制。
## 2. 定义
可靠性设计就是在常规的软件设计中，应用各种方法和技术，使程序设计在兼顾用户的功能和性能需求的同时，全面满足软件的可靠性要求。
## 3. 软件可靠性设计的原则
1. **整体性与协调性**：软件可靠性设计是软件设计的一部分，必须在软件的总体设计框架中使用，并且不能与其他设计原则相冲突。
2. **质量与目标导向**：软件可靠性设计在满足提高软件质量要求的前提下，以提高和保障软件可靠性为最终目标。
3. **合理定位与目标设定**：软件可靠性设计应确定软件的可靠性目标，不能无限扩大化，并且排在功能度、用户需求和开发费用之后考虑（即在满足基本功能和成本约束后再追求高可靠性）。
## 4. 主要设计技术
软件可靠性设计技术主要有容错设计、检错设计、降低复杂度设计和系统配置技术等技术。
# 13.4 软件可靠性设计
## 1. 两大关键技术分类
提高系统可靠性的技术可以分为以下两类：
- **避错（排错）技术**：
- **定义**：通过技术评审、系统测试和正确性证明等技术，在系统正式运行之前避免、发现和改正错误。
- **容错技术**：
- **定义**：系统在运行过程中发生一定的硬件故障或软件错误时，仍能保持正常工作而不影响正确结果的一种性能或措施。
- **核心手段**：主要是采用**冗余方法**来消除故障的影响。
## 2. 冗余技术详解
- **定义**：在正常系统运行所需的基础上加上一定数量的资源，包括信息、时间、硬件和软件。
- **地位**：冗余是容错技术的基础，通过冗余资源的加入，可以使系统的可靠性得到较大的提高。
- **主要的冗余技术分类（4种）**：
1. 结构冗余（分为静态、动态、混合）
2. 信息冗余
3. 时间冗余
4. 冗余附加
# 13.4.1 容错设计技术
## 1. 软件容错技术主要方法
- 恢复块设计
- N版本程序设计
- 冗余设计
## 2. 恢复块设计（动态冗余）
- **基本概念**：
- 程序的执行过程是由一系列操作构成的。
- 该方法的核心是选择一组操作作为容错设计单元，将普通程序块转化为恢复块。
- 本质是一种**动态的故障屏蔽技术**，采用**后向恢复策略**。
- **设计重点与要求**：
- **独立性**：必须保证实现主块和后备块之间的独立性。
- **防共因错误**：避免相关错误的产生，使主块和备份块之间的共性错误降到最低程度。
- **验证**：必须保证验证测试程序的正确性。
## 3. 冗余设计
- **实现原理**：
- 在一套完整的软件系统之外，设计一种**不同路径、不同算法或不同实现方法**的模块或系统作为备份。
- **工作机制**：在出现故障时，可以使用冗余的部分进行替换，从而维持软件系统的正常运行。
## 4. N版本程序设计
- **核心机制**：
- 通过设计出多个模块或不同版本。
- 对于相同初始条件和相同输入的操作结果，实行**多数表决**。
- 目的：防止其中某一软件模块/版本的故障提供错误的服务，以实现软件容错。
- **关键注意事项**：
1. **需求说明的完备性**：软件需求说明必须具有完全性和精确性，这是保证软件设计错误不相关的前提。
2. **设计全过程的不相关性**：
- N个版本的程序必须由**不同的人**独立设计。
- 必须使用不同的算法、编程语言、编译程序、设计工具、实现方法和测试方法。
- 目的：减少N个版本的程序在表决点上相关错误的概率。
- **技术属性**：
- **类型**：一种静态的故障屏蔽技术。
- **策略**：采用前向恢复的策略
# 13.4.1 容错设计技术
## 3. 恢复块设计与N版本程序设计的比较
| 对比维度 | 恢复块方法 | N版本程序设计 |
| :--- | :--- | :--- |
| **硬件运行环境** | 单机 | 多机 |
| **错误检测方法** | 验证测试程序 | 表决 |
| **恢复策略** | 后向恢复 | 前向恢复 |
| **实时性** | 差 | 好 |
## 4. 恢复策略定义
- **前向恢复**：
- **定义**：使当前的计算继续下去，把系统恢复成连贯的正确状态，弥补当前状态的不连贯情况。
- **后向恢复**：
- **定义**：系统恢复到前一个正确状态，继续执行。
# 13.4.4 系统配置技术
## 1. 概述
- **核心手段**：在系统配置中采用容错技术，通过系统的整体来提供相应的可靠性。
- **主要技术**：
- 双机热备技术
- 服务器集群技术
## 2. 双机热备技术
- **定义**：一种软硬件结合的较高容错应用方案。
- **系统组成**：
- 两台服务器
- 一个外接共享磁盘阵列柜
- 相应的双机热备份软件
- **关键机制：“心跳”方法**
- **功能**：保证主系统与备用系统的联系。
- **原理**：主从系统之间相互按照一定的时间间隔发送通信信号，表明各自系统当前的运行状态。
- **故障切换流程**：
1. **检测**：一旦“心跳”信号表明主机系统发生故障，或者备用系统无法收到主系统的“心跳”信号。
2. **判定**：系统的高可用性管理软件认为主系统发生故障。
3. **切换**：立即将系统资源转移到备用系统上。
4. **接管**：备用系统替代主系统工作，以保证系统正常运行和网络服务不间断。
- **3种工作模式**：
- 双机热备模式
- 双机互备模式
- 双机双工模式
# 13.4.4 系统配置技术
## 双机热备技术的三种工作模式
### 1. 双机热备模式 (Active/Standby)
- **工作机制**：
- Active服务器处于工作状态，Standby服务器处于监控准备状态。
- 数据（包括数据库数据）同时往两台或多台服务器写入，保证数据的即时同步。
- **故障处理**：当Active服务器出现故障时，通过软件诊测或手工方式将Standby机器激活，保证应用在短时间内完全恢复正常使用。
- **特点**：
- 是目前采用较多的一种模式。
- **缺点**：另外一台服务器长期处于后备状态，存在一定的计算资源浪费。
### 2. 双机互备模式
- **工作机制**：
- 两个相对独立的应用在两台机器上同时运行。
- 彼此均设为备机。
- **故障处理**：当某一台服务器出现故障时，另一台服务器可以在短时间内将故障服务器的应用接管过来，保证应用的持续性。
- **特点**：对服务器的性能要求比较高。
### 3. 双机双工模式
- **工作机制**：
- 集群的一种形式。
- 两台服务器均处于活动状态，同时运行相同的应用。
- **优势**：
- 保证整体系统的性能。
- 实现了负载均衡和互为备份。
- **存储技术**：通常使用磁盘柜存储技术。
- **应用场景**：Web服务器、FTP服务器等用此种方式比较多。
# 13.4.4 系统配置技术
## 2. 服务器集群技术
- **定义**：
- 指一组相互独立的服务器在网络中组合成为单一的系统工作，并以单一系统的模式加以管理。（即将多台计算机组织起来进行协同工作）
- **工作机制**：
- **任务分担**：每台计算机均承担部分计算任务和容错任务。
- **故障处理**：
1. 隔离：当其中一台计算机出现故障时，系统使用集群软件将这台计算机从系统中隔离出去。
2. 负载转嫁：通过各计算机之间的负载转嫁机制完成新的负载分担。
3. 报警：同时向系统管理人员发出警报。
- **最终目标**：通过功能整合和故障过渡，实现了系统的高可用性和可靠性。
- **特点**：
- 可伸缩性
- 高可用性
- 可管理性
- 高性价比
- 高透明性
- **分类**：
- 高性能计算集群
- 负载均衡集群
- 高可用性集群
# 13.4.4 系统配置技术
## 负载均衡技术
- **定义与目的**：
- 是集群系统中的一项重要技术。
- **作用**：提高集群系统的整体处理能力和系统可靠性，加快响应速度，提高客户端访问的成功概率。
- **核心目的**：让所有节点承受的负荷平均，不出现局部过大负载或过轻负载的情况。
- **常用的负载均衡实现技术**：
1. **基于特定软件的负载均衡（应用层）**
- **原理**：利用网络协议（如HTTP）的重定向功能。服务器返回一个重定向响应，客户端确认新地址后重发请求，从而达到负载均衡。
2. **基于DNS的负载均衡（传输层）**
- **原理**：在DNS服务器中为同一个主机名配置多个IP地址。应答查询时按顺序返回不同的解析结果，将客户端引导至不同节点。
3. **基于NAT的负载均衡**
- **原理**：将一个外部IP地址映射为多个内部IP地址。动态转换连接请求的内部地址，将外部请求引导至对应节点。
4. **反向代理负载均衡**
- **原理**：将来自Internet的连接请求以反向代理的方式动态地转发给内部网络上的多个节点进行处理。
5. **混合型负载均衡**
# 13.5 软件可靠性测试
## 1. 测试概述
- **主要活动**：由可靠性目标的确定、运行剖面的开发、测试用例的设计、测试实施、测试结果的分析等活动组成。
- **简化步骤**：
1. 定义软件运行剖面（为软件的使用行为建模，开发使用模型，明确需要测试的内容）。
2. 设计可靠性测试用例。
3. 实施可靠性测试。
## 2. 可靠性数据类型
软件可靠性数据是可靠性评价的基础。用时间定义的数据主要分为4类：
- **(1) 失效时间数据**：记录发生一次失效所累积经历的时间。
- **(2) 失效间隔时间数据**：记录本次失效与上一次失效间的间隔时间。
- **(3) 分组时间内的失效数**：记录某个时间区内发生了多少次失效。
- **(4) 分组时间的累积失效数**：记录到某个区间的累积失效数。
# 13.6 软件可靠性评价
## 1. 评价过程
主要包括3个过程：
- 选择可靠性模型
- 收集可靠性数据
- 可靠性评估和预测
## 2. 模型选择因素
选择软件可靠性模型时需考虑的4个因素：
- 模型假设的适用性
- 预测的能力与质量
- 模型输出值能否满足可靠性评价需求
- 模型使用的简便性
## 3. 数据收集
- **数据定义**：主要是指软件失效数据，是评价的基础，主要在软件测试、实施阶段收集。
- **解决方法/建议**：
- 及早确定所采用的可靠性模型。
- 制订可实施性较强的可靠性数据收集计划。
- 重视软件测试数据的整理和分析。
- 充分利用数据库来完成可靠性数据的存储和统计分析。
## 4. 评估与预测
- **主要目的**：
- 评估软件系统的可靠性状况。
- 预测将来一段时间的可靠性水平。
- **需解答的关键问题**：
1. 判断是否达到了可靠性目标？
2. 如未能达到，要再投入多少？
3. 在软件系统投入实际运行一年或若干时间后，经过维护、升级和修改，能否达到交付或部分交付用户使用的可靠性水平？
- **技术方法**：
- 主要以软件可靠性模型分析为主。
- 辅以失效数据的图形分析法、试探性数据分析技术（EDA）等。
# 14.1 信息物理系统技术概述 - 14.1.1 信息物理系统的概念
## 1. 定义与起源
- **全称**：信息物理系统（Cyber-Physical Systems，简称 CPS）。
- **定位**：是控制系统、嵌入式系统的扩展与延伸。
- **技术渊源**：其涉及的相关底层理论技术源于对嵌入式技术的应用与提升。
## 2. 核心构成与技术融合
- **技术集成**：通过集成先进的感知、计算、通信、控制等信息技术和自动控制技术。
- **系统构建**：构建了物理空间与信息空间中人、机、物、环境、信息等要素相互映射、适时交互、高效协同的复杂系统。
- **系统特性**：实现系统内资源配置和运行的按需响应、快速迭代、动态优化。
## 3. 本质与价值
- **本质**：构建一套信息空间与物理空间之间基于数据自动流动的状态感知、实时分析、科学决策、精准执行的闭环赋能体系。
- **解决问题**：解决生产制造、应用服务过程中的复杂性和不确定性问题。
- **最终目标**：提高资源配置效率，实现资源优化。
# 14.1.2 CPS的实现
## 1. CPS的体系架构
### (1) 单元级CPS
- **定义**：具有不可分割性的CPS最小单元。
- **功能特征**：具备可感知、可计算、可交互、可延展、自决策功能。
- **典型实例**：一个智能部件、一个工业机器人或一个智能机床。
### (2) 系统级CPS
- **构成**：多个最小单元（单元级）通过工业网络（如工业现场总线、工业以太网等）互联。
- **目标**：实现更大范围、更宽领域的数据自动流动，进一步提高制造资源配置的广度、深度和精度。
- **包含功能**：
- **互联互通、边缘网关、数据互操作**：主要实现单元级CPS的异构集成。
- **即插即用**：主要在系统级CPS实现组件管理，包括组（单元级CPS）的识别、配置、更新和删除等功能。
- **协同控制**：指对多个单元级CPS的联动和协同控制等。
- **监视与诊断**：主要是对单元级CPS的状态实时监控和诊断其是否具备应有的能力。
### (3) SoS级CPS
- **构成**：多个系统级CPS的有机组合。
- **典型实例**：多个工序（系统的CPS）形成一个车间级的CPS或者形成整个工厂的CPS。
- **核心目标**：实现数据的汇聚，从而对内进行资产的优化和对外形成运营优化服务。
- **主要功能**：
- 数据存储
- 数据融合
- 分布式计算
- 大数据分析
- 数据服务（并在此基础上形成了资产性能管理和运营优化服务）
# 14.1.2 CPS的实现
## 1. CPS的体系架构
### (1) 单元级CPS
- **定义**：具有不可分割性的CPS最小单元。
- **功能特征**：具备可感知、可计算、可交互、可延展、自决策功能。
- **典型实例**：一个智能部件、一个工业机器人或一个智能机床。
### (2) 系统级CPS
- **构成**：多个最小单元（单元级）通过工业网络（如工业现场总线、工业以太网等）互联。
- **目标**：实现更大范围、更宽领域的数据自动流动，进一步提高制造资源配置的广度、深度和精度。
- **包含功能**：
- **互联互通、边缘网关、数据互操作**：主要实现单元级CPS的异构集成。
- **即插即用**：主要在系统级CPS实现组件管理，包括组（单元级CPS）的识别、配置、更新和删除等功能。
- **协同控制**：指对多个单元级CPS的联动和协同控制等。
- **监视与诊断**：主要是对单元级CPS的状态实时监控和诊断其是否具备应有的能力。
### (3) SoS级CPS
- **构成**：多个系统级CPS的有机组合。
- **典型实例**：多个工序（系统的CPS）形成一个车间级的CPS或者形成整个工厂的CPS。
- **核心目标**：实现数据的汇聚，从而对内进行资产的优化和对外形成运营优化服务。
- **主要功能**：
- 数据存储
- 数据融合
- 分布式计算
- 大数据分析
- 数据服务（并在此基础上形成了资产性能管理和运营优化服务）
# 14.1.2 CPS的实现
## 2. CPS的技术体系
### (1) 技术体系分类
CPS技术体系主要分为三个层次：
- **CPS总体技术**：主要包括系统架构、异构系统集成、安全技术、试验验证技术等，是CPS的顶层设计技术。
- **CPS支撑技术**：主要包括智能感知、嵌入式软件、数据库、人机交互、中间件、SDN（软件定义网络）、物联网、大数据等，是基于CPS应用的支撑。
- **CPS核心技术**：主要包括虚实融合控制、智能装备、MBD、数字孪生技术、现场总线、工业以太网、CAX\MES\ERP\PLM\CRM\SCM等，是CPS的基础技术。
### (2) 四大核心技术要素
CPS的技术体系可以进一步凝练为“一硬”、“一软”、“一网”、“一平台”：
- **“一硬”（感知和自动控制）**：是CPS实现的硬件支撑。
- **“一软”（工业软件）**：固化了CPS计算和数据流程的规则，是CPS的核心。
- **“一网”（工业网络）**：是互联互通和数据传输的网络载体。
- **“一平台”（工业云和智能服务平台）**：是CPS数据汇聚和支撑上层解决方案的基础，对外提供资源管控和能力服务。
# 14.1.3 信息物理系统的建设和应用
## 1. CPS的典型应用场景
* **(1) 智能设计**
* **核心内容**：在产品及工艺设计、工厂设计过程中的大部分工作都可以在虚拟空间中进行仿真，并实现迭代和改进。
* **包含范围**：产品及工艺设计、生产线/工厂设计。
* **(2) 智能生产**
* **核心内容**：打破生产过程的信息孤岛现象，实现设备的互联互通，实现生产过程监控，合理管理和调度各种生产资源，优化生产计划，达到资源和制造协同，实现“制造”到“智造”的升级。
* **包含范围**：设备管理、生产管理、柔性制造。
* **(3) 智能服务**
* **核心内容**：通过CPS按照需要生成本地与远程云服务相互协作、个体与群体、群体与系统的相互协同一体化工业云服务体系，能够更好地服务于生产，解决装备运行日益复杂、使用难度日益增大的困扰，实现智能装备的协同优化，支持企业用户经济性、安全性和高效性经营目标落地。
* **包含范围**：健康管理、智能维护、远程征兆性诊断、协同优化、共享服务。
* **(4) 智能应用**
* **核心内容**：将设计者、生产者和用户的单调角色转变为新价值创造的参与者，并通过新型价值链的创建反馈到产业链的转型，从根本上调动各个参与者的积极性，实现制造业转型。
* **包含范围**：无人装备、产业链互动、价值链共赢。
## 2. CPS的建设路径
CPS的建设路径分为如下阶段：
1. **CPS体系设计**阶段
2. **单元级CPS**建设阶段
3. **系统级CPS**建设阶段
4. **SoS级CPS**建设阶段
# 14.2 人工智能技术概述 - 14.2.1 人工智能的概念
## 1. 定义
- **全称**：人工智能（Artificial Intelligence, AI）。
- **核心内涵**：是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。
## 2. 目标与研究领域
- **主要目标**：了解智能的实质，并生产出一种新的能以人类智能相似的方式做出反应的智能机器。
- **研究领域**：包括机器人、自然语言处理、计算机视觉和专家系统等。
## 3. 分类
根据人工智能是否能真正实现推理、思考和解决问题，可以将其分为两类：
- **弱人工智能**：不能真正实现推理和解决问题的智能机器。
- **强人工智能**：真正能思维的智能机器。
# 14.2 人工智能技术概述 - 14.2.2 人工智能关键技术
## 1. 自然语言处理 (NLP)
- **核心定义**：研究实现人与计算机之间用自然语言进行有效通信的各种理论和方法。
- **主要技术方向**：
- **机器翻译**：从一种自然语言到另外一种自然语言的翻译。
- **语义理解**：利用计算机理解文本篇章内容，并回答相关问题。
- **问答系统**：让计算机像人类一样用自然语言与人交流。
## 2. 计算机视觉 (CV)
- **核心定义**：使用计算机模仿人类视觉系统的科学。
- **核心目标**：让计算机拥有类似人类提取、处理、理解和分析图像以及图像序列的能力。
- **实现方式**：将图像分析任务分解为便于管理的小块任务。
## 3. 知识图谱 (KG)
- **核心定义**：把所有不同种类的信息连接在一起而得到的一个关系网络。
- **核心价值**：提供了从“关系”角度去分析问题的能力。
- **典型应用**：一般用于反欺诈、不一致性验证等问题。
## 4. 人机交互 (HCI)
- **核心定义**：主要研究人和计算机之间的信息交换。
## 5. 虚拟现实或增强现实 (VR/AR)
- **技术定位**：以计算机为核心的新型视听技术。
- **核心目标**：结合相关科学技术，在一定范围内生成与真实环境在视觉、听觉等方面高度近似的数字化环境。
## 6. 机器学习 (ML)
- **核心定义**：是以数据为基础，通过研究样本数据寻找规律，并根据所得规律对未来数据进行预测。
- **应用领域**：目前广泛应用于数据挖掘、计算机视觉、自然语言处理、生物特征识别等领域。
- **学习模式分类**：
- **监督学习**：需要提供标注的样本集。
- **无监督学习**：不需要提供标注的样本集。
- **半监督学习**：需要提供少量标注的样本集。
- **强化学习**：需要反馈机制
### (1) 监督学习
- **核心机制**：利用已标记的有限训练数据集，通过某种学习策略/方法建立一个模型，从而实现对新数据/实例的标记（分类）/映射。
- **应用领域**：自然语言处理、信息检索、文本挖掘、手写体辨识、垃圾邮件侦测等。
- **典型算法**：回归和分类等。
### (2) 无监督学习
- **核心机制**：利用无标记的有限数据描述隐藏在未标记数据中的结构/规律。
- **主要优势**：
- 不需要以人工标注数据作为训练样本；
- 便于压缩数据存储、减少计算量、提升算法速度；
- 避免正负样本偏移引起的分类错误问题。
- **应用领域**：经济预测、异常检测、数据挖掘、图像处理、模式识别等。
- **常见算法**：Apriori算法、KMeans算法、随机森林、主成分分析等。
### (3) 半监督学习
- **核心机制**：利用少量的标注样本和大量的未标识样本进行训练和分类。
- **主要目的**：减少标注代价、提高学习能力。
- **算法流程**：首先试图对未标识数据进行建模，在此基础上再对标识的数据进行预测。
- **举例**：图论推理算法或者拉普拉斯支持向量机等。
### (4) 强化学习
- **核心机制**：学习从环境状态到行为的映射，使得智能体选择的行为能够获得环境的最大奖赏，最终目标是使外部环境对系统在某种意义下的评价最佳。
- **成功应用领域**：机器人控制、无人驾驶、工业控制等。
- **常见算法**：Q-Learning、时间差学习等。
### 按照学习方法的不同分类
机器学习可分为传统机器学习和深度学习。区别在于，传统机器学习的领域特征需要手动完成，且需要大量领域专业知识；深度学习不需要人工特征提取，但需要大量的训练数据集以及强大的GPU服务器来提供算力。
#### (1) 传统机器学习
- **核心定义**：从一些观测（训练）样本出发，试图发现不能通过原理分析获得的规律，实现对未来数据行为或趋势的准确预测。
- **应用领域**：自然语言处理、语音识别、图像识别、信息检索等许多计算机领域获得了广泛应用。
#### (2) 深度学习
- **核心定义**：是一种基于多层神经网络并以海量数据作为输入规则的自学习方法，依靠提供给它的大量实际行为数据（训练数据集），进行参数和规则调整。
- **核心特点**：深度学习更注重特征学习的重要性。
# 14.2 人工智能技术概述 - 14.2.2 人工智能关键技术
## 6. 机器学习 (ML) （续）
### 其他常见机器学习算法
机器学习的常见算法还包括迁移学习、主动学习和演化学习。
#### (1) 迁移学习
- **核心机制**：当在某些领域无法取得足够多的数据进行模型训练时，利用另一领域数据获得的关系进行的学习。
- **应用场景**：主要在变量有限的小规模应用中使用，如基于传感器网络的定位、文字分类和图像分类等。
#### (2) 主动学习
- **核心机制**：通过一定的算法查询最有用的未标记样本，并交由专家进行标记，然后用查询到的样本训练分类模型来提高模型的精度。
#### (3) 演化学习
- **核心机制**：基于演化算法提供的优化工具设计机器学习算法，针对机器学习任务中存在的大量复杂的优化问题。
- **应用范围**：应用于分类、聚类、规则发现、特征选择等机器学习与数据挖掘问题中。
- **算法流程**：算法通常维护一个解的集合，并通过启发式算子来从现有的解产生新解，并通过挑选更好的解进入下一次循环，不断提高解的质量。
## 人工智能目前典型应用
- ChatGPT
# 14.3 机器人技术 - 14.3.2 机器人4.0的核心技术
## 1. 云-边-端的无缝协同计算
- **系统架构**：面向大规模机器人的服务平台，信息处理和生成主要在云-边-端上分布处理完成。
- **职责分工**：
- **云侧**：提供高性能的计算和知识存储。
- **边缘侧**：进一步处理数据并实现协同和共享。
- **机器人端**：只用完成实时操作的功能。
## 2. 持续学习与协同学习
- **核心目标**：希望机器人可以通过少量数据来建立基本的识别能力。
- **运行机制**：
- 自主地去找到更多的相关数据并进行自动标注。
- 用这些自主得到的数据来对自己已有的模型进行重新训练来提高性能。
## 3. 知识图谱
- **核心需求**：
- 需要更加动态和个性化的知识。
- 需要和机器人的感知与决策能力相结合。
## 4. 场景自适应
- **核心机制**：主动观察场景内人和物之间的变化，预测可能发生的事件，从而影响之后的行动模式。
- **关键问题**：场景预测能力。
- **实现过程**：机器人通过对场景内的各种人和物进行细致的观察，结合相关的知识和模型进行分析，并预测之后事件即将发生的时间，改变自己的行为模式。
## 5. 数据安全
- **基本要求**：既要保证端到端的安全传输，也要保障服务器端的安全存储。
# 14.3 机器人技术 - 14.3.3 机器人的分类
## 1. 按照要求的控制方式分类
机器人可分为操作机器人、程序机器人、示教再现机器人、智能机器人和综合机器人。
- **(1) 操作机器人**
- **典型代表**：在核电站处理放射性物质时远距离进行操作的机器人。
- **(2) 程序机器人**
- **特点**：可以按预先给定的程序、条件、位置进行作业。
- **(3) 示教再现机器人**
- **工作原理**：机器人可以将所教的操作过程自动地记录在磁盘、磁带等存储器中，当需要再现操作时，可重复所教过的动作过程。
- **示教方法**：有直接示教与遥控示教两种。
- **(4) 智能机器人**
- **特点**：既可以进行预先设定的动作，还可以按照工作环境的改变而变换动作。
- **(5) 综合机器人**
- **构成**：由操纵机器人、示教再现机器人、智能机器人组合而成的机器人（如火星机器人）。
- **系统视角**：整个系统可以看作是由地面指令操纵的操作机器人。
## 2. 按照应用行业来分
机器人可分为工业机器人、服务机器人和特殊领域机器人。
# 14.4 边缘计算 - 14.4.1 边缘计算的概念
## 1. 核心定义
- **本质**：将数据的处理、应用程序的运行甚至一些功能服务的实现，由网络中心下放到网络边缘的节点上（靠近物或数据源的位置）。
- **工作方式**：在网络边缘侧的智能网关上就近采集并且处理数据，不需要将大量未处理的原生数据上传到远处的大数据平台。
## 2. 优势与应用价值
- **处理效率**：海量数据能够就近处理，大量的设备也能实现高效协同的工作。
- **解决痛点**：诸多问题迎刃而解。
- **满足的关键需求**：理论上可满足许多行业在敏捷性、实时性、数据优化、应用智能，以及安全与隐私保护等方面的关键需求。
# 14.4 边缘计算 - 14.4.2 边缘计算的定义
## 1. 业务本质与核心方向
- **本质**：云计算在数据中心之外汇聚节点的延伸和演进。
- **三大落地形态**：
- 云边缘
- 边缘云
- 云化网关
- **核心能力发展方向**：
- “边云协同”
- “边缘智能”
- **平台能力要求**：
- **软件平台**：需考虑导入云理念、云架构、云技术，提供端到端实时、协同式智能、可信赖、可动态重置等能力。
- **硬件平台**：需考虑异构计算能力。
## 2. 具体形态解析
- **(1) 云边缘**：
- **定义**：云服务在边缘侧的延伸，逻辑上仍是云服务。
- **主要能力**：提供依赖于云服务或需要与云服务紧密协同。
- **(2) 边缘云**：
- **定义**：在边缘侧构建中小规模云服务能力。
- **主要能力**：边缘服务能力主要由边缘云提供。
- **(3) 云化网关**：
- **定义**：以云化技术与能力重构原有嵌入式网关系统。
- **核心能力**：在边缘侧提供协议/接口转换、边缘计算等能力。
- **配套管理**：部署在云侧的控制器提供边缘节点的资源调度、应用管理与业务编排等能力。
# 14.4 边缘计算 - 14.4.3 边缘计算的特点
## 1. 联接性
- **基础性**：联接性是边缘计算的基础。
- **核心要求**：由于所联接物理对象的多样性及应用场景的多样性，需要边缘计算具备丰富的联接功能。
## 2. 数据第一入口
- **桥梁作用**：作为物理世界到数字世界的桥梁。
- **数据特征**：拥有大量、实时、完整的数据。
- **价值创造**：可基于数据全生命周期进行管理，更好地支撑预测性维护、资产效率与管理等创新应用。
## 3. 约束性
- **环境适应性**：需适配工业现场相对恶劣的工作条件与运行环境（如防电磁、防尘、防爆、抗振动、抗电流/电压波动等）。
- **资源限制**：在工业互联场景下，对边缘计算设备的功耗、成本、空间有较高的要求。
## 4. 分布性
- **部署特征**：实际部署天然具备分布式特征。
- **能力要求**：
- 支持分布式计算与存储。
- 实现分布式资源的动态调度与统一管理。
- 支撑分布式智能。
- 具备分布式安全等能力。
# 14.4 边缘计算 - 14.4.4 边云协同
## 1. 边云协同概述
- **优势互补**：
- **云计算**：擅长全局性、非实时、长周期的大数据处理与分析，在长周期维护、业务决策支撑等领域发挥优势。
- **边缘计算**：适用局部性、实时、短周期数据的处理与分析，能更好地支撑本地业务的实时智能化决策与执行。
## 2. 双向支撑关系
- **边缘支撑云端**：边缘计算靠近执行单元，是云端所需高价值数据的采集和初步处理单元，可更好地支撑云端应用。
- **云端反哺边缘**：云计算通过大数据分析优化输出的业务规则或模型可以下发到边缘侧，边缘计算基于新的业务规则或模型运行。
## 3. 主要协同方式
主要包括以下六种协同：
- **(1) 资源协同**
- **基础设施**：边缘节点提供计算、存储、网络、虚拟化等基础设施资源。
- **管理能力**：具有本地资源调度管理能力，同时可与云端协同，接受并执行云端资源调度管理策略（包括设备管理、资源管理以及网络连接管理）。
- **(2) 数据协同**
- **数据采集**：边缘节点主要负责现场/终端数据的采集。
- **数据处理**：按照规则或数据模型对数据进行初步处理与分析，并将处理结果以及相关数据上传给云端；云端提供海量数的存储、分析与价值挖掘。
- **(3) 智能协同**
- **边缘侧**：按照AI模型执行推理，实现分布式智能。
- **云端**：开展AI的集中式模型训练，并将模型下发至边缘节点。
- **(4) 应用管理协同**
- **边缘侧**：提供应用部署与运行环境，并对本节点多个应用的生命周期进行管理调度。
- **云端**：主要提供应用开发、测试环境，以及应用的生命周期管理能力。
- **(5) 业务管理协同**
- **边缘侧**：提供模块化、微服务化的应用/数字孪生/网络等应用实例。
- **云端**：主要提供按照客户需求实现应用/数字孪生/网络等的业务编排能力。
- **(6) 服务协同**
- **边缘侧**：按照云端策略实现部分ECSaaS服务，通过ECSaaS与云端SaaS的协同实现面向客户的按需SaaS服务。
- **云端**：主要提供SaaS服务在云端和边缘节点的服务分布策略，以及云端分担的SaaS服务能力。
## 4. 边缘计算的应用场合
- 智慧园区
- 安卓云与云游戏
- 视频监控
- 工业互联网
- Cloud VR
# 14.5 数字孪生体技术概述 - 14.5.1 数字孪生体的定义
## 1. 技术定位
- **桥梁作用**：数字孪生体技术是跨层级、跨尺度的现实世界和虚拟世界建立沟通的桥梁。
## 2. 核心定义
- **基本属性**：数字孪生体是现有或将有的物理实体对象的数字模型。
- **运行机制**：
- **感知与调控**：通过实测、仿真和数据分析来实时感知、诊断、预测物理实体对象的状态；通过优化和指令来调控物理实体对象的行为。
- **自我进化**：通过相关数字模型间的相互学习来进化自身。
- **价值目标**：改进利益相关方在物理实体对象生命周期内的决策。
# 14.5 数字孪生体技术概述 - 14.5.2 数字孪生体的关键技术
## 1. 核心技术概览
- **三项关键技术**：
1. 建模
2. 仿真
3. 基于数据融合的数字线程
## 2. 建模
- **目的**：将我们对物理世界的理解进行简化和模型化。
- **本质/目标**：通过数字化和模型化，用信息换能量，以使少的能量消除各种物理实体（特别是复杂系统）的不确定性。
- **技术体系三维空间**：
- 需求指标
- 生存期阶段
- 空间尺度
## 3. 仿真
- **核心作用**：
- 验证和确认建模理解的正确性和有效性。
- 创建和运行数字孪生体，保证数字孪生体与对应物理实体实现有效闭环的核心技术。
- **定义**：将包含了确定性规律和完整机理的模型转化成软件的方式来模拟物理世界的一种技术。
- **前提与效果**：只要模型正确，并拥有了完整的输入信息和环境数据，就可以基本准确地反映物理世界的特性和参数。
# 14.5 数字孪生体技术概述 - 14.5.2 数字孪生体的关键技术
## 1. 核心技术概览
- **三项关键技术**：
1. 建模
2. 仿真
3. 基于数据融合的数字线程
## 2. 建模
- **目的**：将我们对物理世界的理解进行简化和模型化。
- **本质/目标**：通过数字化和模型化，用信息换能量，以使少的能量消除各种物理实体（特别是复杂系统）的不确定性。
- **技术体系三维空间**：
- 需求指标
- 生存期阶段
- 空间尺度
## 3. 仿真
- **核心作用**：
- 验证和确认建模理解的正确性和有效性。
- 创建和运行数字孪生体，保证数字孪生体与对应物理实体实现有效闭环的核心技术。
- **定义**：将包含了确定性规律和完整机理的模型转化成软件的方式来模拟物理世界的一种技术。
- **前提与效果**：只要模型正确，并拥有了完整的输入信息和环境数据，就可以基本准确地反映物理世界的特性和参数。
## 3. 其他技术（内外围核心技术）
除了核心的建模仿真技术，以下技术仍为数字孪生体构建过程中的内外围核心技术：
- **交互与可视化技术**：VR（虚拟现实）、AR（增强现实）、MR（混合现实）。
- **数据集成与管理技术**：数字线程。
- **系统工程方法论**：系统工程、MBSE（基于模型的系统工程）。
- **底层支撑技术**：物联网、云计算、雾计算、边缘计算。
- **数据处理与分析技术**：大数据技术、机器学习。
- **信任与安全技术**：区块链技术。
## 4. 主要应用领域
数字孪生体主要应用于以下领域：
- 制造
- 产业
- 城市
- 战场
# 14.6 云计算和大数据技术概述 - 14.6.1 云计算
## 1. 概念内涵
云计算的概念包含两个核心方面：
- **平台（基础设施）**：地位相当于PC上的操作系统，云计算应用程序需要构建在平台之上。
- **应用**：云计算应用所需的计算与存储通常在“云端”完成，客户端需要通过互联网访问计算与存储能力。
## 2. 云计算的服务方式（服务模式）
- **(1) 软件即服务 (SaaS)**
- **特点**：服务提供商将应用软件统一部署在云计算平台上。
- **使用方式**：客户通过互联网订购服务，按需使用。
- **收费模式**：根据订购软件的数量、时间长短等因素收费。
- **访问方式**：通过标准浏览器提供服务。
- **(2) 平台即服务 (PaaS)**
- **特点**：提供商将分布式开发环境与平台作为一种服务来提供。
- **包含内容**：开发环境、服务器平台、硬件资源等。
- **客户操作**：在平台基础上定制开发自己的应用程序，并通过服务器和互联网传递给其他客户。
- **(3) 基础设施即服务 (IaaS)**
- **特点**：提供商将多台服务器组成的“云端”基础设施作为服务提供给客户。
- **具体服务**：提供整合的虚拟资源池，包括内存、I/O设备、存储和计算能力等。
## 3. 服务模式特征分析
- **灵活性**：SaaS → PaaS → IaaS 灵活性依次增强。（IaaS灵活性最高，SaaS最低）
- **方便性**：IaaS → PaaS → SaaS 方便性依次增强。（SaaS最方便，IaaS最低）
## 4. 云计算的部署模式
- **(1) 公有云**
- **定义**：云基础设施是公开的，可以自由分配给公众。
- **管理者**：企业、学术界与政府机构都可以拥有和管理公用云。
- **优势**：以低廉价格为用户提供有吸引力的服务，创造新的业务价值。
- **(2) 社区云**
- **定义**：云基础设施分配给一些共同关注特定任务、安全需求、政策等信息的社区组织所专有。
- **管理者**：被社区内的一个或多个组织所拥有、管理及操作。
- **归属**：属于“公有云”范畴内的一个组成部分。
- **(3) 私有云**
- **定义**：云基础服务设施分配给由多种用户组成的单个组织。
- **管理者**：可以被这个组织或其他第三方组织所拥有、管理及操作。
- **(4) 混合云**
- **定义**：公有云、私有云和社区云的组合。
- **使用原因**：由于安全和控制原因，并非所有企业信息都能放置在公有云上，因此企业会使用混合云模式。
# 14.6 云计算和大数据技术概述 - 14.6.2 大数据
## 1. 定义
- **大数据**：是指其大小或复杂性无法通过现有常用的软件工具，以合理的成本并在可接受的时限内对其进行捕获、管理和处理的数据集。
- **面临困难**：包括数据的收入（采集）、存储、搜索、共享、分析和可视化。
## 2. 特点
- 大规模
- 高速度
- 多样化
- 价值密度低
- 可变性
- 复杂性
## 3. 大数据分析的步骤（5个主要阶段）
1. **数据获取和记录**
2. **信息抽取和清洗**
3. **数据集成、聚集和表示**
4. **查询处理、数据建模和分析**
5. **解释**
## 4. 应用领域
- 制造业
- 服务业
- 交通行业
- 医疗行业
# AI芯片
## 1. AI芯片的概念
- **定义**：AI芯片是一种特制的微处理器，专门为高效运行人工智能算法而设计。
- **核心目标**：致力于解决AI应用中的大规模并行计算问题。
- **主要应用场景**：针对神经网络模型的密集型数学运算，如矩阵乘法、卷积操作和激活函数计算等。
## 2. AI芯片的原理
- **核心基础**：基于人工神经网络，芯片内部的**处理单元**模拟了生物神经元的工作机制。
- **运算机制**：每个处理单元能够独立进行复杂的数学运算，例如权重乘以输入信号并累加，形成神经元的激活输出。
- **关键组件**：激活函数决定了信号如何转化为有意义的结果，它是AI芯片中不可或缺的一部分。
## 3. AI芯片的硬件架构
AI芯片的硬件架构多种多样，根据其设计目标和应用场景，主要分为以下几类：
### (1) GPU (图形处理器)
- **发展背景**：原本主要用于图形渲染。
- **当前应用**：因其并行计算能力强，被广泛用于训练大型深度学习模型，尤其擅长处理浮点数密集型计算任务。
- **主要特点**：计算能力强，成本高、功耗高。
### (2) FPGA (现场可编程门阵列)
- **核心特性**：具有高度灵活的可编程性，能够在硬件层面快速重新配置以适应不同的AI算法。
- **适用场景**：适用于早期开发阶段和动态工作负载的场景。
- **主要特点**：可编程、高度灵活、计算能力不强。
### (3) ASIC (专用集成电路)
- **定义**：为特定AI任务定制的芯片。
- **性能对比**：相较于GPU和FPGA，它在特定应用中的计算效率更高，能耗更低，但缺乏通用性。
- **主要特点**：体积小、功耗低、适合量产，但是研发时间长，且不可编辑，前期投入成本高，带来一定的技术风险。
### (4) TPU (张量处理单元)
- **背景**：Google推出的ASIC实例，专门针对机器学习任务设计。
- **功能特性**：专注于高效的矩阵运算，尤其适合TensorFlow框架下的深度学习模型。
- **主要特点**：高效的张量计算能力、功耗低、采用低精度计算。
# 15.1 标准化基础知识
## 1. 标准的分类
| 分类 | 内容 |
| :--- | :--- |
| **国际标准 (IS)** | 国际标准化组织 (ISO)、国际电工委员会 (IEC) 制定的标准，以及 ISO 出版的《国际标准题内关键词索引》所收录的其他国际组织制定的标准。 |
| **国家标准 (NB)** | **中国 (GB)**：中华人民共和国国家技术监督局**美国 (ANSI)**：美国国家标准协会**英国 (BS)**：英国标准学会**日本 (JIS)**：日本工业标准调查会 |
| **区域标准** | 太平洋地区标准会议 (PASC)欧洲标准化委员会 (CEN)亚洲标准咨询委员会 (ASAC)非洲地区标准化组织 (ARSO) |
| **行业标准** | 美国电气和电子工程师学会标准 (IEEE)中华人民共和国国家军用标准 (GJB)美国国防部标准 (DOD-STD)美国军用标准 (MIL-S) |
| **企业（机构）标准** | 供公司内部使用。 |
| **项目（课题）标准** | 计算机集成制造系统 (CIMS) 的软件工程规范。 |
# 15.1 标准化基础知识
## 2. 标准的代号和编号
| 标准类型 | 编号规则 |
| :--- | :--- |
| **国际标准** | `ISO`+标准号+[`-`+分标准号]+`:`+发布年号*(注：方括号中的内容可有可无)* |
| **国家标准** | **格式**：国家标准的代号+标准发布顺序号-标准发布年代号（4位）**我国代号**：• `GB`：强制性国家标准• `GB/T`：推荐性国家标准 |
| **行业标准** | **格式**：行业标准的代号（强制或推荐）+标准发布顺序号-标准发布年代号（4位）**常见代号示例**：• `QJ`：航天• `SJ`：电子• `JB`：机械• `JR`：金融系统 |
| **地方标准** | `DB`+行政区域代码（前两位）`/`(强制或推荐)+地方标准发布顺序号-标准发布年代号（4位） |
| **企业标准** | `Q`/企业代号+标准发布顺序号-标准发布年代号（4位） |
# 15.2 知识产权基础知识 - 15.2.1 基本概念
## 1. 定义
- **知识产权**：是指民事权利主体（公民、法人）基于创造性的**智力成果**。
## 2. 保护对象
根据国际公约，知识产权的保护对象包括：
1. 文学、艺术和科学作品；
2. 表演艺术家的表演，以及唱片和广播节目；
3. 人类一切活动领域的发明；
4. 科学发现；
5. 工业品外观设计；
6. 商标、服务标记、商业名称和标志；
7. 制止不正当竞争；
8. 在工业、科学、文学艺术领域内由于智力创造活动而产生的一切其他权利。
- **补充内容**：根据世贸协议，知识产权还包括“未披露过的信息专有权”，即**商业秘密**。
## 3. 分类
### (1) 工业产权
- 专利、实用新型、工业品外观设计
- 商标、服务标记、厂商名称
- 产地标记或原产地名称
- 制止不正当竞争、商业秘密
- 微生物技术和遗传基因技术等
### (2) 著作权（版权）
1. **人身权（精神权利）**：发表权、署名权、修改权、保护作品完整权。
2. **财产权（经济权利）**：使用权、获得报酬权。
# 15.2.2 计算机软件著作权
## 知识产权保护期限
| 客体类型 | 权利类型 | 保护期限 |
| :--- | :--- | :--- |
| **公民作品** | 署名权、修改权、保护作品完整权 | 无限制 |
| | 发表权、使用权和获得报酬权 | 作者终生及其死后50年（第50年的12月31日） |
| **单位作品** | 发表权、使用权和获得报酬权（属于集体，无署名权、修改权等） | 50年（首次发表后的第50年的12月31日），若期间未发表，不保护 |
| **公民软件产品** | 署名权、修改权 | 无限制 |
| | 发表权、复制权、发行权、出租权、信息网络传播权、翻译权、使用许可权、获得报酬权、转让权 | 作者终生及其死后50年（第50年的12月31日），合作开发的，以最后死亡作者为准 |
| **单位软件产品** | 发表权、复制权、发行权、出租权、信息网络传播权、翻译权、使用许可权、获得报酬权、转让权 | 50年（首次发表后的第50年的12月31日），若期间未发表，不保护 |
| **注册商标** | | 有效期10年（若注册人死亡或倒闭1年后，未转移则可注销；期满后6个月内必须续注） |
| **发明专利权** | | 保护期为20年（从申请日开始） |
| **实用新型和外观设计专利权** | | 保护期为10年（从申请日开始） |
| **商业秘密** | | 不确定，公开后公众可用 |
# 15.2.2 计算机软件著作权
## 单位和个人的知识产权归属判定
| 情况说明 | | 判断说明 | 归属 |
|----------|--------|--------------------------------------------------------------------------|--------------------------------------------|
| 作品 | 职务作品 | 利用单位的物质技术条件进行创作，并由单位承担责任的 | 除署名权外，其他著作权归单位 |
| | | 合同明确约定其著作权属于单位 | 除署名权外，其他著作权归单位 |
| | | 其他 | 作者拥有著作权，单位有权在业务范围内优先使用 |
| 软件 | 职务作品 | 属于本职工作中明确规定的开发目标 | 单位享受著作权 |
| | | 属于从事本职工作活动的结果 | 单位享受著作权 |
| | | 使用了单位资金、专用设备、未公开的信息等物质、技术条件，并由单位或组织承担责任的软件 | 单位享受著作权 |
| 专利权 | 职务作品 | 本职工作中作出的发明创造 | 单位享受专利权 |
| | | 履行本单位交付的本职工作之外的任务所作出的发明创造 | 单位享受专利权 |
| | | 离职、退休或调动工作后一年内，与原单位工作相关 | 单位享受专利权 |
# 15.2.2 计算机软件著作权
## 委托知识产权归属判定
|情况说明| 情况说明 | 判断说明 | 归属 |
|-|----------|----------|------|
|**作品软件**| 委托创作 | 合同中明确约定著作权归属委托方 | 委托方 |
| || 合同中未约定著作权归属 | 创作方 |
|| 合作开发 | 只进行组织、提供咨询意见、物质条件等辅助工作 | 不享有著作权 |
| | 共同创作的 | 共同享有，按人头比例。成果可分割的，可分开申请 |
| **商标** || 谁先申请谁拥有同时申请，则根据谁先使用谁拥有（需提供证据）无法提供证据，协商归属，协商无效时使用抽签决定 | |
| **专利** || 谁先申请谁拥有同时申请则协商归属，协商不成的，该发明成为社会共有技术 | |
# 15.2.2 计算机软件著作权
## 侵权的判定
1. 未经著作权人同意而发表或登记其软件作品。
2. 将他人软件当作自己的作品发表或登记。
3. 未经合作者同意将共同开发的软件当作自己的作品发表或登记。
4. 在他人开发的软件上署名或更改他人署名。
5. 未经著作权人或其合法受让者许可，修改、翻译、复制或部分复制、向公众发行或出租、办理权利许可或转让或通过网络传播其作品。
## 非侵权的判定
- **目的**：为了学习和研究软件内含的设计思想和原理。
- **行为**：通过安装、显示、传输或存储软件的方式使用软件。
- **条件**：可以不经许可，不支付报酬。
# 16.1 线性规划
## 1. 定义
线性规划是研究在**有限的资源**条件下，如何有效地使用这些资源以达到预定目标的数学方法。其核心是**在一组线性约束条件下，求一个线性目标函数的极值**（极大值或极小值）。
## 2. 数学模型的三个组成部分
一个线性规划问题的数学模型由以下三部分构成：
1. **线性目标函数**：需要最大化或最小化的线性表达式。
2. **线性约束条件**：一组线性不等式或等式，表示资源的限制。
3. **变量非负条件**：决策变量通常表示实际数量，因此取值非负。
## 3. 基本概念
- **线性规划问题**：求一组**非负变量**，使其满足给定的**线性约束条件**，并使某个**线性目标函数**达到极值。
- **可行解**：满足所有约束条件（包括非负条件）的一组变量值。
- **可行解域 (可行域)**：所有可行解组成的集合。
- **最优解**：使目标函数达到极值（最大值或最小值）的可行解。
## 4. 最优解的可能情况
线性规划问题的最优解可能存在以下四种情况：
- **无可行解**：约束条件互相矛盾，不存在满足所有条件的解。
- **无最优解 (解无界)**：可行域无界，且目标函数值可以无限增大（求最大时）或无限减小（求最小时）。
- **唯一最优解**：存在且仅有一个可行解使目标函数达到极值。
- **无穷多最优解**：存在无穷多个可行解都能使目标函数达到同一个极值。
## 5. 快速解题步骤（图解法/求交点法）
对于两个决策变量的线性规划问题，可在平面直角坐标系中用“求交点法”（图解法）快速求解：
1. **列不等式**：根据题意，列出所有约束不等式（组）。
2. **求交点**：
- 将每个不等式暂时视为等式，画出对应的直线。
- 将所有直线两两联立求解，得到一系列交点坐标。
3. **验证与计算**：
- 筛选出同时满足**所有约束不等式**（即落在可行域内）的交点。
- 将这些可行交点的坐标分别代入**目标函数**进行计算。
- 比较各点的目标函数值，其最大（或最小）值所对应的点即为**最优解**。
- *注：若最优解坐标出现小数等不符合实际问题的情况（如人数），需在附近取满足条件的整数值。*
# 16.5 决策论
## 1. 定义
决策论是研究为了达到预期目的，从多个可供选择的方案中如何选取**最好或满意方案**的学科。
## 2. 决策的六个要素
1. **决策者**
2. **可供选择的方案**（包括行动、策略）
3. **衡量选择方案的准则**（目的、目标、正确性等）
4. **事件**（被决策的对象）
5. **每一事件的发生将会产生的某种结果**
6. **决策者的价值观**
## 3. 决策论的分类
| 决策类型 | 环境状态 | 结果与概率特征 | 说明 |
| :--- | :--- | :--- | :--- |
| **确定型决策** | 确定 | 结果是确定的 | 在已知的、确定的环境条件下进行选择。 |
| **风险决策** | 不确定 | 结果不确定，但**各结果发生的概率已知（一致）** | 在知道各种可能结果及其发生概率的情况下进行决策。 |
| **不确定型决策** | 不确定 | 结果不确定，且**概率未知** | 完全依赖决策者的主观判断、经验和倾向进行选择。 |
# 16.5 决策论：不确定型决策的五种方案
## 1. 乐观主义准则 (Maximax)
- **核心逻辑**：大中取大 `max(max)`
- **操作步骤**：
1. 先找出每个方案在所有自然状态下**最大的收益**。
2. 再从这些最大收益中选出**最大的那个**对应的方案。
- **特点**：对未来充满信心，追求最好结果中的最好。
## 2. 悲观主义准则 (Maximin)
- **核心逻辑**：小中取大 `max(min)`
- **操作步骤**：
1. 先找出每个方案在所有自然状态下**最小的收益**。
2. 再从这些最小收益中选出**最大的那个**对应的方案（即最差方案里挑最好的）。
- **特点**：保守稳健，不指望运气，确保在最坏情况下损失最小。
## 3. 折中主义准则 (Hurwicz)
- **核心逻辑**：引入折中系数 $\alpha$ (alpha)
- **计算公式**：
$$折中收益 = \text{最大收益} \times \alpha + \text{最小收益} \times (1-\alpha)$$
- **操作步骤**：
1. 设定一个折中系数 $\alpha$（$0 \le \alpha \le 1$）。
2. 计算每个方案的折中收益。
3. 选择计算结果**最大**的那个方案。
- **特例**：
- 当 $\alpha = 1$ 时，即为**乐观主义准则**。
- 当 $\alpha = 0$ 时，即为**悲观主义准则**。
## 4. 等可能性准则 (Laplace)
- **核心逻辑**：假设每种自然状态发生的概率相等。
- **操作步骤**：
1. 设定每个可能结果的发生是等可能的（即赋予相同的概率）。
2. 将不确定型问题转化为**风险决策问题**，计算各方案的期望收益。
3. 选择期望收益**最大**的方案。
- **特点**：基于概率论的公平原则，避免主观偏见。
## 5. 后悔值准则 (Minimax Regret)
- **核心逻辑**：最小最大后悔值 `min(max)`
- **关键概念**：后悔值 = 该状态下的最大收益 - 该方案在该状态下的收益
- **操作步骤**：
1. 计算各个方案在每种情况下的**后悔值**。
2. 找出每个方案在各种情况下产生的**最大后悔值**。
3. 从这些最大后悔值中选出**最小**的一个，该值对应的策略即为所选策略。
- **特点**：着眼于机会损失，力求避免因决策失误而产生的最大懊悔。
# Web系统设计 - Web应用技术分类
| 维度 | 涉及技术内容 |
| :--- | :--- |
| **从架构来看** | MVC, MVP, MVVM, REST, Webservice, 微服务 |
| **从缓存来看** | MemCache, Redis, Squid |
| **从并发分流来看** | 集群 (负载均衡), CDN |
| **从数据库来看** | 主从库 (主从复制), 内存数据库, 反规范化技术, NoSQL, 分区 (分表) 技术, 视图与物化视图 |
| **从持久化来看** | Hibernate, Mybatis |
| **从分布存储来看** | Hadoop, FastDFS, 区块链 |
| **从数据编码看** | XML, JSON |
| **从Web应用服务器来看** | Apache, Tomcat, JBOSS, IIS, WebSphere, Weblogic |
| **其它** | 有状态与无状态, 响应式Web设计等 |
# 微服务
## 1. 定义
微服务架构将一个大型的单个应用或服务划分成一组微型、可独立部署的服务。微服务架构围绕业务领域将服务进行拆分，每个服务可以独立进行开发、管理和迭代，彼此之间使用统一接口进行交流，实现了在分散组件中的部署、管理与服务功能，使产品交付变得更加简单，从而达到有效拆分应用，实现敏捷开发与部署的目的。
## 2. 架构图解
- **顶层**：客户需求
- **中间层**：用户接口层
- **底层**：服务组件（由多个模块组成）
- **整体标注**：微服务架构
## 3. 微服务的优势
1. **复杂应用解耦**
- 微服务架构将单一模块应用分解为多个微服务，同时保持总体功能不变。
2. **独立**
- 每个微服务可进行独立开发与部署，并具备独立的运行进程。
3. **技术选型灵活**
- 开发团队可根据自身应用的业务需求发展状况选择合适的体系架构与技术。
4. **容错**
- 由于各个微服务相互独立，故障会被隔离在单个服务中，并且其他微服务可通过重试、平滑退化等机制实现应用层的容错，从而提高系统应用的容错性。
5. **松耦合，易扩展**
- 微服务架构中每个服务之间都是松耦合的，可以根据实际需求实现独立扩展，体现微服务架构的灵活性。
## 4. 微服务架构带来的挑战
1. **并非所有的系统都能转成微服务**
- 例如一些数据库层的底层操作是不推荐服务化的。
2. **部署较以往架构更加复杂**
- 系统由众多微服务搭建，每个微服务需要单独部署，从而增加部署的复杂度，容器技术能够解决这一问题。
3. **性能问题**
- 由于微服务注重独立性，互相通信时只能通过标准接口，可能产生延迟或调用出错。例如一个服务需要访问另一个服务的数据，只能通过服务间接口来进行数据传输，如果是频繁访问，则可能带来较大的延迟。
4. **数据一致性问题**
- 作为分布式部署的微服务，在保持数据一致性方面需要比传统架构更加困难。
# Lambda架构
Lambda架构是一种大数据处理架构，其核心特点是通过**批处理层**和**速度层**的分离，来同时满足对历史数据的**高准确性**和对实时数据的**低延迟性**需求。
其主要特点可概括为：
1. **分层处理**：架构清晰分为三层。
* **批处理层**：处理所有历史数据，生成准确但高延迟的“批处理视图”。
* **速度层**：处理实时增量数据，生成快速但可能近似的“实时视图”以弥补批处理层的延迟。
* **服务层**：合并批处理视图和实时视图的结果，对外提供统一的数据查询服务。
2. **容错性强**：批处理层的数据通常是不可变的，并保留完整历史，任何错误都可以通过重新计算来修正，系统设计上**天生容错**。
3. **可扩展性好**：批处理和实时处理两套系统可以独立扩展，以适应不同的数据量和计算需求。
简单来说，Lambda架构用“批处理保准确，实时处理保速度”的思路，平衡了大数据处理中**准确性**、**延迟**和**容错性**这三个核心诉求。
# Kappa架构
Kappa架构是作为对Lambda架构的简化而提出的，其核心思想是：**只保留流处理层，通过让流处理系统具备重播历史数据的能力，来统一处理实时数据和批量数据，从而用一套技术栈解决所有问题。**
### 核心原理
1. **单一处理层**：摒弃独立的批处理层，所有数据（无论是历史数据还是实时数据）都作为流来处理。
2. **不可变日志作为唯一数据源**：所有原始数据都被持久化到一个具有高吞吐量、可重播的**消息日志系统**中（如Apache Kafka）。这个日志是系统的“唯一真相源”。
3. **流计算处理一切**：流处理引擎（如Apache Flink、Spark Streaming）消费这个日志流。当需要全量重新计算或处理历史数据时，就从头或从某个时间点开始重新消费日志中的数据，进行“重播计算”。
4. **输出服务视图**：流处理引擎将计算结果直接输出到下游的数据库或服务层，供查询使用。
### 与Lambda架构的对比
| 特性 | Lambda架构 | Kappa架构 |
| :--- | :--- | :--- |
| **核心思想** | 批流分离，用批处理保证准确性，用流处理保证低延迟。 | 流处理统一，通过数据重播来满足全量计算需求。 |
| **处理层** | 两套：批处理层 + 速度层。 | 一套：强大的流处理层。 |
| **数据源** | 原始存储（如HDFS）+ 消息队列。 | **唯一的不可变日志**（如Kafka）。 |
| **代码复杂度** | **高**。需要为批处理和流处理开发两套逻辑，并保证结果一致。 | **低**。只需开发一套流处理逻辑。 |
| **运维成本** | **高**。需要维护两套独立的计算系统。 | **较低**。只需维护一套流处理系统。 |
| **计算延迟** | 批处理有高延迟，实时处理低延迟。 | 所有计算都是流式，可实现低延迟。 |
| **全量计算成本** | 批处理层定期进行，资源消耗大但成熟稳定。 | 通过流重播进行，可能消耗大量资源且对流处理引擎要求高。 |
### 优势和适用场景
* **优势**：
* **架构极大简化**：一套代码、一套系统，降低了开发和维护的复杂性。
* **逻辑一致**：避免了Lambda架构中批流代码不一致的问题。
* **真正的实时统一**：所有数据处理都是流式的，概念模型更统一。
* **适用场景**：
* 业务上对**实时性要求非常高**，且需要定期对历史数据进行修正或重新计算。
* 数据处理逻辑相对适合用流模型表达。
* 典型场景：实时推荐系统、实时欺诈检测、实时监控与报警等。
### 挑战与局限
* **流处理系统的压力**：所有计算负载（包括历史数据重算）都压在流处理系统上，要求它具备极高的吞吐量和状态管理能力。
* **长时间范围重播成本高**：如果需要重播非常长时间的历史数据（比如一年），耗时和资源消耗可能非常大，有时反而不如批处理高效。
* **对消息队列的强依赖**：要求消息队列（如Kafka）能长期存储海量历史数据，这带来了存储成本和运维复杂度。
**总结来说，Kappa架构通过“数据重播”这一核心机制，用一套流处理系统取代了Lambda的两套系统，实现了架构的简化。它非常适合实时性要求高、且愿意接受流处理统一模型的项目，但其可行性高度依赖于流处理引擎的能力和消息队列的存储规模。**
# 3DES 密钥与分组长度说明 (26年5月考到到这个知识点)
3DES（Triple DES）是一种基于 DES 的对称加密算法，其**分组长度固定为 64 位（8 字节）**，这一点由算法标准（FIPS 46）直接规定。
在密钥长度方面，3DES 通过对 DES 进行多次加密来提升安全性：DES 本身使用 64 位输入密钥，但其中包含 8 位奇偶校验位，因此**有效密钥长度为 56 位**。
3DES 分为两种模式——双密钥模式（2TDEA）和三密钥模式（3TDEA）：双密钥模式使用两个 56 位密钥，总有效长度为 **112 位**（输入 128 位，含校验位）；
三密钥模式使用三个 56 位密钥，总有效长度为 **168 位**（输入 192 位，含校验位）。在实际开发中，常会看到“3DES 密钥 168 位”和“192 位”两种说法，前者指有效密钥长度，后者指包含奇偶校验的输入长度。
由于 3DES 的分组长度仅为 64 位，存在 Sweet32 等攻击风险，且性能较低，**NIST 已于 2023 年底正式弃用该算法**，新系统应优先采用 **AES-128 或 AES-256**。
| 算法 | 分组长度 | 密钥长度 |
| :--- | :--- | :--- |
| DES | 64 bit | 56 bit |
| 3DES | 64 bit | 112 / 168 bit |
| AES | 128 bit | 128 / 192 / 256 bit |