银行综合业务系统需求分析说明书 - 图文

银行综合业务系统

需求规格说明书

项目编号 编写日期 版本号

项目名称 编写单位

银行业务综合系统 Object 小组

负责人 周侃

目录

一、引言........................................................................................................................................... 3

1.1编写目的 ............................................................................................................................. 3 1.2项目背景 ............................................................................................................................. 3 1.3定义 ..................................................................................................................................... 4 1.4参考资料 ............................................................................................................................. 5 二、任务概述 ................................................................................................................................... 5

2.1目标 ..................................................................................................................................... 5

2.1.1 用户特点 ................................................................................................................. 5 2.1.2 业务设计目标 ......................................................................................................... 6 2.1.3 开发原则 ............................................................................................................... 7 2.2名词解释 ............................................................................................................................. 8 三、系统概述 ................................................................................................................................. 15

3.1系统概述 .......................................................................................................................... 15 3.2具体架构说明 .................................................................................................................. 17 四、 需求分析 ............................................................................................................................... 17

4.1界面需求 ........................................................................................................................... 18

4.1.1签到界面 ................................................................................................................ 19 4.1.2客户开户界面 ........................................................................................................ 20 4.1.3账户客户界面 ........................................................................................................ 20 4.1.4贷款 ........................................................................................................................ 21 4.1.5签退界面 ................................................................................................................ 26 4.1.6查询 ........................................................................................ 错误！未定义书签。

4.1.6.1账户查询 ..................................................................... 错误！未定义书签。 4.1.6.2贷款查询 ..................................................................... 错误！未定义书签。

4.2交易需求 ........................................................................................................................... 27

4.2.1Teller端 .................................................................................................................. 27

4.2.1.1签到 ............................................................................................................. 27 4.2.1.2签退 ............................................................................................................. 28 4.2.2ESB端 .................................................................................................................... 29

4.2.2.1服务拆分 ..................................................................................................... 29 4.2.3Core端 .................................................................................................................... 29

4.2.3.1客户开户界面 ............................................................................................. 29 4.2.3.2账户开户界面 ............................................................................................. 30 4.2.3.3贷款发放界面 ............................................................................................. 32 4.2.3.4日终 ............................................................................. 错误！未定义书签。

五、数据描述 ................................................................................................................................. 33

5.1 系统描述 .......................................................................................................................... 33 5.2 系统E-R图 ..................................................................................................................... 33 5.3实体及其属性的分析 ....................................................................................................... 37 5.4实体间的关系分析 ........................................................................................................... 38

一、引言

近年来，金融业的竞争开始由低层次向高层次发展，高科技战场将是我国各银行参与竞争、加快自身发展的主战场。银行要保持和扩大市场份额，必须拥有一种明显的、持久的优势。这种优势不是产品的优势，也不是网点的优势，而是高科技的优势。因此，银行电子化是银行提高工作效率，提高管理水平，提高服务质量，加速资金周转，促进社会经济发展的趋势。

随着计算机技术的不断发展，银行电子化水平的提高起到了积极的作用。随着客户金融意识的加强，对银行的选择条件也越来越高，而选择的尺度主要就是银行的服务质量。现在客户对银行的服务要求不仅仅是礼貌服务，更主要的看银行能不能给其提供更多的便利、更好的服务方式、更先进的服务工具来满足他们的各种需要。目前，各银行都投入许多精力，针对客户需求，在保持和完善传统业务的基础上，利用信息高技术开拓了许多新的业务领域，为客户提供了许多新的服务手段。

因此，由于银行有处理大量数据的要求，全部采用人工的方式处理显然不合适。这不仅要花费很高的成本，而且处理事物的效率和质量都存在很大的问题。处于这些问题的考虑，采用计算机来处理这类问题就是一个相当理想的解决方案。利用计算机可以极大地降低处理成本，更重要的是可以几乎没有错误的高效的处理所有的事务。

1.1编写目的

编写该文档的目的是明确“银行综合业务系统”项目的业务背景、业务范围、定义项目的专业名词，分析项目的核心功能和系统需求，为后续的系统设计以及开发人员和测试人员提供功能需求和非功能需求的详细定义，为测试人员提供测试用例设计的功能参考。

该文档为了便于更好地理解客户对软件的需求，对于其软件性能以及功能需求有一明确的目标，对于项目规划以及进度也做了简单的计划。 预期读者：组内成员

1.2项目背景

1. 开发项目名称：银行综合业务系统 2. 任务提出人员：神州数码融信软件有限公司

系统开发人员：神州数码融信有限公司实习小组 Object 系统使用用户：银行系统管理员、业务操作员

3. 此软件将开发银行系统中客户开户、账户开户以及贷款的全过程； 4. 本银行系统将提供银行的管理和客户服务的系统：

? 开发此系统是提高自主创造能力，提高开发过程中团队的交流与协作，最终达到完成银

行系统开发的目的。

? 银行系统管理员进行贷款、查询以及相关业务的审批工作，业务操作员为银行客户提供

客户开户、账号开户等服务。

1.3定义

1、 数据（Data）：数据实际上就是描述事物的符号记录。

数据库（Database，简称DB）：是长期存储在计算机内，有结构的大量的共享的数据集合。

数据库管理系统（Database Management System 简称DBMS）：位于用户和操作系统之间的一层数据管理软件。

数据库系统（Database System 简称DBS）：数据库系统是指在计算机系统中引入数据库后的系统构成，一般由数据库、数据库管理系统（及其开发工具）、应用系统、数据库管理员和用户构成。

2、关系：一个关系对应一张二维表，关系名-表名 属性：表中的一列成为属性，列名即属性名。 字段：标记实体属性的命名单位 3、开发术语

需求：用户解决问题或达到目标所需要的条件或功能；系统或系统部件要满足合同、标准，规范或其它正式规定文档所需具有的条件或权能。

需求分析：包括提炼，分析和仔细审查已收集到的需求，以确保所有的风险承担者都有的含义并找出其中的错误，遗憾或其它不足的地方。

银行系统：基本元素为构成银行储蓄及相关行为所必须的各种部分。

企业服务总线（ESB）：为银行提供一种全面、灵活且一致的集成方法。

1.4参考资料

a. Java编程教程 张孝祥 清华大学出版社 b. JDK_API_1_6_zh_CN.CHM参考文档

c. 《软件工程思想》，2000-2编写，林锐，人民出版社

d. 《Java语言程序设计》，2005-12编写， 郑莉、王行言、马素霞编著，清华大学出版

社

e. 《操作系统概论》，1998-1编写，王珊、张凯编著，高等教育出版社

f. 《JSP应用开发详解（第三版）》，2007-1编写，刘晓华、张健、周慧贞编著，电子工业

出版社

g. 《软件测试》，2006-4编写，张小松、王珏、曹跃编著，机械工业出版社

二、任务概述

2.1目标

银行系统是一个含有数据库的软件系统，通过网络将各个客户端连接起来，可以为银行提供一体化的办公、管理，业务更改，业务办理，业务查询功能，并为银行客户提供各种查询的操作。

2.1.1 用户特点

使用本系统的用户为银行职员（普通职员、贷款审批员、贷款发放员、数据操作员、系统管理员等），该部分用户能熟练操作计算机，至少具有一定的计算机应用水平，

用户对柜面平台系统的使用频度为8小时/天,但是其他时间银行系统仍需要正常运行,保证几乎0%的故障率。 具体使用要求：

? 银行系统管理员（包括系统管理员）：具有较高的的管理水平和计算机操作水平，能够

熟练进行鼠标、键盘操作。管理银行系统的业务员的相关信息，并且拥有对于银行核心

业务如利率调整等进行修改和审批的权限。

? 银行系统工作人员（包括贷款审批员、贷款发放员）：具有较高的业务水平和教育水平，

可以在7天的培训中掌握银行系统的操作方法。管理银行顾客的相关信息，并且为银行顾客提供创建帐号、贷款、贷款审批等服务。

? 普通职员：具有较高的业务水平和教育水平，可以在7天的培训中掌握银行系统的操作

方法。

2.1.2 业务设计目标

（1）登录业务：银行用户输入自己的用户名以及密码在前台进行验证看是否存在该客户。如果登录成功之后可以进入客户办理业务页面；如果不存在或者是用户名密码错误则返回反馈信息。

（2）动态加载菜单模块：不同的用户有不同的角色，不同的角色有不同的权限。不同的权限执行不同的功能。例如“柜员可以进行客户开户、账户开户等业务，对于客户经理则可以为客户办理贷款业务以及查询业务”。

（3）开户业务：当客户需要进行金融交易时需要在银行系统中开一个帐户。这个帐户之后就归客户自己所有。对其账户有了唯一拥有权。客户办理贷款业务。

（4）贷款业务：客户在满足贷款条件之下并且在有担保人的担保下可以进行贷款业务。此业务是经由客户经理办理的。在办理贷款的时候银行会为客户制定还款计划、还款计划明细、回收结算、发放结算、回收明细、计提表、总账表等贷款相关表。

客户在银行中的信誉度直接影响客户贷款金额。贷款人的担保人则应该满足一下条件：具有代为清偿债务能力的法人、其他组织或者公民。

贷款具体流程：

申请 审批 合同 开立 发放 还款计划 通知单 结算 回收 利息计提 回收明细 计划明细 结算

备注：

1. 银行有多个分支机构。每个分支机构位于一个特定的城市，由唯一的名字标识。银行监

控每个分支机构的资产。

2. 每笔贷款由某个分支机构发放，能被一个或多个人共有。一笔贷款用一个唯一的贷款号

标识。银行需要知道每笔贷款的金额以及逐步支付的情况。记录每次付款的的时间及金额。

3. 银行还可以有关于某一天或某一段时间内银行的业务情况的记录，即全部客户和银行之

间的交易记录，每条记录以唯一的流水号标识。

2.1.3 开发原则

1. 统一帐薄，所有帐务集中到后台主机处理。 2. 综合柜员，大量采用集成交易。

3. 可扩展性，系统设计模块化，接口标准化，扩展灵活、方便。 4. 可维护性，大量采用自动生成工具，开发、维护简单。

5. 可隔离性，各业务子系统围绕一个核心，相对独立；各交易围绕业务子系统，互不影响。

2.2名词解释

1.IE

IE（Internet Explorer），是微软公司（Microsoft）推出的一款网页浏览器。

2. Tomcat

Tomcat是一个轻量及应用服务器，在中小型系统和并发访问用户不是很多的场合

下被普遍使用，是开发和调试JSP程序的首选，因为它运行是占用的系统资源小，扩展性好，支持负载平衡与邮件服务等开发应用系统常用的功能；而且它还在不断的改进和完善中，任何一个感兴趣的程序员都可以更改它或在其中加入新的功能。当配置正确时，Apache 为HTML页面服务，而Tomcat 实际上运行JSP 页面和Servlet。另外，Tomcat和IIS、Apache等Web服务器一样，具有处理HTML页面的功能，另外它还是一个Servlet和JSP容器，独立的Servlet容器是Tomcat的默认模式。不过，Tomcat处理静态HTML的能力不如Apache服务器。

3. ESB

ESB全称为Enterprise Service Bus，即企业服务总线。它是传统中间件技术与XML、

Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。 ·ESB的五个基本功能：

1)服务的MetaData管理：在总线范畴内对服务的注册命名及寻址进行管理。 2)传输服务：确保通过企业总线互连的业务流程间的消息的正确交付，还包括基于内容的路由功能。

3)中介：提供位置透明的路由和定位服务；提供多种消息传递形式；支持广泛使用的传输协议。

4)多服务集成方式： 如JCA，Web服务，Messaging ，Adaptor等.

5)服务和事件管理支持： 调用服务的记录、测量和监控数据；提供事件检测、触发和分布功能；

·ESB的八个扩展功能：

1) 面向服务的元数据管理： 他必须了解被他中介的两端,即服务的请求以及请求者对服务的要求，以及服务的提供者和他所提供的服务的描述；

2) Mediation ：它必须具有某种机制能够完成中介的作用，如协议转换； 3) 通信：服务发布、订阅，响应 请求，同步异步消息，路由和寻址等； 4) 集成： 遗留系统适配器，服务编排和映射，协议转换，数据变换，企业应用集成中间件的连续等。

5) 服务交互： 服务接口定义，服务实现的置换，服务消息模型，服务目录和发现等。 6) 服务安全： 认证和授权、不可否认和机密性、安全标准的支持等； 7) 服务质量： 事务，服务的可交付性等； 8) 服务等级： 性能、可用性等。

ESB 中最常提到的两个功能是消息转换和消息路由。

4. Oracle

oracle数据库是一个多用户系统，能自动从批处理或在线环境的系统故障中恢复运行。系统提供了一个完整的软件开发套件，包括交互式应用程序生成器、报表打印软件、字处理软件及集中式数据字典，用户可以利用这些工具生成自己的应用程序。Oracle以二维表的形式表示数据，并提供了SQL（结构化查询语句），完成数据查询、操作、定义和控制等基本数据库管理功能。Oracle数据库具有很好的可移植性，通过它的通信功能，微型计算机上的程序可以同小型乃至大型计算机上的oracle相互传递数据。

它可以支持多种不同的硬件和操作系统平台，从台式机到大型机和超级计算机，为各种硬件提供高度的可伸缩性，支持对称多处理器、集群多处理器、大规模处理器等，并提供广泛的国际语言支持。

5. JMS

JMS(Java Message Service) 即Java消息服务。它提供标准的产生、发送、接收消息的接口简化企业应用的开发。它支持两种消息通信模型：点到点（point-to-point）（P2P）模型和发布/订阅（Pub/Sub）模型。 1)点对点方式（point-to-point）

点对点的消息发送方式主要建立在 Message Queue,Sender,Receiver上，Message Queue 存贮消息，Sender发送消息，Receiver接收消息.具体点就是Sender Client发送Message 到Queue中 ,而Receiver Client从Queue中接收消息和\发送消息已接受\到Quere,确认消息接收。消息发送客户端与接收客户端没有时间上的依赖，发送客户端可以在任何时刻发送信息到Queue，而不需要知道接收客户端是不是在运行。 2)发布/订阅 方式（publish / subscribe）

发布/订阅方式用于多接收客户端的方式.作为发布订阅的方式，可能存在多个接收客户端，并且接收端客户端与发送客户端存在时间上的依赖。一个接收端只能接收他创建以后发送客户端发送的信息。作为subscriber ,在接收消息时有两种方法，destination的receive方法，和实现message listener 接口的onMessage 方法。

注：○1connectionFactory 通过这个工厂类就可以得到一个与JMS提供者的连接

2connection 与○Session。

3session○一个Message 。

4destination 消息发送的目的地，也就是所谓的Queue和Topic。创建好一个消息之○

后，只需要把这个消息发送到目的地，消息的发送者就可以继续做自己的事情，而不用等待消息被处理完成。至于这个消息什么时候，会被哪个消费者消费，完全取决于消息的接者。

5messageProducer 消息的生产者，要发送一个消息，必须通过这个生产者来发送。 ○

○6message() 从字面上就可以看出是被发送的消息。

7send()：发送消息。 ○

○8receiver()：接收消息。

JMS提供者建立的一个连接。可以从这个连接创建一个会话，即

与JMS提供者所建立的会话，通过Session我们才可以创建

6. Socket

Socket也称作套接字，用于描述IP地址和端口，是一个通信链的句柄，应用程序通

常通过“套接字”向网络发送请求或者应答网络请求。两个JAVA应用程序可通过一个双向的网络通信连接实现数据交换，这个双向链路的一端称为一个Socket。

Socket通常用来实现client-server连接。Java.net包中定义的两个类Socket和ServerSocket，分别用来实现双向连接的client端和server端。建立连接时所需的寻址信息为远程计算机的IP地址和端口号（port number）。

7. MQ

MQ(Message Queue):消息队列，是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中寄到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递，如果发送消息时接受者不可用，消息队列会保留消息，直到可以成功传递它。

8.XML

XML(eXtensible Markup Language)是万维网联盟(World Wide Web Consortium W3C)定义的一种可扩展标志语言。可扩展性指允许用户按照XML规则自定义标记(tags标签)，它可以轻松表达多层结构的数据。具有平台无关，语言无关。设计目标是描述数据并集中于数据的内容，与显示分离。

9. DOM4J

DOM4J解析是xml的一种解析方式，它合并了许多超出基本XML文档表示的功能，包括集成的XPath支持、XML Schema支持以及用于大文档或流化文档的基于事件的处理。它还提供了构建文档表示的选项，它通过DOM4J API和标准DOM接口具有并行访问功能。DOM4J大量使用了API中的Collections类，但是在许多情况下，它还提供一些替代方法以允许更好的性能或更直接的编码方法。

10. I/O流

I/O流指输入输出流， 在Java程序中，对于数据的输入（input）/输出（output）操

作以“流”（stream）方式进行，java.io包中定义了各样的“流”类，用以获取不同种类的数据。输入流指的是将数据以字符或字节形式从外部媒体比如文件、数据库等读取到内存中，因此也可以分为字符输入流和字节输入流。输出流指的是将内存中的数据写入外部媒介，也分为字符输入流和字节输入流。

11. 多线程

多线程是这样一种机制，它允许在程序中并发执行多个指令流，每个指令流都称为一个线程，彼此间互相独立。线程又称为轻量级进程，它和进程一样拥有独立的执行控制，由操作系统负责调度，区别在于线程没有独立的存储空间，而是和所属进程中的其它线程共享一个存储空间，这使得线程间的通信远较进程简单。

作为一个完全面向对象的语言，Java提供了类 java.lang.Thread 来方便多线程编程，这个类提供了大量的方法来方便我们控制自己的各个线程。JAVA实现多线程的两种方法：继承 Thread 类和实现 Runnable 接口。

12. 线程同步

由于同一进程的多个线程共享同一片存储空间，在带来方便的同时，也带来了访问冲突这个严重的问题。Java语言提供了专门机制以解决这种冲突，有效避免了同一个数据对象被多个线程同时访问。

13.PL/SQL

PL/SQL也是一种程序语言，叫做过程化SQL语言（Procedural Language/SQL）。PL/SQL是Oracle数据库对SQL语句的扩展。在普通SQL语句的使用上增加了编程语言的特点，所以PL/SQL就是把数据操作和查询语句组织在PL/SQL代码的过程性单元中，通过逻辑判断、循环等操作实现复杂的功能或者计算的程序语言。

PL/SQL是Oracle对关系数据库语言SQL的过程化扩充,它将数据库技术和过程化程序设计语言联系起来,是一种应用开发语言,可使用循环,分支处理数据,将SQL的数据操纵功能与过程化语言数据处理功能结合起来. PL/SQL的使用,使SQL成为一种高级程序设计语言,支持高级语言的块操作,条件判断,循环语句,嵌套等,与数据库核心的数据类型集成,使SQL 的程序设计效率更高. · PL/SQL程序的基本结构

PL/SQL块由四个基本部分组成：声明、执行体开始、异常处理、执行体结束。 ·PL/SQL的变量

PL/SQL程序包括了四个部分，在四个部分中，声明部分。主要用来声明变量并且初

始化变量，在执行部分可以为变量赋新值，或者在表达式中引用变量的值，在异常处理部分同样可以按执行部分的方法使用变量。另外，在PL/SQL程序使用时可以通过参数变量把值传递到PL/SQL块中，也可以通过输出变量或者参数变量将值传出PL/SQL块。

14.冲正

冲正就是回滚交易 。

即一笔交易在终端已经置为成功标志，但是发送到主机的帐务交易包没有得到响应，即终端交易超时，所以不确定该笔交易是否在主机端也成功完成，为了确保用户的利益，终端重新向主机发送请求，请求取消该笔交易的流水，如果主机端已经交易成功，则回滚交易，否则不处理，然后将处理结果返回给终端。

15、过滤器

过滤器通过截取从客户端进来的请求，并做出处理的回复。它可以说是外部进入网站的第一道关。在这个关卡里，可以验证客户是否来自可信的网络，可以对客户提交的数据进行重新编码，可以从系统里获得配置的信息，可以过滤掉客户的某些不应出现的词汇，可以验证客户是否已经登录，可以验证客户端的浏览器是否支持当前的应用，可以记录系统的日志等。

可以为一个Web应用组件部署多个过滤器，这些过滤器组成一个过滤链，每个过滤器只执行某个特定的操作或检查。这样请求在达到被访问的目标之前，需要经过这个过滤链。如果由于安全的问题不能访问目标资源，那么过滤器就可以把客户端的请求拦截。

Web应用的请求传递图：

客户端 Filter1 Do filter Filter1 目标组件 过滤链 2.3 软件支持

操作系统： Windows Xp / Windows7 SP的版本： Sp3 数据库： Oracle 10g

2.4 硬件支持

硬盘空间：5G 以上 内存：128M

2.5 运行环境

软件运行环境

WINDOWS平台：WINDOWS98/NT/2000/XP/7 可选： WINDOWS TUXEDO 客户端 UNIX平台：SCO UNIX，AIX平台

可选： WINDOWS TUXEDO 客户端 LINUX平台：红旗LINUX

2.6 条件与约束

2.6.1本项目是否能够成功实施，主要取决于以下条件：

1. 开发小组为了项目的开发和实施，必须对项目的业务流程进行合理的分析与整理，形成

完善的软件需求。

2. 用户应具有适合项目软件的工作环境和系统运行环境。 3. 用户应满足项目系统的硬件环境与通讯环境。

4. 开发小组采用先进的、兼容性强的语言Java进行编程以及先进的技术保证系统的性能

的优化与项目的成功。

5. 开发小组具有相对稳定的项目的团队，不稳定的团队将影响项目的进度和质量。 6. 开发时间是一个连续的时间段，有利于开发软件的连续性，不连续的开发时间将影响项

目的进度与质量。

2.6.2 约束条件：

1. 成本约束：因本项目仅为人员实习的培训，故不考虑人员成本；因无物质采购，故不考

虑物质成本；所需的成本仅为编程过程中的电费，一切由公司承担。 2. 规模约束：此项目有1个项目小组的人员共同完成，人数为8人 3. 完成日期：2011年12月1日

4. 设备约束：自带笔记本，无网络环境。

5. 技术约束：主要使用Java语言开发，系统操作界面为IE界面

2.6.3设备要求

1. 硬件要求：PC机8台。 2. 软件要求：

安装有MyEclipse开发工具；

安装有JAVA SDK的WINDOWS操作系统；

安装有消息队列服务器apache-activemq，作为项目所用的JMS服务器； 导入dom4j、activemq等jar包实现接口对XML进行简单的增删查改操作； 安装Oracle 10g 安装Toad for Oracle 安装Power Designer 安装PL/SQL Developer 安装tomcat

三、系统概述

3.1系统概述

银行综合业务系统平台采用B/S架构，用户可通过PC机采用浏览器的方式访问系统。通过管理不用的数据源，管理平台可以进入不同的交易界面。

平台主要功能是处理和管理业务平台的数据、系统配置、人员、业务交易等。

柜台Teller ESB企业服务总线 业务处理平台 支付业务 金额支付 支持业务 产品业务/日志业务； 渠道管理业务； 签约管理业务； 权限管理业务 ESB企业服务总线 Core DB

各模块功能目标：

(1)Teller端功能目标：用户通过输入其网点号、机构号、用户名和密码，其用户信息进入不同的客户业务办理页面。当用户信息不存在或者是用户信息错误的时候，将反馈信息以界面的形式显示给用户，提示用户信息错误。将用户办理业务所需要的信息以XML的形式经socket传送给ESB端。同时teller端接收ESB端经处理过的客户反馈信息和处理结果，这些消息是以XML的形式经socket传送过来。

（2）ESB端功能目标：ESB端要求实时监听teller端，对teller端发来的请求进行验证其系统码和服务码，解析判断是那种服务类型。需要将其判断结果组包封装到消息队列传送给Core端。在ESB端要及时快速并准确地进行判断，并且要能够准确无误的处理多个客户端发来的消息，以及同一客户端反复发送的多个请求，不允许发生消息的串包问题。同时ESB端也将接收从Core端处理之后的所有信息封装到消息队列中的。也将这些消息经socket传送给teller端。

（3）Core端功能目标：ESB端对从消息队列中传来的消息要及时迅速地做一解析处理，对

XML中的数据也要做及时迅速处理 ，保证对XML同时进行的操作不会发生冲突。同时也要将其封装到消息队列返回给ESB端。

3.2具体架构说明

图3-1 系统总体架构图

系统功能实现的基本流程：

1IE端向Teller端发送报文； ○

2Teller端将接收到的报文通过Socket发送给ESB，并记录流水记录； ○

○3ESB将接收到的报文通过doService 原子服务将报文放入请求消息队列ReqMQ，并记录流水记录；

4Core从请求消息队列ReqMQ中取出报文并解析，并记录流水记录； ○

5Core通过解析的结果来调用存储过程操作数据库； ○

6Core将操作处理的结果返回； ○

○7Core将操作处理的结果返回给响应消息队列RespMQ，并记录流水记录，修改记录流水状态信息；

8ESB从响应消息队列RespMQ中取出返回结果； ○

9ESB将最终处理的结果通过Socket返回给Teller端，并记录流水记 ○

录，修改记录流水状态信息；

10Teller○给

IE端，并记录流水记录，修改记录流水状态信息。

端在接收到处理结果后，作相应的记录，再将处理结果返回

四、需求分析

4.1界面需求

1. 系统界面颜色由设计者自己设定，采用全屏格式，界面的风格鲜明而又特色； 2. 报表格式：以银行原报表格式设计电子打印表格式； 3. 系统上要有足够的导航链接；

4. 要尽量让用户使用鼠标完成整个操作流程，当然填写资料；

5. 界面将采用交互式界面，简化界面设计，以文本框和按钮为主要功能部件，完成输入、

修改、确定、取消等业务功能。

4.1.1签到界面

该界面为柜员签到界面，在该界面上填入柜员的登录名、登录密码、机构号和网点号，然后点击“登录签到”，如果填写的所有信息都正确，则签到成功，进入主界面。如果输入的某项信息有误，则点击“登录签到”按钮后出现提示出错信息，错误包括“登录名不存在”、“密码错误”、“机构号错误”或者“网点号有误”。

签到成功界面

4.1.2客户开户界面

该界面为客户开户界面，需要开户的客户填写完开户信息后，将开户表单交给柜员，然后将开户信息录入系统，信息包括：客户编号 、中文名、英文名、证件号、证件类型、客户简称、性别、地址信息、国家、地区区号、联系方式、客户类型、城市、邮编、移动电话、客户分类。

4.1.3开户界面

账户界面：客户需要贷款时先和银行签订贷款合约，柜员将合约的信息录入系统，贷款信息包括：账号、客户号、证件号、中文名称、客户类型、账户状态、账户币种、存款类型、开户日期、账户类型、客户简称、英文名、客户经理等。对于其中的身份证要求有验证身份证号码位数。对于其客户进行账户开户所办理的类型及账单存折标识都可以进行选择。

4.1.4贷款发放界面

该界面为在客户在贷款开立签约后，获得贷款号，填写相关资料确认需要贷款的金额，并了解利率相关信息，进行贷款发放。

4.1.5贷款发放结算界面

该界面为在贷款发放以后，用来确认贷款发放的相关信息，最终确认贷款发放。

4.1.6贷款计提调整界面

该界面为手动录入变更的利率信息造成利息计算的错误，来更改数据库的利息信息。

4.1.7贷款本息通知单界面

该界面为在贷款规定还本付息的前一个星期需要出通知单告知贷款人需要及时还清利息。

4.1.8贷款回收界面

该界面用于进行贷款回收。

4.1.8贷款回收结算界面

该界面用于银行在回收相关利息及贷款金额的汇总处理。

4.1.9贷款日终界面

日终处理是指银行在每天营业结束后，中心对账务系统进行一系列批量处理的过程。随着银行业务的飞速发展和银行金融产品的日益丰富，日终处理的过程也越来越复杂。银行界数据大步伐的加快，也意味着日终处理系统要面对日益庞大的账务系统。目前，各家银行业务越来越广泛，计算机处理的程度也越来越高，相应数据中心日终处理的内容变得复杂，处理时间也随之增加，这就给做日终处理的工作人员带来压力，容易造成多做、少做或重复做，影响第二天的正常营业。因此，使日终处理更加高效、可靠和灵活是至关重要的。

4.1.10签退界面

点击此处退出系统

柜员每天在进行一天业务之后需要对业务进行核查以确保业务正常办理。下班时需要退出系统时，柜员则可以点击右上角的“退出”按钮后，出现提示框：

点击“确定”，签退成功！

当柜员已签到则可以进行正常地签退业务；假设柜员已经签退则网页会提示反馈信息“您已签退！不能再签退！”

4.2交易需求 4.2.1Teller端

4.2.1.1签到

4.2.1.1.1功能需求

柜员要工作必须要进行签到，签到后才能进入系统为客户服务。每个机构的每个网点

下每个柜员都有唯一的编号，签到时柜员需要输入自己所在的机构号、网点号、柜员编号以及密码，输入正确进入系统后，会在登录表中记录该柜员的登录信息。 签到的流程图如下：

成功登录， 进入系统 信息正确？ 是 否 点击柜员签到 填写机构号、网点号、柜员编号、密码 提示出错信息 签到界面 柜员

柜员在打开IE进入柜员签到界面后，需输入柜员信息进行签到操作，如输入自己专属的：机构编号、网点编号、柜员帐号、密码等并点击“签到”，如输入正确无误后，则界面会出现签到成功的提示语，这样即可完成签到操作，签到完成之后才可以进行如客户开户、账户开户和贷款等其他的各种银行业务的操作。

4.2.1.1.2性能需求

1. 响应时间：5秒之内 2. 更新处理时间：3秒之内

3. 数据的转换和传送时间：3毫秒之内 4. 并发性能：允许1000个柜员同时进行操作 5. 大数据量性能：100M

4.2.1.1.3接口

4.2.1.2签退

4.2.1.2.1功能需求

柜员完成所有的任务后到下班时间或者有事需要离开柜台，就需要执行签退服务，不能转身就走，也不能直接关闭操作页面，如果直接关闭可能导致下次不能正常登录。签退时只需要点击签退操作，确认签退，此时系统会记录柜员的签退信息。

4.2.1.2.2性能需求

1. 响应时间：5秒之内 2. 更新处理时间：3秒之内

3. 数据的转换和传送时间：3毫秒之内 4. 并发性能：允许1000个柜员同时进行操作 5. 大数据量性能：100M

4.1.2.2.3接口

4.2.2ESB端

4.2.2.1服务拆分

根据客户端不同的服务请求，向服务器发送相应的请求。

4.2.3CoreBank端

4.2.3.1客户开户 4.2.3.1.1功能需求

开户是客户在银行办理业务的第一步。首先客户要选择一家银行，然后再到该银行填写资料并由银行工作人员进行录入，并且为了安全问题，生成一个账户初始密码，只有客户本人能够对密码进行维护。开户流程图如下：

确定一家银行 客户 填写纸质材料 查 开 户 材 料正检 确并录入

银行工作人员 系统审核信息是否合法

是 开户处理表 账户信息表 记录开户信息 客户向银行提出开立账户要求；

柜员在系统主界面请求创建账户操作，系统常见账户界面； 柜员添加账户信息后，提交至账户类；

账户类确认数据库是否已存在该客户的账户，如不存在，则创建新客户对象； 然后将客户信息保存到数据库中；

柜员在Teller端系统界面上点击“开户”按钮进入开户界面，填写用户基本信息（姓名、性别、身份证、），点击提交，无误则开户成功。

4.2.3.1.2性能需求

1. 响应时间：5秒之内 2. 更新处理时间：3秒之内

3. 数据的转换和传送时间：3毫秒之内 4. 并发性能：允许1000个柜员同时进行操作 5. 大数据量性能：100M

4.2.3.1.3接口 4.2.3.1.4其他需求

4.2.3.2账户开户

4.2.3.2.1功能需求

账户开户是在客户开户后进行的。客户开户后，客户可进行账户开户，方便对账户进行操作，开户流程图如下：

客户 填写账户开户申请 否 审核信息是否正确 是 记录账户信息 账户处理表 账户信息表

客户向银行提出开立账户要求；

柜员在系统主界面请求创建账户操作，系统常见账户界面； 柜员添加账户信息后，提交至账户类；

账户类确认数据库是否已存在该客户的账户，如不存在，则创建新客户对象； 然后将客户信息保存到数据库中；

柜员在Teller端系统界面上点击“开户”按钮进入开户界面，填写用户基本信息（姓名、性别、身份证、），点击提交，无误则开户成功。

4.2.3.2.2性能需求

1. 响应时间：5秒之内 2. 更新处理时间：3秒之内

3. 数据的转换和传送时间：3毫秒之内 4. 并发性能：允许1000个柜员同时进行操作 5. 大数据量性能：100M

4.2.3.2.3接口 4.2.3.2.4其他需求

4.2.3.3贷款

4.2.3.3.1功能需求

用户由于要进行某种活动资金不足时，需要向银行等金融机构贷款来达到他们的目标，这个时候就需要和银行签订贷款合约。一句话，贷款合同就是借款人想贷款人借款，到期返还借款并支付利息的合同。贷款的内容包括借款种类、币种、用途、数额、利率、期限和还款方式等条款。

审核是否通过 是 借贷双方签订贷款条约 否 拒绝贷款 借款人提出贷款申请，并提交相关资料 贷款机构按相关规定对借款人的条件进行审核

贷款方为借款方按发放计划发放贷

大堂经理将贷款人需要填写的贷款人基本信息和贷款信息的合约打印出来让贷款人填

借款方按回收计划返还利息及贷款 写，填完后将表单交给柜员，柜员进入贷款界面将贷款人填写的信息录入系统，正确填写后点击提交按钮，无误则贷款初步完成，以后银行按照发放计划和回收计划给客户发放贷款和回收贷款和利息。

4.2.3.3.2性能需求

1. 响应时间：5秒之内 2. 更新处理时间：3秒之内

3. 数据的转换和传送时间：3毫秒之内 4. 并发性能：允许1000个柜员同时进行操作 5. 大数据量性能：100M

4.2.3.3.3接口 4.2.3.3.4其他需求

五、数据描述

5.1 系统描述

该系统分为teller服务端、ESB、core核心数据处理。

Teller ESB MQ IE Core Java procedure 存储 过程 存储过程 调用 Tomcat Servlet1 Servlet2 Servlet3 服务 1）判断服务码 2）取服务码 3）判断服务类型 4）组包发送 ReqMQ RespMQ DB DB DB DB

5.2 系统E-R图

Teller业务：

用户表链接：用户角色对照表、角色权限对照表、角色定义表、权限定义表、用户基本信息表（不同的用户有不同的角色，不同的角色有不同的权限） 其中机构表和网点表是为用户进行登录时记录登陆日志时所用的表。

用户进行登录或者是签退时都必须进行记录流水信息。这样对于银行管理员来说查询起来就方便，同时对于每一笔交易来说如果不成功则可以根据流水号进行冲正操作。对于流水表历史信息则对于银行的日终业务有作用。进行日终处理时要根据其内部的日终配置和参数进行相应操作。

对于凭证定义和凭证分配

ESB：

流水表：记录每一笔交易的交易时间、流水号、前端流水号、账号、交易码等，根据这些对于银行管理员的查询以及不成功业务的冲正操作是必须的。对于每一笔交易都必须记录其流水信息。对于流水表历史则是在一个时间段之后将所有的流水表信息放置于流水表历史表里以便提供给以后银行日终处理。

服务对照表则是根据其客户需要办理的业务将其转换成相应的服务码将其传送至核心数据库中去。

日终配置和参数是进行日终处理时所需要的一些依据和参数。

Core端：

贷款开立表：客户需要办理贷款业务需要进行填写一个开立表 贷款发放表：对于贷款分几次发放 还款计划表：对于还款的计划

还款计划明细表：还款计划的进一步划分 贷款发放结算表：发放贷款的结算 计提表：记录每一笔贷款的利息

发放变更表：发生某些事导致发放贷款发生变化

通知单信息表：在发放贷款、回收贷款时系统会自动提醒用户进行发放和回收贷款， 贷款回收信息表：

回收明细信息表：对于回收的每一笔贷款本金和利息分别汇入哪个账号，对于每一次发放贷款的具体时间、利率

贷款回收结算表：对于回收明细信息表的汇总 会计分录设置表：

贷款总账信息表：记录整个贷款交易的信息汇总 总账表：

5.3实体及其属性的分析

客户到银行办理业务，则必须有银行内部的工作人员帮其办理，银行员工每办理一个业务，为了以后责任的问题或是记录问题，则必须要在记录里写上自己的名字，而名字不能唯一标志员工，所以银行必须为每个员工确定一个可以唯一标志他们的员工编号。从银行管理方面来讲，银行必须记录其员工的一些信息，比如员工姓名，性别，以及其开始工作的时间，这样以便日后得知其雇佣总时间长；为了方便联系，则必需保存员工私人电话，家庭电话和办公室电话；且应该知道员工的家庭住址。

银行员工 工作编号 工作起始时性别 姓名 联系方式 家庭地址 银行客户在银行办理业务，则银行管理方面则必须知道唯一标志客户的身份证号，客户的姓名，年龄，性别，联系电话，家庭住址。

这里抽象出实体银行客户：

银行客户 客户身份客户姓名 客户年龄 客户性别 家庭住址 联系方式

客户在银行办理业务时，必须拥有账户，客户必须知道此账户的密码，才能对其操作；般情况下，客户还可以根据需要知道该账户上的余额；该账户的所属银行。如果是贷款账户，

客户还应该知道这个账号的最大透支额。而对于银行管理来说，银行必须知道此账号的种类，看它是办理那种业务，为了方面日后的记录，银行还必须记录此账户初始建立时间，是哪位员工代理的。

因为账户与账户类型是选择的关系，不可能是包含的关系，所以账户类型必须另外

建立在一张表上。

当客户查自己账户的贷款历史记录时，这是银行必须建立这样的记录，此记录肯定

要记录以往客户所拥有的账户，及其当时交易的金额，账户所留余额，还有当时交易的时间，以便满足账户的查询。

一般银行的管理人员必须要知道自己银行的每天运营情况，这样银行管理系统中就

必须有一张详细的交易记录表。一般情况下，管理人员要知道交易的账户，交易类型，交易金额，交易时间，贷给客户的利息。

5.4实体间的关系分析

银行员工与账户，一个银行员工可以给很多账户办理业务，但一个账户在同一时间

内只能让一个员工为其办理，所以是银行员工与账户一对多的关系。

客户与账户，一个客户可以拥有好几个账户，一个账户只能被一个客户共同拥有，

所以客户与账户是一对多的关系。

账户与账户类型，一个账户只能是账户类型中的一种，所以是账户与账户类型是多

对一的关系。

账户与相应的账户的记录，账户可以由多条记录，而一天记录只能是某一个账户的

信息，这条记录也只能是被一个员工处理，所以账户与相应的账户的记录是一对多的关系，账户记录与员工的关系是多对一得关系。

交易记录，一个银行可以由多个交易记录，而一条交易记录之能是某一个银行的。

交易记录只能是某一账户的记录，而一个账户可以交易多次，一个员工可以办理多个交易，而一个交易只可能是某一个员工办理，交易记录只可能属于交易类型中的一种，而一种交易类型可以对应多个交易记录。所以交易记录与银行、账户、员工和交易类型都是是多对一的关系。

2、各实体间的总关系。

银行 交易 管理 交易类型 交易记录 员工 服务 账户 客户 拥有 账户类型

本文来源：https://www.bwwdw.com/article/6erp.html