2023系统与软件工程架构描述

系统与软件工程架构描述目 次范围 1规范性引用文件 1术语、定义和缩略语 1术语和定义 1缩略语 4符合性 5基本概念 5概述 5架构描述的概念模型 5生存周期中的架构描述 12架构描述框架与语言 13架构描述的规格说明 16架构描述识别与概述 16利益相关方的识别 17利益相关方角度的识别 17关注点的识别 17方面的识别 17架构视角的包含内容 18架构视图的包含内容 18视图组件的包含内容 18架构对应的记录 19架构决策和理据的记录 19架构描述框架与架构描述语言 21架构描述框架规格说明 21架构描述语言规格说明 22架构视角和模型种类 22架构视角规格说明 22模型种类规格说明 23视图方法 23附录A（资料性）术语和概念注解 24附录B（资料性）架构视角规格说明指南 33附录C（资料性）与其他标准的关系 36附录D（资料性）架构描述的使用 42I附录E（资料性）架构与架构描述生存周期 43附录F（资料性）架构描述框架 45附录NA（资料性）本文件应用案例一 48附录NB（资料性）本文件应用案例二 59II引 言（包括软件系统（作为数据项或数据结构（作为一个集合AD注：ISO/IEC/IEEE42020规定了架构化的一组过程，用于支持创建一个或多个AD。ISO/IEC/IEEE42020中的架构细化过程与AD的创建紧密相关。AD是有形的工作产品，而架构是无形、抽象的，是通过其概念、属性和原则来理解的。用于编写AD用于编写不同群体和应用域中的AD。AD本文件提供了ADADADADF和ADL内容的通用本体，提供了考虑和比较ADF和ADL的基础。本文件适用于在EoI或其架构的周境中为组织内的AD、ADF和ADL开发建立连贯的架构化实践。本文件的条款适用于评估AD、ADF、ADL、视角和模型种类的规格说明的符合性。本文件旨在提供一套描述架构的连贯一致的方法，包括以文档为中心和基于模型的技术。本文件还给出了在如指南和标准等其他文档中使用架构相关术语和概念的动机。建议本文件用户查阅第5章，了解基本概念以及与AD工作产品相关的概念和原则。本文件未表明ADAD的完整性和正确性进行局部检ADADAD中表现为元素的规格说明对于规格说明主题而言是预期完整、精确及可验证的。IV系统与软件工程架构描述范围本文件规定了对各种实体的架构描述（AD）的结构和表达要求，各种实体包括软件、系统、企业、系统之系统、系统族、产品（货物或服务）、产品线、服务线、技术和业务域。本文件界定了所关注实体（EoI）的架构和表达架构的AD。本文件的主题不是架构。本文件规定了对在ADEoI或其环境的要求。效支持AD的开发和使用。本文件规定了对AD、ADF、ADL、架构视角和模型种类的符合性要求。本文件未规定创建、利用或管理AD的过程、架构化方法、模型、符号、技术或工具。本文件未规定记录AD的任何格式或介质。本文件适用于：帮助理解各种实体的涉及其结构、行为、设计和演变的基本概念或属性；EoIAD、ADFADLAD、ADF、ADL、架构视角和模型种类的规格说明的符合性。规范性引用文件本文件没有规范性引用文件。术语、定义和缩略语术语和定义下列术语和定义适用于本文件。3.1.1架构化architecting在所关注实体（3.12）的整个生存周期中，对一个架构（3.2）进行构想、定义、表达、记录、沟通、证明其正确实施、维护和改进。3.1.2架构architecture[来源：ISO/IEC/IEEE42020:2019，3.3，有修改。]3.1.3架构描述architecturedescription；AD用于表达架构（3.2）的工作产品。1注1：工作产品是由过程产生的人工制品（见ISO/IEC20246：2017，3.18）。注2：AD是提供给利益相关方（3.17）的信息的有形表示。AD认为是一个信息部件（3.14）。3.1.4架构描述元素architecturedescriptionelementAD元素ADelement架构描述（3.3）的已识别或已命名部分。注：AA331313139；所使用的ADL（3.6）、ADF（3.5）和对应（3.11）及对应方法；以及AD（3.3）所包含的架构视图（3.7）、视图组件（3.19）、架构视角（3.8）和模型种类（3.15）。注2：就对应（3.11）的而言，一个AD（3.3）能认为是另一个AD中的AD元素。3.1.5架构描述框架architecturedescriptionframework；ADF在特定的应用域或利益相关方（3.17）群体中建立的架构（3.2）描述的约定、原则和实践。示例：通用企业参考架构建模框架（GERAM）（ISO15704:2019附录B），开放分布式处理参考模型（RM-ODP），统一架构框架（UAF），以及北约架构框架（NAF）。注：架构描述框架促进架构视图（3.7）和模型的组织结构化、描述的一致性、更大的重用潜力以及完整性。3.1.6架构描述语言architecturedescriptionlanguage；ADL具有语法和语义的表达方式，由一组用于描述架构（3.2）的表示、约定和相关规则组成。示例：架构分析和设计语言（AADL）、ArchiMate、UML、SysML、UAF概要文件。3.1.7架构视图architectureview组成架构描述（3.3）的一部分的信息部件（3.14）。示例：信息或数据视图处理由信息视角构造的信息相关的关注点。它包含如视图组件（3.19）、概念数据模型、数据管理模型和数据访问模型，以及将这些组件连接在一起的对应。3.1.8架构视角architectureviewpoint用于创建、解读和使用架构视图（3.7）的一组约定，以构造一个或多个关注点（3.10）。注1：在本文件中，“构造”关注点意为“塑造、组成、表达”这些关注点。它用于区分由视角构造关注点的阶段和在结果视图中处理这些关注点的阶段。这类似于“构造问题”和“解决问题”之间的区别。注2：视角是架构师决定的与架构描述（3.3）的目的相关的关注点的参考框架。注3：架构视角的约定记录在这个视角的规格说明（3.16）中。在一些群体和架构框架中，“视图规格说明”被用来表示相同的东西。注4：视角的识别通常是该视角所适用域的先验知识、经验和实际运用的结果，表明与解决关注点（3.10）相关的信息。3.1.9方面aspect2实体特征或本质的一部分。示例：实体的功能、结构和信息方面。注1：一个特定的方面能用于捕获所关注实体（3.12）的相关特征，作为一个或多个关注点（3.10）的细化，该关注点关于其特征的某些部分，例如实体的结构特征、功能特征或信息特征。注2：方面帮助架构师分析、处理和结构化关注点（3.10）。一般来说，方面和关注点（3.10）之间存在多对多的关系。注3：更多论证和示例见5.2.5。3.1.10关注点concern与利益相关方（3.17）有关的或重要的事项。注1：能针对所关注实体（3.12）识别，或独立地识别关注点，例如针对该实体的环境、场景、情况或用例。注2：在本文件中，对实体的关注意在涵盖对该实体的环境（3.13）、生存周期、架构（3.2）、需求、设计、实施和运营的关注。这些关注通过方面（3.9）、关注点和利益相关方角度（3.18）来捕获。注3：关注点的识别通常是该关注点所适用域的先验知识、经验和实际运用的结果。注4：更多论述和示例见5.2.3。[来源：ISO/IEC/IEEE42020:2019，3.8，有修改。]3.1.11对应correspondence两个及以上架构描述元素（3.4）之间的已识别或命名的关系。示例：对应用于表达广泛的关系，如等价性、组合性、精化性、一致性、可追溯性、依赖性、约束性、满意度和义务。注1：为了形成对应，一个架构描述（3.3）能视为另一个架构描述（3.3）中的AD元素（3.4）。注2：中ADAD（3.4）间的关系。3.1.12所关注实体entityofinterest；Eol架构描述（3.3）的主题。示例：企业、组织、解决方案、系统（包括软件系统）、子系统、过程、业务、数据（作为数据项或数据结构）、应用、信息技术（作为集合）、任务、产品、服务、软件项、硬件项、产品线、系统族、系统之系统、系统集合、应用程序集合等。注1：在本文件中，术语“所关注实体”是指在编制架构描述（3.3）时正在考虑其架构（3.2）的实体。注2：本文件将所关注实体与非架构描述（3.3）主题的其他实体区分开来。注3：在本文件中，对一个实体的关注旨在涵盖对该实体的环境、生存周期、架构、需求、设计、实现和运营的关注。这些关注是通过各方面、关注点和利益相关方角度来捕获的。3.1.13环境environment周围事物、条件或实体所受影响的周境。注1：所关注实体（3.12）的环境包含能对某实体产生各种影响，如开发、技术、商业、运营、组织、政治、经济、法律、监管、生态和社会影响的外部实体，以及外部物理效应，如电磁辐射、带电粒子、引力效应、电场和3磁场。注2：术语“环境”加上限定词标签，识别出某一周境内的另一特定周境，如开发环境、测试环境和操作环境。3.1.14信息部件informationpart为人类和机器使用而生产、存储和交付的可单独识别的信息体。3.1.15模型种类modelkind通过关键特性和建模约定区分的模型类别。示例：功能模型、活动模型、结构模型、用例模型、地缘政治模型、分析模型和经济模型。3.1.16规格说明specification以完整、精确和可验证的方式识别实体的需求、设计、行为或其他预期特性的信息部件（3.14）。[来源：ISO/IEC/IEEE15289：2019，3.1.26，有修改。]3.1.17利益相关方stakeholder在所关注实体（3.12）中拥有利益、权利、股份或权利主张的角色、职位、个人、组织或其阶层。示例：和市场。3.1.18利益相关方角度stakeholderperspective对所关注实体（3.12）的思考方式，特别是在涉及关注点（3.10）时。示例：Zachman（NATO架构框架网格中的行对应于利益相关方角度（）5.2.4。注：影响。3.1.19视图组件viewcomponent架构视图组件architectureviewcomponent由适用模型种类（3.15）或图例支配的一个或多个架构视图（3.7）的可分离部分。示例：描述访问控制机制的架构视图组件能用在架构描述（3.3）的多个视图中，以解释实体的功能流、行为和安全特征。注：在架构描述（3.3）的周境中，图例是约定的非正式文档化形式。缩略语下列缩略语适用于本文件。AADL：架构分析和设计语言（ArchitectureAnalysisandDesignLanguage）4AD：架构描述（ArchitectureDescription）ADF：架构描述框架（ArchitectureDescriptionFramework）ADL：架构描述语言（ArchitectureDescriptionLanguage）BPMN：业务过程模型与符号（BusinessProcessModelandNotation）DoDAF：美国国防部架构框架（USDepartmentofDefenceArchitectureFramework）Eol：所关注实体（EntityofInterest）GERA：通用企业参考架构（GeneralizedEnterprise-ReferencingArchitecture）GERAM：通用企业参考架构建模框架（GeneralizedEnterprise-ReferencingArchitectureModellingFramework）NAF：北约架构框架（NATOArchitectureFramework）OMG：对象管理组（ObjectManagementGroup）OPM：对象-过程方法论（Object-ProcessMethodology）RAMI4.0：工业4.0参考架构模型（ReferenceArchitecturalModelIndustrie4.0）RM-ODP：开放分布式处理参考模型（ReferenceModelofOpenDistributedProcessing）SysML：系统建模语言（SystemsModellingLanguage）TOGAF：开放组架构框架（TheOpenGroup’sArchitectureFramework）UAF：统一架构框架（UnifiedArchitectureFramework）UML：统一建模语言（UnifiedModellingLanguage）符合性本文件的要求包含在第6、7和8章中。下列五种情形能提出符合本文件规定的声明。ADAD6ADFADF7.1ADLADL7.28.18.2本文件既不要求也不准许在提出符合性声明时使用“裁剪”。基本概念概述本章介绍以概念模型集（见5.2）来表达架构描述（AD）的基本概念，并介绍所述基本概念在AD、ADF（见5.4.2）和ADL（见5.4.3）中的应用。附录D概括了使用AD来支持的不同架构实践。本章中介绍的概念在第6章到第8章中用于表达要求。注：附录A进一步讨论了本文件中使用的术语和概念，并给出了其在历史周境中的使用实例。架构描述的概念模型架构描述的周境5术语“所关注实体（EoI）”在本文件中用于指代AD的主题。该术语旨在涵盖但不限于在下列应用领域内的、反映本文件第1章所规定预期范围的各种实体：——软件，包括软件产品和服务（见GB/T8566）；——系统，包括独一无二的系统，大规模生产的系统，定制的、自适应的系统，独立的和嵌入式系统（GB/T22032）；——企业（ISO15704），即具有使命、目标和目的，以提供产品或服务，或实现预期项目成果或业务成果的人类事业或风险企业。AD每个EoI都位于一个影响其特性和行为的环境中。贯穿EoI的整个生存周期，环境决定了对EoI的全部影响，以及EoI对该环境的全部影响，包括它与环境和其他实体的相互作用。图1描绘关于EoI及其架构的关键概念，作为理解AD的一种方式。注1：第5章其余部分的图和文字构成了一套AD1到图6件读者理解。在图中，圆角矩形表示信息对象，箭头表示对象之间的关系且沿箭头方向读取其注释。这些图说明了贯穿第5章描述的关键概念。附录A提供了完整的概念模型。注2：EoI（即已示例：EoI（通常称为“能力架构”）来表示。在这一能力定义阶段，已识别的利益相关方可能会受到未来EoI的关注架构和架构描述EoIEoI的架构能涉及该实体的下列任意部分或全部：——构成要素；——要素之间的相互作用或相互关系；——与其环境的相互作用或相互关系，包括与环境中其他实体的相互作用或相互关系；——行为和结构；——设计、使用、操作和发展的支配原则。ADAD是为进行架构化的特定目的而产生，这与EoI的目的截然不同。AD由AD元素组成（见5.2.9）。EoI的架构能通过一个或多个不同的AD来理解，每个AD都是为了与架构和利益相关方需要相关的目的而创建的。例如，不同的AD可能基于不同的利益相关方（见5.2.3）、利益相关方角度（见5.2.4）、时期（有时称为时代）或环境中的特定周境或用法。注：ISO/IEC/IEEE42020规定了一套架构化过程，能用于支持创建一个或多个AD。利益相关方和关注点6会权利、股份、影响力或主张（如基金组织、政府机构、实体所造成环境影响的接受方、受EoI影响之实体的利益相关方）。一些利益相关方的关注点与EoI的成功背道而驰。这些利益相关方能出于政治或环境考虑而有不同在EoI的生存周期中，关注点能在任何时间出现，包括（但不限于）概念化时期，设计抉择之际，从建设或实施起，贯穿部署、运营、所有权转移、退役及处置过程。关注点可能涉及对某个EoI示例：——系统是如何维护的？——哪些系统行为是安全关键的？——EoI能否符合国家法规？——运营成本是多少？——架构给出了哪些风险、机遇、满意度、弹复性、一致性、可负担性、复杂性和信任？——开放分布式处理参考模型中描述的分布透明性是什么？——如果是商用飞机的飞行导航系统，GPS信号的可用性、可跟踪性、准确性、视线接收、高度或海拔是多少？——数据质量是什么（GB/T25000.12-20174GB/T25000.10-2016——系统维护机密性、完整性和可用性以保护运行的能力是什么？——支持从传统能力向现代化作战能力无缝过渡的能力是什么？利益相关方角度基于其共同的角色、经验、信仰或其他特征，利益相关方通常形成不同的群体或利益相关方角度。角度能反映域知识、职业经验、培训或在EoI生存周期（如设计、开发、制造、供应、运营和使用）中与EoI的接近程度。重要的是，利益相关方角度也会受到个性、性格特征、文化、同行压力、支持者等因素的影响。利益相关方角度是在周境中对EoIEoI的架构有几种思考方式。AD（见示例1：工业生产系统的运行和财务角度。示例2：银行系统的业务、管理、收购和供应角度。示例3：移动应用的开发、部署和定制角度。示例4：接待服务的供方和消费者角度。示例5：内容提供实体的数据用户和数据供方角度。7方面方面捕获EoI在其环境中的一组特性或特征，用以处理AD内的关注点。（较关注点通过对方面进行检查，能够辨别或预测EoI的相关特征或属性。对方面进行分析，能发现一个或多个关注点。对方面与关注点间关系的定义以架构师的经验为基础，由利益相关方根据其理解和知识进行评估。注：A.4.2包含关于方面实用性的更多信息。示例1：飞行器AD中的空间、结构、功能、信息和路线图方面。示例2：计算机AD中的行为、信息和结构方面。示例3：通信网络AD中的连通性方面（通常表现为网络中链路和节点配置的独立逻辑网络和物理网络描绘）。图1描绘AD中所运用的关注点、方面和利益相关方角度之间的关系。图1关注点、方面和利益相关方角度架构考虑点架构考虑点是做架构化时要考虑的因素。关注点（见5.2.3）、利益相关方角度（见5.2.4）和方面（见5.2.5）是架构化时要思考的不同考虑点。其他考虑点还可能因架构使用实践而产生。架构考虑点在规定架构视角时及在构造、解释、组织或使用架构视图（见5.2.7）时是有用的。架构考虑点能对架构视角规格说明进行分组，例如就利益相关方角度。示例：架构考虑点包括：利益相关方对表达利益相关方视图所选的ADL进行解读的能力；视角与模型种类的所需形8式化程度；支撑工具的可用性；给定行业域中的标准使用实践；时间与资源的可用性；利益相关方要达到的理解深度的关键性。注：其他考虑点可能涉及周境、准则、构建块和域词汇表。架构视图和架构视角AD（可能包括非正式知识或隐性经验知识应用以确定架构是否令人满意地处理了关注点。注1：架构关注点、利益相关方角度和方面能够起到AD各视角的组织基础的作用。方面是关注点的提炼，且方面可用于确立视角约定。方面体现在由此产生的架构视图中。1：（实体AD视图）。该视图处理通信参数，如运营方和用户（利益相关方）的吞吐量和上线时间（关注点）。示例2：某部件和变体视图，描述产品线（实体），包括通用部件和单个产品及其变体和选项的内容。图2描绘AD中架构视图和架构视角之间的关系。图2架构视图和架构视角9一个架构视角构造一个或多个关注点（见5.2.3）。一个关注点能够通过多个视角构造。架构视角AD注2：与产品验收需求不同，EoI的架构视图处理关注点并反映方面，可能导致需求修改。在创建视图（见5.2.9）时，视角规格说明用元模型或其他约定来确立AD元素（例如实体、关系、属性和约束）的使用方式以及可能由视角进行转换的方式。注3：第8章规定了关于架构视角规格说明的需求。附录B提供了关于准备架构视角的指引。模型种类、图例和架构视图组件AD1：模型种类包括用例、活动模型[如结构化分析和设计技术（SADT）ICAM1）定义语言（IDEF0）]、威胁模型、组件模型和连接模型。示例2：数据流图能是功能视图的视图组件。单独的控制流图能是同一功能视图中的第二个视图组件。功能视图还能包含解释如何解读视图中的流程图的叙述。流程图是基于模型的，而叙述不是。数据流图能是信息安全视图的部分。示例3：符号体系表能是操作视图的图例。图3描绘视图组件对视图的组成以及视图组件的种类。图3视图和视图组件的概念模型架构描述（AD）元素10AD元素是在AD中一个或多个架构概念的实例。AD元素包括的实例涉及以下架构概念：利益相关方、关注点、方向、利益相关方角度、架构视角、架构视图、模型种类、图例、架构视图组件、架构决策、架构理据以及对所述构件规定的任何对应和对应方法。任一这些概念都能在一个或多个AD中具有多个实例。AD元素实例具体说明一个或多个架构概念。AD中的AD元素能参考另一AD进行细化或详述。AD能运用作为不同AD的AD元素而引入的协议。随着视角（见5.2.7）、模型种类（见5.2.8）和图例（见5.2.8）的规定和应用，附加AD元素被引入。支配地位的视角、模型种类或图例决定所引入的AD元素的语法和语义约定。示例：由视角或模型种类引入的AD元素包括：用例构件（如前置条件、行动者、边界、系统等）；活动模型构件（如活动、输入、输出、控制和机制等）；架构或要采用的设计模式。视图方法AD视图方法分为几类，包括：（如何开始、下一步该做什么）；或描述式指引（此类型视图的模板）；或启发式、风格、模式，或其他习惯用法。——解读类方法，是利益相关方和其他用户理解视图的手段。——分析类方法，用于对视图的结果进行检查、推理、转换、预测、应用和评估。注：视图方法通常在视角中定义，并被模型种类、ADF和ADL所引用或使用。示例：EoI（）EoI预期属性；针对完整性和覆盖范围的要求进行的分析；解读和整合外部模型为信息源。ADAD元素对应识别两个及以上AD元素间的已识别或命名的关系。AD元素对应能够：——将一个AD中的一个或多个AD元素与一个或多个AD元素进行关联；——将多个AD中出现的一个或多个AD元素与一个或多个AD元素进行关联；——将一个ADF或跨越几个ADF中的一个或多个AD元素与一个或多个AD元素进行关联；ADLADADADAD内部和ADADADAD元素之间的具体关系。AD元素对应和对应方法能用于表达和实施架构关系，如AD元素的组成、细化、一致性、可追溯性、依赖性、约束、满意度和义务。1：ADAD统与实现该系统的组织结构之间的对应。示例2：“自我参照”对应是细分为两个及以上同种活动的，或能自我递归调用的活动。11图4描绘AD元素对应的本质。4AD3：ADADADAD注1：对应和对应方法的使用要求在6.9中规定。附加的使用示例在A.7中给出。注2：本文件中的对应跟ISO/IEC10746-2（RM-ODP）和ISO/IEC19793中的视图对应相似。注3：对应方法通常是“跨模型”、“跨视图”或“跨AD”的，因为视图组件内的对应是模型种类规格说明的部分约定。注4：对应和对应方法能应用于多个AD元素，以表达涉及多个AD元素的架构关系。架构决策和理据AD1：架构概念选取、ADADF虑选项组合选择。架构理据记载关于架构决策的解释、理由或推理。决策的理据能包括以下事项：做出决策的基础；2：足运行周境施加的约束。示例3：选取跟有关架构（例如客户的企业架构）一致的建模工具，以确保互操作性和可追踪性。注：关于捕获AD内决策和理据的要求，在6.10中规定。生存周期中的架构描述架构化活动发生以及AD因各种理由而制作，这贯穿EoI的整个生存周期，从初始概念到该实体的运营、整顿或最后退役停用以及最终废弃。注1：由于AD描述EoI的概念，在某些情况下，只要该概念仍受关注，即使退役后AD仍在继续制作，并且能根据该组12织的政策而被搁置或舍弃。AD是由架构化所产生的工作产品，架构化发生在项目和/或组织（公司、公司网络、联盟和标准化机构）的周境中。在EoI的生存周期中，AD能领先于或跟随于架构的创建、更新或变更。注2：关于生存周期中架构化角色的更多细节，见附录E。架构描述框架与语言概述ADF和ADL目前在架构化中广泛使用，来促使AD的建造和使用人员规范化地表达架构，并确保跨AD的风格和内容覆盖的一致性。在本文件提出的AD概念上所构建的ADF和ADL能有效运用于：ADF特殊用途框架和语言，旨在实现更好的分析理解和态势感知；实体实施框架和语言，旨在促进实体的工程、运行和退役。架构描述框架ADF建立在特定关注域（如国防、航空航天和银行等）内对AD进行创建、解读、分析和使用的公共ADF还能为一个或多个专用ADF旨在（行为和适应性ADF中识别的架构视角旨在为更具体的ADFADF中识别的架构视角能从先前架构化工作所规定或使用的架构视角相关经验中产生，以确定对于EoI的关注点满意度细化到与ADF目的一致的程度。注1：ADF中做出具体的架构决策：利益相关方和相关关注点的选取、特定方面以及利益相关方角度。ADF将根据这些决策对AD进行结构化。ADF提供一种结构化形式，对通常与用于生成相关视图的架构视角相关联的AD元素进行组织。结构化形式目的是提供展现架构各种元素间关系以及增进这些元素间交互分析机会的方式。注2：最常见的结构化形式是使用架构考虑点，即关注点、利益相关方角度和方面，以网格或矩阵格式展现。示例1：知名的结构化形式包括：ISO15704中的GERAM立方体、工业4.0参考架构模型（RAMI4.0）、TOGAF阶段（业务、数据、应用和技术）、NAF网格、UAF网格和Zachman框架矩阵。图5描绘ADF的概念模型。13图5架构描述框架的概念模型ADF定义了在结构化形式中使用的结构类别。这些类别是通过对应方法形成的，这些方法将AD元素分组成有意义的配置，以便对EoI的AD进行展示、分析和管理。注3：有时候类别通过图形表示中的“维度”式通常具有两个框架维度，但是结构化形式能具有单个框架维度，通常在多层次层次结构中分段进行描述，或者具有多个框架维度，其中框架维度超过三个就比较困难。2：ZachmanUAFADFEoI注4：虽然可参考的ADFADF用作特定目的时或为了让那些发起架构化工作的利益相关方更好地理解而修改参考ADF时。由于引入特殊化AD元素，改变词汇和架构视角规格说明能成为必要。在ADF中，架构视角是开发架构视图的重要分析资源，因为视角反映架构目的、典型利益相关方及其角度、已识别的关注点、已定义的EoI方面以及特定的AD元素。ADF当用户在共同的方法论中共享典型的ADADF作为参考，其内容包含架构考虑点和利益相关方角度，以及适当的模型种类和图例。一些参考ADF包含与EoI注1：在一些领域中，相似的架构化常常会不断复现，这样可形成一个特定领域的实践群体，并形成规范：具有重复关注点的利益相关方，处理特定方面的约定，以及建立习惯角度的架构化实践。ADF在不同情况下的使用可能会识别出新的架构考虑点和有用的视角、模型种类、图例、视图和对应的新组合。在不同情况下可能会发生以下情况：——忽略生存周期或生存周期的一部分；——只包含一些利益相关方或方面；——包含重叠的方面集合；14——只包含子域或子组的方面；——随着新的关注点出现，包含新的或适应的视角；——识别以前未意识到的对应。从不同的利益相关方角度、跨越不同的EoI方面（如结构、行为和连接性）来审视利益相关方关注点，通常更易于理解。（实体的哪些能力正在被创建注2：ADF通常涵盖对AD的规定和额外的架构化实践。注3：7.1中规定ADF的要求。注4：附录F提供关于ADF的信息以及如何将其与本文件的概念和要求进行关联。注5：ADF识别一个或多个AD元素，这些元素是架构构件（如利益相关方、关注点、利益相关方角度、方面、架构视角、模型种类、图例等）的实例。一种看待ADF（或项目若以通用的方式描述ADF，则其只能用作这个信息模型的参考模型（或部分模型），需要通过添加必要的细节来定制化以满足工作的目的。相反，若ADF已经为应用域的目的进行定制化，则在利用之前需要进行的定制工作就会更少。然而，考虑到具体架构化工作的目标，特定域的ADF能进一步特殊化。例如，从这些目标的视角来看，某些视角、方面或角度可不相关，或者反过来，可存在特定于具体工作并且为此应处理的关注点，这需要规定和使用附加的视角。这种从通用到引用（或部分引用）、以及特定模型的连续性是在ISO15704中表达的相同概念的一种应用（有关详细信息，见C.4）。架构描述语言ADL是一种特定的语法和语义，用于描述EoI的架构。ADL是一种面向利益相关方，包括从事架构化EoI和架构化周境的ADAD能使用多个1：UMLAD（类、属性、操作和活动具有针对特定域例如航空航天、医疗保健、金融）或平台（J2EENET）的共同定制的此类扩展的概要文件集合，并UMLSysML39470-2020）AD能采用（或设计）各种ADL来表达架构师需要解决的特定架构的考虑点。注1：在一个AD中使用多个ADL需要非常小心，以避免混淆和误解。ADL提供一种创建和理解组成架构视图的视图组件的方法。通过考虑规定信息如何在架构视图中选择、转换和呈现的视图方法来选择适当的ADL。视图方法决定在构建AD时要收集的信息，用于分析收集到的描述的信息，以及描述架构概念和特征所需的信息。ADL能为AD的开发提供必要的严谨性。ADL的语义能通过以下方式以逐渐增强的形式和表达能力来进行规范化：使用自然语言的词汇表或术语表，术语和关系的分类体系，表达语言结构使用的元模型，作为本体理论使用形式逻辑中的公理，或者作为分析理论使用微分方程、张量计算等。15当从相当通用的参考ADF通过域特定ADF和实践特定ADF过渡到实施ADF时，可能会使用不同的ADL来满足架构视角和架构视图的更细化规格说明。2：ZachmanUAF（ICT）ADLUAFSysMLUAFUAFADL，用于UML由于多个AD是为相同域EoI创建的，因此保持它们之间的一致性或至少可追溯性非常重要；因此，（见（见A.6关于投影和综合视图创建方法来捕获一致性条件。实践中使用的真正ADL构件是这个集成本体的子集。3：ADAciaSsIO140BMUL、统一架构框架（UAF）概要文件、RM-ODP注2：ADL识别一个或多个AD元素，这些元素是架构构件（利益相关方、关注点、架构视角、模型种类、图例等）的实例。图6给出ADL的概念模型。注3：7.2中规定对ADL的要求。图6架构描述语言的概念模型架构描述的规格说明架构描述识别与概述AD应识别EoI以及该EoI的预期环境。AD应包含其预期目的的声明。AD应包含项目和/或组织确定的识别信息和补充信息。示例：ISO/IEC/IEEE15289ISO/IECTS33060。注1：对于旨在作为其他AD参考的AD，EoI是抽象的，或是EoI的通用化，该AD目的是表达一种参考架构，可能为更多AD提供基础。注2：本文件不规定AD的格式。注3：本文件不规定如何创建AD。例如，它们能单独构建、使用自动化工具生成、从其他信息源和模型派生或基于16其构建。注4：本文件不规定在AD中使用形式化建模方法的范围或预期。虽然非形式化方法能有效地使用，但形式化建模方法通常不那么模棱两可。利益相关方的识别AD应识别所持关注点认为是EoI架构的基础并且与AD目的一致的利益相关方。示例：监管机构（包括政府）、测试方、普通公众、对手和竞争对手。AD宜识别架构对当前和未来利益相关方的潜在影响。应考虑对架构及相关架构的先前评估中提出的建议。ADAD处理已识别的利益相关方和架构考虑点，即关注点、角度和方面。应识别不符合项，并解释产生的原因。利益相关方角度的识别AD应识别认为与EoI架构相关并且与AD目的一致的利益相关方角度。AD应将每个已识别角度与持有该角度的已识别利益相关方进行关联。在AD的预期目的范围内，架构化工作宜识别可与EoI相关的当前或未来的利益相关方角度。对于每个已识别的角度，AD应从已识别的关注点（见6.4）中列举该角度产生的关注点。示例：利益相关方角度包括：战略角度、组织角度、运营角度、逻辑角度、物理角度和技术角度。注1：本文件没有规定：关注点的粒度；利益相关方角度的粒度和依赖性；利益相关方角度如何相互关联；或者利益相关方角度如何与关于一个实体的其他陈述相关联，例如利益相关方的需要、实体的目标或者实体的需求。这些问题是特定AD、ADF、架构化方法或其他实践的主题。注2：有关ADF中使用的利益相关方角度示例，见附录F。关注点的识别AD应识别认为与EoI架构相关并且与AD目的一致的关注点。示例：关注点包括：架构对于实现（达到）EoI（实施）EoIEoI的可行性、EoI还原能力）（延迟）EoIEoIAD应将每个已识别的关注点与拥有该关注点的已识别的利益相关方联系起来。注1：一般来说，关注点与利益相关方的关联是多对多的。注2：应考虑与EoI相关的过去、当前或未来关注点。注3：以疑问句的形式并以AD目的的适当细节表达关注点，能使沟通更有效率和效果。方面的识别AD应识别认为与EoI架构相关并且与AD目的一致的方面。每一个被识别的方面都应与它所应用的关注点相关联。示例：方面包括结构性、行为性、功能性和程序性等方面。注：ADADFADL关使用特定方面和利益相关方角度的ADF示例，见附录F。17架构视角的包含内容AD应包含或引用其中使用的每个架构视角。每个架构视角应包含由组织和/或项目指定的版本标识。每个包含的架构视角相关的规格说明应符合第8章的规定。根据6.4识别的每个关注点应由至少一个架构视角所构造。根据6.3识别的每个利益相关方角度应与覆盖该角度的架构视角相关联。示例：功能、信息、资源和组织。注1：本文件不要求使用任何特定的架构视角。注2：附录B和C提供了关于架构视角规格说明的附加信息。注3：架构视角能作为架构师和利益相关方之间的契约。对于由架构视角所构造的关注点，架构师和利益相关方能就使用什么符号和表示约定来解决这些关注点达成一致。能在进行任何详细的架构化之前签订合同协议，以减少或避免意外。架构视图的包含内容AD应包含一个或多个架构视图，用于所使用的每个架构视角。注1：当一个视角在一个特定AD中支配多个视图时，这些视图在描述一种架构。1：每个架构视图应包含由组织和/或项目指定的版本标识。每个利益相关方角度（根据6.3由AD识别）应由至少一个视图根据该视图的支配视角进行处理。每个关注点（根据6.4由AD识别）应由至少一个视图根据该视图的支配视角进行处理。每个方面（根据6.5由AD识别）应由至少一个视图根据视图的支配视角进行处理。每一个架构视图都应遵守其支配架构视角的约定。每个架构视图可解决不止一个关注点。每个架构视图应包含或给出引用：由组织和/或项目规定的识别和补充信息；该视图的支配架构视角的标识；见6.见6.，EoI；以及视图内跟该视图支配架构视角相关的任何已知问题的记录。注2：d）要做出决策。例外和偏差能记录为决策结果和理据（见6.10）。注3：就AD的目的和范围而言，不必要求每个视图都覆盖整个EoI。例如，视图能有目的地限制在实体的某个特定范围内，有时限制方向，有时限制时间或资源，或者有时基于架构化工作的狭窄范围。AD可包含不属于任何架构视图的其他信息。2：不在任何视图内的信息部件可能有：EoIAD视图组件的包含内容架构视图应由支配架构视角相一致的一个或多个视图组件所组成。每个视图组件应包含由组织和/或项目指定的版本标识。18每个视图组件应识别其支配模型种类（若有），并且遵守其支配架构视角的约定（见6.6）。视图组件可作为多个架构视图的一部分。对应能表达跨视图共享的组件之间的关系。（即对于没有以模型来描述的信息部件该视图组件应包含一个图例来规定该视图组件所使用的约定。示例：视图组件是专家意见记录，而不是能使用计算、模拟或其他任何适用分析方法进行分析的模型。注1：架构视图间共享的视图组件使AD并降低不一致的可能性。视图组件共享也允许面向方面的AD风格：跨架构视图共享的视图组件能用来表达架注2：本文件未规定AD所用视图组件的形式化程度。基于模型的视图组件具有形式化的语义和语法规格说明，能少些歧义，同时，非基于模型的视图组件也能有效使用。架构对应的记录架构描述内的一致性AD应记录一切已知的不一致性。AD宜包含或引用针对其架构视图、其视图组件和其他AD元素的一致性分析。（如6.9.2和6.9.3所规定可用于对ADAD元素的相互一致性进行表达、记录、实施和分析。对应AD应包含或引用AD元素对应列表。AD元素对应应识别一个或多个参与AD元素。示例：ADAD。AD元素对应可涉及一个AD或跨几个AD里的元素。AD元素对应应识别任何支配对应方法（见6.9.3）。每个AD元素对应应识别参与的AD。注：AD对应能用于表达AD、ADF和ADL之间的关系。见附录F中的Zachman框架示例。对应方法AD应包含或引用适用于其自身或其AD元素的对应方法清单。注1：应用于一个或多个AD元素的对应方法能够源自：AD元素、AD本身；AD所用的架构视角或模型种类的规格说明中（见第8章）；或在其中所用的ADF或ADL的规格说明中（见第7章）。注2：对于所应用的每个对应方法，AD应记录该方法是否成立（得到满足）或记录已知的所有违背情况。若能表明相关联的对应得到满足，则对应方法成立。若不能表明相关联的对应得到满足或不存在相关联的对应时，则对应方法遭到违背。AD应包含或引用应用于该AD的每个对应方法。注3：应用于AD的对应方法可能源自：该AD；视角或模型种类的规格说明中（见第8章）；或该AD中所选用的ADF或ADL的规格说明中（见第7章）。架构决策和理据的记录19决策记录AD应记录在AD范围和预期目的内考虑对EoI架构至关重要的架构决策。注1：AD表达有关架构的决策。架构理据表达决策为何选择。AD宜记录考虑的和否决的可替决策以及做出这些选择的理据。AD中有理据地进行记录和支撑。要考虑选取准则的决策其中包括：——关于架构上重大需求的；——需要投入大量精力或时间来制定、实施或执行的；——影响关键利益相关方或许多利益相关方的；——处理基本关注点（如性能、可进化性、安全性等）的；——需经复杂或非显性推理的；——对变化高度敏感的；——对变化极可能代价高昂的；——形成项目规划和管理（如工作分解结构创建、关键链识别和管理质量门跟踪）基础的；——导致假设换成已知信息的；——导致重大资金支出或间接成本的；——与需求符合性有联系的；——与技术标准选取有联系的；——与系统漏洞缓解相关的。在记录决策时宜考虑包含以下信息：——决策的唯一标识；——决策的清晰陈述；——决策机构或所有方的标识；——影响决策之约束和假设的标识；——决策与所涉及实体之关注点或方面的联系；——决策与受该决策影响之AD元素的联系；——与决策理据的联系；——与其他决策的关系；——决策（与其他决策有关）后果的记录；——决策发生、批准和修改的时间戳；——附加信息的来源引文。注2：决策清单并不意在详尽无遗。注3：有时对否决的可替决策及其否决理据进行记录是有用的，例如当未来所述理据不再适用而所述决策成为必要时。示例：关系类型的示例有：约束、影响、赋能、触发、强制、包容、细化、冲突、披露和兼容。决策之间的关系能通过对应或应用对应方法进行捕获。理据记录AD宜包含或引用对选用每个架构视角（见6.6）的理据。AD宜包含或引用对选用每个ADF和每个ADL的理据。20AD应包含或引用每个架构决策（见6.10.1）的理据。AD宜包含或引用对选取可替决策的考虑佐证和理据。AD宜包含对AD（AD架构描述框架与架构描述语言架构描述框架规格说明ADF（3.5）应包含或引用：ADF组织和/ADF一个或多个典型利益相关方（6.2）；典型利益相关方持有的一个或多个典型关注点（6.4）；构造典型关注点的一个或多个架构视角（8.1）。ADFAD一个或多个利益相关方角度（6.3）；一个或多个方面（6.5）；对视角进行组织（5.4.2）的一个或多个结构化形式的定义；适用于所规定架构视角（8.2）的一个或多个模型种类；适用于所规定架构视角的一个或多个图例的定义；能用于创建跟视角规格说明（7.2）ADLg)对应方法（见6.9.3）；视图方法（8.3）；组织和/或项目所规定的版本标识。EoAD，（EoI15704（见A.4.4）中定义为结构化形式的通用性维度。注1：前述清单中的“典型”一词意指“在预期适用性范围内是典型的”。ADF规格说明宜包含适用性条件。示例1：适用性条件如下：——ADF能要求AD当EoI在利益相关方辖地运行对其业务模型造成影响时，对利益相关方进行识别。——ADF能允许AD当没有为EoI识别出某实时视角的任何关注点时，对该实时视角进行省略。——ADF能允许AD当所选取的视角都没有使用某具体模型种类时，对该模型种类的使用进行省略。ADF规格说明宜表明其跟5.2所述概念的一致性。2：上述要求能通过元模型、框架构件对第5章所述要求的映射、文本叙述或其他方式来符合。符合第6章要求的AD在对下列概念的适用性进行识别和考虑时，遵循ADF规格说明。——ADF所识别的每个利益相关方（见6.2）；——ADF所识别的每个利益相关方角度（见6.3）；21——ADF所识别的每个关注点（见6.4）；——ADF所识别的每个方面（见6.5）；——ADF所规定的每个架构视角（见8.1）；——ADF（6.9.3）。ADF规格说明可建立要遵循的附加规则。AD能遵循一个或多个ADF规格说明，也能不遵循任何框架规格说明。注3：对于遵循不止一个框架规格说明的AD来说，需要在每个框架规格说明所识别的利益相关方、关注点、方面、利益相关方角度、架构视角、模型种类和AD内对应方法之间进行协调。ADF可具有带一个或多个结构类别的结构化形式，以提供展现架构各种元素间关系以及增进这些元素间交互分析机会的方式。示例2：结构类别包含如下架构构件：域、模型种类、角度、方面、疑问、抽象层级、关注点的主题、关注点的方面、阶段、层和架构级。注4：关于用到方面、利益相关方角度和其他结构类别的架构框架示例，见附录F。架构描述语言规格说明ADL规格说明应包含或引用：ADL（6.4）和方面（6.5）的标识；ADL（8.3）；ADL（8.2），用于构造相关关注点或反映相关方面；ADL（8.1）；所有对应方法（6.9.3）；组织和/或项目所规定的版本标识。架构视角规格说明架构视角规格说明应包含或引用：与本视角关联的所有利益相关方角度（6.3）；本架构视角所构造的一个或多个关注点（6.4）；与所述关注点相关的一个或多个方面（6.5）；已知的典型利益相关方（6.2），其持有该架构视角所构造（b）的所述关注点；在建造视图时使用的模型种类和图例（8.2）；对结果视图及其视图组件（6.8）内的关系进行捕获的对应方法；本视角所有相关信息来源的引文。（见8.3）；以及一个或多个模型种类（见8.2）。每个图例应向用户提供该图例所载视图组件的解读指引。架构视角规格说明能使用对应方法。架构视角规格说明能成为AD（第6章）的包含部分，成为ADF或ADL规格说明（第7章）的包含部分，或者单独使用本章的要求。注1：当架构视角规格说明在AD中包含并应用时，d）项的典型利益相关方由该AD中识别的已知利益相关方取而代之。注2：本文件不要求使用任何特定的架构视角规格说明。22注3：附录B提供了架构视角规格说明指引。模型种类规格说明模型种类规格说明应包含或引用：构成本模型种类的约定，如语言、符号或建模技术的定义等；与本模型种类关联的所有视图方法（8.3）和对应方法；组织和/或项目所规定的所有版本标识；本模型种类的所有相关信息来源。注：a）项能通过如元模型、语法或模板等多种方式满足，这样，模型种类规格说明对结构和结构模型的解读进行定义（见B.2.9）。视图方法架构视角规格说明可包含一个或多个视图方法。8.2（8.、ADL规格说明（7.2）和ADF规格说明（7.1）中对视图方法进行定义。若在创建视图时用某模型作为信息源，则视图方法宜定义：如何在视图组件中对AD元素进行描画；23附录 A（资料性）概述本附录讨论本文件所依据的原则、概念和术语。图A.1描绘AD的主要概念。图A.1架构描述的概念模型本文件使用几个术语（架构、关注点、方面、利益相关方角度、架构视图、架构视角、视图组件、模型种类本文件定义了AD的最低要求，以支持第1章中确定的范围。该方法允许组织在应用标准时有最大的灵活性，同时证明符合第6、7和8章中的要求。鉴于架构化的多学科性质，其目的是满足多个利益相关方的需求，并允许用不同的方式来描述EoI的架构。将AD组织到由架构视角支配的架构视图中，提供了一种基于利益相关方的关注点分离机制，同时提供了整个实体的集成视图，该实体是架构概念的基础。24建立符合AD（或者AD（这个AD是否完整一是评估AD注：架构评估是ISO/IEC/IEEE42030的主题。实体及其架构EoI的定义有几个关键方EoI元素。在在架构的定义（3.2）中使用短语“概念或属性”，以允许两种不同的理念无偏见地使用本文件。这两种理念是：——架构作为概念：其中架构是人们头脑中实体的概念；——架构作为属性：其中架构是EoI的属性或特性。实证研究发现，组织中存在四种架构隐喻：——架构作为蓝图；——架构作为文献；——架构作为语言；——架构作为决策。关注点（使用这个术语的动机来自EdsgerW.Dijkstra在软件和系统工程中创造的短语“关注点分离”：“让我试着向你解释一下，在我看来，什么是所有智慧思维的特征。那就是，一个人愿意为了其自正如本文件中所述，每个架构视角构造了一个或多个关注点（见6.6），以便从该架构视角的应用中产生的视图，解决了EoI已识别的关注点。通过视图分离关注点的处理，允许利益相关方关注他们特25别关注的问题，并提供了一种组织和管理AD复杂性的方法（见6.7）。企业、系统和软件工程的文献记录了大量这类关注点。5.2.3中给出了示例。方面和视角概述以及少数情况下是的这种先前经验通常被封装在基于网格的ADL中，通常是二维的，但有时是三维或更多维的。虽然这些实践中并没有统一各个行和列包括什么，但是普遍存在至少两个正交基。（适当地迭代AD中需要或可需要涵盖的内容驱（并且能通过这种组合来解决和映射关注点）。（更标准化的架构化和AD方面方面提供了一种划分架构的方法，以支持对架构的基本概念（如结构和属性）进行更系统的检查，以及对架构备选方案的评估。本文件使用术语“方面”作为AD中视图的组织基础（见6.5）。方面、关注点和利益相关方角度将视图集中于AD（示例1：飞机AD中的空间、结构、功能、连通性、分类、信息和路线图等方面。示例2：计算机AD中的行为、信息和结构方面。3：AD（的描述）。方面对于任何特定的关注点都是中立的，尽管这些关注点能映射到许多相关的方面。通过检查AD的各个方面，能辨别或预测实体的某些相关特征或属性。26ADF已经发现某些方关注点将直接应用于与EoI或架构相关的或重要的内容，而方面是架构实体本身的特征或本质的一部分。被认为与域相关和惯用的方（作为一个方面在评估备选架构时，方面也很有用（见ISO/IEC/IEEE42030）。方面的概念已经在软件开发中被用来处理“横切关注点”。方面是程序许多部分共享的一个特征，与程序的主要功能无关。非功能属性，如性能、成本和质量因素（如可靠性、保密性和弹性)是使用方面概念进行结构化的关注点（5.2.5)。这些非功能属性通常被称为“功能”或“非功能需求（NFR)”。利益相关方角度（即一个人的角度（见5.2.4中的示例）。示例：UAFArchiMateNAF退役。利益相关方角度的确定取决于与架构相关的各种利益相关方的关注和立场。对于给定的利益相关方角度，通常有多个关注点和方面需要考虑。结构化形式和结构类别ADF能提供一种结构化的形式，即使用架构考虑点和它们之间的对应的一组规则，来组织用于生成1：知名的结构化形式包括：ISO15704GERAMRAMI4.0、TOGAF（业务、信息系统、技术）、NAFUAFZachman27在本文件中，框架维度的概念被称为“结构类别”，因为这些类别在各种ADF中的使用方式并不总是与“维度”的概念一致。因此，这里使用结构类别术语，因为它是一个更广泛和更具包容性的概念。ADF能定义结构化形式中使用的结构类别。有时，这些类别由图形描述中的“维度”来表示，例如示例2：一些ADF用二维网格作为一种结构化形式，其中利益相关方角度对应于行，方面对应于列。（一些常用的ADF有一个二维网格或矩阵来组织它们的架构视角规格说明。二维网格起源于Zachman。（这些是在那些框架上使用的结构化形式的例子。UA15704中GERAM的三个主要维度的其中两个（通用性ISO15704ISO15704ADF概念。当接近现实世界中实体的实施水平时，就能使用越来越特定的（即较不通用）ADF来提供更多的特异性。3：ICTADFZachmanADFUAF（UAFSysML），这反过来又能转换为一个特定项目的一种特定ADF，这个特定项目使用进一步的建模概要文件扩展，并包含专用域特定周境的足够细节。由于质量和效率的原因，从通用、到部分通用、再到专用的转换（在ADF中提供更多域特定细节）例如具有预定义的角度和方面，这些角度和方面在类似的项目中是常见的和可重用的（先前的成功提供了专业技术和知识），同时使用给定域专家之间共享的术语。方面和利益相关方角度之间的关系方面和利益相关方角度在ADFFADF互补方法28GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022架构视图和视角本文件的目标是通过提供通用术语和概念来涵盖现有的ADAD使架构视角成为一级实体的一个结果是，它们属于视为AD元素的构件。本条的其余部分提供关于“视角”一词在系统和软件中的使用和演变的简要历史说明。Ros于197Nueibh、Kramer和Finkelstein8章规定的架构视角的形成。选择该术语是为了与ISO开放分布式处理参考模型（RM-ODP）保持一致，并用以下方式使用该术语：——（对系统的）视角是产生与一组特定关注点相关的整个系统的规格说明的抽象概念（见ISO/IEC10746-1:1998，6.2.2）；——（对系统的）视角是使用一组选定的架构构件和结构化规则实现的抽象形式，目的是聚焦系统内的特定关注点（ISO/IEC10746-2:2009，3.2.7）。（在单独的AD中，本文件要求每个视图都需要由架构视角来支配。这意味着每个视图都符合一组约定（29在视图开发需要考虑整个EoI、但实体边界未知的情况下，从支配架构视角所构造关注点和所揭示AD（例如在交付给客户时聚焦于视图有两种常见的建造方法：合成法和投影法。在合成法中，架构师建造EoI的视图，并使用对应将这些视图集成到AD附录B和附录C给出与架构视角规格说明有关的进一步信息和参考。对应对应用于识别或表达AD元素内部和之间的命名关系。尽管许多模型种类和ADL包含捕获关系（例如实体-关系-属性图中的关系、UML中的关联）的构件，但是当AD使用多个视角和模型种类时，可能没有可用方式来识别或表达这些不同表示之间的命名关系。在这种情况下，能使用对应来识别和表达这些命名关系。本文件的2011AD元素是ADAD元素包括AD元素还包括ADAD元素中的任意一个都能AD参考文献中给出对模型关系的使用以及关系机制的分类法和分类的调查。对应能用于符合6.9.1中对记录视图一致性与不一致性的要求。AD元素内部和之间的对应上施加的预期关系进行捕获。本条的其余部分给出对应和对应方法的示例，讨论对应机制相较于文献中类似机制的特征。1：考虑汽车系统AD（ECU）视图组件。软件应用视图组件包括以下元素：自动驾驶、仪表板（包含控制装置、仪表盘、中央控制台）、制动、全球定位系统（GPS）、激光雷达（LIDAR）和传感器融合。ECUECU14。图A.2“绑定于”ECU的应用见：M1仪表板、全球定位系统ECU1自动驾驶ECU2激光雷达、传感器融合ECU3制动ECU4图A.2对应的示例30该示例符合6.9.2（应用和对应方法表达要在对应上施加的约束。示例2给出一种朴素的对应方法。示例2：M1：每个应用必须绑定于至少一个ECU上。示例1中命名为“绑定于”的对应符合M1，因为所有应用都分配给至少一个ECU。大多数对应将用视图或视图组件的元素来表达，但不要求如此。示例3和4给出对应的其他形式。示例3：任务交互：对于模型种类的每一个实例，任务都需要细化到模型种类交互的实例。这种对应方法能通过图A.3所示的对应符合，其中有用户、操作员和审核员。每个任务实例（视图组件绘作三角形（视图组件绘作五角形在示例3中，对应中的参与者不是视图组件中的元素，而是视图组件本身。对应能关联任何AD元素（见5.2.11和6.9.2）；本文件的用户自由引入适合自身目的的其他类型的AD元素。许多对应将是二元的，但不要求如此。对应能关联任意数量的AD元素。示例4说明一种n元对应方法。示例4：视图版本控制：在发布本AD之前，每个视图的版本标识符都必须大于1.5。图A.3符合任务-交互方法的对应示例RM-ODPRM-ODPRM-ODPRM-ODPA.5）；31本文件允许异构视图：每个视图由一个或多个视图组件组成，其中的视图组件能使用不同的（视图之间的对应，是有用的。因此，“视图对应”是本文件所必需内容的一个特殊情况，在本文件的一般情况下，该术语某种程度上具误导性；RM-ODPnRM-ODPADAD数学上，对应是一种n元关系。对应方法是n元关系的有意定义。关系包括1-1映射（同构）和作为对架构描述语言的角度自20世纪90年代以来，术语“架构描述语言（ADL）”就在软件、系统和企业架构群体中使用。在本文件的概念模型中，ADL是用于描述架构的任何语言。早期的ADL包括Rapide（斯坦福大学），Wright（卡内基梅隆大学）和Darwin（帝国理工学院）。ADL聚焦于结构性关注点：用组件、连接器和配置表达的大规模系统组织，对构造行为关注点提供不同AADLSysML和ArchiMate。参考ADL与本文件中定义的概念模型的关系，示例1到3描述一些当代的ADL。ADLAD（例如Dari、（例如UMLRapideAADL）（例如（例如ArchiMateSysML）。因此，一个或多个架构视角规格说明能使用ADL来在AD中构造已识别的关注点。1：ArchiMateAD（或基础设施层并在每个层中指定己的元模型来定义的，将该架构视角与其他视角相关联，并指定利益相关方、关注点、目的、层和方面。2：系统建模语言（SysML）UMLSysMLSysML3：统一架构框架概要文件（UAFP）UML/SysMLAD单独创建，为了能够维护跨模型的一致性，UAFPUAFPUML2/SysMLv1.6UAF（UAFUAF例DoDAFNAF）结合使用。ADL通过定义一个或多个模型种类以及任何其他方法或工具，为利益相关方的受众构造一组特定的关注点。与ADF或架构视角类似，ADL是一种可重用的资源——它的使用并不局限于单个实体或AD。32附录 B（资料性）架构视角规格说明指南概述本附录提供用于制作架构视角规格说明的模板，以及当前可用的架构视角规格说明示例的注释指南。架构视角规格说明的记录模板模板概述给出架构视角规格说明的模板。此形式记录的架构视角符合8.1的要求。模板对架构视角规格说明的内容进行识别。内容的各个元素包括：其名称（B.2.X）、预期内容的简要描述以及为内容开发指引。在某些情况下，附加内容嵌套在规格说明的顶层描述内容中。架构视角名称架构视角概述对架构视角及其相关架构视角特征进行抽象或简要概述。关注点罗列本架构视角所构造的架构相关关注点（见8.1b项）。这有助于确定相关的架构视角是否对特定EoI的建模有用。利益相关方角度罗列与本架构视角相关联的所有利益相关方角度（见8.1a项）。方面罗列细化上述关注点（见8.1c项）或涵盖潜在关注点的方面。注：对关注点、利益相关方角度和方面的标识旨在帮助架构师和其他利益相关方确定本视角对他们EoI的实用性。典型利益相关方罗列预期成为用本架构视角所制视图的用户或受众的利益相关方（见8.1d项）。注：在某架构视角被选取使用并应用于AD时，对实际利益相关方跟该视角所构造关注点和相关规格说明之间的关联（见6.4）进行记录，这很有用。对应方法罗列由本视角或其模型种类所定义的所有对应方法（见8.1、8.2和6.9.3）。这些方法能跨视图组件、在AD内跨视图或跨AD进行应用。33模型种类规格说明概述架构视角对每个模型种类进行识别（见8.1e项）。本文件不要求以一种风格来记录模型种类规格说明。模型种类规格说明能以多种方式记录，包括：通过指定定义其核心构件和关系的元模型；通过提供由用户填写的模板；通过语言定义、建模概要文件或引用现有的建模语言；通过这些方式或其他方式的一个或多个组合。B.2.9.2至B.2.9.4中提供有关方式a）到c）的指引。与模型种类规格说明相关的元模型AD——实体：这类模型中所存在元素的主要分类是什么？——属性：在这类模型中，实体具有哪些属性？——关系：在这种类型的模型中，实体之间定义了哪些关系？——约束：在这类模型中，对实体、属性和/或关系有哪种约束？在AD中，实体、属性、关系和约束的实例是是AD元素，如5.2.9中所述。注：当架构视角规格说明指定了多个模型种类时，指定与架构视角相关的元模型来统一模型种类的定义是很有用的。此外，表达一组相关的架构视角时（例如定义ADF或ADL时），使用统一的元模型通常是有帮助的。模型种类规格说明的模板提供一个模板或表单，指定由该模型种类规格说明支配的视图组件的格式或预期内容。当在AD中使用这种模型种类时，每个这样的模板、表单或它们的部件都能有一个图例。与模型种类规格说明相关的语言AD视图方法定义视图上可用的方法（见5.2.10和8.3）。示例本节为读者提供了一些示例。注释本规格说明的用户可需要或发现有帮助的任何附加信息。来源识别本规格说明的来源（若有），包括作者、历史、参考文献和现有技术（见8.1g项）。34用于架构视角规格说明的资源下面是一些关于架构视角规格说明有据可查的资源。并非所有这些都按照本文件的要求进行记录，但能在AD中使用或以符合要求的方式包含在ADF规格说明中。——《为大型复杂的软件密集型系统定义执行视角》。上述来源记录一个“执行视角目录”，用于理解复杂的软件密集型系统的执行。规定四个架构视角：执行概要、执行部署、资源使用和执行并发。还包括架构视角之间的对应方法。——《记录软件架构：视图和其他》。3——《软件架构化的过程》。IEEE1471-2000——架构视角库。该网站是由群体指定的架构视角的存储库。——《软件架构的“4+1”视图模型》上述来源规定了逻辑、开发、过程和物理视图的架构视角。结果视图通过场景集成。——《软件系统架构：使用视角和角度与利益相关方合作》。见5..：软件密集型系统的安全性、性能和可伸缩性、可用性和弹复性，以及演进视角。注：前述角度不符合本文件的定义。35附录 C（资料性）与其他标准的关系概述本附录说明了根据本文件制作的ADAD的核心术语和概AD中使用的架构视角、关注点、方面和角度。ISO/IEC/IEEE42020:2019ISO/IEC/IEEE42020:2019规定适用于企业、组织或项目的架构过程的要求、建议和许可。在这个ISO/IEC/IEEE42020ADISO/IEC/IEEE4202042020。ISO/IEC/IEEE42030:2019ISO/IEC/IEEE42030:2019提供了检查架构有关信息的概念化基础，该基础能有助于确定架构相关ISO/IEC/IEEE4203042030提供的元素能用于确定架构的价值和特性，确认架构是否符合评估准则，确认架构是否满足利益相关方当前与未来的需要，以及确认架构是否从操作和策略方面支持决策制定。ISO/IEC/IEEE4203042030中，ADISO15704ISO15704ISO15704规定了相关的术语、概念和原则，这些术语、概念和原则被认为是解决利益相关方的关ISO15704没有提出或采用创建或使用企业架构或模型的特定方法，但本文件可以作为AD的某些术语和总体特征的来源。然而，重点是ISO15704建立了一个能够支持特定企业计划的参考库，而不是旨在满足所述需求的设计。ISO15704确定了一种广泛的潜在工件集合，用于表达企业参考架构及其相关方法。并不是所有的工件对于所有的架构工作都是适用的、必要的，也未必都是可取的。但工件的识别保证了本文件满足了36ISO15704采用的方法是在企业架构中使用系统思维和系统理论架构，以及如何基于单一的总体框（ISO15704关注企业周境中的各实体的完整生存周期架构，并提倡基于模型的架构化和用于组织这些实体模型的框架。因此，建模框架依据以下几个方面提供组织模型的方法（维度）：——模型使用的抽象程度，例如涵盖识别、概念、需求、初步（架构）设计，详细设计，构建/实施，运行和退役（ISO15704）；——关于由模型（功能、信息、资源和组织）传达的实体的信息（或方面）的类型，它描述了跨抽象范围的视角；——所涵盖的信息范围（描述任务完成和任务控制的模型）；——所依据的实施方式的范围（描述实体的人工实现部分和技术实现部分的模型）。此外，ISO15704根据通用性-特殊性轴对模型进行了分类。相应的，在建模框架中有一个连续统，覆盖：——通用模型，捕获了在关注域中跨企业建模的所有维度使用的概念的语义。通用模型的典型表述（在增加正式程度的情况下）包括分类法、元模型和本体论理论。元模型的详细程度因域（例如ISO19440、UAF域元模型等）而异；——部分通用模型，是可重用的、聚合的、典型的模型（或模型片段、模型构建块），它捕获了很多企业一个或多个工业部门内或跨工业部门的共同特征。结合抽象轴的范围，提供了模型的组织结构。注：大多数ISO标准能表示为部分通用模型或参考模型。——专用模型，描述每个EoI的个体。ISO15704:2019附录和GB/T16642-2008GERAM的GERA建模框架的详细阐述（见图C.1）。37图C.1GERA建模框架的描述从业者可使用工具支持的架构建模框架（AMF）来组织上所述的模型，因为通过这种方式，能按照架构描述框架（ADF）的建议，生成并打包这些模型的各种视图以供利益相关方使用。（GERAM方法的另一个显著特征是使用递归和迭代来管理企业及其供应链中的复杂关系（见图C.2）。38图C.2递归使用架构化工作产品迭代生存周期建模阶段GB/T8566-2022GB/T8566-2022定义了一个专门与软件架构相关的过程：架构定义（见GB/T8566-2022）。本文件中的架构概念与GB/T8566-2022的架构化程序一致。然而，除了本文的要求之外，GB/T8566-2022还对AD正如在GB/T8566-2022中6.4.4.3c）的第2项的注释中所观察到的，架构不一定与所有需求有关，而只与驱动架构的需求有关，因此架构定义过程的重点是关键软件需求。AD的预期用途能包括GB/T8566-2022AD能符合本文件和GB/T8566-2022。C.6与GB/T22032-2021一起使用39GB/T22032-2021定义了