厦门国际银行重要凭证管理系统-毕业论文

厦门国际银行重要凭证管理系统本科毕业论文(科研训练、毕业设计)题 目：厦门国际银行重要凭证管理系统姓 名：学 院：软件学院 系： 专 业：软件工程年 级： 学 号：指导教师（校内）： 职称： 助教： 年 月-65-摘要随着中国加入WTO第五个年头的到来，中国市场将完全允许外资银行进入。提高金融服务质量，加强金融产品创新成为国内银行面对的重要挑战之一。成熟的金融信息产品成为银行业务发展的重要基础，金融软件需求成倍扩展，发展速度持续加快，已经成为最有生命力的IT增长点。与此相伴的是大容量的数据处理与不断更新的业务需求，如何适应这种变化成为软件行业重要的挑战。银行凭证控制管理系统基于银行业普遍使用的J2EE架构，在传统的Browser/Server架构之上应用Ajax技术增强客户端功能，通过预定义接口与银行AIX业务系统无缝集成，结合J2EE框架与AOP技术，无伤织入的提供了安全控制与事务管理。最终形成了一个具有业务自动处理控制，帐务管理，分析汇总的综合凭证管理平台。本文从项目管理、系统设计、软件过程与质量保证等多个角度论述了证控管理系统的开发过程，总结此类系统的具体实践，为今后的开发提供参考。关键字：银行管理信息系统 凭证管理 Ajax J2EE B/SAbstractThis is the 5th year since China has joined the World Trade Organization with a promise to gain permission to qualified overseas banks providing financial services on an equal ground with domestic banks. Financial services quality and invocation ability have become the major challenge to domestic banks. Mature financial IT products are the most important foundation of banking system. With growing requirements and rapidly developing, financial software has become the most highlight field of IT industry. As fast increasing huge data processing requirements and frequently changed business logic, how to enhance banking system capability and functionality is the most critical issue in software industry.The Voucher Management System of XIB is based on Java 2 Enterprise Edition Architecture, which is wildly popular amount banking and other enterprise IT system. Introducing the Ajax technologies to the traditional Browser/ Server architecture to enhance rich client programs, flawless integration with the back-end AIX System via predefined communication protocol, using AOP Technologies and IoC dependencies fill, none injured weaved in faultless Security/ACL and Transaction Management solution into lightweight J2EE framework. Finally build a collaboration voucher management system including automatic dispose control, multiple propose accounting and analyzing system.This thesis will discuss system development process from project management, design and implementation, software process and quality assurance aspects with a conclusion of enterprise software strategy for further system reference.Keywords: Banking MIS Voucher Manage Ajax J2EE B/S目录第1章引言1第2章需求分析22.1系统环境22.2功能点概览22.3系统范围界定32.4系统用例5第3章软件过程方案113.1迭代开发113.2极限编程113.3测试驱动开发123.4每日构建与自动测试12第4章概要设计154.1业务领域分析154.2系统架构18第5章增量详细设计285.1版本1285.2版本2365.3版本349第6章测试536.1静态代码分析536.2单元测试536.3功能测试566.4性能测试576.5客户确认测试60第7章项目总结61致谢62参考文献63附录一：系统ER图64 ContentChapter 1Introduction1Chapter 2Requirement Analysis22.1System Environment22.2Functionalities Overview22.3System Bound Definition32.4System Use Case5Chapter 3Software Process113.1Iterative Development113.2Extreme Programming113.3Test Driven Development)123.4Daily Build And Automatic Testing12Chapter 4 Brief Design154.1Business Domain Analysis154.2System Architecture18Chapter 5Detail Design285.1Version 1285.2Version 2365.3Version 349Chapter 6 Testing536.1Static Code Analysis536.2Unit Testing536.3Functionality Testing566.4Performance Testing576.5User Assurance Testing60Chapter 7Project Summary61Acknowledgement62Reference 63Attachment 1：System ER Diagram64第1章 引言随着外资银行的全面入住，中国的银行业面临着前所未有巨大的考验，这也意味着国内各大银行的新一轮的信息化改革大战的全面来临。作为国内首家中外合资银行的厦门国际银行，在成功获得全面外汇业务和人民币业务牌照以及衍生产品交易业务资格之后，同时开通了为个人客户提供全面外汇业务和为企业客户和非居民提供包括人民币业务在内的全面金融服务。厦门国际银行在信息化建设一直走在同行业的前列，在日益增大的业务压力下，国际银行决定对传统的手工凭证管理升级成为信息化管理。 凭证管理系统是根据厦门国际银行业务部门的需求而量身定做的管理信息系统，用以解决凭证手工管理中存在的各种问题。该系统将实现从凭证领入到发出，至最终使用，回收的全过程的凭证生命周期的管理。并且提供了必需的凭证跟踪、查询、统计、报表生成、自定义打印等功能。具有良好的系统扩展能力，提供预留的、可方便再开发的接口设计，为满足客户的不同需求提供了良好的平台。 该系统是一套高效、简洁，并且能够进行查账、汇总、分析的智能化系统。可以快速、方便地按用户要求查询凭证信息，提高工作效率，减少工作量。并可取代手工记账，发出的凭证自动进入领用行库存，避免账实不符，对不上账等问题。且在业务操作过程中能方便、实时查询库存。此外，强大的数据备份、恢复功能，有效地保证了数据的完整性及安全性。第2章 需求分析2.1 系统环境2.1.1 开发环境Windows XP Service Pack 2Java Develop Kit version MySQL 5.1 / Oracle 10gEclipse WTP 1.5Apache Tomcat 运行环境RedHat Linux 9.0Oracle 10gJBoss 外部系统IBM AIX System2.2 功能点概览2.2.1 解决凭证管理中的问题为目的 申请、发送、领用、使用、回收全过程 凭证跟踪、查询、统计、报表生成 可以与银行小型机系统交互，实现异步同步服务 2.2.2 以稳定与简洁为出发点，优化用户体验 WEB开发，免部署利用Ajax技术优化用户体验和响应时间操作界面友好2.2.3 业务流程购买入库，处理出库，凭证在途，经过领用处理凭证信息同步到小型机，小型机可以对凭证进行多种业务操作，系统通过协议保持状态同步。通过上交操作可以在部门间、业务系统和部门间回收暂时不用的凭证。填写申请，主管授权，上级库管根据实际情况处理，电脑辅助自动分配凭证，下级库管需要核对凭证编号与数量，确认入库，否则重新进入申请处理环节，撤销所有操作。2.2.4 特殊业务状态 通过生效期来保证凭证受控状态 冻结、挂失、注销、销毁等。2.2.5 管理需求机构 自定义树状机构框架 总管理员可以设置并任命机构管理员 各机构管理员可以设置本部门人员 权限 多用户角色权限设置 对于库管员更可以单独设置业务权限 2.2.6 良好的用户界面 快速的反应时间 方便部署和使用 易于掌握 2.2.7 多种报表 科目详细帐 科目汇总张 查库清单 2.2.8 系统自动信息提醒与邮件辅助 2.3 系统范围界定2.3.1 部门说明图表 1 部门机构图管理部门包括总库和分行机构计财部，使用部门包括总行领用部门和分行机构领用部门。2.3.2 角色说明系统管理员系统管理员的主要职责包括系统信息的设置、部门的管理、部门管理员的管理以及部门管理员的分配。部门管理员部门管理员的主要职责包括本部门用户的管理、部门凭证类型的维护、部门凭证警戒线的管理以及与部门相关的批量历史数据的导入。授权主管1. 总库授权主管职责包括授权总库库管员向下级部门发出缴回通知，授权总库凭证出库，授权总库凭证销毁/作废/冻结/当日恢复/解冻，授权总库库管员购买申请,查询等。2. 分行机构计财部授权主管职责包括授权本部门库管员向下级部门发出缴回通知，授权本部门凭证出库，授权本部门库管员的领用申请，授权本部门凭证销毁/作废/冻结/当日恢复/解冻，授权本部门库管员的购买申请，查询等。3. 分行机构领用部门授权主管（包括分行营业部授权主管和支行授权主管）职责包括授权本部门凭证出库，授权本部门库管员的领用申请，授权本部门凭证销毁/作废/冻结/当日恢复/解冻，授权本部门经办手中凭证挂失/解冻，查询等。4. 总行领用部门授权主管职责包括授权本部门凭证出库，授权本部门库管员的领用申请，授权本部门凭证销毁/作废/冻结/当日恢复/解冻，授权本部门经办手中凭证挂失/解冻，查询等。库管员1. 总库库管员职责包括总库凭证的入库，总库凭证的出库（待总库授权主管授权后真正出库），总库凭证销毁/作废/冻结/当日恢复/解冻（待总库授权主管授权后真正执行），拒绝下级部门的领用申请，向下级部门库管员发出缴回申请（待总库授权主管授权），查询，并确认总库非本人所进行的操作等。2. 分行机构计财部库管员职责主要包括本部门凭证的入库，本部门凭证的出库（待本部门授权主管授权后真正出库），向上级部门库管员发出领用申请（待本部门授权主管授权后真正执行），本部门凭证销毁/作废/冻结/当日恢复/解冻（待本部门授权主管授权后真正执行），拒绝下级部门的领用申请，向下级部门发出缴回申请（待本部门授权主管授权），查询，并确认本部门非本人所进行的操作等。3. 分行机构领用部门库管员职责主要包括本部门凭证的入库，本部门凭证的出库（待本部门授权主管授权后真正出库），向上级部门库管员发出领用申请（待本部门授权主管授权后真正执行），本部门凭证销毁/作废/冻结/当日恢复/解冻（待本部门授权主管授权后真正执行），拒绝本部门经办的领用申请，查询，并确认本部门非本人所进行的操作等。4. 总行领用部门库管员职责主要包括本部门凭证的入库，本部门凭证的出库（待本部门授权主管授权后真正出库），向上级部门库管员发出领用申请（待本部门授权主管授权后真正执行），本部门凭证销毁/作废/冻结/当日恢复/解冻（待本部门授权主管授权后真正执行），拒绝本部门经办的领用申请，查询，并确认本部门非本人所进行的操作等。经办主要职责包括向本部门库管员发出领用申请，领用凭证，售出手中凭证，凭证销号，手中凭证销毁/作废/挂失/当日恢复（待本部门授权主管授权后真正执行），每日上缴凭证，查询等。2.4 系统用例2.4.1 基础系统需求账务管理账务管理是银行系统中的核心部分，系统提供自动的账务处理功能，对于凭证在部门间及部门内流动所长生的账务问题自行分析，并能生成科目总账报表和分账户表。定时数据同步由于系统要于银行当前前台所使用AIX系统就行交互，所以系统自动定时同步不同系统中的数据相。通知与邮件系统针对系统其他涉及申请审批的功能模块，自动生成意见书，并自动发送给下一操作人员。使用人员在当先操作流程中输入意见。系统自动将意见等信息生成意见书并发送给流程下一操作人员。日志管理日志系统分为业务日志和系统日志，业务日志记录发生在工作流程所涉及的业务所作及账务转换信息，日志信息存储于数据库表中，为账务管理提供基础；系统日志存放在文件中。系统设置提供用户界面进行一些系统参数的设置，如邮件服务器的地址等。进入系统设置页面，进行相关相的设置，并保存。2.4.2 用户及权限管理部门管理系统管理员进行部门的管理维护的工作，包括部门的新增、修改、删除，部门管理员的 、修改、删除，以及部门管理员的分配。进入部门管理页面，选择机构树上的节点，查看修改部门信息，为部门分配管理员（管理员需先新增，并不为其他部门的管理员），可以为部门新增子部门。用户管理部门管理员对本部门的用户信息进行维护工作，包括新增、修改、锁定等操作，部门管理员进入本部门用户管理界面，显示当前部门所有用户列表，选择用户可以查看修改用户详细信息，并可锁定用户，选择新增可以新增部门用户信息。权限管理授权主管对本部门的库管进行授权操作。授权主管进入库管员授权页面，选择部门库管，查看修改其所拥有的权限。2.4.3 重要凭证购入部门库管员对新购入的凭证进行入库操作，流程分为入库和入库确认，一库管员录入新购凭证的信息，本部门其他库管员进行信息的确认。购入凭证入库部门库管员录入新购凭证的信息。部门库管员进入凭证购入页面，填写新购凭证的信息，可填写多中凭证的信息，确认后系统新增流程信息，待下一步信息的确认。购入凭证入库确认部门库管员对于本部门的新购凭证信息进行确认，业务功能说明，部门库管员登录，如果有需要确认信息，会在任务列表中看到任务信息，打开任务，查看新购凭证信息，填写意见，同意或者拒绝入库。2.4.4 重要凭证申请及领用（部门）下级部门向上级部门申请领用重要凭证，上级部门同意或者拒绝申请，若同意，则分配相关凭证给下级部门，下级部门收到凭证实物后，对凭证进行入库操作，流程分为下级部门申请、上级部门分配、下级部门领用。下级部门申请下级部门库管员填写申请单，申请重要凭证，可申请多种，并可撤销申请。申请完成后本部门授权主管对申请进行授权，可以同意或决绝，如果同意，则交上级部门处理。部门库管员填写申请单，包括申请的凭证类型和数量，可填写多种，在未授权前库管员可撤销自己填写的申请，本部门授权主管查看申请信息，可以同意或拒绝，若同意，则交上级部门处理，若拒绝，则撤销申请。上级部门分配上级部门库管员处理下级部门的领用申请，可以同意活着拒绝申请，若同意则按数量分配凭证。上级部门库管员登录后在任务列表中看到该任务，打开该任务，看到申请的信息，可以同意或者决绝申请，若同意，则填写为每种类型凭证分配的数量，由系统自动分配凭证，若拒绝，则结束流程，发送决绝通知给申请人。下级部门领用下级部门在收到上级部门分配的凭证后，核对实物与处理信息，若无误，则将凭证入库。下级库管登录后打开相关任务，核对实物于处理信息，无误则确认凭证入库。2.4.5 重要凭证特殊业务操作重要凭证注销销号部门库管对本部门内的重要凭证进行注销销号操作，库管选择本部门内相关编号区间内的凭证，并设定生效日期，本部门授权主管授权后，凭证在生效日注销销号，操作不可恢复，部门主管进入注销销号页面，选择本部门内的重要凭证。设定生效日期，本部门授权主管授权此操作，可以同意或者拒绝；若同意，凭证在生效日被注销销号。重要凭证销毁部门库管对本部门内的重要凭证进行销毁操作，库管选择本部门内相关编号区间内的凭证，本部门授权主管授权后，凭证被销毁，操作不可恢复，部门主管进入销毁操作页面，选择本部门内的重要凭证，本部门授权主管授权此操作，可以同意或者拒绝，若同意，凭证被销毁。2.4.6 普通凭证处理普通凭证没有凭证编号，处理时只跟凭证数量有关。普通凭证购入部门库管填写本部门购入普通凭证的种类、数量、单价等信息，直接将购入普通凭证入库。部门库管进入普通凭证购入页面，选择普通凭证种类，填写数量、单价，填写多种凭证购入信息，确认入库。普通凭证经办领用部门库管填写本部门经办普通凭证领用信息，系统与AIX系统交互，同步数据库。部门库管进入普通凭证经办领用页面，填写普通凭证信息，经办操作员码，确定后系统与AIX系统交互，同步数据库，领用完成。2.4.7 凭证查询通过多种查询方式追踪凭证状态重要凭证查询使用人员对重要凭证的信息进行查询，重要凭证查询分为多条件查询、前缀匹配查询和区间查询，使用人员可根据需要，选择合适的查询方式查询信息。使用人员进入重要凭证查询页面，使用人员选择多条件查询/前缀匹配查询/区间查询，多条件查询输入部门，凭证类型，日期，凭证状态，操作员码中的一项或者几项条件，默认不输入时则为查询本部门所有凭证。前缀匹配查询输入凭证号码前面几位，区间查询输入凭证区间号码，条件输入完毕单击查询，生成结果页面，可以对结果中的每一栏目进行页面内排序，双击查询结果中的某一个条目可以查看该凭证的详细信息。普通凭证查询使用人员对普通凭证信息进行查询，主要查询条件为凭证所属部门、凭证类型和交易时间，交易时间为时间区间。本部门库存查询部门库管员查询本部门所有凭证的信息及使用状态等。2.4.8 数据补入用于系统运行前业务数据的按需加入批量数据补入部门管理员将历史存在的批量凭证数据导入系统中，数据存放在CSV格式文件中，具体数据格式请参照模板。单张凭证数据补入本部门库管将部门内的单张凭证信息导入系统，需填写凭证详细信息，确认后更新数据库。2.4.9 凭证基础信息管理部门管理员管理本部门凭证的基本信息，包括部门内凭证类型的管理和警戒线的设置。凭证类型管理部门管理员管理本部门的凭证类型。部门管理员进入凭证类型管理页面，查看凭证类型列表，查看凭证类型详细信息，可以修改或新增凭证类型。凭证警戒线管理部门管理员设置本部门凭证的警戒线。部门管理员进入凭证警戒线设置页面，查看已设置凭证警戒线类表，查看警戒线详细信息，可以修改或新增凭证警戒线信息。2.4.10 押汇部门操作押汇经办领用押汇部门经办领用凭证，本部门库管填写领用信息，并根据操作员码从系统中提取经办信息，打印领用清单。本部门库管进入押汇经办领用页面，填写领用凭证信息，填写多种凭证信息，填写经办操作员码，系统返回经办个人信息，打印领用清单。修改当天业务事件押汇部门经办查看修改当天业务时间信息，需填写详细业务事件信息。2.4.11 业务报表业务人员输入一个时间区间和各种参数，查询该时间区间内每一笔业务操作的详细情况或者当天所有操作的汇总，方便业务人员查看并进行统计计算。分账户报表相关业务人员输入各种必填参数生成每一笔业务操作的详细记录，在页面上查看报表，或者对生成的页面报表进行下载操作。库管，主管，部门管理员都可以进行分报表查询操作。进入业务报表查询界面，填写包括部门，凭证类型，开始日期，结束日期，是否分账户在内的必填参数，单击生成报表，生成页面分账户业务报表，单击下载EXCEL报表下载可以下载excel格式的的电子表单(可选)。总账户报表相关业务人员输入各种参数生成总帐户汇总报表，在页面上查看报表，或者对生成的页面报表进行下载操作。库管，主管，部门管理员都可以进行总报表查询操作。进入业务报表查询界面，填写包括部门，凭证类型，开始日期，结束日期，是否分账户在内的必填参数，单击生成报表，生成页面分账户业务报表，单击下载EXCEL报表下载可以下载excel格式的的电子表单(可选)。第3章 软件过程方案3.1 迭代开发(Iterative Development)这样的一种软件开发方式，计划内固有的论断通过系统演示版本的设计或开发进行重复的验证与评估，每一个均被客观的演示，以减少项目风险及建立另一个完整的解决方案。这种开发方式通常被理解为迭代的增量开发过程，我们对其进行如下的定义：一种包括对一系列活动的重复应用以对一系列论断进行评估，解决一系列风险，达成一系列开发目标，并逐步增量地建立并完善一个有效的解决方案 。由于它通过对核心开发活动的重复应用，包括了对问题，解决方案定义以及解决方案实现的连续的细化，因此，它是一个迭代的过程。由于在一次迭代运行的周期中，对问题的理解以及解决方案提供的功能均会增长，因此，它是一个增量的过程。 在迭代中，其中数个或更多的应用被连续地组织起来以构成一个完整的项目。在每个迭代周期中由包括有限多个个体软件过程。这个过程包括开发者的分析、设计以及测试的过程。开发者通过选择一组需求并变更请求以进行分析，设计，实现，构造，单元测试，然后将其集成入产品发行中以进行自己的工作。开发人员的迭代过程的时间及规模从数个小时，数日，直至数周而不同，这取决于所进行工作的规模与复杂度。迭代的目的是将整个开发团队的工作集成到一个稳定的，完整的，可测试的系统发行版本中。对大多数迭代来说，这些发布版本为内部发布主要为开发团队所建立的基线，并且为迭代以及对所做出的进展进行度量提供关闭条件。这些只是内部发布版本，而并不是为用户所开发的。典型地，在软件公共发布版本之前，存在着三次或更多次的迭代。在此序列中的每次迭代过程审查系统发布产品，从第一次迭代中的小型的，部分实现的系统，通过一次又一次地迭代，逐次增长地实现更多需求，直至产生出最终地客户发布版本。3.2 极限编程(XP)极限编程（Extreme Programming，XP）是一门针对业务和软件开发的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为目标而产生的一种方法论，XP使开发者能够更有效的响应客户的需求变化，哪怕是在软件生命周期的后期。它强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用。极端编程属于轻量级的方法，认为文档、架构不如直接编程来的直接。极限编程中有四个核心价值是我们在开发中必须注意的：沟通（Communication）、简单（Simplicity）、反馈（Feedback）和勇气（Courage）。3.3 测试驱动开发(TDD)测试驱动开发（Test-Driven Development，TDD）是通过测试定义所要开发的功能的接口，然后实现功能的开发过程。Test-Driven Development(TDD)，是Extreme Programming (XP)-极限编程的一个重要组成部分。测试驱动的基本过程包括：明确当前要完成的功能；可以记录成一个 TODO 列表；快速完成针对此功能的测试用例编写；测试代码编译不通过；编写对应的功能代码；测试通过；对代码进行重构，并保证测试通过；循环完成所有功能的开发。3.4 每日构建与自动测试每日构建意味着自动地，每天，完整地构建整个代码树。每日构建对于软件开发的好处主要体现在：当一个bug被修正了，测试者可以很快得到最新的修正后的版本开始重新测试，以验证bug是否真正地被修复了。 开发人员可以更加确定他们对代码做的修改不会破坏1024个操作系统上的任何一个版本。 那些每天将修改过的代码导入（check in）版本控制服务器的开发人员知道，他们对一个模块导入的修改不会拖别的开发人员的后腿。外部团队（例如市场销售部门，进行beta测试的一些客户）可以获得一个比较稳定的版本，这样对他们开展自己的工作比较有利。 假如你将每日构建出的二进制文件（例如一个可执行程序，一个dll等等）存档管理，那么当你发现一个非常奇怪的，无法解决的bug时，你可以通过 对这些文件进行二进制搜索（binary search）来确定什么时候这个bug第一次出现。如果有对代码进行了完善的版本控制，你也可以找出是谁在何时对代码进行的导入（check in）导致了这个bug。 当开发者修正了测试者报告的一个错误时，如果测试者同时报告了发现错误时的构建的版本，开发人员可以直接在那个版本中测试是否bug真正被修复了。 图表 2 日构建工具在实际操作中，项目选择LuntBuild和Ant作为执行日构建任务的工具。Luntbuild是一种基于流行的构建工具- Apache Ant- 的自动化构建和管理工具。 通过Luntbuild，可以很容易做到日构建和持续集成。在Luntbuild里面最基本的操作单位是一次构建(build)。构建通过构建计划(Schedule)触发，也可以通过手工启动。 在Luntbuild里面一次构建会经过以下几个步骤: 1. 从版本控制系统(VCS)中获取源码。(在该项目中为SVN) 2. 对当前源码打上标签，标签值就是当前构建的版本号. 3. 在源码目录下运行相关的Ant构建脚本(build script)。 4. 在源码目录下运行相关的Ant构建后处理脚本(post build script)。 5. 发布构建的日志以及其他构建制品(build artifacts)。同时LuntBuild可以自动发送邮件提醒以及源码变更清单，在出错的时候可以快速定位错误原因。LuntBuild的后处理脚本中可以加入自动化的单元测试，从而进一步实现测试自动化。详细内容可以参看测试与重构一节。项目对LuntBuild构建的最新版本自动部署到测试服务器，客户可以用帐号随时登录查看项目进展情况，并在项目早期提供有价值的反馈，从而保证项目的成功。Apache Ant 构建工具是一个可靠的、跨平台的构建工具，正如其名字一样，小工具可以做大事情。Ant正在逐渐成为开源世界乃至工业界的事实标准。Ant的一些特性：类可扩展性 Java 类可用于扩展构建特性，而不必使用基于 shell 的命令。开放源代码。因为 Ant 是开放源代码，因此类扩展示例很充足。XML 可配置 Ant 不仅是基于 Java 的，它还使用 XML 文件配置构建过程既可以执行Java构建任务，如：编译，打包，部署等等；也可以通过执行命令行来与系统交互，如：开始，停止系统服务等。Ant还可以执行单元测试，返回特定结果，给外部程序处理，如LuntBuild。第4章 概要设计4.1 业务领域分析4.1.1 业务流程活动图图表 3 凭证购入活动图业务逻辑购入凭证，确认购入凭证入库图表 4 凭证申请活动图业务逻辑下级部门申请，下级授权主管批准，上级部门分配，下级部门领用图表 5 经办领用活动图业务逻辑重要凭证申请及领用4.1.2 业务流程状态图图表 6 重要凭证正常业务状态图图表 7 重要凭证特殊业务状态图4.2 系统架构4.2.1 概览图表 8 Web 2.0时代的四层结构在架构上，应用发展多年被绝大多数银行采用的J2EE架构。并且抛弃对该项目而言有点太过笨重的EJB组件，采用轻量级J2EE方案，并且结合新型的Web2.0模式实用的技术，利用Ajax来优化表现层实现。即在原有的MVC三层框架中，加入Ajax引擎，实现第四层可选的架构。图表 9 系统架构图通过这种方式，最大限度的应用已经成功的框架体系，同时融合新技术，在避免风险的同时提供最佳的用户体验。表格 1 系统所用第三方包列表框架集/软件包功能概述Spring 2 Framework轻量级J2EE框架为模块的独立实现与交互操作提供接口提供事务管理支持Hibernate 3 with Annotation数据模型持久化支持利用Jave EE 5的Annotation特性简化配置Acegi安全框架统一规范的用户权限认证应用AOP技术提供代码级别的安全控制Dojo Toolkit受到SUN和IBM支持的AJAX框架跨浏览器支持，优秀的扩展性Direct Web RemoteJavaScript JSON数据与JAVA数据转换WEB程序与J2EE程序无缝连接4.2.2 数据访问层架构1. DAO技术简介DAO是Data Access Object的缩写，数据访问对象。顾名思义，数据访问对象负责与数据库打交道，对数据库进行存取操作。夹在业务逻辑与数据库资源中间，为业务逻辑层提供基础数据和把经过复杂的逻辑转换生成的数据重新存回数据库。DAO是一个经典的设计模式。在著名的J2EE核心模式中对DAO是这样描述的：为了建立一个健壮的J2EE应用，应该将所有对数据源的的访问操作抽象封装在一个公共的API中。从程序设的角度出发，即建立一个接口，接口中定义了此应用程序中将会用到的所有事务方法。在这个应用程序中，当需要和数据源进行交互的时候则使用这个接口，并且编写一个单独的类来实现这个接口在逻辑上对应这个特定的数据存储。我们为每一个模型类都创建一个DAO类，该类继承Hibernate中HibernateDaoSupport类，可以很方便地实现底层数据库的操作。2. ORM技术简介对象关系映射（Object Relational Mapping，简称ORM）是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。 简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将java程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。 这也同时暗示者额外的执行开销；然而，如果ORM作为一种中间件实现，则会有很多机会做优化，而这些在手写的持久层中很难实现。3. Hibernate技术简介Hibernate是目前比较流行的ORM持久化框架。在选取持久化框架的时候，我们综合比较了Ibatis, Hibernate2/Hibernate 3, JDBC几种解决方案。Hibernate，透明持久化，透明意味着调试和配置完毕后，使用起来很方便。对于经常需要访问的东西可以通过简单配置即可以得到二级缓存支持。Hibernate适合Domain Model相对固定，数据库模型到OO模型映射不超出限制的情况。但是Hibernate2需要对每一个POJO(Plain Old Java Objects普通Java对象)类写一个XML映射文件。Hibernate3则无需如此烦琐的配置，只需要用Java 5 中的Annotation新特性，在POJO中用annotation简单注释即可实现一对一或者多对一映射。IBatis则适合批量更新删除，复杂的联表查询，并且还需要O/R Mapping提供足够的OO特性的时候，它比直接用JDBC简单，性能相当。JDBC则对于已经熟悉它的人比较简单。而且JDBC也可以通过自己的包装或者模版类变得简单和规范，但是OO性可能差一些，而且代码量大，相对会比较烦琐。综合比较，我们选取了配置相对简单的Hibernate 3, 它提供了功能完整、性能优秀的对象持久性映射（ORM）即持久层映射核心。Hibernate可以帮助开发者节省持久层编码时间，有助于面向对象的设计。Hibernate 3 中的 Annotation提供了JDK 5.0 代码标注的功能，从而替代Hibernate 2 中的XML元数据配置文件，通过使用Hibernate Annotation，能够减少描述符，编译期校验，以及减少配置和维护工作等。它们提供了其他XML元数据，提供了在XML元数据中不存在的一些功能，诸如Lucene和Validator等等，增强了可扩展性。Hibernate 的轻量级 ORM 模型近年来已经逐步确立了在 Java ORM 架构中的领导地位，甚至取代复杂而又繁琐的 EJB 模型而成为事实上的 Java ORM 工业标准。而且其中的许多设计均被 J2EE 标准组织吸纳而成为最新 EJB 3.0 规范的标准。这也是我们之所以选择Hibernate的原因。图表 10 Hibernate 3.0核心模式4. Java 5 Generic Types (泛型)技术简介在实际的程序应用开发中，集合类是使用最多的基础类，在Java5.0之前，集合类只提供一种类型(object 类型)存储.而现在可以提供多种数据类型,对于像int, boolean, double等基本类型,java5.0中会当放入集合类型中时自动为其装箱成相应的对像如Integer, Boolean, Double数据类型,当取出时自动拆箱成相应的基本数据类型。4.2.3 业务逻辑层架构1. MVC技术简介MVC( Model-View-Controller)，即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层模型层、视图层、控制层。 视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。在我们的系统里则为JSP页面，随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，这里的处理指的是数据验证以及数据修正例如EMAIL地址合法性的验证和删除不可见的控制字符，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个申请单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。 业务模型有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。 控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。 模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。2. Sping技术简介图表 11 Spring 2.0Sping是一个轻量级的容器，可以提供包括事务在内的很多服务。Spring是一个优秀的轻量级J2EE框架，它能够跟Hibernate很好地结合在一起， Spring的目标是实现一个全方位的整合框架，在Spring框架下实现多个子框架的组合，这些子框架之间彼此可以独立，也可以使用其它的框架方案加以替代。Spring不会特別去提出一些子框架来与现有的开源框架竞争，除非它觉得所提出的框架夠新夠好，例如Spring有自己的 MVC框架方案，因为它觉得现有的MVC方案有很多可以改进的地方，但它不强迫您使用它提供的方案，我们可以选用自己选取的框架来取代其子框架，例如我们在Spring中整合WebWork框架 。Spring的核心概念是IoC (Inversion of Control)反向控制，简单而言即一个类只有在生成的时候才知道跟它关联另一个类的信息，这样做可以降低应用程序的耦合度，提高程序的可维护性和可扩展性。Aop(Aspect Oriented Programming)面向方面编程，Spring这个功能可以使得程序开发者更好地将本不应该彼此黏合在一起的功能分离开来。在实际的程序开发中，通常包含两种代码，一种是和业务逻辑相关的代码，比如该系统中的凭证领用上缴销毁等流程相关代码，另一种则是和业务关系不大的代码，比如权限验证，日志系统，异常处理，事务处理，如果没有Spring的AOP，我们编写代码的时候这些代码基本上是写在一堆的，这样一来在程序中处处充满着相似或者类似的代码，当然有些类似的方法我们可以在开发后期用重构的方法进行代码优化，但是并不是每个方法都能够简化，比如日志信息，几乎每个方法都要写日志的输出，又比如权限的验证，在每一次调用关键方法的时候我们需要进行权限的验证，尽管有重构，程序里还是充满了冗余的代码，不利于维护和扩展。而AOP正好就是使这两种代码分离的思想，可以不用在业务逻辑中实现与业务功能关系不大的代码，从而降低了两种代码的耦合性。可以把权限验证，日志输出，事务处理等都看成是一个切面，需要的时候插入进去就可以了，这正是所谓的面向方面编程。业务逻辑层又叫service层，是具体实现业务逻辑的一系列代码，这些代码包含具体的商业逻辑，通过调用底层DAO数据访问对象对数据库进行基础的增删改查，并把取出的数据做若干转换处理形成可用数据，传给表示层展现给最终用户。这相当于MVC（Model View Control）设计中的Control层，我们选用了一个轻量级的J2EE框架Spring来控制事务，而不用仅仅为了事务功能就去实现复杂的EJB对象，减少了开发量和代码的复杂程度。图表 12系统架构图4.2.4 用户表示层架构1. 会话管理(Session Management)“用户会话”，描述的是在客户端和服务器之间的多次请求所构成的一种“会话”。用户会话是用户识别，业务逻辑的基础概念，在BS架构中必须加以控制。因为HTTP协议是一种无状态的协议，因此需要Web应用通过某种机制来维护会话状态。虽然也可以选择其他方式，如客户端保存会话状态等，但表示层保存会话状态更方便使用，也更为常见。此外为了配合复杂多变的系统环境（如集群服务器）和异构的用户环境（不同的浏览器，安全措施），表现层必须具有一定的适应性（如自动切换会话保存模式）和可扩展性。2. 访问控制(Access Control)出于很多原因，我们需要控制用户对于特定资源的访问。我们可能需要用户为某种状态才能访问某个视图。如，用户登录。也可能需要根据业务逻辑的改变展现不同的数据和操作界面。如，工作流的不同阶段。表示层应当提供某种机制来提供这些功能。主要的访问控制手段有：保护视图在视图显示逻辑中加入一些代码来控制用户请求，这种保护适合一些逻辑复杂的场合，但是从全局看显得代码冗余不宜更改。配置保护J2EE的安全标准提供了实现用户访问控制的绝佳方案。而且在特定环境下，有时要求必须使用标准的API来获取用户信息。但这种方式有时显得不够灵活，对于复杂的逻辑难以实现。重复表单提交有时业务要求用户必须以一定的流程访问。重复的事务操作可能引起不确定的业务状态，在大多数情况下我们都希望