凭证管理及报表分析系统.docx
- 文档编号:23704709
- 上传时间:2023-05-20
- 格式:DOCX
- 页数:37
- 大小:1.63MB
凭证管理及报表分析系统.docx
《凭证管理及报表分析系统.docx》由会员分享,可在线阅读,更多相关《凭证管理及报表分析系统.docx(37页珍藏版)》请在冰豆网上搜索。
凭证管理及报表分析系统
本科毕业论文
(科研训练、毕业设计)
题目:
凭证管理及报表分析系统
姓名:
陈肖如
学院:
软件学院
系:
软件工程
专业:
软件工程
年级:
2003级
学号:
03368004
指导教师(校内):
史亮职称:
讲师
指导教师(校外):
王磊职称:
工程师
2005年6月2日
凭证管理及报表分析系统
[摘要]我国加入WTO以后,我国金融业将面临来自国外的竞争,也给中国金融业带来了压力,如何利用更加科学和高效的手段对经营数据进行分析,是商业银行业务发展的需要。
在此背景下,我们开发了凭证管理及报表分析系统。
该系统采用J2EE架构,使用了MVC模式,并以目前较为流行的基于J2EE的应用程序框架Struts作为开发框架,尝试了J2EE在信息管理领域和数据统计领域中的应用。
凭证管理及报表分析系统是基于Web的凭证及报表的生成打印系统。
该系统可以协助银行管理人员管理特种转帐明细记录,并从中获取有价值的统计信息,从而达到管理分析和决策支持的目的。
[关键词]J2EEStrutsB/S架构MVC模型JavaBean
Vouchermanagementandreportanalysissystem
[Abstract]AfterjoiningtoWTO,Chinawillfacethecompetitiontofinanceindustryfromoverseas,thus,ourcommercialbanksmustthinkabouthowtoanalyzethebusinessdatamorescientifically.Withthisbackground,wedeveloptheVouchermanagementandreportanalysissystem.TryingtouseJ2EEininformationmanagementdomainanddatastatisticsdomain,thesystemuseJ2EEstructure,theMVCpatternandtheStrutsframework.Thissystemwillhelpthebankmanagermanagethedealingrecord,andgetvaluableinformationfromthem.
[Keyword]J2EEStrutsB/SMVCJavaBean
中文摘要
Abstract
第1章绪论
1.1引言
当前,随着技术的日益进步,传统的软件开发两层结构正逐渐转变为多层体系结构,但在带来巨大的灵活性的同时,也增加了创建、测试、配置、管理和维护应用组件的复杂性;企业、公司纷纷需要参与到Internet中来,各种业务都进入了网络,这些企业级应用的快速增长促使其需要一个强壮的、企业级的、以web为中心的应用结构来支撑。
以J2EE技术为代表的分布式对象技术和组件技术为解决上述的种种问题提供了一条很好的途径。
J2EE技术的运用,降低了开发多层服务的成本和复杂性,使企业面对新的需求能够迅速部署和增强服务,极大地提高软件的生产率。
本系统对J2EE技术的采用,充分体现了其技术优点。
1.2研究背景与研究意义
在金融领域,尽管目前正在进行数据大集中,但是仍然有许多的业务数据需要手工以书面形式传送。
这种重复工作,加大了业务处室的工作负担,在一定程度上也影响工作效率。
同时,在我国加入WTO以后,我国金融业将面临来自国外的竞争,也给中国金融业带来了压力。
如何利用更加科学和高效的手段对经营数据进行分析,是商业银行业务发展的需要。
当前,现代商业银行基本上已经建立起了完备的业务系统,积累了相对丰富的历史数据,可以利用这些宝贵的历史数据为银行服务,包括从历史数据中发现金融市场的发展规律、预测业务未来的变化趋势、洞悉业务经营的状况、预测和监控风险、辅助决策者发现新的利润增长点、优化银行的资金配置、帮助银行更加稳健地实现银行的管理和经营目标。
1.3工作内容
凭证管理及报表分析系统是基于Web的凭证及报表的生成打印系统。
该系统可以协助银行管理人员管理特种转帐明细记录,并从中获取有价值的统计信息,从而达到管理分析和决策支持的目的。
具体包括:
交易记录的查询、修改功能,凭证的预览打印功能,传统报表以及图形报表的定制、打印功能,和一般的系统管理功能。
1.4论文组织结构
本文将依次介绍以下内容:
在第二章中,我们将主要介绍J2EE相关技术,包括J2EE的基本概念,其常见模式MVC(Model-View-Controller)的体系结构,以及目前较为流行的基于J2EE的应用程序开发框架Struts的基本组成。
在第三章中,我们将提出凭证管理及报表分析系统的总体设计,包括系统的功能框架、数据在系统中的流向和部分组件的设计。
在第四章中,我们将给出本系统的具体实现。
主要包括凭证管理模块的实现顺序、界面实现,和报表分析模块的操作流程、界面实现等。
在第五章中,我们将以Struts中的分页显示,以及金额数值向中文大写金额的转换这两个技术难点的实现细节为例,介绍本系统的一些技术特点。
第2章J2EE相关技术介绍
Java2平台企业版,也就是J2EE,定义了开发多层企业应用程序的标准。
它的诞生并不是偶然的,它是在各种条件积累成熟之下的产物。
2.1J2EE(Java2EnterpriseEdition)
J2EE是一种利用Java2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。
J2EE技术的基础就是核心Java平台或Java2平台的标准版,J2EE不仅巩固了标准版中的许多优点,例如"编写一次、随处运行"的特性、方便存取数据库的JDBCAPI、CORBA技术以及能够在Internet应用中保护数据的安全模式等等,同时还提供了对EJB(EnterpriseJavaBeans)、JavaServletsAPI、JSP(JavaServerPages)以及XML技术的全面支持。
其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。
J2EE使用多层的分布式应用模型,应用逻辑按功能划分为组件,各个应用组件根据他们所在的层分布在不同的机器上。
事实上,sun设计J2EE的初衷正是为了解决两层模式(client/server)的弊端,在传统模式中,客户端担当了过多的角色而显得臃肿,难于升级或改进,可伸展性也不理想,而且经常基于某种专有的协议――通常是某种数据库协议。
它使得重用业务逻辑和界面逻辑非常困难。
现在J2EE的多层企业级应用模型将两层化模型中的不同层面切分成许多层。
一个多层化应用能够为不同的每种服务提供一个独立的层,以下是J2EE典型的多层结构[1]:
(1)Clienttier客户层
一般为浏览器或其他应用。
客户层普遍地支持HTTP协议,也称客户代理。
(2)WEBtierWEB应用层
在J2EE中,这一层由WEB容器运行,它包括JSP,SERVLET等WEB部件。
(3)EJBtier企业组件层
企业组件层由EJB容器运行,支持EJB,JMS,JTA等服务和技术。
(4)EIStier企业信息系统层
企业信息系统包含企业内传统信息系统如财务,CRM等,特点是有数据库系统的支持。
图2-1J2EE体系架构
2.2MVC模式
MVC(Model-View-Controller)模式是交互式应用程序广泛使用的一种体系结构。
它有效地在存储和展示数据的对象中区分功能模块以降低它们之间的连接度,这种体系结构将传统的输入、处理和输入模型转化为图形显示的用户交互模型,或者换一种说法,是多层次的Web商业应用;MVC体系结构具有三个层面:
模型(Model)、视图(View)和控制(Controller),每个层面有其各自的功能作用,MVC体系结构如下:
图2-2MVC模型(B/S模式)[2]
模型层负责表达和访问商业数据,执行商业逻辑和操作。
也就是说,这一层就是现实生活中功能的软件模拟;在模型层变化的时候,它将通知视图层并提供后者访问自身状态的能力,同时控制层也可以访问其功能函数以完成相关的任务。
视图层负责显示模型层的内容。
它从模型层取得数据并指定这些数据如何被显示出来。
在模型层变化的时候,它将自动更新。
另外视图层也会将用户的输入传送给控制器。
控制层负责定义应用程序的行为。
它可以分派用户的请求并选择恰当的视图以用于显示,同时它也可以解释用户的输入并将它们映射为模型层可执行的操作;在一个图形界面中,常见的用户输入包括点击按钮和菜单选择。
在Web应用中,它包括对Web层的HTTPGET和POST的请求;控制层可以基于用户的交互和模型层的操作结果来选择下一个可以显示的视图,一个应用程序通常会基于一组相关功能设定一个控制层的模块,甚至一些应用程序会根据不同的用户类型具有不同的控制层设定,这主要是由于不同用户的视图交互和选择也是不同的[3]。
在模型层、视图层和控制层之间划分责任可以减少代码的重复度,并使应用程序维护起来更简单。
同时由于数据和商务逻辑的分开,在新的数据源加入和数据显示变化的时候,数据处理也会变得更简单。
2.3Struts框架
Struts是Apache软件基金会资助的一个开放源代码框架,是一个免费的开源的WEB层的应用框架。
Struts有一组相互协作的类(组件)、Serlvet以及jsptaglib组成。
基于struts构架的web应用程序基本上符合Model2的设计标准,可以说是MVC设计模式的一种变化类型。
Struts是一个webframwork,而不仅仅是一些标记库的组合。
但Struts也包含了丰富的标记库和独立于该框架工作的实用程序类。
Struts有其自己的控制器(Controller),同时整合了其他的一些技术去实现模型层(Model)和视图层(View)。
在模型层,Struts可以很容易的与数据访问技术相结合,包括EJB,JDBC和ObjectRelationBridge。
在视图层,Struts能够与JSP,VelocityTemplates,XSL等等这些表示层组件想结合。
图2-3Struts架构
2.4本章小结
本章主要介绍了J2EE的基本概念,其常见模式MVC(Model-View-Controller)的体系结构,以及目前较为流行的基于J2EE的应用程序开发框架Struts的基本组成。
下一章将提出凭证管理及报表分析系统的总体设计方案。
第3章系统总体架构设计
系统总体设计是指根据项目的需求,结合项目背景,提出系统的开发方案,并做出系统的总体开发结构的设计。
3.1总体功能框架
如下图所示:
图3-1功能模块图
3.2应用系统的数据流向
数据的流向图如下:
图3-2数据流向图
(1)浏览器的请求通过HTTP协议进入Struts的Web层架构,由ActionServlet来处理客户端的HTTP请求。
当ActionServlet接收到客户请求后,会根据配置文件中的映射关系,将客户请求转交给合适的处理器进行处理。
(2)处理器直接调用不同的业务逻辑处理这些请求;或分发这些请求到其他的处理器进行二次处理甚至三次处理,形成处理链。
(3)业务逻辑处理层根据不同的请求参数对象和数据做相应的处理,然后通过DAO(DataAccessObject)返回数据对象(VO)给业务层。
(4)数据对象通过ResponseEvent,传回给客户端。
3.3部分组件的的设计
3.3.1数据事件对象(Event)
数据事件对象又包括请求事件对象(RequestEvent),返回事件对象(ResponseEvent)。
通过事件来实现服务器与客户端之间数据的传送。
实现方式:
(1)RequestEvent实现了java.IO.Serializable接口,用来封装向EJB核心层传递的消息。
RequestEvent是一个抽象类,在使用的时候必须要实现此抽象类。
他的实现类将一系列将要传送给EJB核心层的属性封装,并为这些属性设置getter和setter方法。
这些属性封装的是ValueObject对象类型。
比如说,对于web客户端,我们将把在JSP页面生成的ActionForm(javabean)对象作为RequestEvent对象的一个属性,并为它生成getter和setter方法。
RequestEvent对象会在客户端被生成,并作为参数传递给处理器,最终被对应的业务逻辑处理,并在处理之后被清除。
(2)ResponseEvent同样也实现了java.IO.Serializable接口,用来封装从EJB核心层传递到各种不同的客户端的数据。
类似于RequestEvent,ResponseEvent中要封装一些ValueObject(javabean),这些ValueObject是根据不同的业务流程所产生的。
ValueObject的封装形式要根据不同的业务流程去具体判断,这里不做详细的描述。
此外,如果在ResponseEvent对象中要封装相同的ValueObject类的多个对象时,要使用ArrayList对象来把这多个ValueObject对象封装起来。
ResponseEvent的生存周期与RequestEvent正好相反,也就是说,哪里生成的RequestEvent,那里就清除相应的ResponseEvent;哪里清除RequestEvent,那么就对应的生成ResponseEvent。
3.3.2数据访问对象(DataAccessObject)
数据访问对象(DAO)封装了对数据源的访问和操作,以保证业务逻辑对数据源的透明访问。
业务逻辑都通过DAO来实现对数据库的访问所以业务逻辑只看到业务逻辑的操作方法,看不到后台的数据库的具体实现,这就实现了业务逻辑与数据逻辑的分离。
实现方式:
每个BusinessObject对应一个(Table),但是能够操作多个数据库表。
每个数据库表对应一个DAO。
简化业务逻辑与数据访问的层次,不设置单独的BusinessObject层,将BusinessObject和DAO合成一层。
也就是说,对于对应多个数据库表的BusinessObject,直接在主要的DAO中包含将对其他辅表的DAO的访问,这种BusinessObject和DAO在一个Class中实现的对象称为BPO。
BusinessObject中只应该包含数据层的逻辑,不能包含业务流程层的逻辑。
DAO类中不仅能处理对单个对象(Row/Record),而且能够处理多个对象(RowSet/RecordSet),这也是符合OO的概念的体现。
3.4本章小结
本章描述了系统的总体设计,包括系统的功能框架、数据在系统中的流向和部分组件的设计。
下一章将阐述系统部分模块的详细设计。
第4章部分模块的设计与实现
凭证管理和报表分析是本系统的核心模块,本章将对这两个模块的设计和实现进行详细介绍。
4.1登陆界面
基于银行内部管理的需要,凭证管理及报表分析系统不支持用户的注册,而是采用用户及其权限预分配的使用方法,因此在登陆界面上不出现注册功能。
系统登陆界面如图4-1:
图4-1登陆界面
4.2凭证管理模块的设计与实现
4.2.1凭证管理顺序图
用户在进入凭证管理界面后可以进行以下操作:
(1)输入0个或多个条件,进行明细记录的查询。
(2)若查询结果不为空,选择一条记录进行修改。
(3)若查询结果不为空,选择一条记录预览对应的电子凭证。
(4)重新进行查询。
如图4-2:
图4-2凭证管理顺序图
4.2.2界面实现
4.2.2.1记录查询页面
用户根据提示,输入0个或任意多个查询条件,输入0个条件视为无条件限制,并且支持商户名字段的中文模糊查询。
如图4-3:
图4-3记录查询页面
4.2.2.2结果输出页面
对查询所得结果进行分页显示。
每条记录所显示的字段为:
该记录在查询结果中的编号、日期、付款人帐号、付款人名称、付款人开户行、收款人帐号、收款人名称、收款人开户行、金额和用途,其中金额字段由数据库表中的净金额字段与交易金额字段相减得出。
对需要打印电子凭证的记录,可利用复选框,进行一次性打印。
如图4-4:
图4-4结果输出页面
4.2.2.3记录修改页面
对查询所得的某条记录,点击其后面的“修改”按钮,进入记录修改页面。
由于记录内容的特殊性,只有规定的字段可以作出修改。
为了避免对信息的非法修改,修改页面做出了相应的设置,使修改仅限于允许的范围。
若修改成功,返回修改前的查询结果输出页面,并更新被修改的记录。
如图4-5:
图4-5记录修改页面
4.2.2.4凭证预览页面
对查询所得的某条记录,点击其后面的“预览”按钮,弹出该条记录对应的电子凭证的预览页面。
凭证的具体名称为“特种转帐贷方凭证”,其规格遵循《中华人民共和国票据法》。
该电子凭证可直接打印。
如图4-6:
图4-6凭证预览页面
4.3报表分析模块的设计与实现
4.3.1相关名词的说明
4.3.1.1利润
由于需求的特殊性,本系统的操作对象为银行特种转帐明细记录,每笔转帐所得利润即该笔转帐收取的手续费,手续费按以下方式收取:
(1)计算应付金额
应付金额=净金额-交易金额(4-1)
(2)应付金额为正时不收取手续费
(3)应付金额为负时收取手续费,具体数额按以下公式计算:
a.付款人开户行为异地他行(XXX行):
手续费(50元封顶)=基本费3元/笔(至少收3元)+应付金额×1%(4-2)
b.付款人开户行为异地我行(XX建行):
手续费(50元封顶)=基本费1元/笔(至少付1元)+应付金额×0.5%(4-3)
c.付款人开户行为本地我行(厦门建行):
手续费=基本费1元/笔(只收1元)(4-4)
d.付款人开户行为本地他行(厦门X行):
手续费(50元封顶)=基本费2元/笔(至少收2元)+应付金额×0.5%(4-5)
4.3.1.2利润贡献度
利润贡献度是一个短期的、某一时点上的和基于历史分析的概念。
对本系统而言,利润贡献度就是某客户或客户组群或某一时间段,在某一期间为企业带来的利润。
利润贡献度分析的主要目标是帮助银行了解其利润贡献度构成因子的分布状况,使行领导能够从不同角度进行绩效评估,制定相应的经营策略,进一步完善分行及业务部门的自身分析和流程规划。
4.3.1.3维度
在数据仓库的概念中,维度(Dimension)是用来反映业务的一类属性,这类属性的集合构成一个维度,如时间、地理位置或产品。
而在数据挖掘与OLAP的概念中,其目标是满足决策支持或者满足在多维环境下特定的查询和报表需求,它的技术核心就是"维"这个概念。
“维”一般包含着层次关系,通过把一个实体的多项重要的属性定义为多个维,使用户能对不同维上的数据进行比较。
在本系统中,统计分析在客户和时间这两个维度上进行,客户维度有(所有客户)-(单个客户)这两个层次;时间维度有(年度)-(季度)-(月份)这三个层次。
4.3.2操作流程图
图4-7报表定制流程图
4.3.2界面实现
4.3.2.1维度选择
进行报表定制的第一步,是选择统计的维度。
本系统有客户和时间这两个维度供选择,可选择时间维度,或客户维度,或同时选择时间和客户维度。
如图4-8:
图4-8维度选择
4.3.2.2度量选择
进行报表定制的第二步,是选择统计的度量。
根据第一步所选的维度,可选择不同的度量。
包括对维度层次的选择,和对利润贡献度计算的参照基准的选择。
参照基准即利润贡献度的时间跨度。
维度选择客户时,度量选择界面如图4-9。
维度选择时间和客户时,度量选择界面如图4-10。
图4-9度量选择1
图4-10度量选择2
4.3.2.3报表展示
根据前面用户输入的定制条件,统计利润额及利润贡献度,生成报表。
用户可根据需要,查看对应的柱状图报表或饼状图报表,或对报表进行打印。
以统计维度为时间为例,生成报表如图4-11:
以统计维度为客户为例,生成报表如图4-12:
图4-11报表1
图4-12报表2
4.3.2.4柱状图报表
图形报表是对传统报表的一个现代化的表现形式,为客户提供了更为直观的统计信息。
对生成的报表,可查看其对应的柱状图报表。
以统计维度为时间为例,生成报表如图4-13:
以统计维度为客户为例,生成报表如图4-14:
图4-13柱状图1
图4-14柱状图2
4.3.2.4饼状图报表
同样,对生成的传统形式报表,可查看其对应的饼状图报表。
以统计维度为时间为例,生成报表如图4-15:
图4-15饼状图
4.4本章小结
本章以凭证管理模块和报表分析模块为例,介绍了本系统的具体实现。
主要内容包括凭证管理模块的实现顺序、界面实现,和报表分析模块的操作流程、界面实现等。
下一章将剖析开发过程中部分技术难点的实现。
第5章部分技术难点的实现
在前面的章节中,系统的设计工作已经得到详细的说明,本章将对体现本系统技术特点的部分技术难点进行分析。
5.1Struts中分页显示的实现
目前比较广泛使用的分页方式是将查询结果缓存在HttpSession或有状态bean中,翻页的时候从缓存中取出一页数据显示。
这种方法有两个主要的缺点:
一是用户可能看到的是过期数据;二是如果数据量非常大时第一次查询遍历结果集会耗费很长时间,并且缓存的数据也会占用大量内存,效率明显下降。
比较好的分页做法应该是每次翻页的时候只从数据库里检索页面大小的块区的数据。
这样虽然每次翻页都需要查询数据库,但查询出的记录数很少,网络传输数据量不大,比在应用服务器层做缓存更为有效。
本系统采用后者实现分页。
5.1.1searchResult.jsp
……
//跳到第一页
linkparamId="curren_page"paramName="first_page"page="/paginationBean.do"> [第一页]
link>
//翻到上一页
presentname="previous"> linkparamId="curren_page"paramName="previous"page="/paginationBean.do"> [上一页] link>
present>
//翻到下一页
presentname="next"> linkparamId="curren_page"paramName="next"page="/paginationBean.do"> [下一页] link>
present>
//跳到最后一页
linkparamId="curren_page"paramName="last_page"page="/paginationBean.do"> [最后一页]
link>
……
5.1.2PaginationBean.java
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 凭证 管理 报表 分析 系统