GB/T 39320-2020 电子商务 元模型 基本模块

　　ICS 35 . 240 . 60 L 79

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 39320—2020

　　电子商务 元模型 基本模块

　　Electronicbusiness—Metamodel—Foundationmodule

　　2020-1 1-19 发布 2021-06-01 实施

　　国家市场监督管理总局国家标准化管理委员会

　　发

　　布

　　GB/T 39320—2020

　　GB/T 39320—2020

　　前 言

　　本标准按照 GB/T 1 . 1—2009 给出的规则起草。

　　本标准由全国电子业务标准化技术委员会(SAC/TC 83)归口 。

　　本标准起草单位：深圳市坤鑫国际货运代理有限公司、厦门吧哒文化传播有限公司、北京九星时代科技股份有限公司、浙江义境通电子商务有限公司、新疆高新技术项 目开发研究院(有限公司)、中国标准化研究院、嘉兴市大地物流有限公司、北京中标纵横标准科技有限公司、重庆精驿行供应链管理有限公司、喀什金利达国际物流中心有限公司、和田恒扬对外贸易有限公司、图木舒克市海纳进出 口有限公司、新疆德鲁亚国际物流有限公司、大连万发联合航贸科技有限公司、伊犁通瑞达运输有限公司、公安部第三研究所、重庆电子工程职业学院、成都理邦系统工程技术有限公司。

　　本标准主要起草人：林忠、张荫芬、朱彤、林婷、姚树红、李金华、林晓炜、曹建峰、金旭峰、杨希江、蒋啸冰、康树春、陈铭、蔡依荻、钟晶、雷雨峰、朱娇杨、向国伦、潘况、罗海莹。

　　GB/T 39320—2020

　　引 言

　　联合 国 贸 易 便 利 化 与 电 子 业 务 中 心 (UN/CEFACT) 建 模 方 法 (UMM) 是 一 种 统 一 建 模 语 言(UML)建模方法，用于设计每一合作伙伴为了进行协作所应提供的业务服务，其为在面向服务的协作体系结构中付诸实施的服务提供业务理由。 因此，UN/CEFACT 首先着眼于获取业务知识，使之能够开发基于面向服务的体系结构(SOA)的低成本软件，帮助中小企业(SME)以及新兴经济体投入电子商务的实际应用。 UMM致力于开发针对组织间业务过程及其信息交换的全球性的编排设计。 UMM 模型以 UML语法表示，并且是独立于平台的模型。 独立于平台的 UMM 模型在面向服务的体系结构中辨别出需要实施业务协作的服务。 这种方法可以防止技术过时。

　　本标准的 UMM包括三个视图，每个包含一组定义明确的构件：

　　— 业务领域视图(Business Domain View )(BDV) ;

　　— 业务需求视图(Business Requirements View)(BRV) ;

　　— 业务交易视图(Business Transaction View)(BTV) 。

　　本标准的 目标在于：

　　— 定义格式良好的 UMM业务协作模型的语义;

　　— 定义符合 UMM 的业务协作模型的验证规则;

　　— 阐明符合 UMM 的业务协作模型所基于的基本概念;

　　— 为 UMM业务协作模型提供明确的定义，允许在面向服务的体系结构中进行非虚拟映射到构件;

　　— 为 UMM基础模块定义 UML概要文件，允许 UML工具供应商自定义其工具以符合 UMM。

　　GB/T 39320—2020

　　电子商务 元模型 基本模块

　　1 范围

　　本标准规定了电子商务元模型的基本模块结构以及基本模块管理、业务领域视图、业务需求视图、业务交易视图等。

　　本标准适用于开放式电子数据交换业务和电子商务领域业务建模，允许 UML 工具供应商基于本标准的 UMM基本模块建模方法定制与 UMM兼容的工具。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的。 凡是注 日期的引用文件，仅注 日期的版本适用于本文件 。凡是不注 日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

　　GB/T 18811 电子商务基本术语

　　3 术语、定义和缩略语

　　3 . 1 术语和定义

　　GB/T 18811 界定的术语和定义适用于本文件。

　　3 . 2 缩略语

　　下列缩略语适用于本文件。

　　BCV：业务编排视图(Business Choreography View)

　　BEV：业务实体视图(Business Entity View)

　　BDV：业务领域视图(Business Domain View)

　　BIV：业务交互视图(Business Interaction View)

　　BPV：业务过程视图(Business Process View)

　　BRV：业务需求视图(Business Requirements View)

　　BTV：业务交易视图 ( Business Transaction View)

　　OCL：对象约束语言 (Object Constraint Language)

　　UML：统一建模语言 (Unified Modeling Language)

　　UMM：联合国贸易便利化与电子业务中心建模方法 (UN/CEFACT Modeling Methodology)

　　4 UMM 元模型和基本模块

　　4 . 1 UMM 元模型

　　电子商务建模方法采用 UN/CEFACT 给出的方法。 UMM 元模型可分为一组元模块。 UMM 元

　　模型按 核心、基本 功 能 到完 整 功 能 的层 次分成基 础模块 ( Base Module)、基本模块 ( Foundation Module)、专用模块(Specialization Module)和扩展模块(Extension Module) ,见图 1。

　　GB/T 39320—2020

　　图 1 UMM 元模型的模块结构

　　基础模块(Base Module)：所有其他高层模块共同适用的基本准则。

　　基本模块(Foundation Module)：定义了构建符合 UMM 规则的业务协作模型的最基本方法论的所

　　有概念。

　　专用模块(Specialization Module)：定义了基本模块之上附加的专业化限定概念。每一专用模块都

　　聚焦于特定领域的专业类型分析对基本模块进行扩充。 专用模块可以作为未来候选的基本模块。

　　扩展模块(Extension Module)：扩展模块与专用模块类似，但专用模块由 UN/CEFACT 开发和维

　　护，扩展模块则可由其他机构基于 UMM 方法增加新特性创建并维护。

　　本标准所定义的 UML概要文件以 UML元模型版本 1 . 4 . 2 为基础，UMM 的基本概念及相互关联方式通过元模型描述和解释。 本标准中 OCL(对象约束语言)约束规定的 UMM 语义验证将使用外部验证服务或定制插件。 可以将基本模块扩展为不同的专业模块和扩展模块，以便在 UMM 业务协作模型所需的最小语义之上定义附加语义。

　　4 . 2 元模型的基本模块结构

　　4 . 2 中定义了 UMM元模型的基本模块的 UML概要文件。 图 2 中显示 UMM 元模型基本模块的程序包结构，不同部分定义了相应程序包的构造型、标签定义和约束。

　　GB/T 39320—2020

　　图 2 UMM 元模型基本模块程序包结构图

　　基本模块第一级程序包包含 UMM 三种视图：业务领域视图(BusinessDomainView)(5.2)、业务需求视图(BusinessRequirementsView)(5.3)和业务交易视图(BusinessTransactionView)(5.4)。

　　业务领域视图(BusinessDomainView)(5.2)不包含不同类型的构件，不再分为子程序包。

　　业务需求视图(BusinessRequirementsView) (5.3)包含三种不同类型的构件：业务过程活动图、业务实体生命周期和用例中定义的协作需求，对应的子程序包为业务过程视图(BusinessProcessView)(5.3.2)、业务实体视图(BusinessEntityView)(5.3.3)和伙伴关系需求视图(PartnershipRequirementsView)(5.3.4)。

　　业务交易视图(BusinessTransactionView)(5 . 4 )包含三个构件：业务协作的流程、用于同步状态的业务交互流程，交互过程中交换的业务信息，对应的子程序包为业务编排视图(BusinessChoreography- View)(5.4.2)、业务交互视图(BusinessInteractionView)(5.4.3)和业务信息视图(BusinessInformation-

　　View)( 5 . 4 . 4 ) 。

　　4 . 3 基本模块与元模型其他部分的依赖性(规范性)

　　4 . 3 . 1 UMM基本模块 1 . 0 基于 UMM基础模块 1 . 0 建立，见图 3 。

　　图 3 UMM 基本模块的依赖性

　　4 . 3 . 2 图 4 为 UMM 基础模块所定义并用于基本模块的构造型。 基础模块的构造型均以灰色背景显

　　示。UMM基础模块 1.0 规定了注册对象(RegistryObject)和业务库包(BusinessLibraryPackage)的构

　　GB/T 39320—2020

　　造型形式。 基本模块中，程序包是实现主要 UMM 构件的构造型容器，被定义为基础构造型业务库包的专用构造型，该程序包及其内容可以作为注册的候选。

　　图 4 UMM 基础模块抽象语法

　　5 UMM 基本模块

　　5 . 1 基本模块管理

　　5 . 1 . 1 概念性描述(资料性)

　　基于 UMM方法构建的业务协作模型，将作为构造型业务协作模型(BusinessCollaborationModel) 。对于业务协作模型，业务领域视图是可选项，业务需求视图和业务交易视图是必选项。 因此，业务协作模型( BusinessCollaborationModel)可由零或一个业务领域视图(BusinessDomainView)构成，同时业务协作模型

　　(BusinessCollaborationModel)还应包括一个业务需求视图(BusinessRequirementsView),或一个业务交易视

　　图(BusinessTransactionView ) 。

　　UMM基础模块管理概念框架，见图 5 。

　　GB/T 39320—2020

　　图 5 UMM 基础模块管理概念框架

　　5 . 1 . 2 构造型和标签定义(规范性)

　　5 . 1 . 2 . 1 UMM基本模块管理抽象语法，见图 6 。

　　图 6 UMM 基本模块管理抽象语法

　　5 . 1 . 2 . 2 构造型和标签定义-业务协作模型，见表 1 。

　　GB/T 39320—2020

　　表 1 构造型和标签定义-业务协作模型

　　5 . 1 . 2 . 3 构造型和标签定义-业务领域视图，见表 2 。

　　表 2 构造型和标签定义-业务领域视图

　　5 . 1 . 2 . 4 构造型和标签定义-业务需求视图，见表 3 。

　　GB/T 39320—2020

　　表 3 构造型和标签定义-业务需求视图

　　5 . 1 . 2 . 5 构造型和标签定义-业务交易视图，见表 4 。

　　表 4 构造型和标签定义-业务交易视图

　　5 . 1 . 3 约束(规范性)

　　5 . 1 . 3 . 1 业务协作模型(BusinessCollaborationModel)可包含零或一个业务领域视图(BusinessDomain- View)程序包。

　　示例：

　　5. 1 .3.2 业务协作模型 (BusinessCollaborationModel) 应包含一个业务需求视图 (BusinessRequire- mentsView)程序包。

　　GB/T 39320—2020示例：

　　5 . 1 . 3 . 3 业务协作模型(BusinessCollaborationModel)应包含一个业务交易视图(BusinessTransaction-

　　View)程序包。

　　示例：

　　5. 1 .3.4 业务领域视图(BusinessDomainView)、业务需求视图(BusinessRequirementsView)和业务交

　　易视图 ( BusinessTransactionView) 应直接位于业务协作模型 ( BusinessCollaborationModel) 根 目 录下方。

　　示例：

　　5 . 1 .4 用于 UMM 基本模块管理的 OCL方法(规范性)

　　OCL方法，参见示例。

　　示例：

　　GB/T 39320—2020

　　5 . 2 业务领域视图

　　5 . 2 . 1 概念性描述(资料性)

　　5 . 2 . 1 . 1 业务领域视图用于发现一个项 目 中相关的业务过程。 业务过程至少由一个(或多个)业务伙伴类型执行。一个业务伙伴类型可执行多个业务过程。业务伙伴类型 (BusinessPartnerType)和业务过程(BusinessProcess)之间的参与(participates)关联为(1..n)至(0..n)的关联。业务伙伴类型 (Business- PartnerType)是利益相关方(Stakeholder)的专用构造型。业务过程(BusinessProcess)和利益相关方 (Stakeholder)之间的关系以 UMM 中的利益关联(isOfInterestTo)依赖关系来描述。一个业务过程可使用包含(include)和扩展(extends)两个关联构造型分解为子过程，通过(0..1)至(0.. *)来表示业务过程(BusinessProcess)的构成 。

　　5 .2 . 1 .2 业务过程应先分类为业务类别，业务领域视图(BusinessDomainView)由一个或多个(1..n) 业务类别(BusinessCategories)构成，业务类别可具有层级关系，进一步由其他业务类别组成，因此业务类别(BusinessCategory)的构成应为(0..1) 至 (0..n)。业务类别层级中最低层的业务类别包含一个或多个业务过程，最高层的业务类别不包含任何业务过程。业务类别(BusinessCategory)和业务过程(Busi- nessProcess)之间的组合为 1 至(0..n) 。

　　5.2. 1 .3 业务类别(BusinessCategory)的专用构造型为业务域(BusinessArea)和过程域(ProcessArea)。业务域对应于组织中的业务部门，过程域对应于业务域内的一组通用操作。 业务域和过程域也可有多个层级。 业务域层级中除了最底层之外各层级业务域都仅包含业务域，但最底层业务域则由一个或多个过程域构成。 业务域(BusinessArea)和过程域(ProcessArea)之间组合由( 0 . . 1 )至(0..n)表示。 业务域不能包含业务过程。 过程域层级中最底层包含一个或多个业务过程。 较高层级中的过程域不包含任何业务过程。 过程域(ProcessArea)和业务过程(BusinessProcess)之间的组合为 1 至(0..n) 。 一个构造型业务类别(BusinessCategory)和构造型过程域(ProcessArea)与业务域(BusinessArea)的组合之间可替代，但 UMM模型不能同时使用业务类别(BusinessCategory)和后两者的组合。

　　5 . 2 . 1 . 4 业务领域视图(BusinessDomainView)概念框架，见图 7 。

　　GB/T 39320—2020

　　图 7 业务领域视图概念框架

　　5 . 2 . 2 构造型和标签定义(规范性)

　　5 . 2 . 2 . 1 业务领域视图(BusinessDomainView)抽象语法，见图 8 。

　　图 8 业务领域视图抽象语法

　　GB/T 39320—2020

　　5 . 2 . 2 . 2 构造型和标签定义-业务类别，见表 5 。

　　表 5 构造型和标签定义-业务类别

　　5 . 2 . 2 . 3 构造型和标签定义-业务域，见表 6 。

　　表 6 构造型和标签定义-业务域

　　GB/T 39320—2020

　　表 6(续)

　　5 . 2 . 2 . 4 构造型和标签定义-过程域，见表 7 。

　　表 7 构造型和标签定义-过程域

　　5 . 2 . 2 . 5 构造型和标签定义-利益相关方，见表 8 。

　　GB/T 39320—2020

　　表 8 构造型和标签定义-利益相关方

　　5 . 2 . 2 . 6 构造型和标签定义-业务伙伴类型，见表 9 。

　　表 9 构造型和标签定义-业务伙伴类型

　　5 . 2 . 2 . 7 构造型和标签定义-业务过程，见表 10 。

　　表 10 构造型和标签定义-业务过程

　　GB/T 39320—2020

　　表 10(续)

　　5 . 2 . 2 . 8 构造型和标签定义-参与，见表 11 。

　　表 1 1 构造型和标签定义-参与

　　GB/T 39320—2020

　　表 1 1(续)

　　5 . 2 . 2 . 9 构造型和标签定义-利益关联，见表 12 。

　　表 12 构造型和标签定义-利益关联

　　5 . 2 . 3 约束(规范性)

　　5.2.3. 1 业务领域视图(BusinessDomainView)程序包应包含至少一个业务类别(BusinessCategory)程序包或至少一个业务域(BusinessArea)程序包。此外，业务领域视图(BusinessDomainView)可包含利益相关方(Stakeholders) 和业务伙伴类型(BusinessPartnerTypes)。业务领域视图 (BusinessDomain- View)不应包含业务类别(BusinessCategory)和业务域(BusinessArea)程序包的组合。

　　示例：

　　5.2.3.2 业务域(BusinessArea)程序包应包含一个或多个业务域(BusinessArea)程序包，或者一个或多个过程域(ProcessArea)程序包，不应包含业务域(BusinessArea)和过程域(ProcessArea)程序包组合。但可包含业务伙伴类型(BusinessPartnerTypes)和利益相关方(Stakeholders)。

　　GB/T 39320—2020示例：

　　5.2.3.3 过程域(ProcessArea)或包含一个或多个其他过程域(ProcessAreas)以及零或多个业务伙伴类型 ( BusinessPartnerTypes ) 和 利 益 相 关 方 ( Stakeholders ) , 或 应 包 含 至 少 一 个 业 务 过 程(BusinessProcess)和可包含业务伙伴类型(BusinessPartnerTypes)、利益相关方(Stakeholders)、构造型关联参与(participates) ,以及构造型依赖性利益相关方(isOfInterestTo)。

　　示例：

　　5.2.3.4 业务类别(BusinessCategory)或包含一个或多个其他业务类别(BusinessCategories)以及零或多个业务伙伴类型(BusinessPartnerTypes)和利益相关方(Stakeholders) ,或者应包含至少一个业务过程(BusinessProcess)和可包含业务伙伴类型(BusinessPartnerTypes)、利益相关方(Stakeholders)、构造型关联参与(participates) ,以及构造型依赖性利益相关方(isOfInterestTo)。

　　示例：

　　5.2.3.5 作为业务类别(BusinessCategory)[或其专用构造型过程域(ProcessArea)]一部分的参与(par- ticipates)关联应始终连接业务伙伴类型 (BusinessPartnerType)和业务过程(BusinessProcess)。

　　GB/T 39320—2020

　　示例：

　　5.2.3.6 利益相关方(isOfInterestTo)的依赖性(dependency)应从业务过程(BusinessProcess) 向利益相关方(Stakeholder)而建立。

　　示例：

　　5 . 2 . 4 实例(资料性)

　　业务领域视图(BusinessDomainView)实例：协商(报价单)，见图 9 。

　　图 9 业务领域视图实例：协商(报价单)

　　GB/T 39320—2020

　　5 .2 .5 BDV所有程序包中使用的 OCL方法(规范性)

　　OCL方法，参见示例。

　　示例：

　　GB/T 39320—2020

　　5 . 3 业务需求视图

　　5 . 3 . 1 需求视图中的子视图

　　5 . 3 . 1 . 1 概念性描述(资料性)

　　5 . 3 . 1 . 1 . 1 业务需求视图用于确定不同业务伙伴类型间的协作业务过程并描述其需求，业务需求视图(BusinessRequirementsView)程序包包含三个不同构件，其中：

　　— 业务过程视图描述业务领域视图内发现的业务过程的活动流和状态，虽然业务过程视图不是必备项，但业务需求视 图可 以 由多个业务过程视 图组成。因此业务需求视 图 ( Business- RequirementsView)包含零或多个业务过程视图(BusinessProcessView)。

　　— 业务实体视图描述协作业务过程中操作的业务实体生命周期，同样地，业务实体视图也是可选择项可以重复。所以业务需求视图(BusinessRequirementsView)包含零或多个业务实体视图(BusinessEntityView)。

　　— 业务需求视图包含伙伴关系需求视图，伙伴关系需求视图描述业务伙伴类型中的合作伙伴需求，最底层不可再分的伙伴关系是业务交易。 业务协作是由业务交易和/或其他业务协作建立的伙伴关系。 交易需求视图描述业务交易需求，协作需求视图描述业务协作需求。 相同业务协作可由一组不同业务伙伴类型执行。 协作实现视图描述一组特定业务伙伴类型实现业务协作用例的需求。伙伴关系需求视图(PartnershipRequirementsView)是一个抽象概念，通过交易需求视图(TransactionRequirementsView)、协作需求视图(CollaborationRequirementsView)或协作实现视图(CollaborationRealizationView)实现。业务需求视图至少描述一个业务协作，业务协作包含至少一个业务交易，并由一组业务伙伴类型执行。因此，业务需求视图(BusinessRequirements- View)包含一到多个协作需求视图(CollaborationRequirementsView),一个或多个交易需求视图 (TransactionRequirementsView),一个或多个协作实现视图(CollaborationRealizationView)。

　　GB/T 39320—2020

　　5.3. 1 . 1 .2 业务需求(BusinessRequirements)视图概念框架，见图 10。

　　图 10 业务需求视图概念框架

　　5 . 3 . 1 . 2 构造型和标签定义(规范性)

　　5.3. 1 .2. 1 业务需求视图(BusinessRequirementsView)抽象语法 ，见图 11。

　　图 1 1 业务需求视图抽象语法

　　5 . 3 . 1 . 2 . 2 造型和标签定义-业务过程视图，见表 13 。

　　GB/T 39320—2020

　　表 13 构造型和标签定义-业务过程视图

　　5 . 3 . 1 . 2 . 3 构造型和标签定义-业务实体视图，见表 14 。

　　表 14 构造型和标签定义-业务实体视图

　　5 . 3 . 1 . 2 . 4 构造型和标签定义-伙伴关系需求视图(抽象)，见表 15 。

　　表 15 构造型和标签定义-伙伴关系需求视图(抽象)

　　GB/T 39320—2020

　　表 15(续)

　　5 . 3 . 1 . 2 . 5 构造型和标签定义-协作需求视图，见表 16 。

　　表 16 构造型和标签定义-协作需求视图

　　5 . 3 . 1 . 2 . 6 构造型和标签定义-交易需求视图，见表 17 。

　　表 17 构造型和标签定义-交易需求视图

　　GB/T 39320—2020

　　5 . 3 . 1 . 2 . 7 构造型和标签定义-协作实现视图，见表 18 。

　　表 18 构造型和标签定义-协作实现视图

　　5 . 3 . 1 . 3 约束(规范性)

　　业务需求视图(BusinessRequirementsView)应至少包含一个协作需求视图(CollaborationRequire- mentsView)程序包，至少包含一个交易需求视图(TransactionRequirementsView)程序包，至少包含一个协作实现视图(TransactionRequirementsView)。此外，可包含业务过程视图(BusinessProcessView)程序包和业务实体视图(BusinessEntityView)程序包。除此之外，不应包含任何其他元素。

　　示例：

　　5 . 3 . 2 业务过程视图

　　5 . 3 . 2 . 1 概念性描述(资料性)

　　5 . 3 . 2 . 1 . 1 业务过程视图描述了业务过程、业务过程活动和执行活动的业务伙伴类型。 业务过程视图(BusinessProcessView)由一个或多个业务过程(BusinessProcess)构成，一个业务过程可能包含其他业务过程或是其他业务过程的扩展。

　　5.3.2. 1 .2 业务过程活动模型(BusinessProcessActivityModel) 表示业务过程的动态行为，业务过程(BusinessProcess)中包含零或一个业务过程活动模型(BusinessProcessActivityModel)。业务过程活动

　　GB/T 39320—2020

　　模型描述了由一个或多个参与方实施的活动流。 涉及两个以上的业务伙伴类型协作的业务过程活动模

　　型将分区。一个业务过程活动模型(BusinessProcessActivityModel) 中包含零或多个分区(Partitions)

　　(UML共享元素)，一个分区指定给一个业务伙伴类型。 一个业务伙伴类型可对应于处于不同活动模

　　型中的多个分区，业务伙伴类型 (BusinessPartnerType)和分区(Partitions)之间以 1 至(0..n)的关联来

　　表示。

　　5 . 3 . 2 . 1 . 3 有多个分区的，一个业务过程活动将被分配给执行该活动的业务伙伴类型所处的分区。 只要通过分区连接两种业务过程活动，就需要协作业务过程。一个业务过程活动模型(BusinessProces- sActivityModel)是由一个或多个业务过程活动(BusinessProcessActivity)构成，或作为业务过程活动模型一部分的一个分区由一个或多个业务过程活动(BusinessProcessActivity)构成。一个业务过程活动可通过另一个业务过程活动模型细化。一项业务过程活动(BusinessProcessActivity)中包含零或含有一个业务过程活动模型 (BusinessProcessActivityModel) , 反之是零个或一个业务过程活动 ( Busi- nessProcessActivity)的组合。

　　5 . 3 . 2 . 1 . 4 一个业务过程活动模型还可表示执行业务过程期间被影响的业务实体状态。 业务实体状态是一个业务活动的输出，并输入到另一个业务活动。 一个业务过程活动到业务实体状态的转换是标志一个输出，而一个业务实体状态到业务过程活动的转换则标志一个输入。 业务过程活动模型包含内部业务实体状态和共享业务实体状态，内部实体状态只对一个业务伙伴类型有意义。 业务过程活动模型(BusinessProcessActivityModel)中包含零或多个内部业务实体状态(InternalBusinessEntityStates)或共享业务实体状态(SharedBusinessEntityStates)。倘若一个业务过程活动模型有多个分区，则创建和使用内部业务实体状态的两个业务过程活动处于同一分区，反之，创建和使用共享业务实体状态的两个业务过程活动处于不同分区，共享业务实体状态标志着协作业务过程的需求。

　　5.3.2. 1 .5 业务过程视图(业务需求视图)[BusinessProcessView(BusinessRequirementsView)]概念框架，见图 12 。

　　图 12 业务过程视图(业务需求视图)概念框架

　　GB/T 39320—2020

　　5 . 3 . 2 . 2 构造型和标签定义(规范性)

　　5.3.2.2. 1 业务过程视图(业务需求视图)[BusinessProcessView(BusinessRequirementsView)]抽象语法，见图 13 。

　　图 13 业务过程视图(业务需求视图)抽象语法

　　5 . 3 . 2 . 2 . 2 构造型和标签定义-业务过程活动模型，见表 19 。

　　表 19 构造型和标签定义-业务过程活动模型

　　5 . 3 . 2 . 2 . 3 构造型和标签定义-业务过程活动，见表 20 。

　　表 20 构造型和标签定义-业务过程活动

　　GB/T 39320—2020

　　5 . 3 . 2 . 2 . 4 构造型和标签定义-内部业务实体状态，见表 21 。

　　表 2 1 构造型和标签定义-内部业务实体状态

　　5 . 3 . 2 . 2 . 5 构造型和标签定义-共享业务实体状态，见表 22 。

　　表 22 构造型和标签定义-共享业务实体状态

　　5 . 3 . 2 . 3 约束(规范性)

　　5 . 3 . 2 . 3 . 1 业务过程视图(BusinessProcessView)应仅包含业务过程活动模型(BusinessProcessActivi- tyModel)、业务伙伴类型 (BusinessPartnerType)以及业务过程(BusinessProcesses) ,且应为空。

　　示例：

　　5.3.2.3.2 不含分区的业务过程活动模型(BusinessProcessActivityModel)应含有一个或多个业务过程活动(BusinessProcessActivity),且可含有内部业务实体状态(InternalBusinessEntityStates)、共享业务实体状态 (SharedBusinessEntityStates)、伪态 ( Pseudo states)、最终状态 ( Final states) 以及转换态

　　( Transitions) 。

　　GB/T 39320—2020

　　示例：

　　5.3.2.3.3 业务过程活动模型(BusinessProcessActivityModel)中的分区应含有一个或多个业务过程活动(BusinessProcessActivity) , 且 可 含 有 内 部 业 务 实 体 状 态 (InternalBusinessEntityStates)、伪 态

　　( Pseudo states)、最终状态(Final states)以及转换态(Transitions) 。

　　示例：

　　5 . 3 . 2 . 4 实例(资料性)

　　业务过程视图(业务需求视图)[BusinessProcessView(BusinessRequirementsView)]实例：采购产品-协作视图业务过程活动模型(活动图)[BusinessProcessActivityModel (ActivityGraph)],见图 14。

　　GB/T 39320—2020

　　图 14 业务过程视图(业务需求视图)实例：采购产品-协作视图业务过程活动模型(活动图)

　　5 . 3 . 3 业务实体视图

　　5 . 3 . 3 . 1 概念性描述(资料性)

　　5.3.3. 1 . 1 sinessEntity(业务实体)是实际应用中具有明确业务意义的实体，在协作业务过程(如“订单” “账目”等)中由两个或多个业务伙伴类型 (BusinessPartnerType)共用。业务实体视图(BusinessEnti- tyView)由一个至多个业务实体(BusinessEntity)构成。业务实体(BusinessEntity)可不包含业务实体 生命周期(BusinessEntityLifecycle) ,也可包含一个业务实体生命周期(BusinessEntityLifecycle)。业务 实体生命周期表示一个业务实体在一个完整业务过程中可以不同状态存在，业务实体生命周期(Busin- essEntityLifecycle)包含一个或多个业务实体状态(BusinessEntityState)。和其他 UML 状态机相似 ，业务实体生命周期也包含事件和状态转换触发业务实体从一个状态转换到另一个状态。

　　5.3.3. 1 .2 业务实体视图(业务需求视图)[BusinessEntityView(BusinessRequirementsView)]概念框架，见图 15 。

　　GB/T 39320—2020

　　图 15 业务实体视图(业务需求视图)概念框架

　　5 . 3 . 3 . 2 构造型和标签定义(规范性)

　　5.3.3.2. 1 业务实体视图(业务需求视图)[BusinessEntityView(BusinessRequirementsView)]抽象语法，见图 16 。

　　图 16 业务实体视图(业务需求视图)抽象语法

　　5 . 3 . 3 . 2 . 2 构造型和标签定义-业务实体，见表 23 。

　　表 23 构造型和标签定义-业务实体

　　5 . 3 . 3 . 2 . 3 构造型和标签定义-业务实体生命周期，见表 24 。

　　GB/T 39320—2020

　　表 24 构造型和标签定义-业务实体生命周期

　　5 . 3 . 3 . 2 . 4 构造型和标签定义-业务实体状态，见表 25 。

　　表 25 构造型和标签定义-业务实体状态

　　5 . 3 . 3 . 3 约束(规范性)

　　5.3.3.3. 1 业务实体视图(BusinessEntityView)应且仅包含业务实体(BusinessEntity)。示例：

　　5.3.3.3.2 业务实体(BusinessEntity)不包含或只含有一个业务实体生命周期(BusinessEntityLifecycle)来表示

　　其行为。

　　示例：

　　5.3.3.3.3 业务实体生命周期(BusinessEntityLifecycle)应且仅含有业务实体状态(BusinessEntityState)、伪态(PseudoState)、最终状态(FinalState)或转换(Transition ) 。

　　GB/T 39320—2020

　　示例：

　　5 . 3 . 3 . 4 实例(资料性)

　　5.3.3.4. 1 业务实体视图(业务需求视图)[BusinessEntityView (BusinessRequirementsView)]的实例：业务实体(BusinessEntities)报价和订单类图(ClassDiagram) ,见图 17。

　　图 17 业务实体视图(业务需求视图)实例：业务实体报价和订单(类图)

　　5.3.3.4.2 业务实体视图(业务需求视图)[BusinessEntityView (BusinessRequirementsView)]的实例：报价业务实体生命周期(状态机)[BusinessEntityLifecycle (StateMachine)],见图 18。

　　GB/T

　　39320—2020

　　图 18 业务实体视图(业务需求视图)实例：报价[业务实体生命周期(状态机)]

　　5.3.3.4.3 业务实体视图(业务需求视图)[BusinessEntityView(BusinessRequirementsView)]的实例：订单业务实体生命周期(状态机)[BusinessEntityLifecycle (StateMachine)],见图 19。

　　图 19 业务实体视图(业务需求视图)实例：订单[业务实体生命周期(状态机)]

　　GB/T 39320—2020

　　5 . 3 . 4 伙伴关系需求视图

　　5 . 3 . 4 . 1 概念性描述(资料性)

　　5 . 3 . 4 . 1 . 1 业务伙伴关系视图以用例方式描述业务伙伴类型之间已确定的协作需求，包含业务协作用例、业务交易用例以及业务协作实现。 业务交易用例用于说明交易需求，是两种授权角色之间仅限于一次发起信息交换和一个可选响应的特定交互行为。 业务协作用例描述了两个或更多授权角色之间执行的业务协作需求，由一个或多个业务交易或嵌套的业务协作构成。 业务协作用例应由一组业务伙伴类型执行。 两组不同的业务伙伴类型可能会实现相同的业务协作用例。 业务协作实现是通过一组特定业务伙伴类型实现业务协作的过程。

　　5.3.4. 1 .2 交易需求视图(TransactionRequirementsView) 仅由一个业务交易用例(BusinessTransac- tionUseCase)构成。同时，交易需求视图(TransactionRequirementsView) 仅包含两个授权角色 (Au- thorizedRole) ,这两个授权角色(AuthorizedRole)参与该业务交易用例(BusinessTransactionUseCase ),授权角色应与对应的业务交易用例在同一交易需求视图程序包中定义。假设某一角色(如卖方、收款人)参与多项业务交易，则每个业务协作用例需要该角色的不同授权角色，每个授权角色都处于对应交易需求视图中的不同命名空间。

　　每个业务交易用例(BusinessTransactionUseCase) 和每个授权角色(AuthorizedRole) 只能关联 一次，用 1 表示，每个业务交易用例(BusinessTransactionUseCase)与两个授权角色(AuthorizedRole)关联，用 2 表示。 一个业务协作用例(BusinesCollaborationUseCase) 可嵌套在多个父类业务协作用例( BusinesCollaborationUseCase)中，以对应的(0…n)和(0….n)的包含(include)关系表示嵌套与被嵌套的业务协作用例的关联。 业务协作用例可包含多个业务交易用例，业务交易用例应至少包含在一个业务协作用例中，以(1….n)和(0….n)表示业务协作用例(BusinessCollaborationUseCase)和业务交易用

　　例(BusinessTransactionUseCase)之间的聚合关联，但 UMM 不在业务协作用例和业务交易用例中使用任何扩展(extend)关联。业务协作用例至少包含一个嵌套业务协作用例或一个业务交易用例。包含关

　　系的业务协作用例的层级结构不能含有任何循环。 业务交易用例不能进一步分解。

　　5.3.4. 1 .3 对于每个包含关系的用例，应将源用例的授权角色映射至目标用例授权角色，授权角色(Au- thorizedRole)应是一一对应的映射关系，以(1..n)至(1..n)表示。每个来源用例的授权角色最多只映射一次到相同的 目标用例的授权角色，同时可映射至不同 目标用例的不同授权角色。 业务伙伴类型不直接与业务协作用例和业务交易用例相关联，而是用到业务协作实现规定一组参与协作的具体业务伙伴类型。 协作实现视图 ( CollaborationRealizationView) 中仅包含一个业务协作实现(BusinessCollabora- tionRealization) ,业务协作实现仅实现一个业务协作用例。每个业务协作用例可通过多个业务协作实现来实现，但并非每个业务协作用例(如嵌套在另一业务协作中的用例)都需要一个相应的业务协作实现，业务协作用例(BusinessCollaborationUseCase)和业务协作实现(BusinessCollaborationRealization)之间的 realize(实现)关联可表示为 1 和(0…n)。参与一个业务协作实现的两个或多个授权角色与此业务协作实现都应在同一协作实现视图程序包中定义。协作实现视图(CollaborationRealizationView)含有两个或更多授权角色(AuthorizedRole)。参与业务协作用例和业务协作实现中的授权角色(如付款人和收款人)在不同命名空间中定义，即各自相对应的视图程序包中定义。 与业务协作用例相类似，每个授权角色(AuthorizedRole)只能与业务协作实现(BusinessCollaborationRealization)关联一次，以 1表示，两个或多个授权角色(AuthorizedRole)可参与到同一个业务协作实现(BusinessCollaborationRe- alization)中，以(2…n)表示，且参与业务协作用例中的角色数量应与参与业务协作实现中的角色数量相同。

　　5 . 3 . 4 . 1 . 4 业务伙伴类型需要映射为参与业务协作实现的授权角色。 每个具体的授权角色是相应的某一业务伙伴类型映射关系唯一对应的一个目标。 一个业务伙伴类型可以对应业务协作实现中的多个授

　　GB/T 39320—2020

　　权角色，业务伙伴类型 (BusinessPartnerType)和授权角色(AuthorizedRole)之间的映射至(mapsTo)关联为(0…1)和(0…n)。

　　5.3.4. 1 . 5 伙伴关系需求视图(业务需求视图)[CollaborationRequirementsView(BusinessRequire- mentsView)]概念框架，见图 20 。

　　图 20 伙伴关系需求视图(业务需求视图)概念框架

　　5 . 3 . 4 . 2 构造型和标签定义(规范性)

　　5.3.4.2. 1 协作需求视图(业务需求视图)[CollaborationRequirementsView(BusinessRequirements- View)]抽象语法，见图 21 。

　　GB/T 39320—2020

　　图 2 1 协作需求视图(业务需求视图)抽象语法

　　5 . 3 . 4 . 2 . 2 构造型和标签定义-业务协作用例，见表 26 。

　　表 26 构造型和标签定义-业务协作用例

　　5 . 3 . 4 . 2 . 3 构造型和标签定义-业务交易用例，见表 27 。

　　GB/T 39320—2020

　　表 27 构造型和标签定义-业务交易用例

　　5 . 3 . 4 . 2 . 4 构造型和标签定义-业务协作实现，见表 28 。

　　表 28 构造型和标签定义-业务协作实现

　　5 . 3 . 4 . 2 . 5 构造型和标签定义-授权角色，见表 29 。

　　表 29 构造型和标签定义-授权角色

　　5 . 3 . 4 . 2 . 6 构造型和标签定义-映射至，见表 30 。

　　GB/T 39320—2020

　　表 30 构造型和标签定义-映射至

　　5 . 3 . 4 . 3 约束(规范性)

　　5.3.4.3. 1 协作需求视图(CollaborationRequirementsView)应且仅含有一个业务协作用例(Business- CollaborationUseCase)和至少两个授权角色(AuthorizedRoles),以及至少两个参与(participate)关联。

　　示例：

　　5.3. 4. 3. 2 交易需求视 图 (TransactionRequirementsView) 应且仅含有一个业务交 易用例 ( Busi- nessTransactionUseCase),并仅含两个授权角色(AuthorizedRole)和两个参与(participate)关联。

　　示例：

　　5 . 3 . 4 . 3 . 3 协作实现视图(CollaborationRealizationView)应且仅含有一个业务协作实现(BusinessCol- laborationRealization)、至少两个授权角色(AuthorizedRole),以及至少两个参与(participate)关联。

　　GB/T 39320—2020示例：

　　5.3.4.3.4 业务协作用例(BusinessCollaborationUseCase)应通过构造型参与(participate)关联与两个或更多的授权角色(AuthorizedRole)进行二元关联。

　　示例：

　　5.3.4.3.5 业务交易用例(BusinessTransactionUseCase)应通过构造型参与(participate)来关联，且仅与两个授权角色(AuthorizedRole)进行二元关联。

　　示例：

　　5.3.4.3.6 业务协作实现(BusinessCollaborationRealization)应通过构造型参与(participate)关联与两个或更多授权角色(AuthorizedRole)进行二元关联。

　　示例：

　　GB/T 39320—2020

　　5.3.4.3.7 业务协作实现(BusinessCollaborationRealization)应且仅是一个依赖于业务协作用例(Busi-

　　nessCollaborationUseCase)的实现的客户端 。

　　示例：

　　5.3.4.3.8 业务协作用例(BusinessCollaborationUseCase)应包含一个或多个其他业务协作用例(Busi- nessCollaborationUseCase) ,或者一个或多个业务交易用例(BusinessTransactionUseCase) ,但至少为

　　业务协作用例(BusinessCollaborationUseCase)或业务交易用例(BusinessTransactionUseCase)之一 。

　　示例：

　　5.3.4.3.9 业务交易用例(BusinessTransactionUseCase)不应包含其他用例。示例：

　　5 . 3 . 4 . 3 . 10 业务交易用例(BusinessTransactionUseCase) 应被包含在至少一个业务协作用例(Busi- nessCollaborationUseCase)中 。

　　示例：

　　5 . 3 . 4 . 3 . 1 1 业务协作用例(BusinessCollaborationUseCase)和业务交易用例(BusinessTransactionUse- Case)不应是一个扩展(extends)关联的来源或目标。

　　GB/T 39320—2020示例：

　　5 . 3 . 4 . 3 . 12 业务协作实现(BusinessCollaborationRealization)不应是一个包含(includes)关联或多个扩展(extends)关联的来源或目标。

　　示例：

　　5.3.4.3. 13 所有来自或目标为授权角色的授权角色(AuthorizedRole)依赖对象应映射至(mapsTo)其

　　依赖对象。

　　示例：

　　5 . 3 . 4 . 3 . 14 参与业务协作实现( BusinessCollaborationRealization) 的授权角色( AuthorizedRole)应且

　　仅是一个映射至(mapsTo)依赖于业务伙伴类型(BusinessPartnerType)的对象的提供方。进而，参与业务协作实现(BusinessCollaborationRealization) 的授权角色(AuthorizedRole) 应且仅是一个映射至(mapsTo)依赖于参与业务协作用例(BusinessCollaborationUseCase)的授权角色(AuthorizedRole) 的

　　对象的客户端。

　　示例：

　　GB/T 39320—2020

　　5 . 3 . 4 . 3 . 15 源业务协作用例(BusinessCollaborationUseCase)包含目标业务交易用例(BusinessTransaction- UseCase )和/或业务协作用例(BusinessCollaborationUseCase) 。 源用例的每个授权角色(AuthorizedRole) ,

　　应最多一次映射至(mapsTo)同一目标用例的授权角色(AuthorizedRole)[但可映射至(mapsTo)不同 目标用例的不同授权角色(AuthorizedRole)] 。 目标用例的每个授权角色(AuthorizedRole)是从源用例的授权角色(AuthorizedRole)所映射至(mapsTo)的对象的提供方。

　　示例：

　　5 . 3 . 4 . 3 . 16 参与业务协作用例(BusinessCollaborationUseCase)的授权角色(AuthorizedRole)数量应与实现该用例的每个业务协作实现(BusinessCollaborationRealization)的授权角色(AuthorizedRole)数量相同。

　　示例：

　　5.3. 4. 3. 17 交易需求视图 (TransactionRequirementsView)、协作需求视 图 (CollaborationRequire- mentsView)或协作实现视图(CollaborationRealizationView)中的授权角色(AuthorizedRole)应在其所

　　在的程序包内具有唯一名称。

　　示例：

　　GB/T 39320—2020

　　5 . 3 . 4 . 4 实例(资料性)

　　5.3.4.4. 1 协作需求视图(业务需求视图)[CollaborationRequirementsView(BusinessRequirements- View)]实例：报价单(用例图)[OrderFromQuote(UseCase Diagram)],见图 22。

　　图 22 协作需求视图(业务需求视图)实例：报价单(用例图)

　　5.3.4.4.2 交易需求视图(业务需求视图)[TransactionRequirementsView(BusinessRequirementsView)] 实

　　例：下订单交易(PlaceOrder Transaction ),见图 23 。

　　GB/T 39320—2020

　　图 23 交易需求视图(业务需求视图)实例：下订单交易

　　5.3.4.4.3 协作实现视图(业务需求视图)[CollaborationRealizationView(BusinessRequirementsView)]实例：采购组织和销售组织之间实现报价单(OrderFromQuote)协作，见图 24。

　　图 24 协作实现视图(业务需求视图)实例：采购组织和销售组织之间实现报价单协作

　　GB/T 39320—2020

　　5 .3 .5 所有 BRV程序包中采用的 OCL方法(规范性)

　　OCL方法，参见示例。

　　示例：

　　GB/T 39320—2020

　　GB/T 39320—2020

　　GB/T 39320—2020

　　GB/T 39320—2020

　　5 . 4 业务交易视图

　　5 . 4 . 1 交易视图概述

　　5 . 4 . 1 . 1 概念性描述(资料性)

　　5 . 4 . 1 . 1 . 1 业务交易视图、业务编排视图、业务交互视图和业务信息视图都是包含各类构件的容器。 业务交易视图程序包包含业务编排视图、业务交互视图和业务信息视图三个不同构件，共同描述信息交换的总体编排。 业务编排视图和业务交互视图分别根据 BRV 中相应的协作需求视图和交易需求视图确定可定义流程的构件，这些构件主要描述协作中动态过程，而业务信息视图处理描述协作的结构方面的构件。 业务编排视图包含的构件描述涉及业务伙伴类型之间的多个步骤的复杂业务协作。 业务交互视图包含的构件定义交互的两个业务实体之间的编排进而同步其状态。 业务信息视图包含的构件描述交互过程中信息交换。

　　5.4. 1 . 1 .2 业务交易视图(BusinessTransactionView)包含一个到多个业务编排视图(BusinessChoreog- raphyView) ,一个到多个业务交互视图 ( BusinessInteractionView) , 以及一个到多个业务信息视图( BusinessInformationView) 。

　　5 . 4 . 1 . 1 . 3 业务交易视图(BusinessTransactionView)概念框架，见图 25 。

　　图 25 业务交易视图概念框架

　　GB/T 39320—2020

　　5 . 4 . 1 . 2 构造型和标签定义(规范性)

　　5 . 4 . 1 . 2 . 1 业务交易视图(BusinessTransactionView)抽象语法，见图 26 。

　　图 26 业务交易视图抽象语法

　　5 . 4 . 1 . 2 . 2 构造型和标签定义-业务编排视图，见表 31 。

　　表 3 1 构造型和标签定义-业务编排视图

　　5 . 4 . 1 . 2 . 3 构造型和标签定义-业务交互视图，见表 32 。

　　GB/T 39320—2020

　　表 32 构造型和标签定义-业务交互视图

　　5 . 4 . 1 . 2 . 4 构造型和标签定义-业务信息视图，见表 33 。

　　表 33 构造型和标签定义-业务信息视图

　　5 . 4 . 1 . 3 约束(规范性)

　　一个业务交易视图(BusinessTransactionView)应包含至少一个业务编排视图(BusinessChoreog- raphyView)程序包、至少一个业务交互视图(BusinessInteractionView)程序包，和至少一个业务信息视图(BusinessInformationView)程序包。

　　示例：

　　GB/T 39320—2020

　　5 . 4 . 2 业务编排视图

　　5 . 4 . 2 . 1 概念性描述(资料性)

　　5.4.2. 1 . 1 业务编排只定义一个业务协作的流程，因此业务编排视图(BusinessChoreographyView)仅由某一个业务编排(BusinessChoreography)组成，业务编排通过业务编排行为定义业务协作的执行顺序，每个业务编排(BusinessChoreography)仅由一个业务编排行为(BusinessChoreographyBehavior)组成。一个业务协作用例 (BusinessCollaborationUseCase) 和业务编排行为 (BusinessChoreographyBe- havior)具有一对一的映射至(mapsTo)关系。

　　5.4.2. 1 .2 一个有效的专用构造型业务编排行为(BusinessChoreographyBehavior)被定义为业务协作协议(BusinessCollaborationProtocol) 。一个业务协作协议的活动为业务协作活动和/或业务交易活动。 一个业务协作协议(BusinessCollaborationProtocol)包含零到多个业务协作活动(BusinessCollaborationActivities)或零到多个业务交易活动(BusinessTransactionActivities) 。一个业务协作协议中应出现至少一个业务协作活动或业务交易活动。定义业务协作活动和/或业务交易活动的活动流转换可由业务实体的状态监控。

　　5 . 4 . 2 . 1 . 3 倘若一个业务协作协议嵌套于一个业务协作活动中，该业务协作活动将被此业务协作协议精确确定。一个业务协作协议可嵌套于不同的业务协作活动中。业务协作活动(BusinessCollabortion- Activity)和业务协作协议(BusinessCollaborationProtocol)之间的聚合关系为(0…n)对 1。

　　5 . 4 . 2 . 1 . 4 一个业务交易活动由业务交易来精确确定。 每个业务交易应至少有一次被用于确定业务交易活动。一个业务交易可被嵌套于不同的业务交易活动中，业务交易活动(BusinessTransactionActivity)和业务交易(BusinessTransaction)之间的聚合关系为(1…n)对 1 。

　　5.4.2. 1 .5 业务编排视图(业务交易视图)[BusinessChoreographyView(BusinessTransactionView)]概念框架，见图 27 。

　　图 27 业务编排视图(业务交易视图)概念框架

　　GB/T 39320—2020

　　5 . 4 . 2 . 2 构造型和标签定义(规范性)

　　5.4.2.2. 1 业务编排视图(业务交易视图)[BusinessChoreographyView(BusinessTransactionView)]抽象语法，见图 28 。

　　图 28 业务编排视图(业务交易视图)抽象语法

　　5 . 4 . 2 . 2 . 2 构造型和标签定义-业务编排，见表 34 。

　　表 34 构造型和标签定义-业务编排

　　5 . 4 . 2 . 2 . 3 构造型和标签定义-业务编排行为(抽象)，见表 35 。

　　表 35 构造型和标签定义-业务编排行为(抽象)

　　GB/T 39320—2020

　　5 . 4 . 2 . 2 . 4 构造型和标签定义-业务协作协议，见表 36 。

　　表 36 构造型和标签定义-业务协作协议

　　5 . 4 . 2 . 2 . 5 构造型和标签定义-业务交易活动见表 37 。

　　表 37 构造型和标签定义-业务交易活动

　　5 . 4 . 2 . 2 . 6 构造型和标签定义-业务协作活动见表 38 。

　　表 38 构造型和标签定义-业务协作活动

　　GB/T 39320—2020

　　表 38(续)

　　5 . 4 . 2 . 3 约束(规范性)

　　5.4.2.3. 1 业务编排行为(BusinessChorographyBehavior)应且仅是一个映射至(mapsTo)业务协作用例(BusinessCollaborationUseCase )的依赖对象的客户端。

　　示例：

　　5.4.2.3.2 业务编排视图(BusinessChoreographyView)程序包应且仅包含一个业务编排(BusinessCho- reography)且无其他元素。

　　示例：

　　5.4.2.3.3 一个业务编排(BusinessChoreography) 的行为应且仅由一个业务编排行为 (BusinessCho- reographyBehavior)描述。

　　示例：

　　5 . 4 . 2 . 3 . 4 一个业务协作协议(BusinessCollaborationProtocol) 应包含至少一个业务交易活动 ( Busi- nessTransactionActivity)或业务协作活动(BusinessCollaborationActivity) ,可包含伪态(PseudoState)、

　　GB/T 39320—2020

　　最终状态(FinalState)和转换(Transition) 。

　　示例：

　　5.4.2.3.5 一个业务协作活动(BusinessCollaborationActivity )应且仅由一个业务协作协议(Business- CollaborationProtocol)通过与构造型映射至(mapsTo)相关的依赖对象来精确确定。

　　示例：

　　5.4.2.3.6 一个业务交易活动(BusinessTransactionActivity)应仅由一个业务交易(BusinessTransaction)通过与构造型映射至(mapsTo)相关的依赖对象来精确确定。

　　示例：

　　5 . 4 . 2 . 4 实例(资料性)

　　业务编排视图(业务交易视图)[BusinessChoreographyView (BusinessTransactionView)]实例：报价单业务协作协议(活动图)[OrderFromQuote BusinessCollaborationProtocol (ActivityGraph)],见

　　图 29 。

　　GB/T 39320—2020

　　图 29 业务编排视图(业务交易视图)实例：报价单业务协作协议(活动图)