知识库

软件体系结构概述 - Software Architecture An Overview

24分钟阅读

软件体系结构概述 — Software Architecture: An Overview

北京大学软件与微电子学院 周立新博士 《软件体系结构》课程第1讲 103页完整课件，覆盖架构定义、建筑类比、复杂性、4+1视图、RUP架构中心主义、架构模式、架构师角色、行业实例等十二大模块

一、软件架构设计师

国内现状

  • 以架构为中心组织软件开发是 RUP 的核心思想，为软件项目带来革命性变化和效益
  • 对开发团队提出严峻挑战，称职的软件架构师成为成败关键
  • 国内软件业最缺的人才就是软件架构师

架构师的八大职责

  1. 规划产品的开发、演进体系
  2. 分析与构思核心的软件体系架构
  3. 规划与建设组织级的软件重用库
  4. 负责组织级软件技术资产的积累与管理
  5. 领导与协调项目组的主要技术活动，对主要技术工作产品负责
  6. 负责项目组的体系架构设计，定义系统的高层结构与接口
  7. 指导系统设计、开发人员细化与实现既定的体系架构
  8. 协助制定与评审软件开发计划

架构师的资质与技能要求

  • 具备完整的软件工程理论体系知识
  • 多才多艺、成熟练达、洞察力强、经验丰富
  • 软件领域 5~10 年以上工作经验
  • 精通 RUP 软件过程体系
  • 精通各类软件架构体系：分布式计算架构（三层/Corba/J2EE/.NET）、管道过滤器架构等
  • 精通企业级应用核心技术：事务处理、安全机制、消息队列等
  • 精通 OOA/OOD
  • 具备业务领域的信息化技术知识
  • 精通体系架构的设计方法
  • 掌握 UML/Rose 建模、RequisitePro 需求管理等工具
  • 掌握 ClearCase/ClearQuest 配置与变更管理工具

二、什么是软件架构（五种经典定义对比）

软件架构是需求与实现之间的桥梁，辅助软件工程的许多方面。

1. Fred Brooks 定义（《人月神话》）

“概念完整性是系统设计中最重要的考量。” “系统的架构是’用户’接口的完整且详细的规格说明。”

—— 强调概念完整性和用户接口视角

2. Roger Pressman 定义

“架构设计的首要目标是开发模块化的程序结构，并表示模块之间的控制关系。”

—— 强调模块化和控制结构

3. David Garlan & Dewayne Perry 定义（IEEE TSE 1995）

程序/系统的组成部分的结构、它们之间的相互关系，以及指导其设计和随时间演进的原则和准则。

—— 强调结构 + 关系 + 原则 + 演进

4. Bass, Clements & Kazman 定义（《软件架构实践》1997）

程序或计算系统的软件架构是系统的一个或多个结构，这些结构包括软件组件、这些组件的外部可见属性，以及它们之间的关系。

—— 强调多结构 + 组件外部属性 + 关系，是最广泛引用的定义之一

5. ANSI/IEEE Std 1471-2000 标准定义

（详见 IEEE-1471-软件架构描述标准 笔记）

—— 国际标准，系统定义架构描述的框架

三、为什么软件架构重要

八大价值

  1. 简化复杂系统 — 通过抽象和分层降低理解成本
  2. 组件复用 — 架构级复用比代码级复用收益更高
  3. 辅助沟通 — 架构是利益相关者之间的通用语言
  4. 系统演进 — 好的架构支持平滑演进
  5. 培训新成员 — 架构是新人快速上手的地图
  6. 改进项目管理 — 架构基线是项目管理的重要参照
  7. 改进软件构建 — 架构指导开发，减少返工
  8. 提供系统分析 — 架构是质量属性分析的基础

架构作为成熟学科的标志

一个成熟工程学科的关键属性是在新系统开发中常规使用已有解决方案。 设计通过纳入手册、技术出版物和企业标准而制度化。 这些传播方法带来高水平的设计复用。

四、建筑类比：软件架构 vs 土木工程

古典建筑类比（Shaw & Garlan）

维度建筑软件
表示法蓝图、物理模型、透视图结构图 + 行为视图 + 信息视图
架构风格罗马式、哥特式、维多利亚式分布式、分层、客户/服务器
约束条件声学、气流、采光吞吐量、时序、容错、易用性
标准/实践建筑规范与检查接口标准与评审/审查

化工过程类比（Unit Process Architecture）

维度化工软件
组件单元操作（如热交换器）架构组件（如 DBMS）
连接件管道、传送带过程调用、管道
架构风格操作方式（间歇、连续）拓扑风格（管道过滤器、黑板）
约束条件过程中元素的先后顺序执行序列中元素的先后
表示法过程流程图ADL（架构描述语言）
产品化工厂应用系统

不同规模的架构对比

规模建筑类比所需条件
狗屋1人可建最少建模、简单过程、简单工具
房屋团队高效建造需要建模、明确过程、强力工具
摩天大楼多团队/多公司大量建模、复杂需求定义过程、众多工具

建筑演进史的启示

  • 青铜时代/埃及（Imhotep）：模仿前人努力
  • 希腊/罗马（Vitruvius）：从失败中学习、整合其他力量、实验
  • 拜占庭/罗马式 → 哥特式 → 风格主义 → 巴洛克 → 工程/理性 → 新艺术运动 → 现代运动（Wright, Le Corbusier）
  • 现代建筑进步：材料进步 + 分析方法进步 → 5倍于万神殿跨度，3倍于胡夫金字塔高度

Brand 剪切层理论（How Buildings Learn）

建筑的不同部分以不同速率变化：

  1. Site（场地） — 最慢，几百年不变
  2. Structure（结构） — 几十年
  3. Skin（表皮） — 十几年
  4. Services（服务设施） — 几年
  5. Space plan（空间规划） — 几年
  6. Stuff（家具物品） — 最快，随时变化

软件架构也有类似的分层变化规律：底层架构稳定，上层功能快速迭代。

五、软件复杂性与架构的作用力

Walker Royce：软件复杂性维度矩阵

技术复杂度从低到高：

  • 低技术：4GL 或基于组件、应用再造、交互性能
  • 高技术：嵌入式/实时/分布式/容错、定制/前所未有的/架构再造、高性能

管理复杂度从低到高：

  • 低管理：小规模、非正式、单一利益相关者、“产品”
  • 高管理：大规模、合同性、多利益相关者、“项目”

典型项目分布：

  • 商业电子表格（低技术 + 低管理）
  • IS 应用 GUI/RDB（中等）
  • 电信交换机（高技术 + 高管理）
  • 国家空中交通管制系统（最高）

软件架构的作用力（质量属性）

  • 功能性 / Functionality
  • 容量 / Capacity
  • 性能 / Performance, Throughput
  • 可用性 / Availability
  • 容错 / Fault tolerance, Fail safe
  • 弹性 / Resilience
  • 成本 / Cost
  • 兼容性 / Compatibility
  • 技术 churn / 技术演进压力

“未来20年的挑战不是速度、成本或性能，而是复杂性问题。” — Bill Raduchel, Sun Microsystems CSO “我们的敌人是复杂性，我们的目标是消灭它。” — Jan Baan

六、架构的领域模型与元模型

Wojtek Kozaczynski：架构的领域

架构位于 “为什么”（Why） 和 “如何做”（How） 之间：

  • Why — 架构质量（Architecture Qualities）
  • What — 架构表示（Architecture Representation）→ 系统功能 → 满足软件需求 → 系统质量属性
  • How — 架构过程（Architecture Process）→ 由架构师执行 → 定义角色 → 组织

Shaw / Booch / Kruchten：架构定义

软件架构包含关于软件系统组织的一系列重大决策：

  1. 系统组成的结构元素及其接口的选择
  2. 这些元素之间协作所指定的行为
  3. 将这些结构和行为元素组合成更大的子系统
  4. 指导这种组织的架构风格

还涉及：使用、功能、性能、弹性、复用、可理解性、经济和技术约束与权衡、美学考量

架构风格（Architectural Style）

架构风格定义了一个系统家族，按照结构组织的模式来定义。

架构风格定义了：

  • 一套组件和连接件类型的词汇表
  • 一组关于如何组合它们的约束
  • 一个或多个语义模型，说明如何从部分的性质确定系统的整体性质

架构元模型（Architecture Metamodel）

软件架构
├── 是系统架构的一部分
├── 由软件架构师参与
├── 由架构设计过程产生
├── 由软件架构描述表示
├── 由架构风格指导
│   └── 架构模式
├── 由架构视图构成
│   ├── 逻辑视图（Logical View）
│   ├── 过程视图（Process View）
│   ├── 实现视图（Implementation View）
│   ├── 部署视图（Deployment View）
│   └── 用例视图（Use Case View）
├── 描绘组件（Component）
│   ├── 形式（Form）
│   └── 连接（Connection）
├── 满足约束
│   └── 需求
└── 由架构蓝图记录

架构视图（Architectural View）

架构视图是从特定视角或有利点对系统的简化描述（抽象），覆盖特定关注点，省略与该视角无关的实体。

架构显著性元素

不是所有设计都是架构。架构上重要的元素包括：

  • 主要”业务”类
  • 重要机制
  • 处理器和进程
  • 层和子系统
  • 接口

好架构的六大特征

  1. 有弹性（Resilient）
  2. 简单（Simple）
  3. 可接近（Approachable）
  4. 清晰的关注点分离（Clear separation of concerns）
  5. 均衡的职责分配（Balanced distribution of responsibilities）
  6. 平衡经济和技术约束（Balances economic and technology constraints）

七、Kruchten 4+1 视图模型

五大视图

视图视角关注点主要观众
逻辑视图（Logical View）功能需求系统功能、概念完整性最终用户
过程视图（Process View）并发/分布性能、可伸缩性、吞吐量系统集成者
实现视图（Implementation View）软件管理软件模块组织、编程程序员
部署视图（Deployment View）系统拓扑硬件部署、安装、交付系统工程师
用例视图（Use Case View）+1视图连接其他四个视图，验证架构所有利益相关者

视图之间的关系

  • 逻辑视图 ↔ 组件视图（α 映射）
  • 过程视图 ↔ 部署视图（β 映射）

UML 中的对应关系

架构视图UML 表示
设计视图（逻辑）类、接口、协作
实现视图组件
用例视图用例
过程视图主动类
部署视图节点
组织包、子系统
动态交互、状态机

八、RUP 与架构中心主义

Rational Unified Process 四大特征

  1. 迭代式（Iterative）
  2. 以架构为中心（Architecture-centric）
  3. 用例驱动（Use-case driven）
  4. 对抗风险（Risk confronting）

架构中心主义

  • 模型是可视化、规格说明、构建和记录架构的工具
  • 统一过程规定可执行架构的连续精化
  • 时间线：先启（Inception）→ 精化（Elaboration）→ 构建（Construction）→ 移交（Transition）
  • 架构基线在精化阶段建立

架构设计活动

  1. 识别、选择和验证”架构上重要”的元素
  2. 不是所有东西都是架构（只有主要业务类、重要机制、处理器和进程、层和子系统、接口）
  3. 产出软件架构文档（SAD）

架构的三个来源

来源经典系统前所未有的系统
方法（Method）yy
偷窃（Theft）y—
直觉（Intuition）yy

经典系统可以更多借鉴已有方案，前所未有的系统更多依赖方法和直觉。

九、架构模式全景

模式的层次

模式是上下文中问题的解决方案。 模式将从领域经验中收集的特定知识编码化。

三个层次：

  1. 惯用法（Idioms） — 语言特定的低层技巧
  2. 设计模式（Design patterns） — 中观，GoF 23种
  3. 架构模式（Architectural patterns） — 宏观，系统级结构

Shaw & Garlan 分类（8大经典架构风格）

  • 分布式（Distributed）
  • 事件驱动（Event-driven）
  • 基于框架（Frame-based）
  • 批处理（Batch）
  • 管道过滤器（Pipes and filters）
  • 以仓库为中心（Repository-centric）
  • 黑板（Blackboard）
  • 解释器（Interpreter）
  • 基于规则（Rule-based）

Buschmann 等（POSA 卷1）分类

  • 分层（Layered）
  • MVC
  • 以信息检索为中心（IR-centric）
  • 包容（Subsumption）
  • 一次性（Disposable）
  • ……等

逻辑应用架构（三层架构）

图形用户界面
    ↕
业务对象模型
    ↕
关系数据库

物理应用架构：瘦客户端/胖服务器演进

  • 客户端：GUI 组件
  • 应用服务器：业务对象服务 + 业务对象引擎（COM/MTS/CORBA Beans/EJB）
  • 数据库服务器：RDBMS
  • Web 层：HTML/CGI/ASP/Java

互联网第二波浪潮（Paul Dreyfus, Netscape）

复杂互联网系统的五层架构：

  1. 客户端（DHTML/JS/Java 插件）
  2. Web 服务器（Java/C/C++/CGI）
  3. 应用服务器（Java/C/C++/JavaBeans/CORBA/DCOM）
  4. 后端系统（履约/财务/库存）
  5. RDBMS 服务器

十、架构师角色与团队

架构师是什么，不是什么

  • 不只是高层设计师 — 需要确保可行性
  • 不是项目经理 — 但”紧密相连”（joined at the hip）
  • 不只是技术专家 — 更关注系统目的和”适配性”
  • 不是孤独的科学家 — 沟通者

架构师的素质

  • 经验（软件开发经验 + 领域经验）
  • 主动、目标导向
  • 领导力、权威
  • 架构团队（需要平衡）

软件架构团队宪章（七大职责）

  1. 定义软件的架构
  2. 维护软件的架构完整性
  3. 评估与软件设计相关的技术风险
  4. 提议连续迭代的顺序和内容
  5. 咨询服务
  6. 协助未来产品定义的市场营销
  7. 促进项目团队之间的沟通

架构就是决策

软件架构师的生命是一长串（有时痛苦的）次优决策序列，部分在黑暗中做出。

架构师的六大活动

  1. 理解领域需求
  2. 开发/选择架构
  3. 表示/沟通架构
  4. 分析/评估架构
  5. 基于架构实现系统
  6. 确保实现符合架构（一致性保障）

十一、行业架构实例

1. 建筑市场监督管理信息系统

  • 项目管理框架
  • 系统体系结构分析设计
  • 构件开发 + 子系统集成 + 系统部署
  • 开发协调 + 程序管理

2. 中山大学数字化校园

  • 统一用户管理 + 通用/专用信息服务
  • 统一系统平台与资源管理
  • 大容量存储 + 超级计算 + 统一数据库
  • 基础设施 + 系统与信息安全体系 + 校园门户

3. 用友 CRM v2.0

  • 三大业务操作：市场自动化 + 销售自动化 + 服务自动化
  • 前台应用 + 后台应用（供应链/ERP/财务/物流/OA/HR）
  • 数据挖掘 + OLAP + 数据库/数据仓库
  • 与 U8/NC 两大产品线结合

4. 数字化校园财务管理系统（北大实践）

  • 信息共享与自动化：校级财务 ↔ 各部门系统 ↔ 银行
  • 三层体系：部门会计 → 财务服务器 → WEB 应用/数据库

5. 上海电信大客户网管系统

  • 四层架构：业务管理 → 网络管理 → 通信接口网关 → 厂商设备
  • CORBA/SML/TCP-IP 多协议
  • 多厂商适配：华为/北电/朗讯/Cisco 等
  • SNMP/Q3/TL1/ASCII/专有 多协议网关

6. 电子业务智能平台 Matrix

  • 服务渠道门户 + 业务协作门户 + 业务智能代理 + 业务智能服务器
  • Matrix XMA Framework

7. .NET Framework 体系架构

  • 语言层：VB/C++/C#/J#/…
  • 公共语言规范（CLS）
  • 基类库 + ADO.NET 和 XML
  • 公共语言运行库（CLR）
  • 操作系统层
  • ASP.NET/Web 表单/Web 服务
  • Visual Studio .NET

8. J2EE 体系架构

  • 客户端：Browser / Rich Client
  • Web 层：JSP / Servlets
  • 业务层：EJB
  • 企业信息系统层：DBMS
  • 协议：HTTP/IIOP/JDBC 等

十二、未来方向与参考书目

三大发展方向

  1. ADL（架构描述语言） — UML, UniCon, LILEAnna, P++, LEAP, Wright, µRapid
  2. 概念标准化 — IEEE 架构工作组、INCOSE 系统架构工作组
  3. 架构模式的系统化捕获 — 将经验编码为可复用的模式

核心参考书目

  1. Bass, Clements & Kazman, Software Architecture in Practice, 2nd Ed., Addison-Wesley, 2003
  2. Buschmann et al., Pattern-Oriented Software Architecture - A System of Patterns, Wiley, 1996
  3. Hofmeister, Nord & Soni, Applied Software Architecture, Addison-Wesley, 1999
  4. Clements, Kazman & Klein, Evaluating Software Architectures: Methods and Case Studies, Addison-Wesley, 2002
  5. Gamma, Helm, Johnson & Vlissides, Design Patterns, Addison-Wesley, 1995
  6. Philippe Kruchten, “The 4+1 View Model of Architecture,” IEEE Software, 1995
  7. Eberhardt Rechtin, Systems Architecting: Creating and Building Complex Systems, Prentice-Hall, 1991
  8. Rechtin & Maier, The Art of System Architecting, CRC Press, 1997
  9. Mary Shaw & David Garlan, Software Architecture — Perspectives on an Emerging Discipline, Prentice-Hall, 1996
  10. Witt, Baker & Merritt, Software Architecture and Design — Principles, Models, and Methods, Van Nostrand Reinhold, 1995
  11. IEEE P1471 Recommended Practice for Architectural Description

核心洞见

  1. 架构是复杂度管理的核心武器 — 未来20年软件的最大挑战不是性能而是复杂性，架构是驯服复杂性的主要工具
  2. 架构是决策的集合 — 架构师的工作就是持续做出次优决策，重要的是决策的一致性和可演进性
  3. 多视角原则 — 单一视图无法完整描述复杂系统，4+1 视图模型提供了经典的多视角框架
  4. 建筑类比的深度 — 从建筑史中可以学到架构演进的规律：从模仿到实验、从工艺到工程、剪切层变化理论
  5. 质量属性驱动 — 功能性只是一个维度，性能/可用性/可维护性/成本等质量属性才是架构决策的主要驱动力
  6. 架构中心主义 — RUP 将架构置于软件开发的中心，架构基线是迭代开发的稳定基石

关联笔记：

关系图谱