架构是为完成某个特定任务所提供的软件规范，属于系统的顶层设计。
架构设计可分为：
进程间通信（IPC，Inter-Process Communication） 指至少两个进程或线程间传送数据或信号的一些技术或方法。进程是计算机系统分配资源的最小单位。每个进程都有自己的一部分独立的系统资源，彼此是隔离的。为了能使不同的进程互相访问资源并进行协调工作，才有了进程间通信。这些进程可以运行在同一计算机上或网络连接的不同计算机上。
IPC 技术包括：
IPC 是一种标准的 Unix 通信机制。
本地过程调用（LPC）
远程过程调用（RPC）
通过 IPC 和 RPC，程序能利用其它程序或计算机处理的进程。客户机/服务器模式计算把远程过程调用与消息传递等技术作为系统间通信的一种机制。
架构设计的主要目的是解决软件系统复杂度带来的问题。
单个网关扩展成多个后，需要将任务分发给不同的网关。常见方法包括：
高可用通过冗余备份和失效转移实现。
每个微服务都应具备以下能力：
Kafka 支持消息顺序，但一台 Broker 宕机后会产生消息乱序。
| 架构模式 | 核心思想 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 单体架构 | 所有功能高度耦合，集中部署 | 简单、直接 | 难维护、难扩展 | 小型应用或初期项目 |
| 分层架构 | 按职责水平分离，上层调用下层 | 结构清晰、易管理 | 易产生层级耦合 | 传统企业级应用 |
| 微服务架构 | 按业务拆分为自治服务，松耦合 | 弹性、可扩展、技术灵活 | 分布式系统复杂 | 复杂的大型系统 |
| 事件驱动架构 | 组件通过事件异步通信 | 高扩展性、高响应性 | 最终一致性、复杂度高 | 实时系统、数据流处理 |
| 微核架构 | 核心系统 + 插件模块，动态扩展 | 灵活性好、隔离性强 | 契约设计复杂 | IDE、浏览器、可扩展应用 |
| 无服务器架构 | 函数为单位，事件触发，云托管 | 零运维、按需付费 | 冷启动、厂商锁定 | 事件驱动、突发任务 |
| 云架构 | 云环境设计原则集合，多模式综合 | 全球部署、高可用性 | 云厂商依赖 | 需要横向扩展的现代应用 |
可以将分成4种:结构型、框架模型、动态模
型和过程模型。
| 架构风格 | 适用场景 |
|---|---|
| 管道-过滤器风格 | 用于将系统分成若干独立的步骤 |
| 主程序/子系统和面向对象的架构风格 | 用于对组件内部进行设计 |
| 虚拟机风格 | 用于构造解释器或专家系统 |
| C/S和B/S风格 | 适合于数据和处理分布在一定范围,通过网络连接构成系统 |
| 平台/插件风格 | 用于具有插件扩展功能的应用程序 |
| MVC风格 | 用于用户交互程序的设计 |
| SOA风格 | 用在企业集成等方面 |
| C2风格(Component-Connector（组件-连接器）架构风格) | 用于GUI软件开发,用以构建灵活和可扩展的应用系统等 |
| 特性维度 | 详细说明 |
|---|---|
| 全称 | Component-Connector（组件-连接器）架构风格 |
| 核心思想 | 通过严格的组件层级规则和异步消息机制实现松耦合 |
| 基本组成 | 组件（独立计算单元） + 连接器（消息路由组件） |
| 通信方式 | 组件间通过连接器进行异步消息通知（非直接调用） |
| 关键约束 | 1. 顶层组件不允许直接通信 2. 底层组件通信必须通过上层连接器 3. 组件间保持松耦合关系 |
| 主要优势 | • 极高的系统灵活性 • 良好的可扩展性 • 组件可独立替换和修改 • 支持并发处理 |
| 典型应用 | • GUI应用程序开发 • 需要高度灵活性的软件系统 • 可扩展应用框架 |
C2风格通过严格的分层消息传递机制，为GUI系统提供了高度灵活和可扩展的架构解决方案，特别适合需要频繁交互和动态扩展的图形化应用场景。
主要因素：目标、过程、数据
| 等级 | 失效状态 | 简要说明 | 目标数量 |
|---|---|---|---|
| A级 | 灾难性的 | 软件异常会导致的后果是：航空器无法安全飞行和着陆 | 66 |
| B级 | 危害性的 | 软件异常会导致的后果是：严重降低了航空器或机组在克服不利运行情况时的能力 | 65 |
| C级 | 严重的 | 软件异常会导致的后果是：显著降低了航空器或机组在克服不利运行情况时的能力 | 56 |
| D级 | 不严重的 | 软件异常会导致的后果是：轻微降低了航空器或机组在克服不利运行情况时的能力 | 28 |
| E级 | 没有影响的 | 软件异常会导致的后果是：不会影响航空器或机组任何能力 | 0 |
将生命周期中产生的文档、代码、报表、记录等所有产品统称为软件生命周期数据。
C = B*log_{2}(1+S/N)
| 视图 | 要点描述 | 图形表示 | 关心人员 |
|---|---|---|---|
| 用例视图 | 描述系统的功能需求，系统功能模型 | 用例图 | 客户、分析者、设计者、开发者和测试者 |
| 逻辑视图 | 描述如何实现系统内部的功能，系统的静态结构和应发送消息而出现的动态协作关系 | 类图、对象图、状态图、顺序图、协作图和活动图 | 系统分析和设计人员 |
| 进程视图 | 描述系统的并发性，并处理这些线程间的通信和同步；它将系统分割成并发执行的控制线程及处理这些线程的通信和同步 | 状态图、顺序图、协作图、活动图、构件图和部署图 | 开发者和系统集成者 |
| 实现视图 | 描述系统代码构件组织和实现模块及它们之间的依赖关系 | 构件图 | 设计者、开发者和测试者 |
| 部署视图 | 定义系统中软硬件的物理体系结构及连接、哪个程序或对象驻留在哪台计算机上执行 | 部署图 | 开发者、系统集成者和测试者 |
注：用例视图是系统的中心视图，它定义了系统的外部行为，是其他视图的核心和基础。
媒体是承载信息的载体，即信息的表现形式（如文字、声音、图像、动画、视频等）。
媒体分为以下五类：
为了最好地实现系统，对系统组成要素、组织结构、信息流、控制机构等进行分析研究的科学方法
建模方法的形式化应用，以使建模方法支持系统需求、分析、设计、验证和确认等活动，这些活动从概念性设计阶段开始，持续贯穿到设计开发以及后来的所有生命周期阶段。
系统工程过程的三个阶段分别产生三种图形
需求分析阶段，产生需求图、用例图、包图
功能分析阶段与分配阶段，产生顺序图、活动图、状态机图
设计综合阶段，产生模块定义图、内部块图、参数图等
MBSE的三大支柱分别是建模语言、建模工具、建模思路。
加速比=未使用增强部件时执行时间/使用增强组件后的执行时间。
例：某一功能执行时间为整个系统运行时间的60%，若使改功能的处理速度提高五倍，根据阿姆达尔定律，整个系统的处理速度可以提高1.923倍。
\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²⁴ | 一亿亿亿次 | 远期未来概念 |
存储容量用1024（2¹⁰）作为进率，并创造了KiB、MiB等二进制单位，导致了长期的混淆。
如今，标准做法是：
存储容量：严格区分 SI十进制单位（KB, MB, GB， 基于1000）和 二进制单位（KiB, MiB, GiB， 基于1024）。硬盘厂商通常使用十进制，而操作系统可能显示为二进制。
| 特性 | OPS | FLOPS |
|---|---|---|
| 核心衡量对象 | 整数操作（如INT8, INT4） | 浮点数运算（如FP32, FP16, FP64） |
| 主要应用场景 | AI推理、专用加速芯片 （如NPU、TPU、自动驾驶芯片） |
科学计算、图形渲染、AI训练 （如CPU、GPU） |
| 关键特点 | 贴近AI模型的低精度整数计算，一次乘加(MAC)常计为2次操作，能直接反映AI任务执行速度。 | 衡量计算精度的传统标准，在需要高数值精度的场景中至关重要。 |
主要结论：
指进程在内存中的三种基本状态及其转换：
| 状态 | 说明 |
|---|---|
| 运行态 (Running) | 进程正在 CPU 上执行 |
| 就绪态 (Ready) | 进程已具备运行条件，等待分配 CPU |
| 阻塞态 (Blocked) | 进程因等待某事件（如 I/O）而暂停执行 |
在三态基础上增加 新建 (New) 与 终止 (Terminated) 状态，有时还包含 挂起 (Suspend) 相关状态（图中涉及中级调度与挂起）：
| 状态 | 说明 |
|---|---|
| 新建 | 进程刚被创建，尚未进入就绪队列 |
| 就绪 | 同三态模型 |
| 运行 | 同三态模型 |
| 阻塞 | 同三态模型 |
| 终止 | 进程执行结束，等待系统回收资源 |
三态模型是在内存中的模型，如果任务比较简单、数量少可以存储在内存中使用三态模型即可。 在多道程序的模型中使用五态模型更清晰，避免资源混乱。在内存、外存中分别存储活跃、不活跃的数据，这样可以加载更多的任务。
吞吐率 (Throughput) 指单位时间内流水线完成的任务数量。
公式：
吞吐率=指令条数/流水线执行时间
其中：
最大吞吐率是当任务数趋于无穷大时，流水线所能达到的极限吞吐率，也就是cycle(时钟周期（每段最长操作时间）)的倒数。
公式：
\(TP_{\max} = \lim_{n \to \infty} \frac{n}{(k + n - 1) \Delta t} = \frac{1}{\Delta t}\)
其中：
加速比 (Speedup) 用于衡量流水线相对于顺序执行带来的性能提升效果。
定义：
\(S = \frac{\text{不使用流水线执行时间}}{\text{使用流水线执行时间}}\)
超标量流水线是一种并行处理技术，通过重复设置多个功能部件，使得在一个时钟周期内可以并发执行多条指令。
关键点：
流水线的效率 (Efficiency) 反映了流水线中各部件的利用率。
定义： 流水线的设备利用率。在时空图上，效率 \(E\) 的计算公式为：
\(E = \frac{n\text{个任务占用的时空区}}{k\text{个流水段的总时空区}}\)
其中：
| 指令系统类型 | 指令 | 寻址方式 | 实现方式 | 其它 |
|---|---|---|---|---|
| CISC（复杂） | 数量多，使用频率相差很大、可变定长 | 多种寻址方式 | 微程序控制技术 | 周期长，指令直接在主存处理，执行速度慢 |
| RISC（精简） | 数量少，使用频率相近，定长格式，大部分为单周期指令，只有LOAD/Store操作内存 | 支持方式少 | 增加了通用寄存器；硬布线逻辑控制为主；适合采用流水线。 | 优化编译，对编译的要求高，支持高级语言 |
在数据中间加入几个校验码，码距均匀拉大，当某一位出错时，会引起几个校验位的数值发生变化
2^r>=r+m+1
如果满足不等式，那么理论上 k 个校验码就可以判断是哪一位出现了问题
校验码存放在 2^n 的位置（1、2、4、8等），其余位置为信息位。
1010进行海明编码D3 D2 D1 D0 = 1 0 1 0n = m + r = 7 位P1, P2, P3 放在 \(2^n\) 的位置，即第1、2、4位。注：有时校验位用\(P_i\)表示，有时用位置号表示，此处P4即校验位P3。
校验位负责监督其位置号在二进制表示中“某一位为1”的所有位置。
P1 (位置1，二进制001)：监督所有位置号二进制第0位为1的位置（即奇数位）。
D3(位3=1), D2(位5=0), D0(位7=0)P1 ⊕ D3 ⊕ D2 ⊕ D0 = 0P1 ⊕ 1 ⊕ 0 ⊕ 0 = 0 -> P1 = 1P2 (位置2，二进制010)：监督所有位置号二进制第1位为1的位置。
D3(位3=1), D1(位6=1), D0(位7=0)P2 ⊕ D3 ⊕ D1 ⊕ D0 = 0P2 ⊕ 1 ⊕ 1 ⊕ 0 = 0 -> P2 = 0P4/P3 (位置4，二进制100)：监督所有位置号二进制第2位为1的位置。
D2(位5=0), D1(位6=1), D0(位7=0)P4 ⊕ D2 ⊕ D1 ⊕ D0 = 0P4 ⊕ 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 ⊕ 1 ⊕ 0 ⊕ 0 = 0? 计算：1⊕1=0, 0⊕0=0, 0⊕0=0。正确，应为0。0 ⊕ 1 ⊕ 0 ⊕ 0 = 11 ⊕ 0 ⊕ 0 ⊕ 0 = 1组成错误字 S4 S2 S1 = 1 1 0 (二进制)，对应十进制为 6。
这表明第6位出错，将其取反即可纠正。
D1，从0纠正为1，得到正确码字 1 0 1 1 0 1 0。总结：通过三个校验位，该(7,4)海明码可以检测并纠正任意1位错误。
模2运算规则：
将生成多项式转换为二进制形式
G(x) = x^4 + x + 11·x^4 + 0·x^3 + 0·x^2 + 1·x^1 + 1·x^010011（5位）110101，G = 10011 (5位)11010100000011（4位）1101010011接收端用同样的生成多项式除接收到的数据
| 名称 | 多项式表示 | 二进制/十六进制 | 应用领域 |
|---|---|---|---|
| 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 |
| 错误类型 | 检测能力 |
|---|---|
| 单比特错误 | 100%检测 |
| 双比特错误 | 100%检测（如果生成多项式有(x+1)因子） |
| 奇数个错误 | 100%检测（如果生成多项式有(x+1)因子） |
| 突发错误 | 长度 ≤ (k-1) 的突发错误：100%检测 |
| 较长突发错误 | 长度 > (k-1) 的突发错误：检测概率 1-2⁻⁽ᵏ⁻¹⁾ |
注：
实际CRC计算可能包含以下参数：
crc32指令）T(x) = D(x)·x^k + R(x)T'(x) mod G(x) = 0 则正确| 工作方式 | 子类型 | 特点 |
|---|---|---|
| 程序控制（占用CPU时间最长） | 无条件传送 | I/O端口总是准备好，CPU在需要时，随时直接利用访问相应的I/O端口。 |
| 程序查询 | CPU必须不停地测试I/O设备的状态端口。CPU与I/O设备是串行工作的。 | |
| 中断 | — | 某个进程要启动某个设备时，CPU就向相应的设备控制器发出一条设备I/O启动指令，然后CPU又返回做原来的工作。CPU与I/O设备可以并行工作。 |
| DMA（直接内存存取） | — | 为了在主存与外设之间实现高速、批量数据交换而设置。通过DMA控制器直接进行批量数据交换，除了在数据传输开始和结束时，整个过程无须CPU的干预。 |
网络规划设计分为 5个核心阶段，按顺序推进，将需求逐步转化为可实施的物理网络：
需求分析 → 通信规范分析 → 逻辑网络设计 → 物理网络设计 → 实施阶段
需求规范（需求说明书）通信规范逻辑设计文档物理结构设计文档| 阶段 | 核心关注点 | 是否涉及物理位置 | 输出重点 |
|---|---|---|---|
| 逻辑网络设计 | 网络行为、性能、数据传输逻辑 | 否 | 逻辑架构、IP方案、安全策略、服务规划、人员培训及费用估计 |
| 物理网络设计 | 物理实现（设备、布线、安装） | 是 | 物理拓扑、设备清单、费用估计、安装计划、测试与培训计划 |
现代网络常采用分层架构设计，各层分工明确，协同工作。典型的层次结构（从上至下/从外至内）为：
出口层 → 核心层 → 汇聚层 → 接入层。
数据流动通常从 接入层 的用户端发起，向上经过 汇聚层 聚合，由 核心层 高速转发，最终通过 出口层 访问外部互联网（ISP）。
| 层级 | 主要功能 | 说明与特点 |
|---|---|---|
| 出口层 | 连接不同的互联网服务提供商（ISP）。 | 网络对外的总出口，实现与Internet的互联。通常采用多ISP链路以实现冗余和负载均衡，提高出网的可靠性与性能。 |
| 核心层 | 高速数据交换、高速数据传输、出口路由，常采用冗余机制。 | 网络的骨干和中枢，专注于高速、可靠的数据转发。设计强调高带宽、低延迟和高可用性（如设备冗余、链路冗余），通常在此层避免复杂的策略控制，以保证交换效率。 |
| 汇聚层 | 网络访问策略控制、数据包处理/过滤、寻址、策略路由、广播域定义。 | 承上启下的中间层，负责汇聚多个接入层的流量，并实施区域性的、精细化的网络策略（如VLAN间路由、访问控制列表ACL、流量整形）。是策略执行的关键层面。 |
| 接入层 | 用户接入、计费管理、MAC地址认证或过滤、收集用户信息。 | 最靠近终端用户的层级，负责连接用户设备（如PC、打印机、无线AP）。主要实现用户接入控制、身份识别和基本的安全防护。 |
IPv6有三种主要的地址类型，用于不同模式的网络通信。
| 地址类型 | 描述 | 关键特点与示例前缀 |
|---|---|---|
| 单播 | 唯一标识一个IPv6节点的接口，用于点对点通信。 | 可聚合全球单播地址：前缀为 001 (例如 2000::/3)本地单播地址： - 链路本地：前缀 1111111010 (FE80::/10)，用于同一链路上节点间通信。- 站点本地：前缀 1111111011 (FEC0::/10)，已被唯一本地地址取代。 |
| 多播 | 标识一组IPv6节点的接口，用于一对多通信。 | 前缀固定为 11111111 (FF00::/8)。 |
| 任播 | 指派给多个节点的接口，发往任播地址的数据包只会被路由到其中“最近”的一个接口。 | 地址从单播地址空间分配，格式上无区别，路由协议负责定位“最近”节点。 |
IPv6的设计解决了IPv4的诸多限制，主要优势包括：
为了在IPv4向IPv6演进过程中保证业务共存与平滑过渡，主要采用以下技术：
根据图片内容整理的 RAID 级别对比笔记如下（Markdown 格式）：
| 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 层级 | 主要功能 | 详细说明与协议示例 |
|---|---|---|
| 应用层 (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 等。 |
| 协议名 | 要点 | 协议名 | 要点 |
|---|---|---|---|
| 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. 系统分析 | 核心任务：建立系统的逻辑模型，即业务逻辑。 主要内容：对组织结构及功能、业务流程、数据和数据流程进行分析，形成系统初步方案。 |
| 4. 系统设计 | 核心任务：将逻辑模型转化为物理模型，即技术实现方案。 主要内容：包括系统架构设计、数据库设计、处理流程设计、功能模块设计、安全控制方案设计、系统组织与队伍设计、管理流程设计等。 |
| 5. 系统实施 | 核心任务：将设计转化为可运行的实体系统。 关键点：具体实现，并强调用户参与（如培训、测试）。 |
| 6. 系统验收 | 核心任务：确认系统符合要求并交付使用。 关键点：系统经过试运行后，进入正式验收阶段。 |
关键提示：
- 概念阶段是起点，决定了项目的方向和范围，需求分析是此阶段的核心。
- 系统分析与系统设计是两个关键环节，分别对应解决 “业务问题”（逻辑） 和 “技术实现”（物理） 。
- 系统实施阶段必须重视用户参与，这是项目成功的重要保障。
| 开发方法 | 特点 |
|---|---|
| 结构化法 | - 核心思想：自顶向下，逐步求精。 - 主要特点： • 模块化开发。 • 开发目标清晰化。 • 工作阶段程式化。 • 开发文档规范化。 • 设计方法结构化。 |
| 原型法 | - 适用场景：需求不明确的情况。 - 开发过程：用户提出需求 → 快速构建系统模型 → 与用户反复交流迭代。 - 原型分类： • 按功能分：水平原型（界面原型）、垂直原型（复杂算法原型）。 • 按结构分：抛弃型原型、演化型原型。 |
| 面向对象 (OO) | - 核心思想：自底向上，通过抽象对象来提高复用性，构造问题域的模型。 - 基本构成：对象 → 类 → 类库。 - 主要优势：更符合人类的思维习惯。 |
| 面向服务的方法 (SOA) | - 演进路径：将相关对象和类按业务功能分组形成构件，通过标准化的接口实现分离。 - 核心特点：粗粒度、松耦合、标准化。 - 抽象级别：操作 → 服务 → 业务流程。 |
TPS的核心是对业务数据进行收集、存储、计算和输出，其典型流程如下：
[数据输入]
↓
[数据处理] → (批处理 / 联机实时处理)
↓
[数据库维护] → (更新、存储)
↓
[文件、报表生成] [查询处理]
↓ ↓
输出结果 响应查询
流程详解：
管理信息系统由四大核心部件构成：
MIS根据其决策过程中的信息反馈机制，可分为两种基本结构：
| 结构类型 | 核心特点 | 执行流程 | 示例 |
|---|---|---|---|
| 开环结构 (开环MIS) |
单向执行，不根据反馈调整。在执行决策的过程中不收集外部信息，也不根据信息改变当前决策。事后的评价仅供后续决策参考。 | 输入 → 处理 → 输出 (决策执行完毕后才进行效果评估) |
批量生产、订单执行 |
| 闭环结构 (闭环MIS) |
双向循环，动态调整。在决策执行过程中不断收集外部信息，并及时反馈给决策者，用于调整和优化当前的决策活动。 | 输入 → 处理 → 输出 → 反馈 → 调整输入... (形成一个包含实时反馈的循环) |
库存控制、过程控制系统 |
简单对比：
决策支持系统 (Decision Support System, DSS) 是一个由语言系统、知识系统和问题处理系统三个互相关联的部分组成的，基于计算机的信息系统。
DSS主要有两种基本结构形式：
DSS的构建通常涉及以下关键技术或组成部分：
专家系统 (Expert System, ES) 是一种智能的计算机程序，该程序使用知识与推理过程，求解那些需要资深专家的专门知识才能解决的高难度问题。
专家系统的核心架构由三个要素构成，分别对应三级知识：
| 系统要素 | 对应知识级别 | 功能描述 |
|---|---|---|
| 综合数据库 | 数据级 | 描述和存储问题的当前状态和事实。 |
| 知识库 | 知识库级 | 存放领域专家的启发式经验知识（规则、案例等）。 |
| 推理机 | 控制级 | 对知识库中的知识进行推理和问题求解的控制机制。 |
关键对比：专家系统具备数据、知识库、控制三级结构，而传统应用程序通常只有数据和程序两级结构。
专家系统不同于传统的应用程序，也不同于其他类型的人工智能程序，主要体现在以下五个方面：
问题类型与求解方法
模拟对象
系统结构
问题性质
性能与通用性
ERP系统的结构原理通常包括以下几个关键步骤：
生产预测
生产计划大纲
主生产计划
物料需求计划
能力需求计划
车间作业计划
| 方法 | 核心要点 |
|---|---|
| 1. 业务流程重构方法 | 核心思想是 “彻底的、根本性的”重新设计 业务流程，而非渐进改良。 |
| 2. 核心业务应用方法 | 企业信息化必须围绕并服务于自身的 核心业务，以此为主要推动力。 |
| 3. 信息系统建设方法 | 信息系统的建设是实施企业信息化的 重点和关键 环节。 |
| 4. 主题数据库方法 | 建立面向企业核心业务的 主题数据库，旨在整合数据，消除“信息孤岛”。 |
| 5. 资源管理方法 | 利用计算机与网络技术增强企业资源管理能力，典型应用如 ERP（企业资源规划）、SCM（供应链管理） 等。 |
| 6. 人力资本投资方法 | 将一部分优秀员工视作 “资本”（而不仅是资源），认为对其投资可以获得收益，这是与“人力资源”概念的主要区别。 |
系统需求通常分为三个相互关联的层次，它们从宏观战略逐步落实到具体运作与技术层面。
运作需求是连接战略与具体实施的关键环节，包含以下三方面内容：
技术需求源于实际开发与运行过程中产生的问题，主要关注：
| 需求层次 | 关注焦点 | 核心内容 |
|---|---|---|
| 战略需求 | 为什么做 (Why) | 提升竞争力，支持可持续发展 |
| 运作需求 | 做什么 (What) | 实现战略、支持运作、培养人才 |
| 技术需求 | 如何做/如何改进 (How) | 系统的完善、升级与集成 |
信息系统规划的方法和核心目标随着企业发展不断演变，主要可分为以下三个阶段：
| 阶段 | 规划核心 | 关注焦点 | 主要规划方法 |
|---|---|---|---|
| 第一阶段 | 数据处理 | 围绕职能部门的需求 | 企业系统规划法 (BSP) 关键成功因素法 (CSF) 战略集合转化法 (SST) |
| 第二阶段 | 企业内部管理信息系统 (MIS) | 围绕企业整体的需求 | 战略数据规划法 (SDP) 信息工程法 (IE) 战略栅格法 |
| 第三阶段 | 集成 | 综合考虑企业内外环境，围绕企业战略需求 | 价值链分析法 战略一致性模型 (SAM) |
演变脉络总结：
| 方法名称 | 简称 | 核心思想与关键步骤 | 主要特点与要点 |
|---|---|---|---|
| 企业系统规划法 | BSP | 核心：自上而下规划，自下而上实现。 四步骤：1. 定义管理目标；2. 定义管理功能；3. 定义数据分类；4. 定义信息结构（CU矩阵）。 |
主要用于大型信息系统开发。 |
| 关键成功因素法 | CSF | 核心：识别影响目标达成的关键因素，据此确定信息需求与开发次序。 步骤：确定目标 → 识别CSF → 明确信息需求（定义性能指标与数据字典）。 |
通过识别CSF来确定系统开发的优先次序。 |
| 战略集合转化法 | SST | 核心：将企业战略（使命、目标、战略、管理水平、环境约束等）视为一个“信息集合”，并将其转化为信息系统的战略目标。 | 强调整体性，将企业战略直接映射为信息系统战略。 |
| 战略数据规划法 | SDP | 核心：自顶向下全局规划，自底向上详细设计，以建立主题数据库为主要特征。 主题数据库特征：面向业务、信息共享、一次一处输入、由基本表组成。 四类数据环境：文件环境、应用数据库环境、主题数据库环境、信息检索系统环境。 |
旨在挖掘数据和信息的规律，规划稳定的数据结构。 |
| 信息工程方法 | IE | 核心：围绕企业整体需求，以管理信息系统为核心进行规划。认为信息系统由信息、技术和过程三要素构成。 四阶段：规划、分析、设计、构建。 |
强调三要素，采用明确的阶段化开发过程。 |
| 战略栅格法 | - | 核心：创建一个2x2战略栅格矩阵，从战略影响维度评估企业现有及未来的信息系统组合，分析它们对企业生存与竞争地位的影响。 | 用于评估信息系统投资组合的战略价值。 |
| 价值链分析法 | - | 核心：将企业活动视为一系列输入、转换与输出的价值创造链。通过分析每个环节，识别哪些活动增值，哪些减值，从而确定信息化可优化的环节。 | 从价值创造角度分析信息化机会，增强企业竞争地位。 |
| 战略一致性模型 | SAM | 核心：分析企业战略与信息化战略的匹配关系。模型分为内、外两大部分： 外部：企业面临的竞争环境（如市场）。 内部：企业组织结构、信息架构和业务流程等。 |
用于评估和确保企业战略与IT战略之间的一致性。 |
客户关系管理 (Customer Relationship Management, CRM) 通过将企业的人力资源、业务流程与专业技术进行有效整合，最终在涉及客户或消费者的各个领域提供完美集成。
其核心目标是：
一个典型的CRM系统主要包含以下四个模块：
销售自动化 (SFA)
营销自动化 (MA)
客户服务与支持 (CSS)
商业智能 (BI)
CRM 系统主要包含以下四大核心功能，它们相互关联，共同构成完整的客户管理闭环。
| 核心功能 | 核心描述与价值 | 关键活动与说明 |
|---|---|---|
| 客户服务 | CRM的关键内容，通过提供优质服务提高客户满意度和忠诚度。 | 处理客户咨询、投诉、支持请求，是建立长期客户关系的基础。 |
| 市场营销 | 负责商机挖掘与管理，是企业赢利的核心驱动因素。 | 包括： • 商机产生、获取与管理 • 商业活动管理（如市场活动策划） • 电话营销 • 核心是将潜在客户发展为忠诚客户。 |
| 共享的客户资料库 | 连接市场营销与客户服务的基础与依托，是企业重要的信息资源。 | 统一存储客户信息、交互历史、交易记录等，确保各部门信息一致，打破数据孤岛。 |
| 分析能力 | 使客户价值最大化的关键，通过对客户数据的深度分析，支持智能决策。 | 对共享资料库中的数据进行统计分析、建模，以识别客户行为模式、细分客户群体、预测趋势，并评估营销活动效果。 |
一个成功的CRM系统不仅是一套软件，更是一套整合了策略、流程和技术的解决方案。其核心要素包括：
| 要素 | 核心描述与作用 |
|---|---|
| 畅通有效的客户交流渠道 (触发中心) |
建立多样、便捷的沟通渠道（如电话、邮件、社交媒体、在线客服），作为与客户互动、获取需求与反馈的“触发”起点。 |
| 对所获信息进行有效分析 (挖掘中心) |
对从各渠道收集的客户数据进行深度分析与挖掘，转化为商业洞察，以支持精准营销、个性化服务和战略决策。 |
| 与ERP系统良好集成 | CRM必须能与企业资源规划(ERP)系统无缝集成，实现客户信息、订单、库存、财务等数据的贯通，打破信息孤岛，形成业务闭环。 |
提示：图中特别用红色强调了 “触发中心”、“挖掘中心” 和 “与ERP集成” 这三个关键点，它们是评估CRM解决方案有效性的核心。
CRM的实施与应用是一个持续的价值创造过程，主要围绕以下三个核心环节展开：
| 过程环节 | 核心目标与活动 |
|---|---|
| 客户服务与支持 | 核心：通过控制与服务品质，赢得顾客的忠诚度。 活动：处理咨询、投诉、提供售后支持，确保客户问题得到及时有效解决，提升客户满意度与黏性。 |
| 客户群维系 | 核心：通过与现有顾客的持续交流与关系维护，实现新的销售（交叉销售与向上销售）。 活动：进行客户关怀、满意度回访、个性化推荐，将一次性客户转化为长期忠诚客户。 |
| 商机管理 | 核心：利用客户数据库开展销售，将潜在需求转化为实际交易。 活动：管理销售线索、跟踪商机进程、分析客户购买行为，赋能销售团队，提升成交率与销售效率。 |
供应链管理 (Supply Chain Management, SCM) 是一种集成的管理思想和方法。其核心是在满足既定的服务水平要求的同时，为了使系统总成本达到最低，而采用的将供应商、制造商、仓库和商店有效地结合成一体来生产商品，并有效地控制和管理各种信息流、资金流和物流，最终实现把正确数量的商品在正确的时间配送到正确地点的一套管理方法。
| 特点 | 核心描述 |
|---|---|
| 以客户为中心 | SCM追求的首要目标是满足客户需求。衡量其绩效的最重要指标是客户满意度。 |
| 集成化管理 | SCM的本质在于集成化管理，强调对供应链上各环节与资源的协同与整合。 |
| 扩展性管理 | 现代的SCM促使传统的企业向扩展性企业（Extended Enterprise） 发展，其管理范围超越了企业自身的边界。 |
| 合作管理 | 非常强调企业之间的合作，打破传统的封闭经营意识，在供应链各节点企业之间建立起新型的合作关系。 |
| 多层次管理 | 其管理活动涵盖战略、战术和作业三个层次。主要目标是通过系统的观点，对各职能和各层级的供应商进行整合。 |
供应链是由一系列相互关联的实体组成的网络，主要节点包括：
供应链管理包括计划、采购、制造、配送、退货五大基本活动，其核心说明如下：
| 组成部分 | 核心说明 |
|---|---|
| 计划 | 这是SCM的策略部分。企业需要一个策略来管理所有资源，以满足客户对产品的需求。好的计划建立一系列方法来监控供应链。 |
| 采购 | 核心任务是选择合适的供应商，为企业提供产品和服务。 |
| 制造 | 安排生产、测试、打包和准备送货所需的活动。是供应链中测量内容最多的部分。 |
| 配送 | 即物流。包括调整用户订单、建立仓库网络、安排提货送货、建立计价系统、接收付款等活动。 |
| 退货 | 是供应链中的问题处理部分。 |
企业应用集成 (Enterprise Application Integration, EAI) 是指对企业内部或企业间多个独立的应用系统进行整合，以实现数据、流程和功能的共享与协同。
| 集成方式 | 别称 | 集成层次 | 主要特点与说明 | 典型例子 |
|---|---|---|---|---|
| 表示集成 | 界面集成、黑盒集成 | 用户界面层 | 最原始、浅层的集成。将多个系统的用户界面统一入口，提供一个看上去统一但由多个后台系统组成的应用。 | 企业门户、统一桌面 |
| 数据集成 | 白盒集成 | 数据层 | 将不同来源、格式的数据在逻辑或物理上有机集中，实现全面的数据共享。 | ETL工具、数据仓库、联邦数据库 |
| 控制集成 | 功能集成、应用集成、黑盒集成 | 业务逻辑层 | 将多个应用系统的功能（业务逻辑）进行绑定与调用，使其像一个实时系统一样协同工作。 | 远程过程调用(RPC)、面向消息的中间件(MOM)、钉钉（集成多个应用功能） |
| 业务流程集成 | 过程集成 | 业务流程层 | 最彻底、最综合的集成。超越单个系统和数据，通过一系列基于标准、统一格式的工作流将多个应用串联，实现端到端的自动化流程。 | 跨系统审批流、供应链协同流程 |
| 门户集成 | - | 表示层/应用层 | 将内部应用系统的功能和数据对接到互联网，通过统一门户（如企业门户网站、移动APP）向外部用户或合作伙伴提供访问。 | 企业客户门户、供应商自助平台 |
EAI 从底层到顶层，依次提供以下四个层次的服务：
| 层次 (从下至上) | 服务名称 | 核心作用 |
|---|---|---|
| 第一层 | 通讯服务 | 为系统间集成提供基础的数据传输通道。 |
| 第二层 | 信息传递与转化服务 | 负责数据的路由、格式转换与传递。 |
| 第三层 | 应用连接服务 | 直接连接和调用不同应用系统的具体功能。 |
| 第四层 | 流程控制服务 | 最高层服务，协调和管理跨系统的业务流程。 |
EAI 的核心活动是在各个应用系统的接口之间共享数据和功能。其基本原则是：集成多个系统，并保证被集成的系统之间互不干扰，即保持各自的独立性。
企业内部的信息集成通常按照集成内容与层次，自底向上分为以下四个方面：
| 集成层次 | 核心目标与内容 |
|---|---|
| 技术平台的集成 | 实现系统底层体系结构、软件、硬件以及异构网络的整合，为上层集成提供统一、稳定的技术基础。 |
| 数据的集成 | 解决数据和数据库的集成问题，实现不同系统间的数据交流与共享。这是进行更深入集成（应用、流程）的基础。 |
| 应用系统的集成 | 实现不同应用系统之间的互操作，使它们能够共享数据和方法。为更高层的业务流程集成奠定基础。 |
| 业务过程的集成 | 最高层次的集成。确保不同应用系统中的业务流程能够无缝连接，实现流程的协调运作与流程信息的充分共享。 |
核心演进：四个层次呈现出自底向上、从技术到业务的递进关系，共同构成企业内部信息集成的完整框架。
企业外部的信息集成主要关注与外部实体的连接与协同，包含以下两个部分：
| 集成部分 | 核心目标与方式 |
|---|---|
| 与公众及客户的集成 | 通过企业门户网站和互联网，实现与公众、社会团体、客户等的互动，促进内外部信息资源的有效交流与集成。 |
| 与合作伙伴的集成 | 通过与合作伙伴信息系统的直接对接，建立动态的企业联盟，发展基于合作竞争机制的虚拟企业，以此重塑企业的战略模式和竞争优势。 |
数据挖掘 是从海量数据中提取或“挖掘”知识的过程。
其重要的功能包括：分类、聚类、关联规则和离群点分析。
| 级别 | 名称 | 要点 |
|---|---|---|
| 第1级 | 用户自主保护级 | 通过隔离用户与数据，使用户具备自主安全保护的能力。为用户提供访问控制手段，保护用户和用户组信息，避免其他用户对数据的非法读写与破坏。 |
| 第2级 | 系统审计保护级 | 实施更细粒度的自主访问控制。通过登录规程、审计安全性相关事件和隔离资源，使用户对自己的行为负责。 |
| 第3级 | 安全标记保护级 | 具备第2级所有功能，并增加： 1. 提供安全策略模型、数据标记以及主体对客体的强制访问控制的非形式化描述。 2. 具有准确标记输出信息的能力。 3. 消除通过测试发现的任何错误。 |
| 第4级 | 结构化保护级 | 将第3级中的自主和强制访问控制扩展到所有主体与客体，并考虑隐蔽通道。此外： 1. 加强鉴别机制。 2. 支持系统管理员和操作员的职能。 3. 提供可信设施管理。 4. 增强配置管理控制。 5. 系统具有相当的抗渗透能力。 |
| 第5级 | 访问验证保护级 | 满足访问监控器需求。访问监控器仲裁主体对客体的全部访问，其本身是抗篡改的，且必须足够小以能够分析和测试。此外： 1. 排除非必要代码，复杂性最低。 2. 支持安全管理员职能。 3. 扩充审计机制（安全事件告警）。 4. 提供系统恢复机制。 5. 系统具有很高的抗渗透能力。 |
安全级别核心演进总结：
敏捷模型是一组以轻量、快速、灵活、协作为核心的软件开发方法集合。其核心思想是拥抱变化，快速响应，通过短周期的迭代交付可工作的软件，并强调人员协作和客户反馈。
| 模型/方法 | 核心思想与特点 |
|---|---|
| 极限编程 (XP) | - 价值观：交流、朴素、反馈、勇气。 - 开发模式：近螺旋式的开发方法，将复杂过程分解为简单的小周期。 - 关键实践：通过积极的交流与持续的反馈来推进。 |
| 水晶方法 (Crystal) | - 核心：提倡“机动性”，认为不同项目需要不同的方法。 - 特点：包含一系列具有共性的核心元素（角色、模式、工作产品等），形成“Crystal家族”。团队可根据项目类型和环境选择最合适的成员方法。 |
| SCRUM | - 侧重点：侧重于项目管理。 - 过程模型：是一个迭代式增量的软件开发过程。通过固定时长的“Sprint”迭代交付增量产品。 |
| 特征驱动开发 (FDD) | - 核心理念：有效的软件开发需要人、过程和技术三大要素。 - 关键角色：定义了6种关键项目角色（如项目经理、首席架构师、主程序员等）。 - 核心过程：包含5个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计、特征构建。计划基于特征间的依赖关系。 |
总结：敏捷模型并非单一方法，而是一系列具有共同价值观（个体和互动高于流程和工具、可工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划）的方法论集合，旨在应对快速变化的需求。
敏捷开发强调轻量、快速响应和团队协作，其日常实践遵循以下基本原则：
敏捷开发包含一系列具体的方法论，常见的有：
总结：敏捷模型通过其价值观、原则和一系列具体的最佳实践，构建了一个以人为核心、迭代快速、能灵活响应变化的软件开发框架。
构件组装模型，即基于构件的软件开发 (Component-Based Software Development, CBSD) 模型，是一种利用模块化方法，通过复用和组合预先构建好的软件构件来构造应用系统的过程。
基于构件的软件开发主要包含以下五个阶段：
| 阶段 | 主要任务 |
|---|---|
| 1. 需求分析和定义 | 明确系统的功能与非功能需求。 |
| 2. 体系结构设计 | 设计系统的整体结构，确定构件间的接口与协作关系。 |
| 3. 构件库的建立 | 创建、获取或管理可复用的软件构件库。 |
| 4. 应用软件构建 | 通过选择、适配和组装构件库中的构件来构建应用系统。 |
| 5. 测试和发布 | 对组装后的系统进行测试，并最终发布。 |
快速应用开发 (Rapid Application Development, RAD) 模型是一种 增量型 的软件开发过程模型。它强调 极短的开发周期，通过 大量使用可复用构件 和 基于构件的建造方法 来赢得快速开发。
RAD模型通常包含以下五个顺序阶段：
业务建模 (Business Modeling)
数据建模 (Data Modeling)
过程建模 (Process Modeling)
应用生成 (Application Generation)
测试与交付 (Testing and Turnover)
总结：RAD模型的核心是利用复用和自动化工具，将需求、设计、构建阶段高度压缩并迭代进行，以实现快速交付。
CMMI（能力成熟度模型集成）是一个过程改进框架，用于帮助组织提升其开发和管理产品与服务的过程能力。
| 级别 | 要点 |
|---|---|
| 初始级 | 过程是无秩序且混乱的。项目的成功高度依赖于个人的努力和机遇。 |
| 已管理级 | 建立了基本的项目管理过程。能够对成本、进度和功能进行跟踪，类似的项目可复现成功。 |
| 已定义级 | 软件过程均已实现文档化、标准化，并整合成为整个组织统一的标准软件过程。所有项目均使用经批准、剪裁的组织标准过程来开发和维护软件。 |
| 量化管理级 | 对软件过程和产品质量建立了详细的量化度量标准，并运用统计技术进行定量过程管理。 |
| 优化级 | 专注于过程的持续改进。能够利用来自过程和创新的量化反馈，通过增量式和创新式的技术进步，持续地优化过程性能。 |
成熟度演进：从 依赖个人 → 项目可控 → 过程标准化 → 量化管理 → 持续优化。高级别包含低级别的所有特征。
软件需求可以从两个不同的维度进行分类：一是按需求内容的性质，二是从客户（或用户）的价值感知角度。
此分类方式关注需求的来源、抽象层次和具体内容。
| 需求类别 | 定义与描述 | 说明与示例 |
|---|---|---|
| 1. 业务需求 | 由客户或高层提出的宏观功能与目标需求，反映了组织或业务的高层目标。 | 具有整体性和全局性，例如“建设一个在线商城以提升销售额”。 |
| 2. 用户需求 | 设计人员通过调研，获得的系统中每个具体用户（或角色）所需要完成的任务或期望。 | 是业务需求的细化，描述了用户希望通过系统“做什么”，例如“作为买家，我希望能够搜索商品”。 |
| 3. 系统需求 | 对用户需求进行分析、整合与细化后形成的最终技术性需求规格。它详细定义了系统必须实现什么。 | 通常包含以下子类： • 功能需求：软件必须完成的具体动作或服务。 • 性能需求：软件需要满足的静态或动态数值指标，如响应时间、吞吐量、并发用户数等。 • 设计约束：受外部标准、硬件或其它系统限制而必须遵守的条件，如必须运行在Linux系统上、必须使用特定数据库等。 |
此分类方式关注功能对客户满意度的不同影响。
| 需求类别 | 定义与对满意度的影响 | 客户心理与开发考量 |
|---|---|---|
| 1. 基本需求 | 需求中明确规定的、必须实现的功能。 | 客户认为“必须有”。如果缺失会导致客户极度不满；但即使完美实现，也仅能消除不满，不会提升满意度。是项目的“及格线”。 |
| 2. 期望需求 | 除了明文规定的基本需求外，客户认为理所应当包含的功能。 | 客户认为“应该有”。这类需求的实现程度与客户满意度呈线性正比关系。实现得越好，客户越满意。是竞争的关键。 |
| 3. 兴奋需求 | 客户并未明确要求的额外功能或特性。 | 客户“没想到但很喜欢”。如果实现，能带来惊喜并显著提升满意度；如果不实现，客户也不会不满。需要注意的是，过度开发此类需求可能浪费项目时间和成本。 |
总结：第一种分类（按内容）主要用于需求分析与文档化的过程管理；第二种分类（按客户角度）则更侧重于需求优先级排序与产品策略规划，以最大化客户价值和满意度。
结构化设计过程通常分为概要设计和详细设计两个阶段：
| 阶段 | 主要任务 | 核心产出 |
|---|---|---|
| 概要设计 (总体设计/架构设计) |
确定软件系统的整体结构，进行模块划分，明确每个模块的功能、接口以及模块间的调用关系。 | 软件系统结构图、模块说明书 |
| 详细设计 (过程设计) |
为每个模块设计具体的实现细节，即“如何做”。 | 详细的模块算法描述、流程图、伪代码等 |
内聚 (Cohesion)：
耦合 (Coupling)：
总结：优秀的结构化设计追求模块内部“抱团紧”（高内聚），模块之间“联系松”（低耦合）。
内聚性由高到低排列，高内聚是优秀设计的追求目标。
| 内聚类型 | 描述 | 内聚性评价 |
|---|---|---|
| 功能内聚 | 模块内所有部分协同工作，共同完成一个且仅一个独立、完整的功能。 | 最高。是最理想的内聚类型。 |
| 顺序内聚 | 模块内的处理元素相关，且必须按特定顺序依次执行，通常前一个处理的输出是下一个处理的输入。 | 高。 |
| 通信内聚 | 模块内的所有处理元素都操作于同一个数据结构或数据区域上。 | 中。 |
| 过程内聚 | 模块内的处理元素相关，并且必须按照特定的过程次序（流程）执行。 | 中。 |
| 时间内聚 | 模块内的处理元素必须在同一时间间隔内执行（如初始化、结束处理），但彼此逻辑关联不强。 | 低。 |
| 逻辑内聚 | 模块完成一组在逻辑上相关（相似）但功能不同的任务，通过调用时传入的参数来决定具体执行哪一项。 | 低。 |
| 偶然内聚 | 模块内的任务之间没有实质联系，关系松散，只是为了某种方便（如节省空间）而组合在一起。 | 最低。应避免。 |
核心设计原则：在结构化设计中，应致力于实现高内聚（特别是功能内聚）的模块，这有助于提高模块的独立性、可理解性和可维护性。
耦合性由低到高排列，低耦合是优秀设计的追求目标。
| 耦合类型 | 描述 | 耦合性评价与说明 |
|---|---|---|
| 非直接耦合 | 两个模块之间没有直接关系，它们之间的联系完全是通过主模块（上级模块）的控制和调用来实现的。 | 最低。模块独立性最强，是最理想的耦合形式。 |
| 数据耦合 | 一组模块之间只通过参数表传递简单的数据值（而非控制信息或复杂结构）。 | 低。模块间接口清晰，是一种良好的耦合形式。 |
| 标记耦合 (特征耦合) |
一组模块通过参数表传递的是记录、数组、对象等复杂的整体数据结构。虽然传递的是数据，但由于接收模块可能只使用其中一部分，会造成隐含的依赖。 | 中。增加了模块间不必要的连接，应控制其使用。 |
| 控制耦合 | 模块之间传递的信息中包含了用于控制对方内部逻辑的信号或参数（如标志、开关值）。 | 中/高。一个模块的行为会直接影响另一个，降低了接收模块的独立性。 |
| 外部耦合 (图中为通信耦合) |
一组模块共享同一组输入数据，或者它们的输出需要组合才能形成完整的输出数据集。 | 较高。模块通过共享的输入/输出区域产生间接关联，结构不清晰。 |
| 公共耦合 | 多个模块都访问同一个公共数据环境（如全局变量、共享的数据库、公共内存区）。 | 高。对公共数据的修改会影响所有相关模块，难以控制和追踪错误。 |
| 内容耦合 | 一个模块直接访问另一个模块的内部数据；或不通过正常入口（如跳转）进入另一个模块；或代码重叠；或一个模块有多个入口。 | 最高。严重破坏了模块的封装性和独立性，是必须避免的耦合形式。 |
核心设计原则：在结构化设计中，应致力于实现低耦合（特别是非直接耦合和数据耦合）的模块间关系。结合高内聚原则，共同构成优秀模块化设计的基础。
内聚与耦合的关系：高内聚往往有助于达成低耦合。一个功能单一的模块（高内聚）通常只需要通过简单的接口与其他模块通信（低耦合）。
自顶向下，逐步细化；清晰第一，效率第二；书写规范，缩进格式；基本结构，组合而成。
面向对象开发方法认为：
面向对象开发是一个：
OOA模型由5个层次和5个活动构成。
| 5个层次 (构成) | 5个活动 (过程) | 说明 |
|---|---|---|
| 主题层 | 定义主题 | 控制复杂性，提供系统概貌。 |
| 对象类层 | 标识对象类 | 识别与问题域相关的对象类。 |
| 结构层 | 标识结构 | 识别对象类之间的分类结构与组装结构。 |
| 属性层 | 定义属性 | 定义对象类的数据特征。 |
| 服务层 | 定义服务 | 定义对象类的操作或方法。 |
OOA中定义了两种对象类之间的结构：
| 结构类型 | 描述 |
|---|---|
| 分类结构 | 表示对象类之间 “一般与特殊” 的关系（即继承关系）。 |
| 组装结构 | 表示对象之间 “整体与部分” 的关系（即组合/聚合关系）。 |
UML 是一种标准化的建模语言，用于对软件密集系统进行可视化、详述、构造和文档化。下图汇总了UML 2.x中定义的13种图形。
| UML图 | 描述与用途 |
|---|---|
| 用例图 | 由参与者 (Actor)、用例 (Use Case)、边界以及它们之间的关系构成，用于描述系统的功能需求。用例之间的关系有包含、扩展、泛化。 |
| 类图 | 展现一组对象、接口、协作以及它们之间的关系。描述系统的静态结构。类之间的关系有关联、依赖、实现、泛化。 |
| 对象图 | 描述一组对象及它们之间的关系。可以看作是类图在某一时刻的实例（静态快照）。 |
| 构件图 | 描述一个封装的构件和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。 |
| 组合结构图 | 用于描述结构化类（如构件或类）的内部内容，包括其组成部分以及它们之间的协作关系。 |
| 顺序图 (序列图) |
一种交互图，由一组对象或参与者以及它们之间可能发送的消息构成，强调消息的时间次序。 |
| 通信图 (协作图) |
一种交互图，强调收发消息的对象或参与者的结构组织，侧重于对象间的链接关系。 |
| 定时图 | 一种交互图，强调消息跨越不同对象或参与者的实际时间，而不仅仅是相对顺序。 |
| 状态图 | 描述一个特定对象在其生命周期中所有可能的状态，以及由事件引起的状态之间的转移和变化。 |
| 活动图 | 将进程或计算的结构展示为一步步的控制流和数据流，可用于描述业务流程或算法流程。支持并行、分支、合并。 |
| 部署图 | 描述软件制品（如可执行文件、库）在硬件节点上的物理部署情况，展现软件和硬件的物理关系。 |
| 制品图 | 描述系统的物理结构，即软件制品（如源码文件、可执行文件、脚本等）以及它们之间的关系。通常与部署图一起使用。 |
| 包图 | 描述由模型本身分解而成的组织单元（包） 以及它们之间的依赖关系。用于对模型元素进行分组管理。 |
| 交互概览图 | 是活动图和顺序图的混合物，它以活动图的框架为基础，但其中的节点是交互图（如顺序图），用于概述控制流。 |
常见分类：
逻辑覆盖是以程序内部逻辑为基础的测试技术，属于白盒测试的范畴。其核心是通过设计测试用例，运行程序以覆盖其内部的逻辑结构。
常用的逻辑覆盖标准及其发现错误的能力从弱到强依次为：
语句覆盖 → 判定覆盖 → 条件覆盖 → 判定/条件覆盖 → 条件组合覆盖 → 路径覆盖
| 覆盖标准 | 核心要求 | 说明 |
|---|---|---|
| 语句覆盖 | 每条可执行语句至少执行一次。 | 最弱的覆盖标准，仅覆盖语句，不关注判断逻辑。 |
| 判定覆盖 (分支覆盖) |
每个判定的每个分支（“真”分支和“假”分支）至少执行一次。 | 比语句覆盖强，覆盖了所有的判断结果。 |
| 条件覆盖 | 每个判定中的每个条件（简单布尔表达式）应取到各种可能的值（真/假）。 | 关注判定中每个条件的取值，但不保证覆盖所有判定结果。 |
| 判定/条件覆盖 | 同时满足判定覆盖和条件覆盖的要求。 | 覆盖了所有分支以及所有条件的取值，是两者的结合。 |
| 条件组合覆盖 (图片中红圈强调) |
每个判定中各条件的每一种可能组合（真/假值的组合）至少出现一次。 | 覆盖强度高，能暴露复杂的条件交互错误。 |
| 路径覆盖 | 使程序中的每一条可能的执行路径（从入口到出口）至少执行一次。 | 最强的逻辑覆盖标准，但路径数量可能非常多，甚至无限，难以实现完全覆盖。 |
净室软件工程的理论基础是函数理论和抽样理论。
核心总结：净室软件工程是一种以数学为基础、以预防缺陷为核心、以统计验证为评估手段的高质量软件开发范式。
净室软件工程的理论基础是函数理论和抽样理论。
净室软件工程通过以下四种关键技术手段实现其高质量目标：
按照函数理论，使用盒结构方法在三种抽象层次上进行规约与设计：
| 抽象层次 | 视图类型 | 核心描述与关注点 |
|---|---|---|
| 黑盒 (Black Box) | 行为视图 | 刻画系统或部件的外部行为。定义一组“激发(输入)-反应(输出)”的变迁规则，不关心内部状态与实现。 |
| 状态盒 (State Box) | 有限状态机视图 | 以类似对象的方式封装状态数据和服务(操作)。在此视图中，明确标出状态盒的输入(激发)和输出(反应)，并揭示其内部状态数据。 |
| 清晰盒 (Clear Box) | 过程视图 | 定义状态盒内部蕴含的具体变迁过程（即过程设计）。清晰盒包含了实现状态盒功能所需的详细逻辑与潜在的子盒结构。 |
应用顺序：规约从黑盒开始，逐步精化为状态盒，最后细化为清晰盒的设计。
总结：净室软件工程是一种以数学为基础、以缺陷预防为核心、以统计验证为评估手段的严谨开发范式。它通过增量开发控制过程，通过盒结构进行严格规约与设计，通过正确性验证在早期消灭缺陷，最后通过统计测试进行科学认证，从而系统性地保障软件的高质量。
净室软件工程虽然强调通过数学和统计学方法生产高质量软件，但其在实际应用中存在一些明显的局限性和挑战。
| 序号 | 缺点描述 | 具体说明与挑战 |
|---|---|---|
| ① | 过于理论化，实施成本高 | - 需要开发人员具备较多的数学知识。 - 正确性验证的步骤比较困难且耗时。 - 要求掌握增量式开发、盒结构、统计测试等特定方法，普通工程师需加强训练才能掌握，导致开发成本比较高昂。 |
| ② | 跳过传统模块测试不现实 | - 认为不进行传统的模块测试是不现实的。 - 工程师可能对编程语言和开发环境还不熟悉。 - 编译器或操作系统的Bug也可能导致未预期的错误，而这些在净室方法的早期验证中可能难以发现。 |
| ③ | 未能完全摆脱传统弊端 | - CSE毕竟脱胎于传统软件工程，不可避免地带有传统软件工程的一些弊端。其理想化的流程在复杂、多变的现实开发环境中可能难以完全贯彻。 |
净室软件工程（CSE）是一种以严格验证和缺陷预防为核心的高质量软件开发范式。其优点在于理论上能极大降低缺陷数，但其缺点也很突出：理论复杂、实施成本高、对环境和人员要求苛刻，且在实践中可能难以完全规避传统工程方法的问题。因此，它更适合于对可靠性要求极高、预算和周期相对充裕的关键系统开发。
构件是一个独立的软件单元，可以与其他构件组合构成一个软件系统。系统中的构件可以是：
一个合格的构件应具备以下特征：
| 特征 | 核心要求与说明 |
|---|---|
| (1) 可组装性 | 所有外部交互都必须通过公开定义的接口进行。 |
| (2) 可部署性 | 必须是自包含的独立实体，能以二进制形式在构件平台上直接运行，无须在部署前编译。 |
| (3) 文档化 | 必须提供完全文档，用户据此判断构件是否满足需求。 |
| (4) 独立性 | 应能独立组装和部署。如需其他构件服务，必须显式声明依赖。 |
| (5) 标准化 | 必须符合某种标准化的构件模型。 |
目前主流的构件模型主要包括以下三种：
总结：CBSE通过使用符合标准、具备可组装、可部署等特征的预制构件，改变了传统的软件开发模式，致力于提升开发效率、降低成本和改善可维护性。
基于构件的软件工程遵循一个系统的、以构件为核心的开发流程，主要包括以下六个步骤：
| 步骤 | 核心任务与说明 |
|---|---|
| 1. 系统需求概览 | 对系统进行整体需求分析，明确目标和范围。 |
| 2. 识别候选构件 | 根据需求，在构件库或市场中寻找、评估和选择潜在的可用构件。 |
| 3. 根据发现的构件修改需求 | 基于实际可用构件的功能和约束，调整和细化原始需求，使需求更贴合可复用资产。 |
| 4. 体系结构设计 | 设计系统的整体结构，确定所选构件如何组织、交互以及如何与可能的新开发部分集成。 |
| 5. 构件定制与适配 | 对选定的构件进行必要的修改、配置或包装，以满足系统的特定集成要求。 |
| 6. 组装构件创建系统 | 将定制后的构件通过“胶水代码”或集成框架连接起来，构建出完整的可运行系统。 |
构件组装是指将多个构件相互集成，或通过专门编写的 “胶水代码” 将它们整合在一起，从而创造出一个新系统或一个更大构件的过程。
常见的构件组装主要有三种方式：顺序组装、层次组装、叠加组装。下图详细说明了其中一种基础且重要的方式：
上一个构件的输出 与 下一个构件的输入 相兼容。
流程总结：CBSE过程从需求出发，经历“寻找构件-调整设计-集成组装”的迭代，最终通过构件组装（尤其是顺序调用配合胶水代码）实现系统构建，体现了“购买而非构造”的核心理念。
构件是一个独立的软件单元，可以与其他构件组合构成一个软件系统。系统中的构件可以是：
一个合格的构件应具备以下特征：
| 特征 | 核心要求与说明 |
|---|---|
| (1) 可组装性 | 所有外部交互都必须通过公开定义的接口进行。 |
| (2) 可部署性 | 必须是自包含的独立实体，能以二进制形式在构件平台上直接运行，无须在部署前编译。 |
| (3) 文档化 | 必须提供完全文档，用户据此判断构件是否满足需求。 |
| (4) 独立性 | 应能独立组装和部署。如需其他构件服务，必须显式声明依赖。 |
| (5) 标准化 | 必须符合某种标准化的构件模型。 |
目前主流的构件模型主要包括以下三种：
基于构件的软件工程遵循一个系统的、以构件为核心的开发流程，主要包括以下六个步骤：
| 步骤 | 核心任务与说明 |
|---|---|
| 1. 系统需求概览 | 对系统进行整体需求分析，明确目标和范围。 |
| 2. 识别候选构件 | 根据需求，在构件库或市场中寻找、评估和选择潜在的可用构件。 |
| 3. 根据发现的构件修改需求 | 基于实际可用构件的功能和约束，调整和细化原始需求，使需求更贴合可复用资产。 |
| 4. 体系结构设计 | 设计系统的整体结构，确定所选构件如何组织、交互以及如何与可能的新开发部分集成。 |
| 5. 构件定制与适配 | 对选定的构件进行必要的修改、配置或包装，以满足系统的特定集成要求。 |
| 6. 组装构件创建系统 | 将定制后的构件通过“胶水代码”或集成框架连接起来，构建出完整的可运行系统。 |
构件组装是指将多个构件相互集成，或通过专门编写的 “胶水代码” 将它们整合在一起，从而创造出一个新系统或一个更大构件的过程。
常见的构件组装主要有三种方式：
上一个构件的输出 与 下一个构件的输入 相兼容。
总结：CBSE通过使用符合标准、具备可组装、可部署等特征的预制构件，并运用顺序、层次、叠加等方式进行灵活组装，改变了传统的软件开发模式，致力于提升开发效率、降低成本和改善可维护性。
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的活动。
进度管理是为了确保项目按期完成所需要的管理过程。其主要活动包括以下六个步骤：
工作分解结构 (Work Breakdown Structure, WBS) 是把一个项目，按一定的原则分解成任务，任务再分解成一项项工作，再把工作分配到每个人的日常活动中。
其核心分解路径为：项目 → 任务 → 工作 → 日常活动。
在软件项目中，这通常体现为：软件系统 → 子系统/组件 → 功能模块 → 具体编程/测试活动。WBS是进行估算、制定预算、规划进度和分配资源的基础。
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对以下四个核心要素进行分析和管理的活动：
进度管理是确保项目按期完成所需要的管理过程。其主要包含以下六个活动过程：
| 序号 | 主要活动 | 说明 |
|---|---|---|
| 1 | 活动定义 | 识别为完成项目可交付成果而需采取的具体行动。 |
| 2 | 活动排序 | 识别和记录项目活动之间的逻辑关系与依赖。 |
| 3 | 活动资源估算 | 估算每项活动所需的人员、材料、设备等资源的类型和数量。 |
| 4 | 活动历时估算 | 根据资源估算结果，估算完成单项活动所需的工作时段数。 |
| 5 | 制定进度计划 | 分析活动顺序、持续时间、资源需求和进度制约因素，创建项目进度模型。 |
| 6 | 进度控制 | 监督项目状态，更新项目进展，管理进度基准的变更。 |
工作分解结构 (Work Breakdown Structure, WBS) 是把一个项目，按一定的原则分解，其路径为：
项目 → 任务 → 工作 → 日常活动。
在软件项目中，这通常体现为：软件系统 → 子系统/组件 → 功能模块 → 具体编程/测试活动。WBS是进行项目估算、计划、控制和分配工作的基础。
进行工作分解时，应遵循以下基本原则以确保分解的有效性：
活动定义是指确定为完成项目的各个交付成果所必须进行的各项具体活动。其核心是明确每个活动的：
主要有两种图形化表示方法用于描述活动顺序和依赖关系：
| 方法 | 别称 | 核心特点 |
|---|---|---|
| 前导图法 | 单代号网络图法 | 用节点（框）表示活动，用箭线表示活动之间的逻辑关系。 |
| 箭线图法 | 双代号网络图法 | 用箭线表示活动，用节点（通常为圆圈）表示事件的开始或完成。 |
软件配置管理的核心内容包括以下两部分：
| 核心内容 | 说明 |
|---|---|
| 版本控制 (Version Control) | 对软件资产（如源代码、文档）的不同版本进行标识、存储和管理。 |
| 变更控制 (Change Control) | 对变更进行管理，目的并非阻止变更发生，而是确保变更有序进行。它为变更请求提供标准化的流程（如提交、评估、批准、实施、验证）。 |
变更请求主要来源于两个方面：
| 因素来源 | 具体描述 | 处理难度比较 |
|---|---|---|
| 外部变更要求 | 来自客户或外部干系人，如修改工作范围、需求等。 | 最难处理。因为IT项目需求变更概率大，且引发的工作量也大，尤其在项目后期。 |
| 内部变更要求 | 来自开发过程内部，如为解决测试中发现的错误而修改源码或设计。 | 相对可控。 |
总结：SCM通过系统的版本管理和严格的变更控制流程，应对软件开发中必然出现的变更，特别是难以应对的外部需求变更，以保障项目在受控状态下有序推进。
软件配置管理的核心内容包括以下两部分：
| 核心内容 | 说明 |
|---|---|
| 版本控制 (Version Control) | 对软件资产（如源代码、文档）的不同版本进行标识、存储和管理。 |
| 变更控制 (Change Control) | 对变更进行管理，目的并非阻止变更发生，而是确保变更有序进行。它为变更请求提供标准化的流程。 |
配置库是存储和管理所有配置项及其版本的仓库。根据对配置项的控制级别，通常分为三类：
| 库类型 | 别称 | 主要用途与特点 | 访问与修改控制 |
|---|---|---|---|
| 动态库 (Development Library) |
开发库、程序员库、工作库 | 保存开发人员当前正在开发的配置实体（如正在编写的代码模块）。 | 开发人员可随意修改，是私有的或小组共享的工作区。 |
| 受控库 (Controlled Library) |
主库、系统库 | 管理当前基线和控制对基线的变更。包含已被提升并集成的配置项，用于创建测试版本或发布构建。 | 可自由复制/读取。但必须经过授权流程（如变更控制委员会批准）才能进行修改。 |
| 静态库 (Static Library) |
软件仓库、软件产品库 | 用于存档各种已广泛使用的、已发布的基线（如正式发布的版本）。 | 只读。存档的基线不能修改，用于发布、回滚或作为历史记录。 |
流程关系：代码通常在动态库中开发，达到一定稳定状态后提升至受控库形成基线，经测试和批准后，最终发布版本存入静态库。
变更请求主要来源于两个方面：
| 因素来源 | 具体描述 | 处理难度比较 |
|---|---|---|
| 外部变更要求 | 来自客户或外部干系人，如修改工作范围、需求等。 | 最难处理。因为IT项目需求变更概率大，且引发的工作量也大，尤其在项目后期。 |
| 内部变更要求 | 来自开发过程内部，如为解决测试中发现的错误而修改源码或设计。 | 相对可控。 |
总结：SCM通过版本控制、变更控制以及动态、受控、静态三库的体系，系统性地管理软件开发中的变更与资产，保障项目在受控状态下有序推进，并维护产品的完整性和可追溯性。
软件质量保证的关注点集中于一开始就避免缺陷的产生，而非事后检查。其主要目标包括：
| 目标 | 核心思想 |
|---|---|
| ① 事前预防 | 着重于缺陷预防，而不是缺陷检查。 |
| ② 早期捕获 | 力求在缺陷刚刚被引入时就将其发现并纠正，防止其扩散到后续阶段。 |
| ③ 作用于过程 | 关注改进软件过程本身，而非仅仅检查最终产品。这能带来更广泛的影响和更大的收益。 |
| ④ 全面贯穿 | 质量保证活动应贯穿于所有开发活动之中，而不是只集中在某个特定点。 |
软件质量保证主要包含以下三个方面的工作：
| 任务 | 具体内容与原则 |
|---|---|
| ① SQA审计与评审 | 对软件工作产品、工具和设备进行审计，评估其是否符合组织规定的标准。 |
| ② SQA报告 | 记录工作结果并生成报告。报告发布需遵循三条原则： 1. SQA与高级管理者之间应有直接沟通渠道。 2. 报告必须发布给软件工程组，但不必发布给项目管理人员。 3. 在可能的情况下，向所有关心软件质量的人员发布。 |
| ③ 处理不符合问题 | 这是SQA的一项重要任务，即跟踪和处理审计中发现的不符合标准或规范的问题。 |
目前国内软件企业主要采用的质量认证模式有两种：
核心总结：软件质量管理通过以预防为核心、过程为导向的质量保证活动，并借助审计、报告和问题处理等任务，系统性地提升软件质量。最终可通过国际或行业标准（如ISO 9000、CMM）进行能力认证。
项目风险是一种不确定的事件或条件，一旦发生，会对项目目标产生某种正面或负面影响。
风险管理是一个系统性的过程，主要包括以下六个活动：
| 序号 | 活动过程 | 核心任务与目标 |
|---|---|---|
| 1 | 风险管理计划编制 | 定义如何实施项目风险管理活动，制定风险管理的整体方案和计划。 |
| 2 | 风险识别 | 判断哪些风险可能影响项目，并将其特征记录在案。 |
| 3 | 风险定性分析 | 评估并综合分析风险的发生概率和影响，对风险进行优先级排序。 |
| 4 | 风险定量分析 | 就已识别的风险对项目整体目标的（数值化）影响进行定量分析。 |
| 5 | 风险应对计划编制 | 针对项目目标，制定提高机会、降低威胁的方案和措施。 |
| 6 | 风险监控 | 在整个项目生命周期中，跟踪已识别的风险、监测残余风险、识别新风险，并评估风险过程有效性。 |
逆向工程源于硬件领域，在软件工程中，其核心思想类似于“分析现有系统以理解其设计”。它是指分析已有程序，旨在寻求比源代码更高层次的抽象表现形式，从而理解、恢复或改进系统的过程。
| 概念 | 定义与说明 |
|---|---|
| 逆向工程 | 分析目标系统，以识别其组件及相互关系，并创建更高抽象层次的系统表示（如设计模型、架构图）。 |
| 重构 | 在同一抽象级别上，转换系统的描述形式（如代码），以改善其内部结构，但不改变其外部行为。 |
| 设计恢复 | 借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等信息。这是逆向工程的核心活动之一。 |
| 再工程 | 对现有系统进行重新开发的完整过程。旨在结合新技术和新需求，全面提升系统。它包括三个关键步骤：逆向工程、新需求的考虑过程和正向工程。 |
| 正向工程 | 不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。通常是从需求或设计出发，生成代码的传统过程。 |
再工程是一个综合性的循环改进过程，其典型流程可以概括为：
[现有系统] → (逆向工程) → [理解与抽象] → (结合新需求) → (正向工程) → [新/改进的系统]
逆向工程所能恢复的信息层次和完整性有所不同，从具体到抽象可分为以下四级：
| 级别 | 包含的信息 | 说明 |
|---|---|---|
| 实现级 | 程序的抽象语法树、符号表、过程的设计表示。 | 最具体的级别，接近代码本身的结构。 |
| 结构级 | 反映程序分量之间相互依赖关系的信息，如调用图、结构图、程序和数据结构。 | 描述了模块/组件间的静态关系。 |
| 功能级 | 反映程序段功能及程序段之间关系的信息，如数据和控制流模型。 | 描述了系统的动态行为与逻辑。 |
| 领域级 | 程序分量或程序实体与应用领域概念之间对应关系的信息，如实体关系模型。 | 最高、最抽象的级别，关联了代码与业务知识。 |
总结：逆向工程是从具体实现（代码）向抽象设计乃至业务领域概念进行回溯和理解的关键技术，是系统维护、演化与再工程的基础。
面向对象设计有一些被广泛认可的基本原则，遵循这些原则有助于构建出灵活、可维护、可扩展的软件系统。以下是七大核心设计原则：
| 设计原则 | 核心思想与重要特性 |
|---|---|
| 单一职责原则 (SRP) | 一个类应该只负责一项职责，不能将太多的职责放在一个类中。目标是设计功能单一的类。 |
| 开闭原则 (OCP) | 对扩展开放，对修改关闭。即软件实体（类、模块、函数等）应该在不修改原有代码的基础上，通过扩展来实现新的功能。 |
| 里氏替换原则 (LSP) | 所有引用基类（父类）的地方必须能透明地使用其子类的对象。子类可以完全替换父类。具体要求： 1. 子类可以增加自己特有的方法。 2. 子类重载父类方法时，前置条件（输入参数）应更宽松。 3. 子类实现父类抽象方法时，后置条件（返回值）应更严格。 |
| 依赖倒转原则 (DIP) | 针对接口（抽象）编程，而不要针对实现（具体的类）编程。即高层模块不应依赖低层模块，二者都应依赖其抽象。 |
| 接口隔离原则 (ISP) | 使用多个专门的、细粒度的接口，而不使用单一的、臃肿的总接口。客户端不应该被强迫依赖它不用的接口。 |
| 合成复用原则 (CRP) | 在系统中应尽量多使用组合(has-a)/聚合(contains-a)关系，少使用继承(is-a)关系。因为继承带来的父子强耦合会降低灵活性。组合关系更松散。 |
| 迪米特法则 (LoD) (最少知识原则) |
一个对象应该对其他对象保持最少的了解（“不要和陌生人说话”）。只与直接的朋友通信，降低类之间的耦合度。 |
核心总结：
这些原则共同的目标是降低系统的耦合度，提高内聚性，增强可维护性和可扩展性。其中，开闭原则是面向对象设计的终极目标，而依赖倒转原则是实现开闭原则的主要手段。
在系统运行过程中，软件需要维护的原因多样。根据维护的原因不同，可以将软件维护分为以下4种类型。
| 维护类型 | 核心原因与目的 | 形象比喻 |
|---|---|---|
| 改正性维护 | 为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用。 | 知错能改 |
| 适应性维护 | 为适应变化的外部环境（新的硬、软件配置）或数据环境（数据库、数据格式、存储介质等）。 | 与时俱进 |
| 完善性维护 | 为满足用户提出的新功能与性能要求，扩充功能、增强性能、提高效率或可维护性。 | 锦上添花 |
| 预防性维护 | 预先提高软件的可维护性、可靠性等，为未来改进打下基础。即“把今天的方法学用于昨天的系统以满足明天的需要”。 | 防患于未然 |
总结：软件维护并非只是“修bug”，它是一个持续的质量与价值提升过程，涵盖了从纠正错误、适应环境、增强功能到前瞻性优化的全部活动。
系统转换是指新系统开发完毕、投入运行，以取代现有（旧）系统的过程。这是一个关键阶段，需要考虑多方面问题，以确保新旧系统平稳交接。
系统转换主要有以下三种计划，各有其适用场景和特点：
| 转换计划 | 核心描述 | 适用场景 | 优点 | 缺点与风险 |
|---|---|---|---|---|
| 直接转换 (直接切换) |
在某一确定时间点，现有系统被新系统直接、完全取代。 | 新系统不复杂，或现有系统已经完全不能使用的情况。 | 节省成本，实施过程简单直接。 | 风险极大。一旦新系统出现问题，业务将面临中断，无回退方案。 |
| 并行转换 | 新系统与老系统并行工作一段时间，新系统经过充分试运行后再完全取代旧系统。 | 适用于大型、关键的信息系统。 | 风险极低。新系统有问题不影响业务运行；可比较新旧系统性能，验证结果。 | 耗费大量人力和时间资源（需两套系统同时维护）；难以控制两个系统间的数据转换与同步。 |
| 分段转换 (逐步转换) |
分期分批逐步转换。是直接和并行转换的结合，将大型系统划分为多个子系统，依次试运行和转换。 | 适用于大型、复杂的项目，允许分阶段实施和验证。 | 风险可控，每次只转换一个子系统，影响范围小；资金和人力可分阶段投入。 | 更耗时（整体转换周期长）；新旧系统在过渡期混合运行，需要协调好接口与数据一致性问题，管理复杂度高。 |
核心提示：对于重要业务系统，并行转换因其安全性常被优先考虑；而对于模块化清晰的大型系统，分段转换是更可行和稳妥的策略。
遗留系统指的是任何基本上不能进行修改和演化以满足新的、变化了的业务需求的信息系统。
核心：该模型为决策者提供了清晰的系统评估与处置框架。
数据库系统的三级模式（外模式、概念模式、内模式）与两级映像是实现数据独立性和多用户共享的核心架构。它有效地将用户的应用程序与数据库的物理存储分离开来。
| 模式层级 | 别称 | 定义与描述 | 数量说明 |
|---|---|---|---|
| 外模式 | 子模式、用户模式 | 数据库用户（包括应用程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述。 | 一个数据库可有多个外模式，每个用户或用户组对应一个。 |
| 概念模式 | 模式、逻辑模式 | 数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。 | 一个数据库只有一个概念模式。 |
| 内模式 | 存储模式 | 数据物理结构和存储方式的描述，是数据在数据库内部的表示方式（如存储记录类型、索引组织方式等）。 | 一个数据库只有一个内模式。 |
两级映像是连接三个抽象级别的桥梁，是实现数据独立性的关键。
| 映像 | 作用 | 保障的独立性 | 机制说明 |
|---|---|---|---|
| 外模式/概念模式映像 | 定义了外模式与概念模式之间的对应关系。 | 逻辑独立性 | 当概念模式改变时（如增加新关系、新属性），由数据库管理员修改此映像，可使外模式保持不变，从而基于外模式的应用程序也无需修改。 |
| 概念模式/内模式映像 | 定义了概念模式与内模式之间的对应关系。 | 物理独立性 | 当内模式改变时（如存储结构、存储设备变化），由数据库管理员修改此映像，可使概念模式保持不变，从而应用程序同样无需改变。 |
用户或应用程序访问数据库的典型路径如下：
根据您提供的关于数据库“三级模式两级映像”架构的PPT图片，已为您整理出清晰的结构化笔记。
数据库系统的三级模式（外模式、概念模式、内模式）与两级映像是实现数据独立性和多用户共享的核心架构。它有效地将用户的应用程序与数据库的物理存储分离开来。
| 模式层级 | 别称 | 定义与描述 | 数量说明 |
|---|---|---|---|
| 外模式 | 子模式、用户模式 | 数据库用户（包括应用程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述。 | 一个数据库可有多个外模式，每个用户或用户组对应一个。 |
| 概念模式 | 模式、逻辑模式 | 数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。 | 一个数据库只有一个概念模式。 |
| 内模式 | 存储模式 | 数据物理结构和存储方式的描述，是数据在数据库内部的表示方式（如存储记录类型、索引组织方式等）。 | 一个数据库只有一个内模式。 |
两级映像是连接三个抽象级别的桥梁，是实现数据独立性的关键。
| 映像 | 作用 | 保障的独立性 | 机制说明 |
|---|---|---|---|
| 外模式/概念模式映像 | 定义了外模式与概念模式之间的对应关系。 | 逻辑独立性 | 当概念模式改变时（如增加新关系、新属性），由数据库管理员修改此映像，可使外模式保持不变，从而基于外模式的应用程序也无需修改。 |
| 概念模式/内模式映像 | 定义了概念模式与内模式之间的对应关系。 | 物理独立性 | 当内模式改变时（如存储结构、存储设备变化），由数据库管理员修改此映像，可使概念模式保持不变，从而应用程序同样无需改变。 |
用户或应用程序访问数据库的典型路径如下：
[用户/应用程序] (通过 主语言 + 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 精要
1. 本质
查找在关系 R 中，能“配齐”关系 S 中所有公共属性值的元组。
形式：R(X, Y) ÷ S(Y, Z)，Y 为公共属性，X 为专属属性。
2. 核心步骤
① 求象集：找出 R 中每个 X 值对应的所有 Y 组合。
② 取投影：获取 S 在 Y 上的所有值组合（去重）。
③ 判包含：若某 X 的象集包含 S 的 Y 投影，则该 X 入选结果。
3. 关键与特例
4. 典型应用
用于查询“具有所有…”的问题，如“选修了全部课程的学生”、“供应了所有零件的供应商”。
Armstrong公理是从已知的一组函数依赖（Functional Dependencies, F）出发，推导出蕴含于其中的其他函数依赖的一套形式化推理规则。该公理系统是数据库模式规范化的理论基础。
设关系模式 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出发，仅用这三条规则推导出来。
根据上述三条基本公理，可以推导出以下三个常用的实用规则：
| 规则 | 名称 | 内容 | 说明与用途 |
|---|---|---|---|
| 合并规则 (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
高级别的范式自动满足低级别范式的要求。规范化过程就是通过模式分解，从低级别范式向高级别范式转化的过程。
核心概念：
X → Y 中，X 称为决定因素。数据库系统运行的基本工作单位是事务。事务是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。事务相当于操作系统中的进程。
为了保证数据的正确性与一致性，数据库事务必须满足以下四个核心属性（ACID）：
| 属性 | 英文 | 核心要求与解释 |
|---|---|---|
| 原子性 (Atomicity) |
Atomicity | 事务中包含的所有操作被视为一个不可分割的整体。这些操作要么全部成功执行，要么全部不执行（回滚到事务开始前的状态）。 |
| 一致性 (Consistency) |
Consistency | 事务的执行必须使数据库从一个一致性状态转变到另一个一致性状态。即事务的执行结果必须保证数据库中的数据满足所有的完整性约束。 |
| 隔离性 (Isolation) |
Isolation | 一个事务的执行过程不能被其他并发事务干扰。多个并发事务的执行应当相互隔离，使得每个事务都感觉不到有其他事务在同时执行。 |
| 持久性 (Durability) |
Durability | 也称为永久性。一旦一个事务成功提交，它对数据库所做的任何改变就是永久性的，即使后续系统发生故障，这些改变也不会丢失。 |
核心总结：ACID属性共同构成了数据库事务处理的可靠性与正确性的基石。其中：
在多用户并发访问数据库的环境下，为了保证事务的隔离性（ACID特性之一）和数据的一致性，数据库系统采用封锁作为实现并发控制的主要技术。
主要有两种基本的封锁类型，其核心区别在于允许的“读/写”权限不同。
| 封锁类型 | 简称 | 核心定义与规则 | 允许的操作 | 核心特性与目的 |
|---|---|---|---|---|
| 排他型封锁 (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)：可以是一个数据项、一条记录、一个数据集，乃至整个数据库。
目的：通过这两种锁及其相容性控制，封锁技术能够有效协调并发事务的交叉执行，防止丢失修改、读“脏”数据、不可重复读等问题，从而保障事务的隔离性与数据一致性。
锁的使用规则称为封锁协议。不同级别的协议规定了何时申请锁、何时释放锁，以及持有锁的时长，这直接决定了事务的隔离级别和数据一致性保障程度。下表详细对比了三个级别的封锁协议。
| 封锁协议级别 | 核心内容 (加锁规则) | 优点 (解决的问题) | 缺点 (仍存在的问题) |
|---|---|---|---|
| 一级封锁协议 | 事务在修改数据之前，必须对该数据加X锁，直到事务结束才释放。 对只读数据可以不加锁。 |
防止 “丢失修改” (Lost Update) | 对不加锁的只读事务，可能 “读脏数据” (Dirty Read) 或 “不可重复读” (Non-repeatable Read)。 |
| 二级封锁协议 | 在一级协议基础上，增加： 事务在读取数据之前，必须对该数据加S锁，读完后即可释放S锁。 （X锁仍需保持到事务结束） |
防止 “丢失修改” 防止 “读脏数据” |
对加了S锁的事务，由于S锁提前释放，在其事务周期内仍可能 “不可重复读”。 |
| 三级封锁协议 | 在一级协议基础上，增加： 事务在读取数据之前，必须对该数据加S锁，并且直到事务结束时才释放S锁。 （X锁与S锁均保持到事务结束） |
防止 “丢失修改” 防止 “读脏数据” 防止 “不可重复读” |
并发度最低，对系统性能影响最大。 |
各级协议核心与演进总结：
关键理解：封锁协议的级别越高，规则越严格，能防止的并发问题越多，但事务的并发度也越低，系统开销越大。这是一个在数据一致性和系统性能之间进行权衡的过程。
分布式数据库系统通过增加分布透明性，在传统集中式数据库的三级模式（外模式、模式、内模式）基础上进行了扩展，形成了典型的六层模式结构。
| 模式层级 | 描述 | 说明 |
|---|---|---|
| 1. 全局外模式 | 全局应用的用户视图，是全局概念模式的子集。 | 代表终端用户看到的逻辑数据结构。 |
| 2. 全局概念模式 | 定义了分布式数据库中所有数据的整体逻辑结构，如同一个集中式数据库的概念模式。 | 描述了数据本身，不涉及数据的分布细节。 |
| 3. 分片模式 | 描述了全局数据如何被划分和逻辑分段（分片）的过程。每个全局关系可以被划分为若干互不重叠的部分（分片）。 | 分片原则：完备性、可重构、不相交。 |
| 4. 分布模式 | 描述了逻辑片段在物理上被分配到各个场地（站点） 的映像关系。一个片段在物理上可以存放于一个或多个场地。 | 定义了分片的物理存储位置。 |
| 5. 局部概念模式 | 定义在每个场地上的局部数据的逻辑结构，是其局部数据库的概念模式。 | 是全局概念模式被分段和分配在该场地的结果映射。 |
| 6. 局部内模式 | 描述每个场地上局部数据的物理存储结构。 | 与传统数据库的内模式定义相同。 |
结构关系：全局外模式 → 全局概念模式 → 分片模式 → 分布模式 → 局部概念模式 → 局部内模式
数据分片是将全局数据进行逻辑划分。分片时必须遵循三个基本原则：
数据分配是指将分片后得到的逻辑片段具体分配到网络中各场地的过程。主要有四种策略：
| 分配策略 | 核心描述 | 特点 |
|---|---|---|
| 集中式 | 所有的数据片段都安排在同一个场地上。 | 本质上非分布式，无冗余，可靠性低，依赖中心节点。 |
| 分割式 | 所有数据只有一份，被分割成若干逻辑片段，每个片段被指派到一个特定的、互不重复的场地。 | 无冗余，易实现，但存在数据访问的局部性。 |
| 全复制式 | 数据在每个场地重复存储，每个场地都拥有一个完整的数据副本。 | 冗余度最高，可靠性高，但同步更新开销大。 |
| 混合式 | 介于分割式和全复制式之间，数据被分片后，各片段按需被复制并分配到多个场地。 | 兼顾了可靠性与存储开销，是实际中最常用的策略。 |
总结：分布式数据库通过六级模式实现了从全局逻辑到局部物理的映射与透明性，并通过分片与分配策略，在数据管理的集中统一性与物理存储的分布局部性之间取得平衡。
ABSD方法建立在以下三个基础之上：
| 基础 | 核心内容与说明 |
|---|---|
| 1. 功能的分解 | 在功能分解中，ABSD方法使用已有的、基于模块的内聚和耦合技术。 |
| 2. 选择体系结构风格 | 通过选择特定的体系结构风格来实现既定的质量属性和商业需求。 |
| 3. 软件模板的使用 | 利用一些软件系统固有的、可复用的结构模式（软件模板） 来指导和加速设计。 |
| 序号 | 子过程 | 核心任务与产出 |
|---|---|---|
| 1 | 体系结构需求 | 明确并定义驱动体系结构设计的商业、质量与功能需求。 |
| 2 | 体系结构设计 （图中标红） |
基于需求，选择体系结构风格，定义系统的高层结构、组件及其交互关系。 |
| 3 | 体系结构文档化 （图中标红） |
将设计决策、体系结构视图和组件规格等正式记录下来，形成可供沟通和评估的文档。 |
| 4 | 体系结构复审 （图中标红） |
评估体系结构设计方案是否满足需求，特别是质量属性（如性能、安全性），并识别潜在风险。 |
| 5 | 体系结构实现 （图中标红） |
依据已确定的体系结构，进行具体设计与编程，将体系结构转化为具体的软件构件和类。 |
| 6 | 体系结构演化 （图中标红） |
在系统运行和维护阶段，对体系结构进行调整和优化，以适应新的需求或环境变化。 |
总结：ABSD是一种以软件体系结构为核心、受多类需求驱动、并遵循自顶向下递归细化过程的系统化设计方法。其三大基础确保了从需求到设计的可追踪性和设计决策的有效性。
ABSDM模型将开发过程清晰地划分为六个子过程，它们顺序执行但也允许迭代。
ABSDM是一个严谨的、以架构为中心的开发框架。它通过 “需求→设计→文档化→复审→实现→演化” 的闭环流程，确保了软件系统从概念到实现再到维护的整个生命周期都处于受控状态，并能灵活应对变化，最终目标是构建出高质量、可维护、可演化的软件系统。
软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。
以下是五种主要的通用软件架构风格及其典型实例：
| 风格类别 | 核心思想 | 典型实例 |
|---|---|---|
| 数据流风格 | 以数据流动为主要驱动力，构件是过滤器，连接件是管道。 | 批处理序列、管道/过滤器 |
| 调用/返回风格 | 通过明确的调用机制来控制系统逻辑流。 | 主程序/子程序、面向对象风格、层次结构、客户端/服务器 |
| 独立构件风格 | 构件是独立的进程或对象，通过消息传递或事件进行通信。 | 进程通信、事件系统 |
| 虚拟机风格 | 通过一个“虚拟机”或解释器来执行自定义的指令或规则。 | 解释器、基于规则的系统 |
| 仓库风格 | 围绕一个中心数据仓库（如数据库、黑板）来组织构件，构件通过该仓库进行交互。 | 数据库系统、超文本系统、黑板系统 |
总结：不同的架构风格为软件系统提供了不同的高层组织模式、交互范式和约束规则，是架构师在设计系统时进行选择和决策的重要基础。
以数据流动为主要驱动力，构件是过滤器，连接件是管道。
| 优点 | 缺点 |
|---|---|
| 1. 高内聚、低耦合 | 1. 交互性差 |
| 2. 良好的重用性/可维护性 | 2. 复杂性较高 |
| 3. 可扩展性（标准接口适配） | 3. 性能差（每个过滤器都需解析与合成数据） |
| 4. 良好的隐蔽性 | |
| 5. 支持并行处理 |
通过明确的调用机制来控制系统逻辑流，是一种“分而治之”的策略。
围绕一个中心数据仓库来组织构件，构件通过该仓库进行交互。
通过一个“虚拟机”或解释器来执行自定义的指令或规则。
| 优点 | 缺点 | 要点 |
|---|---|---|
| 可以灵活应对自定义场景 | 复杂度较高 | 1. 解释器：适用于需要“自定义规则”的场合。 2. 规则为中心：在解释器基础上增加经验规则，适合于专家系统。 |
该风格主要强调系统中的每个构件都是相对独立的个体，它们之间不直接通信，以降低耦合度，提升灵活性。
| 类别 | 核心描述 | 连接件 | 特点 |
|---|---|---|---|
| 进程通信风格 | 构件是独立的过程。 | 消息传递 | 构件是命名过程，消息传递方式多样（点到点、异步/同步、远程过程调用）。 |
| 事件系统风格 (隐式调用) |
构件不直接调用过程，而是触发或广播一个或多个事件。系统自动调用在该事件中注册的所有过程。 | 事件触发与响应 | 触发者不知哪些构件会受影响，不能假定处理顺序。常包含显式调用作为补充。涉及事件源、事件、事件管理器、事件处理器等角色。 |
| 优点 | 缺点 |
|---|---|
| 1. 松耦合。 | 1. 构件放弃了对系统计算的控制。 |
| 2. 良好的复用性/可修改性/可扩展性。 | 2. 数据交换问题。 |
| 3. 过程语义依赖于被触发事件的上下文约束，正确性推理困难。 |
给定值 → 控制器 → 执行器 → 被控对象给定值 → 比较器 → 控制器 → 执行器 → 被控对象 → (反馈量) → 比较器C2风格可以概括为：通过连接件绑定在一起的、按照一组规则运作的并行构件网络。
MDA (Model-Driven Architecture) 是OMG提出的一种基于模型的软件开发框架，其核心是通过不同抽象级别的模型来驱动开发。
| 模型层级 | 全称 | 描述 |
|---|---|---|
| PIM | 平台独立模型 (Platform Independent Model) |
具有较高抽象层次，独立于任何具体实现技术的模型。 |
| PSM | 平台相关模型 (Platform Specific Model) |
为某种特定实现技术量身定做的模型，用该技术的可用构造来描述系统。PIM会被变换成一个或多个PSM。 |
| Code | 代码 | 用源代码对系统进行的具体描述。每个PSM都会被变换成代码。 |
核心转换关系：PIM → (通过映射Mappings) → PSM → Code
该表格对常见软件架构风格进行了归纳总结，特别突出了常考的关键字、典型实例及其核心思想，便于快速回顾与区分。
| 架构风格类别与名称 | 常考关键字与典型实例 | 核心简介 |
|---|---|---|
| 数据流风格 | 以数据流动为主要驱动力。 | |
| 数据流 - 批处理 | 传统编译器；每个阶段的结果作为下一阶段的输入；区别在于数据以整体为单位处理。 | 处理步骤一个接一个顺序执行，数据是一批一批地传递。 |
| 调用/返回风格 | 通过明确的调用机制来控制系统逻辑流。 | |
| 调用/返回 - 主程序/子程序 | 显式调用，主程序直接调用子程序。 | |
| 调用/返回 - 面向对象 | 对象是构件，通过对象调用其封装的方法和属性。 | |
| 调用/返回 - 层次结构 | 分层，每层最多影响其上下两层，有调用关系。 | 系统组织成层次结构，上层使用下层的服务。 |
| 独立构件风格 | 构件相对独立，通过间接机制通信。 | |
| 独立构件 - 进程通信 | 进程间独立的消息传递，可以是同步或异步的。 | 构件是独立的进程，通过消息传递进行通信。 |
| 独立构件 - 事件系统 (事件驱动/隐式调用) |
事件触发推动动作；实例：程序语言的语法高亮、语法错误提示。 | 构件不直接调用，而是发布或订阅事件，由事件驱动后续动作。 |
| 虚拟机风格 | 通过一个“解释器”或“引擎”来执行自定义的指令或规则。 | |
| 虚拟机 - 解释器 | 自定义流程，按流程执行；规则可随时改变，灵活定义，业务灵活组合。 | 包含解释引擎、存储区、数据结构，用于解释执行自定义的规则或语言。 |
| 虚拟机 - 规则系统 | 用于决策支持系统(DSS)、人工智能和专家系统。 | 包含规则集、规则解释器、选择器和工作内存，基于规则进行推理。 |
| 仓库风格 (以数据为中心) |
围绕一个中心数据仓库来组织构件。 | |
| 仓库 - 数据库 | 现代编译器的集成开发环境(IDE)。 | 中央共享数据源（数据库），配合多个独立的处理单元。 |
| 仓库 - 超文本 | IDE，以数据为中心。 | 通过网状链接组织信息，多用于互联网。 |
| 仓库 - 黑板 | 又称数据共享风格；用于语音识别、知识推理等问题复杂、解空间很大、求解过程不确定的软件系统。 | 包含三个核心部分：黑板（共享数据）、知识源（独立求解模块）、控制（协调机制）。 |
| 闭环风格 (控制环风格) |
适用于需要根据反馈进行自动调节的系统。 | |
| 闭环 - 过程控制 | 实例：汽车巡航定速、空调温度调节；设定参数，并不断调整。 | 系统发出控制命令并接受反馈，循环往复以达到并维持设定的状态（平衡）。 |
| C2风格 | 构件和连接件、顶部和底部。 | 通过连接件绑定在一起的、按照一组规则运作的并行构件网络。构件间通过连接件的顶部和底部规则连接。 |
总结归类：
软件复用是一种系统化的软件开发过程，其核心在于：
| 类型 | 核心描述 | 特点 |
|---|---|---|
| 机会复用 (或称偶然复用) |
在开发过程中，只要发现有可复用的资产，就对其进行复用。 | 自发的、非计划性的复用。 |
| 系统复用 (或称有规划复用) |
在开发之前，就要进行规划，以决定哪些部分需要复用、如何复用。 | 有计划的、系统性的复用，是更高级的形态。 |
复用的实施是一个持续循环的过程，主要包含以下三个阶段：
[阶段1：构造/获取可复用资产]
↓ (入库)
[阶段2：管理可复用资产] → (形成) → [可复用资产库]
↓ (选择/定制/组装)
[阶段3：使用可复用的资产]
流程详解：
核心思想：软件架构复用不仅是一种技术，更是一种需要系统化管理和持续积累的工程实践。
在DSSA上下文中，“领域”有垂直和水平两种含义，代表了复用的不同方向与层次。
| 领域类型 | 核心描述 | 特点与区别 |
|---|---|---|
| 垂直域 | 定义一个特定的系统族，包含整个系统族内的多个系统。其结果是可在该领域中作为系统可行解决方案的一个通用软件架构。 | 相同领域，深入 针对同一个业务领域内部，提供完整的、通用的解决方案框架。 |
| 水平域 | 定义在多个系统和多个系统族中，功能区域的共有部分。它在子系统级上涵盖多个系统族的特定功能，无法为整个系统提供完整的通用架构。 | 不同领域，平移 关注跨不同业务领域的、可共享的通用子功能或模块。 |
DSSA的建设与应用主要包含以下三个顺序且迭代的基本活动：
| 活动 | 主要目标 | 核心产出与描述 |
|---|---|---|
| 领域分析 | 获得领域模型 | 描述领域中系统之间的共同需求（领域需求）。 |
| 领域设计 | 获得DSSA本身 | 描述针对领域模型所表达需求的解决方案。它不是单个系统的设计，而是能够适应领域中多个系统需求的一个高层次设计。 |
| 领域实现 | 开发和组织可重用信息 | 依据领域模型及DSSA，进行具体的开发，并构建和组织可复用的资产（如构件、代码、文档等）。 |
总结：DSSA是一种针对特定问题域（如金融、电信、医疗）的系统化复用方法。它通过垂直/水平两种方式界定复用范围，并通过分析→设计→实现的活动循环，构建可支持该领域内多个应用快速开发的高层通用架构（DSSA）及可复用资产库。
DSSA的建立和应用需要不同专长的人员协同工作，各角色及其职责如下：
| 角色 | 人员背景/要求 | 主要职责 |
|---|---|---|
| 领域专家 | 有经验的用户，或从事该领域中系统的需求、设计、实现及项目管理的有经验的软件工程师。 | 提供深入的领域知识，确保DSSA符合真实的业务需求与约束。 |
| 领域分析师 | 由具有知识工程背景的有经验的系统分析员担任。 | 负责领域分析，识别和定义领域内的共同需求和概念，建立领域模型。 |
| 领域设计人员 | 由有经验的软件设计人员担任。 | 负责领域设计，基于领域模型创建或精化DSSA（即领域通用的高层次设计）。 |
| 领域实现人员 | 由有经验的程序设计人员担任。 | 负责领域实现，根据DSSA开发、获取和组织可复用的产品单元（如构件、代码、工具）。 |
DSSA的建立是一个并发的、递归的、反复的螺旋式过程，通常包含以下5个阶段：
| 阶段 | 核心任务与输出 |
|---|---|
| 阶段1：定义领域范围 | 明确DSSA所覆盖的领域边界。主要输出是领域内应用需要满足的一系列用户需求。 |
| 阶段2：定义领域特定的元素 | 识别和标准化领域内的核心概念与术语。主要活动是编撰领域字典和领域术语的同义词词典。 |
| 阶段3：定义领域特定的设计和实现需求约束 | 明确在该领域内进行系统设计和实现时必须遵循的特定约束与规则。 |
| 阶段4：定义领域模型和架构 | 创建领域模型（描述领域概念与关系）和DSSA本身（描述通用的解决方案架构）。这是将需求转化为设计的关键阶段。 |
| 阶段5：产生、搜集可重用的产品单元 | 基于已定义的DSSA，实际开发、获取或搜集具体的可复用资产，如构件库、代码框架、生成工具等。 |
过程特点：这五个阶段并非严格线性，而是并发、递归和反复的。在实践中，团队可能需要根据后续阶段的发现，回溯并调整前一阶段的产出，形成一个不断迭代和深入的“螺旋”式演进过程。
总结：DSSA的成功依赖于领域专家、分析师、设计人员和实现人员的紧密协作，并通过一个非线性的、五阶段的螺旋过程，逐步明确范围、统一语言、定义约束、建立架构，并最终产出可复用的资产，从而系统化地支持特定领域内的高效开发。
特定领域软件架构 (DSSA) 是一个针对特定问题领域的、标准化的软件框架，旨在支持该领域内一系列应用的快速开发。
DSSA的实施包含两个相辅相成的工程过程：
| 过程 | 核心目标 | 主要活动与产出 |
|---|---|---|
| 领域工程 (Domain Engineering) |
为一组相近或相似的应用建立基本能力和必备基础。 | 覆盖建立可重用软件元素的所有活动，产出领域通用的资产（如架构、模型、构件、工具）。 |
| 应用工程 (Application Engineering) |
通过重用领域工程产生的软件资源，开发出满足具体用户需求的应用软件。 | 以领域通用体系结构为框架，进行具体应用的开发、测试与部署。 |
关系：领域工程生产可复用资产，应用工程消费这些资产。两者共同构成DSSA的完整生命周期。
示意图清晰地展示了DSSA中三类核心角色及其所处的环境与工作内容：
| 角色 | 工作环境 | 核心职责与工作内容 |
|---|---|---|
| 领域构架师 (领域工程师) |
领域开发环境 | 负责领域工程。工作围绕领域模型、参考需求、参考结构（构架） 展开，并产出开发工具等可复用资产。 |
| 应用工程师 | 领域特定的应用开发环境 | 负责应用工程。在领域构架师提供的环境下，将领域通用体系结构实例化，开发出具体的应用。 |
| 操作员 (最终用户) |
应用执行环境 | 使用应用工程师交付的、最终部署在运行环境中的具体应用系统。 |
总结：DSSA通过领域工程构建可复用的领域资产库和通用架构，再通过应用工程高效地复用这些资产生产具体应用。领域构架师、应用工程师、操作员在开发、应用、运行三个不同环境中各司其职，协同完成从领域知识到具体软件产品的转化。
UML 模型由事务 (Things)、关系 (Relationships) 和图 (Diagrams) 三大要素构成。其中，事务是UML模型中最基本的构成元素，代表了被抽象化的模型概念。UML 中共有4种基本的事务类型。
| 事务 | 描述 |
|---|---|
| 类 (Class) | 描述具有相同属性、方法、关系和语义的一组对象。 |
| 接口 (Interface) | 描述一个类或构件所提供服务的操作集合。 |
| 协作 (Collaboration) | 定义一组角色及其交互，共同完成某个特定功能。 |
| 用例 (Use Case) | 定义一组动作序列，描述系统与参与者交互所产生的、对参与者有价值的结果。 |
| 主动类 (Active Class) | 其对象至少拥有一个进程或线程的类，能够发起控制活动。 |
| 构件 (Component) | 系统中可替换的物理部分，实现一组接口。 |
| 制品 (Artifact) | 软件开发过程中的物理实体（如源码文件、可执行文件、脚本等）。 |
| 结点 (Node) | 运行时存在的物理计算资源（如服务器、硬件设备）。 |
总结：四种事务分别从静态结构、动态行为、逻辑组织和辅助说明四个维度，共同构成了描述软件系统所需的完整概念集合。
UML 模型由事务 (Things)、关系 (Relationships) 和图 (Diagrams) 三大要素构成。其中，关系是描述事务之间如何相互联系和协作的基本方式。UML 中定义了四种基本关系。
| 关系名称 | 核心解释 | 典型举例 | 图形表示 |
|---|---|---|---|
| 依赖 (Dependency) |
一个事物（源）的语义变化依赖于另一个事物（目标）的语义。是最弱的一种关系。只要有使用关系就算依赖。 | 人 依赖 食物 | -----→ （虚线箭头） |
| 关联 (Association) |
两个类之间存在某种语义上的联系。描述了对象之间的一组连接（链）。 | 人 和 公司 之间存在雇佣关联 | 实线（可带箭头、多重性） |
| 泛化 (Generalization) |
一种特殊/一般关系，即继承关系。描述父类与子类之间的关系。 | 老师 是一种特殊的 人 | ─────▶ （实线空心三角箭头） |
| 实现 (Realization) |
规定接口和实现该接口的类或组件之间的关系。 | 类 实现 某个接口 | ------- （虚线空心三角箭头） |
关联关系（整体与部分的关系）根据耦合强弱，可进一步细分为三种：
| 关联子类型 | 核心解释 | 耦合强度 | 典型举例 | 图形表示 |
|---|---|---|---|---|
| 普通关联 (Association) |
类之间的一种语义联系，描述了一组对象之间的连接。 | 一般 | 学生 选修 课程 | ── 或 ─→ |
| 聚合 (Aggregation) |
整体与部分的关系，但部分可以脱离整体而独立存在。 | 较弱 | 狼 是 狼群 的一部分 | ──◇ （实线空心菱形箭头） |
| 组合 (Composition) |
整体与部分的关系，且部分不能脱离整体而独立存在，生命周期一致。 | 最强 | 车轮 是 汽车 的一部分 | ──◆ （实线实心菱形箭头） |
关键对比：
- 依赖 vs. 关联：依赖是临时性的“使用”关系（如参数传递）；关联是结构性的“拥有”关系（如类的属性）。
- 聚合 vs. 组合：都是“has-a”关系。聚合是松散的（电脑和其外设），组合是紧密的、共生的（公司与部门）。组合的耦合度比聚合更强。
总结：理解这四种关系及其强弱（依赖<关联<聚合<组合<泛化/实现），是绘制准确UML图、进行面向对象设计的基础。其中，泛化是“is-a”关系，聚合/组合是“has-a”关系。
UML 采用“4+1”视图模型来描述一个系统的不同侧面。每种视图从特定角度关注系统，并使用不同的 UML 图进行建模。
| 视图 | 核心关注点 | 描述 | 包含的主要 UML 图 |
|---|---|---|---|
| 用例视图 (Use Case View) |
功能需求 | 描述系统应该提供的功能，是从最终用户（外部参与者）角度看到的外部行为。是需求分析的起点和核心。 | 用例图 |
| 逻辑视图 (Logical View) |
静态结构与动态行为 | 描述系统内部如何实现功能，聚焦于系统的逻辑组成、对象协作和状态变化。也称为设计视图。 | 类图、对象图、状态图、顺序图、通信图、活动图 |
| 进程视图 (Process View) |
并发性、同步与通信 | 描述系统的并发性 aspects，如线程、进程及其之间的交互、同步和通信机制。关注运行时行为。 | 状态图、顺序图、通信图、活动图、构件图、部署图 |
| 实现视图 (Implementation View) |
代码构件的组织 | 描述程序代码的物理组织结构，以及模块、库、构件之间的编译依赖关系。 | 构件图 |
| 部署视图 (Deployment View) |
软硬件的物理架构 | 定义系统在运行时的物理拓扑结构，描述硬件节点、软件制品（如可执行文件）的部署位置及连接。 | 部署图 |
核心思想：这五种视图共同构成了对软件系统完整、多角度的描述。用例视图是驱动其他视图的“+1”视图，确保系统满足用户需求；其余四种视图（逻辑、进程、实现、部署）则分别从结构、并发、实现和物理层面详细阐述系统的构建与运行方式。
一个完整的设计模式描述通常包含以下四个基本要素：
| 要素 | 描述 |
|---|---|
| ① 模式名称 | 一个助记名，用于描述设计模式、解决方案和效果。帮助思考、交流和记录设计。 |
| ② 问题 | 描述了模式的应用场景，即在何种情况下、面对何种设计问题时使用该模式。 |
| ③ 解决方案 | 描述了设计的组成部分、职责、协作关系。通常不针对具体情景，而是一个通用的、可复用的设计方案模板。 |
| ④ 效果 | 描述了应用该模式带来的结果、权衡（优缺点）及应考虑的约束。 |
经典的GoF设计模式共有23种，可以从两个不同维度进行分类：
根据模式的主要目的和应用场景，可分为三类：
| 类别 | 核心关注点 | 说明 |
|---|---|---|
| 创建型模式 (Creational Patterns) |
与对象的创建有关。 | 将对象的创建与使用分离，使系统在对象创建时更加灵活、独立。 |
| 结构型模式 (Structural Patterns) |
处理类或对象的组合。 | 描述如何将类或对象按某种布局组成更大的结构，以获得更灵活、高效的架构。 |
| 行为型模式 (Behavioral Patterns) |
对类或对象怎样交互和怎样分配职责进行描述。 | 关注对象间的通信、职责委派，以及算法和控制的流程。 |
根据模式是主要作用于类还是对象，可分为两类：
| 类别 | 核心应用对象 | 说明 |
|---|---|---|
| 类设计模式 (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 设计模式按照其范围（类/对象）和目的（创建型/结构型/行为型）两个维度的分类总览。
| 范围 | 创建型 | 结构型 | 行为型 |
|---|---|---|---|
| 类 | 工厂方法模式 | 适配器模式（类） | 解释器模式 模板方法模式 |
| 对象 | 抽象工厂模式 生成器模式 原型模式 单例模式 |
适配器模式（对象） 桥接模式 组合模式 装饰模式 外观模式 享元模式 代理模式 |
责任链模式 命令模式 迭代器模式 中介者模式 备忘录模式 观察者模式 状态模式 策略模式 访问者模式 |
说明：
信息安全旨在保护信息系统及其处理、传输、存储的信息免受未经授权的访问、使用、披露、破坏、修改或销毁。
信息安全旨在保护信息系统及其处理、传输、存储的信息免受未经授权的访问、使用、披露、破坏、修改或销毁。
| 要素 | 核心定义与要求 |
|---|---|
| 机密性 | 确保信息不暴露给未授权的实体或进程。 |
| 完整性 | 确保只有得到允许的人才能修改数据，并且能够判别出数据是否已被篡改。 |
| 可用性 | 确保得到授权的实体在需要时可以访问数据，攻击者不能占用所有资源而阻碍授权者的工作。 |
| 可控性 | 可以控制授权范围内的信息流向及行为方式。 |
| 可审查性 | 对出现的信息安全问题提供调查的依据和手段。 |
信息安全的范围通常包括物理设备、数据、内容与行为四个层面的安全。
| 安全层面 | 核心定义与所包含的方面 |
|---|---|
| 设备安全 | 信息系统设备的安全是信息系统安全的物质基础。它包含以下三个方面： 1. 稳定性：设备在一定时间内不出故障的概率。 2. 可靠性：设备能在一定时间内正常执行任务的概率。 3. 可用性：设备可以正常使用的程度。 |
| 数据安全 | 采取措施确保数据免受未授权的泄露、篡改和毁坏。它包含三个方面，与信息安全基本要素相对应： 1. 秘密性 (机密性) 2. 完整性 3. 可用性 |
| 内容安全 | 信息安全在政治、法律、道德层次上的要求。它主要关注信息内容本身，包括三个方面： 1. 信息内容在政治上健康 2. 符合国家法律法规 3. 符合道德规范 |
| 行为安全 | 信息系统的服务功能最终通过行为提供给用户，确保信息系统行为的安全是最终保障。其特性包括： 1. 行为的秘密性 2. 行为的完整性 3. 行为的可控性 |
总结：信息安全是一个多层次的概念。设备安全是基础，数据安全是核心（对应机密、完整、可用），内容安全是信息的社会性规范，行为安全是系统服务功能的最终保障。它们共同构成了完整的信息安全体系。
信息存储安全是指为确保存储在信息系统中的数据免遭破坏、泄露、篡改和未授权访问而采取的一系列技术和管理的综合性措施。
信息存储安全主要涵盖以下五个方面：
| 方面 | 核心要求与措施 |
|---|---|
| 信息使用的安全 | 1. 用户的标识与验证：确保访问者的身份真实可信。 2. 用户存取权限限制：根据用户角色和最小权限原则，严格控制其对数据的访问和操作范围。 |
| 系统安全监控 | 1. 建立安全监控系统，全面监控系统活动，实时检查使用情况，以便及时发现非法入侵。 2. 建立完善的审计系统和日志管理系统，利用日志和审计功能跟踪、记录和审查所有安全相关事件，以确定和填补安全漏洞。 |
| 计算机病毒防治 | 1. 在网络服务器上必须加装网络病毒自动检测系统。 2. 必须定期更新网络病毒检测系统，以防范新型计算机病毒的侵袭。 |
| 数据的加密 | 对敏感或重要数据进行加密存储，确保即使数据被非法获取，也无法被直接识别和利用。 |
| 防止非法的攻击 | 采取防火墙、入侵检测/防御系统（IDS/IPS）等技术手段，主动抵御和防范来自外部的恶意攻击。 |
总结：信息存储安全是一个多层次的防御体系，它融合了身份认证、访问控制、实时监控、病毒防护、数据加密和攻击防御等多种手段，共同保障存储数据的机密性、完整性和可用性。
从实现技术层面看，一个完整的信息安全系统涉及以下关键技术和组件：
| 技术领域 | 核心描述与关键技术 |
|---|---|
| 基础安全设备 | 包括密码芯片、加密卡、身份识别卡等核心硬件，并延伸到物理安全层面的技术，如满足防护要求的机房环境、硬件设备、电力供应保障，以及抗电磁干扰和防电磁泄漏的防护措施。 |
| 计算机网络安全 | 保障信息在网络传输过程中的安全，防止和监控对数据的未授权破坏、更改和盗取。主要技术包括： • 网络隔离：物理隔离、防火墙、访问控制。 • 传输保护：加密传输、认证、数字签名、摘要、VPN隧道技术。 • 威胁防范：病毒防范、上网行为管理。 • 审计追溯：安全审计。 |
| 操作系统安全 | 确保操作系统自身无错误配置、无漏洞、无后门、无木马，并能防止非法用户对计算机资源的非法存取。其安全机制主要包括： • 标识与鉴别机制 • 访问控制机制 • 最小特权管理 • 可信通路、运行保障、存储保护、文件保护机制 • 安全审计机制 |
| 数据库安全 | 可大致分为数据库管理系统(DBMS)安全和数据库应用系统安全。关键技术涉及： • 完整性：物理数据库与逻辑数据库的完整性。 • 元素安全性、可审计性 • 访问控制、身份认证、可用性 • 推理控制、多级保护、消除隐通道 |
| 终端安全设备 | 从电信网终端设备的角度划分，主要包括：电话密码机、传真密码机、异步数据密码机等。 |
总结：信息安全技术体系是一个涵盖物理、网络、系统、数据、终端多个层次的纵深防御体系，各部分协同工作，共同构成整体的安全保障能力。
下表详细说明了诺兰模型的六个阶段及其核心特征：
| 阶段 | 核心特征 | 关键说明与问题 |
|---|---|---|
| 1. 初始阶段 | 计算机作为办公设备引入，应用稀少。 | 计算机初次进入企业，通常只用于财务部门等特定领域，属于尝试和启蒙时期。 |
| 2. 传播阶段 | 应用扩散，盲目投入，效率不高。 | 企业对计算机有了初步了解，开始尝试用其解决更多问题（如数据处理）。软件投入大幅增加，但因缺乏规划，易产生投资浪费、使用效率不高等新问题。 |
| 3. 控制阶段 | 从整体上控制发展，解决数据共享问题。 | 意识到盲目发展的弊端，开始从组织层面进行协调与控制，重点解决数据共享问题。此阶段系统呈现单点、分散的特点，资源利用率仍不理想。是从计算机管理转向数据管理的关键阶段。 |
| 4. 集成阶段 | 重新规划，建立统一系统，实现集成共享。 | 在控制的基础上，企业开始重新进行顶层设计与规划，建立基础数据库和统一的管理信息系统，初步实现人、财、物等信息在企业的集成共享，提升了IT系统和资源的利用效率。 |
| 5. 数据管理阶段 | 信息成为战略资源，实现平台统一与资源整合。 | 企业高层真正认识到信息的战略价值。信息化建设进入真正的数据处理阶段，通过统一平台，基本实现各部门、各系统的资源整合与信息共享。 |
| 6. 成熟阶段 | IT与管理和深度结合，内外部资源充分整合利用。 | 信息系统已能全面满足企业各层次需求（从事务处理到决策支持）。企业真正将IT与管理过程深度融合，实现对组织内、外部资源的充分整合和利用。 |
诺兰模型揭示了信息系统在组织内部发展的一种渐进式、阶段性的演化规律，从一个技术引入的初始点，经历扩散、控制、整合，最终走向与战略和管理深度融合的成熟状态。它对于组织理解自身信息化所处阶段、预见未来挑战和制定发展战略具有重要的指导意义。
企业信息系统的战略规划可划分为以下三个阶段，其核心焦点和方法论各有不同：
| 阶段 | 规划核心 | 主要规划方法 |
|---|---|---|
| 第一阶段 | 以数据处理为核心，围绕职能部门需求 | 关键成功因素法 (CSF) 战略目标集转化法 (SST) 企业系统规划法 (BSP) |
| 第二阶段 | 以企业内部管理信息系统 (MIS) 为核心，围绕企业整体需求 | 战略数据规划法 (SDP) 信息工程法 (IE) 战略栅格法 |
| 第三阶段 | 综合考虑企业内外环境，围绕企业战略需求 | 价值链分析法 战略一致性模型 (SAM) |
提示：本笔记根据图片内容，主要整理详述了第一阶段的三种方法。
总结：第一阶段（数据处理为核心）的三种方法为信息系统规划奠定了方法论基础。CSF 用于确定开发重点，SST 用于确保IT战略与业务战略对齐，BSP 则通过系统性的数据分析和流程梳理，为构建集成的信息系统提供蓝图。
企业信息系统的战略规划可划分为以下三个递进的阶段，其核心焦点和方法论各有不同：
| 阶段 | 规划核心 | 主要规划方法 |
|---|---|---|
| 第一阶段 | 以数据处理为核心，围绕职能部门需求 | 关键成功因素法 (CSF) 战略目标集转化法 (SST) 企业系统规划法 (BSP) |
| 第二阶段 | 以企业内部管理信息系统(MIS)为核心，围绕企业整体需求 | 战略数据规划法 (SDP) 信息工程法 (IE) 战略栅格法 (SG) |
| 第三阶段 | 综合考虑企业内外环境，以集成为核心，围绕企业战略需求 | 价值链分析法 (VCA) 战略一致性模型 (SAM) |
总结：ISP方法论从早期的部门级数据处理（第一阶段），演进到关注企业级集成管理（第二阶段），最终发展为与企业总体战略深度融合（第三阶段）。其规划焦点从技术实现层面，逐步提升至业务整合与战略驱动层面。
关键理解：软件架构是一种表达或蓝图，而非可运行软件本身。它定义了系统的高层组织结构和关键决策。
架构作为一种表达，使软件工程师能够：
| 作用 | 核心价值 |
|---|---|
| (1) 分析有效性 | 分析设计在满足所规定的需求方面的有效性。 |
| (2) 评估选择方案 | 在设计变更相对容易的阶段，考虑体系结构可能的不同选择方案。 |
| (3) 降低风险 | 降低与软件构造相关联的风险。 |
软件架构在软件开发中扮演着至关重要的角色，其意义体现在以下几个方面：
| 意义层面 | 具体说明 |
|---|---|
| 交流的手段 | 是项目干系人（如客户、管理者、开发人员）进行交流的共同语言和手段。 |
| 实现的约束 | 明确了对系统实现的约束条件。 |
| 组织的影响 | 决定了开发和维护组织的组织结构。 |
| 质量的制约 | 制约着系统的质量属性（如性能、安全性、可修改性）。 |
| 根本目的 | 研究软件架构的根本目的是解决好软件的复用、质量和维护问题。 |
| 预测模型 | 软件架构是可传递和可复用的模型，通过研究软件架构可以预测软件的质量。 |
总结：软件架构是系统设计的顶层抽象，它连接需求与实现，是进行技术决策、风险评估、团队协作和质量保障的核心基础。一个良好的架构是构建成功软件系统的基石。
软件架构的设计贯穿于软件生命周期的多个阶段，其中需求分析和设计是两个尤为关键的阶段。
设计阶段是软件架构研究关注最早、最多的核心阶段，主要包括三方面内容：
| 研究方面 | 核心内容与说明 |
|---|---|
| SA模型的描述 | 研究如何表达和记录软件架构，分为三个层次： 1. 基本概念：如构件、连接子。 2. 体系结构描述语言(ADL)：专门用于描述软件架构的形式化语言。 3. SA模型的多视图表示：从不同视角描述系统。 |
| SA模型的设计与分析方法 | 研究如何进行架构设计、评估和验证其质量属性的方法与技术。 |
| SA设计经验的总结与复用 | 对成功的架构设计模式、风格、策略进行总结，以支持在新项目中复用。 |
| 视图 | 核心关注点 | 描述内容 |
|---|---|---|
| 逻辑视图 | 功能需求 | 系统的静态结构，如对象、类、包及其关系。面向最终用户。 |
| 开发视图 | 软件开发 | 软件在开发环境中的静态组织，如模块、组件、源码结构。面向开发者。 |
| 进程视图 | 运行特性 | 系统的并发、同步、通信等运行时行为。面向集成人员。 |
| 物理视图 | 系统部署 | 软件到硬件（节点、网络）的映射。面向系统工程人员。 |
| 场景 (统一的+1) | 重要用例 | 通过一组关键用例（场景）将上述四个视图有机地串联起来，验证和阐明它们。 |
总结：需求分析阶段完成从“问题”到“解决方案”的跨越，设计阶段则通过多视图建模等方法，将解决方案具体化为可指导实现的、全面的软件架构蓝图。
“4+1视图模型”是Philippe Kruchten提出的一种描述软件架构的经典方法。它从五个不同的视角来刻画一个软件系统，实现了关注点分离，使得不同干系人能专注于系统的特定方面。其中，场景作为“+1”视图，是连接和验证其他四个视图的纽带。
下表详细说明了“4+1”模型中每种视图的核心关注点、面向对象和描述内容：
| 视图 | 别称 | 核心关注点 | 面向对象 | 描述内容与侧重点 |
|---|---|---|---|---|
| 逻辑视图 | 设计视图 | 系统的功能需求，即软件如何实现用户功能。 | 最终用户、设计人员 | 描述系统的静态结构，如对象、类、包、子系统及其关系。 |
| 进程视图 | 过程视图 | 系统的非功能性需求，如性能、可用性、并发、容错等。 | 集成人员、系统工程师 | 描述系统的动态行为，强调并发性、分布性、集成性、进程/线程间的交互与通信。 |
| 开发视图 | 实现视图 | 软件在开发环境中的静态组织，便于程序设计、实现与管理。 | 开发人员、项目经理 | 侧重于软件模块、组件、库、框架的组织结构，源码的目录划分与依赖关系。 |
| 物理视图 | 部署视图 | 软件到硬件（计算节点）的映射，即系统在物理上的部署与运行。 | 系统工程师、运维人员 | 描述硬件节点、网络拓扑、软件制品（可执行文件等）的安装位置及节点间的物理连接。 |
| 场景 | 用例视图 | 关键的系统活动，作为统一线索串联和验证其他视图。 | 所有干系人（尤其是架构师） | 抽象一组最重要的用例或用例场景，用以驱动架构设计，并验证构件及其交互关系是否满足核心需求。 |
模型价值：“4+1视图模型”提供了一个全面、多维的架构描述框架，是沟通、设计和文档化复杂软件系统的强大工具。
设计阶段是软件架构研究关注最早、最多的核心阶段，主要包括三方面内容：
| 研究方面 | 核心内容与说明 |
|---|---|
| SA模型的描述 | 研究如何表达和记录软件架构，分为三个层次： 1. 基本概念：如构件、连接子。 2. 体系结构描述语言(ADL)：专门用于描述软件架构的形式化语言。 3. SA模型的多视图表示：从不同视角描述系统。 |
| SA模型的设计与分析方法 | 研究如何进行架构设计、评估和验证其质量属性的方法与技术。 |
| SA设计经验的总结与复用 | 对成功的架构设计模式、风格、策略进行总结，以支持在新项目中复用。 |
| 视图 | 核心关注点 | 描述内容 |
|---|---|---|
| 逻辑视图 | 功能需求 | 系统的静态结构，如对象、类、包及其关系。面向最终用户。 |
| 开发视图 | 软件开发 | 软件在开发环境中的静态组织，如模块、组件、源码结构。面向开发者。 |
| 进程视图 | 运行特性 | 系统的并发、同步、通信等运行时行为。面向集成人员。 |
| 物理视图 | 系统部署 | 软件到硬件（节点、网络）的映射。面向系统工程人员。 |
| 场景 (统一的+1) | 重要用例 | 通过一组关键用例（场景）将上述四个视图有机地串联起来，验证和阐明它们。 |
| 概念 | 定义与说明 | 关键区别 |
|---|---|---|
| 构件 | 由一组原子构件组成的、独立可交付的复用单元。 | 侧重于复用和功能服务，是逻辑上的高级单元。 |
| 原子构件 | 构件的基本组成单位，是部署和版本控制的基本单元。 | 侧重于物理部署和构成。与构件的核心区别在于：原子构件通常不被单独部署，而是作为构件家族的一部分整体部署。 |
| 模块 | 一种特殊的原子构件，是不带单独资源的原子构件。 | 本质上是一组类和/或过程/函数的集合，是代码的组织单位，不包含独立的资源文件。 |
总结：在软件架构中，构件是高层级的、可复用的功能单元；它由多个可部署的原子构件组成；而模块是一种更纯粹、无资源的代码级原子构件。理解这三者的层次与关系对于基于构件的软件开发至关重要。
| 对比维度 | 构件 (Component) | 对象 (Object) |
|---|---|---|
| 单元性质 | 独立部署单元，具有原子性，是不可拆分的。 | 一个实例单元，具有唯一的标志。 |
| 组装角色 | 作为第三方的组装单元。 | (未在图中明确对应) |
| 状态可见性 | 没有外部的可见状态。 | 可能具有状态，此状态外部可见。 |
| 封装内容 | 封装了自己的状态和行为。 |
说明：一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。
构件技术是利用编程手段，将一些需要但又不便由最终用户直接操作的细节进行封装，并对各种业务逻辑规则进行实现，从而处理系统内部操作细节的技术。
目前国际上广泛采用的构件标准主要分为以下三大流派：
| 流派/标准 | 制定方 | 核心组成/内容 | 主要特点与说明 |
|---|---|---|---|
| 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则是旨在实现跨平台、跨语言互操作的开放分布式对象规范。这三大标准构成了构件化企业软件开发的主要技术选择。
基于架构的软件设计 (Architecture-Based Software Design, ABSD) 是一种以架构为核心的软件开发方法。
ABSD方法建立在以下三个基础之上：
总结：ABSD是一种架构先行、需求驱动的方法。它允许设计与需求分析并行，并通过功能分解、风格选择和模板复用三个坚实基础，以递归、迭代的清晰步骤，系统化地推导出稳定的软件架构。
ABSD方法是一个自顶向下，递归细化的方法。软件系统的体系结构通过该方法被逐步细化，直到能够推导出具体的软件构件和类。
ABSD方法中使用的设计元素及其分解关系如下图所示，遵循自顶向下、逐层分解的原则。
关键概念定义：
总结：ABSD通过将系统逐层分解为概念子系统 → 概念构件，并结合可复用的软件模板，以递归的方式系统地完成从高层架构到具体设计与实现元素的推导。
在考虑软件体系结构时，需要从不同的视角 (Perspective) 来观察，以全面描述和评估架构设计。
核心思想：不同的视角关注架构的不同属性，共同构成完整的架构描述。
主要分类：
| 视角类型 | 关注核心 | 用于判断的特性 | 典型视图举例 |
|---|---|---|---|
| 静态视角 | 展示系统的功能组织与结构。 | 质量特性 (如可维护性、可扩展性) | 逻辑视图、配置视图 |
| 动态视角 | 展示系统的并发行为与运行时交互。 | 系统行为特性 (如性能、可靠性) | 进程视图、实现视图 |
逻辑视图的作用：常用来记录设计元素的功能和概念接口。设计元素的功能定义了它在系统中的角色，这些角色包括功能、性能等。
ABSD方法使用两种不同的“场景”来分别捕获功能需求和非功能（质量）需求。
| 场景类型 | 用途 | 核心描述 |
|---|---|---|
| 用例 (Use Case) | 捕获 功能需求 | 是系统的一个给予用户一个结果值的功能点。它描述了系统在特定情境下为达成用户目标而执行的一系列动作。 |
| 质量场景 (Quality Scenario) | 捕获 质量需求 (非功能需求) | 通过定义具体的、可验证的场景来明确系统的质量属性要求，如性能、安全性、可用性等。 |
总结：在ABSD中，视角与视图提供了多维度描述架构的框架，而用例与质量场景则是将功能性与非功能性需求具体化、场景化的重要工具，共同驱动架构的设计与评估。
ABSD 方法定义了一个结构化的、以架构为核心的软件开发模型。该模型将传统以功能实现为中心的线性过程，转变为以架构设计和演化为驱动的迭代过程。
一个典型的传统软件开发过程通常包含以下顺序阶段：
ABSD 模型将整个软件过程明确划分为以下六个步骤，架构活动贯穿始终：
| 步骤 | 核心任务 |
|---|---|
| 1. 架构需求 | 明确并定义驱动体系结构设计的商业、质量与功能需求。 |
| 2. 架构设计 | 基于需求，选择体系结构风格，定义系统的高层结构、组件及其交互关系。 |
| 3. 架构文档化 | 将设计决策、体系结构视图和组件规格等正式记录下来，形成架构文档。 |
| 4. 架构复审 | 评估体系结构设计是否满足需求与质量属性，识别潜在风险。 |
| 5. 架构实现 | 依据已确定的体系结构，进行具体设计与编程，实现系统。 |
| 6. 架构演化 | 在系统运行和维护阶段，对体系结构进行调整和优化，以适应变化。 |
模型核心：这六个步骤构成了一个从需求到实现再到演化的完整闭环。它强调架构先行，并通过文档化和复审确保架构设计的可见性与正确性，最终支持系统的可持续演化。
基于架构的软件开发 (ABSD) 模型将开发过程划分为六个清晰、顺序与迭代相结合的核心子过程。以下是每个步骤的详细说明、关键活动和产出。
总结：ABSD 开发模型通过 “需求→设计→文档化→复审→实现→演化” 六个步骤，构建了一个严谨的、以架构为核心的软件开发生命周期闭环。它强调早期关注架构、持续验证与复审，并支持系统在生命周期内的持续演化，从而系统性地保障软件的质量、可维护性与适应性。
基于软件系统的生命周期，质量属性可分为以下两大类：
| 类别 | 核心描述 |
|---|---|
| 开发期质量属性 | 在软件开发阶段所关注的质量属性。 |
| 运行期质量属性 | 在软件运行阶段所表现和关注的质量属性。 |
注：本笔记主要详述开发期质量属性。运行期质量属性通常包括性能、安全性、可用性、可靠性等，将在后续部分介绍。
开发期质量属性主要包含以下六个方面：
| 属性 | 核心定义与说明 |
|---|---|
| 易理解性 | 指软件的设计被开发人员理解的难易程度。 |
| 可扩展性 (灵活性) |
软件因适应新需求或需求变化而增加新功能的能力。 |
| 可重用性 | 指重用软件系统或其某一部分的难易程度。 |
| 可测试性 | 对软件进行测试，以证明其满足需求规范的难易程度。 |
| 可维护性 | 当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。 |
| 可移植性 | 将软件系统从一个运行环境转移到另一个不同运行环境的难易程度。 |
总结：开发期质量属性聚焦于软件构建、演化和维护过程的效率与成本。它们直接影响开发团队的生产力和软件产品的生命周期总成本。良好的开发期质量是构建高质量运行期系统的基础。
| 属性 | 核心定义与说明 |
|---|---|
| 性能 | 软件系统及时提供相应服务的能力。包括对速度、吞吐量和容量等指标的要求。 |
| 安全性 | 软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。 |
| 可伸缩性 (可扩展性) |
当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提升系统处理能力。 |
| 互操作性 | 本软件系统与其他系统交换数据和相互调用服务的难易程度。 |
| 可靠性 | 软件系统在一定的时间内持续无故障运行的能力。 |
| 可用性 | 系统在一定时间内正常工作的时间所占的比例。会受到系统错误、恶意攻击、高负载等问题的影响。 |
| 鲁棒性 (健壮性/容错性) |
软件系统在非正常情况下（如用户进行了非法操作、相关的软硬件系统发生了故障等）仍能够正常运行的能力。 |
总结：运行期质量属性关注软件在生产环境中的行为表现。它们共同决定了系统在面对真实用户、数据和复杂环境时的稳定性、效率和安全水平，是终端用户最能直接感知到的软件质量维度。
在软件架构评估过程中，通常关注以下八种核心质量属性。
| 属性 | 核心定义 | 关键要点与细分 |
|---|---|---|
| (1) 性能 | 指系统的响应能力。即要经过多长时间才能对某个事件做出响应，或者在某个时间段内系统所能处理的事件个数。 | 衡量指标：响应时间、吞吐量。 设计策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。 |
| (2) 可靠性 | 是软件系统在应用或系统错误面前，在意外或错误使用的情况下，维持其功能特性的基本能力。 | 衡量指标：平均失效等待时间（MTTF）、平均失效间隔时间（MTBF）。在失效率为常数和修复时间很短的情况下，两者几乎相等。 两个层面： • 容错：错误发生时确保系统行为正确，并进行内部“修复”。 • 健壮性：使系统不受错误使用和错误输入的影响，能按既定程序忽略错误。 设计策略：冗余、心跳、选举、Ping/Echo。 |
| (3) 可用性 | 是系统能够正常运行的时间比例。经常用两次故障之间的时间长度，或在出现故障时系统能够恢复正常的速度来表示。 | 衡量指标：如故障间隔时间。 设计策略：冗余、心跳、选举、Ping/Echo。 |
| (4) 安全性 | 是指系统在向合法用户提供服务的同时，能够阻止非授权用户使用的企图或拒绝服务的能力。 | 可细分为： • 机密性：保证信息不泄露给未授权的用户、实体或过程。 • 完整性：保证信息的完整和准确，防止信息被非法修改。 • 不可否认性：信息交换的双方不能否认其在交换过程中发送或接收信息的行为。 • 可控性：保证对信息的传播及内容具有控制的能力，防止为非法者所用。 设计策略：入侵检测、用户认证、用户授权、追踪审计。 |
| (5) 可修改性 | 指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考查这些变更的代价来衡量。 | 可细分为： • 可维护性：在错误发生后“修复”软件系统的难易程度。 • 可扩展性：软件为适应新需求或需求变化而增加新功能的能力。 • 结构重组：重新组织软件系统的构件及构件之间的关系的难易程度。 • 可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。 设计策略：接口-实现分离、抽象、信息隐藏。 |
| (6) 功能性 | 是系统所能完成所期望的工作的能力。 | 核心：一项任务的完成需要系统中许多或大多数构件的相互协作。 |
| (7) 可变性 | 指架构经扩充或变更而成为新架构的能力。这种新架构应该符合预先定义的规则，在某些具体方面不同于原有的架构。 | 应用场景：当要将某个架构作为一系列相关产品的基础时，可变性很重要。 |
| (8) 互操作性 | 作为系统组成部分的软件通常需要与其他系统或自身环境相互作用。 | 核心要求：为了支持互操作性，软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。 典型问题：程序和用其他编程语言编写的软件系统的交互作用就是互操作性问题，这种互操作性也影响应用的软件架构。 |
为了精确描述软件系统的质量属性，通常采用质量属性场景 (Quality Attribute Scenario) 作为描述和定义质量需求的具体手段。它是一种面向特定质量属性的、结构化的需求描述方式。
一个完整的质量属性场景由以下六个部分构成，它们共同定义了一个具体的、可评估的质量需求实例。
| 组成部分 | 核心定义 |
|---|---|
| 刺激源 (Source) | 产生该刺激的实体，可以是人、计算机系统或任何其他刺激器。 |
| 刺激 (Stimulus) | 当刺激到达系统时，所需考虑的具体条件或事件。 |
| 环境 (Environment) | 刺激发生时，系统所处的特定条件（如正常运行、过载、维护等）。 |
| 制品 (Artifact) | 被刺激的对象，可能是整个系统，也可能是系统的某个特定部分。 |
| 响应 (Response) | 刺激到达后，系统（或制品）所必须采取的行动。 |
| 响应度量 (Response Measure) | 用于对响应进行度量的具体指标，以便对该需求进行验证和测试。 |
以下以“淘宝APP功能更新”为例，展示一个可修改性质量属性场景的具体应用。
| 场景组成部分 | 对应实例描述 |
|---|---|
| 刺激源 | 淘宝APP的开发团队（开发人员修改代码）。 |
| 刺激 | 淘宝APP需要进行版本更新，以增加新功能或修复已知问题。 |
| 环境 | APP运行平台（如iOS、Android的应用商店发布环境）。 |
| 制品 | 新版本的淘宝APP安装包。 |
| 响应 | 成功发布新版本，增添了计划中的功能或修复了特定的BUG。 |
| 响应度量 | 用户可以观察到：过去的某个BUG已消失，或者应用中出现了承诺的新功能。 |
总结：质量属性场景通过刺激-响应模型，将抽象的质量属性（如可修改性、性能、安全性等）转化为包含具体角色、条件、对象、行动和验收标准的实例。这种描述方法使质量需求变得具体、可评估、可测试，是架构设计与评估的重要沟通与验证工具。
下表展示了一个完整的、用于描述“可修改性”质量属性的通用场景模板。它通过定义场景的六个要素及其可能的具体情况，为评估系统的可修改性提供了清晰的分析框架。
| 场景要素 | 可能的情况 / 描述 |
|---|---|
| 刺激源 | 最终用户、开发人员、系统管理员 |
| 刺激 | 希望增加、删除、修改、改变功能、质量属性、容量等 |
| 环境 | 系统设计时、编译时、构建时、运行时 |
| 制品 | 系统用户界面、平台、环境或与目标系统交互的系统 |
| 响应 | 查找架构中需要修改的位置，进行修改且不会影响其他功能，对所做的修改进行测试，部署所做的修改 |
| 响应度量 | 根据所影响元素的数量度量的成本、努力、资金；该修改对其他功能或质量属性所造成影响的程度 |
实例应用说明：
质量属性场景主要用于描述和定义系统的特定质量需求。它主要关注以下六类质量属性，并明确了每类属性在场景描述中需要考察的核心方面。
| 质量属性 | 场景主要关注点 |
|---|---|
| 可用性 | 系统故障发生的频率、故障发生时的表现、允许系统非正常运行的时间长度、何时可以安全地出现故障、如何防止故障发生以及故障发生时的通知要求。 |
| 可修改性 | 系统在改变功能、质量属性时需要付出的成本和难度。此类场景可能发生在系统设计、编译、构建、运行等多种情况和环境下。 |
| 性能 | 系统的响应速度，可通过效率、响应时间、吞吐量、负载等指标客观评价性能的好坏。 |
| 可测试性 | 系统测试过程中的效率，以及发现系统缺陷或故障的难易程度。 |
| 易用性 | 用户使用系统时的容易程度，包括系统的学习曲线、完成操作的效率、用户对使用过程的满意程度等。 |
| 安全性 | 系统在向合法用户提供服务的同时，阻止非授权用户使用的能力。 |
总结：质量属性场景是一种结构化的需求描述方法，它将抽象的、非功能性的质量要求（如“系统要可靠”、“界面要友好”）转化为针对具体属性、包含明确关注点的、可评估和验证的具体场景，从而为架构设计和测试提供明确的依据。
系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策的过程。
总结：理解敏感点/权衡点有助于识别关键设计决策；明确风险承担者及其目标（特别是架构师的调和角色）是评估的社会维度；运用场景则是将抽象的质量目标具体化、可评估化的核心方法。三者共同构成了进行有效架构评估的基础认知框架。
| 评估方法 | 核心特点与描述 | 关键要素/备注 |
|---|---|---|
| (1) 基于调查问卷或检查表的方法 | 类似于需求获取中的问卷调查，但侧重于架构方面。 | 要求：评估人员必须对评估的领域非常熟悉。 |
| (2) 基于场景的评估方法 | 主要方法。通过分析架构对特定场景（使用或修改活动）的支持程度，来判断其对质量需求的满足度。 | 场景设计三要素： 1. 刺激（事件） 2. 环境（事件发生条件） 3. 响应（架构应对过程） 应用：ATAM（架构权衡分析方法）、SAAM（软件架构分析方法）。 |
| (3) 基于度量的评估方法 | 制定定量指标（如代码行数）来直接度量架构。 | 核心活动： 1. 建立质量属性与度量间的映射原则； 2. 从文档中获取度量信息； 3. 分析推导出系统质量属性。 要求：评估人员需对架构熟悉。 |
SAAM (Software Architecture Analysis Method) 是一种针对非功能质量属性的架构分析方法，是最早形成文档并得到广泛使用的软件架构分析方法。
对描述应用程序属性的文档进行审查，以验证基本的架构假设和原则。
ATAM (Architecture Tradeoff Analysis Method) 是在 SAAM 的基础上发展起来的，主要针对性能、安全性、可修改性和可用性，在系统开发之前，对这些质量属性进行评价和折中。
ATAM 被分为四个主要的活动领域，整个评估过程强调以质量属性作为架构评估的核心：
ATAM 的评估过程通常分为四个阶段，共包含九个具体步骤：
阶段1：场景和需求收集
阶段2：体系结构视图和场景实现
3. 描述体系结构视图
4. 实现场景
阶段3：属性模型构造和分析
5. 特定属性分析（优秀的分析理论）
阶段4：折中
6. 标志敏感度
7. 标志折中
8. 产生分析
最终输出
用 ATAM 方法评估软件架构，其工作分为 4 个基本阶段，即演示、调查和分析、测试和报告。
这是使用 ATAM 评估软件体系结构的初始阶段。
在这个阶段，人们对评估期间需要重点关注的一些关键问题进行彻底调查。
ATAM 方法采用 效用树（Utility tree） 这一工具来对质量属性进行分类和优先级排序。
效用树的结构：
ATAM 主要关注的质量属性：
ATAM 主要关注以下 4 类质量属性，因为这 4 个质量属性是利益相关者最为关心的：
整理场景
对场景进行细化
确定场景的优先级
分配效用
形成“策略-场景-响应级别”的对应关系
使用内插法确定期望的质量属性响应级别的效用
计算各架构策略的总收益
根据受成本限制影响的投资回报率 ROI 选择架构策略
中间件是指在一个分布式系统环境中处于操作系统和应用程序之间的系统级软件。它可以在不同的技术之间共享资源，将不同的操作系统、数据库、异构的网络环境以及若干应用结合成一个有机的协同工作整体。
中间件位于客户机/服务器的操作系统之上，管理计算机资源和网络通信。
中间件的任务是使应用程序开发变得更容易，通过提供统一的程序抽象，隐藏异构系统和分布式系统下低级别编程的复杂度。
中间件提供的支持通常包括两方面：
负责连接与通信：
提供互操作与控制机制：
提供开发与运行平台：
屏蔽底层差异：
提供高级管理与安全功能：
提供通用服务：
通信处理（消息）中间件
事务处理（交易）中间件
数据存取管理中间件
Web 服务器中间件
安全中间件
跨平台和架构的中间件
专用平台中间件
网络中间件
软件可靠性（Software Reliability）是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。
(1) 复杂性：
(2) 物理退化：
(3) 唯一性：
(4) 版本更新周期：
MTBF = MTTF + MTTR系统可用性 = MTTF / (MTTF + MTTR) * 100%无论什么系统，都是由多个设备组成，并协同工作，而这多个设备的组合方式可以是串联、并联，也可以是混合模式。假设每个设备的可靠性为 \(R_1, R_2 \cdots R_n\)，则：
模型组成部分：
绝大多数模型包含的3个共同假设：
需求分析阶段：
概要设计阶段：
详细设计阶段：
编码阶段：
测试阶段：
实施阶段：
实践证明，保障软件可靠性最有效、最经济、最重要的手段是在软件设计阶段采取措施进行可靠性控制。
可靠性设计就是在常规的软件设计中，应用各种方法和技术，使程序设计在兼顾用户的功能和性能需求的同时，全面满足软件的可靠性要求。
软件可靠性设计技术主要有容错设计、检错设计、降低复杂度设计和系统配置技术等技术。
提高系统可靠性的技术可以分为以下两类：
基本概念：
设计重点与要求：
核心机制：
关键注意事项：
技术属性：
| 对比维度 | 恢复块方法 | N版本程序设计 |
|---|---|---|
| 硬件运行环境 | 单机 | 多机 |
| 错误检测方法 | 验证测试程序 | 表决 |
| 恢复策略 | 后向恢复 | 前向恢复 |
| 实时性 | 差 | 好 |
前向恢复：
后向恢复：
定义：一种软硬件结合的较高容错应用方案。
系统组成：
关键机制：“心跳”方法
3种工作模式：
定义：
工作机制：
特点：
分类：
定义与目的：
常用的负载均衡实现技术：
软件可靠性数据是可靠性评价的基础。用时间定义的数据主要分为4类：
主要包括3个过程：
选择软件可靠性模型时需考虑的4个因素：
构成：多个系统级CPS的有机组合。
典型实例：多个工序（系统的CPS）形成一个车间级的CPS或者形成整个工厂的CPS。
核心目标：实现数据的汇聚，从而对内进行资产的优化和对外形成运营优化服务。
主要功能：
CPS技术体系主要分为三个层次：
CPS的技术体系可以进一步凝练为“一硬”、“一软”、“一网”、“一平台”：
(1) 智能设计
(2) 智能生产
(3) 智能服务
(4) 智能应用
CPS的建设路径分为如下阶段：
根据人工智能是否能真正实现推理、思考和解决问题，可以将其分为两类：
机器学习可分为传统机器学习和深度学习。区别在于，传统机器学习的领域特征需要手动完成，且需要大量领域专业知识；深度学习不需要人工特征提取，但需要大量的训练数据集以及强大的GPU服务器来提供算力。
机器学习的常见算法还包括迁移学习、主动学习和演化学习。
机器人可分为操作机器人、程序机器人、示教再现机器人、智能机器人和综合机器人。
(1) 操作机器人
(2) 程序机器人
(3) 示教再现机器人
(4) 智能机器人
(5) 综合机器人
机器人可分为工业机器人、服务机器人和特殊领域机器人。
(1) 云边缘：
(2) 边缘云：
(3) 云化网关：
主要包括以下六种协同：
(1) 资源协同
(2) 数据协同
(3) 智能协同
(4) 应用管理协同
(5) 业务管理协同
(6) 服务协同
除了核心的建模仿真技术，以下技术仍为数字孪生体构建过程中的内外围核心技术：
数字孪生体主要应用于以下领域：
云计算的概念包含两个核心方面：
(1) 软件即服务 (SaaS)
(2) 平台即服务 (PaaS)
(3) 基础设施即服务 (IaaS)
(1) 公有云
(2) 社区云
(3) 私有云
(4) 混合云
AI芯片的硬件架构多种多样，根据其设计目标和应用场景，主要分为以下几类：
| 分类 | 内容 |
|---|---|
| 国际标准 (IS) | 国际标准化组织 (ISO)、国际电工委员会 (IEC) 制定的标准，以及 ISO 出版的《国际标准题内关键词索引》所收录的其他国际组织制定的标准。 |
| 国家标准 (NB) | 中国 (GB)：中华人民共和国国家技术监督局美国 (ANSI)：美国国家标准协会英国 (BS)：英国标准学会日本 (JIS)：日本工业标准调查会 |
| 区域标准 | 太平洋地区标准会议 (PASC)欧洲标准化委员会 (CEN)亚洲标准咨询委员会 (ASAC)非洲地区标准化组织 (ARSO) |
| 行业标准 | 美国电气和电子工程师学会标准 (IEEE)中华人民共和国国家军用标准 (GJB)美国国防部标准 (DOD-STD)美国军用标准 (MIL-S) |
| 企业（机构）标准 | 供公司内部使用。 |
| 项目（课题）标准 | 计算机集成制造系统 (CIMS) 的软件工程规范。 |
| 标准类型 | 编号规则 |
|---|---|
| 国际标准 | ISO+标准号+[-+分标准号]+:+发布年号(注：方括号中的内容可有可无) |
| 国家标准 | 格式：国家标准的代号+标准发布顺序号-标准发布年代号（4位）我国代号：• GB：强制性国家标准• GB/T：推荐性国家标准 |
| 行业标准 | 格式：行业标准的代号（强制或推荐）+标准发布顺序号-标准发布年代号（4位）常见代号示例：• QJ：航天• SJ：电子• JB：机械• JR：金融系统 |
| 地方标准 | DB+行政区域代码（前两位）/(强制或推荐)+地方标准发布顺序号-标准发布年代号（4位） |
| 企业标准 | Q/企业代号+标准发布顺序号-标准发布年代号（4位） |
根据国际公约，知识产权的保护对象包括：
| 客体类型 | 权利类型 | 保护期限 |
|---|---|---|
| 公民作品 | 署名权、修改权、保护作品完整权 | 无限制 |
| 发表权、使用权和获得报酬权 | 作者终生及其死后50年（第50年的12月31日） | |
| 单位作品 | 发表权、使用权和获得报酬权（属于集体，无署名权、修改权等） | 50年（首次发表后的第50年的12月31日），若期间未发表，不保护 |
| 公民软件产品 | 署名权、修改权 | 无限制 |
| 发表权、复制权、发行权、出租权、信息网络传播权、翻译权、使用许可权、获得报酬权、转让权 | 作者终生及其死后50年（第50年的12月31日），合作开发的，以最后死亡作者为准 | |
| 单位软件产品 | 发表权、复制权、发行权、出租权、信息网络传播权、翻译权、使用许可权、获得报酬权、转让权 | 50年（首次发表后的第50年的12月31日），若期间未发表，不保护 |
| 注册商标 | 有效期10年（若注册人死亡或倒闭1年后，未转移则可注销；期满后6个月内必须续注） | |
| 发明专利权 | 保护期为20年（从申请日开始） | |
| 实用新型和外观设计专利权 | 保护期为10年（从申请日开始） | |
| 商业秘密 | 不确定，公开后公众可用 |
| 情况说明 | 判断说明 | 归属 | |
|---|---|---|---|
| 作品 | 职务作品 | 利用单位的物质技术条件进行创作，并由单位承担责任的 | 除署名权外，其他著作权归单位 |
| 合同明确约定其著作权属于单位 | 除署名权外，其他著作权归单位 | ||
| 其他 | 作者拥有著作权，单位有权在业务范围内优先使用 | ||
| 软件 | 职务作品 | 属于本职工作中明确规定的开发目标 | 单位享受著作权 |
| 属于从事本职工作活动的结果 | 单位享受著作权 | ||
| 使用了单位资金、专用设备、未公开的信息等物质、技术条件，并由单位或组织承担责任的软件 | 单位享受著作权 | ||
| 专利权 | 职务作品 | 本职工作中作出的发明创造 | 单位享受专利权 |
| 履行本单位交付的本职工作之外的任务所作出的发明创造 | 单位享受专利权 | ||
| 离职、退休或调动工作后一年内，与原单位工作相关 | 单位享受专利权 |
| 情况说明 | 情况说明 | 判断说明 | 归属 |
|---|---|---|---|
| 作品软件 | 委托创作 | 合同中明确约定著作权归属委托方 | 委托方 |
| 合同中未约定著作权归属 | 创作方 | ||
| 合作开发 | 只进行组织、提供咨询意见、物质条件等辅助工作 | 不享有著作权 | |
| 共同创作的 | 共同享有，按人头比例。成果可分割的，可分开申请 | ||
| 商标 | 谁先申请谁拥有同时申请，则根据谁先使用谁拥有（需提供证据）无法提供证据，协商归属，协商无效时使用抽签决定 | ||
| 专利 | 谁先申请谁拥有同时申请则协商归属，协商不成的，该发明成为社会共有技术 |
线性规划是研究在有限的资源条件下，如何有效地使用这些资源以达到预定目标的数学方法。其核心是在一组线性约束条件下，求一个线性目标函数的极值（极大值或极小值）。
一个线性规划问题的数学模型由以下三部分构成：
线性规划问题的最优解可能存在以下四种情况：
对于两个决策变量的线性规划问题，可在平面直角坐标系中用“求交点法”（图解法）快速求解：
决策论是研究为了达到预期目的，从多个可供选择的方案中如何选取最好或满意方案的学科。
| 决策类型 | 环境状态 | 结果与概率特征 | 说明 |
|---|---|---|---|
| 确定型决策 | 确定 | 结果是确定的 | 在已知的、确定的环境条件下进行选择。 |
| 风险决策 | 不确定 | 结果不确定，但各结果发生的概率已知（一致） | 在知道各种可能结果及其发生概率的情况下进行决策。 |
| 不确定型决策 | 不确定 | 结果不确定，且概率未知 | 完全依赖决策者的主观判断、经验和倾向进行选择。 |
max(max)max(min)\[折中收益 = \text{最大收益} \times \alpha + \text{最小收益} \times (1-\alpha) \]
min(max)| 维度 | 涉及技术内容 |
|---|---|
| 从架构来看 | MVC, MVP, MVVM, REST, Webservice, 微服务 |
| 从缓存来看 | MemCache, Redis, Squid |
| 从并发分流来看 | 集群 (负载均衡), CDN |
| 从数据库来看 | 主从库 (主从复制), 内存数据库, 反规范化技术, NoSQL, 分区 (分表) 技术, 视图与物化视图 |
| 从持久化来看 | Hibernate, Mybatis |
| 从分布存储来看 | Hadoop, FastDFS, 区块链 |
| 从数据编码看 | XML, JSON |
| 从Web应用服务器来看 | Apache, Tomcat, JBOSS, IIS, WebSphere, Weblogic |
| 其它 | 有状态与无状态, 响应式Web设计等 |
微服务架构将一个大型的单个应用或服务划分成一组微型、可独立部署的服务。微服务架构围绕业务领域将服务进行拆分，每个服务可以独立进行开发、管理和迭代，彼此之间使用统一接口进行交流，实现了在分散组件中的部署、管理与服务功能，使产品交付变得更加简单，从而达到有效拆分应用，实现敏捷开发与部署的目的。
Lambda架构是一种大数据处理架构，其核心特点是通过批处理层和速度层的分离，来同时满足对历史数据的高准确性和对实时数据的低延迟性需求。
其主要特点可概括为：
简单来说，Lambda架构用“批处理保准确，实时处理保速度”的思路，平衡了大数据处理中准确性、延迟和容错性这三个核心诉求。
Kappa架构是作为对Lambda架构的简化而提出的，其核心思想是：只保留流处理层，通过让流处理系统具备重播历史数据的能力，来统一处理实时数据和批量数据，从而用一套技术栈解决所有问题。
| 特性 | Lambda架构 | Kappa架构 |
|---|---|---|
| 核心思想 | 批流分离，用批处理保证准确性，用流处理保证低延迟。 | 流处理统一，通过数据重播来满足全量计算需求。 |
| 处理层 | 两套：批处理层 + 速度层。 | 一套：强大的流处理层。 |
| 数据源 | 原始存储（如HDFS）+ 消息队列。 | 唯一的不可变日志（如Kafka）。 |
| 代码复杂度 | 高。需要为批处理和流处理开发两套逻辑，并保证结果一致。 | 低。只需开发一套流处理逻辑。 |
| 运维成本 | 高。需要维护两套独立的计算系统。 | 较低。只需维护一套流处理系统。 |
| 计算延迟 | 批处理有高延迟，实时处理低延迟。 | 所有计算都是流式，可实现低延迟。 |
| 全量计算成本 | 批处理层定期进行，资源消耗大但成熟稳定。 | 通过流重播进行，可能消耗大量资源且对流处理引擎要求高。 |
总结来说，Kappa架构通过“数据重播”这一核心机制，用一套流处理系统取代了Lambda的两套系统，实现了架构的简化。它非常适合实时性要求高、且愿意接受流处理统一模型的项目，但其可行性高度依赖于流处理引擎的能力和消息队列的存储规模。
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 |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。