一、概念基础
概念基础包括：1、架构说明的概念模型；
2、架构在生命周期中的角色；
3、架构说明的使用；
4、架构框架和架构说明语言
上图是，系统说明的上下文
一个系统位于一个环境中。环境决定了整个生命周期中施加于系统的所有影响，包括系统在
环境中，与环境的交互。一个系统的环境中可以包含其他系统。
系统的架构包含与其环境相关的系统基本要素。单一的特征刻画不能定义系统的本质的或基
础；系统的特征可能与以下部分或全体相关：
–
系统组成或元素；
–
系统元素如何安置或相互关联；
–
系统组织或设计的原则；以及，
–
管控系统在其生命周期中演进的原则。
同一系统可以通过几种不同的架构来理解（例如，在不同环境中进行考虑时）。一
个架构可以通过几种不同的架构说明来表达（例如，当采用不同的架构框架时）。相同的架
构可以表征多个系统（例如，公用一个共同架构的系统系列）。
1.1架构说明
架构说明是构造系统和软件架构时输出的工作产品。
架构说明包含以下内容，将在本条款的其余部分进行说明。
– 架构说明的标识和概述信息
；
– 系统干系人及其关注点的标识
；
– 在架构说明中使用的每个架构视点的定义
；
– 应用每个架构视点得到的对应的架构视图和架构模型
；
– 可用的
AD
对应关系规则、
AD
对应关系以及对已知的、与架构说明所需内容不一致的
记录
；
– 架构决策所依据的基本原理
。
ISO 42010 标准将系统架构
(
architecture of a system
)
与
架构说明
(
architecture description)
区分开来。架构说明，而不是架构，是ISO 42010 标准的主题。架构说明是一种工作产品，而架
构是抽象的，由概念和属性组成。ISO 42010 标准指明了架构说明的需求。ISO 42010 标准中没有关于架构、系统或其环境的需求。
架构说明的方法，包括以文档为中心的、基于模型的和基于存储库的技术。
一个架构说明应标识利益系统，以及包括项目和/或组织决定的附加信息。 细节内容的标识和附加信息条目应由项目和/或组织指明。
1.1.1 干系人与关注点
系统的干系人关注于与其环境相关的利益系统。一个关注点可以有一个或多个干系人关注。
从系统需要和需求、设计选择以及实现和操作考虑，整个生命周期都会引发关注点。
关注点可以以多种形式表现出来，诸如与一个或多个干系人需求、目标、期望、责任、要求、 设计约束、假设、依赖关系、质量属性、架构决策、风险或与系统相关的其他问题。
一个架构说明应识别与利益系统架构的基础性关注点相关的系统干系人。
在架构说明中，应考虑并在适用时识别以下干系人：
– 系统的用户；
– 系统的操作员；
– 系统的接收者；
– 系统的拥有者；
– 系统的供应方；
– 系统的开发者；
– 系统的构建者；
– 系统的维护者。
架构说明应识别利益系统架构的基础性关注点。
架构说明应考虑并在适用时识别以下关注点：
– 系统的目标；
– 架构在达成系统目标上的适合性；
– 构建和部署系统的可行性；
– 系统在其生命周期中对其干系人的潜在风险和影响；
– 系统的可维护性和演进性。
一个架构说明应将每个识别的关注点和识别的包含该关注点的干系人关联起来。
1.1.2 架构视图和视点
架构说明包括一个或多个架构视图。架构视图（或简称视图 view）致力于系统干系人所持的一个或多个关注点。
架构视图根据架构视点（或简称为视点
viewpoint
）表述利益系统的架构。与视点有两个相
关方面：它为干系人构成的关注点以及建立视图的约定。 架构视点构成
(frame)
1
一个或多个关注点。一个关注点可以由多个视点构成。 一个视图受其视点管控
(governed)
：视点确立了构建、解释和分析视点的约定，以关注于该 视点所形成的关注点。视点协议可以包括语言、符号系统、模型种类、设计规则和/
或建模方法、分析技术和视图上的其他操作。
架构说明中，与每个使用的架构视点都应有一个确切的架构视图与其对应。每个架构视图应 遵从其管控架构视点的协定。
每个架构视图应包含：
a) 组织和
/
或项目指定的识别和附加信息；
b) 其管控视点的标识；
c) 描述其管理视点构架的所有关注点、并覆盖来自该视点的整个系统的架构模型；
d) 与其管控视点对应的视图内所有已知问题的记录。
一个架构视点应指明：
a)
该视点构造的一个或多个关注点
；
b)
对应该视点构建的关注点的典型干系人
；
c)
一个或多个该视点使用的模型种类；
d)
对每个
c)
中标识的模型种类，该类型的模型使用的语言、符号系统、协议、建模技术、
分析方法和
/
或其他操作；
e)
该视点来源的引用处。
1.1.3架构模型
架构视图由一个或多个架构模型组成。架构模型采用适合要解决的问题的建模约定。这些约
定由管理该模型的
模型种类
(
model kind
)
指定。在架构说明中，一个架构模型可以是多个架构视图的一部分。
每个架构模型应包括由组织和/
或项目指定的版本标识。
每个架构模型应识别其管理模型种类并遵从该模型种类的协议
。
一个架构模型可能是超过一个架构视图的组成部分。
1.1.4 架构关联
架构说明应记录所有已知的架构模型和视图中的不一致。
架构说明应包含其架构模型和视图的一致性分析。
对应关系和对应关系规则，可能用于表达、记录、强化和分析架构说明内模型、视图和其他 AD 元素之间的一致性。
对应关系：架构说明中的每个对应关系都应被识别，同时识别它们参与的 AD 元素。 AD 元素可能是任何构件的实例（干系人、系统关注点、架构视点、架构视图, 模型种类、架构模型、架构决策和基本原理）。在定义视点和模型类型时，可能会引入其他的附加类别的 AD 元素。
架构说明中的每个对应关系应识别所有对它进行管控的对应关系规则。
一个架构说明应包含它所使用的每个对应关系规则。
对每个已识别的对应关系规则，架构说明应记录是否遵守了规则，或记录所有已知的违例情况。当一个对应关系能够显示出它满足了对应关系规则，则是遵守(hold)了对应关系规则。如果一个对应关系显示出它不满足对应关系规则，或者没有对应关系规则，存在则是规则被违反(violated)。
1.1.4.1AD元素与对应关系
AD 元素是架构说明中的任一构件。
AD
元素是本国际标准中讨论的最原始的构件。每个干
系人、关注点、架构视点、架构视图、模型类别、架构模型，架构决策和基本原理（见
4.2.7
）
都可被视为
AD
元素。在定义视点和模型类型时，以及用它们来组装模型时，会引入更多的
AD
元素。
对应关系(
correspondence
)
定义了
AD
元素之间的关系。对应关系用于表示架构说明（或
架构说明之间）中的利益方面的架构关系。对应关系可以通过
对应关系规则
(
correspondence rules
)
来管控。对应关系规则用于在架构说明（或架构说明之间）实施关
系。
1.1.5 架构决策和基本原理
架构基本原理记录了对已做出的架构决策的解释、理由或推理。决策的基本原理可包括决策
的依据、已考虑的备选方案和权衡、决策的潜在后果，以及对附加信息来源的引用。
决策与系统关注点相关；但是两者之间通常没有简单的映射。一项决策可以通过多种方式影
响架构。在架构说明中可以呈现如下：
–
要求存在
AD
元素；
–
改变
AD
元素的属性；
–
触发权衡分析，在其中修订了一些
AD
要素，包括其他决定和关注点；
–
提出新的关注点。
基本原理的记录：架构说明应当包括使用架构视点而包含的每个架构视点的基本原理，基本原理使用干系人、关注点、模型类型、符号系统和方法等方面的信息来说明。
架构说明应包含每个关键架构决策的原理陈述。
架构说明应提供证据说明如何考虑其他替代方案和以及做出选择的原理陈述。
决策的记录：架构说明应当记录被认为对利益系统架构关键的架构决策。记录系统中每个架构决策并不现实。组织和/或项目应当应用决策记录和共享的策略，来建立在架构说明的原理陈述中记录和支持的关键决策的选择标准。可以考虑的标准包括：
– 架构性重大需求的决策；
– 需要主要的资本投入或时间去创建、实施或执行的决策；
– 影响关键干系人或许多干系人的决策；
– 天然较复杂、或原因非显而易见的推理的决策；
– 对变更敏感较高的决策；
– 变更成本高的决策；
– 构成项目计划和管理基础的决策(例如，工作分解结构的创建，质量关的跟踪；
– 导致主要的支出或间接成本的决策。
当记录决策时，需要考虑以下内容：
– 决策是唯一标识的；
– 决策被陈述；
– 决策关联到其所属的系统关注点；
– 识别决策的拥有者；
– 决策关联到受其影响的
AD
元素；
– 有依据
基本原理的记录 中
关于决策的原理陈述；
– 识别影响决策的约束和假设；
– 记录所考虑的备选方案及其潜在后果；
– 记录决策(关联到其他决策)的结果；
– 记录做出决策，批准决策和变更决策的时间点；
– 提供附加信息来源的引用。
1.2 生命周期中的架构构建
架构构建(Architecting)贡献于系统的开发、操作和维护，从最初概念到退出使用及处置。
架构构建发生在项目和/或组织的环境中。架构构建在整个系统生命周期中执行，而不仅仅是在生命周期的一个阶段内。因此，系统的架构潜在影响整个系统生命周期中的过程。
架构说明是在利益系统的生命周期内执行架构活动而产生的工作产品。生命周期规定了生成符合标准的架构说明内容的阶段和方式。即使架构说明是由单个生命周期活动产生的，其内容也可能是多个活动的结果。或者，可以通过聚合来自生命周期活动开发的其他工作产品的信息来产生架构说明。
1.3 架构说明的使用
在整个系统生命周期中，架构说明可供各种干系人使用。架构说明的用途包括但不限于：
–
作为系统设计和开发活动的依据；
–
作为分析和评估架构的备选实现方案的依据；
–
作为开发和维护文档；
–
记录系统的基础方面，例如： ○ 预期用途和环境； ○ 指导未来变化的原则，假设和约束； ○ 系统在未来变化方面的灵活性或局限性； ○ 架构决策、基本原理和暗示；
–
作为用于仿真、系统生成和分析的自动化工具的输入；
–
指明具有一组共同特征的系统（例如架构风格，参考架构和产品线架构）；
–
用与系统开发、生产、部署、运行和维护的各方之间的沟通；
–
作为验收准备文件的依据（如征求建议书和工作说明书）；
–
作为合同谈判的一部分，与客户、需求方、供给方和开发方之间进行沟通；
–
为潜在客户、需求方、拥有者、操作者和集成者编档系统的特征、特性和设计；
–
从遗留架构过渡到新架构的规划；
–
作为运营和基础设施支持和配置管理的指南
;
–
支持系统规划，进度和预算编制活动
;
–
建立标准，用于保证实现方式遵从了架构；
–
作为外部和项目和
/
或组织内部政策的合规机制（例如，立法，构建架构原则）；
–
作为系统在整个生命周期内进行审查，分析和评估的依据；
– 作为分析和评估备选架构的依据；
– 通过视点、模式和风格分享经验教训并复用架构知识；
– 对干系人和其他各方，在架构构建和系统演进的最佳实践的方面进行培训和教育。
1.4 架构框架和架构说明语言
架构框架和架构说明语言（ADL）是架构构建中得到广泛使用的两种机制。架构框架和架构说明语言是在本国际标准中建立的架构说明的概念基础上来指明的。
架构框架建立了在特定应用程序领域或干系人团体中创建、解释、分析和使用架构说明的通用实践。
架构框架的使用包括但不限于：
1、创建架构说明；
2、开发架构建模工具和架构方法；
3、还有建立过程以促进跨多个项目和/或组织的沟通、承诺和协作。
架构框架的概念模型
架构说明语言（ADL
）是用于架构说明的任何形式的表达。
ADL 提供一个或多个模型种类，作为构造干系人受众关注点的方法。
ADL
可以是较窄地聚
焦，定义单一的模型种类，或者在较广范围内提供几种模型种类，选择性地组织为视点。通
常，
ADL
由自动化工具提供支持，以帮助其创建、使用和分析模型
一个架构框架应包括：
a) 标识架构框架的信息；
b) 识别一个或多个关注点
；
c) 包含以上关注点的一个或多个干系人的识别
；
d) 构造以上关注点的一个或多个架构视点
；
e) 所有对应规则
。
一个架构框架应包含适用性的条件。
【例】以下是一些适用性条件：
–
使用架构框架
AF1
的架构说明，需要在利益系统在其管辖权限
J
内运行时，识别干系人
A, M
和
P
；
–
使用架构框架
AF2
的架构说明，允许在没有实时系统关注点时省略视点
V1
；
–
使用架构框架
AF3
时，视点
V2
可以省略模型类型
MK
，除非
S
是识别到的干系人。
1.4.1 架构说明遵从于架构框架
架构说明在以下情形下遵从于架构框架：
–
架构说明中已考虑和识别架构框架中识别的每个可应用的干系人
；
–
架构说明中已考虑和识别架构框架中识别的每个可应用的关注点
；
–
架构说明包含(通过
5.4
) 架构框架中指定的每个可应用的视点
；
–
架构说明包含架构框架中指定的每个可用的对应规则
；并且，
–
架构说明遵循条款
5
的要求。
可应用
(
Applicable
)
意味着满足了适用性条件。
架构框架可以建立附加的遵从规则。
1.4.2 架构描述语言
一个架构说明语言应指明：
a)
识别一个或多个
ADL
表示的关注点的识别
；
b)
识别包含以上关注点的一个或多个干系人的识别物
；
c)
为构造以上关注点，由
ADL
实现的模型种类
；
d)
所有架构视点
；
【注】
ADL
不需要提供任何架构视点；它可以定义一个或多个在他处定义的架构视点中使
用的模型类型。
e)
通过
c)
的模型种类的对应规则
