标准规范下载简介
在线阅读
中华人民共和国国家标准
金融服务 金融业通用报文方案 第3部分：建模导则
Financial services-Universal financial industry message scheme-Part 3：Modelling guidelines
GB/T 27926．3-2011
发布部门：中华人民共和国国家质量监督检验检疫总局
中国国家标准化管理委员会
发布日期：2011年12月30日
实施日期：2012年05月01日
前 言
GB/T 27926《金融服务 金融业通用报文方案》由以下5部分构成：
——第1部分：输入输出方法和格式规范；
——第2部分：注册机构的角色及职责；
——第3部分：建模导则；
——第4部分：XML设计规则；
——第5部分：反向工程。
本部分为GB/T 27926的第3部分。
本部分等同采用ISO/TS 20022-3：2004《金融服务 金融业通用报文方案 第3部分：ISO 20022建模导则》（英文版）。
为便于使用，本标准还做了下列编辑性修改：
a)“ISO 20022的本部分”改为“GB/T 27926的本部分”；
b)删除国际标准前言；
c)将国际标准名称由“ISO 20022建模导则”改为“建模导则”。
本部分附录A为资料性附录。
本部分由中国人民银行提出。
本部分由全国金融标准化技术委员会(SAC/TC 180)归口。
本部分负责起草单位：中国金融电子化公司。
本部分参加起草单位：中国人民银行、中国证券监督管理委员会、中国工商银行、中国建设银行、博时基金管理有限公司、深圳证券通信公司、申银万国证券股份有限公司、中国人民银行长春中心支行、中国人民银行南京分行。
本部分主要起草人：王平娃、陆书春、李曙光、赵志兰、马小琼、贾树辉、王毛路、王德英、巫禄芳、强庆华、施轶倩、李迎辉、成永德、刘运、景芸、陈立军、程晓阳。
引 言
GB/T 27926的本部分描述了适用于标准化业务交易和报文集开发的方法论。标准化业务交易的目标是，针对特定的业务过程环境，为不同组织间存在的信息交换问题定义一个通用的解决方案。
对于特定业务背景下的信息交换问题，可开发出多个解决方案。本部分的目的是向建模人员说明应遵循的不同步骤，以确保业务组件/元素、报文组件/元素、业务交易和报文定义的一致性。
GB/T 27926建模方法由一系列活动构成。这些活动分为以下阶段：
——业务分析；
——需求分析；
——逻辑分析；
——逻辑设计（报文设计）；
——技术设计。
对于每项活动，本部分描述了：
——开始该项活动所需的条件（需要的输入）；
——该项活动应产生的结果（预期输出）；
——示例-在有必要时；
——应当遵循或者参考的建模导则和其他导则。
本部分对应满足的条件和/或者应提交给注册机构的文档未加描述。这些信息见GB/T 27926网站上发布的提交模板及其相关指南。
提供的示例仅用于说明建模的方法，不应视做所描述业务领域的定义性描述。
GB/T 27926．1中的术语和定义适用于本部分。
1 业务分析
业务分析的简单示例参见附录A（业务分析：基金行业业务过程）。
1．1 简介
1．1．1 目的
业务分析的目的是为更好的理解业务领域和业务过程，并基于此制定符合GB/T 27926标准的业务交易和报文集：
——描述业务过程，包括业务角色及其业务信息的需求，以帮助确定该过程各参与方间的信息交换问题。这些信息交换问题是进行下一阶段（需求分析）的主要动因；
——识别业务领域中使用的业务信息也非常重要，因为在后续阶段设计的报文会包括与该业务信息有关的数据元素。业务元素/组件和报文元素/组件间的明确联系有助于互操作性，也有助于以后的维护和变更管理；即如果业务领域内的某些因素发生变化时，就可能确定其对先前已定义的报文的影响。
1．1．2 关键主题
——确定待解决信息交换问题的业务背景；
——理解业务领域和业务过程中的日常业务，而不是仅关注于待开发的业务交易和报文集；
——提取业务过程中使用的业务信息；
——确保所有人员，如业务专家和标准制定者对业务领域和业务过程有共同理解。
1．1．3 交付内容
——业务领域的文字描述（目标、范围和边界）；
——描述业务过程和其包含的业务信息和业务角色的模型，所有模型元素的详细的文字说明，并包含业务术语表。
1．2 过程概览
下图给出了在本阶段开展的不同活动（以椭圆形表示）和需要的输入输出（以矩形表示）。这些活动在下文中有详细描述。
1．3 活动
1．3．1 定义业务背景
本活动包括定义和提炼：
——业务目标：所考虑的业务领域的全局目标和目的；
——范围：包含的业务过程或金融工具，需要考虑的业务参与者和业务角色等；
——边界：业务背景中处理和/或使用的关键业务组件和业务元素。它们可分成输入信息（即影响业务过程，但是又不在业务背景控制范围内的信息）和输出信息（即在业务背景控制内且影响其他业务过程的信息）；
——与业务领域相关的假设；
——业务需求（预期功能）和约束（例如，将成为解决方案一部分的市场基础架构、性能需求(T＋1)、互操作性需求、应考虑的市场惯例）；
——业务术语，该术语或者由简短明确的描述进行定义以消除可能的歧义，或者更适宜的是指向已存在的业务术语表。
1．3．2 定义业务模型
为了定义业务模型，应采用下列步骤：
a)业务过程图：根据项目范围中已确定的业务过程列表，生成一幅包含所有业务过程的图表。该图表应从顶层节点（表示总图业务目标）开始给出业务过程的组织。可通过AND-分解，OR-分解，“包含”关联和“扩展”关联进行细化；
b)业务活动图：对于每个业务过程，使用一个或多个业务活动图来补充业务过程图。业务活动图更好更详尽的说明了业务过程中各式各样的活动和业务角色、活动和业务角色间的交互作用。活动图应尽可能的描述每个业务过程中的常规和非常规流。推荐的活动图类型称之为“泳道(swim lane)”。实际上对于每个业务角色，都存在一个这样的“泳道(swim lane)”，用来描述该业务角色的活动以及（选择性的）包含该业务角色可达到的主要状态；
c)对每个业务过程以及每个业务过程的活动进行描述：
·定义（即活动的说明）；
·触发事件（即导致活动开始的事件）；
·前置条件（即开始该活动应满足的条件）；
·后置条件（即完成该活动应满足的条件）；
·参数（即活动执行所必需的、生成的或改变的信息）；
·角色（即活动中业务参与者的功能）。
d)业务角色图：生成与项目范围相关的所有业务角色的图表（这些角色在前述的步骤中已定义）。遍历GB/T 27926数据字典(DD)中已有角色，并复制业务角色图中需要的角色，使用这些业务角色及在数据字典中不存在的业务角色完成图表。如果业务角色与数据字典中的角色相比具有“多于或少于”的差异（即具有很大的相符之处但同时也存在一些重大差异），应生成新的角色并在该图表中标注出与数据字典中已存在的相关业务角色间的联系。所有这些附加业务角色都应提交至注册机构；
e)业务组件图：生成一个由上述第c)步中“参数”得到的所有业务组件1)的图表。它应包括继承、关联和聚合关系。遍历GB/T 27926数据字典(DD)中的所有已存在的业务组件，并复制业务组件图中需要的组件。使用这些业务组件及在数据字典中不存在的业务组件完成图表。如果业务组件与数据字典中的组件相比具有“多于或少于”的差异（即具有很大的相符之处但同时也存在一些重大差异）或需要增加新的业务元素，应生成新的组件并在该图表中标注出与数据字典中已存在的相关业务组件间的联系。所有这些附加业务组件都应提交至注册机构；
f)通过验证以下内容来检查业务模型的一致性：
·业务过程和业务活动图中使用的所有业务组件和业务角色是否都包含于业务角色图和业务组件图中？
·图中定义的所有业务组件和业务角色，是否至少在一个业务过程或活动中涉及（除了那些从数据字典中复制的作为项目“特定化”基础的组件或角色）？
·业务过程图与项目范围中的信息是否一致？
·业务组件图与项目边界中的信息是否一致？
·业务过程和业务活动是否正确函盖了所用业务组件的生命周期（生成、更新、删除）2)？
1．4 导则
——应用“鸟瞰视图”。在业务分析阶段，我们需要集中关注业务而避免讨论解决方案及信息交换问题。这意味着我们假设不存在信息交换问题，每个业务角色对任何业务过程中使用的信息具有充分的了解及访问。须牢记一个“好”的业务过程应切实增加业务价值；
——通过引入业务组件或业务角色，主要集中于能带来巨大价值的业务过程。不要太关注如“撤消”、“修改”、“生成”等细节。本阶段也不对错误处理进行分析。例如，“银行内转账”业务过程将引出如“账户”、“贷记”等概念，“撤消银行内转账”却不会带来特别的价值，在本阶段应不予考虑。这些细节将在逻辑分析阶段，业务交易和报文集定义完毕后进行详细描述；
——集中于功能型角色，而不是现实的业务参与者。例如，当前阶段最重要的是确定“购买者”这一角色，而不是确定购买者是个人、企业还是金融机构；
——依据可用细节层次的不同程度，可以将业务过程分解成多个更细化的业务过程；
——通常，角色应仅与最细化的业务过程和业务活动（即最低层次）关联；
——确保为新的业务组件和业务角色提供所有需要的信息（例如，建议的名称和定义）；
——注意业务组件图中“聚合关系”仅用于表示具有真正业务包含关系的情况（例如，对于账户中未涉及到的参与方，则账户和该方之间不应具有聚合关系）。真正的业务包含关系意味着在现实中被包含元素不能脱离于包含元素而存在（例如，账户余额不能脱离账户存在）；
——业务组件图可包含关于多样性的信息，且应指明每个业务元素的类型（通过数据类型或业务组件表示）。
---------------------------
1)在业务模型中，业务组件定义为类。业务组件就是业务概念的一个详尽定义。应注意业务组件不会直接用于报文模型，因为它是通用的且不会考虑报文环境的特殊需求。
2)这不意味着在描述的业务过程中，所有的业务组件都必须经过生成、更新和删除过程，而意味着必须明确哪些组件包含了生成、更新和删除过程，哪些组件为什么不必包含。
2 需求分析
需求分析的简单示例参见附录A（需求分析：基金行业信息交换需求）。
2．1 简介
2．1．1 目的
需求分析的目的是定义由于业务参与者的物理分离导致的信息交换需求，这些业务参与者将在业务过程中执行不同的业务角色。
需求分析将确定并详细说明业务过程和业务活动在协定范围内出现的所有信息交换需求。它将确定谁、从何处、在何时、需要何种信息。这样，需求分析将为待开发的解决方案（即业务交易和报文集）提供详细描述，而不是去探究报文和报文流的实际定义。
2．1．2 关键主题
——对业务分析的结果进行分析以引出信息交换需求；
——对待开发的业务交易和报文集预期属性进行准确定义（功能及与业务角色的交互关系）。
2．1．3 主要活动
——确定待开发的业务交易和报文集的目标（信息交换以及尽可能的提高特定业务过程或活动的性能）；
——详细描述待开发业务交易和报文集的功能（即行为）需求；
——详细描述待开发业务交易和报文集的约束条件（即硬性限制）。
2．1．4 交付内容
——最终解决方案范围和边界的文字描述；
——经提炼的、完整的约束条件的文字描述；
——待开发业务交易和报文集的预期功能的需求用例。用例的说明应包含定义、参数、触发事件、前置条件和后置条件；
——每个业务角色使用的信息的业务组件图（可通过相关业务规则进行补充）。
2．2 过程概览
下图给出了在本阶段开展的不同活动（以椭圆形表示）和需要的输入输出（以矩形表示）。这些活动在下文中有详细描述。
2．3 活动
2．3．1 定义最终范围和边界
待开发业务交易和报文集支持的业务过程和活动的定义，需基于业务分析阶段定义的业务过程图、业务活动图，及本项目定义的需求和范围。
2．3．2 定义信息交换需求
在本阶段，不再使用业务分析阶段使用的“鸟瞰视图”。要认识到业务过程活动中的业务角色不能访问所有信息（即它们对业务组件和/或业务过程中其他活动的状态仅有有限的了解），由于对业务组件和/或业务过程中其他活动的状态缺少了解从而导致业务过程不能完成。实际上，根本问题是：我们需要确保业务过程（范围中的）中的所有活动能够访问完成活动所需的信息。因此，解决方案是生成一个或多个业务交易，这些业务交易解决业务过程中各业务角色之间所有必要的信息交换。这样，业务交易将确保业务过程中的每项活动都能访问它所需的信息。需求分析的目标就是确定并详细说明这些信息交换需求（即在何种条件下，需要向谁提供何种信息等）。
需遵循的步骤如下：
a)在业务活动图中，确定在业务范围内的活动和参与活动的角色；
b)为执行的每项活动定义所需的信息。包括：输入的参数、触发该活动的可能信息（例如，另外一项活动结束）和检查前置条件可能需要的信息；
c)从上述定义的所需信息中定义业务角色执行该活动无法获得的信息（即业务角色不拥有何种信息）；
d)根据信息生成“需求用例”，并确定提供信息的业务角色。上述信息需作为待开发业务交易的一部分进行信息交换。在某些情况下，信息（部分信息）可由多个业务角色共同提供（在整个业务过程中的不同时刻）。需要注意需求用例可能已经生成的情况（如果其他活动需要）。
需求用例3)使用下述信息进行描述：
——定义：用例的目标和功能，即向哪些活动提供何种信息以及在何种业务角色间提供；
——触发事件：使用例开始执行的事件；
——前置条件：执行用例应满足的条件；
——后置条件：执行用例完毕应满足的条件；
——参数：用例使用和生成的信息。
2．3．3 完成需求和约束条件
——基于前阶段已经完成的分析和确定的项目范围，系统地记录所有约束条件（例如，属于特定实现的约束条件）；
——验证上述约束条件是否对需求用例中描述的功能有影响，如有必要，修改用例。
2．4 导则
——当对需求进行详细说明时，可能有必要结合一些潜在的需求用例（例如，因为它们处理同一业务信息或者总是被同一业务角色一起执行）或者放大/缩小潜在的需求用例（例如，为了使细节具有可管理的层次）。
----------------------------
3)需要注意，需求用例中的信息可能基于业务过程或活动中的相关信息，但是不一定完全如此。
3 逻辑分析
逻辑分析的简单示例参见附录A（逻辑分析：业务交易）。
3．1 简介
3．1．1 目的
逻辑分析的目的是详细描述待开发业务交易和报文集的细节。
因此本阶段的重点是定义报文流和报文，用于在正确的时间从正确的业务角色获取所需的信息。本阶段仍从单纯的业务视角看待业务交易和报文集，也就是说从语义的视角（即潜在的业务含义）而非语法的视角（即报文的表达及其规则）。所有的结论均源自需求分析阶段已确认和说明的需求（功能需求和约束）。
逻辑分析之所以称之为“逻辑的”，是因为它从一个抽象的视角描述业务交易和报文集，而不是从具体的、技术的视角。这种抽象的方法使其在不同的技术表示形式间保持互通性。
3．1．2 关键主题
——解决方案的总体架构是什么？参与报文交换的子系统是什么？我们需要寻找一个端到端的还是星形结构的解决方案？
——业务交易是什么？不同报文可按照经确认允许的多个报文流的方式进行交换；
——从业务内容角度描述的报文是什么？交换的信息应具有业务价值，报文组件/元素应源自业务分析和需求分析阶段确定的业务组件/元素并由之定义；
——适用于各种业务交易和报文的规则是什么，每条规则的范围是什么？如果范围仅是报文，则规则仅针对报文的内容；如果范围是业务交易，规则将针对全部业务交易信息检验报文的内容（例如，之前交换的报文包含的信息）。
3．1．3 主要活动
——确定解决方案的总体架构；
——将需求用例提炼成为具体的业务交易。基于该业务交易，确定报文、主要的报文流及其相关规则；
——设计报文，即确定业务内容、总体架构、报文组织和报文适用的规则。
3．1．4 交付内容
——业务交易图（包含业务交易的结构化描述）；
——当为星形结构系统时，对（子）系统架构的文字描述；
——序列图（即业务交易背景下的典型报文交换）。
3．2 过程概览
下图给出了在本阶段开展的不同活动（以椭圆形表示）和需要的输入输出（以矩形表示）。这些活动在下文中有详细描述。
3．3 活动
3．3．1 定义“架构”
——定义解决方案的架构，即确定包含在业务交易中的各个“子系统”。子系统是业务交易的边界，即标准制定者不需对发生在这些子系统中的应用细节进行标准化，而只需对这些应用间的信息交换（接口）进行标准化。对子系统及其活动的详细说明有助于定义所需的报文流；
——如何确定子系统？虽然我们不关注与业务参与者个体，但事实上，它与业务交易中充当业务角色的业务参与者的类型存在联系。所以，最好在此时将子系统定义和业务参与者类型的定义结合起来：
·确定是否涉及主系统（例如，传输流监控(TFM)、市场基础架构）。如果涉及，针对每个主系统应有一个子系统与其相连；
·将子系统与每个类型的业务参与者进行关联，这些业务参与者将充当一个或多个相关的业务角色。某些情况下，可将多个业务角色结合到一个子系统。这需要根据子系统行为的基本共性或个性决定。同一业务参与者是否充当多个业务角色的情况也对其产生影响。在其他情况下，可能有必要为单一业务角色预先考虑多个子系统。例如，如果多种类型的业务参与者能充当同一业务角色，并且业务参与者的类型对子系统的行为及其信息交换需求存在显著影响时，就有必要为该业务角色预先考虑多个子系统。
——子系统可通过类图描述。
3．3．2 定义业务交易
——综合考虑定义的子系统，描述子系统实现需求用例的方法（即子系统是如何互相作用的）和该过程中需要的信息流；
——业务交易应至少通过文字和序列图描述，以给出子系统间的信息流。可选地，可以加上协作图（注意，协作图可从序列图中自动导出）。业务交易的描述将提供关于子系统间信息流（报文）的信息、这些流发生的顺序、特殊情况的处理、以及与每个信息流有关的触发事件、前置和后置条件；
——对于每个确定的信息流，定义报文名称、报文内容和初步的报文结构（即按照逻辑，哪些信息应放到一起），且在序列图（与每个信息流关联）中说明这些信息。报文内容可根据不同业务活动需要的和提供的信息加以确定。在本阶段，也可以给出有关多样性、选项和规则描述方面的信息。如果必要，也应确定信息流是同步还是异步、是推还是拉等；
——如必要，可提炼子系统类图。
3．4 导则
3．4．1 概述
——在多数情况下，基础架构（即端到端或者星形结构）由最初的需求决定；
——典型的金融行业中，业务参与者类型包括：银行、代理机构（例如，经纪人、投资经理等）以及企业等；
——同业务角色一样，业务参与者也是数据字典的一部分。在项目中，它们被加入到业务角色图中（但应明确标明他们是业务参与者）。在业务角色图中也给出了业务参与者及其充当的业务角色之间的联系；
——通常每个需求用例能（并且将）按照多种业务背景实现。对于每种业务背景，应由单独的业务交易进行定义并描述；
——业务交易也应考虑（进而描述）非常规处理、错误处理、确认等。这些处理可导致附加序列图的产生；
一一应注意，一个业务交易仅是描述一组需求的一个可能的解决方案。针对同样的问题可能有多个解决方案。在此情况下，对于同样的需求用例可能会有多个业务交易；
一一在确定业务交易时，业务交易可以是其他业务交易的特例、扩展或者组合。对于这种情况，可以使用包含、扩展和泛化关系。
3．4．2 报文粒度
应遵循报文粒度的初始规定（以下规则将对4．4．1．1报文粒度建模导则产生影响）：
——报文要明确且符合特定目的。报文细化会导致大量报文的产生，因此在特定情况下，需要借助某些帮助来选取适合应用的报文。可以通过自上而下的方法依次确定业务领域、业务过程、业务交易和报文。利用该方法，可生成准确但业务功能有限的报文。这些报文具有较少的可选域，因为可将报文中进一步定义报文功能的元素去掉，因此报文也较短。所有这些，简化了实现和维护，并最终导致了较高的直通交易处理(STP)率；
示例：在证券买卖时，我们需要的信息不同，返回的确认信息也不相同，因此导致了不同报文的产生。
——最低原则是为不同功能定义各自的报文（例如，用于生成、修改、撤消的报文，用于指令和报告的报文）；
——对于不同类型的金融工具，原则上使用同一报文来涵盖，除非它们的差别不仅仅在于对金融工具的描述（例如，如果使用了其他金融工具，则必须在报文中标识其他参与方）；
——对于“市场惯例”，原则是首先集中生成一个独立于市场惯例的报文（即包含所有共性的报文），然后，我们可关注特定的市场惯例，确定更多有关多样性、数据类型和规则的特定的信息及需求并根据差异的要求程度生成在同一报文定义下的不同“变体”和/或覆盖多个市场惯例需求的报文定义；
——对于充当同一业务角色的多个子系统，与市场惯例遵循的原则类似。首先集中于子系统间的共性。然后，确定其在信息需求、多样性、数据类型和规则方面的区别并根据差异的要求程度，生成在同一报文定义下的不同“变体”和/或覆盖多个子系统需求的报文定义；
——验证生成多个报文定义（有多个变体的）较生成单个报文是否有意义的有用工具是，考虑为了生成多个显式的报文，从报文定义中去掉一个特定组件或元素后所产生的影响。如果去掉组件或元素导致了大量报文的产生，则不宜生成多个报文（例如，从一个以欧元、英镑或美元等形式支付的报文中将币种去掉），另一方面，如果去掉的组件或元素简化了报文中的规则，则宜生成多个报文（例如，去掉购买/出售指示符，意味着可以省略其他规则）。
当要去掉的元素包含很多可能值时，不建议将其去掉，因为该元素的每个值都可能导致产生新的报文定义或报文定义变体。
4 报文设计
报文设计的简单示例参见附录A（报文设计：组建报文）。
4．1 间接
4．1．1 目的
报文设计的目的是提炼解决方案的逻辑模型，以使其规范化（即精确无误）并确定可重用的报文组件。
4．1．2 关键主题
——将使用哪些已有的报文组件？
——必须生成哪些新的报文组件？
4．1．3 主要活动
——规范报文内容；
——确定合适的报文组件；
——将上述内容合并成为报文定义图。
4．1．4 交付内容
——报文定义图；
——用形式化语言书写的完成逻辑模型规范化的文本规则。
4．2 规程概览
下图给出在本阶段开展的不同活动（以椭圆形表示）和必要的输入输出（以矩形表示）。这些活动在下文中有详细描述。
4．3 活动：定义报文组件
理解报文中可包含什么样的组件非常重要。下述报文元模型图给出了报文中允许包含的组件、组件间的关系、数据类型等。任何报文都应根据该元模型图构建。
[如何阅读元模型图：
报文由多个报文构建块构成，各个报文构建块表示的信息彼此具有逻辑关系。报文构建块的内容和结构通过报文组件定义。
报文组件由报文元素构成。报文元素或者引用其他报文组件（通过使用聚合或做为一个属性建模），或者拥有某种数据类型（做为一个属性建模）。数据类型可为《Quantity》、《Identifier》、《Code》、《Amount》等。
表示报文组件的类具有《MessageComponent》（指出报文元素的顺序）或《ChoiceComponent》构造型（指出报文元素间的某一选择）。
4．3．1 通用导则
4．3．1．1 报文组件由业务组件导出
大部分报文组件由业务组件导出，大部分报文元素由业务元素导出4)。数据字典中定义了报文组件/元素和其相关业务组件/元素间的追溯关系。几个报文组件/元素可定义并追溯至同一个业务组件/元素。
报文定义中的某些报文组件或报文元素可能是由于“报文特定的”的原因（例如，页码、特定引用等）而出现的，这些组件或元素是“技术性的”，它们不源于任何业务组件或业务元素。
4．3．1．2 如何为报文选取/生成正确的报文组件
a)首先应根据在逻辑分析阶段定义的结构来确定什么类型的信息应放置在一起；
b)第一种（且最简单的）情况是一个业务组件需要多个业务元素。这种情况下，可以通过搜索数据字典获得基于该业务组件的所有报文组件。如果存在一个报文组件包含了所有需要的业务元素，而且报文组件包含正确的多样性与规则，则该报文组件就是所要选择的报文组件；
c)如果不存在准确匹配需求的报文组件，则：
·使用包含更多元素的报文组件（如果多余的元素可接受）；
·使用对多样性和/或规则限制较少的报文组件（如果较宽松的确认可接受）；
·使用两个或两个以上的报文组件以包含所有需要的业务元素。可以：
·在报文中将相关报文组件相邻放置；
·建议RA生成一个新的组合报文组件。
d)如果多个业务组件包含多个业务元素，并且不需表示不同业务组件之间的联系，则根据以上描述的方法使用多个报文组件；
e)如果多个业务组件包含多个业务元素，并且需要表示不同业务组件之间的联系（例如，需要表示账户、账户拥有者和账户服务商之间的关联性），应通过数据字典获得基于已确定业务组件的所有报文组件。
集中考虑那些已经表示了两个（或多个）业务组件之间关系的报文组件。找出包含了所有所需元素并且表示了所需关系的报文组件。如果该报文组件不存在，可以找出包含了多于所需元素的报文组件，或者将多个报文组件合并。如果不能接受该解决方案，可建议生成一个或多个新的报文组件。
4．3．1．3 如何定义新的报文组件
——如果报文组件仅涉及单一业务组件中的业务元素，建议生成一个基于该业务组件的、包含所需报文元素的报文组件，该报文组件应同时满足所需多样性和规则的要求（见4．3．1．4）；
——另外，报文组件可能包含“技术性”报文元素（见4．3．1．4），这些“技术性”报文元素是在任何业务组件中都不存在且仅在特定报文中有意义的附加元素。在此情况下，建议按照前述生成一个满足所需多样性和规则的报文组件，并追加所需的技术性报文元素——因为不存在与其对应的业务元素；
——如果报文组件需要从多个业务组件中获取元素（因为必须表示出业务组件之间的关系），可参考以下选项：
·使用几个“简单”报文组件（即报文组件基于单一业务组件），如有必要，在报文层增加规则来说明彼此的联系；
·把“简单”报文组件聚合成为一个“父”报文组件，通过这种方式，所有简单报文组件则成为子报文组件（例如，新组件包含三个报文组件A、B和C）。在此情况下，建模人员应指出这些不同的报文组件同属某项功能，并且描述其必要的多样性信息和/或规则。将新报文组件提交至注册机构；
·生成表示依赖关系的新报文组件（例如，新报文组件A1和报文组件B1有聚合关系，其中A1基于业务组件A，B1基于业务组件B）。在此情况下可能有两种选择，或者保持明确的聚合关系，或者从所依赖的报文组件“导入”报文元素到父报文组件（即使用属性代替聚合关系）。后者应谨慎使用，因为它表达的依赖关系有限（例如，它不能表示新报文组件应包含报文组件B1的所有的报文元素，还是不包含其报文元素）。使用该选项的一个原则是仅有一个报文元素来自报文组件B1。下图表示了上述两种选择（左边是“聚合关系”，右边是“导入”）
4．3．1．4 什么是报文元素
报文元素可以是基于业务元素的报文元素或技术性报文元素。
4．3．1．4．1 基于业务元素的报文元素
这类报文元素是对特定业务组件中业务元素的一种“拷贝”，且具有以下特性：
——如果规定了业务元素的数据类型，则也应规定报文元素的数据类型。该数据类型必须相同，或者数据类型相同且具有更严格的限制。在需要对报文元素的允许值进行限制时（例如，定义用于业务元素的代码列表的子集），在保持相同数据类型的条件下应使用相应的限制；
——如果由业务组件规定业务元素的类型，则应由报文组件规定报文元素的类型。该报文组件应基于限定业务元素的业务组件；
——如果报文元素和业务元素在语义上完全一致，则应继续使用业务元素的定义和名称；
——如果报文元素的语义比业务元素更加丰富和具体，则应对业务元素的定义和名称进行修改以适应报文元素。
示例：报文需要引用业务元素的特定要求（“最后”进入的日期而不是进入日期）或者引用已经计算出的数据。在此情况下，报文元素的定义和名称必须表达出特定的语义（例如，LastEntryDate）。
4．3．1．4．2 技术性报文元素
技术性的报文元素仅在报文背境下有意义，没有对应的业务元素，因此也没有可追溯的业务元素与之关联。
下面从业务组件中导出报文组件的例子描述了这些原则。
a)生成报文组件“FinancialInstrumentDetails”，并将其与相对应的业务组件“FinancialInstrument”建立可追溯的关联；
b)拷贝属性“IsinIdentifier”和“DescriptionText”，不修改名称和类型；
c)仅为“FinancialInstrumentDetails”生成“NoFinancialIdentification”报文组件。该信息也可以根据报文中该报文组件的存在/不存在得到。
4．3．2 高级导则
4．3．2．1 如何聚合两个报文组件
当两个报文组件相关联时，它们的关系可以通过两种形式表示，一种是使用两个组件间的聚合关系直接表示，另外一种是使用属性间接表示。
——当报文组件为聚合关系时，两个组件之间的联系可明确表示。建模人员可以给聚合关系的“角色名称和定义”附加背景信息。这种表示形式可视性较好，但是会使报文图很快变得很繁杂；
——当使用属性表示报文组件关系时，一个组件的属性指向其他的报文组件。在此情况下，建模人员可以给属性的“名称和定义”附加背景信息。属性的名称等同于前述步骤中聚合关系（角色名称）的名称。该方法可视性较差（关联是隐含的），但是对于复杂的报文，较之聚合关系而言报文图看起来较简洁。这种建模方法在UML中称为“外键”使用属性。
4．3．2．2 如何处理抽象类
报文组件不应基于“抽象”的业务组件之上开发。当业务组件不能实例化时，就将其定义为抽象的。某种程度上，报文组件是业务组件的实现。因此报文组件作为抽象业务组件的实现是没有意义的。
由于抽象业务组件没有可追溯的联结，其追溯性将存在于具体化该抽象业务组件的业务组件。
4．3．2．3 如何处理双向关系
如果两个业务组件间的关联是“双向的”，需要引入多个报文组件以描述该关联的每个方向。这是分层报文定义的结果。
例如，符合GB/T 27926的业务组件关系是通过嵌套相关的报文组件来描述的。两个报文组件的嵌套是指一个组件的定义包含另外一个组件的定义。
所以，如果业务组件“FinancialInstrument”包含业务组件“Market”，而“Market”包含“FinancialInstrument”，这意味着报文实例中包含一个无限循环。在这样的报文组件中，我们仅需通过“被引用”方向进行单向描述关联即可。解决方案是定义一个报文组件，例如，称做“FinancialInstrumentDetail”，它包含所需信息“FinancialInstrument”标识和其引用位置的标识。
4．3．2．4 如何处理关系循环
假设一个例子中包含三个业务组件A、B、C，其中A关联于B，B关联于C，C关联于A，则需要引进多个报文组件以避免递归。原因是报文定义本质上支持分层关系（树状描述），而建模允许定义网状关系。
4．3．2．5 继承
报文组件不应复制业务组件中的继承关系，业务建模中的继承关系允许建模人员将业务概念进行分类。报文组件是为实现需求而开发的，具有有限的可视性。
4．3．2．6 如何优化报文组件
假设业务组件A与业务组件B相关联，报文组件的两种基本定义方式如下：
a)定义报文组件A和报文组件B，通过定义一个A到B的聚合关系来表示两者之间的联系；
b)在报文组件A中追加B所需的报文元素。这个过程称为反向规范化(denormalization)。应谨慎对待这些“被移动的”报文元素的命名。
由于报文元素“背景敏感”，强烈推荐在“被移动的”报文元素的新名称中包含该报文元素的背景信息。
下面的例子说明了，如果将属于报文组件“Account”（关联到报文组件“SettlementDetails1”）的报文元素“Id”，移到报文组件“SettlementDetails2”时，报文元素“Id”应当重新命名为“AccountId”。
4．4 活动：构建报文
对于序列图中确认的每个报文，组合选定的（或者新的）报文组件以生成报文定义图中对应报文的最终结构。
对于符合GB/T 27926的报文定义，其数据结构主要为树状，树的每个分支由对应的组件定义。定义报文组件时规定的原则也适用于设计报文。
为确保所有的报文都以同样的方式构建，应遵守报文元模型中规定的约束条件和规则（见活动“4．3定义报文组件”）。
4．4．1 通用导则
当将报文组件构建成为报文时，基本原则是将报文组件按照“非破坏”的方式联结。如果组件A和组件B需要联结，在构件报文时，应实现这种关系且不能影响A或者B的定义，除非它们总是被联合使用。
应将报文建模为构造型《Message》类。
报文应由报文组件构成。
报文组件建模为构造型《MessageComponent》类。报文组件在构建成为报文时不能被修改。这意味着《MessageComponent》类中不能加入任何属性和聚合关系。
如有必要，应追加关于多样性、选择性、限定性（例如，元素的允许结构）、操作（例如，检查币种代码的存在）和规则（例如，清算日期必须滞后于订单日期）方面的信息（见GB/T 27926．4语法设计规则）。
4．4．1．1 报文粒度
在业务交易开发时，已经采用了很多与报文粒度相关的规定，其主要规定同样适用于构建报文。
4．4．1．1．1 从支持这些过程的数据中分离处理信息
报文不应包含业务过程指示符（购买、出售、生成、删除等）。报文的标识可通过在报文头或报文名中包含指示符或者在报文范围中描述。报文应仅包含支持业务过程的数据，而不应包含业务过程的识别信息或差异信息。
4．4．1．1．2 避免重复性
示例：为不在重复序列中出现币种代码及出现“所有币种代码必须相同”的说明，可在重复序列之外放置一次币种代码。
4．4．1．1．3 避免代码值和组件之间的依赖关系
示例：为了不使用代码“PhysicalDelivery＝yes or no”、地址组件和出现“如果PhysicalDelivery＝yes则地址必须存在”的说明，一个更有效的方法是生成一个组件“PhysicalDeliveryAddress”。
4．4．1．1．4 谨慎使用嵌套组件
示例：如果在InvestmentAccount组件中定义Intermediaries列表，我们会感到当不需要Intermediaries的背景中重复使用这个组件会感到很困难。建议保留InvestmentAccount和Intermediaries作为两个独立的组件，并生成第三个组件来表示两者之间的关系。
----------------
4)注意：业务组件不能在报文模型中直接使用，因其是通用的且没有将报文背景的特殊需求考虑在内。
5 技术设计
技术设计包含一套从逻辑设计模型到最终技术实现的映射规范（例如，GB/T 27926 XML Schema）。在技术设计活动中，报文、协作等的逻辑描述被映射成为目标技术（例如，GB/T 27926 XML）。
技术设计基于一套映射规范，这些映射规范用于自动生成报文和业务交易的可预测表示形式。
称该活动为技术性的是因为它处理的是目标技术环境中报文的技术表示形式（例如，用于报文语法的XML Schema以及用于某些验证规则的编程代码）。
映射规范见“GB/T 27926 XML设计规则”。
6 命名约定
GB/T 27926网站上发布的提交模板及其相关指南中给出了命名约定的详细内容。以下为适用于GB/T 27926库大多数条目的通用规则：
a)使用英式英语词汇；
b)当命名元素时，遵循大多数语法的典型（字符）约束条件：
·所有名称以字母开头；
·第一个字符后面的字符必须是字母或数字字符。
c)使用camel惯例：
·元素和属性的名称可以由包含字母与数字的多个单词复合而成；
·首字母大写；
·词与词之间不留空格。
附录A
（资料性附录）
示例
A．1 业务分析：基金行业业务过程
A．1．1 定义业务模型：订单处理
业务过程图：
图A．1给出了基金行业涉及的所有业务过程：
定义：
投资人发出申购、赎回、过户或者基金转换的指令。
参数：
——操作类型；
——金额、币种或基金份额数量；
——基金代码、基金份额类型（份额种类）；
——账号和账号注册信息；
——交易日期和时间/结算日期；
——结算方式；
——过户代理代码、中间商代码、托管人代码；
——合规证明、分红方式选择；
——佣金信息：类型、金额和收取人；
——请求折扣（如果不同于标准契约折扣）；
——实际交付申请；
——税金信息；
——交易币种。
触发事件：
——投资人/中间商决定；
——企业行为事件（如，分红）；
——标准指令（储蓄计划、储蓄安排等）。
前置条件：
——账户有效；
——基金存在；
——如果需要，（申购）信用额度存在；
——对于转换、过户或赎回，账户的基金份额必须已经结算/生成；
——订单符合基金招募说明书中的规定；
——中间商和投资人是合法（有效）的并经确认。
后置条件：
生成有效指令。
业务角色图（见图A．2）。
业务组件图（见图A．3）。
A．2 需求分析：基金行业信息交换需求
A．2．1 管理订单：定义、参数、触发事件、前置/后置条件
定义：
——基金订单指令和修改；
——基金订单受理确认（可选）；
——基金订单确认。
指令参数：
——操作类型；
——金额、币种或基金份额数量；
——基金代码、账号、投资人代码；
——中间商代码；
——结算类型/日期；
——工具/证券代码；
——（份额、百分比或资金）数量；
——订单发出的时间/日期；
——订单支付币种、结算币种；
——所需外汇；
——取消权、洗钱状态；
——注册指令、注册指定；
——佣金数据。
确认参数：
——订单所有参数，包括价格、费用、税金；
——佣金（由注册登记代理(TA)发送给中间商时）；
——交易登记时间；
——订单价格的核算日期和时间；
——合同金额（税金及费用）的类型和数额；
——估值日期、合同价格和币种；
——注册明细；
——基金代码、账号；
——汇率。
触发事件：
——投资人向其代理提交订单，或者；
——经客户授权，中间商根据客户的交易策略生成订单。
前置条件：
——订单发起人被授权对该账户进行交易；
——账户中的基金份额或现金足够完成交易。
后置条件：
拒绝订单或订单执行被触发。
A．3 逻辑分析：业务交易
A．3．1 订单管理
对于需求用例“订单管理”，我们定义其实现方式，即需要有不同的解决方案和报文流。
在文字和序列/协作图中描述了3种情形，分别表示所有可能参与者/子系统间的报文流。
A．3．2 序列/协作图
A．3．2．1 订单管理直接情形-序列图
A．4 报文设计：组建报文
A．4．1 定义报文组件（由业务组件）
A．4．2 投资基金申购订单-报文模型