系统与软件工程 架构描述 征求意见稿

1系统与软件工程架构描述本文件规定了对各种实体的架构描述（AD）的结构和表达要求，各种实体包括软件、系统、企业、系统之系统、系统族、产品（货物或服务）、产品线、服务线、技术和业务域。本文件界定了所关注实体（EoI）的架构和表达架构的AD。本文件的主题不是架构。本文件规定了对在AD中捕获的架构概念及其关系的使用要求，但未规定对任何EoI或其环境的要求。本文件规定了对架构描述框架（ADF）、架构描述语言（ADL）、架构视角和模型种类的要求，以有效支持AD的开发和使用。本文件规定了对AD、ADF、ADL、架构视角和模型种类的符合性要求。本文件未规定创建、利用或管理AD的过程、架构化方法、模型、符号、技术或工具。本文件未规定记录AD的任何格式或介质。本文件适用于：a)帮助理解各种实体的涉及其结构、行为、设计和演变的基本概念或属性；b)在EoI或其架构的周境中为组织内的AD、ADF和ADL开发建立连贯的架构化实践；c)评估AD、ADF、ADL、架构视角和模型种类的规格说明的符合性。2规范性引用文件本文件没有规范性引用文件。3术语、定义和缩略语3.1术语和定义下列术语和定义适用于本文件。3.1.1架构化architecting在所关注实体（3.12）的整个生存周期中，对一个架构（3.2）进行构想、定义、表达、记录、沟通、证明其正确实施、维护和改进。3.1.2架构architecture实体在其环境（3.13）中的基本概念或属性，以及该实体及其相关生存周期过程的实现和演化的管控原则。[来源：ISO/IEC/IEEE42020:2019，3.3，有修改。]3.1.3架构描述architecturedescription；AD用于表达架构（3.2）的工作产品。2GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022注1：工作产品是由过程产生的人工制品（见ISO/IEC20246：注2：AD是提供给利益相关方（3.17）的信息的有形表示。AD认为是一3.1.4架构描述元素architecturedescriptionelementAD元素ADelement架构描述（3.3）的已识别或已命名部分。AD所使用的ADL（3.6）、ADF（3.5）和对视图组件（3.19）、架构视角（3.8）和模型种类（3.15注2：就对应（3.11）的而言，一个AD（3.3）能认为是另3.1.5架构描述框架architecturedescriptionframework；ADF在特定的应用域或利益相关方（3.17）群体中建立的架构（3.2）描述的约定、原则和实践。示例：通用企业参考架构建模框架（GERAMISO），注：架构描述框架促进架构视图（3.7）和模型的组织结构化、描述的一致性、更大的重用潜力以及完整性。3.1.6架构描述语言architecturedescriptionlanguage；ADL具有语法和语义的表达方式，由一组用于描述架构（3.2）的表示、约定和相关规则组成。示例：架构分析和设计语言（AADL）、Arch3.1.7架构视图architectureview组成架构描述（3.3）的一部分的信息部件（3.14）。示例：信息或数据视图处理由信息视角构造的信息相关的关注据管理模型和数据访问模型，以及将这些组件连3.1.8架构视角architectureviewpoint用于创建、解读和使用架构视图（3.7）的一组约定，以构造一个或多个关注点（3.10）。注1：在本文件中，“构造”关注点意为“塑造、组成、表达”这些关注点。它用于区分由视角构造关注点的阶段注2：视角是架构师决定的与架构描述（3.3）的目的相注3：架构视角的约定记录在这个视角的规格说明（3.16）中。在一些群体和架构框架中，“视图规格说明”被用注4：视角的识别通常是该视角所适用域的先验知识、经验和实际运用的结果，表明与解决关注点（3.10）相关的3.1.9方面aspect3GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022实体特征或本质的一部分。注1：一个特定的方面能用于捕获所关注实体（3.12）的相关特征，作为一个或多个关注点（3.10）的细化，该关注点关于其特征的某些部分，例如实体的结构特征、功注2：方面帮助架构师分析、处理和结构化关注点（3.10）。一般来说，方面和关注点（3.10）之间存在多对多的3.1.10关注点concern与利益相关方（3.17）有关的或重要的事项。注1：能针对所关注实体（3.12）识别，或独立地识别关注点，例如针对该实体的环境、注2：在本文件中，对实体的关注意在涵盖对该实体的环境（3.13）、生和运营的关注。这些关注通过方面（3.9）、关注点和利益相关方角度注3：关注点的识别通常是该关注点所适用域的先验知识、经验[来源：ISO/IEC/IEEE42020:2019，3.8，有修改。]3.1.11对应correspondence两个及以上架构描述元素（3.4）之间的已识别或命名的关系。示例：对应用于表达广泛的关系，如等价性、组合性、精化性、一致性、注1：为了形成对应，一个架构描述（3.3）能视为另一个架构描述（3.3）中3.1.12所关注实体entityofinterest；Eol架构描述（3.3）的主题。示例：企业、组织、解决方案、系统（包括软件系统）、子系统、过程、应用、信息技术（作为集合）、任务、产品、服务、软件项、硬件项、产品线、系统族、系统之系统注2：本文件将所关注实体与非架构描述（3.3）主注3：在本文件中，对一个实体的关注旨在涵盖对该实体的环境、生存周期、架构、需求、设计、实现和运营的关注。这些关注是通过各方面、关注点和利益相3.1.13环境environment周围事物、条件或实体所受影响的周境。法律、监管、生态和社会影响的外部实体，以及外部物理效应，如电磁辐射、带电粒子、引力效应、电场和4GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:20223.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框架中间三行的标签（即所有注：人们思考实体的方式会受到其信仰、培训、经验、知识、个性、3.1.19视图组件viewcomponent架构视图组件architectureviewcomponent由适用模型种类（3.15）或图例支配的一个或多个架构视图（3.7）的可分离部分。示例：描述访问控制机制的架构视图组件能用在架构描述（3.3）的多个视图中，以解释实体的功能流、行为和安注：在架构描述（3.3）的周境中，图例是约定的非正式文档化形式。3.2缩略语下列缩略语适用于本文件。AADL：架构分析和设计语言（ArchitectureAnalysisandDesignLanguage）5GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022AD：架构描述（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）4符合性本文件的要求包含在第6、7和8章中。下列五种情形能提出符合本文件规定的声明。a)当对AD的符合性进行声明时，声明应证明AD的规格说明符合第6章中列出的要求。b)当对ADF的符合性进行声明时，声明应证明ADF的规格说明符合7.1中列出的要求。c)当对ADL的符合性进行声明时，声明应证明ADL的规格说明符7.2中列出的要求。d)当对架构视角的符合性进行声明时，声明应证明架构视角的规格说明符合8.1中列出的要求。e)当对模型种类的符合性进行声明时，声明应证明该模型种类的规格说明符合8.2中列出的要本文件既不要求也不准许在提出符合性声明时使用“裁剪”。5基本概念5.1概述本章介绍以概念模型集（见5.2）来表达架构描述（AD）的基本概念，并介绍所述基本概念在AD、ADF（见5.4.2）和ADL（见5.4.3）中的应用。附录D概括了使用AD来支持的不同架构实践。本章中介绍的概念在第6章到第8章中用于表达要求。注：附录A进一步讨论了本文件中使用的术语和概念，并给出了其在历史周境中的使用实例。5.2架构描述的概念模型5.2.1架构描述的周境6GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022术语“所关注实体（EoI）”在本文件中用于指代AD的主题。该术语旨在涵盖但不限于在下列应用领域内的、反映本文件第1章所规定预期范围的各种实体：——软件，包括软件产品和服务（见GB/T8566）；——系统，包括独一无二的系统，大规模生产的系统，定制的、自适应的系统，独立的和嵌入式系统（见GB/T22032）；——企业（如ISO15704所述），即具有使命、目标和目的，以提供产品或服务，或实现预期项目成果或业务成果的人类事业或风险企业。本文件对上述应用领域或其他领域中的实体构成不持任何立场。实体可能是具体的实体，也可能是抽象的实体。本文件中规定的AD不仅适用于上述应用领域中的实体，还适用于自然系统或概念系统等领域中的实体。每个EoI都位于一个影响其特性和行为的环境中。贯穿EoI的整个生存周期，环境决定了对EoI的全部影响，以及EoI对该环境的全部影响，包括它与环境和其他实体的相互作用。图1描绘关于EoI及其架构的关键概念，作为理解AD的一种方式。注1：第5章其余部分的图和文字构成了一套AD的概念模型。图1到图6件读者理解。在图中，圆角矩形表示信息对象，箭头表示对象之间的关系且沿箭头方向读取其注释。这些图说明了贯穿第5章描述的关键概念。附录A提供了示例：EoI的识别通常源自问题空间的定义。问题描述能5.2.2架构和架构描述EoI的架构涵盖在其环境中考虑的该实体的基本概念或属性。EoI的架构能涉及该实体的下列任意部分或全部：——构成要素；——要素之间的相互作用或相互关系；——与其环境的相互作用或相互关系，包括与环境中其他实体的相互作用或相互关系；——行为和结构；——设计、使用、操作和发展的支配原则。AD是架构的一种表达。AD是架构化的工作产品。作为工作产品，AD是为进行架构化的特定目的而产生，这与EoI的目的截然不同。AD由AD元素组成（见5.2.9）。EoI的架构能通过一个或多个不同的AD来理解，每个AD都是为了与架构和利益相关方需要相关的目的而创建的。例如，不同的AD可能基于不同的利益相关方（见5.2.3）、利益相关方角度（见5.2.4）、时期（有时称为时代）或环境中的特定周境或用法。注：ISO/IEC/IEEE42020规定了一套架构化过程，能用于支持创建一个或多个AD。5.2.3利益相关方和关注点利益相关方是在实体中具有直接或间接利益的各方。利益相关方包括对实体施加影响或控制的各方以及受实体影响的各方。利益相关方的关注通常表示为对EoI或已知架构的关注点。关注点常常是从领域知识、经验、培训、责任和权威得到的利益相关方角度的结果。关注点是一个或多个利益相关方关注或重要的事项。一个关注点能由一个或多个利益相关方共同持有，一个利益相关方能持有多个关注点。利益相关方所持关注点的合理性和重要性能归因于利益相关方的角色作用（如所有方、最终用户/参与方、开发方、架构师、维护方、处置方），或者经济权利、社7GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022会权利、股份、影响力或主张（如基金组织、政府机构、实体所造成环境影响的接受方、受EoI影响之实体的利益相关方）。一些利益相关方的关注点与EoI的成功背道而驰。这些利益相关方能出于政治或环境考虑而有不同意见，能主动干扰实体的运营甚至彻底摧毁实体。在开发实体的架构时，能考虑这些相反的关注点。例如，能通过在实体的架构中纳入协商解决方案来解决政治反对，或者能通过采取预防措施来减轻威胁。在EoI的生存周期中，关注点能在任何时间出现，包括（但不限于）概念化时期，设计抉择之际，从建设或实施起，贯穿部署、运营、所有权转移、退役及处置过程。关于利益相关方的需要、架构目标、期望、责任、需求、设计约束和假设，关注点能以不同的方式体现。关注点也能体现对依赖性、质量特性、架构决策、风险或其他问题的认识。关注点可能涉及对某个EoI施加的或由其施加的影响，包括发展、技术、商业、运营、组织、政治、经济、法律、监管、生态、社会和物理的影响。关注点也可能与设计影响有关，例如内部结构特征和组件互操作性，特别是在对系统之系统或企业进行架构化时。——系统是如何维护的？——哪些系统行为是安全关键的？——EoI能否符合国家法规？——运营成本是多少？——架构给出了哪些风险、机遇、满意度、弹复性、一致性、可负担性、复杂性和信任？——开放分布式处理参考模型中描述的分布透明性是什么？——如果是商用飞机的飞行导航系统，GPS信号的可用性、可跟踪性、准确性、视线接收、高度或海拔是多少？——数据质量是什么（即GB/T25000.）？——系统维护机密性、完整性和可用性以保护运行的能力是什么？——支持从传统能力向现代化作战能力无缝过渡的能力是什么？5.2.4利益相关方角度基于其共同的角色、经验、信仰或其他特征，利益相关方通常形成不同的群体或利益相关方角度。角度能反映域知识、职业经验、培训或在EoI生存周期（如设计、开发、制造、供应、运营和使用）中与EoI的接近程度。重要的是，利益相关方角度也会受到个性、性格特征、文化、同行压力、支持者等因素的影响。利益相关方角度是在周境中对EoI的思考方式，特别是在涉及关注点时。通常，对于EoI的架构有几种思考方式。AD的目的（见6.2）在于指导识别能反映某些利益相关方角度的关注点。对于任何EoI，通常存在多个利益相关方角度。每个角度产生一个或多个关注点。由于关注点产生自利益相关方角度，构造这些关注点的架构视角通常按利益相关方角度分组。关注点基于利益相关方的当前关注和影响，并且通常本质上具有主观性。8GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:20225.2.5方面方面捕获EoI在其环境中的一组特性或特征，用以处理AD内的关注点。一个方面能涉及利益相关方的一个或多个关注点。根据应用领域内的先前经验使用已知方面，使能对已确立关注点范围的系统覆盖以及对新关注点的识别。方面基于架构表征中的经验，而且在性质上（较关注点）更为客观，这是因为方面产生于专家对域内实践的共识并且因此被推定为最佳实践。通过对方面进行检查，能够辨别或预测EoI的相关特征或属性。对方面进行分析，能发现一个或多个关注点。对方面与关注点间关系的定义以架构师的经验为基础，由利益相关方根据其理解和知识进行评估。注：A.4.2包含关于方面实用性的更多信息。图1描绘AD中所运用的关注点、方面和利益相关方角度之间的关系。图1关注点、方面和利益相关方角度5.2.6架构考虑点架构考虑点是做架构化时要考虑的因素。关注点（见5.2.3）、利益相关方角度（见5.2.4）和方面（见5.2.5）是架构化时要思考的不同考虑点。其他考虑点还可能因架构使用实践而产生。架构考虑点在规定架构视角时及在构造、解释、组织或使用架构视图（见5.2.7）时是有用的。架构考虑点能对架构视角规格说明进行分组，例如就利益相关方角度。示例：架构考虑点包括：利益相关方对表达9GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022式化程度；支撑工具的可用性；给定行业域中的标准使用实践；时间与资源的可注：其他考虑点可能涉及周境、准则、构建块和域词汇表。5.2.7架构视图和架构视角AD包含一个或多个架构视图。架构视角支配这些架构视图中的一个或多个。架构视角规格说明确立了对视图进行创建、解释、展示和分析的约定，以处理由该视角构造的关注点。视角规格说明通常反映信息元素，这些信息元素促进知识（可能包括非正式知识或隐性经验知识）应用以确定架构是否令人满意地处理了关注点。注1：架构关注点、利益相关方角度和方面能够起到AD各视角的组织基础的作用。方面是关注点的提炼，且方面可视图）。该视图处理通信参数，如运营方和用户（利益相关方）的吞吐量和上线），图2描绘AD中架构视图和架构视角之间的关系。图2架构视图和架构视角GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022一个架构视角构造一个或多个关注点（见5.2.3）。一个关注点能够通过多个视角构造。架构视角对将反映于一个或多个架构视图里的特定方面以及将由一个或多个架构视图处理的关注点进行识别。架构视角规格说明为架构视图的创建者、解读者或使用者提供约定，例如AD元素、语法和语义、使用指南和方向。注2：与产品验收需求不同，EoI的架构视图处理关注点并反映方在创建视图（见5.2.9）时，视角规格说明用元模型或其他约定来确立AD元素（例如实体、关系、属性和约束）的使用方式以及可能由视角进行转换的方式。架构视角是开发架构视图的重要分析资源，因为视角反映了架构化目的、典型利益相关方及其角度、识别的关注点、定义的EoI方面以及具体的AD元素。注3：第8章规定了关于架构视角规格说明的需求。附录B提供了5.2.8模型种类、图例和架构视图组件架构视图由一个或多个架构视图组件组成。视图组件能基于模型或者不基于模型。每个视图组件由其架构视角所识别的模型种类或图例所支配。模型种类决定基于模型之视图组件的约定。图例记载视图组件的约定。所述约定包括：预期用途、术语、符号及其语法与语义，以及图例所支配模型的符号体系。一个模型种类或图例能为AD中的多个视角所用。在AD中，架构视图组件能是多个架构视图的部分，以使当其内容和表现与多个视图相关时能共享信息。示例2：数据流图能是功能视图的视图组件。单独的控制流图能是同一功能视图中的第二个视图组件。功能视图还能包含解释如何解读视图中的流程图的叙述。流程图是基于模型的，而叙述不是。图3描绘视图组件对视图的组成以及视图组件的种类。图3视图和视图组件的概念模型5.2.9架构描述（AD）元素GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022AD元素是在AD中一个或多个架构概念的实例。AD元素包括的实例涉及以下架构概念：利益相关方、关注点、方向、利益相关方角度、架构视角、架构视图、模型种类、图例、架构视图组件、架构决策、架构理据以及对所述构件规定的任何对应和对应方法。任一这些概念都能在一个或多个AD中具有多个实例。AD元素实例具体说明一个或多个架构概念。AD中的AD元素能参考另一AD进行细化或详述。AD能运用作为不同AD的AD元素而引入的协议。随着视角（见5.2.7）、模型种类（见5.2.8）和图例（见5.2.8）的规定和应用，附加AD元素被引入。支配地位的视角、模型种类或图例决定所引入的AD元素的语法和语义约定。示例：由视角或模型种类引入的AD元素包括：用例构件（如前置条件、行动者、边界、系统等）；活动模型构件）；5.2.10视图方法架构视角规格说明包括一个或多个视图方法。视图方法提供了指引、启发、度量、模式、设计规则或指南、最佳实践和示例，以助于视图建造及关联视图使用。视图方法规定视图上的表达规则、建模方法、分析技术和其他操作。这些方法规定创建视图时所使用的AD元素，以及评估所关注属性的视图分析、询问或查询方法。对视图方法的要求在8.3中规定。视图方法分为几类，包括：——建造类方法，是使用某个视角来准备视图的手段。此类方法能采用的形式有：过程式指引（如何开始、下一步该做什么）；或描述式指引（此类型视图的模板）；或启发式、风格、模式，或其他习惯用法。——解读类方法，是利益相关方和其他用户理解视图的手段。——分析类方法，用于对视图的结果进行检查、推理、转换、预测、应用和评估。注：视图方法通常在视角中定义，并被模型种类、ADF和ADL所引用或使用。示例：视图方法涉及：链接依赖项以评估变化的影响；权衡质量或其他）；预期属性；针对完整性和覆盖范围的要求进行的分析；解读和整5.2.11AD元素对应AD元素对应识别两个及以上AD元素间的已识别或命名的关系。AD元素对应能够：——将一个AD中的一个或多个AD元素与一个或多个AD元素进行关联；——将多个AD中出现的一个或多个AD元素与一个或多个AD元素进行关联；——将一个ADF或跨越几个ADF中的一个或多个AD元素与一个或多个AD元素进行关联；——将使用一种或多种ADL的一个或多个AD元素与一个或多个AD元素进行关联。为达到对应目的，AD本身可认为是不同AD的AD元素。AD元素对应可用于：表示AD内部和AD之间的一致性关系；促进相关系统的AD之间的相关性；或使相关描述能进行协调解读与分析。AD元素对应可由对应方法支配，对应方法通过表达规则、实践或模型来规定AD元素之间的具体关系。AD元素对应和对应方法能用于表达和实施架构关系，如AD元素的组成、细化、一致性、可追溯性、依赖性、约束、满意度和义务。示例1：视图内AD元素与该视图所处理关注点之间的对应；架构视图与所实现方面之间的对应；AD元素与所实现功能之间的对应；组件接口与该接口所遵循标准堆栈之间的对应；功能流数GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022图4描绘AD元素对应的本质。图4AD元素对应的概念模型注1：对应和对应方法的使用要求在6.9中规定。附加的注2：本文件中的对应跟ISO/IEC10746-2（RM-ODP）和ISO/IEC19注3：对应方法通常是“跨模型”、“跨视图”或“跨AD”的，因为视图组件内的对应是模型种注4：对应和对应方法能应用于多个AD元素，以表达涉及5.2.12架构决策和理据架构决策是在架构整体周境中做出的选择的集合。这些选择通常涉及到多种AD元素、实体需求或对架构的环境影响。示例1：架构概念选取、AD元素选择、ADF选取、架构分层方案选择、底层技术选择、业量所用战术选择、业务过程选择、适用模式选择、待应用风格选择、待考虑实现技术或其他实架构理据记载关于架构决策的解释、理由或推理。决策的理据能包括以下事项：做出决策的基础；对质量属性的影响；考虑的替代和折衷方案；决策的潜在后果；架构原则；以及对附加信息来源的引用。示例2：满足成本承诺；满足时间承诺；使用经过验证的技术；最小化返工；减少资本投入；实现接口兼容性；满注：关于捕获AD内决策和理据的要求，在6.10中规定。5.3生存周期中的架构描述架构化活动发生以及AD因各种理由而制作，这贯穿EoI的整个生存周期，从初始概念到该实体的运营、整顿或最后退役停用以及最终废弃。注1：由于AD描述EoI的概念，在某些情况下，只要该概念仍受关注，即使退GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022AD是由架构化所产生的工作产品，架构化发生在项目和/或组织（公司、公司网络、联盟和标准化机构）的周境中。在EoI的生存周期中，AD能领先于或跟随于架构的创建、更新或变更。5.4架构描述框架与语言5.4.1概述ADF和ADL目前在架构化中广泛使用，来促使AD的建造和使用人员规范化地表达架构，并确保跨AD的风格和内容覆盖的一致性。在本文件提出的AD概念上所构建的ADF和ADL能有效运用于：a)通用参考框架和语言，旨在为更具体的ADF提供指导和支持；b)特殊用途框架和语言，旨在实现更好的分析理解和态势感知；c)实体实施框架和语言，旨在促进实体的工程、运行和退役。5.4.2架构描述框架ADF建立在特定关注域（如国防、航空航天和银行等）内对AD进行创建、解读、分析和使用的公共实践。ADF还能为一个或多个专用ADF提供指导或作为参考。对于特定实践域周境中的通用EoI，ADF旨在作为参考对预期或已知架构考虑点的架构视角进行典型识别，架构考虑点通常是利益相关方角度、关注点或有关结构、功能（行为和适应性）和生存周期的方面。为参考使用，许多不同的利益相关方角度能进行通用化。利用架构视角，参考的用户有权访问适合通用EoI的视图，该实体能满足该视角所构造的架构考虑点。ADF中识别的架构视角旨在为更具体的ADF提供指导或作为参考，对典型关注点、方面、模型种类和视图方法进行识别，这些组成支配该视角所关联视图的约定。通用参考ADF的用户能对架构考虑点、架构视角规格说明以及由此产生的架构视图进行特殊化，形成用于实现特定EoI架构的ADF。ADF中识别的架构视角能从先前架构化工作所规定或使用的架构视角相关经验中产生，以确定对于EoI的关注点满意度细化到与ADF目的一致的程度。注1：ADF中做出具体的架构决策：利益相关方和相关关注点的选取、特定方面以及利益相关方角度。ADF将根据这ADF提供一种结构化形式，对通常与用于生成相关视图的架构视角相关联的AD元素进行组织。结构化形式目的是提供展现架构各种元素间关系以及增进这些元素间交互分析机会的方式。注2：最常见的结构化形式是使用架构考虑点，即关注点、利益相关方角度和方面，以网图5描绘ADF的概念模型。GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022图5架构描述框架的概念模型ADF定义了在结构化形式中使用的结构类别。这些类别是通过对应方法形成的，这些方法将AD元素分组成有意义的配置，以便对EoI的AD进行展示、分析和管理。式通常具有两个框架维度，但是结构化形式能具有单个框架维度，通常在多层次层次结构中分段进行描述，示例2：Zachman和UAF的ADF好地理解而修改参考ADF时。由于引入特殊化AD元素，改变词汇和架构视角规格说在ADF中，架构视角是开发架构视图的重要分析资源，因为视角反映架构目的、典型利益相关方及其角度、已识别的关注点、已定义的EoI方面以及特定的AD元素。根据框架的预期应用，视角产生的详细程度能有很大的差异。参考框架能期望具有更通用化的利益相关方角度和架构考虑点，通常分为多个功能集群，如产品和生存周期。5.4.3ADF的应用当用户在共同的方法论中共享典型的AD元素时，他们能开发和维护不太通用的特定域的ADF作为参考，其内容包含架构考虑点和利益相关方角度，以及适当的模型种类和图例。一些参考ADF包含与EoI的每个视图所使用的模型种类和图例相关的符号的明确定义。而额外的模型种类能解决特定框架未涵盖却需要考虑的问题。特殊化框架或者旨在实施而不是参考的框架，有更具体和可能更详细的利益相关方关注点、特定方面，并且通常只考虑生存周期的一小部分或者不考虑生存周期。注1：在一些领域中，相似的架构化常常会不断复现，这样可形成一个特定领域的实践群体，并形成规范：具有重复关注点的利益相关方，处理特定方面的约定，以及ADF在不同情况下的使用可能会识别出新的架构考虑点和有用的视角、模型种类、图例、视图和对应的新组合。在不同情况下可能会发生以下情况：——忽略生存周期或生存周期的一部分；——只包含一些利益相关方或方面；——包含重叠的方面集合；GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022——只包含子域或子组的方面；——随着新的关注点出现，包含新的或适应的视角；——识别以前未意识到的对应。从不同的利益相关方角度、跨越不同的EoI方面（如结构、行为和连接性）来审视利益相关方关注点，通常更易于理解。一些利益相关方从业务角度来看待架构，能关注所需或所提供的功能（实体的哪些能力正在被创建或改变，或者需要哪些新的过程另一些利益相关方则从经济角度来看待架构，能关注相同功能的财务影响（投资影响如何，对底线的预期影响是什么。注4：附录F提供关于ADF的信息以及如何将其与本文件的概注5：ADF识别一个或多个AD元素，这些元素是架构构件（如利益相关方、一种看待ADF的角度是，ADF对架构化工作（或项目）的信息模型进行规定，该工作负责开发架构及其描述。换句话说，ADF以有组织的形式描述需要制作的信息元素。若以通用的方式描述ADF，则其只能用作这个信息模型的参考模型（或部分模型），需要通过添加必要的细节来定制化以满足工作的目的。相反，若ADF已经为应用域的目的进行定制化，则在利用之前需要进行的定制工作就会更少。然而，考虑到具体架构化工作的目标，特定域的ADF能进一步特殊化。例如，从这些目标的视角来看，某些视角、方面或角度可不相关，或者反过来，可存在特定于具体工作并且为此应处理的关注点，这需要规定和使用附加的视角。这种从通用到引用（或部分引用）、以及特定模型的连续性是在ISO15704中表达的相同概念的一种应用（有关详细信息，见C.4）。5.4.4架构描述语言ADL是一种特定的语法和语义，用于描述EoI的架构。ADL是一种面向利益相关方，包括从事架构化工作者的语言，通过涉及EoI和架构化周境的AD元素来表达架构考虑点。AD能使用多个ADL，甚至每个视角使用不同的ADL，或甚至单个架构视角所规定的每个模型种类使用不同的ADL。具有针对特定域（例如航空航天、医疗保健、金融）或平台（J2EE、.NET）的共同定制的能采用（或设计）各种ADL来表达架构师需要解决的特定架构的考虑点。注1：在一个AD中使用多个ADL需要非常小ADL提供一种创建和理解组成架构视图的视图组件的方法。通过考虑规定信息如何在架构视图中选择、转换和呈现的视图方法来选择适当的ADL。视图方法决定在构建AD时要收集的信息，用于分析收集到的描述的信息，以及描述架构概念和特征所需的信息。ADL能为AD的开发提供必要的严谨性。ADL的语义能通过以下方式以逐渐增强的形式和表达能力来进行规范化：使用自然语言的词汇表或术语表，术语和关系的分类体系，表达语言结构使用的元模型，作为本体理论使用形式逻辑中的公理，或者作为分析理论使用微分方程、张量计算等。GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022当从相当通用的参考ADF通过域特定ADF和实践特定ADF过渡到实施ADF时，可能会使用不同的ADL来满足架构视角和架构视图的更细化规格说明。由于多个AD是为相同域EoI创建的，因此保持它们之间的一致性或至少可追溯性非常重要；因此，需要使用对应（见6.9.2）或统一的底层本体（见A.6关于投影和综合视图创建方法）来捕获一致性条件。实践中使用的真正ADL构件是这个集成本体的子集。注2：ADL识别一个或多个AD元素，这些元素是架构构件（利益相关方、关注点、图6给出ADL的概念模型。图6架构描述语言的概念模型6架构描述的规格说明6.1架构描述识别与概述AD应识别EoI以及该EoI的预期环境。AD应包含其预期目的的声明。AD应包含项目和/或组织确定的识别信息和补充信息。示例：发行日期和状态、作者、审核人、审批机关、发行制信息、配置管理信息和参考资料。更多示例见ISO/IEC/IEEE注1：对于旨在作为其他AD参考的AD，EoI是抽象的，或是EoI的通用化，该AD目的是表达一种参考架构，可能为更注3：本文件不规定如何创建AD。例如，它们能单独构建、使用自动化工具生成、从其他信息源和模型派生或基于GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022注4：本文件不规定在AD中使用形式化建模方法的范围或预期。虽然非形式化方法能有效地使用，但形式化建模方6.2利益相关方的识别AD应识别所持关注点认为是EoI架构的基础并且与AD目的一致的利益相关方。监管机构（包括政府）、测试方、普通公众AD宜识别架构对当前和未来利益相关方的潜在影响。应考虑对架构及相关架构的先前评估中提出的建议。AD应包含已知资源限制或其他约束的声明，这些限制或约束阻碍AD处理已识别的利益相关方和架构考虑点，即关注点、角度和方面。应识别不符合项，并解释产生的原因。6.3利益相关方角度的识别AD应识别认为与EoI架构相关并且与AD目的一致的利益相关方角度。AD应将每个已识别角度与持有该角度的已识别利益相关方进行关联。在AD的预期目的范围内，架构化工作宜识别可与EoI相关的当前或未来的利益相关方角度。对于每个已识别的角度，AD应从已识别的关注点（见6.4）中列举该角度产生的关注点。示例：利益相关方角度包括：战略角度、组织角度、运营角度注1：本文件没有规定：关注点的粒度；利益相关方角度的粒度和依赖性；利益相关方角度如何相互关联；或者利益相关方角度如何与关于一个实体的其他陈述相关联，例如利益相关方6.4关注点的识别AD应识别认为与EoI架构相关并且与AD目的一致的关注点。示例：关注点包括：架构对于实现（达到）EoI的目标的适用性、实现（实施）EoI的企业能力、实现和操作EoI的可行性、EoI在其整个生存周期中对其利益相关方的潜在风险和影响、对利益相关方的附加值、已知架构的重用、弹复性（还原能力）、可扩展性、适应性、可演进性、等待时间（延迟）、资源利用率、有效性、AD应将每个已识别的关注点与拥有该关注点的已识别的利益相关方联系起来。注3：以疑问句的形式并以AD目的的适当细节表达关注点，能使沟6.5方面的识别AD应识别认为与EoI架构相关并且与AD目的一致的方面。每一个被识别的方面都应与它所应用的关注点相关联。注：本文件没有规定：方面的粒度和依赖性；方面如何相互关联；或者方如利益相关方要求、实体目标或实体需求。GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:20226.6架构视角的包含内容AD应包含或引用其中使用的每个架构视角。每个架构视角应包含由组织和/或项目指定的版本标识。每个包含的架构视角相关的规格说明应符合第8章的规定。根据6.4识别的每个关注点应由至少一个架构视角所构造。根据6.3识别的每个利益相关方角度应与覆盖该角度的架构视角相关联。注3：架构视角能作为架构师和利益相关方之间的契约。对于由架构视角所构造的关注点，架构师和利益相关方能就使用什么符号和表示约定来解决这些关注点达成一致。能在进行任何详细的架构化之前签订合同协议，以6.7架构视图的包含内容AD应包含一个或多个架构视图，用于所使用的每个架构视角。注1：当一个视角在一个特定AD中支配多个视图时，每个架构视图应包含由组织和/或项目指定的版本标识。每个利益相关方角度（根据6.3由AD识别）应由至少一个视图根据该视图的支配视角进行处理。每个关注点（根据6.4由AD识别）应由至少一个视图根据该视图的支配视角进行处理。每个方面（根据6.5由AD识别）应由至少一个视图根据视图的支配视角进行处理。每一个架构视图都应遵守其支配架构视角的约定。每个架构视图可解决不止一个关注点。每个架构视图应包含或给出引用：a)由组织和/或项目规定的识别和补充信息；b)该视图的支配架构视角的标识；c)一个或多个视图组件，其处理由该视图的支配架构视角（见6.6）构造的所有关注点（见6.4并且覆盖跟该视角相关的某些或全部EoI；以及d)视图内跟该视图支配架构视角相关的任何已知问题的记录。要做出决策。例外和偏差能记录为决策结果和理注3：就AD的目的和范围而言，不必要求每个视图都覆盖整个EoI。例AD可包含不属于任何架构视图的其他信息。示例2：不在任何视图内的信息部件可能有：EoI概览、架构原则、架构模式和架构风格，其应用跨越多个视图；架构的参考基础，例如域或参考架构；视图之间的对应；及架构理据。此信息能帮助利益相关方和负责AD维护和开发6.8视图组件的包含内容架构视图应由支配架构视角相一致的一个或多个视图组件所组成。每个视图组件应包含由组织和/或项目指定的版本标识。GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022每个视图组件应识别其支配模型种类（若有），并且遵守其支配架构视角的约定（见6.6）。在一个视图内，能用一个或多个视图组件来选择性地呈现架构视角所需的部分或全部信息内容，以突显所关注要点。视图组件可作为多个架构视图的一部分。对应能表达跨视图共享的组件之间的关系。当视图组件没有支配模型种类时（即对于没有以模型来描述的信息部件该视图组件应包含一个图例来规定该视图组件所使用的约定。示例：视图组件是专家意见记录，而不是能使用计算、模拟或其他并降低不一致的可能性。视图组件共享也允许面向方面的AD风格：跨架构视图共享的视图组件能用来表达架注2：本文件未规定AD所用视图组件的形式化程度。基于模型的视图组件具有形式化的语义和语法规格说明，能少6.9架构对应的记录6.9.1架构描述内的一致性AD应记录一切已知的不一致性。AD宜包含或引用针对其架构视图、其视图组件和其他AD元素的一致性分析。对应和对应方法（如6.9.2和6.9.3所规定）可用于对AD内部和之间的视图、视图组件和其他AD元素的相互一致性进行表达、记录、实施和分析。6.9.2对应AD应包含或引用AD元素对应列表。AD元素对应应识别一个或多个参与AD元素。AD元素对应可涉及一个AD或跨几个AD里的元素。AD元素对应应识别任何支配对应方法（见6.9.3）。每个AD元素对应应识别参与的AD。注：AD对应能用于表达AD、ADF和ADL之间的关系。见附录F中的Zachman框架示例。6.9.3对应方法AD应包含或引用适用于其自身或其AD元素的对应方法清单。注1：应用于一个或多个AD元素的对应方法能够源自：AD元素、AD本身；AD所用的架构视角或模型种类的规格说明）；注2：对于所应用的每个对应方法，AD应记录该方法是否成立（得到满足）或记录已知的所有违背情况。若能表明相关联的对应得到满足，则对应方法成立。若不能表明相关联的对应得到满足或不存在相关联的对应时，则AD应包含或引用应用于该AD的每个对应方法。注3：应用于AD的对应方法可能源自：该AD；视角或模型种类的规格说明中（见第8章）；或该AD中所选用的ADF或6.10架构决策和理据的记录GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:20226.10.1决策记录AD应记录在AD范围和预期目的内考虑对EoI架构至关重要的架构决策。AD宜记录考虑的和否决的可替决策以及做出这些选择的理据。组织和项目宜建立决策记录和共享的策略以及重要决策的选取准则，以在AD中有理据地进行记录和支撑。要考虑选取准则的决策其中包括：——关于架构上重大需求的；——需要投入大量精力或时间来制定、实施或执行的；——影响关键利益相关方或许多利益相关方的；——处理基本关注点（如性能、可进化性、安全性等）的；——需经复杂或非显性推理的；——对变化高度敏感的；——对变化极可能代价高昂的；——形成项目规划和管理（如工作分解结构创建、关键链识别和管理质量门跟踪）基础的；——导致假设换成已知信息的；——导致重大资金支出或间接成本的；——与需求符合性有联系的；——与技术标准选取有联系的；——与系统漏洞缓解相关的。在记录决策时宜考虑包含以下信息：——决策的唯一标识；——决策的清晰陈述；——决策机构或所有方的标识；——影响决策之约束和假设的标识；——决策与所涉及实体之关注点或方面的联系；——决策与受该决策影响之AD元素的联系；——与决策理据的联系；——与其他决策的关系；——决策（与其他决策有关）后果的记录；——决策发生、批准和修改的时间戳；——附加信息的来源引文。注3：有时对否决的可替决策及其否决理据进行记录是有用的，例如当未来所述理据不再适用而所述决策成为必要决策之间的关系能通过对应或应用对应方法进行捕获。6.10.2理据记录AD宜包含或引用对选用每个架构视角（见6.6）的理据。AD宜包含或引用对选用每个ADF和每个ADL的理据。GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022AD应包含或引用每个架构决策（见6.10.1）的理据。AD宜包含或引用对选取可替决策的考虑佐证和理据。AD宜包含对AD限度（例如资源问题、时机问题以及在其他AD已覆盖、众所周知的描述上所免除的工作）的理据。7架构描述框架与架构描述语言7.1架构描述框架规格说明7.1.1ADF（3.5）应包含或引用：a)对ADF及其预期适用范围的识别信息；b)组织和/或项目所规定的ADF版本标识；c)一个或多个典型利益相关方（见6.2d)典型利益相关方持有的一个或多个典型关注点（见6.4）；e)构造典型关注点的一个或多个架构视角（见8.1）。7.1.2ADF宜在预期用于相符AD时规定：a)一个或多个利益相关方角度（见6.3）；b)一个或多个方面（见6.5）；c)对视角进行组织（见5.4.2）的一个或多个结构化形式的定义；d)适用于所规定架构视角（见8.2）的一个或多个模型种类；e)适用于所规定架构视角的一个或多个图例的定义；f)能用于创建跟视角规格说明（见7.2）有关视图的ADL标识；g)对应方法（见6.9.3）；h)视图方法（见8.3）；i)组织和/或项目所规定的版本标识。预期使用范围能大幅度游走，从非常普遍的（所有行业、应用域及EoI种类，以及ADF的多目的使用到非常特殊或具体的（预期覆盖的某给定行业、应用域或EoI种类，某具体EoI，或者处于生存周期给定阶段或出于具体目的的某具体EoI，诸如此类）。此分类近似于ISO15704（见A.4.4）中定义为结构化形式的通用性维度。ADF规格说明宜包含适用性条件。ADF规格说明宜表明其跟5.2所述概念的一致性。注2：上述要求能通过元模型、框架构件对第5章所述要求的映射、文本符合第6章要求的AD在对下列概念的适用性进行识别和考虑时，遵循ADF规格说明。——ADF所识别的每个利益相关方（见6.2）；——ADF所识别的每个利益相关方角度（见6.3）；GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022——ADF所识别的每个关注点（见6.4）；——ADF所识别的每个方面（见6.5）；——ADF所规定的每个架构视角（见8.1）；——ADF所规定的每个对应方法（见6.9.3）。ADF规格说明可建立要遵循的附加规则。AD能遵循一个或多个ADF规格说明，也能不遵循任何框架规格说明。注3：对于遵循不止一个框架规格说明的AD来说，需要在每个框架规格说明所识别的利益相关方、关注点、方面、利益相关方角度、架构视角、模型种类和AD内对应ADF可具有带一个或多个结构类别的结构化形式，以提供展现架构各种元素间关系以及增进这些元素间交互分析机会的方式。示例2：结构类别包含如下架构构件：域、模型种类、角度、方面、疑问、抽象层级、关注点的主题、关注点的方注4：关于用到方面、利益相关方角度和其他结构类别的7.2架构描述语言规格说明ADL规格说明应包含或引用：a)ADL所覆盖的典型关注点（6.4）和方面（6.5）的标识；b)从ADL选取的一个或多个视图方法的标识（见8.3）；c)ADL所实现的一个或多个模型种类（见8.2），用于构造相关关注点或反映相关方面；d)ADL所实现的所有架构视角（见8.1）；e)所有对应方法（见6.9.3）；f)组织和/或项目所规定的版本标识。8架构视角和模型种类8.1架构视角规格说明架构视角规格说明应包含或引用：a)与本视角关联的所有利益相关方角度（见6.3）；b)本架构视角所构造的一个或多个关注点（见6.4）；c)与所述关注点相关的一个或多个方面（见6.5）；d)已知的典型利益相关方（见6.2），其持有该架构视角所构造（见b项）的所述关注点；e)在建造视图时使用的模型种类和图例（见8.2）；f)对结果视图及其视图组件（见6.8）内的关系进行捕获的对应方法；g)本视角所有相关信息来源的引文。架构视角规格说明宜识别：对由关联架构视角支配的视图进行创建、解读或分析所用的视图方法（见8.3）；以及一个或多个模型种类（见8.2）。每个图例应向用户提供该图例所载视图组件的解读指引。架构视角规格说明能使用对应方法。架构视角规格说明能成为AD（第6章）的包含部分，成为ADF或ADL规格说明（第7章）的包含部分，或者单独使用本章的要求。GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:20228.2模型种类规格说明模型种类规格说明应包含或引用：a)构成本模型种类的约定，如语言、符号或建模技术的定义等；b)与本模型种类关联的所有视图方法（见8.3）和对应方法；c)组织和/或项目所规定的所有版本标识；d)本模型种类的所有相关信息来源。注：a）项能通过如元模型、语法或模板等多种方式满足，这样，模型种类规格说明对结构和结构模型的解读进行8.3视图方法架构视角规格说明可包含一个或多个视图方法。在有必要给出视图如何建造或使用的指引时，应在模型种类规格说明（8.2）、视角规格说明（8.ADL规格说明（7.2）和ADF规格说明（7.1）中对视图方法进行定义。若在创建视图时用某模型作为信息源，则视图方法宜定义：如何在视图组件中对AD元素进行描画；如何对模型数据进行转换或翻译，以用于视图组件中；以及如何在视图组件中对不同源信息之间的关系进行描画。若在创建视图时用某“非模型”作为信息源，则视图方法宜定义：如何在视图组件中将其内容描画为AD元素；如何对非模型相关数据进行转换或翻译，以用于视图组件中；以及如何在视图组件中对不同源信息之间的关系进行描画。GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022（资料性）术语和概念注解A.1概述本附录讨论本文件所依据的原则、概念和术语。图A.1描绘AD的主要概念。图A.1架构描述的概念模型本文件使用几个术语（架构、关注点、方面、利益相关方角度、架构视图、架构视角、视图组件、模型种类），这些术语在整个群体中广泛使用，具有不同的含义。本附录讨论了这些术语及其在本文件中定义的动机，并将这些定义与其他用法进行了对比。本文件定义了AD的最低要求，以支持第1章中确定的范围。该方法允许组织在应用标准时有最大的灵活性，同时证明符合第6、7和8章中的要求。鉴于架构化的多学科性质，其目的是满足多个利益相关方的需求，并允许用不同的方式来描述EoI的架构。将AD组织到由架构视角支配的架构视图中，提供了一种基于利益相关方的关注点分离机制，同时提供了整个实体的集成视图，该实体是架构概念的基础。GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022建立符合AD所描述的架构的质量（这是一个好的架构吗？）或者AD本身的质量（这个AD是否完整一致？）是评估AD的因素。本文件不假定施加质量考虑所需的条件。但确实建议对此类评估的结果进行记录（见6.2）。注：架构评估是ISO/IEC/IEEE42030的主题。A.2实体及其架构在本文件中，术语“架构”旨在表达EoI的本质或基础。本文件中架构（3.2）的定义有几个关键方面。这个定义被选择是为了通过识别这些关键方面潜在的共同主题，来涵盖术语“架构”的各种先前用法。其中最主要的是需要理解和控制在EoI环境中有助于该EoI效用、成本、时间和风险的EoI元素。在某些情况下，基本元素是实体的物理或结构组件及其关系。有时，基本元素是功能或逻辑元素。在其他情况下，对理解一个实体而言，其根本或必要的是它的总体原则或模式。属性也能是实体、其元素及其关系的基本特征。本文中架构的定义意在涵盖这些不同但相关的用途，同时鼓励对实体架构的构成进行更严格的界定。在架构的定义（3.2）中使用短语“概念或属性”，以允许两种不同的理念无偏见地使用本文件。这两种理念是：——架构作为概念：其中架构是人们头脑中实体的概念；——架构作为属性：其中架构是EoI的属性或特性。实证研究发现，组织中存在四种架构隐喻：——架构作为蓝图；——架构作为文献；——架构作为语言；——架构作为决策。本文件的基本概念并不假定这些隐喻中的任何一种；相反，它与它们中的任何一种都同样适用。这些多重隐喻的存在支持了本文件的核心设计原则：架构本质上是基于具有多重关注点和使用多重视角与方面的多个利益相关方。A.3关注点本文件使用术语“关注点”来表示与正在架构化的实体或架构本身相关的任何所关注的主题。该主题的利益相关方，包括架构师持有这些关注点。一些关注点驱动或与架构相关，因此本文件要求将它们标识为AD的一部分。关注点涉及广泛的利益（包括技术、个人、发展、科技、商业、运营、组织、政治经济、法律、监管、生态、社会影响）。使用这个术语的动机来自EdsgerW.Dijkstra在软件和系统工程中创造的短语“关注点分离”：“让我试着向你解释一下，在我看来，什么是所有智慧思维的特征。那就是，一个人愿意为了其自身的一致性而孤立地深入研究他的主题的一个方面，并始终知道自己只专注于其中的一个方面。我们知道一个程序必须是正确的，我们只能从这个视角来研究它；我们也知道它应该是高效的，我们能改天再研究它的效率。在另一种情况下，我们可能会问自己，这个项目是否值得，如果值得，为什么值得。但相反，同时解决这些不同的方面并不会带来任何好处。这就是我有时称之为“关注点分离”的方法，即使不完全可能，这也是我所知道的有效整理思想的唯一方法。这就是我所说的“将一个人的注意力集中在某个方面”：这并不意味着忽略其他方面，这只是公正地对待这样一个事实，即从这个方面的角度来看，其他方面是不相关的。它是同时具有一种或多种思维”。正如本文件中所述，每个架构视角构造了一个或多个关注点（见6.6），以便从该架构视角的应用中产生的视图，解决了EoI已识别的关注点。通过视图分离关注点的处理，允许利益相关方关注他们特GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022别关注的问题，并提供了一种组织和管理AD复杂性的方法（见6.7）。企业、系统和软件工程的文献记录了大量这类关注点。5.2.3中给出了示例。A.4方面和视角A.4.1概述一直以来，架构化工作是由利益相关方的关注点所驱动的。然而，ADF（以及少数情况下是ADL）的出现，建立了借鉴先前架构化经验的实践，这些实践导致架构化工作的条理化。这些架构化工作不一定是由特定于所讨论的架构化工作的关注点驱动的，而是很大程度上受先前经验驱动。在利用ADF驱动的方法首次构建架构视图之后，这种借鉴先前经验的架构化方法能够识别特定的关注点。这种先前经验通常被封装在基于网格的ADL中，通常是二维的，但有时是三维或更多维的。虽然这些实践中并没有统一各个行和列包括什么，但是普遍存在至少两个正交基。其中一个维度是“方面”。架构师不必同时处理所有方面，甚至也不必处理所有可能的方面，而是倾向于根据架构化目标、先前的经验和所应用的任何方法，以特定的顺序（适当地迭代）处理它们。对特定的架构化工作而言，某些方面可能并不重要（例如，因为它们与对所关注架构或其架构种类无关，或者因为它们不是特定架构的驱动因素）。另一个维度“利益相关方角度”也是基本的并且捕获架构师所有工作，即在例如关注点、先前经验或方法等驱动下，采用不同的方式对实体或其架构进行思考。利益相关方角度更多地由架构化思想和方法驱动。方面更多的是由AD中需要或可需要涵盖的内容驱动的。关注点形成了一个或多个方面和一个或多个利益相关方角度的某种组合（并且能通过这种组合来解决和映射关注点）。方面和利益相关方角度的使用与更有组织性、更规范（更标准化）的架构化和AD方法兼容。值得注意的是，在特定域或状况中，一些架构问题能是直接利益相关方的关注点。在这种情况下，这类架构问题通常通过利益相关方角度的机制来解决。在其他情况下，它们是能通过方面的机制来处理。这种差异导致常用的ADF中所用材料的组织发生变化。A.4.2方面方面提供了一种划分架构的方法，以支持对架构的基本概念（如结构和属性）进行更系统的检查，以及对架构备选方案的评估。本文件使用术语“方面”作为AD中视图的组织基础（见6.5）。方面、关注点和利益相关方角度将视图集中于AD中所关注的内聚集合上。方面、关注点和利益相关方角度能为捕获与架构相关的许多架构考虑点提供基础。方面与技术架构化专业保持一致，这些专业获取相关的架构信息，以便能够分析、综合、评估、阐述其特定方面，并反过来增加（即开发、修饰、阐述、增强信心等）架构信息。涉及相关专业的人员通常包括，例如系统架构师和分析师、安全架构师、可靠性工程师、人因工程专家、组织人力专家和成本预算人员。方面对于任何特定的关注点都是中立的，尽管这些关注点能映射到许多相关的方面。通过检查AD的各个方面，能辨别或预测实体的某些相关特征或属性。GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022方面通常反映域知识，并来自于工程师和架构师的经验。它们也来自ADF，这些ADF已经发现某些方面对该框架作用域进行架构化是有用的。这些方面也包含在架构师所学习的方法中，并封装在一些建模工具中。关注点将直接应用于与EoI或架构相关的或重要的内容，而方面是架构实体本身的特征或本质的一部分。将“利益相关方关注点”作为创建架构视图的起点假设，这些假设是已知利益相关方是谁以及他们的关注点可能是什么。但在许多复杂的实体中，这是不可行的。因为，在为被认为与域相关和惯用的方面创建架构视图之前，一些利益相关方通常是不知道的。当向潜在的利益相关方展示这些视图时，他们可能会向我们透露他们对隐含的架构解决方案的关注点（如果有的话）。作为利益相关方的架构师，其关注点通常与方面不同，因为他们在范围上没有那么广泛，在形式上也没有那么结构化。通常，当这些关注点应用于特定的应用域时，它们能随着时间的推移以及随后的审查和整合，被编入各个方面。方面能用于检查实体，从而更全面地了解架构如何处理该关注点。方面同样能帮助理解架构在多大程度上没有处理这个关注点。关注点和方面之间的关系能用这些例子来说明：我们能针对多个关注点分析诸如实体的行为（作为一个方面），如：可移植性、性能等；或者能通过对例如行为、结构和组织等方面的分析来评估诸如安全性之类的关注点。在评估备选架构时，方面也很有用（见ISO/IEC/IEEE42030）。方面的概念已经在软件开发中被用来处理“横切关注点”。方面是程序许多部分共享的一个特征，与程序的主要功能无关。非功能属性，如性能、成本和质量因素（如可靠性、保密性和弹性)是使用方面概念进行结构化的关注点（5.2.5)。这些非功能属性通常被称为“功能”或“非功能需求（NFR)”。A.4.3利益相关方角度本文件使用术语“利益相关方角度”来表示对实体的一种特殊的思考方式，特别是受个人信念或经验影响的方式。一个人对实体的思考方式（即一个人的角度）会受到组织角色、培训、经验、知识、个性、性格特征、文化、同行压力等的影响。在进行架构化时，通常会采用不同的的架构思考方式（见5.2.4中的示例）。示例：UAF：战略、运营、服务、人员、资源、安全、项目、标）：利益相关方角度的确定取决于与架构相关的各种利益相关方的关注和立场。对于给定的利益相关方角度，通常有多个关注点和方面需要考虑。A.4.4结构化形式和结构类别ADF能提供一种结构化的形式，即使用架构考虑点和它们之间的对应的一组规则，来组织用于生成关联视图的架构视角，例如网格框架形式。结构化形式的目的是提供表示架构的各种元素之间关系的方法，并增加分析这些元素之间相互作用的机会。GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022在本文件中，框架维度的概念被称为“结构类别”，因为这些类别在各种ADF中的使用方式并不总是与“维度”的概念一致。因此，这里使用结构类别术语，因为它是一个更广泛和更具包容性的概念。ADF能定义结构化形式中使用的结构类别。有时，这些类别由图形描述中的“维度”来表示，例如在多个框架中使用的行和列。网格形式的结构化形式通常具有两个框架维度，但是结构化形式能具有单个框架维度，这通常在多层层次结构中划分，或者具有多个框架维度，其中三个以上的框架维度的视觉表示是困难的。结构类别（即“维度”）能包括诸如域、模型种类、角度、方面、疑问词、抽象层级、关注点的主题、关注的方面、阶段、层、架构级等。一些常用的ADF有一个二维网格或矩阵来组织它们的架构视角规格说明。二维网格起源于Zachman。（现在还有许多其他形式，如立方体、星形、五边形和椭圆形。）这些是在那些框架上使用的结构化形式的例子。这些网格中的行是本文件中提到的角度，尽管这些行在框架中的名称会有所不同：UAF称之为“域”，ArchiMate称之为“层”，NAF称之为“关注点的主题”，ISO15704中GERAM的三个主要维度的其中两个表示抽象程度（通用性）和生存周期建模阶段。这些框架的基本思想是相同的，这个概念已经被本文件所采用。这一概念也清楚地表明，视角提供了角度。“通用性”是ISO15704中的一个关键概念方法，适用于企业对日益具体的概念表达进行建模。ISO15704定义了通用性的三个层级：通用、部分通用和专用。此通用性概念也适用于其他类型的实体和ADF概念。当接近现实世界中实体的实施水平时，就能使用越来越特定的（即较不通用）ADF来提供更多的特异性。细节ADF，例如UAF（使用UAF概要文件和伴随的SysML符号和语义），这反过来又能转换为一个特定项目的一种特定于实施的ADF，这个特定项目使用进一步的建模概要文件扩展，并包含专用域特由于质量和效率的原因，从通用、到部分通用、再到专用的转换（在ADF中提供更多域特定细节）是有用的，因为任何特定的项目都更喜欢使用针对应用领域定制的ADF（例如具有预定义的角度和方面，这些角度和方面在类似的项目中是常见的和可重用的并且之前已经经过测试（先前的成功提供了专业技术和知识），同时使用给定域专家之间共享的术语。A.4.5方面和利益相关方角度之间的关系利益相关方角度和方面密切相关，经常混淆。利益相关方角度是人们思考事物的方式，而方面能用于捕获EoI的相关特征。当从特定的角度观察和思考实体时，就会感知到与实体相关的属性或概念的某个方面。当视角转换时，属性或概念通常会有所不同。同样，当观察方面改变时，能辨别出关于实体的不同属性或概念。方面和利益相关方角度在ADF中通常用作组织架构视角的一种方式，如附录F中描述的例子所示。能为特定的方面和特定的利益相关方角度构建架构视图。利益相关方角度能代表一个或多个利益相关方的关注点的集合。当架构框架矩阵或网格使用这些概念时，列通常表示与方面相关项，行通常表示与利益相关方角度相关项。A.4.6ADF互补方法将利益相关方角度和方面结合起来，以一种基于先前经验的方式进行架构化，能作为一种不同的且互补的，由已确定的利益相关方及其具体关注点驱动的架构化方法（见5.2.3）。例如，利用在类似环GB/TXXXXX—XXXX/ISO/IEC/IEEE42010:2022境中进行相似实体的架构化先前经验，能识别出潜在的问题，当向利益相关方提出这些问题时，这些问题会引出真正的关注点。使用已知的利益相关方角度中的既定方面，能极大地帮助减少架构化工作，以获得合适的架构视角。然而，架构师需要小心谨慎，不要让这些方面和先前架构化工作的利益相关方角度掩盖了未曾表达的利益相关方关注点，也不要忽视随着架构化项目的展开而出现的关注点。方面和利益相关方角度所扮演的角色是不同的。对于一个给定的角度，通常需要考虑多个方面。当利益相关方角度改变时，所感知的属性或概念就会不同。A.5架构视图和视角术语“架构视图”和“架构视角”是本文件的核心。尽管有时作为同义词使用，但在本文件中，它们指的是独立且截然不同的概念。本文件的目标是通过提供通用术语和概念来涵盖现有的AD实践。许多现有的实践通过模型的集合来表达架构。通常，这些模型被进一步组织成内聚的组，称为视图。一组模型或其他信息的内聚性是由该组模型和其他信息源所采取的角度以及所处理的关注点和方面决定的。在本文件中，架构视角规格说明指的是根据给定的角度、一组关注点和方面来表达架构的约定：视图是从特定视角表达EoI的一种方式。使用多视图来表达一个架构是本文件的一个基本前提。AD中多视图的需求被广泛认可。虽然多视图的使用很普遍，但是作者根据受众以及表达每个视图的适当方法，对需要什么视图有不同的看法。由于意见广泛，本文件不需要一组预定义的架构视角及其规格说明；它鼓励定义或选取适合EoI架构视角的实践。使架构视角成为一级实体的一个结果是，它们属于视为AD元素的构件。本条的其余部分提供关于“视角”一词在系统和软件中的使用和演变的简要历史说明。最早对一级视角的使用出现在Ross于1977年所著的《结构化分析方法》中。在需求工程中，NKramer和Finkelstein将视角视为具有相关属性和操作的一级实体。这些研究驱使了第8章规定的架构视角的形成。选择该术语是为了与ISO开放分布式处理参考模型（RM-ODP）保持一致，并用以下方式使用该术语：——（对系统的）视角是产生与一组特定关注点相关的整个系统的规格说明的抽象概念（见ISO/IEC10746-1:1998，6.2.2）；——（对系统的）视角是使用一组选定的架构构件和结构化规则实现的抽象形式，目的是聚焦系统内的特定关注点（见ISO/IEC10746-2:2009，3.2.7）。然而，在本文件使用“架构视图”来指代将视角应用于特定