UML建模银行管理系统.docx

上传人:b****7 文档编号:11517587 上传时间:2023-03-02 格式:DOCX 页数:14 大小:319.74KB
下载 相关 举报
UML建模银行管理系统.docx_第1页
第1页 / 共14页
UML建模银行管理系统.docx_第2页
第2页 / 共14页
UML建模银行管理系统.docx_第3页
第3页 / 共14页
UML建模银行管理系统.docx_第4页
第4页 / 共14页
UML建模银行管理系统.docx_第5页
第5页 / 共14页
点击查看更多>>
下载资源
资源描述

UML建模银行管理系统.docx

《UML建模银行管理系统.docx》由会员分享,可在线阅读,更多相关《UML建模银行管理系统.docx(14页珍藏版)》请在冰豆网上搜索。

UML建模银行管理系统.docx

UML建模银行管理系统

 

银行管理系统的UML建模

 

课程设计报告

 

专业:

学号:

姓名:

任课教师:

 

一、系统概述

银行是与人们生活密切相关的一个机构,银行可以提供存款、取款、转账等业务。

在银行设立账户的人或机构被称为银行的客户(customer)。

一个客户可以在银行开设多个账户(account),客户可以存钱到账户中,也可以从自己的账户中取钱,还可以将存款从一个账户转到另一个账户。

另外,客户可以随时查询自己的账户情况,以及查询以前所进行的存款、取款等交易记录。

客户还有权利要求关闭自己的账户。

实际生活中的银行功能其实还要复杂得多,但为了简化系统,本次设计只考虑银行的基本功能。

简化版的银行信息系统至少应具有如下功能:

1.一个银行可以有多个账户;

2.一个银行可以有多个客户;

3.一个客户可以持有多个账户;

4.一个账户可以有多个持有者;

5.银行可以为客户开设账户;

6.银行可以为客户注销账户;

7.客户可以从自己账户中取钱;

8.客户可以向自己账户中存钱;

9.客户可以在同一银行的不同账户之间转账;

10.客户可以在不同银行的不同账户之间转账;

请完成登录、存款、取款、转账和查询几个模块的设计。

二、需求分析

银行系统是与生活紧密相关的一个机构,银行提供了存款、取款、转账等业务。

在银行设立账户的人或机构通常被称为银行的储户。

一个储户可以在银行开多个账户,储户可以存钱到账户中,也可以从自己的账户中取现,还可以将存款从一个账户转到另一个账户。

储户还可以随时查询自己账户的情况,并查询以前所进行的存款、取款等交易记录。

后台管理员可以对客户的账户进行注销、删除、查询等管理,还有就是银行利息、汇率、手续费之类参数的设置,以及财务管理以及财务分析。

软件分别有开户,查询存取款,转账等功能。

各个模块各有不同的功能,但都能完成查询和存取功能。

各模块的数据都存放在数据库中。

数据的调用和连接都有程序来完成。

此软件所要完成的主要功能有三方面:

如果是存款,用户填写存款单,然后交给收银员键入系统,同时系统还要记录存款人姓名,住址,身份证号码,存款类型,存款日期,利率及密码(可选)等信息,完成后由系统反馈成功存款信息给用户。

如果是取款,用户填写取款的相关信息(取款金额、取款币种)进行提交,系统要求用户输入密码以确认身份,核对密码正确无误后系统计算利息并印出利息单给用户。

如果是转账,用户填写转账的相关信息进行提交,系统要求用户输入密码以确认身份,核对密码正确无误后系统计算利息并反馈信息给用户。

系统及时更新数据库。

外部功能:

实现化窗口,开户/销户、存款/取款、查询/转账。

内部功能:

同步,过滤,定位,识别,更新,连接。

三、系统的UML基本模型

(1)、用例图

通过分析对银行管理系统的需求分析,确定参与者有银行客户、收银员。

收银员具有维护系统信息、维护客户信息、查询客户情况和处理处理客户需求的作用。

用例包括:

1)开户、

2)存款、

3)取款、

4)转账、

5)查询、

6)销户等

(2)、用例描述:

用例名称:

银行信息系统

描述:

银行客户对需要办理业务的需求以及收银员对事件的处理。

(3)、银行信息系统的事件流

1.用例存款的事件流

1.1前置条件

在存款之前,客户已经办理银行账号并且带来现金若干,并到达银行网点。

1.2后置条件

如果这个用例成功,这个存款事件是成功的,否则,系统没有变化。

1.3扩充点

1.4事件流

1.4.1基流

(1)客户将银行卡交给收银员。

(2)收银员要求客户输入卡密码。

(3)客户输入卡密码,并确认密码。

(4)收银员提示,请客户选择服务类型。

(5)客户选择存款服务。

(6)收银员提示:

存款数目。

(7)客户说出数目,并把钱交给收银员。

(8)收银员完成服务。

(9)收银员退还卡。

1.4.2替代流

如果输入的密码无效,用户可以重新输入密码或者终止用例。

2.用例转账的事件流

2.1前置条件

在转账之前,客户已经办理银行账号,被转账人的账号已经存在并且已经知道了对方的账号。

2.2后置条件

如果这个用例成功,这个转账事件是成功的,否则,系统没有变化。

2.3扩充点

2.4事件流

2.4.1基流

(1)客户填写转账单。

(2)客户把转账单和银行卡交给收银员。

(3)收银员要求客户输入卡密码。

(4)客户输入卡密码,并确认密码。

(5)收银员转账成功。

(6)收银员退还卡。

2.4.2替代流

如果输入的密码无效,用户可以重新输入密码或者终止用例。

3.用例查询的事件流

3.1前置条件

在查询之前,客户已经办理银行账号并且携带银行卡,并到达银行网点。

3.2后置条件

如果这个用例成功,这个查询事件是成功的,否则,系统没有变化。

3.3扩充点

3.4事件流

3.4.1基流

(1)客户将银行卡交给收银员。

(2)收银员要求客户输入卡密码。

(3)客户输入卡密码,并确认密码。

(4)收银员提示,请客户选择服务类型。

(5)客户选择查询服务。

(6)客户说出查询内容,收银员将内容反馈给客户。

(7)收银员完成服务。

(8)收银员退还卡。

3.4.2替代流

如果输入的密码无效,用户可以重新输入密码或者终止用例。

(4)、活动图

活动图是基于对象的状态变迁所绘制的视图。

收银员首先凭着自己的系统用户名和密码登录系统,收银员可以通过银行客户提供的有效证件号开户,提供客户账号开户、存款、取款、转账、查询、销户等功能,最后退出系统。

1.存款活动图

2.转账活动图

3.查询活动图

(5)、时序图

时序图(SequenceDiagram)主要用于按照交互发生的一系列顺序,显示对象之间的这些交互。

收银员通过用户账号和密码登录系统,在系统的操作窗口对需要存款、取款、转账、查询、销户的用户进行操作,最后退出操作窗口。

我们所开发的银行管理系统时序图如图所示:

(6)、类图

类图是对象结构建模的一部分,类图描述系统中类的静态结构。

类图是代码生成(将模型转化为代码)的来源,也是逆向工程(将代码转化为模型)的目标设生成物。

类图设计如下图:

系统中主要的类

(1)用户类:

它的属性有用户名(Name)、密码(Password)、银行卡号(Cardnumber)、用户身份证号码(ID)。

操作包括修改密码(Changpassword)、存款(deposit)、取款(cash)、转账(transfer)、查询(Chaxun)、、用户开户(Registered)。

(2)系统类:

它的属性有电脑号(Computernumber)、机器地址(Mac)。

本身的操作没有,但有被管理员使用的操作。

(3)收银员类:

它的属性有用户名(name)、密码(password)。

操作包括用户开户(Registeredusers)、注销用户(Deleteusers)、查询用户信息(Chaxun)、系统维护(Weihu)。

(7)状态图

状态图用来表示建模对象是如何改变其状态的,状态定义为对象行为在某一时刻的快照或转折点。

四、结论

系统主要的实现目标是实现客户开户、存款、取款、转账、查询、销户和后台服务器端系统的设计,提供完善的功能设计。

五、总结及心得体会

UML工具很好的帮助我们实现了对银行信息系统的设计,通过UML建模,把事物从抽象到实例化的过程,对每个对象进行细化分析,从而得到简单而方便,容易理解的模型结构。

通过此次试验收获很大,使我们认识到了通过UML模型可以高效完成软件设计,收获颇丰。

 

 

 

一、开发背景与目标 

1.1开发背景 

本系统选题为银行存储系统,是模拟银行存储开发的。

随着计算机的飞速发展及应用领域的扩大,特别是计算机网络和电子商务的发展,极大的改变了商业银行传统的经营模式。

能够为客户提供方便、快捷、安全的服务,也能够有效的降低银行的营运成本,这是银行存储系统追求的目标。

目前,对于现代化银行运营的要求是客户可以实现方便安全的业务交易,银行职员可以进行高效合理的工作管理,实现银行业务电子化

在银行管理系统中,系统包括4个节点,分别是:

银行管理员业务处理节点、

ATM自动取款机节点、系统维护节点、数据库节点。

 

银行管理员业务处理节点,银行管理员通过该节点办理相应业务; ATM自动取款节点,用户通过该节点进行自动取款服务; 

系统维护节点,系统管理员通过该节点进行后台维护,执行银行管理员允许的所有操作;数据库节点,负责数据的存储与处理。

谁使用系统的主要功能?

谁改变系统的数据?

 谁从系统获取信息?

 谁需要系统的支持才能完成日常的工作任务?

谁负责维护,管理并保持系统的正常运行?

系统需要应付,处理那些硬件设备?

系统需要和那些外部系统交互?

谁(或是什么)对系统运行产生的结果感兴趣?

用例图主要用来描述“用户、需求、系统功能单元”之间的关系。

它展示了一个外部用户能够观察到的系统功能模型图。

 

【用途】:

帮助开发团队以一种可视化的方式理解系统的功能需求

 

欢迎您的下载,

资料仅供参考!

 

致力为企业和个人提供合同协议,策划案计划书,学习资料等等

打造全网一站式需求

 

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 法律文书 > 调解书

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1