IEEE 1471-2000 - 软件密集系统架构描述推荐实践
主讲人：Rich Hilliard 讲座时间：2000年11月14日 来源：北京大学软件与微电子学院 0B105 软件体系结构课程 Lecture-1
概述
IEEE Std 1471-2000 是 IEEE 计算机协会发布的《软件密集系统架构描述推荐实践》（Recommended Practice for Architectural Description of Software-Intensive Systems），2000年10月正式发布。这是软件架构领域的第一个 IEEE 标准，建立了架构描述的概念框架和术语体系。
什么是 IEEE 1471
- 推荐实践（Recommended Practice）：IEEE 标准的一种类型，使用组织自行决定是否以及如何采用
- 适用对象：架构描述（Architectural Description, AD）本身——只有架构描述可以声称符合 IEEE 1471
- 不适用对象：系统、项目、流程或组织本身不能”符合”1471
- 核心定位：描述”如何描述架构”，而非规定”应该有什么架构”或”应该用什么流程”
历史沿革
| 阶段 | 时间 | 说明 |
|---|---|---|
| 架构规划组（APG） | 1995.08 首次会议 | 6 名参与者，80 名评审者 |
| 1996.04 | 向 IEEE 软件工程标准委员会提交最终报告 | |
| 架构工作组（AWG） | 1996.05 - 1999.12 | 29 名参与者，137 名评审者，双月例会 |
| 正式发布 | 2000.10 | IEEE-Std-1471-2000 |
目标与使命
IEEE 软件工程标准委员会授权的五大目标：
- 定义方向：将架构思维纳入 IEEE 标准体系
- 宽范围：架构概念适用于各种软件密集系统
- 概念框架：建立讨论架构问题的词汇和概念基础
- 推广实践：识别并推广健全的架构实践
- 预留演进：允许实践随技术成熟而演进
核心概念定义
架构（Architecture）
架构：一个系统的基本组织，体现为其组件、组件之间以及组件与环境的相互关系，以及指导其设计和演进的原则。
关键词解读：
- 基本组织（fundamental organization）：本质性的、统一的概念和原则
- 系统（system）：包括应用、系统、平台、系统之系统（system-of-systems）、企业、产品线等
- 环境（environment）：开发、运行、规划等系统所处的上下文
架构描述（Architectural Description, AD）
架构描述是用于记录架构的产品集合。
特点：
- 不规定格式或媒介：与记法无关（notation-independent）
- 规定最低要求内容：反映当前实践和共识的最低必需内容
- 使用 “shall”（必须）、“should”（应该）、“may”（可以）三级规范语言
IEEE 1471 概念框架
完整的概念模型包含以下核心实体及其关系：
Mission ── fulfills ──> System
Environment ── inhabits ──> System
System ── has ──> Architecture
Architecture ── described by ──> Architectural Description (1)
Architectural Description ── identifies ──> Stakeholder (1..*)
Stakeholder ── is important to ──> Concern (1..*)
Concern ── is addressed to ──> Architectural Description
Architectural Description ── has ──> Viewpoint (1..*)
Viewpoint ── selects ──> View (1..*)
View ── covers ──> Concern (1..*)
View ── consists of ──> Model (1..*)
Viewpoint ── has source ──> Viewpoint Library (0..1)
Architectural Description ── provides ──> Rationale
六大核心概念
| 概念 | 定义 | 关键特征 |
|---|---|---|
| 系统（System） | 有组织的组件集合，为完成特定功能而设计 | 存在于环境中，有使命 |
| 利益相关者（Stakeholder） | 对系统有利益或关注的个人、团队或组织 | 1..* 个，有不同角色 |
| 关注点（Concern） | 利益相关者关心的与系统相关的问题 | 是架构完整性的基础 |
| 架构描述（AD） | 记录架构的产品集合 | 与利益相关，多视图组织 |
| 视点（Viewpoint） | 构建视图的模式/模板 | 一等公民，需声明后使用 |
| 视图（View） | 从一组关注点视角出发对整个系统的表示 | 每个视图对应恰好一个视点 |
架构描述的要求
1. 利益相关者与关注点
- AD 与利益相关：架构描述必须识别系统的利益相关者及其关注点
- 完整性基准：架构描述必须回应所有利益相关者的关注点
- 典型利益相关者角色（16种）：
| 类别 | 角色 |
|---|---|
| 需求方 | Client（客户）、Acquirer（采购方）、Owner（所有者）、Planner（规划者） |
| 使用方 | User（用户）、Operator（操作员）、Service Provider（服务提供商） |
| 开发方 | Developer（开发者）、Designer（设计者）、Builder（构建者）、Architect（架构师）、System Engineer（系统工程师） |
| 供应方 | Vendor（供应商）、Subcontractor（分包商） |
| 维护方 | Maintainer（维护者） |
2. 视图（Views）
- 多视图原则：一个 AD 由一个或多个视图组成
- 视图定义：从一组关注点的视角对整个系统的表示
- 模块化：视图可包含一个或多个架构模型，允许同一视图使用多种记法
- 视图间一致性：AD 必须记录视图之间所有已知的不一致性
3. 视点（Viewpoints）
- 良构性：每个视图恰好对应一个视点
- 视点是模式：定义视图的构建规则
- 无固定集合：IEEE 1471 对视点来源保持中立（agnostic）
- 关注点驱动选择：每个关注点都由某个架构视图回应
- 一等公民：每个使用的视点都必须在使用前声明
视点声明的必需内容
- 视点名称
- 该视点面向的利益相关者
- 该视点要解决的利益相关者关注点
- 视点语言、建模技术或分析方法
- 视点来源（如作者、文献引用）
视点可选包含内容
- 与底层方法相关的一致性或完整性检查
- 可应用于模型的评估或分析技术
- 辅助合成视图或模型的启发式、模式或其他指南
4. 架构理由（Architectural Rationale）
架构描述必须提供架构决策的理由说明。
视点示例
示例一：能力视点（Capability Viewpoint）
| 属性 | 内容 |
|---|---|
| 名称 | Capability（能力） |
| 利益相关者 | 客户、生产者、开发者、集成者 |
| 关注点 | 功能如何打包？如何部署？管理哪些接口？ |
| 语言 | UML 组件图（组件及其依赖）+ UML 类图（接口及其属性） |
| 来源 | 也称为 Static、Application、Structural 视点 |
能力视图特点：
- 覆盖所有数据操作系统功能
- 采用 5 层分层组织，层间有接口
- 每一层本身也是一种能力
- 整个栈是可部署的能力
- 能力可以服务于其他能力
示例二：结构视点（Structural Viewpoint）
| 属性 | 内容 |
|---|---|
| 关注点 | 系统的计算元素及其组织？系统由什么元素组成？接口是什么？如何互连？互连机制是什么？ |
| 语言 | 组件、连接器、端口和角色、属性（基于 Acme ADL） |
| 分析方法 | 连接性、类型一致性 |
视点规模谱系
IEEE 1471 旨在涵盖不同规模的视点体系：
| 体系 | 视点/视图数量 | 代表 |
|---|---|---|
| 最小 | 隐式结构主义 | CMU |
| 经典 | 4+1 视图模型 | Kruchten / Rational（逻辑/过程/开发/物理 + 用例） |
| 中等 | 三视图 | C4ISR（作战/技术/系统） |
| 大型 | 36 视图 | Zachman 框架 |
| 特大型 | 5 视图 | AF 集成 C2 系统（能力/数据/分发/安全/构建） |
库视点（Library Viewpoints）
- 视点不是系统特定的（不同于利益相关者和视图）
- 因此活跃的架构师可以复用视点描述
- 视点可以通过引用方式包含进来
标准组织结构
IEEE 1471 标准全文结构：
正文
| 章节 | 标题 | 内容 |
|---|---|---|
| 1 | Overview（概述） | 范围、目的、目标用户、符合性 |
| 2 | References（参考文献） | 引用标准 |
| 3 | Definitions and acronyms（定义与缩写） | 术语定义 |
| 4 | Conceptual framework（概念框架） | 架构描述上下文、利益相关者、生命周期活动、AD 用途 |
| 5 | Architectural Description practices（架构描述实践） | 架构文档、利益相关者识别、视点选择、架构视图、视图一致性、架构理由、示例 |
附录
| 附录 | 标题 |
|---|---|
| A | Bibliography（参考书目） |
| B | Notes on terminology（术语说明） |
| C | Examples of viewpoints（视点示例） |
| D | Relationship to other standards（与其他标准的关系） |
应用与影响
已应用领域
- 软件密集系统架构课程：纳入高校课程体系
- TOGAF：The Open Group Architecture Framework
- SARA：Software Architecture Review and Assessment 行业组织
- 企业实践：Hewlett-Packard、Rational
- 国防系统：空军指挥控制系统目标架构
后续工作方向
- 通过架构师课程推广推荐实践
- 编写推荐实践指南
- 持续演进和完善
关键洞见
-
架构描述的”利益相关”本质：架构不是客观描述，而是围绕利益相关者的关注点组织的——这是 1471 最核心的认识论转向
-
视点一等公民：视点不是附属物，而是架构描述的基本组织单元。每个视点必须声明其服务的利益相关者和要解决的关注点——这从机制上保证了架构不会脱离实际需求
-
多视图的必要性：单一视图无法覆盖所有利益相关者的所有关注点。多视图不是”可选的豪华配置”，而是架构完整性的必然要求
-
标准的克制：1471 不规定具体的架构描述语言、不规定必需的视图、不规定形式化的一致性标准——它只规定”架构描述应该包含哪些要素”，把具体选择留给实践者
-
与 4+1 视图模型的关系：Kruchten 的 4+1 是特定的视点集合，而 1471 是关于”如何组织视点”的元标准。4+1 可以作为符合 1471 的一种具体视点库来使用