信用卡管理系统.docx
- 文档编号:15748274
- 上传时间:2023-07-07
- 格式:DOCX
- 页数:68
- 大小:1.75MB
信用卡管理系统.docx
《信用卡管理系统.docx》由会员分享,可在线阅读,更多相关《信用卡管理系统.docx(68页珍藏版)》请在冰点文库上搜索。
信用卡管理系统
数学与计算机学院
实训报告
课程名称:
软件开发设计实训
课程代码:
6014409
题目:
商业银行管理系统
年级/专业/班:
2011级软件工程1班
组员姓名:
蒋俊
组员学号:
312011080611118
开始时间:
2013年09月16日
完成时间:
2013年12月06日
课程设计成绩:
技术水平与实际能力(50)
说明书撰写质量(50)
总分(100)
指导教师签名:
年月日
目录
1需求分析模型重构1
1.1业务需求分析1
1.2非功能性需求分析4
2业务分析模型4
2.1业务主角4
2.2业务用例分析6
2.3业务用例场景分析8
2.4业务用例实现14
2.5业务用例完整的包图15
3概念分析模型15
3.1核心业务活动图15
3.2关键业务概念用例图16
图3.1信用卡管理的核心业务16
3.3概念用例分析16
3.4概念用例实现分析18
3.5概念用例完整的包图20
4系统分析模型20
4.1系统用户分析20
4.2系统用例分析21
4.3系统用例实现分析23
4.4分析类25
4.5组件模型分析38
4.6系统分析完整的包图39
5系统设计模型39
5.1软件架构/框架选择39
5.2基于架构的设计类40
6设计类优化42
6.1设计类优化结果42
6.2采用的设计模式说明45
7面向对象数据库分析设计46
7.1概念数据模型46
7.2概念数据模型优化/调整47
7.3物理数据模型48
总结49
附录A部分生成的SQL语句50
1需求分析模型重构
1.1业务需求分析
1.1.1.背景、业务概况
随着社会经济的发展,以及数字生活的逐步渗透,如何为用户提供更加便捷、更加周到的服务已经成为各大银行竞争的焦点。
但如今银行储蓄系统工作效率比较低,越来越不能满足广大人民群众的需求,人们希望可以更方便更省时更省力的办理储蓄的相关业务。
人们不再满足于以前传统的哪家银行卡只可以在那家银行存款提款的模式。
而如今计算机网络的高速发展及普及度的进一步加强,越来越多的人希望通过在家实现存取款或是通过上网实现网上银行的功能等。
在这样的趋势下,明显可以看出现今的银行计算机储蓄系统不能够满足人们日益增长的需求,为提高该银行的存取款工作效率,降低工作的人力、物力开支,提高工作的准确性、正确性,并且便于用户信息存取,需要建立一个新的、高效的、方便的、互联的计算机储蓄系统。
银行信用卡管理系统是一款为用户提供存款、取款、转账,还款等业务的计算机软件系统。
在银行设立账户的人或机构通常被称为银行的客户。
一个客户可以在银行开多个账户,客户可以存钱到账户中,也可以从自己的账户中取现,还可以将存款从一个账户转到另一个账户。
客户还可以随时查询自己账户的情况,并查询以前所进行的存款、取款、还款等交易记录。
后台管理员可以对客户的账户进行注销、删除、查询等管理,还有就是银行利息、汇率、手续费,还款日期之类参数的设置,以及财务管理以及财务分析。
1.1.2业务目标
通过对业务概括的了解和整理(业务目标既可以由客户提出也可以由开发方整理得出)得出该系统的业务目标如下:
BO-1:
规范银行的内部管理,提高工作效率和管理效能
BO-2:
为客户提供业务办理自动化服务,提高办事效率,方便客户,为客户提供更好的服务
BO-3:
能够有效的管理银行的资金,减少差错。
BO-4:
系统要有简捷的界面,供前台操作员能方便的操作本系统
BO-5:
系统安全稳定
1.1.3涉众分析
1.1.3.1涉众
涉众(stakehoder)是指与要建设系统相关的一切人和事情。
(注意:
涉众不等于用户,用户是系统的使用者,只是涉众的一部分)。
涉众的信息可以通过客户的岗位手册,业务手册等相关的文件中获取,也可以经过访谈而获取。
通过需求陈述分析,得出银行信用卡系统的利益相关者(涉众)如图1.1以及涉众的信息如表1-1:
图1.1涉众分析
表1.1涉众概要信息
编号
名称
说明
期望
SH001
信用卡客户
信用卡客户可以查询与自己相关的信息。
1、可以方便的查询自己的相关信息,费用使用情况。
2、可以通过系统快速查找所需相关信息
3、可以提前消费
SH002
银行终端服务机
负责信用卡客户登录、查询、还款、取款、存款等功能
1、可以提供登录功能
2、可以提供登录客户其自身相关信息管理功能
3、可以提供登录客户其自身相关信息查询功能
4、可以提供信用卡客户取款功能
5、可以提供信用卡客户还款功能
6、可以提供信用卡客户存款功能
SH003
系统管理员
负责整个系统的运作管理
1、用户信息维护
2、用户添加
SH004
银行经理
负责银行报表的生成
1、查看消费情况报表
2、查看开卡情况报表
SH005
银行普通员工
负责为客户办理业务,为客户服务
1、负责客户信息维护
2、查询客户账单
3、负责信用卡管理
4、帮助客户存款、取款、还款
1.1.3.2边界
分析业务目标,得到系统边界
业务目标一:
为客户提供业务办理自动化服务,提高办事效率,方便客户,为客户提供更好的服务,就是一个可能的边界。
为此,能够为客户服务的就应该是银行普通员工、银行终端服务机,而系统管理员和银行经理都与客户服务无关,所以应该划分到边界之外。
系统边界的划分如图1.2所示。
图1.2客户服务边界定义
业务目标二:
客户能有效的对个人的信息,个人消费进行管理,减少人为差错。
系统边界的划分如图1.3所示
图1.3客户个人管理边界定义
业务目标三:
使整个银行系统正常运作,系统边界的划分如图1.4所示
图1.4系统服务边界定义
业务目标四:
对银行资金进行管理,查看客户的消费情况,银行客户的数量。
系统边界的划分如图1.5所示
图1.5报表管理边界定义
1.2非功能性需求分析
1.2.1性能(PEformance)需求
PE-1:
系统要求用户进行相应操作后系统的响应时间应尽量短,不能超过一定的时间范围本设计暂规定为10s。
PE-2:
在进行向数据库文件提取数据时,需求数据记录定位精确,在往数据库文件数组中添加数时,要求输入数精确金额,身份证,卡号等按消息设定字符数。
PE-3:
要求数据库具有很好的更新能力,数据库应该能够对并发事件,脏数据具有较强的识别处理能力。
PE-4:
为满足系统在以后运行过程中出现问题能够修正以及系统需要升级等要求,系统应该具有可维护、可扩充、可更新的性能。
1.2.2安全性(SEcurity)需求
SE-1:
每条充值记录都需要有日志文件能够查询。
SE-2:
保证充值或扣款事务的完整进行,不受特殊情况(如断电,误操作等)而影响数据的完整性、一致性。
SE-3:
系统运行应该满足具有一定能够避免黑客、病毒等恶意攻击的安全防范措施。
2业务分析模型
2.1业务主角
2.1.1客户管理业务主角
在客户服务边界之外,客户,系统管理人员、银行经理是在边界外的涉众。
对所有客户来说,假设客户不会直接使用系统,而是由银行内的普通员工代为填写电子表单并提交,另外客户也是通过终端机对系统进行查询交互,那么银行普通员工和终端机将代表客户行使其系统利益,也就是说对客户服务边界而言,虽然利益来自于客户,但由于客户不直接与边界说代表的系统交互,而委托银行内普通员工或者终端机来代表其与系统交互,
因此客户不能构成为业务主角,银行普通员工和终端机则代表涉众利益的业务主角。
而管理人员、采购部门和系统维护部门都是和用户没有直接联系的,所以通过分析,可以得到客户管理的主角。
如图2.1所示
图2.1客户管理主角
2.1.2系统管理业务主角
银行系统主要由系统管理员来维护,其系统管理主角如图2.2所示
图2.2系统管理主角
2.1.3报表管理业务主角
对银行的有效管理是至关重要的,银行经理通过报表有效的对客户员工信息进行管理,直观的了解银行的运营状况,信息需要通过银行普通员工输入到信用卡管理系统中。
所以银行经理和银行普通员工是其业务主角,其报表管理主角如图2.3所示
图2.3报表管理主角
2.2业务用例分析
从岗位手册、业务流程指南和职务说明等一些文件以及与客户的访谈结果可以得出业务用例图。
2.2.1客户管理业务用例
根据客户管理业务分析,得到其用例如图2.4所示:
图2.4客户管理业务用例
2.2.2客户个人管理业务用例
根据客户个人管理业务分析,得到其用例如图2.5所示:
图2.5客户个人管理业务用例
2.2.3报表管理业务用例
根据报表管理业务分析,得到其用例如图2.6所示:
图2.6报表管理业务用例
2.2.4系统管理业务用例
根据系统管理业务分析,得到其用例如图2.7所示:
图2.7系统管理业务用例
2.3业务用例场景分析
2.3.1客户信息查询业务用例场景分析
客户信息查询主要是指银行普通员工对客户开卡信息进行查询,通过数据库可以很方便的查询客户的信息。
便于管理,银行普通员工必须拥有查询员工信息的权利,银行普通员工成功登录银行管理界面,进入银行普通员工操作界面,对客户信息进行查询,根据客户的唯一标识符ID号进行查询,通过数据库查询需要的客户信息并返回的结果,其客户信息查询的时序图(如图2.8)以及活动图(如图2.9)、协作图(如图2.10)
图2.8客户信息查询的时序图
图2.9客户信息查询的活动图
图2.10客户信息查询的协作图
2.3.2柜台存款业务用例场景分析
柜台存款是客户和银行交互的关键用例,银行普通员工有为客户服务的义务,银行普通员工成功登录银行管理界面,进入银行普通员工操作界面,对客户进行存款、数据库更新,当数据库更新时,显示存款成功。
其柜台存款的时序图(如图2.11)以及活动图(如图2.12)、协作图(如图2.13)
图2.11柜台存款时序图
图2.12柜台存款活动图
图2.13柜台存款协作图
2.3.3添加客户信息业务用例场景分析
添加客户信息主要是指银行普通员工对客户基本信息的添加,添加到数据库,便于银行相关人员精确的管理,,银行普通员工有为客户服务的义务,银行普通员工成功登录银行管理界面,进入银行普通员工操作界面,添加开户的客户的信息,生成唯一标识符ID号,保存在数据库,返回显示添加成功,其添加客户信息的时序图(如图2.14)以及活动图(如图2.15)、协作图(如图2.16)
图2.14添加客户信息时序图
图2.15添加客户信息活动图
图2.16添加客户信息协作图
2.3.4账单查询业务用例场景分析
银行普通员工需要经常了解客户的消费情况,判断是否预支,预支是否超期,需要查询客户的账单,是否需要催款,银行普通员工成功登录银行管理界面,进入银行普通员工操作界面,
根据ID号查询账单,并返回客户的消费情况。
其账单查询的时序图(如图2.17)以及活动图(如图2.18)、协作图(如图2.19)
图2.17账单查询时序图
图2.18账单查询活动图
图2.19账单查询协作图
2.4业务用例实现
2.4.1柜台存款业务用例实现
在实际工作中,某些业务用例有多重实现路径,这时应当绘制其用例实现视图,用来组织实现业务对象和业务过程,柜台存款用例实际上是包括了柜台存款和柜台还款两种方式实现。
其用例实现如图2.20
图2.20柜台存款的用例实现
2.4.2客户信息维护业务用例实现
在实际工作中,某些业务用例有多重实现路径,这时应当绘制其用例实现视图,用来组织实现业务对象和业务过程,客户信息维护用例实际上是包括了查询客户信息和修改客户信息、删除客户信息三种方式实现。
其用例实现如图2.21
图2.21客户信息维护用例实现
2.5业务用例完整的包图
图2.20业务用例包图
3概念分析模型
3.1核心业务活动图
信用卡管理系统最核心的业务就是开卡,用户消费,柜台存款,绘制该核心业务活动图,如图3.1所示
3.2关键业务概念用例图
…………
…………
画出所有的业务用例实现
图3.1信用卡管理的核心业务
3.3概念用例分析
3.3.1信用卡管理概念用例分析
3.3.1.1信用卡管理概念用例
当核心业务找到后,就要根据业务主线的需要,为这些业务用例找到概念用例,获取概念用例的目的是为了完成业务主线,信用卡管理的概念用例图如图3.2所示
图3.2信用卡管理概念用例图
3.3.1.2开卡概念用例场景分析
为了更清楚地分析开卡概念用例,就需要对开卡概念用例进行用例场景分析,通过活动图分析开卡的整个过程,开卡需要包括客户的申请,银行经理的审核,以及普通员工为其客户办理,如图3.3所示
图3.3开卡概念用例活动图
3.4概念用例实现分析
3.4.1开卡概念用例实现分析
3.4.1.1开卡概念用例实现(时序图)
绘制了核心业务流程,就要从系统对象的角度来解释业务主线如何在计算机中运行,利用时序图表示核心流程中的“开卡”关键对象是如何在系统中实现的。
如图3.4所示
图3.4开卡关键对象实现过程分析
3.4.1.2开卡概念用例场景分析对象(类图)
根据用例场景,找出来了核心对象,其对象有:
“客户信息”、“开卡信息”、“信用卡信息”如图3.5所示
图3.5完成开卡分析对象
3.4.2卡信息维护概念用例实现分析
3.4.2.1卡信息维护概念用例实现(时序图)
绘制了核心业务流程,就要从系统对象的角度来解释业务主线如何在计算机中运行,利用时序图表示核心流程中的“卡信息维护”关键对象是如何在系统中实现的。
如图3.6所示
图3.6卡信息维护关键对象实现过程分析
3.4.2.2卡信息维护概念用例场景分析对象(类图)
根据用例场景,找出来了核心对象,其对象有:
“卡信息”、“客户信息”、“ID信息、金额信息”如图3.7所示
图3.7卡信息维护对象图
3.5概念用例完整的包图
图3.8概念用例包图
4系统分析模型
4.1系统用户分析
系统用户是直接操作系统的人员,银行普通员工,银行经理,系统管理员他们所做的事情是通过计算机来做的事情,所以他们都是系统用户,其系统用户如图4.1
图4.1系统用户
4.2系统用例分析
4.2.1系统用例图
系统用例应当只描述一次完整的计算机交互过程,通过对业务场景用例(活动图),一个一个活动进行分析,绘制出系统用例图,如图4.2所示
图4.2系统用例图
4.2.2系统用例图场景分析(活动图)
用活动图来描述系统用例如图4.3以及图4.4所示
图4.3添加信用卡客户用例场景
图4.4查询信用卡客户用例场景
用活动图来描述了系统用例,就需要对系统用例书写用例规约对其进一步说明。
如表4.1所示
表4.1添加客户信息用例规约
用例名称
添加客户
用例描述
开卡时,银行普通员工添加客户,录入基本信息(姓名,手机号,卡号等)
执行者
银行普通员工
前置条件
银行普通员工成功登录系统,进入客户信息管理界面
后置条件
1、创建新的客户,并生成唯一的客户ID
2、创建信用卡
主事件流描述
1、银行普通员工正确输入用户名密码并成功登陆系统,系统显示银行普通员工界面,银行普通员工选择客户管理界面,系统显示客户管理界面
2、银行普通员工开始实现一次添加客户信息活动
3、银行普通员工选择添加客户信息菜单
4、系统打开添加客户信息页面
5、银行普通员工向系统中增添客户信息
6、创建客户对象
7、查询数据库中客户信息是否存在,是否合法。
8、若客户信息在数据库中不存在并且合法,系统向数据库中添加客户信息,否则重复3-7步
9、系统判断是否添加成功
10、显示添加信息。
分事件流描述
银行普通员工选择否,系统显示取消操作
异常事件流描述
客户信息不完整,不能添加
业务规则
遵循银行相关规则
涉及的实体
客户、银行普通员工
4.3系统用例实现分析
4.3.1系统用例实现用例图
系统用例的用例实现的目的是实现系统的需求,反映了这些用例,计算机是怎么实现的
其系统用例实现用例图如图4.5所示
图4.5系统用例实现用例图
4.3.2用例实现场景分析(活动图)
分析“图4.4查询信用卡客户用例场景”每个活动,通过分析每个活动得到边界对象、控制对象和实体对象,用时序图表示其用例实现场景,如图4.5所示
4.4分析类
图4.5信用卡客户信息查询用例实现
分析“图4.3添加信用卡客户用例场景”每个活动,通过分析每个活动得到边界对象、控制对象和实体对象,用时序图表示其用例实现场景如图4.6所示
图4.6添加信用卡客户用例实现
4.4.1实体类
图4.7实体类
4.4.2控制类
图4.8控制类
4.4.3边界类
图4.9边界类
4.4.4各系统分析模型
4.4.4.1添加信用卡客户分析模型
分析“图4.23添加信用卡客户分析类图”绘制添加信用卡客户信息的Window层分析模型,如图4.10所示
图4.10添加信用卡客户window层实现
根据添加信用卡客户window层实现时序图绘制分析类图,如图4.11所示
图4.11添加信用卡客户window层实分析类图
BusinessControl层实现
图4.12添加信用卡客户Business层实现
根据添加信用卡客户Business层实现时序图绘制分析类图,如图4.13所示
图4.13添加信用卡客户Business层分析类图
Entity层实现
图4.14添加信用卡客户Entity层实现
根据添加信用卡客户Business层实现时序图绘制分析类图,如图4.15所示
图4.15添加信用卡客户Entity层分析类图
通过上面3个层的分析类图得到“添加信用卡客户用例最终分析模型”如图4.16所示
图4.16添加信用卡客户用例最终分析模型
4.4.4.2查询信用卡客户信息分析模型
分析“图4.24查询信用卡客户分析类图”绘制查询信用卡客户信息的Window层分析模型,如图4.17所示
图4.17查询信用卡客户window层实现
图4.18查询信用卡客户window层分析类图
图4.19查询信用卡客户Business层实现
图4.19查询信用卡客户Business层分析类图
图4.20查询信用卡客户Entity层实现
图4.21查询信用卡客户Entity层分析类图
通过上面3个层的分析类图得到“查询信用卡客户用例最终分析模型”如图4.22所示
图4.22查询信用卡客户用例最终分析模型
4.4.5各系统分析类图
4.4.5.1添加信用卡客户分析类图
把在“实体类”“控制类”“边界类”三个包中新建的类直接拖入到其视图中,用关联关系连接起来,如图4.23所示
图4.23添加信用卡客户分析类图
4.4.5.2、查询信用卡客户分析类图
把在“实体类”“控制类”“边界类”三个包中新建的类直接拖入到其视图中,用关联关系连接起来,如图4.24所示
图4.24查询信用卡客户分析类图
4.5组件模型分析
组件是一种特殊的包,它用来组织所有的类,在传统模式下信息查询只在银行终端机上进行查询,不需要建立组件模型,但是随着业务的发展需要,信用卡客户可以通过Internet网在网上查询个人信息,业务模型发生改变。
查询信息就需要被两种不同业务进行调用。
因此需要通过组件模型来实现业务扩展。
如图4.25以及图4.26所示
图4.25信息查询组件运行环境
图4.26信用卡管理业务用例组件图
4.6系统分析完整的包图
图
图4.27系统分析包图
5系统设计模型
5.1软件架构/框架选择
5.1.1软件架构描述
软件架构需要在业务架构的基础上引入计算机环境,软件架构的目的就是要说明业务架构如何发布在计算机环境中,和如何执行,架构需要描述两个方面的内容,一是针对业务领域的理解,二是针对系统领域的理解,分别对应为业务架构和软甲架构,用包图软件架构如图5.1所示
图5.1用包图描述软件架构
5.2基于架构的设计类
5.2.1window层设计类
图5.2window层设计类
图5.3window层设计类
5.2.2Business设计类
图5.4Business层设计类
图5.5Business层设计类
6设计类优化
6.1设计类优化结果
数据访问层所做的事务就是直接操作数据库,针对数据的增添、删除、修改、更新、查找等,如图6.1所示
图6.1对数据库操作类图
业务逻辑层是系统架构中体现核心价值的部分,处于数据访问层与表示层中间,起到了数计交换中承上启下的作用,其类图如图6.2所示
、
图6.2
图6.2业务逻辑类图
实体层描述系统中具体对象所属类,实体层里面的一个类对应数据库里面的一张表,类里面的每个属性对应表里面的一个字段,每个属性都有自己的GET和SET方法,项目中的数据存取都要依靠GET和SET方法实现,信用卡管理系统的实体类有客户,银行普通员工,部门,账单。
其如图6.3所示
图6.3实体类图
6.2采用的设计模式说明
信用卡管理系统采用的是FactoryMethod设计模式,使用的多层结构,包括数据访问层、控制层、实体层、服务层、表示层,业务逻辑层。
其包图如图6.4所示
图6.4结构包图
7面向对象数据库分析设计
7.1概念数据模型
概念数据模型是实体-联系(Entity-RelationShip,简称E-R)理论为基础,并对这一理论进行了扩充。
是面向数据库用户的实现世界的模型
图7.1概念数据模型
7.2概念数据模型优化/调整
概念数据模型优化是生成概念数据模型后,为每个对象找其主键的过程,如图7.2所示
图7.2概念数据模型优化
7.3物理数据模型
物理数据模型(PhysicalDataModel)PDM,提供了系统初始设计所需要的基础元素,以及相关元素之间的关系。
即用于存储结构和访问机制的更高层描述,描述数据是如何在计算机中存储的,如何表达记录结构、记录顺序和访问路径等信息。
使用物理数据模型,可以在系统层实现数据库。
图7.3物理数据模型
总结
通过这学期的软件开发实训,让我学到了很多东西,熟悉了PowerDesigner作图软件,也认识到了PowerDesign
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 信用卡 管理 系统