知识库

IEEE Std 1471-2000 软件密集型系统架构描述推荐实践

13分钟阅读

IEEE Std 1471-2000 — 软件密集型系统架构描述推荐实践

IEEE 软件架构领域的奠基性标准，2000年9月21日批准，定义了架构描述的概念框架、核心术语和实践规范。

一、标准概述

地位

IEEE Std 1471-2000 是软件架构领域第一个国际标准，由 IEEE 软件工程标准委员会（SESC）下属的架构规划组（APG）自1995年8月启动制定，历时5年完成。它为软件密集型系统的架构描述建立了统一的术语体系和概念框架。

后续演进：2007年被 ISO/IEC 42010:2007 采纳为国际标准，2011年更新为 ISO/IEC/IEEE 42010:2011（系统与软件工程——架构描述）。

范围

适用于软件密集型系统——即软件在系统整体的设计、构建、部署和演进中起决定性影响的系统。架构描述（AD）可用于：

  1. 表达系统及其演进
  2. 系统利益相关者之间的沟通
  3. 以一致方式评估和比较架构
  4. 规划、管理和执行系统开发活动
  5. 表达系统的持久特性和指导可接受变更的原则
  6. 验证系统实现是否符合架构描述
  7. 记录软件密集型系统架构知识体系的贡献

目的

通过标准化架构描述的元素和实践，促进架构的表达与沟通，从而为质量提升和成本降低奠定基础。

标准的核心前提是：架构隐喻——借鉴民用建筑的早期决策模式，在系统开发的最早阶段做出关键设计决策。

目标用户

  • 主要用户：系统使用者/获取者、架构师、开发/交付/维护人员、评估/审计人员
  • 次要用户：方法学家、流程工程师、研究者、标准制定者、工具开发者、培训师

二、十大核心定义

编号术语定义
1acquirer（获取方）从供应方采购系统、软件产品或服务的组织（买方、客户、所有者、用户、采购方）
2architect（架构师）对系统架构负责的个人、团队或组织
3architecting（架构活动）定义、记录、维护、改进和验证架构正确实现的一系列活动
4architectural description (AD)（架构描述）用于记录架构的一组产品的集合
5architecture（架构）系统的基本组织，体现为其组件、组件之间及组件与环境之间的关系，以及指导其设计和演进的原则
6life cycle model（生命周期模型）包含软件产品开发、运行和维护所需过程、活动和任务的框架，跨越从需求定义到终止使用的整个系统生命期
7system（系统）为完成特定功能而组织起来的组件集合
8system stakeholder（系统利益相关者）对系统有兴趣或有关注点的个人、团队或组织（或其类别）
9view（视图）从一组相关关注点的角度对整个系统的表示
10viewpoint（视点）构造和使用视图的约定的规范。是开发单个视图的模式或模板，规定了视图的目的、受众以及创建和分析视图的技术

三、概念框架

核心概念关系链

使命 (Mission)
    ↓ 履行
系统 (System) ← 影响 → 环境 (Environment / Context)
    ↓ 有
架构 (Architecture)
    ↓ 记录
架构描述 (AD)
    ↓ 组织为
视图 (View) → 对应 → 视点 (Viewpoint)
    ↓ 组成
架构模型 (Architectural Model)

关键概念辨析

  1. 系统与环境：系统存在于环境中，环境决定系统的边界和范围，包括其他交互系统、开发/运行/政治等影响因素。

  2. 利益相关者与关注点：每个系统有一个或多个利益相关者，每个利益相关者有其关注点（concerns）——涉及系统开发、运行或其他方面的重要利益。关注点包括性能、可靠性、安全性、分布性、可演进性等。

  3. 架构与架构描述的分离：架构是概念性的，架构描述是具体的制品。每个系统都有架构，无论是否被记录。

  4. 视图与视点的关系：类比于面向对象中的”类与对象”——viewpoint : view = class : object。视点是模板/约定，视图是特定系统的实际表示。

  5. 多视图的必要性：单一视角无法覆盖所有利益相关者的所有关注点。标准不规定具体需要哪些视图，而是通过视点机制允许定制和演进。

架构描述的四大用途

  1. 决策支持：帮助利益相关者理解和评估架构
  2. 沟通：在利益相关者之间建立共同语言
  3. 系统构建指南：指导开发、测试和部署
  4. 演进管理：指导系统变更和维护

四、架构描述实践（六大核心要素）

符合本标准的架构描述必须包含以下六大要素：

5.1 架构文档（AD整体信息）

AD 必须包含以下8项整体信息：

  1. 发布日期和状态
  2. 发布组织
  3. 变更历史
  4. 摘要
  5. 范围
  6. 上下文/环境
  7. 术语表
  8. 参考文献

5.2 利益相关者与关注点识别

必须识别架构相关的利益相关者和关注点。

最低要求的利益相关者（4类）：

  • 系统用户
  • 系统获取方/客户
  • 系统开发者
  • 系统维护者

最低要求的关注点（5类）：

  • 系统的目的或使命
  • 系统完成使命的适当性
  • 构建系统的可行性
  • 系统开发和运行对用户、获取方和开发者的风险
  • 系统的可维护性、可部署性和可演进性

5.3 架构视点选择

AD 必须选择并明确规定所使用的视点。

每个视点必须规定5项内容：

  1. 视点名称
  2. 该视点服务的利益相关者
  3. 该视点解决的关注点
  4. 构建视图所用的语言、建模技术或分析方法
  5. 库视点的来源（作者、日期、引用文档）

视点可选补充信息：

  • 一致性和完整性测试方法
  • 评估或分析技术
  • 启发式规则、模式或其他综合指南

关键要求：

  • 必须提供每个视点的选择理由
  • 理由必须说明视点如何覆盖 5.2 要求的利益相关者和关注点
  • 每个利益相关者和每个关注点必须至少被一个视点覆盖
  • 标准不强制要求使用任何特定视点

5.4 架构视图

AD 必须包含一个或多个架构视图。

视图规则：

  • 每个视图精确对应一个视点
  • 每个视图必须符合其对应视点的规范
  • 每个视图包含：标识符和介绍信息、系统表示、配置信息
  • 一个视图可由一个或多个架构模型组成

5.5 视图间一致性

  • 必须记录视图间所有已知的不一致
  • 应该包含跨所有视图的一致性分析

5.6 架构基本原理（Rationale）

  • 必须包含所选架构概念的理由
  • 应该提供对备选架构概念的考虑以及做出选择的理由
  • 对于遗留系统的 AD，如果已知，应呈现其架构的历史理由

五、视点深度解析

视点的本质

视点是可复用的视图模板。它独立于具体系统，定义了：

  • 针对什么关注点
  • 服务哪些利益相关者
  • 使用什么建模语言和方法
  • 如何分析和验证

视点库（Library Viewpoint）

在别处定义、可被多个 AD 复用的视点称为”库视点”。标准预期各领域将形成自己的视点库：

  • 领域特定的架构框架可通过规定一组视点来实现
  • 例如 RM-ODP 的5个视点、Zachman 框架、Bass/Clements/Kazman 的视图法

典型视点示例（附录C）

结构视点（Structural Viewpoint）

最常用的软件架构视点，源自 Perry & Wolf (1992) 和 Shaw & Garlan (1996) 的经典工作。

关注点：

  • 系统的计算元素及其组织
  • 组成系统的软件元素
  • 它们的接口
  • 它们如何互连
  • 互连机制

建模语言：

  • 组件（计算单元）及其端口（接口）
  • 连接器（组件间通信与协调）及其角色（连接位置）
  • 组件和连接器可被类型化

分析方法：

  • 接口兼容性检查
  • 依赖分析
  • 系统结构一致性验证

六、标准的意义与影响

理论贡献

  1. 首次统一术语：在混乱的架构术语中建立了共识基础
  2. 视图-视点分离：明确了”视图是实例、视点是模板”的关系，为架构框架的标准化提供了机制
  3. 架构≠架构描述：区分了概念性的架构和具体的描述制品
  4. 多视图方法论：将多视图从实践经验提升为标准规范
  5. 视点可复用：通过视点库机制支持领域特定架构框架

实践价值

  • 为架构师提供了描述架构的规范模板
  • 为组织建立架构评审和质量保证提供了标准依据
  • 为工具开发商提供了功能需求参考框架
  • 为不同方法和框架之间的沟通提供了共同语言

历史地位

IEEE 1471 是软件架构领域的里程碑标准，直接影响了：

  • ISO/IEC 42010（国际标准版本）
  • TOGAF（The Open Group Architecture Framework）
  • DoDAF（美国国防部架构框架）
  • RM-ODP（开放分布式处理参考模型）
  • 各类企业架构框架和方法论

七、与其他知识的关联

关系图谱