软件体系结构概述 — Software Architecture: An Overview
北京大学软件与微电子学院 周立新（Dr. Lixin Zhou） 课程：0B105 Software Architecture（软件体系结构） 类型：课程第1讲，概述篇 来源：田浩然上传的资料 / 0B105-SoftwareArchitecture / Lecture-1
一、核心定位：软件架构是什么？
软件架构是需求与实现之间的桥梁——上承业务需求，下启代码构造。
1.1 三种经典定义
| 来源 | 定义核心 |
|---|---|
| Brooks（人月神话作者） | “概念完整性是系统设计中最重要的考量。架构即’用户’接口的完整而详细的规约。“ |
| Pressman | ”架构设计的首要目标是开发模块化的程序结构，并表达模块之间的控制关系。“ |
| Garlan & Perry（IEEE 1995） | “程序/系统组件的结构、它们之间的相互关系，以及支配其设计和随时间演进的原则与指南。“ |
| Bass, Clements, Kazman（SAiP 1997） | “系统的一个或多个结构，包括软件组件、这些组件的外部可见属性，以及它们之间的关系。” |
关键洞察：架构 ≠ 结构。架构 = 结构 + 外部可见属性 + 关系 + 设计原则与演进规律。
1.2 IEEE 1471-2000 标准
ANSI/IEEE Std 1471-2000《架构描述的推荐实践》是软件架构领域的官方标准化里程碑。
二、为什么软件架构重要？
2.1 直接价值
- 简化复杂系统：通过抽象与分而治之驯服复杂性
- 组件复用：架构级复用比代码级复用影响更大
- 促进沟通：架构是利益相关者之间的通用语言
- 支撑系统演进：好的架构能容纳变化，降低维护成本
- 新人培训：架构图是新人理解系统的最快入口
- 改善项目管理：架构为估算、计划、风险评估提供骨架
- 提升构建质量：架构先行避免返工
- 支撑系统分析：在编码前即可分析质量属性
2.2 成熟学科的标志
“一个成熟工程学科的关键属性，是在新系统开发中常规性地复用已有解决方案。”
建筑学科的成熟体现在：设计被制度化在手册、技术出版物和企业标准中。软件架构正在走同样的路——从手工作坊走向工程化。
2.3 复杂性是最大敌人
“未来20年的挑战不会是速度、成本或性能，而将是复杂性问题。” —— Bill Raduchel, Sun Microsystems 首席战略官
“我们的敌人是复杂性，我们的目标是消灭它。” —— Jan Baan
2.4 软件复杂性的两个维度（Walker Royce）
更高技术复杂度
▲
│ 电信交换机 / 嵌入式编译器 / 汽车软件
│ 国防武器系统 / 国家空管系统 / 大型组织仿真
│
│ 平均项目：5-10人，10-15个月，3-5个外部接口
│
│ IS应用 / 分布式对象 / CASE工具 / 小型科学仿真
│ 电子表格 / 业务IS应用（GUI+RDB）
▼
更低技术复杂度
◄──────────────────────────────────►
更低管理复杂度 更高管理复杂度
（小规模/非正式/单一利益相关方） （大规模/合同/多方利益相关）
三、与建筑架构的类比
3.1 经典建筑类比（Classical Building Architecture Analogy）
| 维度 | 建筑 | 软件 |
|---|---|---|
| 表示法 | 蓝图、物理模型、透视图 | 结构图、行为视图、信息视图 |
| 架构风格 | 罗马式、哥特式、维多利亚式 | 分布式、分层、客户/服务器 |
| 约束条件 | 声学、水/气流、照明 | 吞吐量、时序、容错、易用性 |
| 标准与实践 | 建筑规范与检查 | 接口标准与走查/评审 |
3.2 化工过程类比（Chemical Architecture Analogy）
| 维度 | 化工 | 软件 |
|---|---|---|
| 组件 | 单元操作（如换热器） | 架构组件（如DBMS） |
| 连接件 | 管道、传送带 | 过程调用、管道 |
| 架构风格 | 操作方式（批处理、连续） | 拓扑风格（管道-过滤器、黑板） |
| 约束 | 流程中元素的先后顺序 | 执行序列中元素的先后顺序 |
| 表示法 | 工艺流程图 | 架构描述语言（ADL） |
| 产品 | 化工厂 | 应用系统 |
3.3 规模差异决定方法论
| 建筑类型 | 人数 | 建模 | 过程 | 工具 |
|---|---|---|---|---|
| 狗屋 | 1人 | 极少 | 简单 | 简单工具 |
| 住宅 | 团队 | 需要 | 明确过程 | 电动工具 |
| 摩天大楼 | 多个团队（多家公司） | 大量建模 | 复杂的”需定义”过程 | 大量工具 |
软件同理——不同规模的系统需要不同量级的架构投入。
3.4 建筑学科的演进史
青铜时代/埃及 → 希腊/罗马 → 拜占庭/罗马式 → 哥特式 → 风格主义 → 巴洛克 → 工程/理性/民族/浪漫 → 新艺术运动 → 现代运动（赖特、勒·柯布西耶）
规律：从模仿前人 → 从失败中学习 → 整合其他力量 → 实验 → 体系化
3.5 建筑的分层变化（Brand《建筑如何学习》）
Shearing layers of change（剪切层变化理论），从慢到快：
- Site（场地）—— 几百年不变
- Structure（结构）—— 几十年
- Skin（表皮）—— 十几年
- Services（服务设施）—— 几年
- Space plan（空间规划）—— 几个月到几年
- Stuff（物品）—— 每天
软件架构中也有类似的”变化速度分层”——越底层越稳定，越上层越频繁变化。
3.6 软件与建筑的关键差异
- 建筑：你可以从设计图和成品中”看到”架构
- 软件：你无法通过阅读成千上万行源代码”看到”架构
四、软件架构师
4.1 架构师的职责
- 规划产品的开发、演进体系
- 分析与构思核心的软件体系架构
- 规划与建设组织级的软件重用库
- 负责组织级软件技术资产的积累与管理
- 领导与协调项目组的主要技术活动，对主要技术工作产品负责
- 负责项目组的体系架构设计，定义系统的高层结构与接口
- 指导系统设计、开发人员细化与实现既定的体系架构
- 协助制定与评审软件开发计划
4.2 资质与技能要求
- 完整的软件工程理论体系知识
- 多才多艺、成熟练达、洞察力强、经验丰富
- 软件领域 5~10年以上 工作经验
- 精通 RUP 软件过程体系
- 精通各类软件架构体系，特别是分布式架构（三层/CORBA/J2EE/.NET/管道过滤器等）
- 精通企业级应用核心技术（事务、安全、消息队列等）
- 精通 OOA/OOD
- 具备业务领域信息化知识
- 精通架构设计方法
- 掌握 UML/Rose/RequisitePro 等工具
- 掌握 ClearCase/ClearQuest 配置与变更管理
4.3 架构师的角色认知
| 不是什么 | 是什么 |
|---|---|
| 不仅仅是高层设计师 | 需要确保可行性 |
| 不是项目经理 | 但与项目经理”紧密相连” |
| 不是技术专家 | 理解系统的目的与”适配” |
| 不是孤独的科学家 | 是沟通者 |
4.4 架构团队的使命（Charter）
- 定义软件架构
- 维护软件架构的完整性
- 评估与软件设计相关的技术风险
- 提议连续迭代的顺序和内容
- 提供咨询服务
- 协助未来产品定义的市场工作
- 促进项目团队之间的沟通
4.5 架构就是做决策
“软件架构师的人生，是一长串（有时痛苦的）次优决策序列，部分是在黑暗中做出的。“
五、架构设计的核心概念
5.1 Mary Shaw & Booch & Kruchten 的架构定义
软件架构包含关于软件系统组织的所有重大决策：
- 系统组成的结构元素及其接口的选择
- 这些元素之间协作所指定的行为
- 这些结构和行为元素组合成更大的子系统
- 指导这种组织的架构风格
还涉及：使用、功能、性能、弹性、复用、可理解性、经济与技术约束与权衡、美学考量。
5.2 架构风格（Architectural Style）
架构风格定义了一个系统家族，以结构组织模式为特征。
架构风格定义了：
- 组件和连接件类型的词汇表（如管道、过滤器、对象、进程）
- 组合约束（如何连接它们的规则）
- 一个或多个语义模型（如何从部分属性推导整体属性）
5.3 好架构的特征
- Resilient（有弹性的）—— 能承受变化和故障
- Simple（简单的）—— 没有不必要的复杂性
- Approachable（可接近的）—— 新人容易理解
- Clear separation of concerns（清晰的关注点分离）
- Balanced distribution of responsibilities（责任均衡分配）
- Balances economic and technology constraints（平衡经济与技术约束）
六、Kruchten 4+1 视图模型
软件架构需要从多个视角描述，单一视图不足以覆盖所有利益相关者的关注点。
| 视图 | 视角 | 关注者 | 关注点 |
|---|---|---|---|
| 逻辑视图（Logical View） | 功能需求 | 最终用户 | 系统功能、类、对象 |
| 进程视图（Process View） | 并发与同步 | 系统集成者 | 性能、可伸缩性、吞吐量 |
| 开发视图（Implementation View） | 软件管理 | 程序员 | 包、模块、子系统 |
| 物理视图（Deployment View） | 系统拓扑 | 系统工程师 | 部署、安装、通信 |
| +1：用例视图（Use Case View） | 场景驱动 | 所有利益相关者 | 串联其他四个视图 |
6.1 视图之间的关系
- 逻辑视图 ↔ 组件视图 ↔ 进程视图 ↔ 部署视图
- 每个视图关注不同的结构维度，但相互关联
- UML 中对应：设计视图（类/接口/协作）、实现视图（组件）、进程视图（主动类）、部署视图（节点）
6.2 架构上的重要元素
不是所有设计都是架构：
- 主要”业务”类
- 重要机制
- 处理器和进程
- 层和子系统
架构视图 = 穿过模型的切片，只保留架构上重要的元素。
七、架构模式（Architectural Patterns）
7.1 模式的三个层次
- Idioms（惯用法）—— 语言级（如C++的RAII）
- Design patterns（设计模式）—— 模块级（GoF的23种）
- Architectural patterns（架构模式）—— 系统级
7.2 常见架构模式（Shaw & Garlan / Buschmann）
| 类别 | 模式 |
|---|---|
| 分布式 | Distributed |
| 事件驱动 | Event-driven |
| 基于框架 | Frame-based |
| 批处理 | Batch |
| 管道-过滤器 | Pipes and filters |
| 仓库式 | Repository-centric |
| 黑板 | Blackboard |
| 解释器 | Interpreter |
| 基于规则 | Rule-based |
| 分层 | Layered |
| MVC | Model-View-Controller |
| 信息检索中心 | IR-centric |
| 包容式 | Subsumption |
| 一次性 | Disposable |
八、逻辑架构 vs 物理架构
8.1 逻辑应用架构（三层）
图形用户界面 ← 表现层
业务对象模型 ← 业务逻辑层
关系型数据库 ← 数据层
8.2 物理应用架构的演进
从胖客户机 → 瘦客户机/胖服务器 → n层分布式架构
典型技术栈：
- COM/DCOM/MTS 体系
- CORBA/Beans/ETS 体系
- Web/HTML/CGI/ASP/Java 体系
- J2EE 多层架构（Browser → JSP/Servlet → EJB → DBMS）
- .NET Framework 体系（多语言 + CLR + 基类库 + ADO.NET + ASP.NET）
九、RUP 与架构中心主义
9.1 RUP 的四大特征
- 迭代式（Iterative）
- 架构为中心（Architecture-centric）
- 用例驱动（Use-case driven）
- 直面风险（Risk confronting）
9.2 架构在 RUP 中的位置
Inception Elaboration Construction Transition
│ │ │ │
├────────────┼────────────┼────────────┤ 时间
│ 架构基线（Architecture Baseline）
▼
先形成可执行的架构骨架，再在此基础上增量构建功能
在 Elaboration（细化）阶段 结束时，必须形成稳定的架构基线。
9.3 架构设计的产出
- 识别、选择并验证”架构上重要的”元素
- 产出 软件架构文档（Software Architecture Document）
十、架构的来源
| 系统类型 | 方法比例 |
|---|---|
| 经典系统（有先例） | 借鉴（Theft）+ 方法（Method）+ 直觉（Intuition） |
| 前所未有的系统 | 方法（Method）+ 直觉（Intuition）+ 借鉴（Theft） |
好的架构师善用已有模式和实践，而非每次从零开始。
十一、架构领域的未来方向
- ADL（架构描述语言）：UML、UniCon、LILEAnna、P++、LEAP、Wright、μRapid 等
- 概念标准化：IEEE 架构工作组、INCOSE 系统架构工作组
- 架构模式的系统化整理：从零散经验到模式语言
十二、推荐参考文献
- Bass, Clements & Kazman — Software Architecture in Practice（SAiP，软件架构实践）
- Buschmann et al. — Pattern-Oriented Software Architecture: A System of Patterns（POSA，面向模式的软件架构）
- Hofmeister, Nord, Soni — Applied Software Architecture
- Clements, Kazman, Klein — Evaluating Software Architectures: Methods and Case Studies
- Gamma, Helm, Johnson, Vlissides — Design Patterns（GoF 设计模式）
- Kruchten — “The 4+1 View Model of Architecture”（IEEE Software 1995）
- Shaw & Garlan — Software Architecture: Perspectives on an Emerging Discipline
- Witt, Baker, Merritt — Software Architecture and Design: Principles, Models, and Methods
- Rechtin & Maier — The Art of System Architecting
- IEEE 1471 — Recommended Practice for Architectural Description
关键概念速查
- 架构 = 结构 + 组件 + 属性 + 关系 + 原则 + 演进
- 好架构的6个特征：弹性、简单、可接近、关注点分离、责任均衡、约束平衡
- 4+1视图：逻辑/进程/开发/物理 + 用例
- 架构风格三要素：词汇表、组合约束、语义模型
- 三层架构：表现层 → 业务逻辑层 → 数据层
- RUP架构基线：细化阶段结束时形成稳定可执行架构
- 复杂性是最大的敌人——架构的核心使命是驯服复杂性
笔记由云盘图书管理员整理自课程第1讲PDF。原文件约70+页PPT，周立新博士授课。
设计模式课程-第3讲-原则 （相关：设计原则与架构原则的关系） 《代码整洁之道》-Clean Code （相关：设计质量与架构质量的关联） 《敏捷软件开发》-原则模式与实践-Robert-C-Martin （相关：SOLID原则与架构设计） 《STL源码剖析》-侯捷 （相关：组件设计的架构实践）