1、ICS 03.060 A 11 gB 中华人民主七./、和国国家标准金融服务第3GB/T 27926.3-2011 /ISO/TS 20022-3: 2004 金融业通用报文方案部分:建模导则Financial services-Universal financial industry message scheme一Part 3 : Modelling guidelines (ISO/TS 20022-3: 2004 , IDT) 2011-12-30发布2012-05-01实施数码防伪中华人民共和国国家质量监督检验检夜总局中国国家标准化管理委员会发布GB/T 27926.3-2011 /IS
2、O/TS 20022-3: 2004 目次前言.1 引言.n 1 业务分析-1. 1 简介1. 2 过程概览.1. 3 活动.21. 4 导则2 需求分析42.1 简介.4 2. 2 过程概览.4 2.3 活动52.4 导则.3 逻辑分析.63. 1 简介3.2 过程概览3.3 活动.83.4 导则4 报文设计104.1 简介.104.2 过程概览.104.3 活动:定义报文组件4.4 活动:构建报文5 技术设计.18 6 命名约定.四附录A(资料性附录)示例UA.1 业务分析:基金行业业务过程.A.2 需求分析:基金行业信息交换需求nA. 3 逻辑分析:业务交易.24 A.4 报文设计:组建
3、报文.25 GB/T 27926.3-2011 /ISO/TS 20022-3: 2004 目。吕GB/T 27926(金融服务金融业通用报文方案由以下5部分构成:第1部分:输入输出方法和格式规范;一-第2部分z注册机构的角色及职责;一一第3部分:建模导则;一一第4部分:XML设计规则;-第5部分:反向工程。本部分为GB/T27926的第3部分。本部分等同采用ISO/TS20022-3: 2004(金融服务金融业通用报文方案第3部分:ISO 20022 建模导则)(英文版)。为便于使用，本标准还做了下列编辑性修改:a) ISO 20022的本部分改为GB/T27926的本部分;b) 删除国际标
4、准前言;c) 将国际标准名称由ISO20022建模导则改为建模导则。本部分附录A为资料性附录。本部分由中国人民银行提出。本部分由全国金融标准化技术委员会CSAC/TC180)归口。本部分负责起草单位:中国金融电子化公司。本部分参加起草单位:中国人民银行、中国证券监督管理委员会、中国工商银行、中国建设银行、博时基金管理有限公司、深圳证券通信公司、申银万国证券股份有限公司、中国人民银行长春中心支行、中国人民银行南京分行。本部分主要起草人z王平娃、陆书春、李曙光、赵志兰、马小琼、贾树辉、王毛路、王德英、巫禄芳、强庆华、施轶倩、李迎辉、成永德、刘运、景芸、陈立军、程晓阳。I GB/T 27926.3-
5、2011 /ISO/TS 20022-3: 2004 引GB/T 27926的本部分描述了适用于标准化业务交易和报文集开发的方法论。标准化业务交易的目标是，针对特定的业务过程环境，为不同组织间存在的信息交换问题定义一个通用的解决方案。对于特定业务背景下的信息交换问题，可开发出多个解决方案。本部分的目的是向建模人员说明应遵循的不同步骤，以确保业务组件/元素、报文组件/元素、业务交易和报文定义的一致性。GB/T 27926建模方法由一系列活动构成。这些活动分为以下阶段z一一业务分析;一一需求分析;一一逻辑分析;逻辑设计(报文设计); 技术设计。对于每项活动，本部分描述了:一一开始该项活动所需的条件
6、(需要的输入); 一一该项活动应产生的结果(预期输出); 一一示例一一在有必要时;应当遵循或者参考的建模导则和其他导则。本部分对应满足的条件和/或者应提交给注册机构的文档未加描述。这些信息见GB/T27926网站上发布的提交模板及其相关指南。H 提供的示例仅用于说明建模的方法，不应视做所描述业务领域的定义性描述。GB/T 27926. 1中的术语和定义适用于本部分。1 业务分析GB/T 27926.3-2011 /ISO/TS 20022-3: 2004 金融服务金融业通用报文方案第3部分:建模导则业务分析的简单示例参见附录A(业务分析:基金行业业务过程)。1. 1 简介1. 1. 1 目的业
7、务分析的目的是为更好的理解业务领域和业务过程，并基于此制定符合GB/T27926标准的业务交易和报文集:描述业务过程，包括业务角色及其对业务信息的需求，以帮助确定该过程各参与方间的信息交换问题。这些信息交换问题是进行下一阶段(需求分析)的主要动因;识别业务领域中使用的业务信息也非常重要，因为在后续阶段设计的报文会包括与该业务信息有关的数据元素。业务元素/组件和报文元素/组件间的明确联系有助于互操作性，也有助于以后的维护和变更管理:即如果业务领域内的某些因素发生变化时，就可能确定其对先前已定义的报文的影响。1. 1. 2 关键主题一确定待解决信息交换问题的业务背景;一理解业务领域和业务过程中的日
8、常业务，而不是仅关注于待开发的业务交易和报文集;提取业务过程中使用的业务信息;一一确保所有人员，如业务专家和标准制定者对业务领域和业务过程有共同理解。1. 1. 3 交付内容-一业务领域的文字描述(目标、范围和边界); -一描述业务过程和其包含的业务信息和业务角色的模型，所有模型元素的详细的文字说明，并包含业务术语表。1. 2 过程概览下图给出了在本阶段开展的不同活动(以椭圆形表示)和需要的输入输出(以矩形表示)。这些活动在下文中有详细描述。GB/T 27926.3-2011/ISO/TS 20022-3 :2004 t纽件E业务组件类图业务组件图定义业务背呆定义业务模婴活动图业务活动阁1.3
9、 活动1.3. 1 定义业务背景2 本活动包括定义和提炼:二二业务目标z所考虑的业务领域的全局目标和目的z范围z包含的业务过程或金融工具，需要考虑的业务参与者和业务角色等;一一边界:业务背景中处理和/或使用的关键业务组件和业务元素。它们可分成输入信息(即影响业务过程，但是又不在业务背景控制范围内的信息)和输出信息(即在业务背景控制内且影响其他业务过程的信息h二与业务领域相关的假设;一一业务需求(预期功能)和约束(例如，将成为解决方案一部分的市场基础架构、性能需求(T+1)、互操作性需求、应考虑的市场惯例); 业务术语，该术语或者由简短明确的描述进行定义以消除可能的歧义，或者更适宜的是指向已存在
10、的业务术语表。GBjT 27926.3-20 lljISOjTS 20022-3: 2004 1. 3. 2 定义业务模型为了定义业务模型，应采用下列步骤:a) 业务过程图:根据项目范围中己确定的业务过程列表，生成一幅包含所有业务过程的图表。该图表应从顶层节点(表示总体业务目标)开始给出业务过程的组织。可通过AND-分解，OR-分解，包含关联和扩展关联进行细化Eb) 业务活动图:对于每个业务过程，使用一个或多个业务活动图来补充业务过程图。业务活动图更好更详尽的说明了业务过程中各式各样的活动和业务角色、活动和业务角色间的交互作用。活动图应尽可能的描述每个业务过程中的常规流和非常规流。推荐的活动图
11、类型称之为泳道(swimlane)。实际上对于每个业务角色，都存在一个这样的泳道(swimlane)，用来描述该业务角色的活动以及(选择性的)包含该业务角色可达到的主要状态;c) 对每个业务过程以及每个业务过程的活动进行描述: 定义(即活动的说明); 触发事件(即导致活动开始的事件); 前置条件(即开始该活动应满足的条件); 后置条件(即完成该活动应满足的条件); 参数(即活动执行所必需的、生成的或改变的信息); 角色(即活动中业务参与者的功能)。d) 业务角色图:生成与项目范围相关的所有业务角色的图表(这些角色在前述的步骤中己定义)。遍历GBjT27926数据字典(DD)中已有角色，并复制业
12、务角色图中需要的角色，使用这些业务角色及在数据字典中不存在的业务角色完成图表。如果业务角色与数据字典中的角色相比具有多于或少于的差异(即具有很大的相符之处但同时也存在一些重大差异)，应生成新的角色并在该图表中标注出与数据宇典中已存在的相关业务角色间的联系。所有这些附加业务角色都应提交至注册机构;巳)业务组件图:生成一个由上述第c)步中参数得到的所有业务组件1)的图表。它应包括继承、关联和聚合关系。遍历GBjT27926数据宇典(DD)中的所有己存在的业务组件，并复制业务组件图中需要的组件。使用这些业务组件及在数据字典中不存在的业务组件完成图表。如果业务组件与数据字典中的组件相比具有多于或少于的
13、差异(即具有很大的相符之处但同时也存在一些重大差异)或需要增加新的业务元素，应生成新的组件并在该图表中标注出与数据字典中己存在的相关业务组件间的联系。所有这些附加业务组件都应提交至注册机构;f) 通过验证以下内容来检查业务模型的一致性:业务过程和业务活动图中使用的所有业务组件和业务角色是否都包含于业务角色图和业务组件图中? 图中定义的所有业务组件和业务角色，是否至少在一个业务过程或活动中涉及(除了那些从数据字典中复制的作为项目特定化基础的组件或角色)?业务过程图与项目范围中的信息是否一致?业务组件图与项目边界中的信息是否一致?业务过程和业务活动是否正确函盖了所用业务组件的生命周期(生成、更新、
14、删除)2)? 1. 4 导则一一应用鸟瞰视图。在业务分析阶段，我们需要集中关注业务而避免讨论解决方案及信息交换1) 在业务模型中，业务组件定义为类。业务组件就是业务概念的一个详尽定义。应注意业务组件不会直接用于报文模型，因为它是通用的且不会考虑报文环境的特殊需求。2) 这不意味着在描述的业务过程中，所有的业务组件都必须经过生成、更新和删除过程，而意味着必须明确哪些组件包含了生成、更新和删除过程，哪些组件为什么不必包含。3 G/T 27926.3-2011 /ISO/TS 20022-3: 2004 问题。这意味着我们假设不存在信息交换问题，每个业务角色对任何业务过程中使用的信息具有充分的了解及
15、访问。须牢记一个好的业务过程应切实增加业务价值;一通过引人业务组件或业务角色，主要集中于能带来巨大价值的业务过程。不要太关注如撤消、修改、生成等细节。本阶段也不对错误处理进行分析。例如，银行内转账业务过程将引出如账户、贷记等棋念，撤消银行内转账却不会带来特别的价值，在本阶段应不予考虑。这些细节将在逻辑分析阶段，业务交易和报文集定义完毕后进行详细描述;一集中于功能型角色，而不是现实的业务参与者。例如，当前阶段最重要的是确定购买者这一角色，而不是确定购买者是个人、企业还是金融机构;一-依据可用细节层次的不同程度，可以将业务过程分解成多个更细化的业务过程;一一通常，角色应仅与最细化的业务过程和业务活
16、动(即最低层次)关联;一一一确保为新的业务组件和业务角色提供所有需要的信息(例如，建议的名称和定义); 注意业务组件图中聚合关系仅用于表示具有真正业务包含关系的情况(例如，对于账户中未涉及到的参与方，则账户和该方之间不应具有聚合关系)。真正的业务包含关系意味着在现实中被包含元素不能脱离于包含元素而存在(例如，账户余额不能脱离账户存在); 一一业务组件圈可包含关于多样性的信息，且应指明每个业务元素的类型(通过数据类型或业务组件表示)。2 需求分析需求分析的简单示例参见附录A(需求分析:基金行业信息交换需求。2.1 简介2. 1. 1 目的需求分析的目的是定义由于业务参与者的物理分离导致的信息交换
17、需求，这些业务参与者将在业务过程中执行不同的业务角色。需求分析将确定并详细说明业务过程和业务活动在协定范围内出现的所有信息交换需求。它将确定谁、从何处、在何时、需要何种信息。这样，需求分析将为待开发的解决方案(即业务交易和报文集)提供详细描述，而不是去探究报文和报文流的实际定义。2. 1.2 关键主题对业务分析的结果进行分析以引出信息交换需求;一一对待开发的业务交易和报文集预期属性进行准确定义(功能及与业务角色的交互关系)。2.1.3 主要活动确定待开发的业务交易和报文集的目标(信息交换以及尽可能的提高特定业务过程或活动的性能); -详细描述待开发业务交易和报文集的功能(即行为)需求;详细描述
18、待开发业务交易和报文集的约束条件(即硬性限制)。2. 1. 4 交付内容一最终解决方案范围和边界的文字描述;一一经提炼的、完整的约束条件的文字描述;一一待开发业务交易和报文集的预期功能的需求用例。用例的说明应包含定义、参数、触发事件、前置条件和后置条件;每个业务角色使用的信息的业务组件图(可通过相关业务规则进行补充)。2.2 过程概览下图给出了在本阶段开展的不同活动(以椭圆形表示)和需要的输入输出(以矩形表示)。这些活动在下文中有详细描述。4 2.3 活动类图业务组件图提炼2.3. 1 定义最终范围和边界GB/T 27926.3-2011 /ISO/TS 20022-3: 2004 定义信息交
19、换需求完成需求和约束类图业务角色图文档约束待开发业务交易和报文集支持的业务过程和活动的定义，需基于业务分析阶段定义的业务过程图、业务活动图，及本项目定义的需求和范围。5 GB/T 27926.3-2011 /ISO/TS 20022-3: 2004 2.3.2 定义信息交换需求在本阶段，不再使用业务分析阶段使用的鸟瞰视图。要认识到业务过程活动中的业务角色不能访问所有信息(即它们对业务组件和/或业务过程中其他活动的状态仅有有限的了解)，由于对业务组件和/或业务过程中其他活动的状态缺少了解从而导致业务过程不能完成。实际上，根本问题是:我们需要确保业务过程(范围中的)中的所有活动能够访问完成活动所需
20、的信息。因此，解决方案是生成一个或多个业务交易，这些业务交易解决业务过程中各业务角色之间所有必要的信息交换。这样，业务交易将确保业务过程中的每项活动都能访问它所需的信息。需求分析的目标就是确定并详细说明这些信息交换需求(即在何种条件下，需要向谁提供何种信息等)。需遵循的步骤如下:a) 在业务活动图中，确定在业务范围内的活动和参与活动的角色;b) 为执行的每项活动定义所需的信息。包括:输入的参数、触发该活动的可能信息(例如，另外一项活动结束)和检查前置条件可能需要的信息;c) 从上述定义的所需信息中定义业务角色执行该活动元法获得的信息(即业务角色不拥有何种信息hd) 根据信息生成需求用例，并确定
21、提供信息的业务角色。上述信息需作为待开发业务交易的一部分进行信息交换。在某些情况下，信息(部分信息)可由多个业务角色共同提供(在整个业务过程中的不同时刻)。需要注意需求用例可能已经生成的情况(如果其他活动需要)。需求用例3)使用下述信息进行描述:定义:用例的目标和功能，即向哪些活动提供何种信息以及在何种业务角色间提供;一一触发事件:使用例开始执行的事件;二前置条件:执行用例应满足的条件;后置条件:执行用例完毕应满足的条件;一一参数:用例使用和生成的信息。2.3.3 完成需求和约束条件基于前阶段已经完成的分析和确定的项目范围，系统地记录所有约束条件(例如，属于特定实现的约束条件); 一验证上述约
22、束条件是否对话求用例中描述的功能有影响，如有必要，修改用例。2.4 导则一一一当对需求进行详细说明时，可能有必要结合一些潜在的需求用例(例如，因为它们处理同一业务信息或者总是被同一业务角色一起执行)或者放大/缩小潜在的需求用例(例如，为了使细节具有可管理的层次)。3 逻辑分析逻辑分析的简单示例参见附录A(逻辑分析:业务交易)。3.1 简介3. 1. 1 目的逻辑分析的目的是详细描述待开发业务交易和报文集的细节。因此本阶段的重点是定义报文流和报文，用于在正确的时间从正确的业务角色获取所需的信息。本阶段仍从单纯的业务视角看待业务交易和报文集，也就是说从语义的视角(即潜在的业务含义)而非语法的视角(
23、即报文的表达及其规则)。所有的结论均源自需求分析阶段已确认和说明的需求(功能需求和约束)。p 3) 需要注意，需求用例中的信息可能基于业务过程或活动中的相关信息，但是不一定完全如此。G/T 27926.3-20门/ISO/TS20022-3: 2004 逻辑分析之所以称之为逻辑的，是因为它从一个抽象的视角描述业务交易和报文集，而不是从具体的、技术的视角。这种抽象的方法使其在不同的技术表示形式间保持互通性。3. 1.2 关键主题一一解决方案的总体架构是什么?参与报文交换的子系统是什么?我们需要寻找一个端到端的还是星形结构的解决方案?二一业务交易是什么?不同报文可按照经确认允许的多个报文流的方式进
24、行交换E从业务内容角度描述的报文是什么?交换的信息应具有业务价值，报文组件/元素应源自业务分析和需求分析阶段确定的业务组件/元素并由之定义;适用于各种业务交易和报文的规则是什么，每条规则的范围是什么?如果范围仅是报文，则规则仅针对报文的内容;如果范围是业务交易，规则将针对全部业务交易信息检验报文的内容(例如，之前交换的报文包含的信息)。3. 1.3 主要活动确定解决方案的总体架构;一将需求用例提炼成为具体的业务交易。基于该业务交易，确定报文、主要的报文流及其相关规则;一一设计报文，即确定业务内容、总体架构、报文组织和报文适用的规则。3. 1.4 支付内容业务交易图(包含业务交易的结构化描述h当
25、为星形结构系统时，对(子)系统架构的文字描述;序列图(即业务交易背景下的典型报文交换)。3.2 过程概览下图给出了在本阶段开展的不同活动(以椭圆形表示)和需要的输入输出(以矩形表示)。这些活动在下文中有详细描述。7 GB/T 27926.3一2011/ISO/TS20022-3 : 2004 组件业务参与者与业务角色(;顶序图报文序列定义架构定义业务交易提炼4协作图报文协作用例图话求用例图类图业务角色图3.3 活动3.3. 1 定义架构，、。一一定义解决方案的架构，即确定包含在业务交易中的各个子系统。子系统是业务交易的边界，即标准制定者不需对发生在这些子系统中的应用细节进行标准化，而只需对这些
26、应用间的信息交换(接口)进行标准化。对子系统及其活动的详细说明有助于定义所需的报文流;如何确定子系统?虽然我们不关注于业务参与者个体，但事实上，它与业务交易中充当业务角色的业务参与者的类型存在联系。所以，最好在此时将子系统定义和业务参与者类型的定义结合起来: 确定是否涉及主系统(例如，传输流监控(TFM)、市场基础架构)。如果涉及，针对每个主系统应有一个子系统与其相连; 将子系统与每个类型的业务参与者进行关联，这些业务参与者将充当一个或多个相关的业务角色。某些情况下，可将多个业务角色结合到一个子系统。这需要根据子系统行为的基本共性或个性决定。同一业务参与者是否充当多个业务角色的情况也对其产生影
27、响。在其他情况下，可能有必要为单一业务角色预先考虑多个子系统。例如，如果多种类型的业务参与者能充当同一业务角色，并且业务参与者的类型对子系统的行为及其信息交换需求存在显著影响时，就有必要为该业务角色预先考虑多个子系统。一一子系统可通过类图描述。G/T 27926.3-2011 /ISO/TS 20022-3: 2004 3.3.2 定义业务交易综合考虑定义的子系统，描述子系统实现需求用例的方法(即子系统是如何互相作用的)和该过程中需要的信息流;一一业务交易应至少通过文字和序列图描述，以给出子系统间的信息流。可选地，可以加上协作图(注意，协作图可从序列图中自动导出)。业务交易的描述将提供关于子系
28、统间信息流(报文)的信息、这些流发生的顺序、特殊情况的处理、以及与每个信息流有关的触发事件、前置和后置条件;一一对于每个确定的信息流，定义报文名称、报文内容和初步的报文结构(即按照逻辑，哪些信息应放到一起)，且在序列图(与每个信息流关联)中说明这些信息。报文内容可根据不同业务活动需要的和提供的信息加以确定。在本阶段，也可以给出有关多样性、选项和规则描述方面的信息。如果必要，也应确定信息流是同步还是异步、是推还是拉等;如必要，可提炼子系统类图。3.4 导则3.4.1 概述一一在多数情况下，基础架构(即端到端或者星形结构)由最初的需求决定;典型的金融行业中，业务参与者类型包括z银行、代理机构(例如
29、，经纪人、投资经理等)以及企业等;同业务角色一样，业务参与者也是数据字典的一部分。在项目中，它们被加入到业务角色图中(但应明确标明他们是业务参与者)。在业务角色图中也给出了业务参与者及其充当的业务角色之间的联系;通常每个需求用例能(并且将)按照多种业务背景实现。对于每种业务背景，应由单独的业务交易进行定义并描述;业务交易也应考虑(进而描述)非常规处理、错误处理、确认等。这些处理可导致附加序列图的产生;一一应注意，一个业务交易仅是描述一组需求的一个可能的解决方案。针对同样的问题可能有多个解决方案。在此情况下，对于同样的需求用例可能会有多个业务交易;在确定业务交易时，业务交易可以是其他业务交易的特
30、例、扩展或者组合。对于这种情况，可以使用包含、扩展和泛化关系。3.4.2 报文粒度应遵循报文粒度的初始规定(以下规则将对4.4.1.1报文粒度建模导则产生影响): 一一报文要明确且符合特定目的。报文细化会导致大量报文的产生，因此在特定情况下，需要借助某些帮助来选取适合应用的报文。可以通过自上而下的方法依次确定业务领域、业务过程、业务交易和报文。利用该方法，可生成准确但业务功能有限的报文。这些报文具有较少的可选域，因为可将报文中进一步定义报文功能的元素去掉，因此报文也较短。所有这些，简化了实现和维护，并最终导致了较高的直通交易处理CSTP)率;示例:在证券买卖时，我们需要的信息不同，返回的确认信
31、息也不相同，因此导致了不同报文的产生。最低原则是为不同功能定义各自的报文(例如，用于生成、修改、撤消的报文，用于指令和报告的报文); 一一对于不同类型的金融工具，原则上使用同一报文来涵盖，除非它们的差别不仅仅在于对金融工具的描述(例如，如果使用了其他金融工具，则必须在报文中标识其他参与方h9 GB/T 27926.3-20 11/ISO/TS 20022-3 :2004 对于市场惯例，原则是首先集中生成一个独立于市场惯例的报文(即包含所有共性的报文), 然后，我们可关注特定的市场惯例，确定更多有关多样性、数据类型和规则的特定的信息及需求并根据差异的要求程度生成在同一报文定义下的不同变体和/或覆
32、盖多个市场惯例需求的报文定义;一一对于充当同一业务角色的多个子系统，与市场惯例遵循的原则类似。首先集中于子系统间的共性。然后，确定其在信息需求、多样性、数据类型和规则方面的区别并根据差异的要求程度，生成在同一报文定义下的不同变体和/或覆盖多个子系统需求的报文定义;一一验证生成多个报文定义(有多个变体的)较生成单个报文是否有意义的有用工具是，考虑为了生成多个显式的报文，从报文定义中去掉一个特定组件或元素后所产生的影响。如果去掉组件或元素导致了大量报文的产生，则不宜生成多个报文(例如，从一个以欧元、英镑或美元等形式支付的报文中将币种去掉)，另一方面，如果去掉的组件或元素简化了报文中的规则，则宜生成
33、多个报文(例如，去掉购买/出售指示符，意味着可以省略其他规则)。当要去掉的元素包含很多可能值时，不建议将其去掉，因为该元素的每个值都可能导致产生新的报文定义或报文定义变体。4 报文设计报文设计的简单示例参见附录A(报文设计:组建报文)。4. 1 简介4. 1. 1 目的报文设计的目的是提炼解决方案的逻辑模型，以使其规范化(即精确无误)并确定可重用的报文组件。4. 1. 2 关键主题一一将使用哪些己有的报文组件?必须生成哪些新的报文组件?4.1.3 主要活动一一规范报文内容;一一确定合适的报文组件;将上述内容合并成为报文定义图。4. 1. 4 交付内容一一报文定义图;-一一用形式化语言书写的完成
34、逻辑模型规范化的文本规则。4.2 过程概览下图给出在本阶段开展的不同活动(以椭圆形表示)和必要的输入输出(以矩形表示)。这些活动在下文中有详细描述。10 G/T 27926.3-2011月SO/TS20022-3 :2004 定义报文组件类图新更改的报文组件组件报文4.3 活动:定义报文组件理解报文中可包含什么样的组件非常重要。下述报文元模型图给出了报文中允许包含的组件、组件间的关系、数据类型等。任何报文都应根据该元模型图构建。11 GB/T 27926.3一2011/ISO/TS20022-3: 2004 如何阅读元模型图:报文由多个报文构建块构成，各个报文构建块表示的信息彼此具有逻辑关系。
35、报文构建块的内容和结构通过报文组件定义。报文组件由报文元素构成。报文元素或者引用其他报文组件(通过使用聚合或做为一个属性建模)，或者拥有某种数据类型(作为一个属性建模)。数据类型可为(Quantity)、(Idendfier)、(Code)、(Amount)等。表示报文组件的类具有(MessageCom ponen t) (指出报文元素的顺序)或(ChoiceComponent)构造型(指出报文元素间的某一选择。4.3.1 通用导则4.3. 1. 1 报文组件由业务组件导出大部分报文组件由业务组件导出，大部分报文元素由业务元素导出4)。数据字典中定义了报文组件/元素和其相关业务组件/元素间的追
36、溯关系。几个报文组件/元素可定义并追溯至同一个业务组件/元素。报文定义中的某些报文组件或报文元素可能是由于报文特定的的原因(例如，页码、特定引用等)而出现的，这些组件或元素是技术性的，它们不源于任何业务组件或业务元素。4.3. 1. 2 如何为报文选取/生成正确的报文组件12 a) 首先应根据在逻辑分析阶段定义的结构来确定什么类型的信息应放置在一起;b) 第一种(且最简单的)情况是一个业务组件需要多个业务元素。这种情况下，可以通过搜索数据字典获得基于该业务组件的所有报文组件。如果存在一个报文组件包含了所有需要的业务元素，而且报文组件包含正确的多样性与规则，则该报文组件就是所要选择的报文组件;。
37、如果不存在准确匹配需求的报文组件，则:的注意z业务组件不能在报文模型中直接使用，因其是通用的且没有将报文背景的特殊需求考虑在内。GB/T 27926.3-20门/ISO/TS20022-3: 2004 使用包含更多元素的报文组件(如果多余的元素可接受); 使用对多样性和/或规则限制较少的报文组件(如果较宽松的确认可接受); 使用两个或两个以上的报文组件以包含所有需要的业务元素。可以: 在报文中将相关报文组件相邻放置; 建议RA生成一个新的组合报文组件。d) 如果多个业务组件包含多个业务元素，并且不需表示不同业务组件之间的联系，则根据以上描述的方法使用多个报文组件;e) 如果多个业务组件包含多个
38、业务元素，并且需要表示不同业务组件之间的联系(例如，需要表示账户、账户拥有者和账户服务商之间的关联性)，应通过数据字典获得基于已确定业务组件的所有报文组件。集中考虑那些已经表示了两个(或多个)业务组件之间关系的报文组件。找出包含了所有所需元素并且表示了所需关系的报文组件。如果该报文组件不存在，可以找出包含了多于所需元素的报文组件，或者将多个报文组件合井。如果不能接受该解决方案，可建议生成一个或多个新的报文组件。4.3. 1. 3 如何定义新的报文组件如果报文组件仅涉及单一业务组件中的业务元素，建议生成一个基于该业务组件的、包含所需报文元素的报文组件，该报文组件应同时满足所需多样性和规则的要求(
39、见4.3. 1. 4) ; 一一另外，报文组件可能包含技术性报文元素(见4.3.1.的，这些技术性报文元素是在任何业务组件中都不存在且仅在特定报文中有意义的附加元素。在此情况下，建议按照前述生成一个满足所需多样性和规则的报文组件，并追加所需的技术性报文元素一因为不存在与其对应的业务元素;如果报文组件需要从多个业务组件中获取元素(因为必须表示出业务组件之间的关系)，可参考以下选项: 使用几个简单报文组件(即报文组件基于单一业务组件)，如有必要，在报文层增加规则来说明被此的联系; 把简单报文组件聚合成为一个父报文组件，通过这种方式，所有简单报文组件则成为子报文组件(例如，新组件包含三个报文组件A、
40、B和C)。在此情况下，建模人员应指出这些不同的报文组件同属某项功能，并且描述其必要的多样性信息和/或规则。将新报文组件提交至注册机构; 生成表示依赖关系的新报文组件(例如，新报文组件Al和报文组件Bl有聚合关系，其中Al基于业务组件A，Bl基于业务组件B)。在此情况下可能有两种选择，或者保持明确的聚合关系，或者从所依赖的报文组件导人报文元素到父报文组件(即使用属性代替聚合关系)。后者应谨慎使用，因为它表达的依赖关系有限(例如，它不能表示新报文组件应包含报文组件Bl的所有的报文元素，还是不包含其报文元素)。使用该选项的一个原则是仅有一个报文元素来自报文组件Bl.下图表示了上述两种选择(左边是聚合
41、关系，右边是导入勺。13 G/T 27926.3一2011/ISO/TS20022-3: 2004 摆在attl部att2也att3每att4报文组件Al 报文组件Bl 在导attlatt2 部att3报文组件AIBl 4.3. 1. 4 什么是报文元素报文元素可以是基于业务元素的报文元素或技术性报文元素。4.3. 1. 4. 1 基于业务元素的报文元素这类报文元素是对特定业务组件中业务元素的一种拷贝，且具有以下特性:如果规定了业务元素的数据类型，则也应规定报文元素的数据类型。该数据类型必须相同，或者数据类型相同且具有更严格的限制。在需要对报文元素的允许值进行限制时(例如，定义用于业务元素的代
42、码列表的子集)，在保持相同数据类型的条件下应使用相应的限制;如果由业务组件规定业务元素的类型，则应由报文组件规定报文元素的类型。该报文组件应基于限定业务元素的业务组件;一一如果报文元素和业务元素在语义上完全一致，则应继续使用业务元素的定义和名称;一一如果报文元素的语义比业务元素更加丰富和具体，则应对业务元素的定义和名称进行修改以适应报文元素。示例:报文需要引用业务元素的特定要求(最后进入的日期而不是进入日期)或者引用已经计算出的数据。在此情况下，报文元素的定义和名称必须表达出特定的语义(例如，LastEntryDate)。4.3. 1.4.2 技术性报文元素技术性的报文元素仅在报文背境下有意义
43、，没有对应的业务元素，因此也没有可追溯的业务元素与之关联。下面从业务组件中导出报文组件的例子描述了这些原则。14 GB/T 27926.3-2011 /ISO/TS 20022-3: 2004 业务组件Fma咀anc口ialIns引tr阳umentE侮岛妒妒Isi剖削1击岛导D阳e因町scn刷严ionText瞅:De阳1刷ptionTe吼t 报文章1件F inaciall nstrumentDetai Is 每Isinl由1巾:lsinldentifier 每每如Des口旧S皿C口nptlG) NoFm阳na咀um町an阳阳l皿阳c口i且刷alInst阳以s引tr阳um阳n阳l阳entl川11
44、0队:T刊ur阳cF巳Fal川11se叫4巳el丑ln毗1叫毗dic叫a剖10町r a) 生成报文组件FinancialInstrumentDetails，并将其与相对应的业务组件FinancialInstrument建立可追溯的关联;b) 拷贝属性Isinldentifier和DescriptionText，不修改名称和类型;c) 仅为FinancialInstrumentDetails生成NoFinancialInstrumentID，它没有可追溯的关联。其目的是指明在报文中是否存在Financiallnstrumentldentification报文组件。该信息也可以根据报文中该报文组件
45、的存在/不存在得到。4.3.2 高级导则4.3.2. 1 如何聚合两个报文组件当两个报文组件相关联时，它们的关系可以通过两种形式表示，一种是使用两个组件间的聚合关系直接表示，另外一种是使用属性间接表示。一一一当报文组件为聚合关系时，两个组件之间的联系可明确表示。建模人员可以给聚合关系的角色名称和定义附加背景信息。这种表示形式可视性较好，但是会使报文图很快变得很繁杂;一一当使用属性表示报文组件关系时，一个组件的属性指向其他的报文组件。在此情况下，建模人员可以给属性的名称和定义附加背景信息。属性的名称等同于前述步骤中聚合关系(角色名称)的名称。该方法可视性较差(关联是隐含的)，但是对于复杂的报文，
46、较之聚合关系而言报文图看起来较简洁。这种建模方法在UML中称为外键使用属性。4.3.2.2 如何处理抽象类报文组件不应基于抽象的业务组件之上开发。当业务组件不能实例化时，就将其定义为抽象的。某种程度上，报文组件是业务组件的实现。因此报文组件作为抽象业务组件的实现是没有意义的。由于抽象业务组件没有可追溯的联结，其追溯性将存在于具体化该抽象业务组件的业务组件。15 G/T 27926.3-2011/ISO/TS 20022-3 :2004 抽象PostalAddress 业务组件StructuredPostalAddress 业务组件F reeF orrnatPostalAddress 毒岛bCo肌u山川11垣Pos引tCode:Pos曰tCodeldentifierE郎导刊wnN阳am阳e:M缸35T圳在各StreetName:M皿35Text
