银行储蓄系统报告.docx

银行储蓄系统报告.docx

《银行储蓄系统报告.docx》由会员分享，可在线阅读，更多相关《银行储蓄系统报告.docx（15页珍藏版）》请在冰豆网上搜索。

银行储蓄系统报告

一、课程设计的目的和要求

1．1设计目标

运用数据库设计理论设计一个较完善有意义的数据库。

掌握目前流行的数据库管理系统MicrosoftSqlServer2000的使用与应用开发技术。

为数据库开发相应的应用程序，构成完整的数据库应用系统。

将设计在数据库管理系统上Oracle等一个或组合实现，开发工具可以选用VB、VC、java、html或其他程序设计语言。

1.2基本要求

采用面向对象的方法开发，按照软件工程课程中讲的有关数据库及其应用系统设计章节的内容，进行分析和设计，并按照面向对象的设计流程给出相应的分析设计文档。

分析文档中应涉及到以下几个基本方面：

需求分析与表达（oo分析，需求建模）、oo模型与关系模型的转换（映射方案、数据库结构、建库的sql语句）、完整性考虑（完整性约束、存储过程或触发器）、并发控制（数据并发问题，可加锁）、安全性考虑（数据库安全机制）、数据库备份与恢复、系统体系结构（c/s、b/s）、用户接口设计（操作界面设计）、程序功能设计、关键源程序等等。

1.3课题选择

银行储蓄管理系统

二、银行储蓄可行性分析

2.1基本要求

2.1.1功能要求

此系统所要完成的主要功能有两方面：

储户填写存款单或取款单交给业务员键入系统，如果是存款，系统记录存款人姓名、住址、存款类型、存款日期、利率等信息，完成后由系统打印存款单给储户。

如果是取款，业务员把取款金额输入系统并要求储户输入密码以确认身份，核对密码正确无误后系统计算利息并印出利息清单给储户

2.1.2性能要求

为了满足储户的要求，系统必须要有高的运作速度，储户填写的表单输入到系统，系统必须能快速及时作出响应，迅速处理各项数据、信息，显示出所有必需信息并打印出各项清单，所以要求很高的信息量速度和大的主存容量；由于要存贮大量的数据和信息，也要有足够大的磁盘容量；另外，银行计算机储蓄系统必须有可靠的安全措施，以保证储户的存储安全。

2.1.3接口要求

业务员键入储户的资料要全部一直显示在屏幕上；储户键入密码到系统以核对；计算机与打印机有高速传输的连接接口，最后以纸张的形式打印出清单给储户。

2.1.4输入要求

业务员从存取款表单输入数据，要迅速精确，适当调整输入时间，不能让客户等太久，但也不能让业务员太过忙碌以免影响正确率，造成用户损失。

2.1.5输出要求

要求快速准确地打印出存款或取款清单给客户。

2.2开发目标

近期目标：

第一年内在一个银行建立一个银行内部计算机储蓄系统，初步实现银行储蓄系统计算机化，并保证该银行能够按期望顺利完成工作。

长期目标：

希望在三至四年内，在国内银行中建立该计算机储蓄系统，促进银行间的互联合作，实现银行储蓄系统的计算机管理体制，提高银行储蓄系统的整体水平；并实现银行储蓄系统的高效性、方便性、实用性、互联性，给储蓄用户带来方便和益处，从而提高银行的信用度，提高银行公司的经济效益和社会效益。

2.3限制条件

2.3.1开发时间（只限于近期目标）

预定为半年。

2.3.2运行环境

Windowsxp及以上操作系统、数据库：

MicrosoftSQLServer2000。

MicrosoftVisualBasic6.0中文版.

2.3.3使用寿命

该系统至少使用四年以上。

2.3.4进行可行性研究的方法

采用调查方法：

通过对银行业务员和客户的调查以获得第一手资料，确定客户和实际应用中的需求；然后经过座谈或开会的形式和专家以及银行经理交谈，落实最后的问题定义。

三、银行储蓄需求分析

3.1编写目的

本报告的目的是规范化本软件的编写，旨在于提高软件开发过程中的能见度，便于对软件开发过程中的控制与管理，同时提出了本银行储蓄系统的软件开发过程，便于程序员与客户之间的交流、协作，并作为工作成果的原始依据，同时也表明了本软件的共性，以期能够获得更大范围的应用       此文档进一步定制软件开发的细节问题，明确软件需求、安排项目规划与进度、组织软件开发与测试，便于用户与开发商协调工作。

本文档面向的读者主要是项目委托单位的管理人员、设计人员和开发人员，希望能使本软件开发工作更具体。

3.2背景

软件名称：

银行储蓄系统

委托单位：

银行

开发单位：

xxxxxxxxx

主管：

xxxxxx

3.3定义

·银行储蓄应用系统软件：

基本元素为构成银行储蓄及相关行为所必须的各种部分。

·媒体素材：

是指传播教学信息的基本材料单元，可分为五大类：

文本类素材、图形（图像）类素材、音频类素材、动画类素材、视频类素材。

·需求：

用户解决问题或达到目标所需的条件或功能；系统或系统部件要满足合同、标准，规范或其它正式规定文档所需具有的条件或权能。

·需求分析：

包括提炼，分析和仔细审查已收集到的需求，以确保所有的风险承担者都明其含义并找出其中的错误，遗憾或其它不足的地方。

·模块的独立性：

是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他的模块的接口是简单的.

·SQLServer2000：

Microsoft公司开发的一种功能强大的关系型数据库。

·MicrosoftVisualBasic6.0中文版：

Microsoft公司开司的一种功能强大的编程软件。

3.4功能需求

根据系统可行性分析及业务要求，及相关的功能、性能分析，可以对系统现有的需求进行需求建模，主要涉及到用例、用例图的建立，类图及联系的建立，以及数据结构的定义等。

3.5用例分析

根据银行储蓄管理系统的分析，可明确系统的功能需求主要涉及都以下的几个部分。

参与人员：

银行管理员、储户、系统用户

用例：

存款、取款、转账、查现、查看历史、修改密码（储户）；

开户、销户、挂失、解挂、修改密码（系统用户）；

增加用户、查看用户、删除用户、已批申请、待批申请（银行管理员）

根据相应的用例分析，可以为系统功能建模（用例图）：

简单用例流程分析：

1.用户注册系统后，即成为系统用户，系统用户可凭借用户名、密码、等级进入系统。

系统用户可实现开户、销户、挂失、解挂、修改系统密码等用例。

2.系统用户只有使用账户、账户密码二次登陆后，才可以实现存款、取款、转账、查询余额、查询历史、修改账户密码等用例。

3.银行管理人员登陆后，可以实现增加用户、删除用户、查看用户、查看已批申请、处理待办申请、修改系统密码等用例。

4.系统的参与者（系统用户、储户、银行管理员）在实现用例时，系统会自动根据其权限给予适当的实现用例。

3.6系统层次方框图

由用例分析可知，系统的参与者有三种：

系统用户、储户、银行管理员，由于角色不同，故参与者权限的分配也不同，根据功能描述的用例图可得到以下不同角色的层次方框图。

（1）银行管理员

（2）系统普通用户

（3）储户

由于储蓄用户也是系统普通用户，故储户也拥有和系统普通用户一样的所有权限，在上面的层次方框图中，仅列出了储蓄用户特有的权限。

3.7OO模型分析

根据银行储蓄管理系统的用例分析，银行的参与者主要有三种：

银行管理员、储户、系统用户，因为储户、银行管理员都实现了系统用户，故参与者用CommonUser角色实现；由于一个系统用户可拥有多个账号，每个账户可以对应一个系统用户，故账户用AccountUser角色实现；考虑到相关系统参与者的业务涉及范围，银行管理员可以操作账户申请以及账户的挂失、解挂等申请信息，故申请信息用MessageRegister实现申请信息记录；由于储户在相关业务操作的过程中，系统可为其记录相关的操作日志，用户实时可以查看历史记录，以了解储蓄详情和保障账户安全，故可以用MessageLogger来实现历史记录。

有上述分析可知，在银行储蓄管理系统中，主要涉及到四个数据模型的建立，分别用CommonUser、AccountUser、MessageRegister、MessageLogger四个实体类实现。

由于业务操作中，系统参与者之间的交互性，各个数据实体之间存在一定的相关性。

一个系统用户CommonUser，可以对应多个账户AccountUser，一个账户AccountUser只能对应一个系统用户CommonUser；一个账户AccountUser可以对应多条历史记录信息MessageLogger，一条历史记录信息MessageLogger只能对应一个账户AccountUser；一个账户还可以对应多条申请记录信息MessageRegister，但一条申请记录信息MessageRegister只能对应一个账户AccountUser。

3.8关系模型的分析

由以上数据模型的分析，以及相关类和类之间的映射关系的确立，可以将上述的OO模型按照对应的映射方案，映射成对应的关系模型，并按照映射出的关系模型设计合理的数据库文件结构。

关系模型的映射：

根据数据模型分析，由于AccountUser与Commonuser间是多对一映射，故：

AccountUser（account,apassword,address,phone,realname,deposit,state,cname）;

CommonUser（cname,cpassword,clevel）;

由于AccountUser与MessageLogger之间是一对多映射，故：

MessageLogger（dealid,dealtype,dealtime,dealmoney,dealaccount）;

由于AccountUser与MessageRegister之间是一对多映射，故：

MessageRegister（registerid,registertype,solvement,registertime,registeraccount）

3.9数据描述

根据关系模型，可以为本系统的建立数据库accont，其中有四张表，分别是系统用户表CommonUser、储户表AccountUser、储户操作日志表MessageLogger、储户申请信息表MessageRegister。

由上面的数据表的结构描述，给出了银行储蓄管理系统的数据库的具体的见表的sql语句，如下：

------创建数据库------

createdatabaseaccount

useaccount

-----系统用户表（可对应多个账户用户）------

createtableCommonUser（

cnamevarchar（10）primarykeynotnull,

cpasswordvarchar（10）notnull,

clevelvarchar（5）notnull

）

-----账户用户表（只对应一个系统用户）-------

createtableAccountUser（

accountvarchar（20）primarykeynotnull,

apasswordvarchar（6）notnull,

realnamevarchar（10）,

addressvarchar（20）,

phonevarchar（15）,

depositint,

statevarchar（5）notnull,

cnamevarchar（10）foreignkeyreferencesCommonUser（cname）ondeletecascade

）

------账户用户存取款日志表-------

createtableMessageLogger（

dealidintprimarykeynotnull,

dealtypevarchar（10）notnull,

dealmoneyint,

dealtimesmalldatetime,

dealaccountvarchar（20）foreignkeyreferencesAccountUser（account）ondeletecascade

）

------账户用户挂失、解挂申请表-------

createtableMessageRegister（

registeridintprimarykeynotnull,

registertypevarchar（5）notnull,

solvementvarchar（5）notnull,

registertimesmalldatetime,

registeraccountvarchar（20）foreignkeyreferencesAccountUser（account）ondeletecascade

）

3.10性能需求

3.10.1数据精确度

在进行向数据库文件提取数据时，要求数据记录定位准确，在往数据库文件数组中添加数时，要求输入数准确金额，身份证，卡号等按需求设定字符数。

3.10.2时间特性

程序响应时间：

在人的感觉和视觉事件范围内；

信息交换时间：

要求在程序调用前调用后都与数据库保持同步更新，网络信息交换施加应该小于程序调用的时间。

3.10.3适应性

要求数据库具有很好的更新能力，由于本产品是实验性软件，故对磁盘和内存容量没有很高的要求，但是数据库应该能够对并发事件，脏数据具有较强的识别处理能力。

四、银行储蓄总体设计

4.1.编写目的

通过前面的需求分析部分，基本明确了本系统的功能需求、性能需求、数据文件结构等的一些方面的要求，故在需求分析的基础上，可以对银行储蓄管理系统进行概要的总体设计，该设计旨在实现系统的大概功能，以及系统的一些交互界面、模块等。

4.2定义

银行储蓄管理系统：

基本元素为构成银行储蓄及相关行为所必须的各种部分。

总体设计：

又称概要设计或初步设计，划分出组成系统的物理元素（程序、文件、数据库、人工过程和文档），设计软件的结构，模块间的关系，但每个物理元素仍处于黑盒子级别，具体分析将在以后的详细设计中说明。

顺序图以二维表显示，横轴代表各个模块的实现中的涉及的角色对象，纵轴是时间轴，时间自上而下。

通过顺序图，可以很好的看到模块中各个对象的建立和销毁，以及对象间的消息传递的交互性。

4.3主要模块设计（顺序图分析）

根据职责划分，可以对系统的功能进行模块化，即不同角色的不同模块间的独立性以及联系，为每个模块的实现进行流程分析，利用顺序图对每个独立模块建立时间上的对象交互流程。

（1）系统普通用户管理：

主要包括开户、销户、挂失、解挂、修改系统密码等模块，分析如下。

用户登录系统后，具有相应的开户权限，用户通过与系统打交道，可以获取一个合理的账户，顺序建模如下：

（2）银行管理员：

增加用户、查看用户、待批申请、已批申请等模块。

模块的分析，以及对象间的交互过程如下。

银行管理员具有增加系统用户的权限，管理员可以为系统增加一些特定的系统用户，同时可以给予他们一定的权限。

模块分析如下：

4.4总体结构设计

五、银行储蓄详细设计

5.1.编写目的

总体设计已经基本确定了每个模块的借口和功能，详细设计的任务就是为每个模块设计其实现细节，详细设计的根本目标就是确定应该怎样具体的实现所需求的系统，得出对目标银行储蓄系统的精确描述。

5.2.定义

软件系统的类有不同的关系依赖，3种更为常见的类型：

依赖、聚集和继承。

依赖性：

一个类的方法出发另一个类的方法，这是“users”关系。

将类之间的依赖关系最小化。

聚集：

聚集有时被称为“hasa”关系。

聚集是一种特殊的依赖，也就是说一个类的部分通过另一个依赖于它的类来定义。

在软件世界里，我们将聚集对象定义为任何将其他对象的引用包含为实例数据的对象。

继承：

继承有时被描述为“isa”关系。

它是一个类从另一个现有类的派生过程。

原始用于派生新类的类称为“基类”或“父类”，派生出来的类称为“派生类”或“子类”。

5.3主要模块设计说明

5.3.1身份验证模块（G1）设计说明

（1）模块描述

设置身份验证模块的目的保证储户信息的安全。

（2）功能

身份验证模块功能在于对申请登录的用户进行身份验证，通过者才能进入系统。

（3）性能

本操作的响应时间应控制在1—2秒内。

（4）输入项

输入项包括：

名称

标识

数据类型

数据值

输入方式

用户ID

customerid

字符

键盘输入

密码

password

字符或数字

键盘输入

（5）输出项

该模块的输出项为合法用户。

（6）设计方法（算法）

银行业务员输入储户用户ID，储户输入密码并确定，系统保存用户输入的用户ID和密码，并在customer表中查找customerid和customername字段值，看是否等于业务员输入的用户ID和密码，如相同则通过验证，否则不通过，并给出“密码错误”的提示，如数据库中不存在这样的记录，则给出“该用户不存在”的提示。

5.3.2存款模块（G2）设计说明

（1）模块描述

设置存款模块的目的在于将储户的金额存到系统中并记录信息。

（2）功能

存款模块将储户存款金额录入存储到系统中，并附带显示其他储户信息。

（3）性能

本操作的响应时间应控制在1—2秒内。

（4）输入项

输入项包括：

名称

标识

数据类型

数据值

输入方式

存款金额

cunkuancount

数字（Double）

>0

键盘或鼠标

（5）输出项

该模块的输出项为存款金额，并且附带显示其他信息：

用户名、账号、账户余额、利息金额。

（6）设计方法（算法）

当银行业务员输入存款金额后，系统进行处理，显示出账户余额，并且显示其他固定信息。

取款模块（G3）设计说明

5.3.3取款模块（G3）设计说明

（1）模块描述

设置取款模块的目的在于将储户的取款金额录入并存储到系统中。

（2）功能

取款模块将储户取款金额录入存储到系统中，并附带显示储户其他信息。

（3）性能

本操作的响应时间应控制在1—2秒内。

（4）输入项

输入项包括：

名称

标识

数据类型

数据值

输入方式

取款金额

qukuancount

数字（Double）

>0

键盘或鼠标

（5）输出项

该模块的输出项为取款金额，并且附带显示其他信息：

用户名、账号、账户余额、利息金额。

（6）设计方法（算法）

当银行业务员输入取款金额后，点击确定按钮，系统进行处理，显示出账户余额，并且显示其他固定信息。

六、银行储蓄系统测试计划

测试设计说明

6.1“按用户名和ID查询”模块（G6）黑盒测试

6.1.1控制

6.1.2输入

按照黑盒测试用例输入用户名和ID

6.1.3输出

输出结果为用户储蓄的各项信息

6.1.4过程

使用测试用例不断进行测试，观察和记录测试结果

6.2“按用户名和ID查询”模块（G6）白盒测试

6.2.1控制

6.2.2输入

按照白盒测试用例输入用户名和ID

6.2.3输出

输出结果为用户储蓄的各项信息

6.2.4过程

使用白盒测试用例不断进行测试，观察和记录测试结果

七、课程设计的心得体会

本课题通过对基于面向对象思想的银行储蓄管理系统做深入分析和设计为目标，利用问题求解的方法，从方案的提出，方案的分析，方案的设计，方案的修改，方案的测试和完善等方面，以用力驱动，建立OO模型，映射关系模型，分析用例交互等，逐步实现系统的整体分析和模块设计。

本课题的分析过程采用了简单的UML建模方法，如用例图、类图、顺序图等的建模，以更直观的图形化分析将软件的功能一步步展现在用户面前，大大简化了文字性描述，提高了效率；同时，高效便捷的开发环境为我们提供了大量的集成控件，大大减少了编码量，为开发过程提供了便捷。