《计算机类毕业论》word版.doc

摘要商业银行是现在金融体系的主体，并且随着经济的发展，它将在未来经济生活中发挥越来越重要的作用。银行综合业务系统作为电子化银行业务运行的最基本的支撑平台，不仅成为银行市场运作、金融创新、客户服务、量化管理的技术基础，也是银行争取未来竞争优势的重要手段。本文详细地描述和记录了作者在实习公司参与开发第三代商业银行综合业务系统的过程。首先分析了目前商业银行综合业务系统的实际需求，并且根据个人在团队中的分工确定主要工作内容；然后着手概要设计和详细设计，重点是数据库结构的设计；最后是编码和测试以及系统使用手册说明。整个系统采用C/S的架构，在Unix平台上完成开发，使用C语言进行程序编码，使用Tuxedo作为中间件，使用Informix作为数据库管理器。本文最后对今后的银行综合业务系统的发展做了展望。关键词： 商业银行， 综合业务系统， 数据库设计， C/S架构目录1 绪论11.1 系统开发背景11.1.1 我国商业银行的历史与现状11.1.2 银行综合业务系统11.1.3 对公储蓄业务11.2 论文的主要工作及安排11.2.1 论文的主要工作11.2.2 论文的结构安排22 C/S架构及中间件概述32.1 基本C/S模式32.2 可管理多层C/S模式32.2.1 中间件概述32.2.2 引入中间件管理的MMT C/S模式32.3 银行综合业务系统中的C/S模式应用42.3.1 客户端42.3.2 服务器端53 相关技术和工具简介63.1 C语言概述63.2 TopSmartTeller主要特点63.2.1 用户界面63.2.2 脚本配置63.2.3 交易驱动方式63.2.4 外设驱动63.2.5 编译机制73.3 BEA Tuxedo简介74 系统设计与实现84.1 需求分析84.1.1 功能要求84.1.2 开发环境84.2 系统设计94.2.1 系统框架94.2.2 数据库设计94.3 模块及交易的设计与实现114.3.1 模块设计114.3.2 交易定义124.3.3 交易流程设计125 程序及界面调试145.1 程序结构145.1.1 交易程序145.1.2元操作程序145.1.3底层封装函数。155.2 源码举例分析155.2.1 头文件155.2.2 变量申明165.2.3 主程序165.3 测试与分析175.3.1 交易正确驱动175.3.2 交易数据接收185.3.3 交易执行测试及结果返回196 总结与展望206.1 论文总结206.2 展望20谢辞21参考文献22附录23第 II 页 共 页1 绪论1.1 系统开发背景1.1.1 我国商业银行的历史与现状根据1995年7月1日开始实施的中华人民共和国商业银行法的规定，商业银行是指依照公司法设立的吸收公众存款、发放贷款、办理结算等业务的企业法人。就目前我国市场经济金融活动实际情况而言，商业银行是现代金融体系的主体。在1979年以前的多数年份中，中国人民银行是全国唯一的国家银行，农村信用合作社是全国唯一的民间金融机构。自1979年我国实行经济体制改革以来，中国银行、中国工商银行先后从中国人民银行分离出来，又恢复了中国农业银行，原先隶属于财政部的中国人民建设银行（后更名中国建设银行）在1985年也将其信贷计划纳入中国人民银行负责编制并监督执行的国家银行综合信贷计划的体系。此外，还恢复、成立了交通银行、中信实业银行、中国光大银行等多家综合性银行。1.1.2 银行综合业务系统随着知识经济时代的到来和银行电子化建设的发展，现代信息技术不再只是银行开展业务的一种辅助工具。银行电子化水平已经成为银行市场运作、金融创新、客户服务、量化管理的技术基础，也是银行争取未来竞争优势的重要手段。银行综合业务系统作为电子化银行业务运行的最基本的支撑平台，是其他所有银行电子化产品得以应用的前提。没有综合业务系统，电子化银行就等于没有地基的大楼。1.1.3 对公储蓄业务对公储蓄业务，是商业银行开展的最基本也是最主要的业务项目之一。所谓对公，1.2 论文的主要工作及安排1.2.1 论文的主要工作商业银行综合业务系统是一个复杂而庞大的系统，并且在进行开发工作之前，必需掌握相应的商业银行会计知识，了解银行核算流程，熟悉银行服务项目和种类。因此，明确的团队分工、良好的团队配合、始终保持一致的团队风格就显得尤为重要。这也是在此次毕业设计过程中，我所感受到的与那些在校内完成既定设计课题的同学之间最大的不同之处。在整个开发团队中，作者主要的工作是完成对公储蓄业务相关交易的后台程序设计开发和测试，同时接触、了解和学习相应的前台程序的设计。本文从软件开发流程的角度，详细记录和描述了整个工作过程，所涉及的主要工作也将围绕着这个工作目标展开，并且在必要的地方，适当地对其他相关业务模块进行介绍。下面是各阶段要完成的主要工作：（1）基础知识准备：这部分工作主要包括两个方面：u 学习商业银行会计核算的相关基础知识，了解银行业务和相应会计核算的流程；u 分析前几代商业银行综合业务系统的内核，重点在于熟悉后台系统的常见层次和结构。（2）需求分析和系统设计：在软件工程的相关定义中，需求分析和系统设计是两个阶段。但是在实际参与开发的过程中，作者发现很难界定两者之间的时间分割线。在开发中过程，根据客户变更的需求来修改设计，抑或由于实际情况来说服客户对于某些需求进行妥协，这些都是不可避免的。因此，这部分的工作势必在一种隐含变数的稳步交替中完成。但不可否认，这将对以后的工作开展起决定性作用。（3）数据库结构设计：严格地说，这部分的设计应该属于系统设计的一部分。但是商业银行综合业务系统本身的功能和目的，决定了其必然是依托在一个数据库管理器的基础上实现各个模块的功能，因此数据库结构的设计也就尤为重要。在实际工作中，这一部分也需要相对独立地去设计和完成。其主要内容是参考需求制定表结构和表间参照性。（4）实现：后台程序全部使用C语言完成编码，由于作者所在的实习公司在综合业务系统开发方面有相当的经验，因此很多底层操作都由技术部封装成函数，供程序员直接调用，这在一定程度上提高了工作效率，降低了编码难度。此外，作者还尝试去熟悉和使用实习公司开发的TopSmartTeller工具编写各个交易所对应的前台程序模块。（5）调试：这部分工作在整个开发过程中接近尾声，却非常重要，主要包括两个工作步骤：u 单独调试作者按团队分工所负责的各个模块的功能是否正常实现，发现并解决其中出现的问题；u 系统组合后与团队同事联测模块间的联系和配合是否正常实现，发现并解决其中出现的问题。应客户需求，开发过程中对今后将会拓展的信贷系统接口做了预备工作，作者也参与了部分工作，由于条件和时间关系，论文中就不再赘述，留待日后扩充。1.2.2 论文的结构安排本文各个章节的内容安排如下：第1章. 简要介绍商业银行综合业务系统的开发背景，并将作者主要负责的对公储蓄业务作单独介绍。然后介绍了论文的主要工作和结构安排。第2章. 系统地介绍C/S架构的系统结构，包括基本模式、可管理多层模式的演化、以及中间件的概念。第3章. 对系统开发所用到的主要工具和技术进行介绍，包括人们熟悉的C语言的概述、使用Tuxedo作为系统中间件的概念和技术、作为数据库管理器的Informix。最后说明了系统的开发环境和配置。第4章. 该部分包含了系统的需求分析、详细设计以及编码实现和测试等内容，是全文最重要的部分。在这一章中，对程序已经实现的部分作了详细的介绍。第5章. 在这一章中，重点选取了几段具有代表性的源码进行分析，从而说明整个系统编码的结构特征。此外，还对程序测试过程中出现的一些问题及解决方法进行分析说明。第6章. 总结论文设计过程中所作的工作，并且对商业银行综合业务系统在未来的发展前景作了简单的分析和展望。2 C/S架构及中间件概述2.1 基本C/S模式图 2.1 基本C/S模式结构示意C/S系统架构即Client（客户端）/Server（服务端）系统架构，它是一种分布式系统架构，基本结构如图2.1所示，由其程序决定其主要特点是：u 客户端部分执行前端功能，如：提供用户界面，向后台发出用户请求的交易，将结果返回给用户。u 服务端提供一般后端功能，按交易组织，将结果返回前端。u 交易是分散的，按需求的操作，可以被远程客户端访问的程序。C/S系统架构有如下几项优点：u 减小客户端程序体积，提高反应速度u 位置无关u 模块化u 扩展性好2.2 可管理多层C/S模式2.2.1 中间件概述在本节中，必需要提出“中间件”这个词，并且就这个问题，从概念上进行一些介绍。所谓中间件，2.2.2 引入中间件管理的MMT C/S模式在可管理多层(Managed Multi-Tier MMT)C/S模式中，提出了中间件管理。提供以下功能：u 在客户端和服务端之间提供通信和传输。在分布式交易处理框架下，并不在C/S间建立一对一的关系，因此服务端可以从多个客户端接收数据流，客户端也可以向多个服务发出请求。除此以外，MMT C/S模式给OTLP应用增加了如下的优点：u 基本C/S模式的优点在MMT模式下都得到了有效的增强2.3 银行综合业务系统中的C/S模式应用银行综合业务系统，属企业分布式事务系统，因此针对C/S架构的系统层次结构为：u 用户界面。重在突出表示逻辑和表示管理。u 商业逻辑。重在商业应用逻辑和商业应用规则。u 逻辑实现。将商业应用逻辑按商业应用规则实际化。u 数据管理。包含了数据访问逻辑（SQL）和数据库管理。2.3.1 客户端在此节中，我们重新细致地认识一些客户端在C/S模式中扮演的角色。客户端基本工作流程，如图2.2所示：图 2.2 客户端基本工作流程这里针对商业银行综合业务系统的开发，对如图2.2中的几个名词作一些解释：（1）交易商业银行业务交易请求，简称“交易”，它不是普通意义上价值与价值之间的互换。银行业务系统中所谓交易，是指由客户或终端柜员在系统前台对系统后台提供的服务项目发出服务请求，然后等待系统调用相关程序并返回结果的整个过程。一次过程的结束就是一个交易的结束，返回了客户期望的正确结果称为交易成功，反之称为交易失败。（2）系统图2.2中有“连接系统”和“退出系统”两项。这里的系统并不是指整个银行综合业务系统，它仅特指某一项服务所涉及的程序、数据库和底层元操作程序的集合，是针对一次交易而言的、狭义上的系统。2.3.2 服务器端在此节中，我们重新细致地认识一些服务端在C/S模式中扮演的角色。首先，服务是系统资源的联系点。例如，服务端基本工作流程，如图2.3所示：图 2.3 服务端基本工作流程这里有必要对公告牌的概念作一个说明。首先必须明确，公告牌是伴随中间件而产生的一种“请求联系服务”的管理机制。关于中间件，详细内容参考前文相关定义。当一个服务端具备多个服务功能时，3 相关技术和工具简介3.1 C语言概述本文中，系统设计编码和实现工作使用的是C程序设计语言。一直以来，作为一门在国际上广泛流行的程序设计语言，C语言因其语言功能丰富、表达能力强、语法灵活直观、应用面广和目标程序效率高的特点，适合于作为系统描述语言，编写各类软件。同时，作为一门传统的面向过程程序设计语言，使用C语言进行系统设计与编码的首要工作是强调程序结构的规范化，遵循“自顶向下、逐步细化、模块化设计、结构化编码”的原则，从而在保证程序结构清晰的前提下，降低资源占用、减少信息冗余、提高程序效率。但是，C语言毕竟不具备很多集成、交互、3.2 TopSmartTeller主要特点本文所围绕的“商业银行综合业务系统”是作者在实习期间接触、了解的最主要的软件项目，这也是作者选择其作为毕业设计对象的主要原因。而实现该系统终端界面的开发工具，就是作者实习公司专为银行、邮储系统终端所开发的TopSmartTeller，目前版本号V3.1。由于TopSmartTeller在设计上采用了基于脚本的思路，运用了事件驱动的处理机制和面向对象的界面元素设计使得，TOPSmartTeller 拥有大量技术优势，主要包括一下若干内容。3.2.1 用户界面作为终端开发工具，TopSmartTeller提供标准多窗口界面，便于用户操作，同时满足负责的应用要求。针对开发应用，TopSmartTeller提供了功能强大的下拉式菜单、支持动态属性变化的控件、多种信息提示方式和输入方式，同时轻松实现了多种屏幕元素的动态动作。3.2.2 脚本配置所有画面都是通过脚本配置编写来实现的。脚本编写使用STScript脚本语言，它是TopSmartTeller提供的专用的编程工具。提供脚本的配置，用户可以定义画面，消息格式，以及处理逻辑流程。使用了脚本配置方法一方面避免了大量C语言繁琐的底层开发，另一方面也避免了由此造成的开发要求高系统稳定性没有保障等问题。3.2.3 交易驱动方式对系统而言，由于实现的功能和操作的对象不同，对交易的驱动方式也有着不同的要求。TopSmartTeller提供适合于大量交易复杂系统的菜单驱动方式，适合于速度快、操作熟练柜员的交易代码驱动方式，针对一些特殊用途的功能键驱动方式，以及适合同一业务流程多个相关交易的交易驱动方式。以上几类驱动方式的互补并存，有效地提供了操作柜员和系统本身的工作效率。3.2.4 外设驱动在银行业务流程中，往往需要许多外设硬件提供帮助，比如常见的POS机、打印机等，各类外设的使用规范往往各不相同。3.2.5 编译机制TopSmartTeller采用的编译机制是将每个交易的脚本编译成为独立的数据文件，每个交易的数据文件在运行时刻动态加载。3.3 BEA Tuxedo简介系统的设计开发中，使用BEA Tuxedo作中间件。BEA Tuxedo是在企业、Internet这样的分布式运算环境中，开发和管理三层结构的客户/服务器型任务应用系统的强有力工具。它具备分布式事务处理和应用通信功能，并提供完善的各种服务来建立、运行和管理任务应用系统。开发人员能够用它建立跨多个硬件平台、数据库和操作系统的可互操作的应用系统。BEA TUXEDO是企业、Internet分布式应用中的基础主干平台。它提供了一个开放的环境，支持各种各样的客 户、数据库、网络、遗留系统和通讯方式。4 系统设计与实现从本章节开始，将对“商业银行综合业务系统”的设计和实现过程作详细说明。由于“商业银行综合业务系统”其本身是庞大而复杂的，整个开发过程由十数人组成团队完成，而每个队员则按分工不同，独立完成相应模块的设计编码并测试相关程序，最终进行系统模块联测。所以受到时间和其他条件制约，无法对整个系统的设计与实现进行完整叙述说明。接下来的叙述，将侧重于针对作者所主要参与的对公储蓄业务。此外，对与之相关的其他一些业务流程和设计情况，作者也将作一些介绍。4.1 需求分析4.1.1 功能要求商业银行综合业务系统对公储蓄业务，其功能服务的对象是经过国家相关法规认证的、具备商业运营资格的国有、合资或私营公司企业。其功能的实现目标是，不但提供大多数普通个人储蓄业务的项目，而且还根据企业级客户的实际需求开展一系列独有的业务服务项目。该业务模块所具备的主要功能包括：（1）单位活期业务单位活期业务包括：单位活期帐户开立申请、帐户开立、帐户销户及反销户、现金存取、利息结算支付、帐户相关信息查询与维护等。（2）单位定期业务单位定期业务包括：单位定期帐户开立申请、帐户开立、定期存取、定期质押与解除质押、存款变更、帐户相关信息查询与维护等。（3）保证金业务保证金业务包括：保证金帐户开立、保证金存取、保证金相关信息查询维护等。（4）医疗保险金/公积金业务医疗保险金/公积金业务包括：医疗保险金/公积金帐户开立申请、帐户开立、医疗保险金/公积金存取等。（5）大额支付业务大额支付业务包括：委托收款的录入、修改与发送、托收承付的录入、修改与发送、申请报文的录入、修改、发送及相对应的反向撤销操作、报文相关信息查询与维护等。（6）单位通知存款业务单位通知存款业务包括：单位通知存款的开户与销户、存款存入、存款提取预约通知与通知取消、通知存款通知信息查询等。（7）同业存款/同业存放业务同业存款/同业存放业务包括：同业存款的开户与相关信息查询及维护、同业存放的开户与相关信息查询及维护等。4.1.2 开发环境（1）开发工具使用C for SCOUnix作为服务端的程序编码工具，使用TopSmartTeller V3.1for Unix/Linux/win32编写客户端的终端界面程序，这两个工具的功能和特点在第三章中已经作了详细介绍，这里不再赘述。（2）数据库选择使用Informix V7.3 作为服务端数据库管理器。银行数据库属于典型的对象关系型数据库，其操作类型主要是在线事务处理（OLTP）。由于引入中间件帮助负责交易的通讯和管理，数据库服务器便成为一个纯粹的RM（Resouce Manager）。（3）中间件选择使用BEA Tuxedo 作为Client/Server间的中间件软件，进行两者间的消息报传送与处理，服务项发布，以及交易与服务间的选择联系。关于BEA Tuxedo的详细介绍，请参见本文章节3.3。4.2 系统设计4.2.1 系统框架商业银行综合业务系统框架如图4.1，其中箭头方向指示了一次交易的流程：图 4.1 商业银行综合业务系统框架4.2.2 数据库设计商业银行综合业务系统数据库基本表内容庞大，总量超过160张，按基本表的用途可大致分为三类。由于时间和本文篇幅的限制，以下只列出与对公储蓄交易相关的基本表，并且同一类下只列出最具代表性的一张表。（1）系统记录类系统记录类基本表，不局限于某一模块或某一具体交易，而是记录系统运行时的常规数据，便于需要时审查核对，一般情况下不对外提供查询。其典型代表为“交易流水表”，如表4.1所示：表 4.1 交易流水表NameDescription （索引表）PK_xdtltxday,kinbr,tlrno,tlsrnoNameTypeDescription （基本表）txdaydate(char(8)日期kinbrbrcode(char(6)交易行号tlrnotlrno(char(6)操作员号tlsrnotlsrno(char(7)流水号txtimechar(14)交易时间db_descnodesccd(char(4)借方摘要代码db_custnocustno(char(20)借方客户代码cr_actidactid(int)贷方帐号cr_brcodebrcode(char(6)贷方机构cr_curcdcurcd(char(3)贷方币种xsubtypetype(char(1)子类型spflgflag(char(1)是否经过主管授权sptlrnotlrno(char(6)授权主管vflagflag(char(1)复核标志 0-未复核,1-已复核miscamt3decimal(14)扩展信息3miscvarchar(100)其他信息（2）系统定义类系统定义类基本表，记录了系统底层的基本定义，提供给相关交易统一的标准，是交易按正确流程进行的保证，在一定权限或需求下才提供查询。典型代表为“交易定义表”，如表4.2所示：表 4.2 交易定义表NameDescription （索引表）PK_txdefTxcodeNameTypeDescription （基本表）txcodetxncd(char(4)交易代码nameadesc(varchar(20)交易名称onlinepermittype(char(1)允许在什么系统状态下进行的交易nvflgflag(char(1)是否需要事中审核0-否1-是（3）交易涉及对象定义类交易涉及对象定义基本表，针对交易涉及的具体对象，也是对象关系型数据库中最常见的基本表。表的内容往往就是交易处理的具体数据对象，处理内容包括查询、修改、删除等。其典型代表为“企业客户基本信息表”，如表4.3所示：表 4.3 企业客户基本信息表NameDescription （索引表）PK_custcorpcustnoNameTypeDescription （基本表）custnocustno(char(20)客户号namecname(varchar(60)中文名称enameename(varchar(60)英文名称idnoidno(varchar(20)企业标识代码或事业单位代码licensenoidno(varchar(20)营业执照号码nationtaxnoidno(varchar(20)国税税务登记号localtaxnoidno(varchar(20)地税税务登记号crttlrnotlrno(char(6)创建操作员crtbridbrid(char(6)创建机构(内部机构号)lupddatedate(char(8)上次修改时间lupdtlrnotlrno(char(6)上次修改操作员lupdbridbrid(char(6)上次修改机构(内部机构号)4.3 模块及交易的设计与实现4.3.1 模块设计一个模块，由若干个互相间存在联系的交易组成。所谓互相间存在联系，主要指交易在业务流程上具有相似性，或者交易在业务流程上具有相关性。在设计模块时，一般不但将这些有联系的交易组成一个大模块（第一层模块），而且再次基础上，将在业务流程上具有相关性的交易组成小模块（第二层模块）。同一小模块内的交易在业务流程上具有相关性，而同一大模块内、不同小模块间的交易在业务流程上具有相似性。为了使表述能够更加直观，作者结合如图4.2，来解释模块与交易间的关系：图 4.2 系统模块设计图（局部）由图4.2可见，“对公储蓄业务”是“商业银行综合业务系统”下的第一层模块；在其下层则包含了“单位活期”、“单位定期”、“保证金”等若干个第二层模块；每个第二层模块下则又包含了若干个交易，同一层模块下的交易在业务流程上具有相关性，例如“活期帐户信息查询维护”交易只能对已经在本行完成“活期开户”的单位进行操作。需要说明的是，4.3.2 交易定义商业银行综合业务系统中，根据业务种类分，存在两种交易类型：联机和批量。所谓批量交易，是指银行在一天的营业结束后，（1）交易名与交易代码每个交易都有一个交易名和一个交易代码，交易名和交易代码不但可以用来标示不同，（2）交易参数设置每个交易在正常使用前，必须在系统中完成相关申请，提交参数。交易参数主要包括：u 交易类型Xtype。标示出交易为查询类、账务处理类、特殊处理类、信息维护类、审核类、系统管理类-u 子类型XSubtype。当交易能用于交易驱动或被驱动，那么该交易就有可能饱含子类型-u 是否支持连续交易Multitxtype一些交易基于业务流程的规范，当前交易是否支持连续交易。交易参数设置的目的主要有两个：其一是帮助系统管理员对系统中存在的交易进行管理，其二则是为系统后台程序运行提供了重要参数依据。后者主要针对的都是一些批量交易，不是作者分工任务范围，这里简单介绍一些，不再赘述。4.3.3 交易流程设计之前刚介绍了交易分为联机和批量两种类型。作者参与设计开发的对公储蓄业务模块，其涉及的主要交易全是联机交易。前后台之间的交易流程和数据流，如图4.3所示，其中虚线间为中间件管理层：图 4.3 联机交易数据处理流程图4.3中的“包头”区域需要特别解释一下。“包头”也是一串字符数据，它包含了一部分系统信息，有一些给中间件联系前台交易请求和后台服务程序提供了依据，另外一些则是后台程序可能会使用到的全局变量值，基本结构参见图4.4：图 4.4 消息包头结构图如图4.4的结构中，服务代码、反馈类型和交易代码等信息，提供了中间件联系前台交易请求和后台服务程序的重要依据。而机构号、柜员号及系统日期等信息，则是后台程序可能会用到的全局变量值。在交易请求和应答过程中，5 程序及界面调试5.1 程序结构商业银行综合业务系统程序由两部分组成：前台程序和后台程序。前台程序使用TopSmartTeller编写，而后台程序使用C for SCOUnix编写，本章主要针对后台程序的设计编写作详细解释说明。一个后台程序的基本结构包括一下若干部分：5.1.1 交易程序这是响应服务请求，接收前台数据，并按业务会计流程对数据进行操作的程序。交易程序的命名规则为：“模块代码+交易代码+后缀名”。u 模块代码模块代码是系统设计时，一般为两位英文字母。与对公储蓄业务相关的部分模块名称与模块代码，见表5.1：表 5.1 模块名称与模块代码对照表模块名称模块代码大额支付h v单位活期s e单位定期d p保证金d p医疗保险金/公积金d pu 交易代码交易代码的定义在前文4.3.2中已经详细介绍过了，这里不再赘述。u 后缀名后缀分两种，通常C语言程序代码文件的后缀为.c，但是综上所述，对于程序文件dp2032.c，其对应的是对公定期模块dp下，交易代码为2032的交易，即“单位定期开户申请”交易。并且由后缀名可知，该程序中没有内嵌SQL语句。其他程序文件名也可以按此规律去理解其代表的含义，这里就不再逐一解释了。5.1.2元操作程序元操作程序是位于交易程序下层的独立程序。编码和编译时，针对元操作程序的流程与针对交易程序的流程没有本质区别。但是在运行时，元操作程序不能直接独立运行，而只是供其所属的上层交易程序按业务流程需要进行调用，调用方式同函数调用的方式类似。元操作程序的命名规则为：“模块代码+对象名+元操作名+后缀名”。u 模块代码模块代码的定义在前文5.1.1中已经详细介绍过了，这里不再赘述。u 对象名元操作一般都是针对数据库中某张基本表、甚或是具体的基本表内某个字段中的数据进行操作，所谓“元操作”中的“元”，就是单元、单独的意思。因此利用在程序名中标示基本表名、或者字段名的方法来区分同一模块下针对不同基本表、或同一基本表不同字段的元操作。这样的规则对以后程序的修改和维护工作将有很大帮助u 元操作名元操作名，指的是该元操作对基本表作了什么动作，常见动作包括增加、删除、修改、查寻、核对等，对应的元操作名则是Add、Del、Upd、Inq、Chk等。此外，可以根据实际情况定义其他元操作名，但要求简洁明了易于理解，这同样也是出于对今后程序修改维护的考虑，提高工作效率。u 后缀名元操作程序的后缀名同样有.c和.ec两种，使用规则及目的同交易程序后缀名的使用规则及目的相同，这里不再赘述。综上所述，对于元操作程序文件dpActChk.c，其对应的是对公定期模块dp下，对Act(账号Actno)，进行核查操作。并且由后缀名可知，该程序中没有内嵌SQL语句。其他元操作程序文件名也可以按此规律去理解其所代表的含义，这里不再一一解释。5.1.3底层封装函数。底层封装函数，是将常用的SQL语句按固定格式封装成函数，供上层程序调用。目的在于减少或避免在上层程序中内嵌SQL语句，保持简洁的程序风格，提高程序可读性，以及日后程序修改维护的工作效率。其命名规则为：“dbsvr_基本表名.ec”。5.2 源码举例分析本章节内，作者选择了一个交易程序和其包含的元操作程序，在对该程序分析解释的过程中，阐述商业银行综合业务系统后台程序的特点。样例选择dp2032.c，即“单位定期存款开户”交易程序。之所以选择这个程序作样例，是经过一番考虑，有一定的原因的。因此，作者最终选择了dp2032.c，“单位定期存款开户”交易程序。原因有二，首先从银行业务流程和会计规范上说，该交易称得上“中规中矩”，即使对商业银行会计业务知识不熟悉的读者也能够通过阅读接下来的程序分析，理解该交易的流程规范；其次，从程序设计的角度来说，dp2032.c是该系统众多程序中比较具有代表性的一个，其程序结构、编写规范等都可以反映出这个系统的程序结构和编写规范。以下就是dp2032.c的部分程序源代码，以及作者对它的详细分析：5.2.1 头文件程序首先要申明相关的头文件，在系统中，头文件命名格式为：“模块代码_头文件类型”。模块代码相信大家已经很清楚其涵义了，而头文件类型主要有三种，申明格式如下：（1）#Define dp_itf.h以itf做标识的头文件，其内容包含了该交易程序所调用的元操作程序的传入、传出变量结构和类型的申明。在5.1.2中已经说明过，元操作程序被交易程序的调用过程类似函数调用，因此对传入传出变量的结构和类型申明也是必须的。（2）#Define dp_def.h以def做标识的头文件，其内容是在该交易程序中出现的宏变量定义和申明，尤其是对于一些标志位，如果在程序中直接使用数字，会降低程序可读性，提高日后的维护难度。使用宏定义将数字转化为具有一定文字意义的短语就可以解决这些问题。（3）#Define dp_err.h以err做标识的头文件，其内容是该交易程序执行过程中可能出现的错误类型代码的宏定义。当交易程序执行过程中发现前台传来的信息有错误，或者执行过程中发生的错误，那么同样也要返回信息给前台，这个信息就是错误类型代码。这些错误代码同样在头文件中用宏定义转换为有实际文字意义的短语，提高程序可读性，降低日后维护难度。5.2.2 变量申明变量申明顾名思义，是对程序执行过程中需要用的变量，进行类型定义。其中比较重要的是前后台之间传递数据的结构定义，称为TITA和TOTA结构：/* define TITA text */static struct char actnoDLEN_OTACTNO; /*基本帐号*/char nameDLEN_CNAME; /*名 称*/。char acnoDLEN_AC_ACNO; /*科 目 号*/char outflag; tis2032;/* define TOTA text */static struct char newactnoDLEN_ACTNO; /*新 帐 号*/char tlsrnoDLEN_TLSRNO; /*交易流水*/ tos2032;其他需要使用的变量的定义，紧接着TITA和TOTA结构后列出，例如程序中调用的元操作程序，传入和传出变量结构申明在头文件中已经完成，这里就要进行定义：/* define module global variables */static aTisCifTxnLog taTisCifTxnLog; /*客户交易发生登记传入结构*/。static aTosDpActInfUpd taTosDpActInfUpd; /*存款账号信息新增传出结构*/除以上这些比较重要的变量结构定义以外，其他程序要使用的变量也应注意进行定义，变量名应尽量与其代表涵义相符合。此外，还要申明程序调用的自定义函数的类型和结构：void dp2032Initial(); /*程序初始化*/。void dp2032PutMessage(); /*反馈信息发送*/5.2.3 主程序在主程序中，严格按照交易相关业务流程和会计规范，调用相关元操作核函数，对前台传来的数据进行处理，并生成反馈信息传回前台。dp2032对公储蓄定期存款开户的业务流程和会计规范基本如图5.1：图 5.1 单位定期存款开户业务流程在图5.1中的单位定期存款开户交易业务流程中，如果任意一步产生错误，那么开户即告失败。程序返回错误代码到前台，错误代码对应的错误类型在头文件中已经申明了宏定义。对于该流程中的每一步，程序都按照如图5.2的步骤执行元操作：图 5.2 元操作程序调用流程/* 客户号资料读取与状态检查 */memset(&taTisCifCorpChk, 0, sizeof(taTisCifCorpChk); |memset(&taTosCifCorpChk, 0, sizeof(taTosCifCorpChk); | 元操作输入结构变量赋值memcpy(taTisCifCorpChk.sCustno, sCustno, DLEN_CUSTNO); |。 ERRTRACE(E_FD_ACT_STATUS_ERR, dp2032: iActid%d, taTisDpActInq.iActid); return; |返回错误类型以上代码是对客户号和基本帐号的检查程序。此外，其他各步骤的程序全部都按照这个程序结构和风格编写。限于时间和篇幅的限制，这里不再详细列出全部程序源代码，如果需要进一步了解系统程序编码的结构和特点，请参见附录。5.3 测试与分析调试的任务就是诊断和改正程序中的错误，而根本目的就是向客户提交除符合其要求的软件。如果不改正程序中存在的问题，那么这是就一个不合格的软件。而把一个充满bug的程序应用到实际工作中，那么可能会因为潜在的问题造成各种隐患，尤其针对银行业务系统而言更是如此。因此，系统的调试显得尤为重要。下面就本论文程序调试过程中发现的一些问题进行分析。对于交易的测试，主要就以下几项内容展开：5.3.1 交易正确驱动一个交易的正常运行，第一步就是保证交易的正确驱动。在系统设计阶段已经介绍过，系统中的交易驱动方式有两种：交易代码驱动和交易菜单驱动。如图5.3所示，是对公模块下单位活期业务各项交易的菜单驱动测试图。如图5.4所示，“企业活期存款开户申请”交易驱动成功。图 5.3 交易菜单驱动方式测试图图 5.4 交易驱动成功5.3.2 交易数据接收每一项联机交易，必定要在前台输入相关的交易数据，供后台程序接收处理。为了正确、顺利地完成程序执行，前台的数据输入必须正确。而对于输入错误或输入不合规范的数据，程序必须具备识别能力，并且及时地发出错误提示信息，提示用户更正。如图5.5所示，是单位活期存款开户交易界面，该交易要求前台输入客户的基本号，以便正确地定位总账下内部分户帐，并对该基本号登记科目存款帐号。图 5.5 企业活期存款开户交易界面5.3.3 交易执行测试及结果返回当交易能正确驱动并且前台正确地接收了数据后，接下来的重点就是考察后台程序是否按照相关业务流程执行，并且返回给前台。如图5.6所示，是活期现金存入交易界面，该交易要求输入客户名、对应账号类型与代码、存入现金金额等数据。前台将该数据包发送到后台，通过正确业务流程后，应返回前台客户号、客户名、对应帐号、交易金额及帐户余额。由于该交易参数设置为记交易流水，因此返回信息中还应显示当日该机构该笔交易的交易流水号。如图5.7所示，是交易成功后的返回信息界面。图 5.6 活期无折现金存入交易界面图 5.7 交易成功反馈信息界面6 总结与展望6.1 论文总结本文从计算机软件的角度，对商业银行综合业务系统后台进行了部分研究和设计实现的工作。在整个设计过程中，主要完成的工作有：（1） 通过现场调研和学习，掌握了商业银行综合业务的主要会计流程，以及设计并实现该系统所需要的技术知识和工具使用方法。（2） 在与客户充分沟通的基础上，做出需求分析。主要针对旧有系统的不足，以及随着时间发展，在银行会计流程上所发生的改变而相应地对系统进行更新和拓展。（3） 基于团队合作的精神，明确分工并制定统一的开发规则和编程风格，为今后工作顺利开展打下良好基础。（4） 在Unix环境下，使用C语言完成后台程序的编写工作。使用SmartTeller语言完成对应前台程序的编写工作。（5） 对程序进行调试，及时纠正产生的错误，并对调试过程中反映出的一些设计上的不足进行分析并采取相应措施。论文部分完成或没有完成的缺憾主要在于：首先，在本文完成时，系统已提交客户进行现场联测。在这个阶段，仍有可能出现一些隐藏的问题，或是应客户要求对系统进行一些调整或改变。作者没能参与这一阶段的工作，无法掌握第一手资料，因此在本文中对此无法进行详细分析和说明。其次，而有一部分则需留待日后，在掌握了更多相关知识并进行进一步需求分析和设计后才能开展。本文中则不能详细的介绍了。6.2 展望随着经济发展，商业银行业务种类和服务内容都不断拓展，商业银行综合业务系统的设计和实现具有非常重要的意义。未来一段时间内，针对该系统或与该系统相关的扩展工作势必持续不断。目前作者已知的主要有：（1） 配合银联2.0改造计划的继续实施，对系统本身安全性进一步分析和研究。此外，还包括完善对外接口的种类和数量，从而保证对各类外系统的支持。（2） 由于商业活动中，商业贷款流通次数日益增多、流通量日益增大，使得信贷业务系统纷纷从原先的综合业务系统中剥离而成为独立的系统。但是为了提高效率，很多交易又仍旧依赖综合业务系统后台，这对综合业务系统对外接口提出了新的要求。（3） 根据中国反洗钱监测分析中心中国反洗钱监测分析本外币报送标准相关内容，在数据报补入和监测方面提出了新的要求。（4） 商业银行为了自身生存和抢占市场的角度考虑，提出愈来愈多的中间服务，中间服务重在方便快捷，要做到这些，就必需要得到综合业务系统的良好支持。总的来说，目前国内在商业银行综合业务系统开发上已经积累了一定的经验，成果也得到了相当范围的注意和应用。还有一点在上文中并没有列出，目前属于作者自己的估计：在今后的日子中，考虑到外资银行在中国被允许开展的业务种类和数目的增加，系统与国际标准的接轨将愈来愈成为今后设计开发工作的重点。相应的，有关外汇业务的扩展工作也势必增加，并且很有可能如信贷业务系统一般，成为既依赖综合业务系统又相对独立的模式。从软件开发的市场角度来说，这会成为一片新天地。谢辞首先要感谢。老师在论文的设计过程中对我的精心辅导。在此，对。老师表示最诚挚的感谢!同时，要感谢大学四年来，各位老师对我的悉心教导，。我还要感谢我的校外指导老师，。有限公司的软件工程师，。老师。我表示由衷的敬意和衷心的感谢。另外，要感谢我周围的同学和公司开发团队中的队友们在学习和生活中对我的帮助，最后，感谢在百忙之中为本文审稿的诸位老师，。参考文献1 张海藩. 软件工程导论. 北京：清华大学出版社(第三版)，1998。2 萨师煊，王珊. 数据库系统概论. 北京：高等教育出版社（第三版），2000。3 钱逢胜，孙烨，汤丽萍. 商业银行会计. 上海：上海财经大学出版社（第二版），2004。4 谭浩强. C语言程序设计教程. 北京：清华大学出版社，1998。5 林锐，等. 高质量程序设计指南C/C+. 北京：电子工业出版社，2002。6 李凌云. UNIX环境下C语言编程规范. 上海华腾软件系统有限公司内部文档，2000。7 林德良. 中国银联信息处理中心交换系统集成项目编程规范. 上海华腾软件系统有限公司内部文档，2003。8 洪俊. TOPSmartTeller 使用手册 V3.1. 上海华腾软件系统有限公司内部文档，2002。9 TopSmartTeller终端界面开发平台 （/solutions/ solutioncolumn/huateng.pdf）10 Bea Tuxedo Quick S