金融服务逻辑分析

1、金融服务逻辑分析一、简介1、目的逻辑分析的目的是详细描述待开发业务交易和报文集的细节。因此本阶段的重点是定义报文流和报文，用于在正确的时间从正确的业务角 色获取所需的信息。本阶段仍从单纯的业务视角看待业务交易和报文集，也就是 说从语义的视角（即潜在的业务含义而非语法的视角（即报文的表达及其规那么）0 所有的结论均源自需求分析阶段已确认和说明的需求（功能需求和约束）。逻辑分析之所以称之为逻辑的，是因为它从一个抽象的视角描述业务交 易和报文集，而不是从具体的、技术的视角。这种抽象的方法使其在不同的技术 表示形式间保持互通性。2、关键主题解决方案的总体架构是什么？参与报文交换的子系统是什么？我们需

2、要寻找一个端到端的还是星形结构的解决方案？业务交易是什么？不同报文可按照经确认允许的多个报文流的方式进 行交换；从业务内容角度描述的报文是什么？交换的信息应具有业务价值，报 文组件/元素应源自业务分析和需求分析阶段确定的业务组件/元素并由之定义;适用于各种业务交易和报文的规那么是什么，每条规那么的范围是什么？ 如果范围仅是报文，那么规那么仅针对报文的内容；如果范围是业务交易，规那么将针 对全部业务交易信息检验报文的内容（例如，之前交换的报文包含的信息）03、主要活动确定解决方案的总体架构；将需求用例提炼成为具体的业务交易。基于该业务交易，确定报文、 主要的报文流及其相关规那么；设计报文，即确定

3、业务内容、总体架构、报文组织和报文适用的规那么。4、交付内容业务交易图（包含业务交易的结构化描述）；当为星形结构系统时，对（子）系统架构的文字描述；序列图（即业务交易背景下的典型报文交换）。二、过程概览下列图给出了在本阶段开展的不同活魂以椭圆形表示泳口需要的输入输出（以 矩形表示）。这些活动在下文中有详细描述。定义架构定义业务交易三、活动1、定义架构定义解决方案的架构，即确定包含在业务交易中的各个子系统。子系统是业务交易的边界，即标准制定者不需对发生在这些子系统中的应用细节 进行标准化，而只需对这些应用间的信息交换（接口）进行标准化。对子系统及 其活动的详细说明有助于定义所需的报文流；如何确定

4、子系统？虽然我们不关注与业务参与者个体，但事实上，它与业务交易中充当业务角色的业务参与者的类型存在联系。所以，最好在此时将 子系统定义和业务参与者类型的定义结合起来：确定是否涉及主系统（例如，传输流监控（TFM）、市场基础架构）。如果涉 及，针对每个主系统应有一个子系统与其相连；将子系统与每个类型的业务参与者进行关联，这些业务参与者将充当一个 或多个相关的业务角色。某些情况下，可将多个业务角色结合到一个子系统。这 需要根据子系统行为的基本共性或个性决定。同一业务参与者是否充当多个业务 角色的情况也对其产生影响。在其他情况下，可能有必要为单一业务角色预先考 虑多个子系统。例如，如果多种类型的业务

5、参与者能充当同一业务角色，并且业 务参与者的类型对子系统的行为及其信息交换需求存在显著影响时，就有必要为 该业务角色预先考虑多个子系统。子系统可通过类图描述。2、定义业务交易综合考虑定义的子系统，描述子系统实现需求用例的方法（即子系统 是如何互相作用的）和该过程中需要的信息流；业务交易应至少通过文字和序列图描述，以给出子系统间的信息流。 可选地，可以加上协作图（注意，协作图可从序列图中自动导出）。业务交易的 描述将提供关于子系统间信息流（报文）的信息、这些流发生的顺序、特殊情况 的处理、以及与每个信息流有关的触发事件、前置和后置条件；对于每个确定的信息流，定义报文名称、报文内容和初步的报文结构

6、 （即按照逻辑，哪些信息应放到一起），且在序列图（与每个信息流关联）中说 明这些信息。报文内容可根据不同业务活动需要的和提供的信息加以确定。在本 阶段，也可以给出有关多样性、选项和规那么描述方面的信息。如果必要，也应确 定信息流是同步还是异步、是推还是拉等；如必要，可提炼子系统类图。四、导那么1、概述在多数情况下，基础架构（即端到端或者星形结构）由最初的需求决 定；典型的金融行业中，业务参与者类型包括：银行、代理机构（例如， 经纪人、投资经理等）以及企业等；同业务角色一样，业务参与者也是数据字典的一局部。在工程中，它 们被加入到业务角色图中（但应明确标明他们是业务参与者）0在业务角色图中 也给

7、出了业务参与者及其充当的业务角色之间的联系；通常每个需求用例能（并且将）按照多种业务背景实现。对于每种业 务背景，应由单独的业务交易进行定义并描述；业务交易也应考虑（进而描述）非常规处理、错误处理、确认等。这 些处理可导致附加序列图的产生；应注意，一个业务交易仅是描述一组需求的一个可能的解决方案。针对 同样的问题可能有多个解决方案。在此情况下，对于同样的需求用例可能会有多 个业务交易；在确定业务交易时，业务交易可以是其他业务交易的特例、扩展或者组 合。对于这种情况，可以使用包含、扩展和泛化关系。2、报文粒度应遵循报文粒度的初始规定（以下规那么将对441.1报文粒度建模导那么产生 影响）：报文要

8、明确且符合特定目的。报文细化会导致大量报文的产生，因此 在特定情况下，需要借助某些帮助来选取适合应用的报文。可以通过自上而下的 方法依次确定业务领域、业务过程、业务交易和报文。利用该方法，可生成准确 但业务功能有限的报文。这些报文具有较少的可选域，因为可将报文中进一步定 义报文功能的元素去掉，因此报文也较短。所有这些，简化了实现和维护，并最 终导致了较高的直通交易处理（STP）率；例如：在证券买卖时，我们需要的信息不同，返回确实认信息也不相同，因 此导致了不同报文的产生。最低原那么是为不同功能定义各自的报文（例如，用于生成、修改、撤 消的报文，用于指令和报告的报文）；对于不同类型的金融工具，原

9、那么上使用同一报文来涵盖，除非它们的 差异不仅仅在于对金融工具的描述（例如，如果使用了其他金融工具，那么必须在 报文中标识其他参与方）；对于“市场惯例，原那么是首先集中生成一个独立于市场惯例的报文（即包含所有共性的报文），然后，我们可关注特定的市场惯例，确定更多有关 多样性、数据类型和规那么的特定的信息及需求并根据差异的要求程度生成在同一 报文定义下的不同变体和/或覆盖多个市场惯例需求的报文定义；对于充当同一业务角色的多个子系统，与市场惯例遵循的原那么类似。首先集中于子系统间的共性。然后，确定其在信息需求、多样性、数据类型和规 那么方面的区别并根据差异的要求程度,生成在同一报文定义下的不同变体和 /或覆盖多个子系统需求的报文定义；验证生成多个报文定义（有多个变体的）较生成单个报文是否有意义 的有用工具是，考虑为了生成多个显式的报文，从报文定义中去掉一个特定组件 或元素后所产生的影响。如果去掉组件或元素导致了大量报文的产生，那么不宜生 成多个报文（例如，