共享信息系统 - 软件架构课程 Lecture-4
授课教师：周立新（Dr. Lixin Zhou） 课程：0B105 - Software Architecture 来源：北京大学软件与微电子学院
课程概述
本讲探讨**共享信息系统（Shared Information Systems）**这一类系统的架构风格，通过三个领域的历史演进案例，揭示信息系统架构从批处理顺序模型向集成式、分布式、交互式系统演进的共同规律，并讨论领域特定设计支持（domain-specific design support）的问题。
三个典型领域案例：
- 数据库系统（Database Systems）
- CASE 环境（Computer Aided Software Engineering）
- 建筑设计系统（Building Design Systems）
一、数据库系统的架构演进
1. 批处理顺序模型（Batch Sequential）
早期数据库系统采用批处理顺序架构，典型特征：
- 处理步骤是独立的程序（Processing steps are independent programs）
- 每一步必须全部运行完成后才能开始下一步（Each step runs to completion before next step starts）
- 数据通过磁带（magtape）在程序间传递
典型数据流（Figure 4.1/4.3）：
Tape → Validate → Tape → Sort → Tape → Update → Tape → Report
↑
Tape（回环）
批处理更新程序的内部结构（Figure 4.2）：
- 驱动程序函数（Driver program functions）：对所有应用通用（Generic to all applications）
- “Access next trans” 模块
- Batch unique functions
- 子程序函数（Subprogram functions）：特定于每个事务
- Basic consistency checks（基本一致性检查）
- Account/item access（账目/项访问）
- Account/item validation（账目/项验证）
- Account/item posting（账目/项过账）
Note: The driver calls a different set of subprograms for each transaction type.
2. 交互式处理模型（Interactive Processing）
技术进步和用户需求推动了从批处理向交互式的转变：
- 并发操作（concurrent operation）
- 更快的更新速度（faster updates）
- 更新与报告不再同步（updates are out of synch with reports）
- 采用**仓库模型（Repository model）**加外部控制
交互式数据库数据流图（Figure 4.4）：
- Transaction database（事务数据库）
- Account/item database（账目/项数据库）
- Extract database（提取数据库）
六大处理节点：
- Batch transaction updates（批处理事务更新）
- On-line validation and update（在线验证与更新）
- Sequential processing facilities（顺序处理设施）
- Output processing（输出处理）
- On-line inquiry（在线查询）
- Exception data changes（异常数据变更）
输入输出：Direct input、Pre-formatted transactions、On-line information、Computer output
3. 统一模式集成（Unified Schemas）
当信息分布在多个不同数据库中时，采用统一模式方法：
- 抽象方法：多路复用数据库（Multiplex the database），在查询/更新上放置过滤器以匹配不同视图
- 通过定义（被动的）一致转换映射到多个数据库，创建一个虚拟数据库
示例：多图书馆系统的模式多样性（Figure 4.8 Diversity of Schemas for a Single Construct）
同一个”图书”概念在四个不同图书馆数据库中模式完全不同：
| 图书馆 | 表名 | 关键属性 |
|---|---|---|
| Main (CDB1) | item | (i#, title, author-name, subject, type, language) |
| Engineering (CDB1) | items | (i#, title, a-name, type, c-letter, f-digit, …) |
| City public (CDB3) | books | (i#, lc-num, name, title, subject) |
| Comm college (CDB4) | item | (i#, lc-number, title, a-name) |
即使是同一领域的同一概念，不同系统的 schema 设计差异也很大，集成需要复杂的模式映射。
4. 多数据库系统（Multi-database）
当数据库有很多用户时，被动映射不再足够：
- 使用主动代理（active agents）
- 采用分层体系结构（Layered hierarchy）
- 受限于：数据量、映射复杂性、数据不一致性处理
5. 数据库架构演进总结
| 阶段 | 架构模型 | 特点 |
|---|---|---|
| 批处理 | 独立程序 + 磁带传递 | 顺序执行，离线处理 |
| 交互式 | 仓库模型 + 外部控制 | 并发操作，实时更新 |
| 分布式 | 多数据库分散 | 信息分布在多个DB中 |
| 统一模式 | 虚拟数据库 + 被动映射 | 模式转换实现集成 |
| 多数据库 | 主动代理 + 分层层次 | 复杂映射 + 不一致处理 |
二、CASE 环境的架构演进
1. 从编译器到 CASE 工具
CASE（Computer Aided Software Engineering）的演进轨迹：
- 最初：只是源代码到目标代码的翻译——编译器、库、链接器、make
- 扩展：设计记录、文档、分析、配置管理、增量性
- 集成需求：被呼吁了20年，但始终未能真正实现
CASE vs DBMS 对比：
| 维度 | CASE | DBMS |
|---|---|---|
| 数据类型 | 更多类型 | 相对较少 |
| 每种类型实例数 | 更少 | 大量 |
| 查询速率 | 更慢 | 更快 |
| 信息特点 | 更大、更复杂、更少离散 | 结构化、离散 |
| 生命周期 | 不更短 | 较长 |
2. 编译器架构的演进
传统编译器（Traditional Compiler）：流水线式处理
现代典范编译器（Modern Canonical Compiler, Figure 4.15）：
Text → Lex → Syn → Sem → Opt → Code → Code
↓ ↓ ↓
Sym tab Tree Sym tab
- Lex（词法分析）→ Syn（语法分析）→ Sem（语义分析）→ Opt（优化）→ Code（代码生成）
- 共享表示：符号表（Sym tab）、语法树（Tree）
- 数据流（Vestigal data flow）vs 内存访问（Memory / Data fetch/store）
- 计算（transducers and transforms）
仓库视角的现代编译器（Canonical Compiler, Revisited, Figure 4.16）：
- 以中央仓库为核心（Tree / Sym tab）
- 多个工具（Lex、Syn、Sem、Opt1、Opt2、Code、Edit、Syn）围绕共享表示工作
- 可能是基于规则的（Might be Rule-Based）
- 体现了从管道过滤器向仓库架构的转变
3. 共享表示的软件工具（Figure 4.17）
两种集成模式对比：
专有项目字典（Proprietary project dictionary）：
- 左侧：tool 1/2/3/4 直接 Query/update 专有字典（封闭系统）
- 右侧：tool a/b 通过 Conversion 转换与 Open representation 交互
- 右侧：tool x/y 通过 conv 转换层访问
- loser 工具——无法集成的工具
关键洞察：
- 封闭系统：工具为系统专门构建，深度集成但扩展性差
- 开放系统：通过转换层集成外部工具，灵活但转换成本高
4. NIST/ECMA 环境集成参考模型（Figure 4.18）
六层架构模型（从下到上）：
| 层级 | 服务 | 说明 |
|---|---|---|
| 1 | Message services（消息服务） | 最底层通信基础设施 |
| 2 | User-interface services（用户界面服务） | 统一界面交互 |
| 3 | Process-management services（过程管理服务） | 工具执行与协调 |
| 4 | Tool layer（工具层） | Vertical tools（纵向工具）+ Horizontal tools（横向工具），Open tool slots（开放工具槽） |
| 5 | Data-integration services（数据集成服务） | 数据转换与集成 |
| 6 | Repository services（仓库服务） | 最顶层，统一数据存储 |
特点：即插即用新工具（Plug and use a new tool），分层架构支持开放性和可扩展性。
5. CASE 环境演进总结
演进路径（与数据库高度相似）：
- 交互方式：批处理 → 交互式
- 粒度：完整处理 → 增量式处理
- 覆盖范围：编译 → 全生命周期
- 集成方式：批处理顺序 → 刚性控制的仓库 → 分层开放系统
集成仍薄弱的原因：
- 被动转换、刚性排序（Passive conversions, rigid ordering）
- 只有系统级概念的知识（文件、日期）
- 需要学会处理复杂依赖关系和工具选择，但目前尚未做到
三、建筑设计系统的架构演进
1. 建筑设计行业特点
建筑业（Construction industry）：
- 完善的责任分解（Well-established decomposition of responsibilities）
- 地理上分散的子问题解决方案（Geographically dispersed solutions）
- 每次不同的组织组合（Different collection of organizations each time）
- 任务相互交互，协调本身就是专门技能（Tasks interact, coordination is its own specialty）
计算的自底向上演进：
- 早期：各子行业独立的算法设计系统
- 下一步：整个设施开发过程的集成
第三个案例（建筑设计）在独立交互式系统出现之前的阶段，与前两个案例类似——从早期集成努力中可以观察到相同的演进模式。
2. 集成建筑设计系统（Integrated Building Design Systems）
核心挑战：
- 各个工具结果的选择和组合需要判断、经验和经验法则（judgment, experience, rules of thumb）
- 不是算法式的（Not algorithmic）
- 需要规划（Requires planning）
早期努力：支持-监控系统（support-supervisory systems）
- 向工具添加数据管理、信息流控制
目标：数据、设计决策、知识的集成
- 紧密耦合的”大师建造者”模式（Closely-coupled Master Builder），或
- 协作工具组成的设计环境（Design environment with cooperating tools）
3. 80年代设计控制问题求解（Problem-Solving for Design Control）
五个维度的分析：
| 维度 | 80年代的典型做法 |
|---|---|
| 数据 | 主要是仓库：共享公共表示 + 转换为工具的私有表示 |
| 通信 | 主要是共享数据，部分消息传递 |
| 工具 | 封闭（为系统专门构建）vs 开放（可集成外部工具） |
| 控制 | 主要是单层层次结构：工具在底层，协调在顶层 |
| 规划 | 主要是固定的种类和处理顺序划分；脚本有时允许有限的灵活性 |
4. 集成建筑设计环境（IBDE, Figure 4.19）
典型架构：
- User（用户）
- Controller（控制器）
- Data manager（数据管理器）
- Global data（全局数据）
- 多种专业工具：Archplan、Strypes、Stanlay、Spex、Footer、Planex 等
5. 智能 IBDE 的架构（Figures 4.20 & 4.21）
高层架构（High-Level Architecture for Intelligent IBDE）：
- Agent 网格架构 + 操作系统（Oper Sys, fixed）
- GI data / Archplan / Strypes / Stanlay / Core / Spex / Footer / Planex 等专业模块
Soar/IBDE 详细架构：
- Knowledge of task（任务知识）
- Knowledge for using ESSs（使用专家系统的知识）
- Formulate subtask（制定子任务）
- Create input（创建输入）
- Simulate ESS（模拟专家系统）
- Operate SW sys（操作软件系统）
- Interpret result（解释结果）
- Convert output（转换输出）
- I/O (fixed)（固定 I/O 层）
- Oper Sys (fixed)（固定操作系统层）
四、架构风格对比与总结
批处理顺序 vs 管道过滤器（Figure 4.22）
| 维度 | (a) Batch Sequential | (b) Pipe/Filter |
|---|---|---|
| 数据载体 | Tape（磁带/文件） | Stream（流） |
| 处理单元 | Validate / Sort / Update / Report | Filter（过滤器） |
| 执行方式 | 每步运行完整后进入下一步 | 流式、增量式处理 |
| 耦合度 | 高（完整数据文件传递） | 低（流式接口） |
批处理顺序架构可以看作管道过滤器架构的”粗粒度”版本——以完整文件为数据单元而非数据流。
黑板架构（Blackboard Architecture, Figure 4.23）
共享信息系统的终极架构形式——黑板架构：
ks1 ks2
\ /
\ /
ks3 — Blackboard (shared data) — ks4
/ \
/ \
ks5 ks6
\ /
ks7 ks8
- 中央共享数据区：Blackboard (shared data)
- 多个独立知识源（ks1 ~ ks8）
- 知识源通过黑板间接通信
- 没有中央控制，知识源自主响应黑板状态变化
- 适用于问题求解路径不明确、需要多领域知识协作的系统
三个领域的共同演进规律
| 阶段 | 数据库 | CASE | 建筑设计 |
|---|---|---|---|
| 1 | 批处理顺序 | 独立编译工具 | 独立专业工具 |
| 2 | 交互式仓库 | 交互式设计工具 | 交互式建筑工具 |
| 3 | 多数据库分布式 | 仓库式CASE环境 | 支持-监控系统 |
| 4 | 统一模式 / 多数据库 | 分层开放环境 | 智能IBDE / 黑板 |
共同主题：
- 从批处理到交互式
- 从独立工具到集成环境
- 从刚性控制到分层开放
- 共享表示 vs 私有表示的平衡
- 数据集成始终是核心挑战
关键概念索引
- Batch sequential model（批处理顺序模型）
- Repository model（仓库模型）
- Unified schema（统一模式）
- Multi-database / Federated database（多数据库/联邦数据库）
- CASE environment（CASE 环境）
- Canonical compiler（典范编译器）
- Shared representation（共享表示）
- Proprietary vs open repository（专有 vs 开放仓库）
- NIST/ECMA reference model（NIST/ECMA 参考模型）
- IBDE（Integrated Building Design Environment，集成建筑设计环境）
- Blackboard architecture（黑板架构）
- Knowledge source（知识源）
- Master Builder model（大师建造者模式）
- Support-supervisory systems（支持-监控系统）
与其他知识的关联
- 数据管理系统-软件架构课程Lecture-21 — 同课程Lecture-21（CMU David Garlan），专注数据管理系统架构
- 软件体系结构概述-软件架构课程Lecture-1 — 课程概述，架构定义与分类
- 软件架构风格-软件架构课程Lecture-2 — 8大经典架构风格（管道过滤器、仓库、分层等）
- KWIC与软件架构案例分析-软件架构课程Lecture-3 — Lecture-3 案例研究（KWIC 四种架构对比）
- Agent系统与多Agent系统-软件架构课程Lecture-4 — 同 Lecture-4 另一个主题：Agent 系统