银行押汇交易数据录入系统论文.doc

毕业设计（论文）

设计（论文）题目 永亨银行押汇交易数据录入系统

学生姓名
学生学号
专业班级
指导老师
院长 (系主任)

年 5 月 22 日

毕业论文 第 37 页
永亨银行押汇交易数据录入系统
摘要
押汇是银行基本外汇业务之一，随着外汇业务的发展，永亨银行押汇业务的用户量将越来越多，业务的繁忙使得原本的手工填写多种登记簿的业务处理方式变得烦琐而且不利于管理。因此，构建一个便于登记和管理押汇业务中与会计分录不相关的有关业务的平台是提升银行服务质量的根本。SDR818押汇交易数据录入系统正是这样一个系统，它能提供记账、复核双人临柜联机交易，联机打印输出相关面函以及提供相关的批量处理，生成交易日志报表。
本论文重点论述了押汇交易数据录入系统(Bills Register System, BRS for short)的应用系统（前台的设计与实现。作为一个提供联机交易的系统，其前台的设计是相当重要的一部分。这里将对BRS三个功能模块：记帐、复核和查询进行详细描述。另外，一个需要处理大量数据的企业级系统，其数据库的设计也是一个非常重要的部分，但因其设计的复杂度及与Core Bank其他系统有着很大的关联，所以这里将简单介绍一点。同时，本文还对该系统的安全机制作个简单描述，因为对于一个银行业务处理系统而言，其安全性是最最重要的。
本系统的设计应用了J2EE相关技术，使用IBM的Rational Application Developer作为开发工具，数据库系统采用Oracle实现。

关键字：押汇，记帐，复核，数据库
Bills register system for Wing Hang Bank

ABSTRACT
Negotiation is one of the basic operations in foreign exchange of bank. As the development of the foreign exchange, the amount of consumers using negotiation operation in Wing Hang Bank becomes more and more. The busy business makes the operating method of filling in registers by hands disordered and against to management. Therefore, to set up a system for related operations easy to register and manage negotiations which is dissertated to accounting is the fundamentality for improving the quality of bank services. SDR818 Bills Log Register System is the right one. It can offer online operation on the counter for accounting and double checking, print outing related envelop and it can offer interrelated batch disposal to build log report forms.
This thesis is emphasis on discussion to design and carry out the application system (prelude) of the Bills Register System (BRS for short). As a system providing online operation, the design of prelude is a quite important part. The thesis will elaborate in detail three function modules of BRS, that is accounting, checking and query. Besides, a corporation system which needs to deal with a great deal of data, the design of its database is also significant. But its complexity and its prodigious relation to other systems in Core Bank, so the author will introduce it simply. In addition, this thesis describes the system's security mechanisms in brief, since the security is crucial in a bank business operation system.
The design of this system applies some technologies of J2EE, exploration tools of Rational Application Developer, and the database system is carried out with the adoption of oracle.

Keywords：negotiation, accounting, review, database
目录
1. 绪论 1
1.1. 问题的引入 1
1.2. 研究目标及其内容 1
1.2.1. 研究目标 1
1.2.2. 研究内容 1
1.3. 文章的组织 2
2. 系统相关技术 3
2.1. J2EE技术 3
2.2. XML 3
3. Core Bank系统的技术 5
3.1. Core Bank系统简介 5
3.2. 系统架构采用的技术 7
3.3. 系统安全技术 8
3.4. 系统兼容性技术 9
3.5. BRS系统的新技术 11
4. 应用系统的设计与实现 13
4.1. 问题的引入 13
4.2. 需求分析 13
4.2.1. 功能需求 13
4.2.2. 用户界面需求 14
4.2.3. 性能需求 14
4.3. 系统设计 15
4.3.1. 总体设计 15
4.3.2. 模块设计 15
4.4. 各功能的详细描述 16
4.4.1. 记帐模块 16
4.4.2. 复核模块 19
4.4.3. 查询模块 19
5. 数据库的设计与实现 23
5.1. 问题的引入 23
5.2. 问题分析 23
5.3. 数据库概念模型的设计 24
5.4. 数据库数据模型的设计与实现 27
6. 系统安全机制的设计与实现 33
6.1. 系统安全的重要性 33
6.2. 系统安全机制的实现 33
总结与展望 35
致谢 35
参考文献 37

软件学院
1. 绪论
1.1. 问题的引入
目前永亨银行中国部的押汇业务分散在Core Bank系统的DEP、LNS或RMT等子应用系统入账中。为了对账和分类统计的需要，用户在处理业务的过程中，手工填写了多种类型的登记簿，以记录未存入Core Bank系统的重要信息。这样一方面增加了大量的手工劳动，另一方面也不利于银行业务运行应急和连续性计划(BCP)的部署实施[1]。
因此，拟在Core Bank系统新增一些联机交易，允许用户按照特定的格式录入手工登记簿的内容，自动生成预定格式的面函（例如：信用证通知），并将登记簿的内容在Core Bank系统存档，方便用户随时查询登记簿的内容，并定期生成必要的分类统计报表。
1.2. 研究目标及其内容
1.2.1. 研究目标
本项目(BRS)是香港永亨银行Core Bank系统中的子项目，系统于2001年投入生产，使用J2EE架构＋企业级数据库Oracle，具有易移植和可扩展的特点，适应银行业务的扩大。该系统包括一系列子系统如SC、DEP、CIF、RMT、BRS、LNS等，每个子系统又包括Online和Batch两个部分，分别处理即时交易和批处理任务。
BRS的目标是提供联机交易，解决银行押汇业务操作繁琐的问题，将押汇业务中与会计分录不相关的有关业务，在Core Bank系统以登记簿的形式进行登记和管理，联机打印输出相关通知书或面函，取代之前需要手工填写的登记簿。并提供相关的批量处理，生成交易日志报表和跟踪管理报表，通过联机分发到各个支行或者提交到香港总行，以作为日后统计和审查的依据。
1.2.2. 研究内容
本项目和Core Bank系统中的其他项目一样分Online和Batch两个部分。Online是白天处理柜台、电话银行以及其他如ATM之类的交易。Batch是晚上系统空闲的时候跑的批量程序，白天的很多交易其实并没有真正录入数据库，只是暂存而已，Batch程序将处理这些交易数据，并生成报表分发到各个支行或者提交到香港总行[2]。日间各分行押汇部通过本系统交易补录、录入、修改、删除数据（记账），晚上批量分类汇总生成统计报表。需要将现有Core Bank系统做以下修改和调整：
1. 增加6个联机程序,用户希望提供记账、复核双人临柜联机交易；
2. 增加2份日报表；
3. 增加12份联机通知书。
1.3. 文章的组织
本论文主要依照以下的主线来完成整篇文章的组织：问题引入－>通用的J2EE核心技术－>Core Bank系统技术（包含简介）－>应用系统（前台）的设计与实现－>数据库的设计与实现－>系统安全机制的设计与实现。
其中，前三章是整个系统的说明。接下来的三章是本论文的主要研究内容故各为一章，也就是接下来的第四到第六章。
2. 系统相关技术
2.1. J2EE技术
为了满足架构企业级应用的需求，Java的创始人Sun公司在早期的J2SE(Java 2 Platform Standard Edition)基础上，针对企业级应用的各种需求，主导并创造了J2EE(Java 2 Platform Enterprise Edition)。
从整体上讲，J2EE是使用Java技术开发企业级应用的一种事实上的工业标准(Sun公司出于其自身利益的考虑，至今没有将Java及其相关技术纳入标准化组织的体系)，它是Java技术不断适应和促进企业级应用过程中的产物。目前，Java平台有三个版本：适用于小型设备和智能卡的J2ME(Java 2 Platform Micro Edition)、适用于桌面系统的J2SE和适用于企业级应用的J2EE。Sun推出J2EE的目的是为了克服传统Client/Server模式的弊病，迎合Browser/Server架构的潮流，为应用Java技术开发服务器端应用提供一个平台独立的、可移植的、多用户的、安全的和基于标准的企业级平台，从而简化企业应用的开发、管理和部署。J2EE是一个标准，而不是一个现成的产品。各个平台开发商按照J2EE规范分别开发了不同的J2EE应用服务器，J2EE应用服务器是J2EE企业级应用的部署平台。由于它们都遵循了J2EE规范，因此，使用J2EE技术开发的企业级应用可以部署在各种J2EE应用服务器上[3]。
2.2. XML
XML(Extensible Markup Language)是一种可以用来定义其它标记语言的语言，被用来在不同的商务过程中共享数据。人们最初使用XML时，主要将它看成是一种数据交换标准。可是，如今XLM的功能已经远远超出了这个范围，它甚至在一些用于开发和部署的平台（比如微软的.NET平台）中起到了核心的作用[4]。
XML的发展和Java是相互独立的，但是它和Java具有的相同目标即平台独立性。通过将Java和XML的组合，可以得到一个完美的具有平台独立性的解决方案。
J2EE平台全面支持和实施XML，这种强大的组合可使XML具备跨平台的兼容性，甚至用于对XML代码进行语法检查和调试的工具也可与平台无关。
XML配置文档，Java对XML文档的操作有一套完整的API。当配置文件中并非一行一行独立的配置项，而是一组一组的，并且每组还不一样，使用XML配置文件是最好的选择。如果自己去控制这种配置之间的逻辑，肯定会很复杂。但是如果用XML就简单多了（使用自定义标记属性）。XML是一种通用的工具，可以做任何事。就像字典一样，我们拿字典来查字，字典就是工具，XML也是一样，可以用XML组合封装成各种各样的东西，甚至协议。
XML格式数据，几乎所有的数据库厂商都意识到了XML的重要性，也几乎所有厂商，包括Oracle和微软，都在去年就为自己的关系型数据库加上了对XML数据的支持我们常常会碰到需要处理以各种格式（从以逗号或者制表符做分隔符的文件到更复杂的格式）保存或者传输的数据的情况，对每一种格式都需要对应的解析器(parser)。这一缺点减缓了开发进度，而且可能会导致错误的发生。一个解决方案就是把常用格式的数据转化成XML文档，然后对它进行保存、处理或者转换成其它格式[5]。

3. Core Bank系统的技术
3.1. Core Bank系统简介
Core Bank系统服务于香港永亨银行，于2001年投入生产（使用），使用J2EE架构＋企业级数据库Oracle，具有易于移植和扩展的特点，适应银行业务的扩大。该系统包括一系列子系统诸如SC、DEP、CIFRMT、BRS、LNS等，每个子系统又包括Online和Batch两个部分，分别处理即时交易和批处理任务。Online处理白天柜台、电话银行以及其他如ATM之类的交易；Batch是在晚上系统空闲的时候跑的批量程序。白天的很多交易数据并没有真正录入数据库，只是暂存而已，Batch程序将处理这些交易数据，并生成报表分发到各个支行或者提交到香港总行。以下分别简单介绍Core Bank和BRS的工作流程。
1. Core Bank Online工作流程

图3.1　Core Bank Online工作流程
如图3.1所示，客户端的请求经过Window Control Frame(Servlet)分发到Apps Screens Flow初步处理，Apps Screens Flow将客户请求打包成XML数据格式送入TXM Connector，TXM Connector初始化一些特定的用户信息添加到XML请求数据，并将该请求转发给TXM Manager(EJB)。如果该请求非“激活”，TXN Manager将该请求送入SCS Controller进行合法性验证，只有合法的请求才送入Service Broker。否则TXM Manager根据XML配置文件查找处理该请求的Function Controller。Function Controller根据需要调用Service Broker进行数据库访问。为了方便跟踪维护，系统记录很多日志文件，包括错误日志记录和正常的交易日志记录。
2. BRS系统流程
联机
1． 各分行、各部门在各业务系统输入当日业务数据

2． 各分行押汇部通过押汇交易数据补登系统交易补录、录入、修改、删除数据（记账）
本行业务系统
（Core Bank）
押汇交易数据补登系统日志表
3．批量分类汇总，生成统计报表
Advicing (通知书)
押汇交易数据补登系统数据表
登记簿统计报表
当日日间
联机交易
日间联
机交易
授权（复核）
批量

图3.2 BRS系统流程
如图3.2所示，Core Bank系统每天都有很多联机交易，各分行、各部门在各业务系统输入当日业务数据，经过本行业务系统存入系统数据表。各分行押汇部通过押汇交易数据录入系统交易补录、录入、修改、删除数据（记账）（可能访问其他业务系统以获得必要的数据）。定义补录、录入、修改、删除数据（记账）的操作为Maker，对这些数据的授权（复核）操作为Checker。Maker的业务操作都需要经过Checker的复查才能成为有效记录存入系统数据表。有些操作是带有通知书（面函），这取决于登记簿的类型，带有通知书的Maker操作是会打印的。有些数据Checker如果拒绝了，那么该记录将恢复初始状态，Maker可以修改或者删除。以上都是Online程序所需要完成的，批量程序一般在晚间工作，这时候没有联机交易，不会造成访问冲突。Batch的周期是不固定的，有的Batch是每天跑一次，而有的是年报表类型，也就是一年才跑一次的。总之，它们的任务都是一个，那就是批量分类汇总，生成统计报表，用户可以有选择的打印。
3.2. 系统架构采用的技术

图3.3　Core Bank系统结构
Core Bank采用J2EE技术架构，使用了J2EE的JSP、EJB、Java Servlet、RMI、XML等核心技术。大多数应用，从PC机上的简单报表程序到大型机上的复杂计算，都由三部分组成[6]：
1. 用户界面部分：表示层；
2. 应用逻辑部分：业务逻辑层；
3. 数据访问部分：数据访问层。
Core Bank同样也是三层。如图3.3所示，它的表示层是由多种Channels组成的，分别是Mobile Banking/Trade、e-Banking/Trade、ATM、Phone Banking/Trade和Branch Operation。业务逻辑层从宏观上讲主要由Online Application Server和Batch Processor组成。数据访问层自然就是Oracle DataBases了。这样分层的方法是按照物理意义上来分的，事实上还可以按照逻辑处理来分，那也是为什么上文中提到“逻辑层从宏观上讲……”。按照逻辑处理来分位于第一层的是JSP页面表现层，第二层是TXM Manager(EJB)，第三层数据访问层是Service Broker（在本图中未体现）。在这些层之间的传输的数据就是XML格式（后面将详细讨论）。
3.3. 系统安全技术
1. 加密
系统的敏感性数据都经过加密或者哈希处理。程序配置文件的数据连接用户名和密码就是哈希后的值，即使有人通过不合法手段得到这些信息也没有用，因为哈希是不可逆的。客户端与服务器之间交互的关键性数据，都经过了加密处理，比方登陆用户的个人信息，交易的金额数据等。由于用户的这些信息量很大，需要太多篇幅，在这里就不列出实例了，只列出配置文件的实例片段（加下画线的就是哈希值），见图3.4。
jdbc:oracle:thin:@192.168.1.129:1521:xe

85769381857E817C3051574647484A4552545955

7E827B7E79968B7C3051574647484A45525459

图3.４　配置文件实例片段
2. 验证

客户端提交的数据是经过严格验证才保存到数据库的。首先，在录入页面上就要经过JavaScript脚本验证（如果用户禁止脚本，则禁止登陆本系统），接着数据转入后台处理，每个页面有个对应的JavaBean，数据转换成JavaBean对象之前要进行合法性验证。由于每个JavaBean可能对应数据库中多个表的操作，JavaBean要转换成数据库表对象的EntityBean，在这之前同样需要合法性验证和逻辑验证。当然，最终存入数据库还有约束条件，经过这么多层的验证，出错基本不会到数据库这一层，否则就是严重的应用程序错误了，这也是应用设计周全考虑数据安全的结果。
3. 权限
首先，系统的数据库权限设置分层次，相应层次的用户拥有不同的权限。系统提供Connect Service，CB系统中的每个子系统要取得数据库连接都通过该Service取得，每个子系统都用自己的Role去访问，当某个子系统需要访问其他子系统的数据时，则通过调用其他子系统的Service（SendEJB方法），不能直接使用本子系统的Role访问其他子系统数据库。在某个子系统中，访问数据库有两种Role，一种是Owner形式的，另外一种是Logic。顾名思义Owner Role是DBA，一般应用程序不推荐使用DBA帐户访问数据库，应用程序操作数据库存在太多的未知，DBA操作风险太大。所以应用程序使用Logic Role，虽然权限比DBA低，但是日常的维护已经够用。图3.5就是Owner Role和Logic Role的SQL授权语句，很多时候Owner和Logic的区别仅仅是前者拥有Drop的权限而已。
grant alter session, create sequence, create session, create synonym, create table,
create view, create procedure, create trigger, create type
to dw_owner;
grant create session, create procedure, create synonym, create view,
ps_dw_role, imp_full_database to dw_logic;
图3.5　授权SQL实例片段
其次，系统用户分组，不同组内的成员可操作的菜单不同。用户组分为Staff Group（职员组） 和 Transaction Group（交易组），每个用户组的用户都有一套自己的菜单，保存在数据库中，通过控制用户菜单来控制该用户的可操作权限。
3.4. 系统兼容性技术
J2EE架构提供了分布式、平台无关、可移植构件的框架。可伸缩、可扩展、易维护的特性使得企业级应用开发中所面临的问题迎刃而解。Core Bank正是因为使用这样的架构才适应了银行业务的不断扩大。系统于2001年开始投入银行业务的处理（仅一家银行），到目前为止香港永亨银行已经在国内开设多家银行，CB系统仍然能稳定工作。这其中添加过不少硬件，到现在已经构成服务器集群，可见其系统兼容性和伸缩性已经达到了完美的标准。
系统所有配置文档均使用XML文件格式，数据传输使用XML传输格式。这样做的好处是显而易见的，因为J2EE应用程序的配置多是以组的形式出现的，如果不使用XML支持的自定义标记，靠程序是难于控制的。系统增大，配置文件容量增大，不使用XML根本不仅难于管理且不具阅读性。图3.6就是AppRuntimeContext配置文档片段，该文档是系统对Controller的配置。这些信息就是按组分的，一个组就是一个TxnMessage。就像前面提到的，XML就是“字典”，系统就是通过该“字典”来查找服务的。根据MessageID查找ProgName（一个Class），在本例中，如果请求的MessageID是BRSO0103Q01，系统就“知道”处理该请求的Contrller是core.bi.brs.controller 包下的BRSO0103。

BRSO0103R01

BRS_LOG_DETAILS
core.bi.brs.controller.BRSO0103
JBEAN

……

图3.6　AppRuntimeContext配置文档片段
XML格式的数据传输方式最大的好处就是统一格式处理，不用编写多种解析器。Core Bank有多种不同的Channle（相当于客户端），如果不对提交的数据进行格式化处理，则对每一种格式都需要设计对应的解析器(parser)，这样做费力且不讨好，解析器太多可能带来效率低下，并增加出错的机会。本系统的解决方案就是把这些请求数据转化成XML文档，然后对它进行保存、处理或者转换成其它格式。图3.7所示的就是本系统使用的XML数据传输格式，这里列出的是Request对象格式化成XML的结果，Response的格式化类似。可以看到Request实质上包括了两个对象，User和Message。User是当前登陆用户的信息，Message是用户请求的信息。该信息送到Screen处理时，Screen就是根据MessageID（前面提到的AppRuntimeContext.xml）来查找处理该请求的Controller，然后进行处理。

127.0.0.1
123065
267062Session>
1
SCS36

COCO
COCO
ZH_CN
永亨银行有限公司深圳分行
深圳分行
oc Code="2201">深圳分行
存汇部 (深圳分行)
SZ　DEP TELLER G01

2004-07-02

SCSS3401Q01
ase>Remote_SCS
SCS34
BRS01
……

图3.7　XML数据传输对象
3.5. BRS系统的新技术
1. Beans Copy
Beans Copy就是将一个JavaBean的属性值Copy到另外一个JavaBean，当然这是有条件的，很显然，Copy两个不同的Bean，必须要求两个Bean中有完全或部分相同的属性，否则这种Copy也就没意义了。前面提过数据最终存入数据库是要经过多次转换的，在RequestMsg（XML格式的数据）转成FormBeans时，在FormBeans转换成EntityBeans（数据库表对应的Bean）时，CB系统惯用的做法是使用目标Bean的Set方法去Set目标Bean的属性，而这些属性值是通过被Copy Bean的Get方法取的。试想一下，假如数据库的某个表有很多字段，那么该表对应的Bean自然有很多属性，如果使用这种方法，可能会有很多的a1.SetAttr(a2.GetAttr ())代码出现，执行效率低且易出错。而使用Beans Copy技术就可以完全解决这些缺点，使用Java的反射机制将属性值Set到目标Bean。
2. 打印
BRS系统中的打印到目前为止只有面函和报表，不能保证以后用户会不会有新的需求。因此，打印API使用抽象工厂模式，该模式可以为一个产品族提供统一的创建接口，当需要这个产品族的某一系列的时候，可以为此系列的产品族创建一个具体的工厂类[7]。不管今后用户需求怎么变，都可以保证现在的打印正常工作，仅仅需要添加新的打印接口。打印API仍然使用JDK2平台的（jdk1.4则提供了一套完整的Java 打印服务 API），即实现Printable接口，其原因是JDK2平台具有良好的自定义打印实现。面函的打印采用HTML格式打印，首先需要制作HTML模板，然后再将该模板读入程序，对模板中标记的标签值进行替换。
4. 应用系统的设计与实现
4.1. 问题的引入
押汇交易数据录入系统旨在为用户提供联机交易，将押汇业务中与会计分录不相关的有关业务，在Core Bank系统以登记簿的形式进行登记和管理。谓联机交易也叫同步处理，即客户端发起交易请求后一直等待服务器端响应,直到客户端进程超时返回[8]。因此，通过设计一个良好的用户互动界面处理用户的业务，并具有良好性能的应用系统，成为了设计必须考虑的问题。
4.2. 需求分析
目前永亨银行中国部处理押汇业务通过用户手工填写登记簿的方式记录未存入Core Bank系统的信息来完成。一方面增加了大量的手工劳动，另一方面也不利于银行业务运行应急和连续性计划(BCP)的部署实施。故此开发了SDR818押汇交易数据录入系统，该系统在Core Bank系统的基础上新增一些联机交易，允许用户按照特定的格式录入手工登记簿的内容，自动生成预定格式的面函，并将登记簿的内容在Core Bank系统存档，方便用户随时查询登记簿的内容，并定期生成必要的分类统计报表。下面从几个方面对该系统的设计做详细的描述。
4.2.1. 功能需求
本系统主要实现押汇业务的处理，而处理押汇业务的过程分为两个部分：首先，记帐员通过押汇交易数据录入系统新增、修改或删除数据；然后，复核员通过押汇交易数据录入系统对记帐员的所新增、修改或删除的数据进行授权或拒绝。另外，所有的用户（包括记帐员和复核员）都可以通过押汇交易数据录入系统对所有数据进行查询。
因此，根据业务需要将该应用系统分成了三个主要的功能模块：记帐模块、复核模块和查询模块。在记帐模块中，记帐员可以登录到“押汇登记簿列表”进行新增、修改或删除登记簿，记账组主任可以登录到“日志查询”进行查看日志、取消日志、修改日志或打印面函；在复核模块中，复核员可以登录到“日志查询”中对新增、修改或删除登记簿给予授权或拒绝；而在查询模块中，所有用户都可以对所有登记簿进行查询，浏览登记簿详细信息或流水查询。
4.2.2. 用户界面需求
设计良好的用户界面是接收用户输入和使应用程序友善的有效手段[9]。界面友好的要求是：系统要提供统一的操作界面和方式，要求操作界面美观大方，布局合理，功能完善，对于初级用户容易上手。
因此，押汇交易数据录入系统提供简单、层次关系明了、清晰的操作界面，使用户一目了然且容易操纵，尽可能地为用户的各种操作提供方便。
4.2.3. 性能需求
作为一个软件系统，其性能与其功能同等重要，不容忽视。系统性能需求包括响应时间、精确度指标需求、安全性等[10]。下面将从几个方面阐述押汇交易数据录入系统应该达到的性能。
1. 系统效率
系统效率包括三个方面的因素：周转时间、响应时间和吞吐量。 一个受用户欢迎的系统，其响应用户的时间一定要控制在用户能够容忍的时间限度之内。所以，押汇交易数据录入系统的响应时间应该是：平均时间在1～3秒以内，最大不超过5秒。其吞吐量要足够大。
2. 系统的可扩充性
面对环境的变化、工作任务量的增多和工作范围的扩大，系统经常面临更新、扩充以及网络化等新问题，系统需要有良好的可扩充性来应付。Core Bank系统面临最大的问题就是相关业务的急剧增长，因此系统设计需充分考虑扩充性，否则实现的系统将难于维护甚至完不成使命。
3. 系统的可维护性
环境的变化，人为的失误使系统运行离不开经常性的维护活动。银行机构的数据库对外保密，使得基于数据操作的系统维护变得相当困难（因为脱离了数据库）。因此，本系统的可维护性设计需要大费周章。
4. 系统的可移植性
系统可移植性是指将系统从一种硬件配置及（或）软件环境下移植到另一种硬件配置及（或）软件环境下所需做的努力程度[11]。系统的可移植性主要取决于系统硬件设备的特点、软件的特征、开发环境。为了方便将该系统移植到其他环境下，应该在系统分析和设计中充分的考虑系统硬件设备、开发环境的通用性。永亨银行陆续开设分行，而各个分行都有自己的服务器，系统要求在少量的改动下进行安装运行。
5. 系统适应性
系统适应性指系统在运行环境、约束条件或用户需求有所变动时的适应能力。如果一个系统只能在开发环境中运行，一旦开发环境有所变化，就不能运行，这样的系统是没多大作用的，至少要费很大的劲才能使原来系统得以运行。故要求系统要有很好的适应性。
6. 系统安全可靠性
因为该系统是对银行相关业务的管理，所以要有很好的安全性和保密性。特别是要确保数据库的安全性，所以我们将数据库与逻辑层服务器进行隔离，以防止数据偷窃与篡改。
4.3. 系统设计
建一座大楼，就先要设计好蓝图，只要蓝图设计好了，然后有条不紊的施工，一座大楼就这样建起来了。同样的道理，做一个软件系统，也应先做好系统设计，以指导系统的进一步开发。软件系统设计阶段的主要任务分总体设计（概要设计）与详细设计[12]。下面我就总体设计和功能模块设计两个部分，从总体到局部，从抽象到具体的对系统进行设计。
4.3.1. 总体设计
经过对系统功能需求的分析，并且在第三章中也已经阐述过系统的架构，下面进行系统的功能方面的设计。将BRS系统分为三大模块，见图4.1。
BRS系统

复核模块

记帐模块

查询模块

图4.1　BRS总体功能结构
4.3.2. 模块设计
依照系统的总体功能结构图，对每个功能模块再进行细分，见图4.2。
记帐模块

押汇登记簿列表

日志查询

新增

修改

删除

查看日志

取消日志

修改日志

打印面函

复核模块

授权

拒绝

查询结果详细内容

打印查询报表