关于银行贷款类的计算机毕业论文资料.doc

云南大学软件工程硕士学位论文 基于J2EE的商业银行贷款管理信息系统的设计与实现关于银行贷款类的计算机毕业论文目 录摘要3目 录5第一章 引言71.1 论文研究的背景和意义71.2 国内外研究现状81.3 研究内容与论文结构9第二章 相关基础理论和技术112.1 J2EE概述112.2 MVC开发模式132.3 Struts162.4 本章小结18第三章 系统需求分析193.1 可行性分析193.1.1技术可行性193.1.2经济可行性203.2 系统功能需求203.2.1 客户信息管理功能需求203.2.2 客户审批授信管理功能需求203.2.3 贷款发放管理功能需求213.2.4 贷款风险管理功能需求213.2.5 贷后管理功能需求213.3 业务流程分析223.4 用例建模233.5 用户概况283.6 系统性能需求293.6.1 系统软件属性需求293.6.2 系统外部接口需求303.7 本章小结31第四章 系统设计324.1 系统总体设计324.1.1系统设计原则32 4.1.2系统总体架构图33 4.1.3系统总体功能设计344.2 系统主要功能模块设计364.2.1 客户信息管理364.2.2 客户审批授信管理374.2.3 贷款发放管理384.2.4 贷款风险管理子模块设计394.2.5 贷后管理子模块设计404.3 数据库设计424.3.1数据库设计规范424.3.2 数据库逻辑结构设计434.3.3数据库物理结构设计444.4 本章小结53第五章 系统主要模块实现545.1系统运行平台及工具545.2 客户信息管理模块实现545.3 客户审批授信管理模块实现605.4 贷款发放管理模块实现635.5 贷后管理模块实现655.6 系统管理模块实现68第六章 总结与展望716.1总结716.2 展望72参考文献73致谢75第一章 引言1.1 论文研究的背景和意义 随着我国资本市场的发展和自身经济体制改革的进步，银行业的竞争变得日趋激烈，因此通过引入新的技术和管理制度手段加强科学管理，提升自身竞争力，实现稳定健康的可持续发展已成为中国银行业必须面对的问题，银行业的现代化主要体现在信息化技术在银行日常经营活动中的运用。 利用计算机为主的信息化技术已经渐渐为各种行业所使用，而要求准确而迅速地处理大量客户资料和户口资料的我国的银行业更是早在20世纪50年代后期便开始了信息化的建设。经过20多年的建设和发展，国内商业银行对信息化的认识已经上升到战略高度，信息技术不再仅仅被看作是模拟传统手工处理、支持业务运作的辅助工具，而是创造核心竞争力、实现业务变革的助推器。从现实技术环境看，数据大集中完成后，我国银行信息化的基础设施建设框架已经基本构成，各大商业银行基本完成物理和逻辑的数据集中工作，信息系统得到再造。建立统一的业务应用平台，实现经营模式由“以账务为中心”向“以客户为中心”转变的条件已经成熟1。信息技术被称为推动现代经济增长的发动机和现代社会发展的均衡器，推动着全球产业分工的深化和经济结构的调整，改变着世界市场和世界经济竞争格局。在金融领域，信息技术的发展和应用所推动的信息化建设，给商业银行的发展带来了深刻的影响2。 整体上看，我国银行业信息化处于比较高的水平，与国内其他行业相比，银行业对信息技术的利用程度最深。但是，在科技手段保障、促进金融服务和管理科学化的深度和广度方面，我们还存在很大差距。还存在着信息化建设欠缺统一的战略部署、信息化建设的重心定位不够准确，信息技术投资结构不尽合理、对信息化建设的长期性及业务与系统关系的认识存在偏差、信息化建设中安全风险日益突出、银行间系统系统的集成化程度不高，跨行业、跨部门网络尚未形成、信息技术的管理和运行机制不健全等问题仍旧普遍存在。 在过去，困于信息化水平的条件，我国绝大部分银行都是使用半手工半信息化的方式处理贷款审批和发放的工作，这种方式存在效率低、误差率高，潜在风险大等问题，容易给银行造成损失，因此这种传统的信贷管理方式已经远远不能满足银行贷款业务发展的需要。 本文就是在此背景下在研究分析商业银行贷款业务现实发展的基础上，研究通过采用J2EE技术架构构建商业银行贷款管理系统，实现信贷管理的信息化、规范化的要求。1.2 国内外研究现状 从上世纪八十年代起至今，信息化系统在商业银行发展经历了一个从无到有的过程，发达国家从20世纪60年代开始将计算机技术应用于金融业，它先后经过脱机业务处理、联机业务处理、经营决策信息化、业务集成和决策智能化四个发展阶段。20世纪末，西方发达国家的银行逐渐步入金融信息化发展阶段。西方发达国家金融信息技术的应用经历了从初始的支持金融业务到运作金融业务、再到改造金融业务的过程，信息技术已成为金融业发展和创新的重要因素3。 在西方发达国家，银行信息化建设较好，对信息化系统的建设和发展技术走在世界前列，随着国际经济一体化和银行金融业国际化而带来的激烈的国际竞争，各国银行业纷纷发展和推行实行电子商务和网络银行4，美国在上世纪90年代开始发展互联网银行，到如今全球已经有多家银行已推出或着手准备提供网络银行的服务内容。银行在互联网上提供的服务可以分为静态信息、动态信息、帐户信息和在线交易四个阶段。目前全球1000多家银行几乎全部连入了互联网，在网上建立了自己的网站，制作了网页，其中约有100多家可提供在线银行金融业务和服务，提供动态网页和动态信息的网络银行正在迅速增多。 中国银行信息化的发展程度还处在较低的水平，随着经济的发展和其他产业信息化的提高，经济领域中各个方面均对银行信息化不断提出新要求，我国当前大力推进信息化建设，国有商业银行和各城市银行纷纷建立自己的网上银行系统和业务管理支持系统，信贷业务作为商业银行一个最重要的经营业务以基本实现了信息化、电子化管理，截止2010年第三季度我国网上银行用户数已超过1.6亿，但与此同时由于我国银行信息化建设发展较晚，技术和管理与西方发达国家相比还有一定差距，因此当前我国银行需要不断加强信息化建设水平，从C/S结构下的MIS管理系统过渡到异构性较好的B/S结构，加强应用系统的安全研究和开发。1.3 研究内容与论文结构 商业银行贷款管理系统，简称贷款管理系统,是一个由贷款管理工作人员和计算机组成的用以对信息进行收集、传输、加工、存储、维护和使用的系统。本文针对银行信贷业务的主要特点，设计了基于 J2EE 体系结构的商业银行贷款管理系统，系统在Struts框架实现MVC的设计模式，将以往使用C/S架构向B/S 架构进行转变，以追求贷款管理系统高效、安全、快捷、稳定的目标。系统采用 Struts 框架技术实现 MVC的设计模式,表现逻辑层与业务逻辑层相分离。在系统设计时综合考虑商业银行的贷款业务需求，结合当前现有的技术水平条件，采用J2EE +Struts +SQL Server2000技术来实现。该系统为信贷人员提供了操作和管理平台，提高了贷款处理效率，控制了贷款风险，且具有很好的移植性和扩展性，因此具有较高的实用价值。 根据前期的准备和后期工作的总结，为了更加有效快速的使该系统与商业银行信贷管理的业务特点结合，以及根据软件工程的设计流程，对于本文的章节安排如下。第一章主要介绍商业银行贷款管理系统的研究背景和国内外研究现状，研究背景和意义强调在当前系统信息化建设的环境下，本课题研究的重要性。第二章主要介绍系统开发中采用的相关技术和系统体系结构，相关技术主要介绍了J2EE体系平台、Struts框架、B/S模式架构等技术。第三章主要分析了商业银行贷款管理系统的业务需求和业务流程，对管理系统的设计原则、数据流图、功能性需求和非功能性需求等内容做了相应的介绍。 第四章描述了商业银行贷款管理系统总体分析与设计。主要包括该系统软件体系结构设计、总体设计层次图、功能模块的设计、数据库的设计等。第五章详细说明了商业银行贷款管理系统各主要功能模块设计，包括客户信息管理模块、银行授信额度模块、放款审批模块，涉及到的各个功能模块的实现结果,进行详细的阐述。第六章 总结与展望：对本文工作进行了全面总结，说明了本文取得的成果，并指出了存在不足和需改进的方向。第二章 相关基础理论和技术贷款管理信息系统采用结构化的分析方法，基于J2EE平台的MVC的分层体系结构，大量运用当前主流的开发技术的如Struts，AJAX，JSP，Struts等，是一套技术含量较为先进的贷款管理信息系统。下面详细讨论系统实现需要的几个关键技术:J2EE、Struts框架和MVC模式。2.1 J2EE概述J2EE是一套全然不同于传统应用开发的技术架构，J2EE核心是一组技术规范与指南5，其中所包含的各类组件、服务架构及技术层次，均有共通的标准及规格，这能够使企业开发者大幅缩短投放市场时间，降低企业开发成本适合作为多层分布式企业应用程序的开发平台。J2EE为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制:第一企业可以保留现存的运行设备和机制，由于新的商业需求不断产生，利用已有的企业信息系统的设备和方案，而不是随时根据新的需求变更整体设计方案，一个以渐进、微调的方式建立在已有系统、设备、方案之上的服务器端平台是简单、快捷、高效的。而基于J2EE平台的特性，在J2EE平台上开发的产品几乎可以在任何操作系统和硬件配置上运行，现有的操作系统和硬件也能继续使用；第二高效的开发效率，J2EE允许系统将一些通用的、繁琐的服务端请求响应交给中间件供应商完成，这样系统开发人员可以集中精力在如何创建商业逻辑上，有效地地缩短了开发的进程，复杂的中间件服务交由高级中间件供应商提供；第三支持异构环境，J2EE作为一种高效、跨平台的开发技术，能够将软件部署在异构环境中，程序具有很强的可移植性，其开发的应用程序不依赖任何特定的操作系统、中间件、硬件，因此设计合理的基于J2EE的程序可以在开发后一次性部署到各种操作系统平台上，构建一个异构企业计算环境对企业来说是十分关键的6。J2EE标准也允许客户订购与J2EE兼容的第三方的现成的组件，把他们部署到异构环境中，节省了由自己制订整个方案所需的费用；第四优秀的可伸缩性，企业选择的服务器端平台必须能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户，而基于J2EE平台的应用程序可可以被大量广泛的被部署到各种操作系统平台上，J2EE领域的供应商提供了更为广泛的负载平衡策略，能消除系统中的瓶颈，允许多台服务器集成部署，这种部署可达数千个处理器，实现可高度伸缩的系统，满足未来商业应用的需要。第五稳定的可用性：一个服务器端平台必须能全天候24小时无高效故障的运转以满足公司客户、合作伙伴的需要，因为应用服务请求和响应是没有时间和地域限制的，即使在夜间按计划停机也可能造成严重损失，意外的停机也会有灾难性的后果，J2EE部署到可靠的操作环境中，他们支持长期的可用性7。J2EE使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组件根据他们所在的层分布在不同的机器上。事实上，sun设计J2EE的初衷正是为了解决两层模式(client/server)的弊端，在传统模式中，客户端担当了过多的角色而显得臃肿，在这种模式中，第一次部署的时候比较容易，但难于升级或改进，可伸展性也不理想，而且经常基于某种专有的协议，通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。现在J2EE 的多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层，以下是 J2EE 典型的四层结构:第一运行在客户端机器上的客户层组件，第二运行在J2EE服务器上的Web层组件，第三运行在J2EE服务器上的业务逻辑层组件和第四运行在EIS服务器上的企业信息系统(Enterprise information system)层软件，客户层组件，J2EE应用程序可以是基于web方式的,也可以是基于传统方式的；web层组件J2EE web层组件可以是JSP 页面或Servlets.按照J2EE规范，静态的HTML页面和Applets不算是web层组件，web层可能包含某些 JavaBean 对象来处理用户输入，并把输入发送给运行在业务层上的enterprise bean 来进行处理；业务层组件，业务层代码的逻辑用来满足银行，零售，金融等特殊商务领域的需要,由运行在业务层上的enterprise bean 进行处理，通常是由enterprise bean从客户端程序接收数据，进行处理并发送到EIS 层储存的，这个过程也可以逆向进行8。有三种企业级的bean: 会话(session) beans、实体(entity) beans和消息驱动(message-driven) beans，会话bean 表示与客户端程序的临时交互. 当客户端程序执行完后, 会话bean和相关数据就会消失。相反, 实体bean 表示数据库的表中一行永久的记录，当客户端程序中止或服务器关闭时, 就会有潜在的服务保证实体bean 的数据得以保存.消息驱动 bean 结合了会话bean 和 JMS的消息监听器的特性, 允许一个业务层组件异步接收JMS 消息；企业信息系统层，企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资源计划(ERP)、大型机事务处理、数据库系统和其它的遗留信息系统，例如J2EE 应用组件可能为了数据库连接需要访问企业信息系统等9。2.2 MVC开发模式MVC英文即（Model.View.Controller），即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三层模型层、视图层、控制层。MVC三层结构采用“分而治之”的思想，把问题划分开来各个解决，易于控制，易于延展，易于分配资源10。 MVC设计模式作为一个很好创建软件的途径，它所提倡的一些原则，像内容和显示互相分离可能比较好理解。但是如果你要隔离模型、视图和控制器的构件，你可能需要重新思考你的应用程序，尤其是应用程序的构架方面。如果你肯接受MVC，并且有能力应付它所带来的额外的工作和复杂性，MVC将会使你的软件在健壮性，代码重用和结构方面上一个新的台阶11。MVC模式是软件设计中的典型系统架构设计模式，依据MVC的设计思想可以将一个复杂的应用系统分解为模型、视图和控制器3部分，分别对应于应用系统中的业务逻辑处理和业务数据、用户操作界面、用户请求的处理和数据访问的控制、管理和调度操作。MVC模式是用来帮助软件系统的开发者控制“变化”（应用系统中的功能、环境、性能等方面经常是会发生改变的，应该要做到在系统发生最大的变化时，系统开发者所要做的改动最小。）的一种设计模式。MVC的设计理念认为：在一个具体的应用系统中，用户界面发生变动的可能性是最大的，而控制部分的变动次之，当然业务逻辑功能的实现一般是最稳定的12。模型、视图、控制器三者之间的关系和各自的主要功能，如图2.1所示。图2.1 MVC模式1、 视图(View) 视图层能够实现数据有目的的显示（理论上，这不是必需的）。在视图中一般没有程序上的逻辑。为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册,就Web应用而言，既可以是HTML界面，也可能是XML、XHTML或Applet界面，随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型13。视图主要由JSP建立，struts包含扩展自定义标签库（TagLib），可以简化创建完全国际化用户界面的过程。目前的标签库包括：Bean Tags、HTML tags、Logic Tags、Nested Tags 以及Template Tags等。视图层能够实现数据有目的的显示（理论上，这不是必需的）。在视图中一般没有程序上的逻辑。为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册。2、模型(Model)业务流程与状态的处理以及业务规则的制定。业务流程的处理过程对其它层来讲是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。“数据模型”（Model）用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“模型”有对数据直接访问的权力，例如对数据库的访问。“模型”不依赖“视图”和“控制器”，也就是说，模型不关心它会被如何显示或是如何被操作14。但是模型中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此模型的视图必须事先在此模型上注册，从而视图可以了解在数据模型上发生的改变。在Struts的体系结构中，模型分为两个部分：系统的内部状态和可以改变状态的操作（事务逻辑）。内部状态通常由一组Actinform Bean表示。根据设计或应用程序复杂度的不同，这些Bean可以是自包含的并具有持续的状态，或只在需要时才获得数据（从某个数据库）。大型应用程序通常在方法内部封装事务逻辑（操作），这些方法可以被拥有状态信息的bean调用15。3、控制器(Controller)控制(Controller)即从用户接受请求， 将视图与模型进行匹配，共同完成用户的请求。控制层并不执行任何的数据处理。控制层的划分其作用相当于一个分发器，选择相应的视图与模型，才能完成相对应的用户请求。在struts中，基本的控制器组件是ActionServlet类中的实例servelt，实际使用的servlet在配置文件中由一组映射（由ActionMapping类进行描述）进行定义。对于业务逻辑的操作则主要由Action、ActionMapping、ActionForward这几个组件协调完成的，其中Action扮演了真正的业务逻辑的实现者，ActionMapping与ActionForward则指定了不同业务逻辑或流程的运行方向。struts-config.xml 文件配置控制器16。 系统执行过程中，若用户单击一个连接，控制层在收到请求之后，并不对业务信息进行任何处理，只负责将用户信息传送给模型，通知模型选取对应的的视图返回给用户。因而，视图与模型可能存在一对多和多对一两种。2.3 StrutsStruts是MVC模式的一种实现。Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件17，这是它的一大优点，使开发者能更深入的了解其内部实现机制。Struts工作原理如图2.2 所示。图2.2 Struts工作原理图Struts工作原理：先将视图层JSP文件中的请求提交到Struts的处理标记文件*.do，*.action中，Struts框架根据其提交的标记名寻找struts.config.xml文件，找到名字相同的文件再跳转到相对应的Action文件中，在Action文件完成业务逻辑处理再跳转到JSP文件中来18。Struts有其自己的控制器（Controller），同时整合了其他的一些技术去实现模型层（Model）和视图层（View）。在模型层，Struts可以很容易的与数据访问技术相结合，如 JDBC / EJB ，以及其它第三方类库，如 Hibernate / iBATIS ，或者 Object Relational Bridge(对象关系桥)。在视图层，Struts能够与JSP，包括 JSTL 与 JSF，以及 Velocity 模板，XSLT 与其它表示层技术,Struts框架先将视图层JSP文件中的请求提交到Struts的处理标记文件*.do，*.action中，Struts框架根据其提交的标记名寻找struts.config.xml文件，找到名字相同的文件再跳转到相对应的Action文件中，在Action文件完成业务逻辑处理再跳转到视图层的JSP文件中来19-20。在struts框架中，模型分为两个部分：一是系统的内部状态，二是可以改变状态的操作（事务逻辑）。内部状态通常由一组ActinForm JavaBean表示。根据设计或应用程序复杂度的不同，这些Bean可以是自包含的并具有持续的状态，或只在需要时才获得数据（从某个数据库）。大型应用程序通常在方法内部封装事务逻辑（操作），这些方法可以被拥有状态信息的bean调用。比如贷款信息bean，它拥有用户贷款的详细信息，可能还有checkOut()方法用来检查用户的账户信息，并向下一级发评审信息。 小型程序中，操作可能会被内嵌在Action类，它是struts框架中控制器角色的一部分。当逻辑简单时这个方法很适合。建议用户将事务逻辑（要做什么）与Action类所扮演的角色（决定做什么）分开。 Struts框架中的视图由JSP建立，struts包含扩展自定义标签库，可以简化创建完全国际化用户界面的过程21。Struts框架中的控制器，其基本的控制器组件是ActionServlet类中的实例servlet，实际使用的servlet在配置文件中由一组映射（由ActionMapping类进行描述）进行定义22。Struts 框架是对Web MVC模式的具体实现，Struts框架作为一个可重用的 MVC 2 的设计实现，不仅将常规的Web MVC设计模式中所倡导的分离应用系统中“显示逻辑和业务逻辑”的设计思想加以具体地应用和实现，而且Struts框架中的MVC 2与JSP Model Two模式中的Web MVC也是有不同的技术实现主要表现在原有视图层（HTML/JSP页面）和控制层（Servlet组件）之间添加了一个前端控制器组件ActionServlet作为控制层中的一个前端控制器，系统中的所有有效的业务功能请求都要经过该前端控制器ActionServlet组件来分发和导航，此时的应用系统将通过该总控ActionServlet组件来管理所有的请求行为23，并由它来决定哪个具体的后端业务调度控制器Action组件被真正调用并处理表示层中的具体业务功能的请求；另外，在系统设计实现方面将标准的Servlet组件改成了Action组件以统一处理浏览器端所产生的Get和Post方式的请求；同时Action组件可以通过XML的配置文件来进行管理，这在一定程度上增加了应用系统的整体结构的灵活性和可扩展性。2.4 本章小结 本章详细介绍了与本系统相关的主要技术，分析了采用采用Struts框架结构的B/S设计模式的贷款管理系统的关键技术，通过采用B/S的设计模式的使系统能简化、规范应用系统的开发与部署，系统整体具有较好的可移植性、安全性与与再用价值，在开发过程中采用的MVC开发模式使模型层、视图层、控制层三层分离，将开发中的问题划分开来各个解决，易于控制、延展和分配资源24，在系统需求分析中采用UML进行系统分析，通过使用面向对象的方法来分析系统，建立了面向对象的系统模型，帮助开发人员了解系统功能与进行系统流程分析，快捷、全面、高效的获取了系统需求。第3章 系统需求分析 本章节主要介绍了系统的需求分析，从可行性分析开始介绍了用户概况、业务流程分析、用例建模、系统功能需求、系统软件属性需求、系统外部接口需求等内容，全面对系统功能、属性、业务流程进行分析。3.1 可行性分析 系统可行性分析分为技术可行性分析和经济可行性分析，从系统可用技术性和可行经济性两个角度进行了论述。3.1.1技术可行性本系统是基于J2EE的WEB应用系统，采用B/S模式。B/S模式的优势在于系统的开发、维护和升级方便，管理成本较低。系统用户界面一致，使用简单，能实现不同人员，不同地点，以不同的接入方式访问和操作；一般客户机只需安装有浏览器就可以进行操作。应用程序运行在服务器端，这样便于系统的管理、更新和升级，降低了服务端和客户端之间的依赖性，同时提高了应用程序安全性，有效地保证了系统平台和服务器数据库的安全25。整个贷款信息管理系统采用基于B/S体系结构和J2EE技术规范，采用先进的构建化技术和中间件技术，在技术架构上完全符合SOA要求，随着信息技术的不断发展和Internet互联网技术的日益普及，人们对计算机的使用越来越熟悉，特别是对基于B/S结构的程序容易掌握与使用，同时对于企业来说，由于企业的业务流程、业务模式不是一成不变的，随着企业不断发展，必然会不断调整。软件供应商提供的软件也不是完美无缺的，所以，对已经部署的软件产品进行维护、升级是正常的。C/S结构软件，由于其应用是分布的，需要对每一个使用节点进行程序安装，所以，即使非常小的程序缺陷都需要很长的重新部署时间，重新部署时，为了保证各程序版本的一致性，必须暂停一切业务进行更新（即“休克更新”）26，其服务响应时间基本不可忍受。而B/S结构的软件不同，其应用都集中于总部服务器上，各应用结点并没有任何程序，一个地方更新则全部应用程序更新，技术上可以做到快速服务响应。因此开发基于B/S的贷款管理信息系统在技术上是可行的。3.1.2经济可行性从开发项目的成本与效益来看，系统开发的人员费用、培训费用、设备费用、运行费用不大，估计100万左右，而通过系统的实施，减轻了信贷人员手工处理的工作负担、提高了工作效率、节约办公费用、规范了贷款发放审批流程、降低了银行信用风险，该系统可为银行管理人员提供决策信息，促进业务的规范化、系统化、条理化和程序化。3.2 系统功能需求根据商业银行贷款的业务需要，商业银行贷款管理系统将功能需求分为：客户信息管理、客户审批授信管理、贷款发放管理、贷款风险管理、贷后管理，下面就系统主要功能分别阐述它们的需求。3.2.1 客户信息管理功能需求由于贷款业务涉及银行和客户双方的经济利益，因此，对客户一般会录入比较多的信息，既包括个人信息、家庭成员信息、相关资产（如房屋、汽车等）信息、家庭经济状况等，有的系统会录入50多项数据。首次开户时必须录入详细的信息，当客户信息发生变化时，还必须及时增删相关信息，以确保客户信息的准确，因此应该提供如下功能：（1） 信贷员登录该贷款管理系统；（2） 信贷员录入客户相关基本信息；（3） 信贷员能够修改、删除、查询客户相关的信息；（4） 信贷员在贷款管理系统中提交客户信息调查报告；3.2.2 客户审批授信管理功能需求在客户审批授信管理中，主要是对客户申请的贷款项目进行处理，包括申请的处理、客户个人及财产情况调查、客户担保情况等，然后信贷审批专员根据相关文件和风险评估报告对贷款项目进行评估，根据评估的结果决定是否接受该贷款项目，以及放款的额度和时间等具体问题。（1） 信贷审批专员登陆该贷款管理系统；（2） 信贷审批专员具有确定贷款申请文件是否规范，否则退回信贷员重新调整的功能。（3）信贷审批专员具有查询客户的相关信息、风险评估报告；（4）信贷审批专员具有贷款项目进行审批的功能；（5）信贷审批专员具有确定贷款额度和放款时间的功能；3.2.3 贷款发放管理功能需求 在信贷业务管理过程中，放款的管理也很重要，规范合理的放款操作可以有效控制控制信贷风险，提高银行信贷资金的使用效益。贷款发放管理主要实现在信贷申请己经通过信贷审核专员审批通过后，对放款的过程进行监控和管理。包括了鉴定正式的贷款合同、确定担保信息、还款计划等。（1）信贷综合管理员具有开具放款报告的功能；（2）信贷综合管理员具有检查、核准正式贷款合同、确定担保信息、还款计划书的功能；（3）信贷综合管理员具有对放款过程中资金的流动进行初始监管的功能；3.2.4 贷款风险管理功能需求在贷款风险管理中，主要是对信贷业务过程中的财产风险、信用风险、操作风险等进行管理和控制，对新贷款业务和贷款变更业务进行风险评估分析，最大程度上降低贷款业务过程中出现的风险。（1）信贷风险评估员具有查阅客户基本资料和财务状况资料的功能；（2）信贷风险评估员具有分析经营风险的功能。（3） 信贷风险评估员具有开具新建贷款和变更贷款业务风险分析报告书的功能；3.2.5 贷后管理功能需求贷后管理是商业银行贷款中一项重要的管理职能，主要是对信贷资金发放后的资金相关走向、用途，贷款合同的变更，贷后检查，逾期催收登记等内容进行管理和控制，良好的贷后管理可以从最大程度上降低贷款业务中出现的风险。（1）信贷综合管理员具有查阅客户基本资料和财务状况资料的功能；（2）信贷综合管理员具有上传、审批，变更担保信息、贷款合同的功能。（3）信贷综合管理员具有核查抵质押物、担保物情况的功能；（4）信贷综合管理员具有核查贷款违约情况、还款情况的功能；（5）信贷综合管理员具有逾期催收定制、登记、下载、打印贷款催收通知书或债务提前到期通知书的功能；3.3 业务流程分析 在商业银行信贷业务审批发放的操作流程，主要是依据“初始客户信息数据录入一审核信贷相关资料一风险评估一提交最终结果一银行接受或拒绝”的步骤来进行，因此最终控制信贷风险可以严格控制管理使信贷管理的每一个流程规范化，在最大程度上降低信贷的风险，流程步骤如下：（1） 客户信息的建立与维护客户信息包括客户个人信息和客户财务信息情况，由信贷员录入贷款管理系统中，客户信息是贷款业务开展的依据，是商业银行对客户进行信贷业务的重要参考依据，信贷员在建立客户档案输入客户基本信息数据时系统自动对客户进行编号，同时自动检查客户所有数据是否符合要求，信贷员可以随时通过系统对客户信息进行管理。（2） 贷款业务数据更新 当出现新的贷款业务和需要变更贷款业务时，系统需要随时对新增贷款业务和变更业务进行同步更新，在更新的过程中系统自动保证各数据的一致性。（3）信贷风险评估员对风险进行评估对新建立或变更的贷款业务，信贷风险评估员对业务进行风险评估，评估根据客户的基本信息和财产、担保情况进行判断，得出并提交风险评估报告。（4）合同财务担保在信贷风险评估员完成风险评估之后，信贷员对客户的财产担保和贷款合同建立关联，保证贷款合同的安全、有效。（5）信贷综合管理人员进行最终审核信贷综合管理人员首先检查贷款相关文件数据是否正确和规范，对出现问题的文件进行退回调整操作，然后根据客户的相关信息文件和风险评估报告，对最终的贷款文件和合同进行确认，决定是否发放贷款或否决发款申请。根据上面的流程介绍，可以得到贷款管理系统业务流程图如下图3.1所示。 图3.1业务流程图3.4 用例建模 用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早是由Iva Jackboson博士提出的27，后来被综合到UML规范之中，成为一种标准化的需求表述体系，在需求分析中使用用例的方法来描述系统的功能需求的过程就是用例建模，通过用例来捕获用户需求。3.3.1识别参与者使用用例来建模分析系统，首先需要确定系统的参与者。参与者是代表与系统交互的人、硬件设备或另一系统，代表唯一的角色。参与者并不是软件系统的组成部分，它存在于系统的外部28。通过对贷款管理信息系统的需求分析，可以确定系统主要有5个参与者：信贷员、信贷风险评估专员、信贷审批专员、信贷综合管理员、系统管理员。3.3.2 用例识别用例是规定系统或部分系统的行为，它定义了系统是如何被参与者所使用的，描述了系统所执行的动作序列集，并为执行者产生一个可供观察的结果，通过对贷款管理信息系统的分析，可以确定系统功能用例。（1） 信贷员用例信贷员参与的用例包括：客户信息管理；信贷业务登记；客户信息调查报告，信贷员用例图如下图3.2所示。 图3.2 信贷员用例图（2）信贷风险评估员用例信贷风险评估员参与的用例包括：客户信息审查管理，风险评估（贷款分类、担保抵押品估值审查、客户信息审查），贷款风险评估报告，信贷风险评估员员用例图如图3.3所示。 图3.3 信贷风险评估员用例图（3）信贷审批专员用例信贷综合管理员参与的用例包括：贷款审核；报告审查；综合查询；信息统计；风险预警；贷款分派。信贷审批专员用例图如图3.4所示。 图3.4 信贷风险审批专员用例图（4）信贷综合管理员用例信贷综合管理员参与的用例包括：综合查询；客户管理；抵押、担保管理；报告查询管理；风险评估决策；固定统计；风险预警。信贷综合管理员用例图如图3.5所示。 图3.5 信贷综合管理员用例图（5）系统管理员用例信贷风险评估员参与的用例包括：系统权限设置；系统日志管理；数据备份恢复管理；机构人员管理；信息发布；柜员管理；客户信息维护管理。系统管理员用例图如图3.6所示。 图3.6 系统管理员用例图（6） 贷款管理信息系统用例关系图如下图3.7所示。 图3.7 贷管理系统用例关系图3.5 用户概况 商业银行贷款管理系统根据其业务流程和要求分为信贷管理部门和风险监控部门，信贷管理部门人员负责开展贷款业务，包括贷款合同的登记录入、贷款额度的管理、项目的审核、项目开展后的跟踪等，风险监控部门主要对贷款合同的建立与变更进行风险监控，并向上一级主管报送风险监控的情况。贷款管理的工作是涉及行长、风险管理处长、信贷审批专员、信贷员、信贷综合管理人员，人员组织结构如下图3.8所示： 图3.8 人员组织结构图在上面的银行贷款管理系统组织结构图中在本系统中涉及到的人员如下：（1） 信贷员:开展信贷具体业务，包括客户基本信息与关联信息管理，信贷合同登记与记录、客户个人资产与负债信息调查报告。（2） 信贷风险评估员：对信贷业务的风险进行审查管理，对信贷员提交的相关资料和调查报告进行风险评估，尤其是客户的担保及还款能力进行风险评估，对其的风险调查审批产生风险评估报告，并提交至银行信贷审批专员。（3）信贷审批专员：对信贷员和信贷风险评估员提交的客户基本信息报告和风险评估报告进行审核和确认，并将其提交给信贷综合管理人员。（4）信贷综合管理员:对所有的分析报告进行汇总统计分析，综合对本行的信贷业务进行管理，控制银行信贷风险，对信贷业务综合管理。（5）系统管理员:对贷款管理信息系统进行维护和管理，包括用户管理，权限管理，日志管理，差错管理，系统数据备份和恢复等。3.6 系统性能需求3.6.1 系统软件属性需求（1） 正确性：要求发布的软件达到用户的预期目标，运行时基本无错误，保证贷款系统在大容量数据环境下的无差错运行。（2） 可靠性：在一般条件下，应不出故障。（3） 效率：对于相关信息、报告的浏览，查询，增加，删除，更新和设置的一般操作，要求及时响应在12秒内。（4） 易实用性：要求能尽量为用户的使用提供方便，软件界面符合目前流行的界面规范。（5） 可维护性：要求本软件在运行中发现错误时，能快速，准确对其进行定位，诊断和修改。（6） 安全保密性：要求提供身份验证，只允许通过身份验证的用户使用本软件。对于三次密码输入不正确的，应强行关闭。软件除Windows NT提供的系统安全保障外，在网络的使用时还提供了系统管理员这个级别最高的控制者，由系统管理员进行用户身份权限的定义，使得数据信息得到了更好的安全保护。（7） 可理解性：对于本软件提供的各种菜单命令，各种信息提示，应易于用户理解，统的整体风格布局以实用、简洁、易用为原则，具有一致、友好的客户化界面，注重界面的整体效果，精心设计界面中诸如按钮位置、数据表现方式等细节，使操作者能够方便地操作和比较容易地理解界面所表达的信息和内容。（8） 可测试性：设计时尽可能减少测试本软件的各项功能所需要的工作量。（9） 复用性：设计时尽可能采取模块化的方法进行设计，对系统内各模块尽可能达到高内聚，低耦合的程度，以提高各模块的复用性。（10） 扩展性：设计时充分考虑系统二次开发和扩展，基于Struts的MVC架构可以保证系统的可扩展性。3.6.2 系统外部接口需求（1）用户界面采用windows的通用图形界面，对用户友好，且必须对鼠标和键盘提供支持，界面的设计应遵循如下规则29：l 界面要具有一致性，界面规范应遵循 Windows 软件界面的规范；l 提供简单明了的错误处理方式；l 提供多信息反馈，用多种信息提示用户当前系统的运行状态，软件界面各元件的功能；l 操作可逆，其动作可以是单个的操作，或者是一个相对独立的操作序列；l 设计良好的系统帮助；l 启动画面简洁明快，富有现代气息，界面舒适得体；l 应遵循国家关于计算机词汇的标准，用词应当精练准确，没有歧义，图形的意义明朗30。（2）硬件接口支持一般的PII或更高档微机，笔记本电脑。（3）软件接口运行于WINDOWS 95/98/ME/2000/NT，且具有WIN32 API的操作系统之上；（4）故障处理正常使用时不出错，若运行是遇到不可恢复的系统错误，也必须保证数据库的完好无损。3.7 本章小结本章主要讨论了系统的需求分析。需求分析是开发软件最重要的一环，任何一个软件本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息很大程度上决定了系统的面貌，对软件设计有深远的影响，因此需求分析对系统的开发有很重要的作用。本章主要从系统可行性分析、功能需求、系统性能需求几个方面详细讨论的系统的需求。在可行性分析中，分析了基于J2EE的WEB应用系统在技术上的优势和可行性。然后详细分析了系统的组成用户和相关用例的用例模型，对各个子功能模块进行了需求分析，分析了软件属性和外部接口需求等内容。第4章 系统设计 系统设计主要围绕系统总体设计、系统功能模块设计和数据库设计几个部分展开，详细分析了系统的设计原则和设计思路。4.1 系统总体设计 系统总体设计介绍了系统设计的原则和系统的总体功能设计，概括、简明的介绍了系统的总体功能能模块，首先介绍系统的设计原则。4.1.1系统设计原则本系统采用当今业界先进的开发技术，实现贷款的全过程管理及基于权限的安全管理，为用户提供一个银行贷款协同的业务平台，为银行管理人员提供一个管理、决策、分析的平台，实现节约运营成本的目标。贷款管理系统是一个规模庞大、结构复杂、信息量大的综合信息系统，因此，在开展本项目时，要认真进行系统设计，这样才能保证项目的顺利进行和规避不必要的项目风险。根据项目特点和业务要求，系统设计应遵循以下原则： 1. 安全性安全保密是贷款管理系统建设的关键，安全保密技术与信息技术应发展同步，也就是同步发展、同步规划。软件除了WindowsNT提供的系统安全保障外，在网络的使用时还提供了系统管理员这个级别最高的控制者，由系统管理员进行用户身份权限的定义，使得数据信息得到了更好的安全保护31。2. 成熟性作为一套庞大而复杂的应用系统开发项目，如何在项目开发过程中实施风险管理，避免出现项目失败是在项目分析阶段应该要关注的重要环节。而系统平台和开发技术的成熟，一般会直接影响到项目开放的成功与否，过去很多的实践证明，过分强调采用先进的平台和开发技术，往往会降低系统的稳定性。本系统在开发过程中进行了多次的调整，在系统稳定性、运行效率和可维护性上得到用户的认可。3.实用性为确保投资的有效性和系统的实用性，在开发本系统时将针对银行贷款业务的特点选用比较成熟而稳定的技术，针对贷款业务流程的特点采用合适的系统结构，使整个系统达到最高的性价比性能，并尽量简化用户的操作步骤，使系统容易被使用。另外，在开发过程中同时考虑到软件的培训成本和维护成本在整个系统成本中占有非常大的部分，因此决定使用B/S 模式来设计系统，降低用户的操作难度，减少培训成本，同时也为降低系统维护和升级的成本打下很好的基础。4.易用性考虑到本系统用户计算机水平参差不齐。因而，本系统的界面设计简洁而实用的。在系统设计时，系统的整体风格布局应以实用、简洁、易用为原则，具有一致、友好的客户化界面，注重界面的整体效果，精心设计界面中诸如按钮位置、数据表现方式等细节，使操作者能够方便地操作和比较容易地理解界面所表达的信息和内容，便于用户快速掌握系统的使用。管理人员力求以最少的人力资源和技术要求，就能够很好地维护和管理系统32。5.可扩展性基于B/S架构的系统具良好可扩展性，而系统可扩展性的程度，直接影响到系统的使用周期。本系统使用基于Struts的MVC架构来保证系统的可扩展性33。4.1.2系统总体架构图系统的开发采取规范的标准体系和安全保障管理体系，系统总体架构可分为5层，包括个性化配置层、业务构件层、工具支撑层、基础构建层、中间技术层、应用集成层。其中个性化配置层主要是完成配置信贷产品的配置和风险控制策略的配置功能，可对组织结构、授权、流程、评级模型等内容就行控制；业务构件层主要关注反映系统的业务构件，实现具体的业务功能，如客户管理、信用评级、贷后检查等内容；工具支撑层支撑服务业务构件层，其主要模块功能如财务分析、客户风险评级、信贷风险评级、贷款定价器等功能为业务构建层的运作提供支持，基础构件层提供基础构件，作为系统的一些基础功能设计，如工作台构件、认证授权构件等；中间技术层主要是反映系统采取的技术架构如MVC应用框架的Struts、J2EE应用服务器等；最后应用集成层OLTP数据库和OLAP数据集市实现与核心账务系统、国际业务系统、票据中心系统和征信上报系统的数据交换，如