银行管理系统设计.docx
- 文档编号:23981621
- 上传时间:2023-05-23
- 格式:DOCX
- 页数:45
- 大小:295.69KB
银行管理系统设计.docx
《银行管理系统设计.docx》由会员分享,可在线阅读,更多相关《银行管理系统设计.docx(45页珍藏版)》请在冰豆网上搜索。
银行管理系统设计
课程设计报告
学生姓名:
学号:
学院:
班级:
题目:
银行管理系统设计
银行储蓄管理系统
指导教师:
职称:
2011年7月15日
1、选题背景
银行储蓄管理软件的主要作用是针对于各类银行中的储蓄业务进行有效管理。
银行储蓄是我们现实生活中的常见活动。
就储蓄业务而言,无论国外还是国内,也无论是那家银行,虽然所开展的业务种类稍有不同,利息的计算也存在差异,但储蓄的本质是完全相同的。
在我国加入WTO以后,各银行的业务逐渐和国际接轨。
银行与企业是市场经济中两个重要的经济主体,两者间的关系是现代市场经济中最重的经济关系之一[1]。
世界经济发展史表明,商业银行从其诞生之日起,便与企业结下了不解之缘,企业的存在是银行产生的前提,企业的发展是银行发展的基础;而银行是企业资金的主要提供者之一,对企业的生产经营具有相当大的影响作用。
商业银行为了保证贷款的安全性、盈利性和流动性,必然会对企业的经营情况和信用程度进行详尽的事前调查分析以及事后的跟踪总结。
现在的银行储蓄系统工作效率低,越来越不能满足广大人民群众的需要,人们希望能更方便、省时就可以办理储蓄业务;随着拥有银行卡的人群不断增加,人们急切希望能有一种通用的银行卡以便方便在哪家银行都可以存款取款;现在计算机网络的高速发展使越来越多的人更喜欢在网上购物、在家存款取款。
本次开发以一个虚拟银行为背景,在深入了解通用的银行储蓄业务管理要求的基础上,力争开发出一个实用性强的通用储蓄系统软件,基本上可满足正常银行业的工作需要。
本项目对系统的安全保密性要求也较高。
另外,还要实现多币种的储蓄业务。
设计者必须了解并掌握银行储蓄业务的一般要求及银行核算的规则(如利息计算的规则、节假日规则、币种兑换规则等)。
同时,应该能模拟出消费者的外部消费与银行的结算业务。
项目工作量和专业跨度较大。
2、银行业务管理系统需求分析
2.1银行管理系统的需求陈述
现在的银行储蓄系统工作效率低,越来越不能满足广大人民群众的需要,人们希望能更方便、省时就可以办理储蓄业务;随着拥有银行卡的人群不断增加,人们急切希望能有一种通用的银行卡以便方便在哪家银行都可以存款取款;现在计算机网络的高速发展使越来越多的人更喜欢在网上购物、在家存款取款。
在这样的背景下,现在的银行储蓄系统已经不能满足人们日益增长的需求,急切需要建立一个新的、高效的、方便的、互联的银行储蓄系统。
在使用此时,需要用户的登录,由系统判断该帐户是否有效(帐户密码是否正确),若密码输入不正确,则再次显示让用户输入密码,若3次输入的密码均不正确,系统自动退出服务,若密码输入正确,则系统进入选择服务类型界面:
1.存款,2.取款,3.查询余额,然后系统根据服务类型进行相应操作,若选择取款操作,系统确认取款请求以后,会询问取款数额,系统界面显示输入数额请求,用户输入取款数额,系统接到信息后发出确认取款请求,用户选择确认,系统选择确认后会向点钞机发出钞请求,然后点钞机出钞,系统向用户发出去钞请求,用户取钞以后,系统记录此次取款并自动计算余额,更新帐户信息,然后系统界面进入是否选择继续服务界面,用户点击否,然后系统退出,至此,取款业务完成。
若选择存款业务,系统确认存款请求以后,系统界面进入请放入存款界面,然后用户将存款放入存款口,系统提示点钞机进行点钞,点钞完毕后,系统记录存款操作并更新余额,系统界面显示存款完毕,然后系统界面进入是否选择继续服务界面,用户点击否,则系统退出,存款业务完成。
若用户选择查询业务,若查询余额,系统确认请求以后根据其账号信息查取余额,并在界面显示余额为多少。
2.2需求分析
2.2.1功能需求
(1)功能划分
软件分别有创建、删除帐户,修改帐户信息,存钱、取钱,及在不同的帐户之间转账(可以是同一银行,也可以跨行)等功能。
各个模块各有不同的功能,但都能完成查询和存储功能。
各模块的数据存放在数据库中。
数据的调用和连结都由程序来完成。
此软件所要完成的主要功能有两方面:
如果是存款,储户填写存款单,然后交给键入系统,同时系统还要记录用户姓名、用户id号、帐号和所存款项的金额等信息,完成后由系统打印存款单给储户。
如果是取款,储户填写取款单交给业务员,业务员把取款金额输入系统要求储户输入密码以确认身份,核对密码正确无误后系统计算利息并印出利息清单给储户。
(2)功能描述
外部功能:
实现化窗口,查询及储蓄。
内部功能:
更新,同步,过滤,定位,识别。
存款功能:
以储户的存款为主要活动,相关记录根据存款结果进行调整,以使信息保持一致。
系统需要在原帐户信息中增加一条记录,包括存款人姓名、住址、存款类型、存款日期、利率等信息。
若为新储户须建立一个帐户,并记录此次的记录。
打印存款单给储户。
取款功能:
系统计算利息,在原帐户信息中将取款减去。
若为清户,记录注销该帐户,将帐户余额一并交与储户。
打印利息清单给储户。
余额查询功能:
为储户提供查询余额服务,将储户的相关记录输出。
①需要储户的帐户信息及密码。
②打印储户的帐户余额。
更新功能:
根据用户的存储数量,系统能够自动更新,并且应储户的需求修改密码并保存。
①需要储户输入帐户及密码,若想修改密码按下一个键,输入密码按确定,并且要求储户再次确认密码。
②系统保存储户信息,并且系统实现自动更新。
2.2.2性能需求
(1)数据精确度
在进行向数据库文件提取数据时,需求数据记录定位精确,在往数据库文件数组中添加数据时,要求输入数精确金额、身份证、卡号等按消息设定字符数。
(2)时间特性
程序响应时间:
在人的感觉和视觉事物范围内;
信息交换时间:
要求在程序调用前后都与数据库保持同步更新,网络信息交换时间应该小于程序调用时间。
(3)适应性
要求数据库局用很好的更新能力,由于本产品是试验性软件,故对磁盘和内存容量没有很高的要求,但是数据库应该能够对并发事件,脏数据具有较强的识别处理能力。
(4)磁盘容量
由于要存储大量的数据和信息,所以要求要有足够的磁盘容量。
(5)主存容量
为了满足储户的要求,系统必须要有高的运作速度,储户填写的表单输入到系统,系统必须能快速作出响应,迅速处理各项数据、信息,显示出所有必需信息并打印出各项清单,所以要求很高的信息量速度和大的主存容量;由于要存贮大量的数据和信息,也还要有足够大的磁盘容量。
除此之外,安全性也是系统最重要的性能需求之一,银行计算机储蓄系统必须有可靠的安全措施,以保证储户的存储安全。
2.3系统需求建模
2.3.1确定参与者
系统中参与者(Actor)信息如表1所示。
表2-1ctor一览表
Actor
中文名称
可选操作
Clerk
银行职员
创建、删除帐户,并可以修改帐户信息
CustomerActor
客户
存钱、取钱,并在不同的帐户之间转账
BankActor
银行
客户可以在BankActor中设立或关闭帐户
2.3.2 确定用例
系统中各用例信息如表2所示。
表2-2例一览表
用例识别符
优先级
UseCase
中文名称
简单用例描述
ZY01
1
Login
登录
提供验证用户身份的功能
ZY02
1
Depositfund
存款
提供存钱到帐户的功能
ZY03
1
Withdrawfund
取款
提供从帐户中取钱的功能
ZY04
1
MaintainAccount
管理帐户
提供创建、删除帐户,以及修改帐户信息的功能
ZY05
1
Transferfundwithinabank
在银行内转帐
提供了在属于同一银行的帐户之间转帐的功能
ZY06
1
Transferfundbetweenbanks
在不同的银行之间转帐
提供了在属于不同银行的账户之间转帐的功能
系统中执行优先级情况如表3所示。
表2-3优先级说明
优先级
优先级名称
优先级描述
1
基本的
必须实现的功能
2.3.3 系统用例建模
根据银行的业务流程、系统参与者确定了系统的主业务用例模型,银行系统主业务用例图如图2-1所示。
图2-1银行系统主业务用例图
2.3.4用例描述
登录(Login)用例
登录用例如表2-4所示
表2-4登录用例
用例名称
登录
表示符
ZY01
用例描述
描述了用户如何登录到系统中
参与者
用户
优先级
1
状态
审查通过
前置条件
无
后置条件
如果用例成功,则用户登录到系统之。
否则,系统状态不变。
基本操作流程
当用户想登录到银行信息系统中时,用例启动。
(1)系统提示用户输入用户名和密码。
(2)用户输入自己的用户名和密码,提交。
(3)系统验证输入的名字和密码(E-1),用户登录系统成功。
可选操作流程
E-1:
如果输入用户名和(或)密码无效,系统提示错误信息,用户可以重新输入或中止该用例。
存款(Depositfund)用例
存款用例如表2-5所示
表2-5存款用例
用例名称
存款
表示符
ZY02
用例描述
本用例允许客户借助Clerk存款到帐户中
参与者
客户
优先级
1
状态
审查通过
前置条件
在本用例开始前,Clerk必须登陆到系统中
后置条件
如果用例成功,则客户账户中存款的金额发生变化。
否则,系统状态不变。
基本操作流程
当客户向存钱到自己的账户时,要向Clerk提供存款单和先进,用例启动。
(1)系统提示Clerk输入用户姓名、用户id号、帐号和所存款项的金额。
(2)Clerk输入相关信息后提交,系统确认帐户是否存在并有效(E-1)
(3)系统建立存款实践记录,并更新账户的相关信息。
可选操作流程
E-1:
账户不存在或者无效,显示提示信
息,用户可以重新输入或终止该用例。
取款(Withdrawfund)用例
取款用例如表2-6所示
表2-6取款用例
用例名称
取款
表示符
ZY03
用例描述
本用例允许Clerk按照客户的要求从客户的帐户中取款
参与者
客户
优先级
1
状态
前置条件
本用例开始前,用户必须登录到系统中
后置条件
如果用例成功,则客户账户中存款的金额发生变化。
否则,系统状态不变。
基本操作流程
当客户向存钱到自己的账户时,要向Clerk提供存款单和先进,用例启动。
(1)系统提示Clerk输入用户姓名、用户id号、帐号和所取款项的金额。
(2)Clerk输入相关信息后提交,系统确认帐户是否存在并有效(E-1),账户中的存款金额是否足够支付所取款项(E-2)。
(3)系统建立存款实践记录,并更新账
户的相关信息。
可选操作流程
E-1:
账户不存在或者无效,显示提示信息,用户可以重新输入或终止该用例。
E-2:
账户中的存款金额不足,显示提示信息,用户可以重新输入金额或终止该用例。
管理帐户(MaintainAccount)用例
管理账户用例如表2-7所示
表2-7管理账户用例
用例名称
管理帐户
表示符
ZY04
用例描述
提供创建、删除帐户,以及修改帐户信息的功能
参与者
客户
优先级
1
状态
审查通过
前置条件
在本用例开始前,Clerk必须登陆到系统中
后置条件
如果用例成功,则客户账户中存款的金额发生变化。
否则,系统状态不变。
基本操作流程
当Clerk想添加\修改或删除账户信息时,用例启动.
系统要求Clerk选择所要执行的活动(添加账户、修改账户信息、或删除帐户)。
如果所选的活动是“添加帐户”,则执行分之流S-1:
添加帐户。
如果所选的活动是“删除帐户”,则执行分之流S-2:
删除帐户。
如果所选的活动是“修改帐户”,则执行分之流S-3:
修改帐户信息。
S-1:
添加帐户
(1)系统要求Clerk输入客户信息:
姓名、用户id号、帐号、地址、存储金额。
(2)Clerk输入帐号后提交。
(3)系统为客户建立帐户。
(4)将帐户信息存储到数据库中。
S-2:
删除用户
(1)系统提示Clerk输入帐号(E-1)。
(2)Clerk输入帐号后提交。
(3)系统检索帐户信息(E-2)。
(4)显示帐户信息。
(5)Clerk确认删除(E-3)。
(6)关闭帐户。
(7)从系统中删除帐户。
S-3:
修改帐户信息
(1)系统提示Clerk输入帐号(E-1)。
(2)Clerk输入帐号后提交。
(3)系统检索帐户信息(E-2)。
(4)显示帐户信息。
(5)Clerk修改帐户信息。
(6)Clerk修改完毕后提交。
(7)系统更新帐户信息。
可选操作流程
E-1:
账户不存在或者无效,显示提示信息,用户可以重新输入或终止该用例。
E-2:
帐户不存在,系统显示错误信息,Clerk重新输入帐号或取消操作(用例终止)。
E-3:
取消删除,删除帐户操作被取消,用例终止。
转账:
转账在银行内转帐(Transferfundwithinabank)用例
在不同的银行之间转帐(Transferfundbetweenbanks)用例
转账用例如表2-8所示
表2-8转账用例
用例名称
转账
表示符
ZY05
用例描述
本用例允许Clerk按照用户的要求将资金从一个账户转到另一个账户。
参与者
客户
优先级
1
状态
审查通过
前置条件
本用例开始前,用户必须登陆到系统中。
后置条件
如果用例成功,则客户账户中存款的金额发生变化。
否则,系统状态不变。
基本操作流程
当客户要求转帐时,用例启动
(1)系统提示Clerk输入用户姓名、用户id号、帐号和所损款项的金额。
(2)Clerk输入相关信息后提交.
(3)系统确认帐户是否存在并有效(E-1),账户中的存款金额是否足够支付所取款项(E-2)。
(4)系统建立存款实践记录,并更新账户的相关信息。
(5)为资金转出账户建立转帐记录。
(6)存储转帐记录。
(7)判断资金转入帐户是否属于同一银行。
如果资金转入账户与资金转出账户适于同一银行,则执行分支流S-1:
在同一银行的账户间转帐。
如果资金转入账户与资金转出账户适于不同银行,则执行分支流S-2:
在不同银行的账户间转帐。
S-1:
在同一银行的账户间转帐
(1)系统确认资金转入帐户是否存在并有效(E-1)。
(2)更新资金转入账户的相关信息。
(3)为资金转入账户建立转帐记录。
(4)存储转帐记录.
S-2:
在不同银行的账户间转帐.
(1)发送转帐通知给另一个银行.
可选操作流程
E-1:
账户不存在或者无效,显示提示信息,用户可以重新输入或终止该用例。
E-2:
账户中的存款金额不足,显示提示信息,用户可以重新输入金额或终止该用例。
3、银行管理系统系统分析
3.1系统用例建模
用例视图是被称为参与者的外部用户所能观察到的系统功能的模型图。
用例是系统中的一个功能单元,可以被描述为参与者与系统之间的一次交互作用。
用例模型的用途是列出系统中的用例和参与者,并显示哪个参与者参与了哪个用例的执行。
用例建模的主要目标是:
1、将需求模型变为可视化模型,并最终得到用户确认;
2、给出清晰、一致的关于系统做什么的描述,确定系统的功能要求;
3、提供从功能需求到系统分析、设计、实现各阶段的度量标准;
4、为最终系统测试提供基准,据此验证系统是否达到功能要求。
通过整理调研内容,根据岗位职责,划分出参与业务活动的各种角色(不完全等同于岗位职责)。
这些角色主要有:
银行职员,客户,银行。
根据银行主要的业务过程,对照岗位职责确定系统中的业务用例。
使用业务用例刻画了业务活动中的各个角色以及它们在业务活动中的关系。
系统主业务用例图如图3-1所示。
图3-1银行系统主业务用例图
3.2静态结构模型
3.2.1 类的识别
起初,按“名词找类法”分析得到系统中的类有:
储户、银行、银行业务员、存款、取款、查询、转账、销户、本金、利息等。
后来经过多次去重和删掉无用的类及属性,得到最终的系统设计到的类是:
银行、账户、用户、交易、存款、取款、转账。
在这一过程中,例如银行业务员等候选类,被列入到最终类的属性中。
1.根据给出的需求陈述,从陈述中找出下列名词,可以把它们作为类与对象的初步的候选者:
银行,账户,客户,资金,计算机,储蓄管理系统,存储卡,工作人员,存/取款单。
通常,在需求陈述中不会一个不漏地写出问题域中的所有有关的类与对象,因此,分析员应该根据领域知识或常识进一步把隐含的类与对象提取出来。
2.筛选出正确的类与对象
通过一个简单、机械的过程不可能正确地完成分析工作。
非正式分析仅仅帮助人们找到一些候选的类与对象,接下来应该严格考察每个候选对象,从中去掉那些不必要的,仅仅保留确实应该记录其信息或需要其提供服务的那些对象。
筛选时主要依据下列标准,删除不正确或不必要的类与对象。
3.2.2 类的关联分析
类是应用领域或应用解决方案中概念的描述。
类图是以类为中心来组织的,类图中的其他元素或属于某个类或与类相关联。
静态视图用类图来实现,正因为它以类为中心,所以称其为类图。
在类图中类用矩形框来表示,它的属性和操作分别列在分格中。
如不需要表达详细信息时,分格可以省略。
一个类可能出现在好几个图中。
同一个类的属性和操作可只在一种图中列出,在其他图中可省略。
关系用类框之间的连线来表示,不同的关系用连线上和连线端头处的修饰符来区别。
银行管理系统的类图如图3-2所示。
图3-2银行业务类图
3.2.3 类的属性描述
类名:
Bank基本信息
功能:
记录物理存在银行的基本信息
属性:
银行代码、银行名称、银行地址、联系电话和传真
类名:
Account基本信息
功能:
记录用户账户的基本信息
属性:
银行名、账户号、持有者姓名、持有者ID、创建日期
类名:
Customer基本信息
功能:
记录客户的基本信息
属性:
客户姓名、客户地址、客户的ID、客户的账号
类名:
Transaction信息
功能:
对交易结果进行统计
属性:
账号、交易日期、交易的金额
类名:
Deposit信息
功能:
对用户的存款信息进行记录
属性:
账号、存款日期、存款金额
类名:
Withdraw信息
功能:
对用户的取款信息进行记录
属性:
账号、取款日期、取款金额
类名:
Transfer信息
功能:
对用户的转账信息进行记录
属性:
账号、转账账号、转账日期、转账银行、转账金额
3.3系统动态模型
3.3.1系统执行顺序分析
顺序图表示了对象之间传送消息的时间顺序。
每一个类元角色用一条生命线来表示,即用垂直线代表整个交互过程中对象的生命期。
生命线之间的箭头连线代表消息。
顺序图可以用来进行一个场景说明——即一个事务的历史过程。
顺序图的一个用途是用来表示用例中的行为顺序。
当执行一个用例行为时,顺序图中的每条消息对应了一个类操作或状态机中引起转换的触发事件。
顺序图将交互关系表示为一个二维图。
纵向是时间轴,时间沿竖线向下延伸。
横向轴代表在协作中各独立对象的类元角色。
类元角色用生命线表示。
当对象存在时,角色用一条虚线表示;当对象的过程处于激活状态时,生命线是一个双道线。
消息用从一个对象的生命线到另一个对象生命线的箭头表示。
箭头以时间顺序在图中从上到下排列。
顺序图的图形元素组成成分:
对象、生存线、消息和激活期。
1.对象:
顺序图中所包含的每个对象用一个对象框表示,对象名需要带下划线。
2.生存线:
对象框下画垂直的虚线,称为该对象的生存线,表示对象的生存时间。
3.激活期:
对象生存线上的一个长方形框,表示该对象的激活时间段,即活动期。
4.消息:
在顺序图中,对象之间的消息发送和接收用两个对象生存线之间的消息箭头线表示,用来指出该对象执行期间的顺序。
①银行系统登录顺序图
对象之间传送消息的时间顺序如图3-3所示,它的先后顺序如图所列。
图3-3银行系统登录顺序图
②银行存款顺序图
对象之间传送消息的时间顺序如图3-4所示,它的先后顺序如图所列。
图3-4银行存款顺序图
③银行取款顺序图
对象之间传送消息的时间顺序如图3-5所示,它的先后顺序如图所列。
图3-5银行取款顺序图
④银行内转账顺序图
对象之间传送消息的时间顺序如图3-6所示,它的先后顺序如图所列。
图3-6银行内转账顺序图
⑤银行间转账顺序图
对象之间传送消息的时间顺序如图3-7所示,它的先后顺序如图所列。
图3-7银行间转账顺序图
⑥银行创建账户顺序图
对象之间传送消息的时间顺序如图3-8所示,它的先后顺序如图所列。
图3-8银行创建账户顺序图
⑦银行删除账户顺序图
对象之间传送消息的时间顺序如图3-9所示,它的先后顺序如图所列。
图3-9银行删除账户顺序图
⑧银行修改账户顺序图
对象之间传送消息的时间顺序如图3-10所示,它的先后顺序如图所列。
图3-10银行修改账户顺序图
3.3.2系统的协作分析
协作图和顺序图都可以表示各对象间的交互关系,但它们的侧重点不同。
顺序图用消息的几何排列关系来表达消息的时间顺序,各角色之间的相关关系是隐含的。
协作图用各个角色的几何排列图形来表示角色之间的关系,并用消息来说明这些关系。
在实际中可以根据需要选用这两种图。
一个协作图描述了系统中为实现某些服务所涉及的对象扮演的角色及其相互之间的交互。
协作图着重于有协作关系的对象之间的交互和链接(指对象实例之间的物理或概念上的链接,一个链接是某关联的一个实例)。
它可用于图示系统中的操作执行、用例执行或一个简单的交互场景。
协作图描述了对象及其之间的链接,还描述了链接的对象之间如何发送消息。
①银行系统登录协作图
对象之间协作关系如图3-11所示。
图3-11银行系统登录协作图
②银行存款协作图
对象之间协作关系如图3-12所示。
图3-12银行存款协作图
③银行取款协作图
对象之间协作关系如图3-13所示。
图3-13银行取款协作图
④银行内转账协作图
对象之间协作关系如图3-14所示。
图3-14银行内转账协作图
⑤银行间转账协作图
对象之间协作关系如图3-15所示。
图3-15银行间转账协作图
⑥银行创建账户协作图
对象之间协作关系如图3-16所示。
图3-16银行创建账户协作图
⑦银行删除账户协作图
对象之间协作关系如图3-17所示。
图3-17银行删除账户协作图
⑧银行修改账户协作图
对象之间协作关系如图3-18所示。
图3-18银行修改账户协作图
3.3.3系统状态分析
状态图描述了事件和对象状态的关系。
状态图描绘事件与对象状态的关系。
由事件引起的状态改变称为“转换”。
用一张状态图描绘一类对象的行为,它确定了由事件序列引出的状态序列不是任何一个类都需要有一张状态图描绘它的行为。
系统分析员应该集中精力仅考虑具有重要交互行为的那些类。
状态图(StateDiagram)用来描述一个特定对象的所有可能的状态及其引起状态转移的事件。
一个状态图包括一系列的状态以及状态之间的转移。
状态 所有对象都具有状态,状态是对象执行了一系列活动的结果。
当某个事件发生后,对象的状态将发生变化。
状态图中定义的状态有:
1、初态—状态图的起始点,一个状态图只能有一个初态。
2、终态—是状态图的终
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 银行 管理 系统 设计