IEEE 1471（ISO/IEC/IEEE 42010）架构描述方法

关于

本文对软件体系架构的描述方法的研究基于 ISO/IEC/IEEE 42010. ISO/IEC/IEEE 42010 于 2011 年批准使用并发布，该标准是继 2006 年 ISO 快速采用 IEEE 标准后，ISO 和 IEEE 联合制定的修订 IEEE Std 1471:2000 的产物。

本文绝大多数内容通过 DeepL 翻译 ISO/IEC/IEEE 42010 原文得来。

本文系软件体系架构与设计模式课程中一项作业。

背景

由程序员编写的各类系统的复杂性已达到前所未有的程度，在为创建并使用系统的组织带来新的机会的同时，也带来了由系统庞大引起的挑战性。因此，架构的概念和原则被越来越多地应用，帮助利益相关者应对系统的复杂性变化。下图描绘了与系统及其架构有关的关键概念，帮助理解架构描述实践的背景。

其中，“系统（System）”指其结构受到关注的实体，在软件开发过程中，可以认为是“软件密集型系统”：任何软件对其设计、构造、部署和演变有重要影响的系统，包括单个应用程序、传统意义上的系统、子系统、系统的系统、产品线、产品系列、整个企业和其他利益的集合。

“利益相关者（Stakeholder）”是指在系统中拥有利益的各方。利益相关者的利益表现为“系统关注点”（System Concern）。利益相关者赋予系统各种目的（Purpose），目的是系统关注点的一种。

“环境（Environment）”决定了系统在其整个生命周期中受到的全部影响，包括与环境的相互作用。一个系统处在一个环境中，一个环境可以包含多个系统。

“架构（Architecture）”构成了系统与其环境相关的基本内容，可能涉及到如下几点：系统的构成要素或元素；系统要素如何安排或相互关联；系统的组织或设计原则；系统在其生命周期中的演变原则。

“架构描述（Architecture Description）”用于表达有关系统架构的内容。下面对架构描述的方法进行详尽的阐述与分析。

架构描述

架构描述是系统和软件体系架构的工作成果。下图是在应用此国际标准编制架构描述时，用于描述一个“利益系统（System of Interest，或简称系统）”的一个架构的概念模型。

利益相关者和关注点

一个系统的利益相关者对系统和与其有关的问题进行关注。一个关注点可能由一个或多个利益相关者持有。在整个生命周期中，对系统的需求和要求以及实施和运行的考虑等都可能成为关注点。关注点可以通过多种形式表现出来，例如与一个或多个利益相关者的需求、目标、期望、责任、要求、设计约束、假设、依赖性、质量属性、架构决策、风险或其他与系统有关的问题有关。

架构描述应确定系统利益相关者，这些利益相关者的关切被认为对相关系统的架构至关重要。架构描述中应考虑并在适用时确定以下利益相关者：

1. 系统的用户；
2. 系统的操作者；
3. 系统的获取者；
4. 系统的所有者；
5. 系统的供应商；
6. 系统的开发者；
7. 系统的建设者；
8. 系统的维护者。

体系结构说明应确定被认为对有关系统的体系结构至关重要的关注点。架构描述中应考虑并在适用的情况下确定以下关注点：

1. 系统的目的。
2. 体系结构对实现系统目的的适用性。
3. 构建和部署系统的可行性。
4. 系统在整个生命周期内对利益相关者的潜在风险和影响。
5. 系统的可维护性和可演变性。

架构描述应将每一个确定的关注点与具有该关注点的利益相关者联系起来。一般来说，关注点与利益相关者的关联是多对多的。

架构视图和架构观点

架构描述包括一个或多个“架构视图（Architecture View，或简称视图）”。视图涉及系统利益相关者所关注的一个或多个问题。

架构视图按照“架构观点（Architecture Viewpoint，或简称观点）”来描述系统的架构。观点包括两个方面的内容：为利益相关者框定的关注点和基于视图建立的规范。

一个观点框定了一个或多个关注点。一个关注点可以由一个以上的观点来框定。

视图受其观点的制约：观点确立了构建、解释和分析视图的规范，以解决该视图框定的关注点。观点规范可以包括语言、符号、模型种类、设计规则，以及（或是）建模方法、分析技术和其他对视图的操作。

架构描述应包括其中使用的每个架构观点，确定的每一个关注点应至少由一个架构观点所构成。架构观点应规定：

1. 架构观点所涉及的一个或多个关注点；
2. 架构观点所框定的关注点的关键利益相关者；
3. 架构观点中使用的一个或多个模型种类。

架构描述应包含每个使用的架构观点的架构视图，架构视图应遵守对应架构视图的规范。架构视图应包括以下内容：

1. 组织和（或）项目规定的标识和补充信息。
2. 架构观点的标识。
3. 解决架构观点所提出的所有问题的架构模型，并从该观点出发覆盖整个系统。
4. 与架构观点相关的任何已知问题的记录。

架构描述可以包括不与架构视图相关的信息。

架构模型

架构视图由一个或多个“架构模型（Architecture Model）”组成。架构模型使用规定好的建模规范，这些规范由管理该模型的模型种类指定。在一个架构描述中，一个架构模型可以是一个或以上架构视图的一部分。
每个架构模型应包括：

1. 组织和（或）项目指定的版本标识；
2. 所管理模型的种类标识。

架构描述应记录其架构模型和架构视图中任何已知的不一致之处。

架构描述应包括对其架构模型和架构视图的一致性分析。

架构关系

“AD 元素（AD Element）”是架构描述中的任何构造。AD元素是此国际标准中讨论的最原始的构造。每一个利益相关者、关注点、架构观点、架构视图、模型种类、架构模型、架构决策和理由都被视为一个AD元素。当架构观点和模型种类被定义且其模型被填充时，就会引入额外的AD元素。

“对应关系（Correspondence）”定义了AD元素之间的关系。对应关系用于表达架构描述中（或之间）的利益相关的架构关系。对应关系可以由“对应规则（Correspondence Rule）”来管理。对应规则用于强制执行架构描述中（或之间）的关系。三者之间的关系如下图所示。

架构描述中的每一种对应关系都应被识别，并确定其参与的AD元素。

架构描述中的每个对应关系都应标识管辖它的所有对应规则。

架构描述应包括适用于它的所有对应规则。

对于每个已识别的对应规则，架构描述应记录该规则是否成立，或以其他方式记录所有已知的违反规则的情况。如果一个关联的对应关系可以被证明满足该规则，则对应关系规则成立。如果相关的对应关系可以被证明不满足规则，或者不存在相关的对应关系，则违反对应规则。

架构原理

“架构原理（Architecture Rationale，或简称原理）”记录了对已作出的架构决定的解释、说明或推理。一项原理可以包括决定的依据、考虑过的替代方案和权衡、决定的潜在后果以及对其他信息来源的引用。

决策与系统关注点有关；然而，两者之间往往没有简单的映射。一个决策可能以多种方式影响架构。如下图所示，这些影响可能反映在架构描述中，具体包括：

• 要求AD元素的存在；
• 改变AD元素的属性；
• 进行权衡分析，其中一些AD元素，包括其他的决策和关注点都会被修改；
• 提出新的关注点。

架构描述应包括使用的每个架构观点的原理，包括利益相关者、关注点、模型种类、符号和方法。

架构描述应包括每个被认为是关键架构决策的原理。

架构描述应提供考虑备选方案的证据和做出选择的原理。

架构描述应记录被认为是相关系统架构的关键的架构决策。

记录系统的每一项架构决定是不切实际的。组织和（或）项目应采用决策记录和共享策略，以建立选择关键决策的标准，并在架构描述中记录和支持这些决策的原理。需要考虑的标准有：

1. 有关架构上重要需求的决策；
2. 需要投入大量精力或时间来制定、实施或执行的决策；
3. 影响关键利益相关者或若干利益相关者的决策；
4. 需要进行复杂或不明显推理的决策；
5. 对变化高度敏感的决策；
6. 可能需要付出高昂代价才能改变的决策；
7. 构成项目规划和管理基础的决策（如工作分解结构的建立、质量跟踪等）；
8. 导致资本支出或间接成本的决策。

在记录决策时，还应考虑以下几点：

1. 决策是唯一确定的；
2. 该决策得到说明；
3. 决策与其所涉及的系统问题相关联；
4. 决策的所有者被确定；
5. 该决策与受该决策影响的AD要素有关；
6. 有与决策相关的架构原理；
7. 确定影响决策的制约因素和假设；
8. 记录已经考虑过的备选方案及其潜在后果；
9. 记录该决策的后果（与其他决策有关）；
10. 记录作出、批准和改变决策的时间戳；
11. 提供补充资料来源的引文。