设计空间与设计规则 — 软件架构系统研究方法
来源：Thomas G. Lane, CMU/SEI-90-TR-18 / CMU-CS-90-175, November 1990
原文标题：Studying Software Architecture Through Design Spaces and Rules
作者：Thomas G. Lane, CMU School of Computer Science, Software Architecture Design Principles Project
页数：38页（约1.1万字符）
类型：文字版英文技术报告 / 博士论文摘要版
目录位置：田浩然上传的资料/0B105-SoftwareArchitecture/Lecture-5/tr18.90.pdf
处理日期：2026-08-28
核心论点
软件系统的整体结构（“软件架构”）可以通过**构建设计空间（design space）来有效研究。设计空间识别创建设计时做出的关键功能和结构选择，并分类每个选择的可用备选方案。可以在设计空间中制定设计规则（design rules）**来关联不同维度的选择。规则集合是有价值的设计辅助工具，并为自动结构设计提供了有前景的途径。
本报告以用户界面软件架构为具体案例，构建了一个设计空间和相关规则，并通过实验验证了这些规则的预测与真实系统设计的一致性。
1. 知识编码化（Codified Knowledge）的价值
1.1 为什么需要设计空间？
软件工程正处于从”每个系统从零发明”到”基于已有模式做常规设计”的转折点。设计空间和设计规则的目标是将软件设计知识组织成可用的形式——就像20年前控制结构的编码化（结构化编程革命）一样。
1.2 三大收益
如果设计词汇被广泛采用，有三大好处：
- 辅助创建设计：提供心智构建块（mental building blocks）
- 辅助理解/预测设计属性：为知识的创建和应用提供上下文
- 降低理解他人设计的成本：减少需要学习的新概念数量
1.3 工程设计手册类比
传统工程领域早已区分创新设计（innovative design）和常规设计（routine design）：
- 创新设计依赖原始发明或从抽象原理推导
- 常规设计使用标准化方法解决与以前相似的问题
常规设计方法更便宜、更可能产出可接受的设计（虽然不一定最优）。设计手册的主要目的就是支持常规设计。算法和数据结构已有手册（Knuth, Sedgewick），但更高层次的软件设计尚未有手册。
2. 设计空间的核心概念
2.1 什么是设计空间？
一个多维设计空间对系统架构进行分类：
- 每个维度描述系统的一个特征或设计选择的变化
- 维度上的值对应备选的需求或设计选择
- 一个具体系统设计对应设计空间中的一个点
设计空间的维度通常不是连续的，也不一定有度量（距离测度）。结构选择维度通常是离散的，可能有意义排序也可能没有。即使原则上连续的维度（如性能数值），在设计早期也常聚合为少数离散值（低/中/高）。
2.2 功能性 vs 结构性设计空间
| 类型 | 反映 | 在瀑布模型中对应 |
|---|---|---|
| 功能设计空间 | 需求或评估标准（功能/性能） | 需求分析和总体功能设计的结果 |
| 结构设计空间 | 结构或其他设计选择 | 初始系统分解的结果 |
两者可视为独立空间，也可视为一个大设计空间的子空间。关键洞见：发现功能维度与结构维度之间的相关性，就能提供直接的设计指导——哪些设计选择最可能满足功能需求。
2.3 粒度问题
构建设计空间的关键问题之一是找到最有用的分类粒度。例如，用户界面行为规约方法包括状态转移图、上下文无关文法、菜单树等，每种还有许多小变化。
2.4 相关工作
- Bell & Newell (1971)：计算机硬件结构分类法（功能、IPS、内存大小、硬件支持的数据类型等维度）——设计空间概念的经典来源
- Wegner (1987)：面向对象语言的设计空间
- Prieto-Díaz & Freeman (1987)：软件复用中的 faceted 分类方案
- 用户界面领域：以往多关注控制流模式（Hayes 85, Tanner 83）或外观/行为表示法分类（Green 86, Myers 89），而内部结构问题被普遍忽视
3. 用户界面软件的三层结构模型
任何完整的用户界面系统都可分为三个组件组：
-
应用特定组件（Application-specific component）
- 针对特定应用、不复用于其他应用的代码
- 包括应用的功能核心，也可能包括应用特定的用户界面代码
-
共享用户界面组件（Shared user interface component）
- 旨在支持多个应用程序用户界面的代码
- 仅适用于所有设备类型的代码
-
设备相关组件（Device-dependent component）
- 特定于某类I/O设备的代码（非应用特定）
两个关键接口：
- 应用接口（application interface）：应用特定代码 vs 共享用户界面代码的分界
- 设备接口（device interface）：设备特定代码 vs 共享用户界面代码的分界
灵活性：真实系统的划分有一定灵活性——可以通过采用不同标记来分析系统的不同层次。例如分析X Window System时，可以把服务器外一切视为应用特定，然后再把服务器内部划分为共享和设备相关层。
4. 功能设计空间维度
功能维度识别对结构影响最大的用户界面系统需求，分三组：
4.1 外部需求
| 维度 | 选项/级别 | 说明 |
|---|---|---|
| 外部事件处理 | 无 / 等待输入时处理 / 抢占用户命令 | 应用是否需要响应非用户界面来源的事件，以及响应时间尺度 |
| 用户可定制性 | 低 / 中 / 高 | 终端用户可定制界面的程度：仅细节修改→命令重定义/宏语言 |
| 跨设备适应性 | 无 / 局部行为变化 / 全局行为变化 / 应用语义变化 | 更换I/O设备时界面行为需要变化的程度 |
| 计算机系统组织 | 单处理 / 多处理 / 分布式处理 | 运行环境的基本性质 |
4.2 基本交互行为
基本界面类（Basic interface class）——基于Shneiderman分类：
- 菜单选择（Menu selection）
- 表单填充（Form filling）
- 命令语言（Command language）
- 自然语言（Natural language）
- 直接操纵（Direct manipulation）
菜单选择和表单填充可由类似系统结构支持；其他每类都有独特需求。
4.3 实际考量
跨界面风格的应用可移植性：
- 高：应用应能跨显著不同的风格移植（如命令语言 vs 菜单驱动）
- 中：应用应独立于较小的风格变化（如菜单外观）
- 低：界面可变性不重要
5. 结构设计空间维度
结构维度代表决定用户界面系统整体结构的决策，分三大组：
5.1 功能与知识的模块划分
应用接口抽象级别（Application interface abstraction level）——核心结构维度，共六级：
| 级别 | 特点 | 典型例子 |
|---|---|---|
| 1. 单体程序（Monolithic） | 应用与共享代码无分离 | 电子游戏等小型专用系统 |
| 2. 抽象设备（Abstract device） | 共享代码只是设备驱动，提供物理操作原语 | ”画线”而非”呈现菜单” |
| 3. 工具包（Toolkit） | 共享代码提供交互技术库（菜单/滚动条等） | 应用负责选择和组合元素 |
| 4. 固定数据类型的交互管理器 | 共享代码控制局部和全局交互序列，通信使用标准数据类型 | ”获取命令”/“呈现结果” |
| 5. 可扩展数据类型的交互管理器 | 同上，但数据类型集可由应用扩展 | - |
| 6. 完全独立的应用语义 | （报告中未详述完整第六级） | - |
关键洞见：抽象级别是用户界面软件的最关键结构属性。这个分类最早可追溯到Hayes et al. 1985。
抽象设备可变性（Abstract device variability）——设备接口的关键维度：
- 设备独立代码放弃对界面细节的控制越多，直接操纵就越难得到好的支持
5.2 表示问题
用户界面定义表示法（Notation for user interface definition）：
- 隐式（Implicit）：表示法存在于代码结构中，无独立规格说明
- 内部过程式（Internal procedural）：通过调用库例程定义界面
- 内部声明式（Internal declarative）：通过数据结构参数定义
- 外部声明式（External declarative）：独立的规格说明文件，如菜单树、UI描述语言
- 外部过程式（External procedural）：外部语言/宏定义
5.3 控制流、通信与同步
通信基础（Basis of communication）：
- 基于共享状态（state-based）
- 基于事件（event-based）
- 混合（状态+提示 / 状态+事件）
控制线程机制（Control thread mechanisms）：
- 单线程（事件处理器 / 中断服务例程）
- 非抢占式进程
- 标准进程（抢占式）
- 轻量级进程
- 中断服务例程
6. 设计规则
6.1 规则的本质
在这个设计层次上，很少有绝对的硬性规则。大多数维度间的关系是：一个维度的某个选择倾向于或不倾向于另一维度的特定选择；这种相关性的强度因情况而异。
设计规则的自然表示法是与两个（或多个）维度的特定备选组合关联的正负权重。给定设计的评估就是对所有适用规则的权重求和。
6.2 两类规则
| 规则类型 | 作用 | 难度 |
|---|---|---|
| 功能→结构规则 | 让系统需求驱动结构设计 | 直接 |
| 结构间互连规则 | 确保设计的内部一致性 | 更复杂（不同维度选择互相影响，需要组合搜索） |
6.3 规则示例（精选）
功能→结构规则：
- 如果外部事件处理需要抢占用户命令 → 强烈倾向抢占式控制线程机制（标准进程/轻量级进程/中断服务例程）
- 高用户可定制性需求 → 倾向外部表示法
- 强跨设备适应性需求 → 倾向更高的应用接口抽象级别（解耦应用与界面细节）
- 分布式系统组织 → 倾向基于事件的通信（基于状态需要共享内存，分布式环境中代价高）
- 基本界面类影响抽象级别选择：菜单/表单适合工具包和不可扩展交互管理器；直接操纵需要可扩展交互管理器或工具包
- 高应用可移植性需求 → 倾向更高级别的应用接口抽象，以及事件型或纯状态型通信（而非混合型）
结构间规则示例：
- 应用接口抽象级别选择影响界面表示法选择：
- 单体/抽象设备 → 隐式表示通常足够
- 工具包 → 隐式+内部声明式
- 交互管理器 → 外部和/或内部声明式
- 可扩展交互管理器 → 大量依赖过程式表示法
7. 验证实验
7.1 实验设计
用6个未参与设计空间构建的系统来测试规则：
- 2个截然不同的UIMS
- 1个面向新手程序员的集成编程环境
- cT教育编程语言环境
- 1个图形数据库显示自动生成系统
- 1个飞行模拟器控制程序
方法：
- 让每个系统的设计者用设计空间术语描述其系统
- 把功能描述输入程序，由规则集推荐最优结构
- 比较推荐结果与实际设计
7.2 实验结果
- 使用 kappa统计量 衡量，规则预测与实际设计中度到实质性一致（moderate to substantial agreement）
- 大部分差异可归类为：合理的设计意见分歧 / 规则中的小错误或疏忽
- 表现最差的领域：表示法选择（用户界面定义表示法和应用语义信息表示）——可能因为当前设计空间主要关注运行时结构，对设计过程维度覆盖不足
7.3 结论意义
这些结果非常出色，因为规则中的信息量很有限（3.1节的例子只占完整规则集的约10%）。这表明设计空间本身提供了巨大杠杆——即设计空间所做的分类使选择正确的设计类型变得更容易。
两个核心发现：
- 专家用户界面系统设计者之间在结构选择上存在显著的共识
- 设计空间和规则捕捉了（至少部分）这种共识
8. 设计空间的构建方法论
8.1 自下而上的归纳法
设计空间和规则基于对现有用户界面系统的广泛调查：
- 通过寻找分类方式将具有相似属性的系统归在一起 → 形成设计空间
- 基于观察到的相关性制定规则
类比：生物分类学的自然史研究——生物学家也是先调查和分类现有形态，再寻找解释性理论。
8.2 两个主要问题
1. 可能遗漏重要维度
- 很难证明一个设计空间覆盖了所有可能相关的内容
- 实验结果表明，可能需要增加与设计方法相关的维度
2. 去除多余维度同样重要和困难
- 最初定义的25个功能维度中，只有约10-12个有显著影响
- 结构维度中，许多选择因与保留选择高度相关而可以省略
- 例如：应用接口抽象级别的分类足以预测该接口的许多属性（如跨接口交换的数据类型性质）
8.3 一个发人深省的观察
前十大功能维度强烈偏向系统灵活性的度量——用户可定制性、跨设备适应性、跨风格可移植性分别衡量灵活性的不同方面。灵活性的重要性远超任何特定系统属性（如I/O设备的性质或速度）。
也许某一天，灵活性会被认为是许多软件结构的基本决定因素。
9. 总结与展望
9.1 核心贡献
- 提出设计空间+设计规则作为组织软件设计知识的通用方法
- 以用户界面软件为具体领域，构建了一个完整的设计空间
- 通过实验验证了方法的有效性——规则预测与专家设计有显著一致性
9.2 实用价值梯度
- 设计空间本身（即使没有规则）就是有用的：作为不同设计方法的紧凑总结，帮助设计者避免忽视好的解决方案
- 非正式规则/指南：帮助设计者快速排除低劣选择，把时间留给在合理备选方案中选择
- 形式化规则集：可作为自动设计助手甚至全自动系统构建的基础
9.3 未来方向
作者希望其他研究者为其他领域构建设计空间和规则：
- 其他类型的系统
- 设计过程中其他抽象级别的设计空间
最终目标：发现软件设计的通用原则——例如某些类型的设计维度可能是普适的。
关键概念速查
| 概念 | 英文原文 | 一句话定义 |
|---|---|---|
| 设计空间 | Design Space | 多维分类空间，每维描述一个系统特征或设计选择 |
| 设计规则 | Design Rules | 维度间的相关性/权重，指导从需求到结构的选择 |
| 功能设计空间 | Functional Design Space | 描述需求和评估标准的维度集合 |
| 结构设计空间 | Structural Design Space | 描述结构选择的维度集合 |
| 应用接口 | Application Interface | 应用特定代码与共享用户界面代码的分界 |
| 设备接口 | Device Interface | 设备特定代码与共享用户界面代码的分界 |
| 抽象级别 | Abstraction Level | 应用接口的关键属性：从单体到可扩展交互管理器的六级 |
| 常规设计 | Routine Design | 使用标准化方法解决已知问题，便宜且可靠 |
| 创新设计 | Innovative Design | 从原始发明或抽象原理出发的全新设计 |
关联
- 共享信息系统-软件架构课程Lecture-4 —— 周立新软件架构课程，数据库架构/CASE/建筑设计三领域演进案例
- 软件架构风格-周立新 —— 八大经典架构风格分类（管道过滤器/OO/事件驱动/分层/仓库/解释器/过程控制等）
- KWIC与软件架构案例分析-软件架构课程Lecture-3 —— 同一课程Lecture-3，四种架构对比案例
- Agent系统与多Agent系统-软件架构课程Lecture-4 —— 同一课程Lecture-4，Agent架构风格
本报告是软件架构设计空间方法的奠基性文献之一，开创了将架构选择系统化、量化的研究路径，对后来的架构评估方法（ATAM等）和软件产品线工程有深远影响。