关系代数除法 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⊆X⊆U，则 X→Y 为 F 所蕴含。	属性集总能决定其自身的任何子集。
A2	增广律 (Augmentation)	若 X→Y 为 F 所蕴含，且 Z⊆U，则 XZ→YZ 为 F 所蕴含。	函数依赖两边可同时增加相同的属性集。
A3	传递律 (Transitivity)	若 X→Y 且 Y→Z 为 F 所蕴含，则 X→Z 为 F 所蕴含。	函数依赖具有传递性。

核心：这三条规则是正确且完备的，即所有成立的函数依赖均可从F出发，仅用这三条规则推导出来。

3. 导出推理规则

根据上述三条基本公理，可以推导出以下三个常用的实用规则：

规则	名称	内容	说明与用途
合并规则 (Union Rule)	若 X→Y 且 X→Z，则 X→YZ 为 F 所蕴含。	将具有相同左部的函数依赖的右部合并。
伪传递规则 (Pseudo Transitivity Rule)	若 X→Y 且 WY→Z，则 XW→Z 为 F 所蕴含。	传递律的增强形式，允许在传递过程中增加条件。
分解规则 (Decomposition Rule)	若 X→Y 且 Z⊆Y，则 X→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)	Atomicity	事务中包含的所有操作被视为一个不可分割的整体。这些操作要么全部成功执行，要么全部不执行（回滚到事务开始前的状态）。
一致性 (Consistency)	Consistency	事务的执行必须使数据库从一个一致性状态转变到另一个一致性状态。即事务的执行结果必须保证数据库中的数据满足所有的完整性约束。
隔离性 (Isolation)	Isolation	一个事务的执行过程不能被其他并发事务干扰。多个并发事务的执行应当相互隔离，使得每个事务都感觉不到有其他事务在同时执行。
持久性 (Durability)	Durability	也称为永久性。一旦一个事务成功提交，它对数据库所做的任何改变就是永久性的，即使后续系统发生故障，这些改变也不会丢失。

核心总结：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

软件架构风格总结 (备考与实例速查)

该表格对常见软件架构风格进行了归纳总结，特别突出了常考的关键字、典型实例及其核心思想，便于快速回顾与区分。

架构风格类别与名称	常考关键字与典型实例	核心简介